ГЛАВА 02
Чек-лист готовности предприятия
Маршрут внедрения · Этап 2 из 10 — чек-лист готовности. Предыдущая контрольная точка: определён уровень зрелости. Следующая контрольная точка: решение – «догоняющие» работы.
Самая дорогая ошибка цифровой трансформации — стартовать большой проект, к которому предприятие организационно не готово. Технический долг можно потом исправить, ИТ-команду докомплектовать, выбранную платформу заменить. А вот провал большого проекта из-за «мы оказались не готовы» оставляет два следа: списанные деньги и устойчивое недоверие к цифровой трансформации на годы вперёд. Второе хуже первого.
Чек-лист в этой главе — 50 пунктов по пяти областям: бизнес, процессы, данные, ИТ-инфраструктура, люди. Каждый пункт — это «обязательное предусловие», без которого нет смысла стартовать соответствующий тип проекта. Если по какой-то области у вас провал больше 30 %, начинать большой проект в смежной области — это решение «купить дорогой кофе и забыть его на стойке».
Чек-лист универсальный — подходит и под ERP-проект, и под MES (система оперативного управления производством) + IIoT (промышленный интернет вещей), и под цифровой двойник, и под машинное зрение. Конкретные точечные чек-листы под отдельные классы проектов есть в главах 07–12.
Область 1. Бизнес: 10 пунктов
Готовность бизнеса — это в первую очередь готовность собственника и СД (совет директоров) отвечать на проект деньгами, временем и вниманием. Технология не закрывает дыры в бизнесе, она их подсвечивает.
| # | Пункт | Что проверять | Если нет | ✓ |
|---|---|---|---|---|
| 1 | Стратегия компании сформулирована и письменно зафиксирована | Документ в СД, не презентация на флешке у CEO | Сначала стратегия, потом цифровизация. Цифровизация без стратегии — это покупка инструментов без понимания, что строим | |
| 2 | Связь цифрового проекта с конкретной бизнес-целью | «Снижение себестоимости на N %», «выход на новый рынок», «сокращение оборотного капитала на N млрд» — а не «общая цифровизация» | Уберите слово «цифровая» из бюджетной заявки. Если без него нечего сказать — проекта нет | |
| 3 | Целевые KPI (ключевой показатель эффективности) цифрового проекта определены и измеримы | OEE (общая эффективность оборудования) × N п.п., FPY (выход годного с первого предъявления) × N п.п., оборачиваемость склада × N %, MTBF (среднее время между отказами) × N %, время выпуска КД × N % — с числом и сроком | Без числа в KPI — это пожелание, не цель. СД должен понять «успех» однозначно через 18 месяцев | |
| 4 | Куратор от руководства назначен и активен | CEO или член СД лично участвует в УК проекта не реже раза в месяц | По BCG (2024) ~65-75 % цифровых трансформаций не достигают целей; главная причина — «people dimension», включая отсутствие исполнительного куратора. Без него проект превращается в ИТ-задачу | |
| 5 | Бюджет цифровой трансформации защищён на 3 года | Не «годовой бюджет с пересмотром каждый год», а среднесрочное обязательство | Большинство проектов рассчитаны на 18–36 месяцев. При ежегодном пересмотре проект сдохнет на 2-м году от «давайте сэкономим» | |
| 6 | Готовность СД к итерациям и пересмотру | Решения изменяемы, проект не закопан в первоначальное ТЗ | Цифровая трансформация — это не строительство моста. По дороге будут открытия, корректировки и переоценки | |
| 7 | Бизнес-кейс сделан с учётом TCO (совокупная стоимость владения), не «голого CAPEX (капитальные затраты)» | Лицензии + внедрение + инфра + обучение + сопровождение + апгрейды + стоимость выхода | См. главу 15. Голый CAPEX занижает реальные затраты в 1,5–2,5 раза | |
| 8 | Решены вопросы господдержки и финансирования | Заявка в ОЗП (особо значимый проект)/ИЦК (индустриальный центр компетенций), или заём ФРП (Фонд развития промышленности), или собственные средства — но решение принято до старта | Если в середине проекта планируется «получить грант» — почти наверняка не получим, а проект уже идёт | |
| 9 | Защита проекта перед СД отработана как стандартный процесс | Раз в квартал — отчёт, формат фиксирован, метрики не меняются под результат | Если СД каждый раз требует «новый формат отчёта» — проект тонет в коммуникации, не в работе | |
| 10 | Готовность «убить проект» при срыве KPI | СД явно понимает условия, при которых проект сворачивается | Проект, который нельзя остановить, всегда довнедряется и всегда списывается. См. Lidl (€500 млн за 7 лет) |
Область 2. Процессы: 10 пунктов
Невозможно автоматизировать процесс, который не описан. И невозможно автоматизировать сразу нелогичный процесс — он останется нелогичным, только теперь в системе.
| # | Пункт | Что проверять | Если нет | ✓ |
|---|---|---|---|---|
| 11 | Ключевые процессы описаны и поддерживаются в актуальности | Order-to-Cash, Procure-to-Pay, ТОиР (техническое обслуживание и ремонт), планирование производства — описаны на уровне регламентов | Сначала описать процессы. Без этого внедрение ERP (система планирования ресурсов предприятия)/MES — это автоматизация хаоса | |
| 12 | У каждого ключевого процесса есть один владелец | Имя в оргструктуре, KPI владельца завязан на KPI процесса | «Владелец процесса — все» означает «владелец — никто». Без владельца процесс не меняется | |
| 13 | Декомпозиция процессов до операций | Каждая операция в техмаршруте: норматив, оборудование, оснастка, операторы | Если на одну операцию у разных мастеров разные нормы — ERP/MES будут считать ерунду | |
| 14 | Технологические маршруты документированы и в актуальном состоянии | Не «у Иванова в Excel», а в общем источнике с историей изменений | Без актуальных маршрутов MES не может планировать. Это обычно главная «дыра» среднего машиностроения | |
| 15 | Регламентированный процесс изменения процесса | Когда меняется норма, маршрут, операция — есть формальная процедура | Без процесса изменения процесса любая новая система быстро расходится с реальностью | |
| 16 | Готовность к BPR (реинжинирингу) — психологическая и оргструктурная | Понимание, что внедрение ERP — это перестройка работы, а не покупка ПО | Технический срез: до 70 % провалов ERP-внедрений — попытка «настроить систему под наши процессы» (см. Lidl). Это внутри общей статистики 65-75 % провалов цифровых трансформаций (см. главу 03), где сквозная причина — «люди и процессы», а кастомизация коробки — её главное техническое проявление в ERP | |
| 17 | Процессы согласованы между функциями | Производство, продажи, закупки, финансы — одинаково понимают «выпуск», «отгрузка», «остаток», «себестоимость» | Если в продажах «выпуск» = «отгружено покупателю», а в производстве = «сделано на складе», система не сойдётся никогда | |
| 18 | Уровень формализации соответствует размеру компании | До 1 млрд выручки — лёгкие регламенты; 1–10 млрд — стандарт ISO 9001-уровня; >10 млрд — полное BPM | Избыточная регламентация на маленьком предприятии убивает гибкость, недостаточная — на большом разрушает управляемость | |
| 19 | Понимание узких мест процессов | Где copy-paste, где двойной ввод, где «лишняя» подпись | Без понимания узких мест автоматизация ускоряет не «процесс», а «бардак» | |
| 20 | Регулярный аудит исполнения регламентов | Не разовый «у нас регламенты есть», а проверка раз в полгода | Регламент, который не проверяется, через год уже не соблюдается |
Область 3. Данные: 10 пунктов
Данные — фундамент. На грязных данных любая верхнеуровневая аналитика, ИИ (искусственный интеллект), цифровые двойники — дают результаты с погрешностью больше, чем сам предмет анализа. GIGO (англ. garbage in, garbage out — «мусор на входе — мусор на выходе») — единственная неотменимая истина цифровой трансформации.
| # | Пункт | Что проверять | Если нет | ✓ |
|---|---|---|---|---|
| 21 | Единые мастер-данные | Один код, одно название, одни характеристики у позиции во всех системах | Без MDM (управление мастер-данными) никакая интеграция не работает. Это проект сам по себе — 6–18 месяцев в среднем бизнесе | |
| 22 | Качество мастер-данных: дубликаты, пустые поля, ошибки | Не более 2 % дубликатов, не более 5 % полей с критическими пустотами | См. Target Canada — $2 млрд убытка из-за грязных мастер-данных | |
| 23 | Единая нормативно-справочная информация (НСИ (нормативно-справочная информация)) | Контрагенты, материалы, оснастка, операции — в одном источнике | НСИ в Excel — это техдолг на десятки миллионов рублей при любой миграции | |
| 24 | Качество транзакционных данных | Точность инвентаризации > 98 %, точность остатков в системе ≈ физический остаток | Если в системе 100, а в цеху 87 — система врёт, MES и BI (бизнес-аналитика) на ней врут тоже | |
| 25 | История данных как минимум за 2 года | Истории отказов, истории операций, истории отгрузок, истории закрытия | Без 1–2 лет качественной истории не работают ни PdM (предиктивное обслуживание), ни цифровые двойники, ни ML-аналитика | |
| 26 | Политика управления данными утверждена | Кто отвечает за качество, кто чистит, кто проверяет, кто наказывает за пустые поля | Без ответственности за данные качество деградирует обратно за 6 месяцев | |
| 27 | Регулярная сверка между системой и реальностью | Циклическая инвентаризация, сверка остатков, сверка норм — по графику | Сверка раз в год — это не сверка, это формальность | |
| 28 | Защита от потери данных (резервное копирование, восстановление) | Backup проверен реальным восстановлением хотя бы раз в год | Бэкап, который не восстанавливают, — не бэкап. См. свежие истории с шифровальщиками 2022–2025 | |
| 29 | Готовность к миграции данных | Понимание объёмов, форматов, источников; ответственный за миграцию | 50 % компаний недоинвестируют в миграцию данных. Это причина срыва половины ERP-внедрений | |
| 30 | Соответствие ФЗ-152 по персональным данным | Аудит видеонаблюдения, СКУД (система контроля и управления доступом), биометрии; согласия сотрудников; журналы | С 30.05.2025 штрафы за разовую утечку — до 15 млн ₽ для крупного масштаба (>100 тыс. субъектов); за повторное нарушение — оборотный штраф до 3 % выручки (потолок 500 млн ₽); утечка биометрии — отдельно, 15-20 млн ₽ |
Область 4. ИТ-инфраструктура: 10 пунктов
ИТ-инфраструктура — не самая частая причина провалов, но самая обидная. Когда проект готов запускаться, а сервер не выдержал, и об этом узнали в день запуска в эксплуатацию.
| # | Пункт | Что проверять | Если нет | ✓ |
|---|---|---|---|---|
| 31 | Серверная инфраструктура с запасом на 3 года | Не «впритык под текущую нагрузку», а с учётом роста ×2–3 | Через 6 месяцев после запуска в эксплуатацию MES начнёт тормозить. Покупать серверы «когда уже не хватает» — это месяцы простоя | |
| 32 | Сегментация OT (операционные технологии)/IT (информационные технологии) | Промышленный контур (станки, контроллеры) отделён от офисной сети | Без сегментации Stuxnet-like атаки становятся реальностью. И КИИ-категорирование требует этого формально | |
| 33 | Категорирование КИИ выполнено | Если вы в ТЭК (топливно-энергетический комплекс)/металлургии/химии/ОПК (оборонно-промышленный комплекс)/транспорте — почти всегда вы субъект КИИ. Категория 1/2/3 — определена и согласована с ФСТЭК (Федеральная служба по техническому и экспортному контролю) | См. главу 13. Без категорирования любые работы по защите можно сразу выбросить | |
| 34 | План перехода значимых объектов КИИ на отечественное ПО | Утверждённый план-график до 01.01.2028 (ПО) и 01.12.2030 (ПАК (программно-аппаратный комплекс)) | Минцифры готовит оборотные штрафы. По данным Шадаева (03.2025), треть значимых КИИ уже в просрочке | |
| 35 | СУБД (система управления базами данных) на отечественном решении | Postgres Pro / Tantor / Arenadata для значимых КИИ — до 01.01.2026 | Если ещё Oracle / MS SQL на значимых объектах — это просрочка прямо сейчас | |
| 36 | Сети и каналы связи | Промышленный Ethernet или Wi-Fi 6 в цехах; резервные каналы; SLA | Без сети нет MES, IIoT, машинного зрения. Старый Wi-Fi 4 у конвейера — нет данных | |
| 37 | Информационная безопасность как процесс, не разовая аттестация | SOC (центр мониторинга безопасности) или SIEM (система управления событиями безопасности), регулярный pentest, инцидент-менеджмент | После 2022–2024 атак на промышленность РФ — это операционный риск, не страшилка | |
| 38 | Контролируемый периметр доступа | MFA, журналирование, разграничение прав, регулярный аудит | Любая «удалёнка» без контроля — это потенциальное нарушение Указа № 166 на значимых КИИ | |
| 39 | Понимание текущей зрелости импортозамещения | Карта ПО: что отечественное, что импортное «в эксплуатации», что в плане миграции | См. главу 14. «Серый» SAP/Oracle/Autodesk — это растущий риск, а не актив | |
| 40 | Бэкап-стратегия, тестируемая ежегодно | Не «бэкап делается», а «бэкап восстанавливается из-за резервной площадки» | См. 2025: компании с «бэкапом», который не восстановился, — заголовки СМИ |
Область 5. Люди: 10 пунктов
Главная причина 65–75 % провалов цифровых трансформаций — не технология. Это люди. Управление изменениями подробно разбирается в главе 16; здесь — минимальный «входной билет».
| # | Пункт | Что проверять | Если нет | ✓ |
|---|---|---|---|---|
| 41 | CDTO (директор по цифровой трансформации) в оргструктуре | Полноценная должность с прямым подчинением CEO или СД, не совместительство секретаря | Совмещение CDTO с другой ролью — это сигнал, что компания не серьёзна про трансформацию | |
| 42 | CIO (ИТ-директор)/CTO (технический директор) технически и стратегически зрелый | Не «сисадмин старший» — а руководитель, говорящий с бизнесом на языке P&L (отчёт о прибылях и убытках) | См. главу 05. Без зрелого ИТ-лидера выбор стека отдаётся подрядчику — со всеми вытекающими | |
| 43 | Владельцы процессов назначены, мотивированы, в курсе проекта | KPI владельцев процессов привязан к KPI проекта | Без вовлечения владельцев процессов проект делается «для ИТ», и в эксплуатацию не уходит | |
| 44 | Проектный офис или равноценная функция | Управление сроками, бюджетом, рисками, статус-отчётность — централизованно | Без проектного офиса 6–8 параллельных потоков работ превращаются в хаос за 3 месяца | |
| 45 | Внутренняя ИТ-команда с критической массой | Не один сисадмин на 500 АРМ; архитектор, бизнес-аналитик, аналитик данных — в штате или как минимум на договорах | Полная зависимость от подрядчика = аренда сервиса, а не актив | |
| 46 | План найма ключевых ролей на 12 месяцев | CDTO, MES-инженер, архитектор данных, ML-инженер — кто, когда, по каким каналам, бюджет | См. реалии рынка 2025–2026: год найма CDTO — нормальный срок | |
| 47 | План обучения существующего персонала | Не «обучили один раз при запуске в эксплуатацию», а программа: техкарты, тренажёры, наставничество, аттестация | Без обучения мастера и операторы не пользуются новой системой. Все KPI остаются на бумаге | |
| 48 | Готовность среднего менеджмента к прозрачности | Цифровые системы делают видимым то, что было скрыто (перетекание простоев между сменами, реальный брак, скрытые перетекания запасов) | Если средний менеджмент не готов к прозрачности, он саботирует проект. Тихо и компетентно | |
| 49 | Программа поощрения активных пользователей | Премии за реальное использование системы, рейтинги, конкурсы | Без поощрения уровень использования системы < 60 % через 6 месяцев, проект формально работает, фактически — нет | |
| 50 | Программа коммуникации проекта | Раз в месяц — сообщения о ходе, успехах, проблемах; ясные ответы на «что это значит для меня» | Информационный вакуум = домыслы = сопротивление |
Сводный результат
Сложите баллы (по 1 за каждый «да») по областям:
| Область | Баллов из 10 | Что значит |
|---|---|---|
| Бизнес | 0–4 | Бизнес не готов. Любой большой проект превратится в политическую борьбу |
| Бизнес | 5–7 | Готов с оговорками. Закрыть провалы до старта |
| Бизнес | 8–10 | Готов. Можно запускать |
| Процессы | 0–4 | Не готов. Сначала описать и упорядочить процессы |
| Процессы | 5–7 | Готов с оговорками. Начать с лёгких блоков (BI, базовый учёт), параллельно — описание процессов |
| Процессы | 8–10 | Готов. Можно идти в ERP/MES |
| Данные | 0–4 | Критический провал. Без чистых данных любая трансформация буксует |
| Данные | 5–7 | Готов с оговорками. MDM и НСИ — в первую волну параллельно |
| Данные | 8–10 | Готов. Можно строить аналитику и ML (машинное обучение) |
| ИТ-инфраструктура | 0–4 | Не готов. Сначала базовая инфра, КИИ, ИБ |
| ИТ-инфраструктура | 5–7 | Готов с оговорками. Уточнить КИИ-категорирование и план импортозамещения |
| ИТ-инфраструктура | 8–10 | Готов |
| Люди | 0–4 | Не готов. Без команды и владельцев процессов — это лотерея |
| Люди | 5–7 | Готов с оговорками. Параллельно — найм и управление изменениями |
| Люди | 8–10 | Готов |
Что делать с провалами
Схема ниже — это продолжение чек-листа готовности (50 пунктов выше), а не отдельный инструмент. «Блокеры» — это области, набравшие 0–4 балла (провалы): именно они определяют, можно ли вообще запускать большой проект. Как пользоваться: посчитайте число провалов (0–4) и оговорок (5–7) по пяти областям, затем по схеме выберите один из четырёх сценариев и идите по его шагам — нет провалов и оговорок → сценарий A; есть оговорки → B; провал в одной области → C; провал в двух и более → D (большой проект не стартуем, сначала 6–12 месяцев догоняющих работ). Конкретные шаги по каждому сценарию — сразу под схемой.
Главное правило: если у вас провалы (0–4 балла) в двух или более областях, не запускайте большой проект. Это не «осторожность», это математика: вероятность успеха при двух провалах падает с ~30 % (базовая статистика BCG) до ~10 %.
Закройте провалы за 6–12 месяцев. Это сэкономит сотни миллионов рублей в будущем проекте. Большинство «провальных трансформаций» из главы 03 — это случаи, когда стартовали при двух-трёх провалах в чек-листе, надеясь «выправить по ходу».
«По ходу» так не выправляется.
Что делать дальше: четыре сценария
Ваша ситуация. Чек-лист готовности пройден; известно число провалов (0–4 балла) и оговорок (5–7).
Сценарий A — нет провалов и оговорок. Зафиксировать исходные значения KPI, утвердить устав Волны 1, запустить выбор ERP/MES (главы 06–07). Контрольная точка: бюджет Волны 1 одобрен ЛПР.
Сценарий B — есть оговорки (5–7). Завести реестр оговорок с дедлайнами и владельцами, стартовать основной проект параллельно. Контрольная точка: ни одна оговорка не блокирует запуск в эксплуатацию.
Сценарий C — провал в одной области (0–4). 3–6 месяцев на устранение с измеримой метрикой, затем переоценка этой области. Контрольная точка: область выросла до ≥ 5 баллов.
Сценарий D — провал в 2+ областях. Не стартовать большой проект; программа догоняющих работ 6–12 мес (НСИ, куратор, инфраструктурный минимум). Контрольная точка: переоценка через 6–12 мес.
Артефакт на выходе. Заполненный чек-лист, выбранный сценарий и план устранения / догоняющих работ (если нужен).
Компания А. Сценарий C: 4 месяца на НСИ и инвентаризацию остатков (цель — расхождение < 1 %), затем старт Волны 1.
Минимальный набор «не стартовать без»
Если из 50 пунктов нужно выделить самые критичные, без которых вообще нельзя стартовать большой проект — это 7 пунктов:
- № 1 — стратегия зафиксирована
- № 4 — куратор от руководства активен
- № 12 — у процессов есть владельцы
- № 21 — единые мастер-данные есть или в первой волне
- № 33 — критическая информационная инфраструктура (КИИ)-категорирование сделано
- № 41 — CDTO в оргструктуре
- № 43 — владельцы процессов в проекте
Если что-то из этих семи отсутствует — никакого большого проекта. Сначала закрыть, потом стартовать.
Связанные главы
- 01. Зрелость и диагностика — оценка текущего уровня, прежде чем приступать к чек-листу.
- 03. Антипаттерны и провалы — как выглядят последствия игнорирования чек-листа.
- 05. Команда и роли — детально по пунктам 41–50 (люди).
- 13. Архитектура, безопасность, КИИ — детально по пунктам 32–40 (инфраструктура).
- 16. Управление изменениями — детально по пунктам 46–50 (адаптация).