Где на самом деле ломаются сроки ERP-проектов

Если вы думаете, что ERP затягивается, потому что «айтишники медленно настраивают систему» — спойлер: в половине случаев дело не в них.

Часто проект стопорится на стороне Заказчика по следующим причинам:
~Доступы. Неделю ждём, пока согласуют учётку, чтобы подключиться к базе.
~Согласования. Документ завис на подписи директора, у которого «нет времени».
~Данные. Внезапно выясняется, что половина справочников в Excel, другая половина — в головах сотрудников.

И вот команда сидит на месте, часы тикают, сроки горят — а виноваты «разработчики, которые не успевают».

📌 Что должен сделать руководитель проекта, чтобы не попасть в эту ловушку:

На старте: зафиксировать список критических составляющих для начала проекта, которые нужны от исполнителя и заказчика (доступы, данные, согласования). С конкретными сроками.

Прямо в плане: поставить эти пункты отдельными задачами с ответственными.

Еженедельный контроль: не ждать, пока сроки сорвутся, а бить тревогу, как только что-то идёт дольше пары дней.

Документировать блокеры: если нет доступа или данных — фиксируйте письменно. Это не про «снять ответственность», а про прозрачность.

ERP-проект — это не только про код и настройки. Это про то, как быстро обе стороны двигают мяч вперёд.
А если он застрял на половине поля Заказчика — никакая «допнагрузка команды» Исполнителя не спасёт.

А у вас чаще стопор был на чьей стороне — у Исполнителя или у Заказчика?

Лаборатория цифровых решений | @eprlab

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

На нашем канале на #Дзен — разбор, почему это работает и как превращает проект в живой результат.

Лаборатория цифровых решений | @eprlab

«Процессы в голове» — главный враг автоматизации

— «У нас всё и так работает, просто надо автоматизировать».
Слышали такое от бизнеса? Я слышал. И каждый раз понимаю: работать-то оно работает, но только в головах «ключевых людей».

А теперь представьте ERP-систему, в которую никто не заложил реальную логику процессов. Потому что:
— нигде не описано, кто за что отвечает,
— нет границ ролей и маршрутов,
— решения принимаются «по наитию»,
— и всё держится на одном человеке, который «всегда знает, как надо».

Что делает ERP в такой ситуации?
Она фиксирует текущий бардак. Не оптимизирует, не улучшает, не спасает. Просто цифровая копия хаоса.

Автоматизировать неописанный процесс — это как строить дом без проекта: вроде стены стоят, а жить невозможно.

Что делать:
— Документировать ключевые процессы хотя бы на уровне «что делает кто и когда».
— Закрепить роли и границы ответственности — без этого любые статусы в системе будут фикцией.
— И да — обсудить, что не должно попадать в систему, пока не приведено в порядок.

ERP — не решение проблемы.
ERP — тест на зрелость. Если зрелости нет, система это быстро покажет.

Если в компании всё «в голове», не спешите автоматизировать. Сначала — разобрать, структурировать и закрепить. И только потом — настраивать.

Лаборатория цифровых решений | @eprlab

Пилот — не игрушка, а страховка

Иногда заказчик говорит:
— «Да зачем этот пилот, давайте сразу в боевую».
И тут у меня всегда один вопрос: а вы готовы тестировать на живом бизнесе?

Пилот — это не про «поиграться в тестовой базе». Это про то, чтобы снять риски, пока они маленькие и дешёвые.

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

Как убедить заказчика на пилот:
~Говорите языком денег: исправить ошибку на пилоте дешевле в 10 раз, чем после релиза.
~Приведите реальные кейсы: «У нас на пилоте выяснилось, что интеграция с CRM режет половину полей — исправили за неделю, в бою это был бы месяц простоя».
~Сделайте чёткий план пилота: цели, метрики, критерии успешности, сроки.

ERP-проект без пилота — как прыжок в воду с завязанными глазами. Можно нырнуть удачно. А можно — нет.

А вы в своих проектах делаете пилоты или идёте сразу «в боевую»?

Лаборатория цифровых решений | @eprlab

Рамки трансформации: почему ИИ-культура важнее, чем сам инструмент

ИИ в бизнесе уже не экзотика. Он встроен в ERP, CRM и BI-системы, помогает автоматизировать процессы, ускорять аналитику и снижать издержки. Но факт в том, что сами по себе инструменты ничего не меняют.

Главный барьер — корпоративная культура.
Компании, где ИИ используется системно, получают устойчивые результаты. Но почти половина проектов «умирают» на пилотах, потому что люди не доверяют системе, боятся перемен или продолжают работать «по-старому».

ERP сегодня может быть не просто учётом, а ядром цифрового мышления. Но чтобы это заработало, нужно:
— обучать сотрудников работать с данными,
— встроить цели ИИ в стратегию,
— создавать доверие к результатам через прозрачность и понятные юзкейсы.

ИИ даёт шанс радикально пересобрать процессы, а не просто «ускорить рутину». Но для этого компании нужны новые стандарты — AI-культура, а не только новый модуль в ERP.

Лаборатория цифровых решений | @eprlab

Источник

Когда заказчик сам тормозит дедлайн
Почему «давайте быстрее» оборачивается вечными согласованиями — и как с этим работать

Ситуация знакома:
На старте переговоров заказчик настаивает:
«Нужно внедрить срочно, времени нет!»

Команда напрягается, поджимает сроки, строит план под жёсткий дедлайн…
А потом начинается:
— «А давайте добавим ещё один вариант отчёта»
— «А согласуем с юристами… потом»
— «А тут лучше перепишем под другой процесс»

Время идёт, задачи множатся, решения откладываются.
В итоге дедлайн всё тот же, а объём работ — в полтора раза больше.

Что это создаёт:
— Постоянное давление на команду.
— Риск получить «сырой» результат из-за спешки в конце.
— Потерю доверия между исполнителем и заказчиком.

Что с этим делать:

Управление изменениями
— Формально фиксируйте каждый новый запрос.
— Оценивайте его влияние на сроки и бюджет.
— Не внедряйте изменения без согласования через установленную процедуру.

Проектный комитет + устав проекта
— Создайте орган, который принимает ключевые решения по проекту.
— Опирайтесь на устав проекта: цели, границы, роли, сроки.
— Любое изменение — только после одобрения комитета.

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

Внедрение — это не только про «успеть», но и про «успеть правильно».
Если заказчик хочет и быстрее, и по-другому, он должен понимать цену такого выбора.

Лаборатория цифровых решений | @eprlab

Внешний ИТ-департамент: больше чем альтернатива

Аутсорс решает только поддержку, но не отвечает за интеграцию и риски.
Внешний ИТ-департамент — это команда вне штата, которая работает как часть бизнеса: с экспертизой, гибкостью и ответственностью за результат.

📌 Читайте нашу новую статью на #Дзен

Лаборатория цифровых решений | @eprlab

Согласовано. Или нет?

На одном из проектов утвердили архитектуру. Формально.
Все участники — ИТ, бизнес, подрядчик — кивнули.
Через месяц — срыв сроков. Почему?

Потому что каждый понял документ по-своему:
🔹 Один считал, что это «черновик для обсуждения»
🔹 Другой — что уже пора запускать разработку
🔹 А третий — вообще не вникал, просто «одобрил», потому что так сказали

С тех пор у меня правило:
Пока человек не может объяснить словами, что мы делаем — он не согласовал, а просто махнул головой.

И это касается не только архитектуры. Это касается вообще всего: целей проекта, ролей, границ, ожиданий.

👀 Формальная подпись — не гарантия понимания.
Гарантия — это когда люди одинаково сформулируют, что именно они приняли.

Лаборатория цифровых решений | @eprlab