Ошибка в проекте в сто раз дешевле ошибки после запуска: правило NASA для тех, кто меняет процессы

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

Есть индустрия, которая так работать не может физически. У марсианского зонда не бывает второй попытки: пропустил окно запуска - жди два года, ошибся в конструкции - потерял миссию. Поэтому NASA с 1958 года оттачивает дисциплину под названием «системная инженерия» и собрала её в NASA Systems Engineering Handbook - открытый справочник, по которому агентство учит проектировать всё, от марсоходов до наземных служб. Мы прочитали его глазами процессного аналитика - и это первая статья серии о том, что оттуда стоит забрать людям, которые проектируют не ракеты, а бизнес-процессы.

Две цифры, которые меняют взгляд на проектирование

Две цифры задают всю экономику этой дисциплины.

Первая - из главы хендбука об экономике жизненного цикла: к моменту, когда потрачено лишь около 15% затрат, проектные решения уже зафиксировали около 75% стоимости всего жизненного цикла. Деньги ещё не потрачены, но уже предопределены: выбранная конструкция диктует, сколько будет стоить эксплуатация, поддержка и исправление ошибок на годы вперёд. У процессов то же самое: когда вы решили, что заявки идут через три инстанции, а проверку делает один отдел, вы уже определили будущие очереди, штат и жалобы - даже если до запуска ещё квартал.

Вторая - из исследования NASA о цене ошибок: та же ошибка, пойманная в эксплуатации, обходится в десятки, а в худших случаях в сотни и тысячи раз дороже пойманной на этапе проектирования - для поздних фаз исследование даёт разброс от 29 до 1500 раз. Не на проценты - на порядки. Ошибка на бумаге стоит условный час работы аналитика. Та же ошибка после внедрения - это переучивание людей, переписывание интеграций, расчистка накопившейся очереди, компенсации клиентам и подорванное доверие к следующему изменению.

Дилемма системного инженера

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

Почему процессы внедряют «на живую», а ракеты - нет

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

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

Что именно переносится из NASA в процессы

Системная инженерия - это не про ракеты. Это про то, как управлять сложной системой из людей, техники и правил, когда цена ошибки высока. Бизнес-процесс - ровно такая система. Вот карта серии, которая из этого следует:

• «Построили правильно» и «построили правильное» - два разных вопроса к любому внедрению, и проваливают обычно второй.
• Регламент как требования - пять проверок, после которых пункт регламента либо работает, либо вылетает.
• Схема только счастливого пути - почему NASA требует описывать нештатные сценарии до проектирования и что это значит для BPMN.
• Правки без контроля - чему аварии NASA из-за исчерканных процедур учат владельцев регламентов в Word.
• Процессы ломаются на стыках - управление стыками: почему каждый отдел прав, а вместе не работает.
• Как NASA выбирает из трёх вариантов - трейд-стади, сравнение вариантов по заранее зафиксированным критериям: решения, за которые не стыдно через год.

С чего начать уже сейчас

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

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