Czas na rozmowę… rozmowę o czasie rozwiązania problemu i MTTR! Czas rozwiązania problemu to wskaźnik, który istnieje odkąd pamiętam. Chociaż czas rozwiązania problemu (lub MTTR) nie jest niczym nowym, nadszedł czas, aby przyjrzeć się mu bliżej i wyjaśnić, co naprawdę oznacza.
Dlaczego teraz? Ponieważ czas potrzebny na rozwiązanie problemów… jest bardzo ważny! A czas potrzebny na rozwiązanie problemów jest w istocie wskaźnikiem użyteczności i doświadczenia użytkownika. Jest to również jeden z tych wskaźników, które są bardzo często źle rozumiane i błędnie interpretowane. Przejdźmy więc do sedna sprawy!
W tym przewodniku „Czas na rozwiązanie”
Czym jest czas rozwiązania?
Co rozumiesz przez „czas rozwiązania”?
Czas potrzebny do rozwiązania problemu (MTTR) to średni czas potrzebny do rozwiązania sprawy lub incydentu o takich samych objawach podczas awarii lub scenariusza rozwiązywania problemów.
Czas rozwiązania = czas od wystąpienia incydentu do jego rozwiązania w trakcie przerwy w działaniu
Zasadniczo czas rozwiązania to wskaźnik, który informuje nas, jak długo użytkownicy czekają na usunięcie określonego błędu. Nie ma znaczenia, czy ludzie mają ten sam problem, czy też doświadczają innego, ale raczej to, czy spotkali się już z czymś podobnym i ile czasu zajmuje im przywrócenie działania poprzez znalezienie rozwiązania.
MTTD i MTTR: jaka jest różnica?
MTTD i MTTR są z tej samej serii. Ale nie są takie same! MTTR pokazuje, ile czasu zajmuje przywrócenie systemu do działania, a MTTD pokazuje, ile czasu minęło od wystąpienia incydentu do jego rozwiązania. Żeby było prościej, w tym poście skupimy się na czasie potrzebnym do rozwiązania problemu, ale chciałem, żebyście wiedzieli o tej małej różnicy między MTTD a MTTR.
MTTD odnosi się do czasu od wystąpienia incydentu do momentu jego rozwiązania.
MTTR odnosi się do czasu od wystąpienia incydentu do momentu jego rozwiązania.
Przykład: Czas wystąpienia zdarzenia (TOI) i czas rozwiązania (TOR)
Pomocne jest myślenie o MTTR w następujący sposób: problem pojawia się w momencie X, użytkownik A potrzebuje średnio Y czasu, aby znaleźć rozwiązanie, a następnie problem zostaje rozwiązany w momencie Z.
Należy również pamiętać, że MTTD oznacza czas od wystąpienia incydentu do jego rozwiązania, natomiast MTTR oznacza czas od wystąpienia problemu do momentu jego rozwiązania. Może się to wydawać trywialne, ale myślę, że wszyscy spotkaliśmy się z tym nieporozumieniem więcej niż raz, więc chciałem się upewnić, że wszystko jest jasne.
Kiedy należy mierzyć czas rozwiązania problemu?
Time To Resolve dostarcza nam świetnych danych, gdy chcemy zrozumieć poziom zadowolenia użytkowników w przypadku powtarzających się błędów – tych o podobnych symptomach. Na przykład:
– Dlaczego moja strona znów nie działa? To samo zdarzyło się w zeszłym tygodniu! Nie mogę uwierzyć, że nie potraficie zapobiec powtarzaniu się takich sytuacji...
– Po aktualizacji przeglądarki ciągle pojawia się ten komunikat. Czy ktoś mógłby to sprawdzić?
– Instrukcje, które przesłałeś, nie były jasne. Czy ktoś mógłby je jeszcze raz sprawdzić?
Jeśli czas rozwiązania problemu jest czymś, co można zmierzyć (a czas rozwiązania problemu jest możliwy do zmierzenia dla każdego), to pomoże on zrozumieć, ile czasu zajmuje użytkownikom przywrócenie pełnej funkcjonalności po awarii. Zasadniczo chodzi o to, ile czasu zajęło użytkownikom ponowne podjęcie pracy po wystąpieniu problemu.
W końcu „czas to pieniądz”! Zobaczmy więc, jak możemy zapewnić, aby czas potrzebny na rozwiązanie problemu był zawsze dostępny...
Czas potrzebny do rozwiązania problemu pozwala nam obliczyć czas, przez jaki użytkownicy czekają na rozwiązanie danej kwestii. Następnie możemy porównać te dane w czasie i między różnymi zespołami. Istnieje kilka innych kluczowych wskaźników wydajności (KPI), które służą do określenia, czy w tym obszarze występują problemy – czas potrzebny do rozwiązania problemu jest jednym z nich!
Jak mierzyć czas potrzebny do rozwiązania problemu?
Przede wszystkim, aby móc wykorzystać czas potrzebny do rozwiązania problemu, należy go zmierzyć. Czas potrzebny do rozwiązania problemu można mierzyć na trzy sposoby: (1) czas od wystąpienia incydentu do momentu jego rozwiązania, (2) czas trwania awarii, (3) czas od wystąpienia incydentu do momentu jego zamknięcia. Każda z tych metod ma swoje zalety i wady, a także różne sposoby raportowania, dlatego przy wyborze metody dla swojego zespołu należy wziąć te kwestie pod uwagę. Przyjrzyjmy się poniżej tym trzem metodom.
1.) Czas od wystąpienia incydentu do momentu jego rozwiązania: Jest to doskonały wskaźnik dla zespołów, które chcą szybko reagować, ponieważ umożliwia szybkie pobranie danych po wystąpieniu awarii. Jedną z wad jest utrata niektórych danych historycznych, jeśli problem nie zostanie rozwiązany w ciągu 72 godzin (co kiedyś uważano za dobrą praktykę), ale szybkość ta wzrasta w dłuższych okresach, co może pomóc w sporządzaniu raportów. Czas rozwiązania problemu w czasie awarii jest jednym z naszych najpopularniejszych wskaźników dotyczących czasu rozwiązania!
2.) Czas od wystąpienia incydentu do momentu zamknięcia: Oto przykład czasu od wystąpienia incydentu do momentu zamknięcia, gdzie widać, że między pojawieniem się problemu a momentem, w którym użytkownik z tego konkretnego zgłoszenia mógł ponownie rozpocząć pracę, minęło 100 minut. Metoda ta zajmuje więcej czasu niż pobranie danych bezpośrednio po awarii, ale zapewnia nam znacznie więcej danych historycznych z dłuższego okresu. Dane te mogą być analizowane przez różne zespoły w celu dokładnego zbadania, co powoduje najdłuższe opóźnienia (i dlaczego).
3.) Czas od momentu zidentyfikowania problemu do momentu jego zamknięcia: Oto kolejny przykład czasu od momentu zidentyfikowania problemu do momentu jego zamknięcia. Tym razem widać, że rozwiązanie problemu zajęło użytkownikowi 50 minut, a także jasne jest, że czas ten obejmuje dane z kilku ostatnich dni, a nie tylko z jednego. Należy pamiętać, że jest to trudniejsze do uzyskania niż w przypadku innych metod, ponieważ problemy są zazwyczaj aktualizowane w miarę postępów w przepływie pracy — należy więc pamiętać, że potrzebujemy co najmniej 24 godzin między aktualizacjami, zanim będziemy mogli zarejestrować dane dotyczące czasu rozwiązania problemu.
Zazwyczaj czas do rozwiązania (pomiar) należy do jednej z trzech poniższych kategorii:
– w czasie przestoju (gromadzone dane dotyczące czasu obejmują czas przestoju oraz czas potrzebny personelowi na rozwiązanie problemu)
– po czasie przestoju (dni lub tygodnie po zebraniu danych dotyczących czasu)
– czas oczekiwania w kolejce (od momentu rozpoczęcia pracy w systemie do momentu zamknięcia systemu).
Twoi użytkownicy czekają, co teraz?
W tym miejscu czas potrzebny do rozwiązania problemu staje się trudny! Pamiętaj, że „czas” to pieniądz, dlatego ważne jest, aby poświęcić odpowiednią ilość czasu na rozwiązanie problemu związanego z danymi i przekształcenie ich w coś użytecznego. Oto kilka pytań, które możesz sobie zadać:
– Jak duże jest to naprawdę problem?
– Jak wygląda ten problem w czasie? Czy dostrzegasz jakieś trendy?
– Czy mój zespół poprawia się, czy pogarsza w zakresie szybkiego rozwiązywania problemów?
Poświęcenie czasu na analizę danych i przekształcenie ich w coś użytecznego może być trudne – czasami zespoły dysponują ogromną ilością informacji, ale wiedzą, że nie mogą wprowadzić zmian bez poświęcenia czasu na analizę danych. Dzięki analizie danych dotyczących czasu potrzebnego do rozwiązania problemu będziesz mógł nie tylko porównać się z innymi podmiotami z branży, ale także sprawdzić, jak efektywnie wykorzystujesz swój czas w tym obszarze!
Wskazówki dotyczące skrócenia czasu rozwiązania problemu i średniego czasu naprawy (MTTR)
Wiesz już, czym jest czas rozwiązania problemu, jak go mierzyć i śledzić. Teraz chcesz zmniejszyć ten niezwykle ważny wskaźnik. Oto nasze ulubione wskazówki!
– Nie bój się przestać robić rzeczy, które są czasochłonne, ale nie są ważne. Jeśli poświęcasz czas na wiele rzeczy, które tylko go zabierają, a nie dodają wartości, to może warto przemyśleć te działania.
– Zacznij korzystać (lub kontynuuj korzystanie)z platformy obserwowalności lub systemu zarządzania incydentami, takiego jakPagerduty lub alternatywnych rozwiązań, które dają mniejszą możliwość popełnienia błędu w porównaniu z pocztą elektroniczną lub arkuszami kalkulacyjnymi, jeśli w ten sposób obecnie śledzisz incydenty. E-maile mogą się zgubić lub zostać zapomniane, arkusze kalkulacyjne stają się nieuporządkowane i mylące, a ostatecznie czas będzie upływał, podczas gdy Ty będziesz próbował rozwiązać problemy.
– Zawsze ustalaj priorytety swojej pracy – zacznij od najważniejszych zadań, ponieważ zajmą one najwięcej czasu, a następnie ustal priorytety czasu potrzebnego do wykonania zadania, aby zaoszczędzić czas.
– Inne sposoby na skrócenie czasu rozwiązania problemu to: posiadanie jasnego procesu, który jest łatwy do przestrzegania, zapewnienie odpowiedniego przeszkolenia zespołu na każdym poziomie oraz stała wiedza o tym, jakie zgłoszenia znajdują się w kolejce – dzięki temu dokładnie wiesz, ilu użytkowników czeka na Ciebie!
Czas do rozwiązania problemu i MTTR – końcowe przemyślenia
Czas rozwiązania problemu jest doskonałym wskaźnikiem jakości pracy działu IT. Służy on jako wskazówka, że problemy są rozwiązywane prawidłowo i z uwzględnieniem zarządzania czasem. Efektywny czas rozwiązania problemu oznacza, że kwestie są rozwiązywane wystarczająco szybko, aby zespoły mogły zająć się problemami, ale nie zbyt szybko, aby nie traktować ich jako „gaszenia pożarów”, a raczej jako dogłębną analizę przyczyn źródłowych problemu. Dobry wskaźnik KPI dotyczący czasu rozwiązania problemu pomaga zespołom odpowiedzieć na pytania dotyczące między innymi obsługi klienta, wydajności i czasu poświęconego na zadania, dlatego ważne jest, aby nie tylko „skupiać się” na czasie rozwiązania problemu, ale także zrozumieć, co to oznacza dla Twojego zespołu!



