Анализ процесса

Записаться

Процесс управления инцидентами: неявные допущения

Процесс управления инцидентами в ITIL (IT Infrastructure Library) выглядит нейтрально, но опирается на неявные допущения. Они возникли из практики 1990-х, когда основные ресурсы были аппаратными: компьютеры, диски, мыши, дискеты, терминалы, клавиатуры. Такие ресурсы часто ломались и требовали ремонта. Тогда не было понимания бизнес-процессов, их целей и услуг. В модели ITIL из всех заказчиков присутствуют только пользователи (users). Организация рассматривалась как коллектив пользователей, потребляющих стандартные, примерно одинаковые услуги.

Допущение 1: массовость инцидентов

Предполагается, что инцидентов (incidents) много. В большой организации, где каждый работает с множеством аппаратных средств, что-то постоянно ломается. Поэтому управление инцидентами строится как конвейер: общий поток распределяется по типам и группам специалистов, обработка распараллеливается, суммарное время сокращается.

Важнее среднее время разрешения, а не скорость каждого отдельного инцидента. Линии поддержки (support lines) должны быть равномерно загружены. Их планируют так, чтобы не было перегруженных и простаивающих линий. Пример: инфраструктура, программное обеспечение, внешние поставщики. Можно делить линии по группам приложений.

Допущение 2: схожесть структуры инцидентов

В группах поддержки работают одни и те же специалисты, а не новая команда под каждый инцидент. Это возможно, если инциденты похожи по структуре. Это значит, что их устраняют в одном и том же порядке.

Пример — горизонтальные эскалации (horizontal escalations) вдоль линий поддержки. Сначала проверяют простые причины: включен ли прибор, горит ли лампочка, есть ли питание. Затем следующая линия снимает кожух, проверяет узлы, определяет неработающий узел. Если узел найден, его заменяют или передают дальше для более тонкой диагностики и ремонта.

Такая последовательность отражает одинаковую структуру технических объектов. Она возникла потому, что первые реализации были ориентированы на оборудование.

Допущение 3: синхронность производства

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

Границы применимости

Все три допущения — лишь приближение. Можно привести правдоподобные контрпримеры. Но ITIL распространена потому, что в среднем ситуация соответствует этим допущениям. Отклонения, непредсказуемые инциденты и задержки находятся за пределами нормального распределения.

Опыт многих организаций, использующих ITIL без научных исследований и моделирования, показывает: с моделью удобно и разумно работать. Это подтверждает жизнеспособность референтной модели (reference model).

Краткие итоги

Логика изложения строится от исторической обусловленности к скрытым предпосылкам, затем к организационным следствиям и границам применимости. Сначала объясняется, почему процесс управления инцидентами не является универсальной абстракцией: его конструкция сформирована средой, где преобладали аппаратные отказы, а организация воспринималась как множество пользователей со стандартными запросами. Это позволяет увидеть, что конвейерная обработка, линии поддержки и распределение потока — не случайные элементы, а способ оптимизировать массовый поток при ограниченной возможности ускорить каждый отдельный случай.

Практический смысл такого анализа в том, что внедрение процесса требует проверки: действительно ли инциденты массовы, повторяемы и однородны, достаточно ли стабильна статистика, можно ли сбалансировать ресурсы. Если условия не выполняются, модель не исчезает, но требует адаптации: пересмотра маршрутов, приоритетов, состава групп, способов эскалации. Далее логика переходит к специализации групп. Одинаковые специалисты и повторяемые последовательности действий дают эффект только при структурной похожести инцидентов. Значит, на практике важно не просто создать несколько линий, а проверить, какие классы работ действительно повторяются, где возможна стандартизация, а где нужна экспертиза.

Горизонтальные эскалации показывают, как порядок действий отражает устройство технического объекта; в нетехнических и слабо формализуемых областях такая логика может давать сбой. Завершающий уровень анализа — синхронность. Он связывает организационную схему с пропускной способностью, очередью и вариабельностью. Практический вывод: даже при хорошем регламенте нужны мониторинг отклонений, анализ узких мест и периодическая переоценка допущений. Средние показатели могут скрывать выбросы, а стабильная статистика — меняться. Ценность модели не в абсолютной точности, а в том, что она дает рабочую рамку для типовых условий и позволяет осознанно корректировать ее там, где реальность отходит от исходных предпосылок.