Міф про вдалий досвід, Директор інформаційної служби, Видавництво «Відкриті системи»
Оцінка змісту операційних процесів у третій версії ITIL показує, що частина з них була перенесена з другої версії до третьої шляхом простого копіювання
Розробники третьої версії ITIL приділили багато уваги оновленню структури тактичних процесів – це стає очевидним після прочитання книг Service Strategy та Service Design. Проте інновації не торкнулися базових операційних процесів. Розробники перебувають під впливом минулого досвіду і не помічають, що назріла потреба змінити давно застарілі концепції. «Навіщо чіпати те, що й так добре працює?» - виправдовуються вони.
Розглянемо, наприклад, базовий операційний процес управління – управління інцидентами. У ITIL 2 наведено варіант консервативної схеми розміщення пріоритетів, що визначаються на строві терміновості вирішення інцидентів та їх впливу на бізнес. Іншими словами, величина пріоритету розраховується за поєднанням значень параметрів терміновості дозволу та сили впливу (або ступеня впливу) інциденту.
Схема підтримується безліччю рішень Service Desk. Вимога забезпечити атрибути «пріоритет», «терміновість» та «вплив» входить до списку критеріїв Pink Verify, найвідомішого у світі методичного засобу для перевірки відповідності програмного рішення ITSM рекомендаціям ITIL.
Слухачі лекцій та учасники семінарів проектування завжди просять пояснити зміст цієї схеми. Майже нікого не задовольняють стандартні пояснення. Уважних слухачів, які вже володіють навичками впровадження ITSM, або досвідчених менеджерів процесів теоретичні пояснення не влаштовують ніколи. Учасники семінару завжди намагаються доповнити та доопрацювати схему розміщення пріоритетів. Кожна така дискусія все більше переконувала,що необхідно оновити схему чи хоча б доповнити її іншими варіантами.
Розподіляємо інциденти
Звернемося тепер до значення пріоритету, вираженого в годиннику і визначає крайній термін виконання. Розглянемо ситуацію, коли відразу після початку роботи над інцидентом з високим пріоритетом (червоний) до виконавця до робочої групи несподівано надходить нескладний інцидент з пріоритетом нижче (жовтий), але найближчим крайнім терміном виконання. Логічно дозволитиме «жовтий» інцидент, не допустивши зриву термінів щодо нього. А вже потім завершуватиме інцидент «червоний».
Нерівні умови можуть виникати у разі відсутності послідовного надходження інцидентів на вхід процедури їх вирішення та перерозподілу завдань за робочими групами, виконавцями (наприклад, за необхідності концентрації ресурсів, їх перерозподілу).
Звичайно, в ідеальному світі процесів вищого рівня зрілості частка таких ситуацій прагне нуля, проте ми живемо у реальному світі. Хорошою варто визнати практику орієнтуватися щодо порядку робіт на час, що залишилося до крайнього терміну виконання (аналогічна пряма рекомендація в ITIL не найдена). Правила розподілу, побудовані на такій практиці, підійдуть як для випадку, коли інциденти надходять послідовно, так і для випадків, коли інциденти надходять вразки з будь-яких причин.
Призначаємо інциденту пріоритет
Мало мати таблицю, схему пріоритетів для інцидентів та розподіляти інциденти відповідно до пріоритету. Потрібно ще й вміти призначити конкретний пріоритет для конкретного інциденту. Призначення та зміна контрольних пріоритетів виконавцем призводить до краху, оскільки отримаємо «контроль виконуючого» та стандартну проблему класичної моделі надання.послуг, розрив у розумінні якості обслуговування виконавцем послуги та користувачем послуги. Пріоритет виконавця не завжди збігається з пріоритетом користувача, більш того, пріоритети ІТ-фахівців та користувача послуги найчастіше не збігаються!
Як правило, ключову роль у розміщенні пріоритетів відіграє перша лінія підтримки. Частково це вирішує проблему розриву в обслуговуванні. Перша лінія забезпечує єдину точку контакту з користувачем та часто обстоює його інтереси.
Однак чи має перша лінія підтримки необхідну кваліфікацію для використання об'єктивних критеріїв, для керування потоком інцидентів?
Як інструмент об'єктивної вказівки пріоритету ITIL пропонує параметри «дві срібні кулі» — терміновість та вплив.
Оцінити вплив дещо простіше — легко визначити інциденти, які впливають всю організацію. Але чи багато буває значних інцидентів за рік і чи варто заради цього доповнювати класифікацію, що щодня використовується? Як бути з незначними інцидентами, що впливають на одного користувача послуги або кількох користувачів, відділ, департамент, один чи кілька філій, нарешті? У момент першого інциденту про справжній рівень впливу мало відомо до початку діагностики. У такому разі фахівці першої лінії підтримки повинні мати як мінімум експертні технічні знання і, бажано, розбиратися в бізнес-специфіці послуг. Хоча, безперечно, можна спробувати обійтися простим даром передбачення.
Таким чином ми знову повертаємося до необхідності використовувати для класифікації інцидентів висококласних експертів, що неефективно.
Є срібна куля!
Проте вирішення цієї проблеми існує. Звернемося до першоджерела і трохи пильніше поглянемо на ціліпроцесу керування інцидентами.
Першоджерело дає нам до рук абсолютно чітку і недвозначну підказку щодо реалізації однієї з процедур управління інцидентами. Вищий пріоритет має надаватися тим інцидентам, вплив яких на послуги більш критичний для бізнесу і, отже, вони мають бути виправлені насамперед.
Необхідно одразу звернутися до формально чи неформально затвердженого документа, що містить вимоги до рівня обслуговування, тобто угоди про рівень обслуговування (Service Level Agreement, SLA). Швидко потрібно відновити ті послуги, відсутність або неякісне надання яких зазнає більших збитків бізнесу, що має бути відображено в SLA. Нормальне надання послуг також має бути визначене у SLA. Адже одним із значущих для замовника результатів є своєчасне відновлення до певного рівня обслуговування за обумовлений час.
Вкрай бажаним елементом для працездатності цієї схеми буде реалізований каталог послуг. У грамотно спроектованому каталозі послуг диспетчеру нескладно визначити послугу, що не працює або працює нижче обумовленого рівня, яку і має на увазі користувач при зверненні. У будь-якому випадку, користувач буде ідентифікований першою лінією підтримки, що відразу дозволить визначити набір SLA з користувачами цього підрозділу.
Тут ми не розглядаємо велику сферу інцидентів, які не належать до збоїв — консультації, скидання пароля, встановлення нового робочого місця, оповіщення від системи моніторингу, тобто запити на обслуговування та події. Дати однозначні рекомендації про те, як класифікувати разом зі збоями всі численні види подій та запитів просто неможливо.
Пріоритизація на основі послуг
Можливі також комбінації перших двох підходів із залученням додаткових аналітик.
Обидві схеми, що пропонуються, об'єктивні з точки зору класифікації інцидентів співробітником першої лінії підтримки і на практиці, як правило, дають кращий результат, ніж стандартна схема «терміновість — вплив».
Другий підхід пропонує, не змінюючи ключової ідеї, перенести аналітику на такі рівні самого каталогу послуг. Призначаючи інциденту послугу з другого або третього рівня каталогу, оператор автоматично проставляє пріоритет, вже заданий для послуги. Прикладом такої пріорітизації буде послуга каталогу «ERPERP логістика усунення збою».
У межах першого підходу найчастіше типи інцидентів приймаються однаковими всім послуг. Друга схема значно гнучкіша, проте каталог виходить складнішим, трудомістким і витратним. Крім того, друга схема обмежує або сильно ускладнює можливості порівняння аналітики інцидентів різних послуг між собою та ускладнює прийняття управлінських рішень. Існують інші ефективні схеми пріоритизації, засновані на послузі.
Безперечно одне: концепція визначення пріоритету у процесі управління інцидентами, без змін перенесена до ITIL 3, давно застаріла. Її потрібно приводити до механізму пріорітизації, що базується на послузі та SLA.
Олександр Жилинський - ІТ-консультант департаменту консалтингу та інтеграції компанії «Інлайн Груп», [email protected]
Поділіться матеріалом з колегами та друзями