Миф о лучшей практике: заметки на полях ITIL v3: приоритеты инцидентов

Много лет назад Френсис Бэкон разработал учение об идолах – ложных предрассудках, мешающих познанию. Похоже, пора дополнить его учение мифологией «лучших практик». Роб Инглэнд (Rob Englang), широко известный как IT Skeptic, публикует шокирующие статьи. Шаг за шагом Роб играючи и остроумно доказывает, что внедрение конфигурационной базы данных в понимании ITIL версии 2 невозможно по определению и сходу приводит десятку причин отказаться от внедрения CMDB.

Много лет назад Френсис Бэкон разработал учение об идолах – ложных предрассудках, мешающих познанию. Похоже, пора дополнить его учение мифологией «лучших практик». Роб Инглэнд (Rob Englang), широко известный как IT Skeptic, публикует шокирующие статьи. Шаг за шагом Роб играючи и остроумно доказывает, что внедрение конфигурационной базы данных в понимании ITIL версии 2 невозможно по определению и сходу приводит десятку причин отказаться от внедрения CMDB.

По мере чтения обновленной, третьей версии ITIL также возникает ряд вопросов: так, например, представители организаций с высоким уровнем зрелости при освоении новой версии библиотеки интересуются вопросами тактического и стратегического уровня процессов – управление жизненным циклом услуги, каталогом услуг, уровнем обслуживания, доступностью услуг. И действительно, если начинать чтение с высокоуровневых книг Service Strategy, Service Design различия в структуре процессов заметны невооруженными взглядом.

Решения ITIL

Разберем один простой пример, касающийся базового операционного процесса управления – Управление Инцидентами. С давних пор ITIL приводит пример консервативной схемы расстановки приоритетов: Приоритет = Срочность x Влияние. Другими словами, величина приоритета рассчитывается по сочетанию параметров срочности и влияния инцидента. Схема поддерживается множеством решений Service Desk. Требование обеспечить наличие атрибутов приоритет, срочность и влияние входит в список критериев Pink Verify, наиболее известного в мире методического средства для проверки, соответствует ли программное решение ITSM рекомендациям ITIL. Попробуем внимательнее рассмотреть процедуру классификации и назначения приоритетов. Очевидно, что ее целью будет подача на вход последующих шагов наиболее достоверной и объективной информацию о приоритете – атрибуте, определяющем степень важности инцидентов относительно друг друга, порядок их обработки.

Распределяем инциденты

В рекомендуемой ITIL схеме значимость приоритета показана двумя способами: собственно в названии приоритета – «критический», «высокий», «средний», в значении плановом сроке устранения (target resolution time, он же крайний срок исполнения, оно же просто deadline) – 1 час, 8 часов, 24 часа.Работу с инцидентом начинают с той задачи, которая имеет более высокий приоритет. Из двух задач с приоритетами Критический и Средний обычно выбирается Критический при прочих равных условиях.

Неравные условия могут возникать в случаях: отсутствия последовательного поступления инцидентов на вход процедуры и переброски задач по рабочим группам, исполнителям (например, необходимость концентрации ресурсов, их перераспределения). Конечно, в идеальном мире процессов высшего уровня зрелости доля таких ситуаций стремится к нулю, однако мы все-таки живем в реальном мире. Хорошей стоит признать практику ориентироваться при определении порядка работ по времени, оставшемуся до крайнего срока исполнения. Правила распределения, построенные на такой практике, универсальны – они работают когда инциденты поступают последовательно, когда инциденты поступают «вразброс» по любым причинам.

Назначаем инциденту приоритет

Приоритет исполнителя не всегда совпадает с приоритетом пользователя, и даже больше – ЧАЩЕ ВСЕГО приоритеты ИТ и пользователя услуги НЕ совпадают. Как обычное зарекомендовавшее себя решение, ключевая роль в расстановке приоритетов отдается на откуп первой линии поддержки. Решает ли это проблему разрыва в обслуживании? Да, отчасти решает. Первая линия обеспечивает единую точку контакта с пользователем и часто отстаивает его интересы.

Цели Service Desk: Обеспечить единую точку контакта для пользователей и способствовать восстановлению нормального уровня предоставления услуги с минимальными влиянием на бизнес в соответствии с согласованным уровнем услуги и бизнес-приоритетами: ITIL2, том Service Support.

ITIL предлагает в качестве инструмента для объективного указания приоритета параметры, две серебряные пули – срочность и влияние. Каким же образом в общем случае первая линия обычной квалификации может объективно точно определить срочность инцидента? Примеры реально работающих оперативных анкет по определению срочности неизвестны. Среднестатистический helpdesk слабо разбирается в бизнес-специфике большинства услуг, используемых бизнес-приложениях; если это конечно не услуги вида: «рабочее место», «печать» или «электронная почта». Заметим также, что в общем случае доскональное знание специфики услуг не есть главная задача первой линии поддержки.

Отделить инциденты высочайшего влияния на всю организацию легко. Но как быть с незначительными инцидентами, воздействующими на одного пользователя услуги или нескольких пользователей, отдел, департамент, один или несколько филиалов наконец? В момент первого инцидента об истинной степени воздействия мало что известно до начала диагностики. В таком случае специалисты первой линии поддержки должны обладать как минимум экспертными техническими знаниями и, желательно, разбираться в бизнес-специфике услуг. Хотя, безусловно, можно обойтись простым даром предвидения.

В случае применения предлагаемой ITIL схемы Приоритет = Срочность х Влияние мы получаем: системную необъективность оценок; изначально неэффективные процедуры (необъективные оценки нужно как-то корректировать и оценивать успешность такой корректировки); для нормальной работы по рекомендуемой ITIL v2,v3 схеме для приоритезации на первой линии обязательно требуются высококлассные технические эксперты (а лучше – предсказатели будущего и телепаты в промышленных объемах). Проще всего — обратится к формально или неформально утвержденному документу, который содержит требования к уровню обслуживания, т.е. соглашениях об уровне сервиса, SLA. Быстро нужно восстановить те услуги, отсутствие предоставления или некачественное предоставление коих несет более высокие убытки бизнесу. Это должно быть отражено в SLA. Нормальное предоставление услуг также должно быть определено в SLA. Ведь одним из значимых для заказчика услуги результатом является своевременное восстановление до определенного уровня обслуживания за оговоренное время.

Интуитивно понятной классификаций инцидента мгновенно становится услуга, затронутая этим инцидентом. Сообщит ли нам эту информацию пользователь? Зависит от качества проектирования каталога услуг. Вопрос выходит за рамки данной статьи, однако в грамотно спроектированном каталоге диспетчеру достаточно несложно отделить «зерна от плевел» и вычислить неработающую или работающую ниже оговоренного уровня услугу, которую и имеет ввиду пользователь при обращении. В любом случае, пользователь будет вычислен, это непосредственная работа первой линии поддержки. Что обычно сразу дает нам набор SLA, предоставляемых для пользователя данного отдела, подразделения, департамента.

Подходы к приоритезации на основе услуги

На данный момент в российской практике существует:

- Подход 1, схема назначения приоритет по связке «Услуга — Тип, Категория»;

- Подход 2, прямая классификация приоритета по услугам «Услуга – Подуслуга» (с двумя и более уровнями вложенности, зависит от конкретного каталога);

- Комбинации первых двух подходов с привлечением дополнительных аналитик.

Обе предлагаемые схемы являются объективными с точки зрения классификации инцидентов сотрудником первой линии поддержки и на практике в общем случае дают лучший результат, чем стандартная схема «срочность – влияние». В первом подходе оператор должен разбираться в имеющейся классификации типов, категорий инцидентов. Информация о типах, категориях инцидентов может храниться как в конкретных SLA, так и в виде отдельной аналитики процесса Управления Инцидентами – при отсутствии реализованного процесса Управления Уровнем Услуг. Примером такой приоритезации является Услуга «ERP Logistic», тип инцидента «Сбой». Второй подход предлагает, не меняя ключевой идеи, перенести аналитику на следующие уровни самого каталога услуг. Назначая услугу инциденту из второго или третьего уровня каталога, оператор автоматически проставляет и приоритет, уже заданный для услуги. Примером такой приоритезации будет услуга каталога «ERP\ERP Logistic\Устранение сбоя»

В рамках первого подхода чаще всего типы инцидентов принимаются одинаковыми для всех услуг. Вторая схема значительно более гибкая, однако и каталог получается более сложным, трудоемким и затратным. Кроме того, вторая схема ограничивает или сильно затрудняет возможности по сравнению аналитики инцидентов разных услуг между собой и соответственно усложняет принятие управленческих решений. Существуют и другие эффективные схемы приоритезации, основанные на услуге.Несомненно одно – концепция определения приоритета в процессе Управления инцидентами, без изменений перенесенная в ITIL v3 – давно устарела. Ее нужно приводить к механизму приоритезации, основанному на услуге и SLA.

Александр Жилинский, Виктория Шахова.

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий

Вы должны быть авторизованы, чтобы разместить комментарий.