ERP внедрили. А управляемости всё равно нет: что происходит?

В реальности после запуска ERP наступает новая фаза неопределённости. Да, система "своя", подрядчики ушли, команда внутри. Но первые месяцы часто уходят на стабилизацию, а не на развитие:

• Рутине по доработкам и адаптации уходит существенно больше времени, чем ожидалось.

• В бизнес-процессах всплывают сценарии, не учтённые в проекте: например, особые условия поставок или параллельные учёты.

• Интеграции или автозаполнение часто ведут себя нестабильно: в тестовой среде выглядят рабочими, но под реальной нагрузкой начинают тормозить и давать сбои.

• Формальные регламенты расходятся с реальной практикой: частый результат - люди находят обходные пути, потому что "так быстрее".

• Параллельно руководство ждёт, что отчёты сразу станут умнее, а решения начнут опираться на единые данные «из коробки». Но так не происходит по щелчку.

Статистика неутешительна: по данным исследования, 57% компаний сталкиваются с остановками операций после полноценного запуска ERP, а 67,5% так и не получают даже половины планируемых выгод от проекта. Иными словами, фактические проблемы после внедрения - почти рутина.

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

Если управленческая модель не меняется, данные не станут «истиной» сами по себе. Важны не просто цифры, а иx контекст и ответственность.

Ключевые моменты:

• У каждого показателя должен быть ответственный. Если никто не отвечает за единую версию (распределение затрат, расчёт воронки продаж и т. п.), цифры неизбежно начнут жить «на стороне».

• Утверждённая методика расчёта. Нужен согласованный алгоритм, который устраивает всех (подтверждённый руководством!). Иначе появятся параллельные расчёты в Excel «для проверки» и «на всякий случай».

• Привязка KPI к результатам. Автоматизация не меняет стимулы сама по себе. Например, наивысший KPI руководителя продаж по выручке никак не связан с конверсией этапов, учтённой в системе. Значит, воронка не станет предметом его заботы.

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

То есть: даже если отчёт работает как часы, он всё равно бесполезен без управленческой привязки. Улучшение ERP-интерфейса без изменения мотивации остаётся только косметикой, а не прорывом вперед.

Прошли месяцы стабилизации - и начинается вторая агония: погоня за срочными запросами.

Каждый запрос оправдан. Каждый «необходим». И каждый – срочен. Команда пытается оценивать, ставить в очередь… и наваливается лавина оперативных правок.

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

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

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

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

Исследования показывают, что технический долг реально тормозит команды:

• Разработчики в среднем тратят ~23% рабочего времени на него. Это больше одного дня в неделю!

• По опыту ИТ-директора говорит: у многих организаций основная часть ИТ-бюджета (10-20%) уходит на поддержку и эксплуатацию действующих систем, а не на развитие

Результат накопления долгов: каждый последующий релиз требует всё больше тестирования и анализа, возрастает риск ошибок. Свежий пример: запрос на «поменять алгоритм резервирования (2 недели работы)» может в итоге затянуться на 6+ недель, потому что приходится учитывать старые костыли и перескакивать между модулями.

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

Ещё на этапе стабилизации Head of IS должен оценить его объём, заложить часть ресурсов на рефакторинг и планомерно гасить. Иначе ERP-система со временем превратится в груз, замедляющий любое изменение.

Когда ощущение «неуправляемости» усиливается, топы обычно реагируют так:

• Появляются дополнительные комитеты по приоритетам, еженедельные статусы и уточнения планов.
• Усиливается контроль за оценками и сроками. Все «под прицелом»: отчёты, релизы, любая активность.
• Некоторые пытаются «добавить людей», чтобы скорее закрыть накопившиеся задачи.

Формально кажется, это правильно: если проект буксует - введём больше дисциплины.

Пример: компания ввела обязательные еженедельные собрания топ-менеджмента для разбора ИТ-задач. Инициативы стали обсуждаться на уровне презентаций и обоснований, а команда ИТ тратила 30–50% времени не на код, а на подготовку и отчётность. Решений стало больше, а скорость — нет. Потому что обсуждали «что считать важным», а не куда мы идём.

Подобно тому, как врач лечит симптомы болезни, а не ищет причину, так и усиление регламентов и встреч без стратегического вектора — малоэффективно. Модель управления должна быть определена сверху: какие 2–3 показателя должны измениться и почему. Пока этого нет, любые усилия по «оптимизации процесса» лишь добавляют «помпы без налёва».

Проект ERP завершён - это одновременно финал и начало. Пока шло внедрение, все всё делали ради одной цели: запустить систему. После запуска нет «чёткой финишной черты»: наступает эпоха непрерывных изменений.

Именно здесь меняется роль ИТ директора. Раньше он управлял проектом: контроль сроков, договоры с подрядчиками, сдача этапов. Теперь он отвечает за траекторию развития ERP как бизнес-инструмента:

• Видение и цели. Вместе с руководством задать пару ключевых целей на квартал или год (например, ускорить закрытие месяца, повысить точность планирования, снизить долю ручной работы и т.п.). Не список «что делать», а именно цели развития.

• Приоритизация и отказ. Любая новая доработка должна проверяться: поможет ли она приблизиться к цели? Если нет - её либо откладывают, либо формально отказываются от неё сейчас. (Отказ от того, что не важно, - важнейшая управленческая мера.)

• Архитектурные принципы. Вместе с ИТ-архитекторами зафиксировать, какие решения и подходы являются обязательными и что нельзя делать даже “ради срочности”. То, что в проекте делали «по-быстрому», сейчас превращается в риск. Принципы помогают отделять срочные задачи от стратегических.

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

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

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

Как справедливо заметили эксперты: «Организации, которые получают максимальный ROI от ERP, те, что вкладываются в постоянное улучшение». Сделайте то же: четко определите вектор, расставьте приоритеты и превратите ERP не в «платформу отчётов», а в настоящий инструмент цифровой трансформации.