Настав час поговорити про час вирішення проблем і MTTR

Що таке час вирішення?

Що ви маєте на увазі під «часом вирішення»?

Час вирішення (MTTR) дає нам середній час, необхідний для вирішення випадку або інциденту з однаковими симптомами під час відключення або усунення проблеми:

Час вирішення = час від виникнення інциденту до його вирішення під час перерви в роботі

По суті, час вирішення — це показник, який вказує, скільки часу користувачі чекають на усунення певної помилки. Не має значення, чи люди стикаються з однаковою проблемою, чи з іншою, а важливо, чи стикалися вони з чимось подібним раніше і скільки часу їм потрібно, щоб відновити роботу, знайшовши рішення.

MTTD та MTTR: у чому різниця?

MTTD і MTTR — це два поняття, що мають спільне походження. Але вони не є однаковими! MTTR показує час, необхідний для відновлення роботи системи, тоді як MTTD показує час від моменту виникнення інциденту до його вирішення. Для простоти в цій статті ми зосередимося на часі вирішення, але я хотів би, щоб ви знали про невелику різницю між MTTD і MTTR.

MTTD означає час від виникнення інциденту до його вирішення.

MTTR означає час від моменту виникнення інциденту до моменту його вирішення.

Приклад: Час інциденту (TOI) та час вирішення (TOR)

Корисно розглядати MTTR таким чином: проблема виникає в момент часу X, користувачеві A потрібно в середньому Y часу, щоб знайти рішення, і потім проблема вирішується в момент часу Z.   

Також майте на увазі, що MTTD означає час від моменту виникнення інциденту до його вирішення, а MTTR означає час від моменту виникнення проблеми до її вирішення. Це може здатися дрібницею, але я думаю, що ми всі не раз стикалися з цією плутаниною, тому я хотів переконатися, що все абсолютно ясно.

Коли слід вимірювати час вирішення проблеми?

Time To Resolve надає нам чудові дані, коли нам потрібно зрозуміти ступінь задоволеності користувачів щодо повторюваних помилок – тих, що мають схожі симптоми. Наприклад:

– Чому мій сайт знову не працює? Це ж сталося тільки минулого тижня! Не можу повірити, що ви не можете запобігти тому, щоб це повторювалося знову і знову…

– Після оновлення браузера я постійно отримую це повідомлення. Чи не могли б ви попросити когось перевірити це?

– Надіслані вами інструкції були нечіткими. Чи може хтось ще раз їх переглянути?

Якщо час вирішення проблеми є тим, що ви можете виміряти (а час вирішення проблеми є можливим для кожного), то час вирішення проблеми допоможе вам зрозуміти, скільки часу потрібно вашим користувачам, щоб відновити роботу після збою. По суті, скільки часу знадобилося користувачам, щоб знову почати працювати після виникнення проблеми?

Адже «час» – це гроші! Тож давайте подивимося, як ми можемо забезпечити, щоб час для вирішення завжди був доступний для використання ...

Час вирішення проблеми дозволяє нам обчислити, скільки часу ваші користувачі чекають на вирішення проблеми. Потім ми можемо порівняти ці дані за певний період часу та між різними командами. Існує кілька інших ключових показників ефективності (KPI), які використовуються для визначення наявності проблем у цій сфері, і час вирішення проблеми є одним з них!

Як виміряти час до вирішення?

Перш за все, щоб використовувати час вирішення, його потрібно виміряти. Час вирішення можна виміряти одним із трьох способів: (1) час від інциденту до часу вирішення; (2) час під час перерви в роботі; (3) час від інциденту до часу закриття. Кожен із цих методів має свої переваги та недоліки, а також особливості звітування, тому враховуйте це, обираючи метод для своєї команди. Давайте розглянемо ці три способи нижче.

1.) Час від інциденту до вирішення: це чудовий показник для команд, які хочуть швидко вирішити проблему, оскільки ви можете швидко отримати дані після виникнення збою. Одним із недоліків є те, що ви втрачаєте деякі історичні дані, якщо проблема не була вирішена протягом 72 годин (що раніше вважалося доброю практикою), але ця швидкість збільшується протягом більш тривалого періоду, що може допомогти з часом для звітування. Час до вирішення проблеми під час збою є одним з наших найпопулярніших показників часу вирішення!

2.) Час від інциденту до моменту закриття: ось приклад часу від інциденту до моменту закриття, де ви можете побачити, що між моментом виникнення проблеми та моментом, коли користувач у цьому конкретному квитку зміг відновити роботу, минуло 100 хвилин. Цей метод займає більше часу, ніж просто витяг даних відразу після збою, але він дає нам набагато більше історичних даних за більш тривалий період часу. Ці дані можна аналізувати в різних командах, щоб дійсно розібратися в тому, що займає найбільше часу (і чому).

3.) Час від виявлення проблеми до її вирішення: Ось ще один приклад часу від виявлення проблеми до її вирішення. Цього разу ви можете бачити, що користувачеві знадобилося 50 хвилин, щоб вирішити свою проблему, і також зрозуміло, що цей час бере дані за кілька днів, а не за один. Пам'ятайте, що це складніше, ніж інші методи, оскільки проблеми, як правило, оновлюються в міру проходження вашого робочого процесу, тому майте на увазі, що нам потрібно щонайменше 24 години між оновленнями, перш ніж ми зможемо зібрати дані про час вирішення.

Зазвичай час вирішення проблеми (вимірювання) відноситься до однієї з цих трьох категорій:

– під час простою (дані про час включають час простою та час, необхідний персоналу для вирішення проблеми)

– після часу відключення (дні або тижні після збору даних про час)

– час очікування в черзі (час початку в системі до часу закриття в системі).

Ваші користувачі чекають, що тепер?

Ось тут і виникає складність із термінами вирішення! Пам'ятайте, що «час» — це гроші, тому важливо не поспішати, щоб вирішити проблему з даними і перетворити їх на щось корисне. Ось кілька питань, які можуть вам допомогти:

– Наскільки серйозною є ця проблема?

– Як ця проблема виглядає з плином часу? Чи помічаєте ви якісь тенденції?

– Чи покращується моя команда у швидкому вирішенні проблем, чи погіршується?

Витрачати час на аналіз даних і перетворення їх у щось корисне може бути складно – іноді команди мають дуже багато інформації, але розуміють, що не можуть внести зміни, не маючи часу на аналіз даних. Збираючи дані про час, необхідний для аналізу, ви зможете не тільки порівняти себе з колегами по галузі, але й побачити, наскільки ефективно використовується ваш час у цій сфері!

Поради щодо скорочення часу вирішення проблеми та середнього часу відновлення роботи (MTTR)

Отже, ви знаєте, що таке час вирішення, як його вимірювати та відстежувати. Тепер ви хочете зменшити цей надзвичайно важливий показник. Ось наші улюблені поради!

– Не бійтеся припинити робити те, що забирає багато часу, але не є важливим. Якщо ви витрачаєте час на багато речей, які просто додають часу, але не додають цінності, то, можливо, настав час переоцінити ці дії.

– Почніть використовувати (або продовжуйте використовувати)платформу спостереження або систему управління інцидентами, таку якPagerduty або альтернативні варіанти, де менше можливостей для помилок, на відміну від електронної пошти або електронних таблиць, якщо саме так ви зараз відстежуєте інциденти. Електронні листи можуть загубитися або бути забуті, електронні таблиці стають безладними і заплутаними, і в кінцевому підсумку час продовжує спливати, поки ви намагаєтеся вирішити проблеми.

– Завжди розставляйте пріоритети у своїй роботі – починайте з найважливіших завдань, оскільки вони займуть найбільше часу, а потім розставляйте пріоритети за часом, необхідним для виконання завдання, щоб заощадити час.

– Інші способи скоротити час вирішення проблеми включають: наявність чіткого процесу, який легко дотримуватися, забезпечення належного навчання вашої команди на всіх рівнях та постійне відстеження черги запитів – таким чином ви точно знатимете, скільки користувачів чекають на вас!

Час до вирішення проблеми та MTTR: остаточні міркування

Час вирішення проблеми є чудовим показником якості роботи ІТ-відділу. Він використовується як індикатор того, що проблеми вирішуються правильно та з урахуванням управління часом. Ефективний час вирішення проблеми означає, що проблеми вирішуються достатньо швидко, щоб команди могли їх вирішити, але не надто швидко, щоб не вважати це «гасінням пожежі», а дійсно глибоким аналізом першопричини проблеми. Хороший показник часу до вирішення KPI допомагає командам відповідати на питання про обслуговування клієнтів, ефективність, час, витрачений на виконання завдань, тощо, тому важливо не просто «зосередитися» на часі до вирішення, а й зрозуміти, що це означає для вашої команди!