Как работает процессно-сервисный подход

Когда организация растёт, она почти неизбежно ломается о три системные проблемы, подтверждённые исследованиями.

1. Кросс-функциональные процессы — главный источник потерь
Классика реинжиниринга процессов: до 70–80% времени процесса может уходить не на работу, а на ожидание между подразделениями.

Что происходит на практике:
— задача «лежит» между отделами
— ответственность размыта
— каждый оптимизирует свой кусок, а не поток целиком

📉 Итог: время цикла растёт, хотя «все заняты на 116%»

Что делает процессный подход: вводит сквозные процессы с владельцем, убирает «ничейные» зоны и начинает измерять end-to-end время, а не KPI отделов

👉 То есть возвращает фокус туда, где создаётся ценность — в поток, а не в оргструктуру.

2. Локальная оптимизация ухудшает систему глобально
Это уже не просто наблюдение, а формализованная теория — теория ограничений (Eliyahu Goldratt).

Улучшение неузкого места почти не влияет на производительность всей системы:
— ускорили отдел → система не ускорилась
— загрузили людей «на 100%» → выросли очереди
— оптимизировали метрики → ухудшили результат

📉 Потому что система ограничена узким местом, а не средним уровнем эффективности

Есть сильная эмпирическая база:
— влияние WIP на lead time (закон Литтла)
— исследования очередей и вариабельности (Factory Physics, Hopp & Spearman)

Что делает процессно-сервисный подход:
— смотрит на систему целиком, а не на функции
— выявляет и управляет узкими местами
— ограничивает незавершённую работу (WIP)
— выравнивает поток, а не «ускоряет всех»

👉 В результате оптимизация начинает работать на пропускную способность системы, а не «на ощущение занятости».

3. В сложных системах сервис важнее функций
В сервисном подходе (ITSM / ITIL): ценность определяется не тем, что делает отдел,
а тем, получил ли клиент стабильный результат

Ключевые идеи, подтверждённые исследованиями сервисных систем:
— клиенту не важна внутренняя структура, важна предсказуемость, качество и доступность услуги
— вариабельность и нестабильность убивают ценность быстрее, чем «медленно, но стабильно»

📉 Функциональная модель не отвечает на вопрос:
«А услуга вообще оказывается нормально?»

Что делает сервисный подход:
— вводит понятие сервиса как единицы управления
— фиксирует SLA / OLA (ожидаемый уровень качества снаружи и внутри)
— связывает процессы с результатом для клиента
— делает качество измеримым, а не декларативным

👉 В итоге организация начинает управлять не деятельностью, а результатом для пользователя.

Разберем на примере

Функции (как было)
· Пользователь создаёт заявку об ошибке доступа к отчету
· Первая линия поддержки собирает логи и передаёт второй линии
· Вторая линия видит, что проблема в БД, и отправляет запрос администраторам БД
· Администраторы БД ждут, когда инфраструктура даст им доступ к серверу
· Заявка висит в системе две недели, а пользователь уже уволился.

Процесс + сервис

1. Есть владелец процесса
Теперь это не «задача поддержки», «задача БД» и «задача инфраструктуры» в каждом моменте.

Это один процесс:
👉 например, «управление инцидентами»

Есть ответственный, который
не передаёт задачу и забывает, а отвечает за ее решение.
Это может быть менеджер инцидентов или руководитель саппорта.

2. Управляют узким местом, а не всем подряд
Выясняется:
80% задержек — на согласовании доступа, а не в поддержке и не у БД
Что делают:
— упрощают или автоматизируют именно этот шаг
— не трогают остальное без необходимости

👉 Система ускоряется, а не «все просто бегают быстрее»

3. Есть измеримый результат (услуга)
Фиксируем в SLA требование:
👉 доступ должен восстанавливаться, например, за 2 часа

И сразу видно:
— где не укладываются
— почему
— что именно чинить

Раньше было: «заявка в работе»
Теперь: «услуга не оказывается в срок»

Разговор резко взрослеет.