Миф о лучшей практике. Заметки на полях ITIL v3 Жилинский Александр, itsmforum.ru 09.07.2008г
02.07.2008
Много лет назад Френсис Бэкон разработал учение об идолах – ложных предрассудках, мешающих познанию. Похоже, пора дополнить его учение мифологией "лучших практик".
Роб Инглэнд (Rob Englang), широко известный как IT Skeptic, публикует шокирующие статьи. Шаг за шагом Роб играючи и остроумно доказывает, что внедрение конфигурационной базы данных в понимании ITIL версии 2 невозможно по определению и сходу приводит десятку причин отказаться от внедрения CMDB.
По мере чтения обновленной, третьей версии ITIL также возникает ряд интересных вопросов. Представители организаций с высоким уровнем зрелости при освоении новой версии библиотеки интересуются вопросами тактического и стратегического уровня процессов – управление жизненным циклом услуги, каталогом услуг, уровнем обслуживания, доступностью услуг. И действительно, если начинать чтение с высокоуровневых книг Service Strategy, Service Design различия в структуре процессов заметны невооруженными взглядом.
А много ли нововведений внесено в базовые операционные процессы? Ключевое – разделен процесс Управление Инцидентами. И все? Внимательнее смотрим на содержание операционных процессов: часто имеет место студенческий прием copy-paste. Я вижу этому самое простое объяснение – разработчики уже подвержены мифологии "лучших практик", не замечая потребностей в изменении давно устаревших концепций и оправдываясь старой, как мир, отговоркой программистов "зачем трогать то, что и так хорошо работает".
Решения ITIL
Разберем один простой пример, касающийся базового операционного процесса управления – Управление Инцидентами. С давних пор ITIL приводит пример консервативной схемы расстановки приоритетов: Приоритет = Срочность x Влияние1 . Другими словами, величина приоритета рассчитывается по сочетанию параметров срочности и влияния инцидента.
Схема поддерживается множеством решений Service Desk. Требование обеспечить наличие атрибутов приоритет, срочность и влияние входит в список критериев Pink Verify, наиболее известного в мире методического средства для проверки, соответствует ли программное решение ITSM рекомендациям ITIL.
Схема расстановки приоритета инцидента в ITIL3 осталась совершенно неизменной по сравнению с ITIL2! А таблицу приоритезации разработчики просто скопировали и превратили из примера в рекомендуемую схему 2 .
Код приоритета определяют влияние и срочность
|
Высокое
|
Среднее
|
Низкое
|
Высокая
|
1
|
2
|
3
|
Средняя
|
2
|
3
|
4
|
Низкая
|
3
|
4
|
5
|
Код приоритета
|
Описание
|
Крайний срок исполнения
|
1
|
Критический
|
1 час
|
2
|
Высокий
|
8 часов
|
3
|
Средний
|
24 часа
|
4
|
Низкий
|
48 часов
|
5
|
Планируемый
|
В соответствие с планом
|
Рис. 1. Схема приоритезации, рекомендуемая ITIL
Участники лекций и семинаров всегда просят объяснить смысл этой схемы. Практически всех слушателей не удовлетворяют стандартные объяснения. Внимательных же слушателей, уже владеющих навыками внедрения ITSM или менеджеров "боевых" процессов – теоретические объяснения не устраивают никогда. Участники семинара всегда пытаются дополнить и доработать схему расстановки приоритетов. Каждая такая дискуссия все больше убеждала меня, что необходимо обновить схему или хотя бы дополнить ее другими возможными вариантами.
И только сейчас я понимаю, что был абсолютно неправ. Последней каплей стал недавний семинар проектирования, где слушатели быстро вынесли свой вердикт. Схема, рекомендуемая ITIL2 и ITIL3, вообще не работает и не будет работать в подавляющем большинстве организаций по причине высокого уровня необъективности, заложенной в ней изначально!
Попробуем внимательнее рассмотреть процедуру классификации и назначения приоритетов. Очевидно, что ее целью будет подача на вход последующих шагов наиболее достоверной и объективной информацию о приоритете – атрибуте, определяющем степень важности инцидентов относительно друг друга, порядок их обработки.
Приоритет — первенство, первое место по времени в открытии, изобретении, формулировке какой-н. идеи; преимущественное право на что-н.
Толковый словарь Ушакова.
|
Те из вас, дорогие читатели, кто проектировал или управлял процессами Управления Инцидентами, Управления Работами3 с множеством рабочих групп и крайним сроком исполнения, могут смело пропустить следующий раздел, не читая – в нем речь идет о возможных способах распределения инцидентов.
Распределяем инциденты
В рекомендуемой ITIL схеме значимость приоритета показана двумя способами:
- собственно в названии приоритета – "критический", "высокий", "средний".
- в значении плановом сроке устранения (target resolution time, он же крайний срок исполнения, оно же просто deadline) – 1 час, 8 часов, 24 часа.
Работу с инцидентом мы начнем с той задачи, которая имеет более высокий приоритет. Из двух задач с приоритетами Критический и Средний мы обычно выберем Критический при прочих равных условиях. Когда же могут возникать условия "неравные"? Обратимся к числовому значению приоритета, выраженному в часах и определяющему крайний срок исполнения. В случае, когда только началась работа над инцидентом с высоким приоритетом (выделен красным цветом на рис.2), к исполнителю в рабочую группу неожиданно поступает несложный инцидент с приоритетом ниже (выделен желтым цветом на рис.2).
Логично будет разрешить "желтый" инцидент, не допустив срыва сроков по нему. А уже затем завершать инцидент "красный".
Рис. 2. Случай разрешения первым инцидента с более низким приоритетом.
Неравные условия могут возникать в случаях:
- отсутствия последовательного поступления инцидентов на вход процедуры;
- переброски задач по рабочим группам, исполнителям (например, необходимость концентрации ресурсов, их перераспределения).
Конечно, в идеальном мире процессов высшего уровня зрелости доля таких ситуаций стремится к нулю, однако мы все-таки живем в реальном мире. Хорошей стоит признать практику ориентироваться при определении порядка работ по времени, оставшемуся до крайнего срока исполнения 4. Правила распределения, построенные на такой практике, универсальны – они работают когда инциденты поступают последовательно, когда инциденты поступают "вразброс" по любым причинам.
Назначаем инциденту приоритет
Пока работа с инцидентом выглядит достаточно неплохо, хоть с небольшими оговорками. Полнейшее разочарование наступает на следующем шаге! Мало иметь таблицу, схему приоритетов для инцидентов и распределять инциденты в соответствии с приоритетом. Нужно еще и уметь назначить конкретный приоритет для конкретного поступающего инцидента. Возможность назначения и изменения контрольных приоритетов собственно исполнителем по инциденту приводит к краху. Мы получаем "контроль исполняющего" и стандартную проблему классической модели предоставления услуг, разрыву в понимании качества обслуживания между исполнителем по услуге и пользователем услуги. Приоритет исполнителя не всегда совпадает с приоритетом пользователя, и даже больше – ЧАЩЕ ВСЕГО приоритеты ИТ и пользователя услуги НЕ совпадают!
Как обычное зарекомендовавшее себя решение, ключевая роль в расстановке приоритетов отдается на откуп первой линии поддержки. Решает ли это проблему разрыва в обслуживании? Да, отчасти решает. Первая линия обеспечивает единую точку контакта с пользователем и часто отстаивает его интересы.
Service Desk:
Обеспечить единую точку контакта для пользователей5;
- Способствовать восстановлению нормального уровня предоставления услуги с минимальными влиянием на бизнес в соответствии с согласованным уровнем услуги и бизнес-приоритетами.
ITIL2, том Service Support.
|
Однако обладает ли первая линия поддержки необходимой квалификацией для использования объективных критериев, для управления потоком инцидентов?
ITIL предлагает в качестве инструмента для объективного указания приоритета параметры, две серебряные пули – срочность и влияние. Каким же образом в общем случае первая линия обычной квалификации может объективно точно определить срочность инцидента? Со слов пользователя? Смех, да и только. У пользователя для всех его заявок всегда один и тот же приоритет. Точнее целый их набор: "жить не могу", "сверхсрочно" и "сделать вчера!". Применение опросных листов? Примеры реально работающих оперативных анкет по определению срочности мне неизвестны. Однако возьму на себя смелость предположить, что эффективность и результативность анкет будет невелика. Определять срочность, пользуясь дистанционным доступом, дотошно проверяя слова пользователя? Долго, дорого и не всегда помогает. Среднестатистический helpdesk слабо разбирается в бизнес-специфике большинства услуг, используемых бизнес-приложениях; если это конечно не услуги вида: "рабочее место", "печать" или "электронная почта". Заметим также, что в общем случае доскональное знание специфики услуг не есть главная задача первой линии поддержки.
С влиянием чуть проще, но примерно та же песня на новый лад. Да, легко отделить инциденты высочайшего влияния на всю организацию. "Ни одного печального сюрприза, за исключеньем пустяка". Много ли бывает значительных6инцидентов за год и стоит ли ради этого дополнять ежедневно используемую классификацию? Как быть с незначительными инцидентами, воздействующими на одного пользователя услуги или нескольких пользователей, отдел, департамент, один или несколько филиалов наконец? В момент первого инцидента об истинной степени воздействия мало что известно до начала диагностики. В таком случае специалисты первой линии поддержки должны обладать как минимум экспертными техническими знаниями и, желательно, разбираться в бизнес-специфике услуг. Хотя, безусловно, можно обойтись простым даром предвидения.
Итак, мы снова возвращаемся к необходимости "усадить" на классификацию инцидентов высококлассных экспертов. Тупик?
Есть серебряная пуля!
Итак, в случае применения предлагаемой ITIL схемы Приоритет = Срочность х Влияние мы получаем:
- системную необъективность оценок;
- изначально неэффективные процедуры (необъективные оценки нужно как-то корректировать и оценивать успешность такой корректировки);
- для нормальной работы по рекомендуемой ITIL v2,v3 схеме для приоритезации на первой линии обязательно требуются высококлассные технические эксперты (а лучше – предсказатели будущего и телепаты в промышленных объемах).
Возможно ли разрешение данной проблемы? Да! В поисках решения обратимся к первоисточнику, чуть пристальнее взглянув на цели процесса управления инцидентами.
Основная цель процесса Управления Инцидентами:
Максимально быстрое восстановление нормального предоставления услуги и минимизация отрицательного влияние на бизнес … Нормальное предоставление услуги определено в соглашении об уровне услуги (SLA).7
ITIL2, том Service Support
ITIL3, том Service Operation
|
Первоисточник дает нам в руки абсолютно четкую и недвусмысленную подсказку по реализации одной из процедур Управления Инцидентами. Более высокий приоритет должен отдаваться тем инцидентам, воздействия на услуги которых более критичны для бизнеса и должны быть исправлены в первую очередь. Стоит ли городить огород, чтобы добраться к крайнему сроку исполнения (а именно этим и является приоритет, смотри рис. 1) через эфемерные субъективные параметры срочности и влияния?
Гораздо проще сразу обратится к формально или неформально утвержденному документу, который содержит требования к уровню обслуживания, т.е. соглашениях об уровне сервиса, SLA. Быстро нужно восстановить те услуги, отсутствие предоставления или некачественное предоставление коих несет более высокие убытки бизнесу. Это должно быть отражено в SLA. Нормальное предоставление услуг также должно быть определено в SLA. Ведь одним из значимых для заказчика услуги результатом является своевременное восстановление до определенного уровня обслуживания за оговоренное время. Крайний срок исполнения – что это, как ни приоритет?
Внимательный читатель с практическим складом ума здесь сформулирует вопрос – а на каком уровне зрелости должен находиться процесс SLM, Управления Уровнем Услуг для функционирования подобных схем приоритезации. Возможность ответить, надеясь на практический подход такого читателя, я оставляю ему самостоятельно. Однако замечу, что крайне желательным элементом будет реализованный каталог услуг.
Интуитивно понятной классификаций инцидента мгновенно становится услуга, затронутая этим инцидентом. Сообщит ли нам эту информацию пользователь? Зависит от качества проектирования каталога услуг. Вопрос выходит за рамки данной статьи, однако в грамотно спроектированном каталоге диспетчеру достаточно несложно отделить "зерна от плевел" и вычислить неработающую или работающую ниже оговоренного уровня услугу, которую и имеет ввиду пользователь при обращении. В любом случае, пользователь будет вычислен, это непосредственная работа первой линии поддержки. Что обычно сразу дает нам набор SLA, предоставляемых для пользователя данного отдела, подразделения, департамента.
Я намеренно оставляю за кадром большую область инцидентов, которые не относятся к сбоям – консультации, сброс пароля, установка нового рабочего места, оповещение от системы мониторинга – т.е. запросы на обслуживание8и события9. В рамках данной статьи дать однозначную рекомендации – каким образом классифицировать вместе со сбоями все многочисленные виды событий и запросов попросту невозможно.
Подходы к приоритезации на основе услуги
На данный момент в российской практике существует:
- Подход 1, схема назначения приоритет по связке "Услуга — Тип, Категория";
- Подход 2, прямая классификация приоритета по услугам "Услуга – Подуслуга" (с двумя и более уровнями вложенности, зависит от конкретного каталога);
- Комбинации первых двух подходов с привлечением дополнительных аналитик.
Рис. 3. Схема приоритезации "Услуга – Тип "
Обе предлагаемые схемы являются объективными с точки зрения классификации инцидентов сотрудником первой линии поддержки и на практике в общем случае дают лучший результат, чем стандартная схема "срочность – влияние".
В первом подходе оператор должен разбираться в имеющейся классификации типов, категорий инцидентов. Информация о типах, категориях инцидентов может храниться как в конкретных SLA, так и в виде отдельной аналитики процесса Управления Инцидентами – при отсутствии реализованного процесса Управления Уровнем Услуг. Примером такой приоритезации является Услуга "ERP Logistic", тип инцидента "Сбой".
Второй подход предлагает, не меняя ключевой идеи, перенести аналитику на следующие уровни самого каталога услуг. Назначая услугу инциденту из второго или третьего уровня каталога, оператор автоматически проставляет и приоритет, уже заданный для услуги. Примером такой приоритезации будет услуга каталога "ERP\ERP Logistic\Устранение сбоя"
В рамках первого подхода чаще всего типы инцидентов принимаются одинаковыми для всех услуг. Вторая схема значительно более гибкая, однако и каталог получается более сложным, трудоемким и затратным. Кроме того, вторая схема ограничивает или сильно затрудняет возможности по сравнению аналитики инцидентов разных услуг между собой и соответственно усложняет принятие управленческих решений. Существуют и другие эффективные схемы приоритезации, основанные на услуге.
Несомненно одно – концепция определения приоритета в процессе Управления инцидентами, без изменений перенесенная в ITIL v3 – давно устарела. Ее нужно приводить к механизму приоритезации, основанному на услуге и SLA.
Жилинский Александр,
ИТ-консультант департамента
консалтинга и интеграции ЗАО "ИНЛАЙН ГРУП",
написать письмо
1 — или степень воздействия, в оригинале impact вернуться
2 - ITIL v2, Service Support, Annex 5B: Example of a priority coding system. ITIL v3, Service Operation, Table 4.1 Simple Priority Coding System. вернуться
3 — еще одним сюрпризом для меня является отсутствие в ITIL3 процесса Управления Работами (Workorder Management) вернуться
4 — аналогичная прямая рекомендация в ITIL не найдена вернуться
5 — в оригинале Customer; здесь в значении получатели, пользователи услуг вернуться
6 — major вернуться
7 — The primary goal of the Incident Management process is to restore normal service operation as quickly as possible and minimise the adverse impact on business operations, thus ensuring that the best possible levels of service quality and availability are maintained. 'Normal service operation' is defined here as service operation within Service Level Agreement (SLA) limits. вернуться
8 — в ITIL v3 процесс Request Fulfilment, том Service Operation вернуться
9 — в ITIL v3 процесс Event Management, том Service Operation вернуться
Возврат к списку