Казалось бы, процесс управления инцидентами описан уже давно, в частности в ITIL он был формализован уже со второй версии в 2000 году. Многие организации годами его выстраивают, дорабатывают, автоматизируют.
А потом в публикациях ITIL4 с 2019 года появилось понятие потока создания ценности, и в качестве одного их типовых потоков был рассмотрен поток восстановления услуги. С тех пор, хотя прошло уже семь лет и уже начал публиковаться ITIL (version 5), у ряда слушателей, приходящих к нам на курсы, возникает закономерный вопрос: а это что-то новое или просто другое название уже известного процесса по решению инцидентов? Ведь у потока и у процесса очень похожи шаги, зачем вводить два разных понятия?
В чем сходство?
Если без деталей описать или нарисовать процесс управления инцидентами (кстати, в актуальных материалах ITIL его корректное название «Процесс обработки и разрешения инцидента», но у русскоговорящей аудитории больше прижилось прежнее название) и поток восстановления услуги, различия, действительно, не сразу бросаются в глаза. И там, и там мы увидим примерно одну и ту же последовательность: мы узнаём об инциденте, фиксируем его, разбираемся в причине, находим решение, реализуем это решение, закрываем работу. На этом месте обычно и возникает ощущение, что речь идёт об одном и том же, просто разными словами.
Но давайте посмотрим на это чуть с другой стороны.
Представьте: инцидент устранён, переведен в статус «закрыт», необходимые нормативы соблюдены. Можно ли на этом остановиться и сказать, что задача решена? Не всегда. Ведь с точки зрения ИТ, как инструмента, помогающего бизнесу, нас интересует не сам факт выполнения действий, а то, может ли пользователь снова выполнять свои задачи – получать ценность от потребления услуги.
В чём разница?
Процесс управления инцидентами – это способ описать, как именно мы выполняем работу. В какой последовательности, кто что делает, какие правила соблюдаются. Мы описываем некоторую деятельность, как процесс, чтобы увеличить её управляемость, а также вероятность достижения успеха при повторении.
А поток – это про создание ценности, и рассматривая восстановление услуги, мы интересуемся тем, как эта ценность создается. Мы задумываемся о том, что должно произойти, чтобы услуга снова начала приносить ценность. Если попробовать описать поток, мы увидим вроде те же шаги, но смысл у них будет другой: не «мы выполнили действие», а «достигнуто нужное состояние»: информация получена, зафиксирована, решение найдено, внедрено, пользователь действительно может работать. То есть поток описывает, какие промежуточные точки обязательно пройти, чтобы ценность создалась. Без прохождения этих точек ценности не будет.
Получается, в случае потока мы управляем другими вопросами, чем в процессе. Мы управляем вопросами: а то, что мы делаем – оно действительно нужно (или нет), чтобы пользователь снова получал ценность от услуги, не упускаем ли мы чего-то важного, что создаст еще больше ценности, не тратим ли мы свой ресурс на то, что ценность не создает.
Итак, зачем вводить два разных понятия?
Когда мы начинаем смотреть на деятельность организации через призму содействия потребителю в создании результата и ценности, процесса нам недостаточно. Процесс отвечает только на вопрос, что мы делаем, а поток заставляет задуматься о смысле нашей деятельности – зачем мы это делаем.
Кроме того, размышляя в категории «что должно быть сделано», мы явно видим, что одной практики управления инцидентами недостаточно.
Чтобы услуга была восстановлена так, чтобы это было ценно потребителю, нужно вовремя узнать об инциденте, нужно корректно выстроить коммуникацию, учитывая удобство и привычки пользователей. Иногда для восстановления нужно реализовать стандартное или нормально, а может даже экстренное изменение. Так же нужно понимать, какие компоненты затронуты.
Для решения этих задач нужны другие практики (мониторинг и управление событиями, сервис-деск, поддержка изменений и прочие), процессы которых должны тем или иным образом быть скоординированными с процессом управления инцидентами.
И как раз-таки поток помогает нам, во-первых, увидеть картинку целиком (понять, какие практики для достижения какого промежуточного результата должны быть задействованы), а во-вторых, задуматься о том, как организовать это взаимодействие практик. Например, предусмотреть в процессе решения инцидента процедуру, чтобы инициировать изменение, если оно необходимо.
И именно поэтому его выделяют отдельно — он помогает не терять из виду общий результат.
А процесс, в свою очередь, остаётся важным, но решает более локальную задачу — делает конкретную деятельность управляемой и воспроизводимой.
Два разных объекта управления
Отсюда и ответ на исходный вопрос.
Процесс управления инцидентом и поток восстановления услуги не одно и то же, и не взаимозаменяемые вещи. Процесс управления инцидентами – это описание того, как мы работаем. Поток восстановления услуги – описание, как мы создаем ценность.
И в реальной практике имеет смысл управлять и тем, и другим. Если фокус только на процессе, есть риск «идеально» выполнять регламент, но при этом не создавать (или недостаточно создавать) ценность для потребителя (а значит, мы рискуем его потерять). Если пытаться работать, задумываясь только о потоке, без процессов, деятельность становится трудно управляемой.
