Мой читатель задал мне вопрос: «Как вы применяете ITIL?». Я честно ответила: в критических информационных системах и процессах — не так, как описано в учебнике.

Не потому, что я не знаю ITIL. А потому, что ITIL имеет допущение, которое в критических ИС и процессах не работает.

Допущение ITIL, которое ломается. ITIL — это функциональная парадигма. Она предполагает, что систему можно разбить на функции, например: · Service Desk — принимает заявки. · Incident Management — восстанавливает сервис. · Problem Management — ищет корневые причины. · Change Management — управляет изменениями. · Compliance / Legal — отвечает за юридические риски.

Логика простая: у каждой функции — своя зона ответственности, свой KPI, свой SLA.

Это работает в стандартизированных сервисах — телеком, аутсорсинг, госуслуги с однотипными задачами.

Но ITIL имеет важное допущение: проблема должна находиться внутри одной функции: · Инцидент — в эксплуатации. · Изменение — в Change Management. · Юридический риск — в Compliance.

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

Где именно ломается.

Пример 1. СЭД Правительства региона. 20 000 пользователей, 3000 юрлиц. Пользователь по адресу X не может загрузить PDF. Service Desk принимает заявку. Incident Management восстанавливает сервис — «перезагрузите устройство, выйдите из СЭД и снова зайдите, повторите операцию заново». Через неделю...месяц...год те же заявки. Что произошло на самом деле: потеря пакетов на конкретном узле физ сети. Service Desk видел симптом, но не понимал причину. Сетевики не знали, какие симптомы у пользователя даёт та или иная инфраструктурная проблема. Никто не видел стыка.

Пример 3. Миграция СЭД в новую сеть. Нужно перевести систему на новые мощности, импортозаместить ОС, перестроить физические и виртуальные серверы. Без простоя. 10 000 пользователей работают, пока инфраструктура меняется. По ITIL — это Change Management с тестированием в тестовой среде. Только тестовая среда не воспроизведёт 3000 локальных сетей, разные версии ViPNet, разные настройки маршрутизации. Тестировать надо на реальных пользователях.

Классический ITIL здесь не работает. Не потому, что он «плохой». А потому, что он не для этих условий.

Что работает вместо этого.

В науке об управлении есть другая парадигма.

Она называется по-разному: · Process Owner (BPM, Hammer & Champy, 1990-е) — владелец сквозного процесса, который видит его целиком и имеет полномочия через функции. · Systems Thinking (Senge, Meadows) — система — не набор частей, а связи между ними. Разделить систему — убить связи. · High Reliability Organizations (Weick & Sutcliffe) — в критических системах нельзя управлять через жёсткое разделение функций. · Socio-technical Systems (Trist & Emery, 1960-е) — нельзя разделять техническую и социальную подсистему. · DevOps — нельзя отделять разработку от эксплуатации. · SRE (Google) — нельзя отделять поддержку от разработки и эксплуатации.

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

Это именно та модель управления, о которой я пишу и которую применяю.

Как это выглядит на практике описала в статье, которая сюда не входит, даю ссылку на TenChat https://tenchat.ru/media/6176143-pochemu-itil-ne-rabotayet-v-kriticheskikh-informatsionnykh-sistemakh

#ITIL #CDTO #CIO #критическиеИС #КИИ #ЭДО #СЭД #SystemsThinking #ProcessOwner #HRO #DevOps #SRE #управлениеИТ #экспертизаБорисовской