Оценка содержания операционных процессов в третьей версии ITIL показывает, что часть из них была перенесена из второй версии в третью путем простого копирования
Разработчики третьей версии ITIL уделили много внимания обновлению структуры тактических процессов — это становится очевидным после прочтения книг Service Strategy и Service Design. Однако инновации не затронули базовые операционные процессы. Разработчики находятся под влиянием прошлого опыта и не замечают, что назрела необходимость изменить давно устаревшие концепции. «Зачем трогать то, что и так хорошо работает?» — оправдываются они.
Рассмотрим, например, базовый операционной процесс управления — управление инцидентами. В ITIL 2 приведен вариант консервативной схемы расстановки приоритетов, определяемых на осрове срочности разрешения инцидентов и их влияния на бизнес. Другими словами, величина приоритета рассчитывается по сочетанию значений параметров срочности разрешения и силы влияния (или степени воздействия) инцидента.
Схема поддерживается множеством решений Service Desk. Требование обеспечить атрибуты «приоритет», «срочность» и «влияние» входит в список критериев Pink Verify, наиболее известного в мире методического средства для проверки соответствия программного решения ITSM рекомендациям ITIL.
Схема расстановки приоритета инцидента в ITIL 3 осталась совершенно неизменной. А таблицу приоритизации разработчики просто скопировали и превратили из примера в рекомендуемую схему (см. таблицы).
Слушатели лекций и участники семинаров проектирования всегда просят объяснить смысл этой схемы. Практически никого не удовлетворяют стандартные объяснения. Внимательных же слушателей, уже владеющих навыками внедрения ITSM, или опытных менеджеров процессов теоретические объяснения не устраивают никогда. Участники семинара всегда пытаются дополнить и доработать схему расстановки приоритетов. Каждая такая дискуссия все больше убеждала, что необходимо обновить схему или хотя бы дополнить ее другими вариантами.
Однако со временем стало понятно, что не правы были все. На недавнем семинаре по проектированию был вынесен вердикт: схема, рекомендуемая ITIL версий 2 и 3, вообще не работает и не будет работать в подавляющем большинстве организаций по причине высокого уровня необъективности, заложенной в ней изначально!
Распределяем инциденты
Рассмотрим внимательнее процедуру классификации и назначения приоритетов. В рекомендуемой ITIL схеме значимость приоритета показана собственно в описании приоритета («критический», «высокий», «средний») и в значении планового срока устранения — 1 час, 8 часов, 24 часа. При прочих равных условиях работу с инцидентом мы начнем с той задачи, которая имеет более высокий приоритет. Из двух задач с приоритетами «критический» и «средний» мы выберем «критический».
Обратимся теперь к значению приоритета, выраженному в часах и определяющему крайний срок исполнения. Рассмотрим ситуацию, когда сразу после начала работы над инцидентом с высоким приоритетом (красный) к исполнителю в рабочую группу неожиданно поступает несложный инцидент с приоритетом ниже (желтый), но более близким крайним сроком исполнения. Логично будет разрешить «желтый» инцидент, не допустив срыва сроков по нему. А уже затем завершать инцидент «красный».
Неравные условия могут возникать в случаях отсутствия последовательного поступления инцидентов на вход процедуры их разрешения и перераспределения задач по рабочим группам, исполнителям (например, при необходимости концентрации ресурсов, их перераспределения).
Конечно, в идеальном мире процессов высшего уровня зрелости доля таких ситуаций стремится к нулю, однако мы живем в реальном мире. Хорошей стоит признать практику ориентироваться при определении порядка работ на время, оставшееся до крайнего срока исполнения (аналогичная прямая рекомендация в ITIL не найдена). Правила распределения, построенные на такой практике, подойдут как для случая, когда инциденты поступают последовательно, так и для случаев, когда инциденты поступают «вразброс» по любым причинам.
Назначаем инциденту приоритет
Мало иметь таблицу, схему приоритетов для инцидентов и распределять инциденты в соответствии с приоритетом. Нужно еще и уметь назначить конкретный приоритет для конкретного поступающего инцидента. Назначение и изменение контрольных приоритетов исполнителем приводит к краху, так как получим «контроль исполняющего» и стандартную проблему классической модели предоставления услуг, разрыв в понимании качества обслуживания исполнителем услуги и пользователем услуги. Приоритет исполнителя не всегда совпадает с приоритетом пользователя, более того, приоритеты ИТ-специалистов и пользователя услуги чаще всего не совпадают!
Как правило, ключевую роль в расстановке приоритетов играет первая линия поддержки. Отчасти это решает проблему разрыва в обслуживании. Первая линия обеспечивает единую точку контакта с пользователем и часто отстаивает его интересы.
Однако обладает ли первая линия поддержки необходимой квалификацией для использования объективных критериев, для управления потоком инцидентов?
В качестве инструмента объективного указания приоритета ITIL предлагает параметры «две серебряные пули» — срочность и влияние.
Каким же образом в общем случае первая линия обычной квалификации может объективно точно определить срочность инцидента? Со слов пользователя это сделать невозможно, так как у него для всех заявок всегда один и тот же набор приоритетов: «жить не могу», «сверхсрочно», «сделать вчера». Примеры применения опросных листов, оперативных анкет по определению срочности автору не известны. Однако возьму на себя смелость предположить, что эффективность и результативность анкет будет невелика. Определять срочность, пользуясь дистанционным доступом, дотошно проверяя слова пользователя, долго, дорого и не всегда помогает. Среднестатистический helpdesk слабо разбирается в бизнес-специфике большинства услуг, используемых бизнес-приложениях, если это, конечно, не услуги вида: «рабочее место», «печать» или «электронная почта». Замечу также, что в общем случае доскональное знание специфики услуг не есть главная задача первой линии поддержки.
Оценить влияние несколько проще — легко определить инциденты, влияющие на всю организацию. Но много ли бывает значительных инцидентов за год и стоит ли ради этого дополнять ежедневно используемую классификацию? Как быть с незначительными инцидентами, воздействующими на одного пользователя услуги или нескольких пользователей, отдел, департамент, один или несколько филиалов, наконец? В момент первого инцидента об истинной степени влияния мало известно до начала диагностики. В таком случае специалисты первой линии поддержки должны обладать как минимум экспертными техническими знаниями и, желательно, разбираться в бизнес-специфике услуг. Хотя, безусловно, можно попытаться обойтись простым даром предвидения.
Таким образом, мы снова возвращаемся к необходимости использовать для классификации инцидентов высококлассных экспертов, что неэффективно.
Есть серебряная пуля!
Итак, в случае применения предлагаемой ITIL схемы расстановки приоритетов мы получаем системную необъективность оценок и изначально неэффективные процедуры (необъективные оценки нужно как-то корректировать и оценивать успешность такой корректировки) Кроме того, для нормальной работы по рекомендуемой ITIL версий 2,3 схеме для приоритизации на первой линии обязательно требуются высококлассные технические эксперты (а лучше — предсказатели будущего и телепаты в промышленных количествах).
Однако решение у данной проблемы существует. Обратимся к первоисточнику и чуть пристальнее взглянем на цели процесса управления инцидентами.
Первоисточник дает нам в руки абсолютно четкую и недвусмысленную подсказку по реализации одной из процедур управления инцидентами. Более высокий приоритет должен отдаваться тем инцидентам, воздействие которых на услуги более критично для бизнеса и, следовательно, они должны быть исправлены в первую очередь.
Необходимо сразу обратиться к формально или неформально утвержденному документу, который содержит требования к уровню обслуживания, то есть соглашению об уровне обслуживания (Service Level Agreement, SLA). Быстро нужно восстановить те услуги, отсутствие или некачественное предоставление которых несет более высокие убытки бизнесу, что должно быть отражено в SLA. Нормальное предоставление услуг также должно быть определено в SLA. Ведь одним из значимых для заказчика результатов является своевременное восстановление до определенного уровня обслуживания за оговоренное время.
Крайне желательным элементом для работоспособности этой схемы будет реализованный каталог услуг. В грамотно спроектированном каталоге услуг диспетчеру несложно определить неработающую или работающую ниже оговоренного уровня услугу, которую и имеет в виду пользователь при обращении. В любом случае пользователь будет идентифицирован первой линией поддержки, что сразу позволит определить набор SLA с пользователями данного подразделения.
Здесь мы не рассматриваем большую область инцидентов, которые не относятся к сбоям — консультации, сброс пароля, установка нового рабочего места, оповещение от системы мониторинга, — то есть запросы на обслуживание и события. Дать однозначные рекомендации о том, как классифицировать вместе со сбоями все многочисленные виды событий и запросов, попросту невозможно.
Приоритизация на основе услуг
На данный момент в российской практике существуют два подхода к приоритизации: схема назначения приоритета по связке «услуга — тип, категория» и прямая классификация по услугам «услуга — подуслуга» (с двумя и более уровнями вложенности, что зависит от конкретного каталога).
Возможны также комбинации первых двух подходов с привлечением дополнительных аналитик.
Обе предлагаемые схемы объективны с точки зрения классификации инцидентов сотрудником первой линии поддержки и на практике, как правило, дают лучший результат, чем стандартная схема «срочность — влияние».
При первом подходе оператор должен разбираться в имеющейся классификации типов, категорий инцидентов, информация о которых может храниться как в конкретных SLA, так и в виде отдельной аналитики процесса управления инцидентами (при отсутствии реализованного процесса управления уровнем услуг). Примером такой приоритизации является услуга «ERP логистика», тип инцидента «сбой» (см. рисунок.).
Второй подход предлагает, не меняя ключевой идеи, перенести аналитику на следующие уровни самого каталога услуг. Назначая инциденту услугу из второго или третьего уровня каталога, оператор автоматически проставляет и приоритет, уже заданный для услуги. Примером такой приоритизации будет услуга каталога «ERPERP логистикаустранение сбоя».
В рамках первого подхода чаще всего типы инцидентов принимаются одинаковыми для всех услуг. Вторая схема значительно более гибкая, однако каталог получается более сложным, трудоемким и затратным. Кроме того, вторая схема ограничивает или сильно затрудняет возможности по сравнению аналитики инцидентов разных услуг между собой и усложняет принятие управленческих решений. Существуют и другие эффективные схемы приоритизации, основанные на услуге.
Несомненно одно: концепция определения приоритета в процессе управления инцидентами, без изменений перенесенная в ITIL 3, давно устарела. Ее нужно приводить к механизму приоритизации, основанному на услуге и SLA.
Александр Жилинский — ИТ-консультант департамента консалтинга и интеграции компании «Инлайн Груп», alexander.zhilinsky@inlinegroup.ru