Совещание по «цифровой трансформации» почти всегда начинается одинаково. Кто-то показывает слайд с новой технологией: «Нам нужен ИИ». «Давайте внедрим RPA». «Пора автоматизировать согласования». Обсуждение сразу уходит в выбор платформы, бюджет и сроки пилота. И только потом — если повезёт — кто-нибудь задаёт неудобный вопрос: а зачем этот процесс вообще существует именно в таком виде? Какой результат мы пытаемся изменить?
Порядок перепутан: решение появилось раньше проблемы. Это главный механизм, из-за которого проекты трансформации не дают эффекта. Зрелая последовательность устроена иначе: сначала результат, потом диагностика, потом конструкция и её проверка, потом технология — и в конце закрепление. Мы не будем объявлять этот порядок правильным. Мы будем его доказывать: исследованиями, первоисточниками и кейсами, у каждой цифры в этой статье есть ссылка.
Раздатка «Process transformation should follow a logic», которая разошлась по LinkedIn. Внизу указаны источники: Hammer (1990), McKinsey (2023), Lean Enterprise Institute, Toyota. Мы проверили каждый.
Поводом стала раздатка выше: 12 вопросов, которые надо задать до внедрения технологии, и воронка «стратегия определяет результат → анализ находит проблему → дизайн определяет решение → технология делает его возможным». Мы отнеслись к ней не как к готовому ответу, а как к гипотезе: подняли указанные первоисточники и проверили каждый крупный тезис. Забегая вперёд: модель в целом честная, но в ней не хватает одного критичного слоя — до него дойдём.
Идея «не автоматизируйте хаос» не родилась вместе с ChatGPT. Ей минимум 35 лет, и появилась она из вполне измеримой боли.
К концу 1980-х американские корпорации десятилетие вкладывались в компьютеры — а статистика производительности этого не видела. Экономист Роберт Солоу сформулировал наблюдение, которое потом назовут парадоксом Солоу: «Компьютерный век виден повсюду, кроме статистики производительности» (New York Times Book Review, 12 июля 1987). Эрик Бринолфссон в обзоре «The Productivity Paradox of Information Technology» (1993) разобрал четыре возможных объяснения: ошибки измерения, лаги обучения, перераспределение прибыли между фирмами вместо её создания — и системное неумение управлять IT.
На этом фоне в Harvard Business Review выходит статья Майкла Хаммера «Reengineering Work: Don't Automate, Obliterate» (1990) — точка отсчёта всей истории реинжиниринга. Диагноз Хаммера: крупные инвестиции в IT дают разочаровывающие результаты, потому что компании «оставляют существующие процессы нетронутыми и используют компьютеры, чтобы просто ускорить их». И дальше: «Пора перестать мостить коровьи тропы. Вместо того чтобы заливать устаревшие процессы в кремний и софт, мы должны уничтожить их и начать заново».
«Don't automate, obliterate» часто читают как призыв ломать всё подряд. У Хаммера смысл другой: отказаться принимать исторически сложившийся процесс как данность. Его позитивная программа — «использовать мощь современных информационных технологий, чтобы радикально перепроектировать бизнес-процессы»: не автоматизировать существующий процесс, а сделать возможным новый. Хаммер не воевал с технологией. Он воевал с автоматизацией того, что не должно существовать.
Доказывал он это кейсами.
Ford, кредиторская задолженность. В отделе оплаты счетов Ford в Северной Америке работало более 500 человек. План менеджмента был классическим: автоматизировать существующий процесс и сократить численность на 20%. Планка казалась амбициозной, пока Ford не посмотрел на Mazda, где ту же функцию выполняли пять человек. Разница даже с поправкой на масштаб была такой, что «ускорять существующее» потеряло смысл. Ford изменил само правило работы: вместо «платим, когда получили счёт» — «платим, когда получили товар». Сверка документов сократилась с 14 позиций до трёх, счёт-фактура исчез из процесса как класс документов, а численность в итоге снизилась на 75% — не на запланированные при автоматизации 20%.
Mutual Benefit Life, андеррайтинг страховых заявок. Заявка проходила до 30 шагов через 5 отделов и 19 человек. Лучший случай — 24 часа, типичный срок — от 5 до 25 дней. У другого страховщика, пишет Хаммер, посчитали точнее: заявка провела в процессе 22 дня, а реальной работы над ней было 17 минут. Всё остальное время она лежала в очередях между исполнителями. MBL заменила конвейер специалистов одной ролью кейс-менеджера с полной ответственностью за заявку от приёма до выпуска полиса, дав ему экспертную систему и доступ к данным. Результат: типичный срок — 2–5 дней, минимальный — 4 часа.
IBM Credit — кейс из книги Хаммера и Чампи «Reengineering the Corporation» (1993): оформление финансирования занимало в среднем 6 дней, иногда до двух недель, при этом чистой работы в процессе было около 90 минут. После замены цепочки специалистов на универсальную роль deal structurer со специализированной системой поддержки срок упал до 4 часов, а пропускная способность выросла на порядки — без роста численности.
Общий знаменатель трёх кейсов: эффект дал не софт, а изменение устройства процесса — правила оплаты, схемы ответственности, маршрута заявки. Технология сделала новое устройство возможным, но источником эффекта была конструкция. Пропорция «17 минут на 22 дня» объясняет, почему так: когда 99% времени заявка лежит в очереди, ускорение самой работы даже в десять раз почти ничего не меняет. Менять надо очереди — то есть конструкцию.
Если бы историю BPR можно было закончить на этих кейсах, статья была бы проповедью. Но у неё есть вторая половина.
К середине 1990-х реинжиниринг превратился в индустрию с оборотом около $51 млрд — и в эвфемизм массовых увольнений. Опрос CSC Index «State of Reengineering» (1994; данные разобраны в обзоре истории BPR) показал: из 99 завершённых инициатив 67% дали посредственные, маргинальные или провальные результаты; 73% компаний использовали реинжиниринг прежде всего для сокращения в среднем 21% рабочих мест. Сами Хаммер и Чампи ещё в 1993 году написали — цитируем точно, потому что эту цифру потом растиражировали без контекста: «По нашей ненаучной оценке, от 50 до 70 процентов организаций, взявшихся за реинжиниринг, не достигают задуманных драматических результатов».
Томас Дэвенпорт — второй отец-основатель BPR, автор вышедшей одновременно с хаммеровской статьи «The New Industrial Engineering» (1990) — в 1995-м подвёл итог в тексте с говорящим названием «The Fad That Forgot People»: «Скала, о которую разбился реинжиниринг, проста: люди. Реинжиниринг обращался с людьми внутри компаний так, будто они просто биты и байты, взаимозаменяемые детали». Сам Хаммер признал в интервью Wall Street Journal (26 ноября 1996): «Я был недостаточно умён в этом. Сказывалось моё инженерное образование, и я недооценивал человеческое измерение. Я понял, что оно критично».
Из истории BPR следуют два урока, и нужны оба. Первый: автоматизация существующего процесса без редизайна упирается в потолок в проценты — вместо разов. Второй: редизайн без работы с людьми, властью и мотивацией даёт те самые 50–70% провалов. Дальше оба урока превратятся в конкретные шаги последовательности.
Из этой же истории выросло различение, которое сегодня часто смешивают. У самого Хаммера была только дихотомия «автоматизировать старое против спроектировать новое»; современную терминологию оформили позже — Gartner в своём глоссарии и исследователи MIT CISR в работе «Don't Confuse Digital with Digitization» (2017). Рабочая лестница выглядит так:
Каждая ступень имеет свой потолок эффекта и свою цену ошибки. Digitization и автоматизация сохраняют конструкцию — вместе с её очередями, петлями переделок и лишними согласованиями. Если конструкция плохая, вы получаете быстрый плохой процесс. Это же правило обычно приписывают Биллу Гейтсу и книге «The Road Ahead» (1995): «автоматизация, применённая к эффективной операции, умножит эффективность; автоматизация, применённая к неэффективной операции, умножит неэффективность». Проследить цитату до конкретной страницы книги нам не удалось — что не мешает ей точно описывать механизм.
У тезиса «сначала процесс, потом технология» есть неприятное свойство: каждое поколение менеджеров переоткрывает его на собственные деньги. Волна повторяется с точностью до названия технологии — меняется только сумма.
Роботы, 1980-е. General Motors при Роджере Смите вложила в автоматизацию заводов около $45 млрд за 1980–1985 годы (Maryann Keller, «Rude Awakening», 1989). Финансовый директор GM Алан Смит посчитал в 1986-м, что запланированных на следующую четырёхлетку $34,7 млрд хватило бы, чтобы целиком купить Toyota и Nissan. Результат вошёл в фольклор: на заводе Hamtramck роботы красили друг друга и приваривали двери не к тем кузовам (Ingrassia & White, «Comeback», 1994). А в это же время в калифорнийском Фремонте совместное предприятие GM и Toyota — NUMMI — взяло худший завод GM с прогулами 20–25% и худшим качеством в корпорации, вернуло на него 85% тех же рабочих и без сопоставимых вложений в роботов сделало его лучшим по качеству заводом GM; прогулы упали до 3–4% (Adler, 1993; This American Life #403). Людей не меняли — изменили систему работы.
ERP, 1990-е. Фармдистрибьютор FoxMeyer с оборотом $5 млрд внедрял SAP R/3 вместе с автоматизацией склада, заложив в ещё не готовую систему свежевыигранный крупный контракт. Система тянула около 10 тысяч заказных строк в сутки против сотен тысяч у старой; при закрытии складов деморализованные рабочие портили запасы; компания потеряла $34 млн инвентаря и в 1996 году обанкротилась. Академический разбор (Scott, «The FoxMeyer Drugs' Bankruptcy: Was it a Failure of ERP?», 1999) заканчивается цитатой одного из участников: «Это не был провал автоматизации. Это не был провал коммерческого софта. Это был провал управления». Hershey в 1999-м запустила SAP, Manugistics и Siebel разом, одним «большим взрывом», сжав рекомендованный график почти вдвое, — прямо перед Хэллоуином, в пик сезона. Компания не смогла отгрузить заказов примерно на $100 млн при полных складах (разбор CIO; хронология урезанного тестирования — в кейс-разборе Pemeco).
Мегапроекты, 2000-е. Британская NHS запустила в 2002 году National Programme for IT с оценкой £2,4 млрд. Программу навязали сверху локальным организациям, не разобравшись, как реально работают клиники; врачи ей не доверяли; подрядчики срывали сроки годами. К моменту официального демонтажа в 2011-м налогоплательщик заплатил более £9,8 млрд (отчёт Public Accounts Committee, 2013), а National Audit Office написал, что потраченные на медкарты £2,7 млрд «не представляют ценности за деньги».
ERP снова, 2010-е. Lidl потратила семь лет и около €500 млн на внедрение SAP for Retail и в 2018-м вернулась на собственную старую систему (Computer Weekly). Корень: Lidl вела учёт запасов по закупочным ценам, стандарт SAP — по розничным. Вместо честного анализа, что дешевле — поменять свой процесс или платить за его сохранение, — компания выбрала массовую кастомизацию, и каждая доработка наращивала сложность, пока проект не рухнул. Это не аргумент «надо было прогнуться под SAP»; это аргумент про последовательность: решение о системе приняли до того, как поняли собственный процесс.
RPA, конец 2010-х. Глобальный опрос Deloitte по RPA (2018): лишь 3% организаций смогли масштабировать RPA до 50+ роботов, а главным барьером масштабирования участники назвали фрагментацию и нестандартность процессов — роботу нельзя поручить процесс, который в каждом филиале выполняется по-своему. Консультанты EY ещё в 2016-м оценивали — это наблюдение практиков, не академическое исследование, — что 30–50% первых RPA-проектов терпят неудачу. Хаос, поставленный на роботизированные рельсы, остаётся хаосом — просто теперь его дороже менять.
ИИ, сейчас. Опросы MIT Sloan Management Review и BCG: в 2019-м 7 из 10 компаний сообщали о минимальном или нулевом эффекте от ИИ; в 2020-м — только 10% получали значимый финансовый эффект, и отличал их не выбор модели, а перестройка процессов и взаимное обучение людей и алгоритмов. Дэвенпорт — тот самый — вместе с Раджеевым Ронанки разобрал 152 ИИ-проекта (HBR, 2018) и вынес вывод в подзаголовок: «не начинайте с лунных миссий» — работают проекты, идущие от конкретной бизнес-задачи. Нашумевший нерецензированный отчёт MIT NANDA (2025) утверждает, что около 95% корпоративных пилотов генеративного ИИ не дают измеримого эффекта на P&L; к методологии есть обоснованные претензии, но его качественный вывод — успешные внедрения отличает интеграция в конкретный рабочий процесс, а не качество модели — совпадает с данными куда более строгого источника.
Этот источник — та самая McKinsey, чей отчёт указан на нашей раздатке. С уточнением: «The State of AI in 2023» зафиксировал взрывное распространение генеративного ИИ — треть компаний уже использовала его регулярно хотя бы в одной функции. А ключевой для нашей темы вывод появился в волне марта 2025 года: из всех проверенных организационных практик наибольший вклад в способность компании получить эффект от генеративного ИИ на уровне EBIT даёт перепроектирование рабочих процессов — workflow redesign. При этом фундаментально перепроектировали хотя бы один процесс лишь 21% компаний-пользователей. Круг замкнулся: через 35 лет после «Don't Automate, Obliterate» самый масштабный опрос индустрии про самую модную технологию приходит к выводу Хаммера — теперь с регрессией по десяткам переменных.
Механизм общий: технология — усилитель. Она умножает ту систему, в которую попадает. Хорошо спроектированную — делает быстрее и дешевле. Плохо спроектированную — быстрее производящей брак, очереди и хаос, причём теперь этот хаос зашит в код и стоит дороже в изменении.
Российская история знает обе стороны этого механизма — и свой Hershey, и свой NUMMI.
ЕГАИС, 2006. Систему учёта алкоголя включили приказом с 1 июля 2006 года — без отладки процессов участников рынка и с ответственностью, размазанной по шести ведомствам: владельца у сквозного процесса не было. Итог «чёрной субботы»: импортный алкоголь исчез из продажи, заводы простаивали месяцами, рынок лихорадило около полугода, а потери отрасли за год оценивали в $1,5–2 млрд (Коммерсантъ; хроника кризиса). Переход на автоматический учёт в итоге отложили на конец 2007-го. Контрастный пример из того же госсектора — МФЦ «Мои документы»: та же государственная машина, но услуга перепроектирована вокруг заявителя по принципу одного окна, и результат — 166 млн обращений в год при удовлетворённости качеством выше 96% (мониторинг Минэкономразвития).
Сбербанк, 2008–2016. С ноября 2008 года банк перестраивал процессы отделений по мотивам производственной системы Toyota: стандартизация операций, пересмотр маршрутов документов, «Биржа идей». К 2010-му очереди в рознице сократились на 36%, длительность корпоративных процессов — на 38%, а суммарные перемещения сотрудников — на 383 километра (Ведомости, 2010). Очереди победил редизайн, а не «большие данные». Обратную сторону та же компания показала через шесть лет: в 2016-м Греф публично признал, что около 30 млрд рублей, вложенных в новую ИТ-платформу, «не дали эффекта» (Ведомости, 2016), а в 2019-м — что ошибки ИИ стоили банку миллиарды (Ведомости, 2019). Одна компания на собственной шкуре прожила обе половины правила про усилитель.
Производственные системы. Росатом строил ПСР на базе системы Toyota — её консультировал Нампачи Хаяси, ученик Тайити Оно. Переработка графиков ремонтов и управления запасами дала за один только 2010 год сокращение ремонтов энергоблоков на 56 суток и эффект в сотни миллионов рублей — без замены оборудования (разбор опыта Росэнергоатома). КАМАЗ с 2006 года получил от своей производственной системы десятки миллиардов рублей накопленного эффекта при затратах менее 200 млн (исследование ВШЭ; НГ, 2018). А нацпроект «Производительность труда» превратил подход в конвейер: эксперты Федерального центра компетенций полгода оптимизируют поток на предприятии без крупных инвестиций и до всякой автоматизации — по итогам 2019–2024 у 6,5 тыс. предприятий-участников время протекания процессов сократилось в среднем на треть, выработка выросла на 45% (итоги нацпроекта; это самоотчёт, но масштаб и методика открыты).
Свежий российский срез по ИИ даёт то же чтение: по обследованию, проведённому по методологии ВШЭ на 15 тысячах организаций (данные 2024 года), главные барьеры внедрения — стоимость, кадры, недостаточные данные и сложность интеграции; о росте эффективности процессов сообщает около половины использующих ИИ организаций, о росте производительности — лишь каждая пятая (ИСИЭЗ ВШЭ). Узкое место — не модели.
Вернёмся к раздатке и пройдём её 12 шагов — не как чек-лист для заучивания, а как цепочку, в которой каждый шаг закрывает конкретную ошибку следующего. Чтобы не запутаться в схемах: лестница выше отвечала на вопрос, насколько глубоко вы меняете систему; 12 шагов отвечают, в каком порядке задавать вопросы; а порядок ходов Remove → Simplify → Standardize → Invest в конце статьи — в каком порядке действовать внутри редизайна. Мы сгруппировали шаги в пять фаз: результат → диагностика → конструкция → технология → закрепление. И добавим один шаг, которого в раздатке нет, а должен быть.
Первый вопрос звучит банально, и именно поэтому его почти никогда не задают всерьёз: какой бизнес-результат должен измениться?
«Внедрить ИИ», «автоматизировать согласование», «перейти на новую систему», «внедрить BPM» — не бизнес-цели. Это решения, ждущие проблему. Бизнес-цель формулируется через изменение результата системы: сократить срок от заявки до решения с 12 до 5 дней; поднять пропускную способность на 30% без роста штата; снизить стоимость обработки одного кейса; уменьшить долю переделок; сократить замороженный оборотный капитал. У такой формулировки три обязательных свойства: единица измерения, текущее значение и целевое значение.
Спросите инициатора проекта: «Какая метрика изменится, с какого значения на какое?» Если в ответе звучит название технологии — цели нет. Опасность подхода «сначала решение» не в том, что решение обязательно плохое, а в том, что без цели невозможно ни выбрать между альтернативами, ни признать неудачу: проект «внедрить систему» всегда можно объявить успешным, ведь система внедрена. Как связать цели процессов со стратегией, не превратив это в ритуал, — в разборе связи стратегии и бизнес-процессов.
Вторая ошибка — оптимизировать участок, а не систему. Она настолько распространена, что против неё написан целый роман: «Цель» Элияху Голдратта (1984), продающийся миллионными тиражами уже сорок лет. Теория ограничений Голдратта сводится к жёсткому утверждению: пропускную способность системы определяет её узкое место, поэтому «час, потерянный на бутылочном горлышке, — час, потерянный всей системой», а «час, сэкономленный не на бутылочном горлышке, — мираж». Улучшение любого звена, кроме ограничения, не даёт системе ничего — а часто делает хуже, наращивая горы незавершённой работы перед узким местом.
Типовой пример: отдел продаж премируют за количество заключённых договоров. Продажи растут, входящий поток увеличивается — и упирается в производство, которое никто не расширял. Очередь растёт, сроки ползут, клиентский опыт ухудшается, и в сумме компания получает больше договоров и меньше довольных клиентов. Каждый отдел при этом перевыполнил свой KPI. Локальные метрики подразделений — официально утверждённый способ разрушать сквозной результат.
Второй пример тоньше, потому что выглядит как добродетель: «загрузим каждого сотрудника на 95–100%». Интуиция говорит, что высокая загрузка — это эффективность. Теория очередей отвечает формулой. Аппроксимация Кингмана (1961) показывает, что среднее ожидание в очереди пропорционально множителю ρ/(1−ρ), где ρ — загрузка ресурса. При загрузке 50% множитель равен 1. При 90% — уже 9. При 95% — 19. Ожидание растёт не линейно, а гиперболически: последние проценты загрузки покупаются взрывным ростом очередей, тем более сильным, чем выше вариативность поступления и обработки — она стоит в формуле отдельным множителем. «Все заняты» и «система быстро работает» при высокой вариативности — почти противоположные состояния; свободная мощность — это то, чем система платит за короткие сроки. Подробнее — в разборе теории очередей для процессов.
Формула Кингмана в действии: после 80% загрузки время ожидания растёт гиперболически. Поэтому «загрузим всех на 100%» и «сократим сроки» — несовместимые цели.
Вывод для практики: границы анализа должны совпадать с границами потока ценности — от события «клиент попросил» до события «клиент получил», через все отделы. Всё, что оптимизируется внутри более узких границ, по умолчанию подозревается в локальной оптимизации. Быстрее всего сквозные границы и зависимости между подразделениями видны на карте процессов верхнего уровня и графе связей реестра.
Документация процесса и диагностика процесса — разные жанры. Регламент и BPMN-схема «как должно быть» отвечают на вопрос «как задумано». Диагностика отвечает на вопрос «как есть»: сколько реально занимает каждый этап, где копятся очереди, сколько существует вариантов исполнения, где возникают петли переделок, где ручные обходные пути, где заявка ждёт, а где теряется информация при передаче между отделами.
Разрыв между «задумано» и «есть» обычно недооценивают на порядки. Пример из практики process mining: в Siemens восстановили из логов ИТ-систем фактический процесс order-to-cash и обнаружили около 900 тысяч вариантов исполнения процесса, который на схеме выглядел одним прямоугольником со стрелками. Process mining — метод, развитый Вилом ван дер Аалстом с конца 1990-х, — строит модель реального процесса из событийных логов: достаточно, чтобы системы писали идентификатор кейса, действие и время.
Но логи видят не всё: они не знают про Excel на рабочем столе, звонки «протолкни мою заявку» и решения, которые принимаются в курилке. Рабочая диагностика — это сочетание: модель процесса как каркас, process mining и операционные данные как факты, интервью, опросы участников процесса и прямое наблюдение как источник того, чего в данных нет. У Toyota последнее возведено в принцип genchi genbutsu — «иди и смотри на месте»: решение о процессе, которого ты не видел своими глазами, — это решение о слухах про процесс.
«Процесс медленный». «Людей не хватает». «Этот этап всех тормозит». «ИИ ускорит работу вдвое». Все четыре утверждения — гипотезы, и до измерений они стоят одинаково: нисколько. Пока чисел нет, совещание решает вопрос статусом говорящих, а не устройством системы.
Минимальный набор показателей невелик: время протекания процесса, оно же lead time (от запроса до результата, глазами клиента), время обработки (сколько над заявкой реально работают), время ожидания (разница между первыми двумя — обычно это 90%+ всего срока), пропускная способность (заявок в неделю), незавершённая работа, она же WIP (заявок в процессе прямо сейчас), доля переделок, стоимость обработки одной заявки — и вариативность каждой из этих величин. Почему без вариативности весь набор врёт — отдельная история.
Три из этих величин связаны законом Литтла (Little, 1961) — доказанной теоремой, а не эвристикой: в устойчивом состоянии среднее число кейсов в системе равно произведению пропускной способности на среднее время прохождения. В операционной записи: время протекания = незавершённая работа / пропускная способность. Отсюда: если команда закрывает 50 заявок в неделю, а в работе постоянно висит 400, средний срок прохождения — 8 недель, и никакие призывы работать быстрее этого не изменят, пока не уменьшится объём незавершённой работы или не вырастет пропускная способность. Закон Литтла позволяет за минуту проверять обещания: «внедрим систему, и сроки упадут вдвое» означает «незавершёнка уменьшится вдвое или пропускная способность вырастет вдвое» — за счёт чего именно?
«Заявки долго согласовываются» — не проблема, а симптом. Причин у него может быть десяток, и лечатся они по-разному: слишком много согласующих; работа накапливается пачками и обрабатывается раз в неделю; неправильно расставлены права решения, и до директора доходит то, что мог решить специалист; единственный редкий эксперт — общий ресурс пяти процессов; SLA стимулирует брать простые кейсы и мариновать сложные; согласование вообще не создаёт ценности и существует потому, что в 2014 году был инцидент.
Прыжок от симптома сразу к решению стоит дороже всего: «долго согласовывается → нужна система электронного согласования». Если причина в правах решения, вы получите электронную версию той же очереди. Инструменты против этого прыжка стары и просты: «пять почему» Тайити Оно — в его книге разобран классический пример, от «станок остановился» через пять «почему» до «на маслонасосе нет фильтра»; диаграмма Исикавы для систематизации ветвящихся причин; анализ Парето, чтобы отделить главные причины от длинного хвоста.
И одно предупреждение от Деминга, меняющее направление поиска: «По моему опыту, большинство проблем и возможностей улучшения распределяются так: 94% принадлежит системе (ответственность менеджмента), 6% — особые причины» («Out of the Crisis», 1986). Это экспертная оценка, а не измерение, но смысл её подтверждён десятилетиями практики: если анализ причин закончился фамилией виноватого — он не закончился. Ищите правило, очередь, стимул или конструкцию, которые заставляют нормального человека работать именно так.
У редизайна есть зеркальная ошибка: увидев карту процесса с 14 согласованиями, потянуться выпилить всё «лишнее». Но часть проверок, подписей и разделений полномочий существует потому, что управляет риском: регуляторное требование, финансовый контроль, разделение обязанностей против фрода, информационная безопасность, аудируемость, безопасность людей.
Поэтому перед редизайном каждый контроль в процессе должен получить ярлык: историческая бюрократия (убрать), регуляторное требование (сохранить, но можно автоматизировать проверку), риск-контроль (сохранить осмысленно: возможно, выборочный постконтроль вместо тотального предконтроля), аудиторский след (сохранить — автоматизированный процесс, кстати, ведёт его лучше ручного). Хороший редизайн удаляет ненужную сложность и сохраняет необходимый контроль, и различие между ними определяется анализом риска, а не эстетическим чувством аналитика.
Самая частая деградация этого шага — нарисовать «тот же процесс, но быстрее и с ИИ». Будущая конструкция — это выбор из пространства альтернатив, и пространство стоит раскрыть до того, как выбирать. Классы ходов известны:
Первые семь классов ходов не требуют покупки технологий вообще: это изменения правил, ролей и маршрутов. Практика редизайна снова и снова показывает, что именно они дают основную часть эффекта, а технология затем масштабирует и закрепляет его. И главное: каждый вариант из этого списка — считаемый. Прежде чем что-либо покупать и внедрять, альтернативы можно прогнать в имитационной модели на своих данных и сравнить по срокам, очередям, загрузке и стоимости — в витрине посчитанных кейсов симуляции видно, как такие расчёты выглядят на живых процессах и как часто выигрывает не тот вариант, на который ставили изначально.
Здесь мы дополняем раздатку: между «спроектировали будущий процесс» и «внедряем технологию» в ней зияет дыра. Красивая схема целевого процесса — это гипотеза о поведении системы. BPMN отвечает на вопрос «как устроен процесс» и ничего не говорит о том, что произойдёт с этой конструкцией во времени под реальной нагрузкой, с реальной вариативностью и реальными ресурсами. Наличие красивого будущего процесса ещё не означает, что он будет работать.
Проверять гипотезу можно по нарастающей цене: аналитическая прикидка (закон Литтла и формула Кингмана на салфетке отсеивают безнадёжные варианты за час), имитационное моделирование, пилот на одном подразделении, контролируемый эксперимент с честным сравнением до и после.
Отдельно про имитационное моделирование, discrete-event simulation. Для процессов это ближайший аналог аэродинамической трубы. Метод не новый — он шестьдесят лет жил в дорогих инженерных пакетах — но только недавно стал доступен процессной команде прямо из BPMN-схемы. Симуляция прогоняет через будущую конструкцию тысячи виртуальных заявок с заданными интенсивностями поступления, длительностями операций, расписаниями и вариативностью. На выходе — распределения, а не мнения: какое время протекания получится в медиане и в 95-м перцентиле, где вылезет новое узкое место, сколько людей нужно в пиковый сезон. Ван дер Аалст, разбирая типовые ошибки симуляции процессов, указывает и главный подводный камень: модель, построенная по регламенту «как задумано», а не по данным «как есть», даст уверенно неверный прогноз («Business Process Simulation Revisited», 2010). Поэтому симуляция питается результатами шагов 3 и 4 — ещё одна причина их не перепрыгивать. Как расчёт меняет управленческое решение, мы показывали на кейсе автосервиса, а почему ошибка, найденная в модели, на порядки дешевле найденной после запуска — в разборе правила NASA.
Симуляция варианта конструкции стоит часы работы аналитика. Внедрение неработающей конструкции стоит месяцы, деньги и — самое дорогое — доверие людей к следующему изменению. Hershey сожгла $100 млн невыполненных заказов на проверке гипотезы «успеем к сезону» в бою; стресс-тест расписания запуска в модели стоил бы дни. Запускать автоматизацию, не прогнав конструкцию в модели, — ставка вслепую размером в бюджет внедрения.
Только здесь — на восьмом шаге из двенадцати — появляется технология. Не потому что она не важна, а потому что теперь известно всё, что делает её выбор осмысленным: целевая метрика (шаг 1), реальное устройство и узкое место (шаги 2–5), проверенная будущая конструкция (шаги 7–7½). Технология отвечает на вопрос: какая цифровая способность нужна, чтобы эта конструкция заработала? Workflow-движок — если узкое место в маршрутизации и прозрачности. Process mining — если в понимании фактического исполнения. RPA — если в ручном переносе данных между системами, которые нельзя интегрировать по-человечески. Интеграция — если информация теряется на стыках. ИИ — если узкое место в решениях и суждениях: классификация обращений, извлечение данных из документов, черновики ответов, прогноз риска.
Вопрос «куда бы нам применить ИИ?» гарантированно находит применение — и почти гарантированно не находит эффекта, потому что место выбирается по удобству демонстрации, а не по положению в системе. Вопрос «является ли ИИ лучшим способом устранить это конкретное ограничение?» часто даёт неожиданный ответ: лучшим способом оказывается удаление согласования; изменение лимита полномочий; починка правила маршрутизации; сдвиг расписания; отказ от пачек; одна ставка в узком месте; замена KPI, который стимулирует неправильное поведение. Все эти решения дешевле любого пилота — если последовательность шагов дала им шанс быть найденными.
А когда ИИ действительно ложится в конструкцию, его эффект складывается с эффектом редизайна: перепроектированный процесс с ИИ-поддержкой решений — это и есть те 21% из отчёта McKinsey, у которых экономика сходится. Что генеративные модели реально знают о вашем процессе и на какие данные им нужно опираться — отдельный разбор.
После запуска новой конструкции у неё должен остаться владелец — человек, отвечающий за сквозную метрику процесса и имеющий право его менять. Не владелец регламента, а владелец результата: он отвечает за время от заявки до решения, разруливает конфликт между KPI продаж и мощностью производства, ведёт бэклог улучшений. Рабочие инструменты здесь — сквозная метрика, закреплённая за конкретной фамилией и отражённая в оргструктуре, а не только в презентации; процессный комитет для кросс-функциональных конфликтов; регулярный ревью процесса с данными на столе; рабочее место владельца процесса вместо строчки в приказе.
Антипример здесь у каждой компании свой, но сценарий один: проект закончился, команду распустили, через год схемы устарели, каждый филиал вернул свои варианты исполнения, и система тихо приползла в состояние, из которого её вытаскивали, — только теперь с дополнительным слоем софта. Процесс без владельца деградирует не потому, что люди плохие: каждый локальный участник продолжает рационально оптимизировать свой участок, и без человека, отвечающего за целое, сумма локальных рациональностей снова складывается в сквозной хаос.
Нельзя доказать успех трансформации, если до неё не существовало базового замера — измеренного «до» (baseline). Логика: замер «до» → целевое значение → вмешательство → измерение → сравнение. Принципиально различие между метриками выпуска и метриками результата. «Автоматизировано 73% операций», «обучено 500 пользователей», «внедрено 40 роботов» — это показатели усилий, output. «Время протекания снизилось с 9,3 до 4,8 дня», «доля переделок упала с 12% до 5%» — это показатели результата, outcome. Проекты любят отчитываться первым, потому что output всегда растёт.
Показательна судьба цифры «70% трансформаций проваливаются», которую индустрия повторяет десятилетиями. Марк Хьюз (Journal of Change Management, 2011) проследил её до источников — той самой «ненаучной оценки» Хаммера и Чампи, наблюдений Коттера без методологии и циклических ссылок консультантов друг на друга — и не нашёл за ней ни одного эмпирического исследования. Индустрия, требующая от клиентов data-driven-решений, живёт на непроверенной цифре. Не будьте этой индустрией: измеряйте своё «до» и «после».
Урок стоимостью в репутацию целого движения — см. историю BPR выше — состоит в том, что процесс меняется тогда, когда меняется поведение людей, а поведение не меняется от рассылки регламента и часового тренинга. Новая конструкция перераспределяет роли, полномочия, статус и иногда рабочие места; люди сопротивляются не изменениям как таковым, а потерям, которые изменения им приносят, — и это рационально. Работать приходится с причинами сопротивления, а не с его симптомами: менять стимулы и KPI вместе с процессом (иначе старые метрики продолжат вознаграждать старое поведение), переучивать под новые роли до запуска, а не после, вести изменение по управляемой модели — как это выглядит на практике, мы показывали на связке BPMN + ADKAR. Согласование новой схемы с её будущими участниками — тоже инструмент внедрения, а не бюрократия: человек, согласовавший модель процесса, уже не скажет, что с ним не посоветовались.
Самое наглядное доказательство, что дело в системе, а не в людях, — всё тот же NUMMI: 85% рабочих худшего завода GM в новой системе работы дали лучшее качество корпорации. Никого не «поменяли» — изменили стимулы, роль мастера, право остановить конвейер и отношение к проблемам.
Трансформация не заканчивается финишной лентой «внедрили — готово». Процесс живёт в меняющейся среде: спрос, продуктовый микс, люди, регуляторика, стоимость ресурсов. Конструкция, оптимальная сегодня, устареет — вопрос только в том, заметите ли вы это. Поэтому конечное состояние трансформации — способность видеть состояние процесса и улучшать его: работающий цикл PDCA (восходящий к Шухарту и Демингу), стандарт как основа для следующего улучшения, а не как памятник.
Именно здесь прячется ловушка, описанная Репеннингом и Стерманом в работе с говорящим названием «Nobody Ever Gets Credit for Fixing Problems that Never Happened» (2001): под давлением текучки менеджеры выбирают «работать усерднее» вместо «работать умнее», срезают углы и урезают время на улучшения; способность процесса деградирует, давление растёт, на улучшения остаётся ещё меньше времени — петля затягивается. Выход один: время на улучшение — не остаток после текучки, а защищённая часть конструкции процесса.
Нижняя строка раздатки предлагает сжатую формулу: убери то, что не добавляет ценности → упрости оставшееся → стандартизируй то, что должно повторяться → инвестируй в способности, технологии и людей. Мы не нашли одного автора этой формулы — и раздатка честно его не называет. Это фольклорная кристаллизация идей, у каждой из которых источники есть: «убери и упрости прежде чем ускорять» — семь видов потерь Тайити Оно («Toyota Production System», 1988) и первый принцип Вумека и Джонса «сначала определи ценность» («Lean Thinking», 1996); «стандартизируй прежде чем улучшать» — стандартная работа TPS; «автоматизируй последним» — и Оно («есть последовательность внедрения автоматизации, которую нужно соблюдать… автоматизация ради самой себя — проблема», «Workplace Management»), и восьмой принцип Лайкера («The Toyota Way», 2004): только надёжная, проверенная технология, которая служит людям и процессу.
Порядок ходов из раздатки: дорогие ходы — в конце, когда система уже маленькая, простая и повторяемая. И это цикл, а не проект.
В развёрнутом виде порядок ходов выглядит так:
Почему порядок именно такой? Каждый шаг уменьшает стоимость следующего. Удаление сокращает фронт упрощения; упрощение сокращает фронт стандартизации; стандартизация делает автоматизацию дешёвой и надёжной. Вся цепочка вместе приводит к тому, что дорогие ходы — технология и ИИ — применяются к маленькой, простой, повторяемой системе, а не к большому запутанному клубку. Инвертируйте порядок — и вы будете закреплять в коде каждый из сотен тысяч фактических вариантов исполнения.
Соберём последовательность на одном модельном примере. Цифры условные, но механика типовая — её легко примерить на любой процесс «заявка → проверки → решение».
Постановка (шаг 1). Банк хочет «внедрить ИИ-скоринг». Останавливаемся, формулируем результат: сократить срок от заявки до решения с 9 дней до 2, не увеличив долю дефолтов. Появились метрика, точка отсчёта и цель.
Диагностика (шаги 2–4). Строим фактическую картину по логам кредитного конвейера и интервью. Обнаруживается: чистая работа над заявкой — около 3 часов из 9 дней; заявка проходит 4 отдела и 2 круга возвратов за недостающими документами — в 40% случаев по одной причине: клиент не приложил выписку, о которой узнаёт на пятый день; андеррайтер — общий ресурс трёх продуктов, загружен на 96%, перед ним очередь в 5 дней (ρ/(1−ρ) = 24 — теперь понятно, откуда); служба безопасности вручную проверяет все заявки подряд, хотя 70% — повторные клиенты с историей.
Root cause и риск (шаги 5–6). Симптом «долго решаем» раскладывается на три причины: возвраты из-за требований, о которых клиент узнаёт поздно; перегруженный общий ресурс; тотальный предконтроль там, где хватило бы выборочного. Проверка СБ — риск-контроль, её нельзя просто удалить; но её можно дифференцировать по риску, сохранив тотальную проверку для новых клиентов.
Редизайн и валидация (шаги 7–7½). Пространство вариантов: (а) полный чек-лист документов на входе плюс автоматическая проверка комплектности; (б) выделенная линия для повторных клиентов с выборочным постконтролем СБ; (в) поднять лимит самостоятельного решения кредитного специалиста, разгрузив андеррайтера; (г) ИИ-скоринг. Симуляция на фактических данных даёт неожиданный результат: варианты (а)+(б)+(в) вместе снимают срок с 9 дней до ~2,5 без всякого ИИ; ИИ-скоринг поверх старой конструкции — только до 7 дней, потому что узкое место не в скоринге, а в возвратах и очереди к андеррайтеру. Первоначальное решение «внедрить ИИ-скоринг» не выдержало проверки моделью — точнее, заняло правильное место: четвёртым ходом после трёх организационных.
Технология и закрепление (шаги 8–12). Теперь технология выбирается под конструкцию: автопроверка комплектности на входе, маршрутизация по сегментам риска, скоринговая модель для типовых повторных заявок — с человеком на нетиповых. Назначен владелец сквозного процесса с правом менять правила маршрутизации; на дашборде — время протекания по перцентилям, доля возвратов, загрузка андеррайтеров; через квартал — сравнение с замером «до» и следующая итерация: очередь переместилась (она всегда перемещается), работаем с новым узким местом.
Заметьте: ИИ в итоге внедрили. Просто он оказался четвёртым ходом, а не первым — и поэтому сработал.
Чтобы статья не превратилась в проповедь, разберём четыре честных возражения.
«Зачем анализировать current state? Может, сразу спроектировать новый процесс?» Иногда — действительно сразу. Если вы строите процесс с нуля (новый продукт, новая компания) — анализировать нечего, проектируйте. Если процесс подлежит полной замене вместе с системой — глубокая диагностика каждого шага избыточна. Но два элемента анализа не пропускаются никогда: замер результата «до» (иначе нечем доказать успех) и понимание, зачем существуют нынешние контроли (иначе вы удалите риск-контроль, приняв его за бюрократию, — привет, Lidl, выяснившая цену своей учётной специфики на седьмом году проекта). Хаммер, кстати, не призывал изучать старый процесс бесконечно — он призывал не принимать его как данность; это разные вещи.
«Когда скорость важнее идеального анализа?» Чаще, чем кажется адептам методологии. Глубина анализа должна быть пропорциональна цене ошибки и её необратимости. Дёшево обратимое изменение — переставили поле в форме, поменяли текст уведомления, перекинули одного человека между участками — быстрее проверить в бою, чем моделировать: «запустили и смотрим» здесь рациональная стратегия. Быстрая грубая диагностика за неделю (логи + три интервью + прикидка по закону Литтла) почти всегда возможна и радикально лучше нулевой; смертельна не короткая диагностика, а пропущенная. Полный аппарат — симуляция, пилот, контролируемый эксперимент — приберегите для решений, которые дорого разворачивать: сокращения, реорганизации, замены систем, изменения клиентских обязательств.
«Когда допустимо начинать с технологии?» Когда технология создаёт способность, которой раньше не существовало, — и тем самым расширяет пространство вариантов дизайна. Это не отступление от логики Хаммера, а сама логика Хаммера: его определение реинжиниринга начинается со слов «использовать мощь современных информационных технологий». Дэвенпорт и Шорт называли это рекурсивным отношением: смотреть на технологию через призму процессов и на процессы через призму технологии — одновременно. LLM, читающий неструктурированные документы, действительно делает возможными конструкции, бессмысленные в 2019 году, и не знать об этом при проектировании — значит проектировать вчерашний процесс. Грань проходит не в знании о технологии, а в том, что считается результатом: «мы изучаем, какие конструкции процесса становятся возможными с LLM» — это исследование пространства дизайна, шаг 7 нашей последовательности. «Мы внедряем LLM, осталось найти куда» — та самая перепутанная последовательность.
«Не превращается ли 12-шаговая модель в водопад на два года?» Превращается — если исполнять его как консалтинговый проект с шестимесячной фазой анализа и отчётом на 300 страниц. Но последовательность — это логическая зависимость шагов, а не календарный план. Один виток «понять → сформулировать гипотезу → смоделировать → проверить → перепроектировать» может занимать две недели на одном процессе; двенадцать шагов — это вопросы, на которые нужно ответить, а не двенадцать фаз с воротами и комитетами. Итерации не отменяют порядок внутри витка: и в двухнедельном спринте цель формулируется до решения, а конструкция проверяется до внедрения. Водопад — это про длину петли обратной связи; наша последовательность — про направление причинности. Их можно и нужно совмещать: короткие петли, правильное направление.
Соберём доказанное. Автоматизация существующего процесса без редизайна упирается в потолок, потому что 90%+ времени заявки — очереди и передачи, а не работа (Hammer, 1990; закон Литтла; формула Кингмана). Основную часть эффекта даёт изменение конструкции — правил, ролей, маршрутов, прав решения (Ford, MBL, IBM Credit, NUMMI); технология масштабирует и закрепляет этот эффект, и в этой роли она незаменима. Конструкцию можно и нужно проверять до внедрения — моделью, симуляцией, пилотом, — потому что ошибка в модели на порядки дешевле ошибки в бою (FoxMeyer, Hershey, NHS). Эффект существует, только если существовал замер «до» и измерен результат, а не объём усилий. Изменение не закрепляется без владельца, работы с людьми и защищённого времени на улучшения (история BPR, ловушка Репеннинга и Стермана). И это не ностальгия по классике: самый масштабный текущий опрос индустрии — McKinsey, март 2025 — находит, что именно перепроектирование рабочих процессов, а не выбор модели, статистически отличает компании, получающие финансовый эффект от ИИ.
Финальная формула: сильная трансформация начинается не с технологии. Она начинается с ответа, какой результат должна создавать система; продолжается пониманием, как система работает сейчас и почему именно так; затем проектируется более простая конструкция и проверяется её работоспособность — и только после этого выбираются технологии, которые делают её возможной. Завершает трансформацию не запуск софта, а измеренный результат и работающий механизм следующего улучшения. Раздатка называет это «business design problem», и, проверив её по первоисточникам, мы готовы подписаться: трансформация процессов — задача проектирования бизнеса, в которой у технологии есть точное место — восьмое из двенадцати, и то после проверки конструкции.
Практически вся середина этой последовательности — модель текущего процесса, реестр, проверка конструкции симуляцией, регламенты и рабочее место владельца — закрывается одной платформой Storm: путь от схемы до посчитанного варианта редизайна проходится, не покидая одного инструмента.
В следующий раз, когда на совещании прозвучит «так, а куда бы нам здесь прикрутить ИИ?» — у вас есть встречный вопрос: «А какой результат мы меняем, и что сейчас мешает его получить?» С него всё и начинается.
Новые статьи в вашем электрическом ящике
Обзоры конференций, лучшие практики процессного подхода и учебные статьи в вашей почте. Не чаще 1 раза в неделю.
Без спама, только то, что вы запросили.
