Те, кто хорошо знаком с ITIL® v2 и ITIL® v3, а также большое количество ИТ-специалистов, работающих в поддержке услуг, не сомневаются в одном из важных шагов процесса управления инцидентами: приоритизация инцидента. Но открывая текст практики «Управление инцидентами» (Incident management ITIL4 Practice guide), мы обнаруживаем удивительную вещь: в описании процесса обработки и решения инцидента (Incident handling and resolution, п.3.2.1) нет ни такого шага, ни хотя бы какого-то упоминания приоритизации.

Что же это значит? Что приоритизация больше не нужна в процессе решения инцидентов, нужно срочно перестраивать все процессы в организациях и можно выбросить используемые сейчас ITSM-системы, как не советующие «лучшим практикам»? Или торопиться с резкими движениями не нужно? Давайте разбираться!

Действительно, сейчас в процессе обработки и решения инцидента за шагом классификации сразу следует шаг диагностики инцидентов, хотя раньше, например в ITIL v3, последовательность шагов была другой: категоризация – приоритизация – диагностика.

Поиски приоритизации в практике «Управление инцидентами» ITIL 4 приводят нас к факторам успеха практики – тем комплексным компонентам, которые необходимы, чтобы практика выполняла свое назначение. Напомним, что назначение практики управления инцидентами – в первую очередь минимизировать негативное влияние инцидентов. Для реализации этой задачи одним из факторов успеха является наше умение решать инциденты быстро и эффективно, и именно в описании этого фактора мы находим понятие приоритизации инцидентов.

Это закономерно. Ведь когда у нас появляется много разнообразных инцидентов, связанных с различными компонентами разных услуг, а количество наших ресурсов ограничено, нам нужно определить, в каком порядке заняться этими инцидентами, чтобы их общее негативное влияние на пользователей было минимально – это говорило бы об эффективности работы практики. А приоритизация по своему определению – это «действие по выбору задач для работы в первую очередь, когда невозможно выделить ресурсы на все задачи».

Вероятнее всего, мы действительно проведем приоритизацию инцидента после его классификации, как и было в процессе третьей версии ITIL, чтобы сразу понимать, каково негативное влияние инцидента по сравнению с другими, уже имеющимися у нас. Причем информация из классификации (на что он влияет, с какой конфигурационной единицей связан, с какой (какими) услугой (или услугами), какие у нас есть SLA по данной услуге и т.д.) поможет нам провести эту первичную приоритизацию более корректно.

В зависимости от определенного приоритета какой-нибудь из наших сотрудников раньше или позже займется диагностикой и решением этого инцидента. Но ведь реальная жизнь не статична, и в этот же момент может, например, появиться второй инцидент, устранять который по каким-либо причинам нужно быстрее. Тогда первый придется отложить – а это значит, что мы «пере-приоритизируем» имеющиеся задачи, хотя, возможно, с первым инцидентом мы уже закончили шаг диагностики и, может быть, даже приступили к его решению. Так же есть вероятность, что в дальнейшем нам понадобится снова заняться приоритизацией – повысить или понизить приоритет того же самого инцидента в зависимости от самых разнообразных причин: изменится ли его влияние, приблизится ли установленный в SLA срок восстановления услуги, изменятся ли еще какие-то обстоятельства, – чтобы заняться решением этого инцидента в оптимальное время относительно ценности для заинтересованных сторон.

И кажется, что именно это является ответом на вопрос, почему же приоритизации нет, как отдельного шага в процессе решения инцидента. Приоритизация рассматривается, как сквозной инструмент управления сразу многими инцидентами, которые одновременно находятся в разных статусах, и не всегда имеет смысл выделить ее, как отдельный шаг, который делается только один раз в процессе решения инцидента и больше не повторяется.

Так что ломать процессы и выбрасывать ITSM-системы не придется. Приоритизация инцидентов остается важной задачей в рамках управления инцидентами. При этом современные публикации ITIL позволяют посмотреть на нее шире, чем раньше, и использовать, как инструмент управления работой в любой момент решения инцидента, а не только на определенном шаге.

ITIL4 предлагает новые интересные взгляды и подходы к приоритизации, и они появляются не только в тексте практики «Управление инцидентами», но и в других практиках, в книге «Create, Deliver, Support», мы в Cleverics рассказываем об этом на курсе “VAP: Управление поддержкой ИТ-услуг”, ведь вопросы управления очередностью выполнения задач касаются не только инцидентов, но и любой другой нашей рабочей деятельности, связанной с ИТ-услугами. И, кстати, было бы здорово иметь единую схему приоритизации разных объектов, чтобы при присущей многим организациям ограниченности в ресурсах, когда одни и те же сотрудники занимаются разной деятельностью и выполняют задачи разных типов, можно было бы наиболее оптимально принимать решение, какими из них заниматься в первую очередь.