ГЛАВА 03

Антипаттерны и провалы

«Учитесь на чужих ошибках». Эта фраза стала клише именно потому, что почти никто на чужих ошибках не учится. Каждый CEO (генеральный директор), читающий о провале Lidl, думает: «у нас будет иначе». Каждый CIO (ИТ-директор), читающий про Hershey, думает: «у нас другая команда внедрения». Каждый CDTO (директор по цифровой трансформации), читающий про Haribo, думает: «у нас зато выбран правильный консультант».

Иначе не будет. Команда другая, консультант — тоже. Но причины провалов повторяются с поразительной точностью. В этой главе — семь главных публичных провалов цифровой трансформации последних 30 лет с конкретными цифрами, российские «тихие» провалы общими паттернами (без названий — почти все под NDA), и пять корневых причин, которые сходятся в каждом из кейсов.

Если у вас на столе лежит большое коммерческое предложение от подрядчика, эта глава — короткозамыкающее чтение. После неё к КП появится десяток новых вопросов.

Семь главных публичных провалов

Lidl (SAP, €500 млн списано за 7 лет)

Хронология. В 2011 году немецкая розничная сеть Lidl стартовала проект внедрения SAP for Retail на платформе SAP HANA под названием eLWIS — единая система управления товародвижением для всей сети. В 2018 году проект был официально закрыт. Списано — €500 млн. Решение СД (совет директоров): продолжать на старой системе и параллельно начать «более простой» проект.

Что произошло технически. Внедряли SAP for Retail на платформе SAP HANA (не S/4HANA — её к 2011 году ещё не существовало). SAP по умолчанию ведёт инвентаризацию по розничным ценам. Lidl исторически вёл инвентаризацию по закупочным ценам — это была одна из основ их конкурентного преимущества (точная видимость маржи на каждой позиции в каждом магазине в реальном времени). Под этот специфический процесс понадобилась глубокая кастомизация коробки. Кастомизация конфликтовала с обновлениями платформы, и обновления переставали ставиться. Через 5 лет проекта ландшафт стал неподдерживаемым.

Что произошло организационно. К моменту, когда стало очевидно, что архитектурное решение неверно, было уже потрачено около €100 млн. Внутри Lidl не нашлось людей, готовых сказать «всё, останавливаемся». Каждый следующий год добавлял по €50–100 млн «давайте довнедрим — мы уже близко». В 2018 СД приняло болезненное решение списать всё.

Корневая причина. Кастомизация коробки под старые процессы вместо реинжиниринга старых процессов под коробку. Это и есть антипаттерн № 1 ERP-внедрений.

Урок. Если ваш процесс настолько уникален, что под него надо переписывать половину ERP — спросите: является ли этот процесс конкурентным преимуществом или это исторически сложившаяся специфика? Если первое — стройте своё ПО. Если второе — меняйте процесс.

Источник: Henrico Dolfing — Lidl €500m SAP debacle.

Hershey (SAP одномоментный запуск всего сразу, $150 млн потерянных продаж к Хэллоуину)

Хронология. В 1996–1999 кондитерская компания Hershey внедряла SAP R/3 + Manugistics + Siebel в формате «одномоментный запуск всего сразу» — единовременный запуск всех модулей. Изначальный план — 48 месяцев. По требованию CEO срок был сжат до 30 месяцев, чтобы успеть к запуску новых продуктовых линий. Запуск в эксплуатацию состоялся в середине 1999.

Что произошло. В третьем квартале 1999 — пиковом сезоне (Хэллоуин, начало Рождества) — заказы не отгружались. Заказы поступали, фиксировались в Siebel, передавались в SAP, но из SAP не уходили в склад Manugistics в правильном виде. Магазины не получили товара. Hershey потерял $150 млн упущенных продаж, акции упали на 10 % за квартал.

Что произошло технически. Из-за сжатых сроков было сэкономлено на тестировании интеграций. Конкретно — на тестировании пиковой нагрузки в режиме реального производства. В лабораторных условиях всё работало. В режиме реального высокого сезона — нет.

Корневая причина. Сжатые сроки + экономия на тестировании + запуск перед пиковым сезоном. Каждое из этих решений по отдельности — рискованное. Все три вместе — почти гарантированный провал.

Урок. Никогда не делайте запуск в эксплуатацию перед пиковым сезоном. Никогда не сжимайте сроки за счёт тестирования. Никогда не запускайте «одномоментный запуск всего сразу» при сложности порядка SAP — поэтапно.

Источник: Pemeco — Hershey ERP failure.

Haribo (миграция на S/4HANA, –25 % продаж в 2018)

Хронология. В 2018 году немецкий производитель кондитерских изделий Haribo переходил со старых legacy-систем (некоторые работали с 1980-х) на SAP S/4HANA. Миграция охватывала 16 заводов в 10 странах одновременно.

Что произошло. Supply chain парализован на несколько месяцев. Не работала система заказов, не выходили правильные планы производства, склады не отгружали. По итогам 2018 года продажи флагманской линейки Haribo (мишки Gold Bear) на немецком рынке упали примерно на 25 %.

Корневая причина. Попытка одновременной миграции в 10 странах при том, что legacy-системы между странами не были унифицированы — у каждой страны были свои локальные доработки за 30+ лет. Кроме того, обучение было сжато до минимума: операторы складов и менеджеры по закупкам узнавали о новой системе за 1–2 недели до запуска.

Урок. Если у вас разнородные унаследованные системы в разных филиалах/странах — сначала их унифицируйте, потом мигрируйте. Никогда не делайте параллельную миграцию в 10 странах☺. Поэтапно: страна за страной, контролируя каждый шаг.

Источник: Panorama Consulting — Haribo ERP failure.

FoxMeyer Drug ($100+ млн в проект, банкротство)

Хронология. В 1993 году американский фармацевтический дистрибьютор FoxMeyer (объём продаж ~$5 млрд) начал внедрение SAP R/3 в связке с системой автоматизации склада Pinnacle. В 1996 году FoxMeyer обанкротился. Активы за бесценок ушли конкуренту. Иски: $500 млн к SAP, $500 млн к интегратору Andersen Consulting (Андерсен Консалтинг).

Что произошло технически. SAP R/3 в той версии физически не справлялся с объёмом транзакций FoxMeyer. До внедрения FoxMeyer обрабатывал 420 000 заказов за ночь. После — 10 000. Склад не успевал отгружать. Поставки срывались. Клиенты массово уходили.

Что произошло организационно. Решение о переходе на SAP было принято без полноценного тестирования на масштабах FoxMeyer. SAP того времени был ориентирован на средний бизнес — а FoxMeyer был крупным фармдистрибьютором. Andersen Consulting рекомендовал внедрение, не имея ни одного аналогичного по масштабу референса.

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

Урок. Прежде чем выбрать платформу — проверьте, есть ли публичные кейсы вашего масштаба и типа бизнеса. Если нет — вы пионер, и риски нужно закладывать как у пионера, а не как у «обычного» проекта.

Источник: Lean B2B — FoxMeyer ERP.

Target Canada ($2 млрд убытка, закрытие 133 магазинов)

Хронология. В 2013 году американская розничная сеть Target вышла на канадский рынок, открыв 133 магазина в течение года. Под выход была развёрнута SAP с миграцией данных из систем поставщиков. К 2015 году Target Canada была полностью закрыта, $2 млрд списано.

Что произошло. Полки магазинов либо пустовали, либо были забиты не тем товаром. Магазины открывались, покупатели приходили, а нужного товара не было. Причина — данные о поставщиках, продуктах, упаковках, размерах паллет, объёмах поставки — оказались грязными при миграции. Те поставки, которые в системе проходили как «100 коробок по 12 единиц», физически приходили как «50 коробок по 24 единицы». Распределение по магазинам считалось неверно.

Что произошло организационно. Команду внедрения сжали по срокам. Целевой запуск был «к рождественскому сезону 2013» — пиковому сезону. Чистка мастер-данных была отложена «на потом». «Потом» так и не наступило.

Корневая причина. Грязные мастер-данные при миграции + жёсткие сроки запуска перед пиком сезона + отсутствие отката («магазины уже открыты»). Это идеальный шторм для разрушения цепочки поставок.

Урок. Никогда не запускайте новую инфраструктуру при одновременном изменении масштаба бизнеса (открытие новой страны, выход на новый рынок). Сначала отработайте инфраструктуру на стабильном периметре, потом масштабируйте.

Источник: Medium — Target Canada ERP failure.

Boeing 737 MAX ($20+ млрд, две катастрофы)

Хронология. В 2017 году Boeing вывел на рынок 737 MAX. В 2018 и 2019 произошли две катастрофы (Lion Air, Ethiopian Airlines, 346 погибших), причина — система MCAS, основанная на показаниях единственного датчика угла атаки. Boeing потерял $20+ млрд прямых убытков, на годы был остановлен выпуск самолёта.

Почему этот кейс в книге про цифровую трансформацию. Потому что MCAS — это программная система. И решения по архитектуре MCAS — это решения по цифровой трансформации авиапромышленности.

Что произошло организационно. Разработка авионики была частично передана на аутсорс программистам по ставке $9/час. Процессы certification были упрощены: для FAA подавалась информация, что MCAS — «незначительная модификация», поэтому пилотам не требовалась обязательная переподготовка на новый самолёт. На самом деле MCAS была критической системой управления.

Корневая причина. Cost-cutting в безопасностно-критичном программном обеспечении. Решение «упростить и удешевить разработку» — на тех системах, где упрощение прямо ведёт к гибели людей.

Урок. Цифровая трансформация — это не везде «быстрее, дешевле, гибче». В безопасностно-критичных системах (АСУ ТП (автоматизированная система управления технологическим процессом), медоборудование, энергетика, оборонка) принципы те же, что были до цифровой эры: тщательная разработка, многократное тестирование, культура «остановиться, если что-то не так». Применение agile/lean/минимально жизнеспособная версия (MVP)-логики в АСУ ТП домны — это путь к катастрофе.

Источник: Henrico Dolfing — Boeing 737 MAX.

Российские «тихие» провалы — паттерны

Большинство провальных цифровых трансформаций в РФ — под NDA. Названия компаний я в этом руководстве не упоминаю. Но паттерны — повторяющиеся, и я их назову.

Паттерн А: «Купили коробку, ждали чудо»

Завод (3 млрд выручки, дискретное производство). Купили коробочный MES (система оперативного управления производством) за 25 млн ₽ + внедрение столько же. Через полгода обнаружили, что мастера всё равно ведут смены в Excel и переписывают в систему «постфактум для отчёта». OEE (общая эффективность оборудования) «считается» — но цифра расходится с тем, что считает технолог по бумажным сменным рапортам.

Корневая причина: не назначили владельца процесса, не сделали интеграцию с контроллерами станков (см. пункт «MES без OPC UA (открытый стандарт промышленного обмена данными)» в главе 08), не обучили мастеров до уровня, на котором они могли работать в новой системе быстрее, чем в Excel.

Что списано: 50 млн ₽ + год. Что в итоге: либо переделка с привлечением другого интегратора, либо тихий выход из эксплуатации с формулировкой «вернулись на доказанную методику».

Паттерн Б: «Двойник всего завода»

Холдинг (>30 млрд выручки, промышленный). Решили построить «цифровой двойник предприятия» — в маркетинге это звучало впечатляюще. Заплатили крупному интегратору 300+ млн ₽. Получили красивую 3D-визуализацию завода с потоковыми данными, которая на 90 % дублировала SCADA (диспетчерское управление и сбор данных) и MES, а оставшиеся 10 % — это «прогноз на основе ML (машинное обучение)», не сошедшийся с реальностью.

Корневая причина: «двойник всего» — это маркетинговая концепция, а не инженерное решение. Реальные двойники строятся на конкретный передел (печь, реактор, линия), под конкретный сценарий оптимизации, на качественных данных за 1–3 года. Двойник предприятия в целом — это инструмент презентации, а не управления.

Что списано: 300+ млн ₽. Эффект: близок к нулю.

Маркетинг vs реальность по этому паттерну:

Обещали (маркетинговый лозунг) Получили (реальность)
«Цифровой двойник предприятия — сквозная оптимизация в реальном времени» 3D-визуализация завода, на 90 % дублирующая SCADA и MES; ML-прогноз не сошёлся с реальностью.
«Снизим простои и себестоимость за счёт двойника всего завода» Эффект близок к нулю: двойник строился без конкретного сценария оптимизации и на неподготовленных данных.
«Единая цифровая модель завода для принятия решений» Инструмент презентации, а не управления: решения по-прежнему принимались по SCADA и MES.

Паттерн В: «Сначала Data Lake, потом разберёмся»

Холдинг (15 млрд выручки, дискретное производство). Построили DWH (корпоративное хранилище данных) на 50 млн ₽, сложили туда всё, что было в ERP (система планирования ресурсов предприятия), MES, CRM. Через год обнаружили, что никто данными не пользуется — потому что бизнес-задачи под эти данные не были сформулированы заранее. Затраты на инфраструктуру и поддержку DWH стали постоянным «налогом», а бизнес-эффекта нет.

Корневая причина: «инфраструктура впрок». DWH/Data Lake — это инструмент под конкретные аналитические задачи. Если задач нет, инструмент не нужен.

Что списано: 50+ млн ₽ CAPEX (капитальные затраты) + 5–10 млн ₽/год OPEX (операционные затраты) на поддержку.

Паттерн Г: «Параллельный импорт SAP — наш план»

Завод (8 млрд выручки, химия, объект критическая информационная инфраструктура (КИИ)). SAP S/4HANA внедрён в 2019, после ухода SAP в 2022 — продолжение эксплуатации через «параллельные» каналы поддержки. К 2025 — отсутствие обновлений безопасности больше 2 лет, ушли несколько ключевых SAP-консультантов. По формальным требованиям Указа № 166 — нарушение. Управленческое решение: «пока не проверяют — продолжим».

Корневая причина: откладывание неприятного. План миграции на отечественную ERP — это многолетний болезненный проект на сотни миллионов. Откладывать его «пока работает» — естественная человеческая реакция. Но дедлайн (01.01.2028) — не отменяется, а готовиться к миграции надо за 3 года.

Что будет: либо успеть мигрировать в последний момент с перерасходом и срывами, либо штрафы от Минцифры (3–15 млн ₽, готовится оборотная привязка).

Паттерн Д: «Президент сменился — проект остановлен»

Холдинг. Цифровая трансформация шла 18 месяцев под кураторством сменившегося CEO. Новый CEO — другой взгляд, другие приоритеты, проект «приостановлен» в формулировке, фактически — заброшен. Уже потрачено 200 млн ₽. Эффект — около нуля, потому что проект не дошёл до фазы устойчивой эксплуатации.

Корневая причина: проекты цифровой трансформации длятся 18–36 месяцев. Это сравнимо с типичным сроком CEO в крупной компании. Без поддержки СД (а не только конкретного CEO) проект не выдерживает смену исполнительной власти.

Что списано: 200+ млн ₽. Урок: куратором цифровой трансформации должен быть СД или собственник, а не отдельный исполнительный руководитель.

Пять корневых причин — повторяющиеся в каждом из кейсов

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

Пять корневых причин — повторяющиеся в каждом из кейсов — схема

1. Кастомизация под старые процессы

«Наши процессы уникальны, давайте настроим систему под них» — этот разговор в той или иной форме идёт в каждом ERP-проекте. И в 9 случаях из 10 «уникальные процессы» — это исторически сложившиеся костыли, а не источник конкурентного преимущества.

Антипаттерн: кастомизировать платформу.

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

Исключение: процессы, действительно являющиеся конкурентным преимуществом (например, фирменная методика разработки лекарств у фарм-холдинга). Их кастомизировать — нормально. Но это редкий случай.

2. Сжатые сроки в ущерб тестированию

Сжатие сроков ради «успеть к Q4», «успеть к новому году», «успеть к Хэллоуину» — почти всегда оборачивается провалом запуск в эксплуатацию. Тестирование — последняя статья, которую урезают, и самая дорогая по последствиям.

Правильно: дата запуск в эксплуатацию планируется с запасом 20–30 % к оценке консультантов. Тестирование интеграций и нагрузочное тестирование — обязательны. Запуск в эксплуатацию никогда не делается перед пиковым сезоном.

3. Грязные данные при миграции

50 % компаний недоинвестируют в миграцию данных. И это — главная причина срыва половины ERP-внедрений. Грязные мастер-данные → грязные транзакции → расхождение системы с реальностью → потеря доверия к системе → откат на старые методы.

Правильно: чистка мастер-данных — отдельный проект внутри ERP-проекта, с собственным бюджетом, ответственным и графиком. Не «между делом», не «на ходу».

4. Отсутствие исполнительного куратора

Без CEO/COO (операционный директор)/члена СД, лично отвечающего за проект, проект становится «ИТ-задачей». А ИТ-задача никогда не двигает бизнес-процессы.

Правильно: куратор — это CEO или член СД, не CIO. Его роль — снимать политические блоки между функциями, защищать бюджет, поддерживать приоритет. У куратора должна быть личная заинтересованность в успехе проекта (KPI (ключевой показатель эффективности), опцион, репутация).

5. Игнорирование управление изменениями

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

70 % провалов цифровых трансформаций — из-за людей, не из-за технологий (BCG, 2024).

Подробно — глава 16.

Чек-лист: 10 признаков провалившегося проекта

Если ваш текущий проект цифровой трансформации обнаруживает у себя больше трёх из этих признаков — пора собирать СД на честный разговор.

# Признак Что значит ✓
1 Срок проекта продлевался уже более двух раз Каждое продление — это либо изначально неверная оценка, либо невидимая дыра в архитектуре
2 Бюджет превышен на 30 % и больше Средний overrun 27 %; больше 30 % — это уже за пределами «нормального»
3 На УК проекта не приходит куратор от руководства Без активного куратора проект превращается в ИТ-задачу. Это терминальная стадия
4 Команда меняется 3-й или 4-й раз Уходят сильные, остаются те, кто согласен ещё подождать. Качество падает с каждой итерацией
5 Сроки запуск в эксплуатацию переносятся раз за разом без чётких причин «Не готова интеграция», «не докомплектованы данные», «не доучены пользователи» — это симптомы провала, не отдельные проблемы
6 Регулярно меняется объём работ «Расползание объёма» — главный убийца проектов. 85 % проектов с неконтролируемым расширением объёма работ превышают бюджет
7 Тестирование сжимается каждый раз, когда сжимаются сроки Это то самое решение, которое утопило Hershey. Сжатое тестирование = почти гарантированный провал запуск в эксплуатацию
8 Команда внедрения говорит, а пользователи не слышат Если на демо-показах нет вопросов от пользователей — это не «всё понятно», это «нам всё равно, мы не будем этим пользоваться»
9 Появляются «параллельные» Excel-таблицы у функциональных пользователей Люди не верят системе и подстраховывают её вручную. Это симптом, что данные расходятся с реальностью
10 Внутри компании растёт скепсис «всей этой цифровизации» Самый опасный признак. Скепсис распространяется быстрее, чем результаты, и убивает не только текущий проект, но и следующие

Если три и больше — реалистичный разговор с СД. Возможные сценарии: пересмотр объёма работ, замена команды, перезапуск с другой платформы, в крайнем случае — закрытие проекта с честным разбором причин.

Закрытие проекта — это нормальное управленческое решение. Самая дорогая ошибка — закрытие проекта на год позже, чем стало понятно, что он провален. Lidl потратил €500 млн именно потому, что не остановился на €100 млн.

Связанные главы