Процессы ломаются на стыках: почему каждый отдел прав, а клиент ждёт три недели

Типичная картина согласования договора. Каждый отдел отчитывается об успехе: продажи обрабатывают заявки за день, юристы проверяют за два, финансы согласовывают за один. Сумма - четыре дня. А клиент ждёт договор три недели. Где остальные семнадцать дней? На стыках: заявка лежит между отделами, ждёт переноса из системы в систему, возвращается из-за неполных данных (а каждый возврат бьёт дважды - снова очередь и снова работа), потому что каждый отдел понимает «комплект документов» по-своему.

В системной инженерии это называется проблемой интерфейсов. Хендбук NASA называет определение и контроль интерфейсов критичными для успеха проекта - и держит под них отдельный процесс и отдельный документ, ICD, под которым подписываются обе стороны стыка. Цена вопроса известна: Mars Climate Orbiter в 1999 году сгорел в атмосфере Марса, потому что одна команда считала импульс в фунтах силы, а другая ждала ньютоны, - контракт стыка существовал на бумаге, но проверить его до полёта никто не удосужился. Это шестая статья серии «Процессы по-инженерному».

Интерфейс - это контракт, а не стрелка на схеме

Хендбук предлагает думать об интерфейсах как о контрактах. Обе стороны явно договорились, что именно передаётся через границу - формат, состав, сроки, качество. Для железа это разъёмы и протоколы. Для процессов - хендовер, момент, когда заявка переходит из рук в руки (дальше будем звать его по-русски стыком).

Контракт стыка отвечает на четыре вопроса:

• что именно передаётся - состав данных и документов;
• в каком виде - система, форма, поля;
• в какой срок;
• по какому критерию принимающая сторона имеет право вернуть.

Без четвёртого пункта стык превращается в пинг-понг: принимающий возвращает по любому поводу, передающий считает это придирками, и спор не решается ничем, кроме громкости.

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

Почему время живёт именно на стыках

Стык - это всегда очередь: заявка вышла из одного отдела и ждёт, когда её возьмёт следующий. При этом внутренние метрики отделов это время не видят: оно ничьё. Продажи уже отчитались, юристы ещё не начали. Именно поэтому оптимизация внутри отделов так часто не даёт ничего клиенту: ускорили работу, которая занимала четыре дня из двадцати одного. Сквозное время живёт в остальных семнадцати - в очередях на стыках и циклах возвратов между отделами. Мерить его просто: штамп «отдел отдал» минус штамп «следующий взял в работу», две метки, которые есть почти в любой системе.

Отсюда инженерное правило: проверяйте интерфейсы до сборки, а не после. В процессном переводе - прежде чем запускать сквозной процесс, прогоните через каждый стык тестовую заявку и посмотрите, что реально передаётся, какие поля теряются и где одни и те же данные вводят руками дважды. И ещё одно правило из того же раздела хендбука: любое изменение интерфейса согласуют обе стороны - до внедрения, а не постфактум.

Стыки в симуляции: что чинить первым

Если время живёт на стыках, то и самые дешёвые улучшения - там же. Убрать один цикл возврата между отделами часто даёт больше, чем ускорить саму работу вдвое. Проверяется это в симуляторе без риска: сценарий «принимаем только полные комплекты, доля возвратов падает, скажем, с 20% до 5%» против сценария «нанимаем ещё одного юриста» - и видно, где выгода больше. Механика подсказывает, чего ждать: новый юрист срезает часы работы, а починенный стык убирает дни ожидания. Хотя бывает и наоборот - стыки чистые, а узкое место в ёмкости отдела; симулятор покажет и этот случай.

Чек-лист

1. На схеме сквозного процесса обведите все места смены исполнителя - это ваша карта стыков.
2. Для каждого стыка проверьте наличие контракта: что, в каком виде, в какой срок, критерий возврата.
3. Замерьте время на стыках отдельно от времени работы. Если стыки съедают больше половины цикла - начинайте с них, а не с отделов.
4. При любом изменении процесса проверяйте, кого из соседей по стыкам оно задевает - и сообщайте им до внедрения.
5. Гипотезы «починить стык или добавить людей» сравнивайте сценариями в симуляторе.

Серия «Процессы по-инженерному» основана на NASA Systems Engineering Handbook (SP-2016-6105) и начинается со статьи о том, почему ошибка в проекте в сто раз дешевле ошибки после запуска. Предыдущая статья - про правки без контроля. Финальная - про то, как NASA выбирает из нескольких вариантов конструкции: трейд-стади для процессных решений.