ERP-система стоит, месяцы пройдены, но ощущение контроля не появилось. Задачи закрываются, "ручные" отчеты уменьшаются, а картинка «как живёт бизнес» не стала яснее. Как такое может быть?
В реальности после запуска ERP наступает новая фаза неопределённости. Да, система "своя", подрядчики ушли, команда внутри. Но первые месяцы часто уходят на стабилизацию, а не на развитие:
- Рутине по доработкам и адаптации уходит существенно больше времени, чем ожидалось.
- В бизнес-процессах всплывают сценарии, не учтённые в проекте: например, особые условия поставок или параллельные учёты.
- Интеграции или автозаполнение часто ведут себя нестабильно: в тестовой среде выглядят рабочими, но под реальной нагрузкой начинают тормозить и давать сбои.
- Формальные регламенты расходятся с реальной практикой: частый результат - люди находят обходные пути, потому что "так быстрее".
- Параллельно руководство ждёт, что отчёты сразу станут умнее, а решения начнут опираться на единые данные «из коробки». Но так не происходит по щелчку.
Статистика неутешительна: по данным исследования, 57% компаний сталкиваются с остановками операций после полноценного запуска ERP, а 67,5% так и не получают даже половины планируемых выгод от проекта. Иными словами, фактические проблемы после внедрения - почти рутина.
Автоматизация без изменения управленческой модели
Нередко наблюдается знакомая картина: бизнес заказывает уточнённый отчёт по прибыльности, IT его быстро допиливает, релиз выходит… а руководители продолжают смотреть в старые Excel-таблицы. Почему?
Потому что данные в системе - это только инструменты. Если управленческая модель не меняется, данные не станут «истиной» сами по себе. Важны не просто цифры, а иx контекст и ответственность. Ключевые моменты:
- У каждого показателя должен быть ответственный. Если никто не отвечает за единую версию (распределение затрат, расчёт воронки продаж и т. п.), цифры неизбежно начнут жить «на стороне».
- Утверждённая методика расчёта. Нужен согласованный алгоритм, который устраивает всех (подтверждённый руководством!). Иначе появятся параллельные расчёты в Excel «для проверки» и «на всякий случай».
- Привязка KPI к результатам. Автоматизация не меняет стимулы сама по себе. Например, наивысший KPI руководителя продаж по выручке никак не связан с конверсией этапов, учтённой в системе. Значит, воронка не станет предметом его заботы.
Исследования подтверждают: в пост-ERP фазе удача проекта сильно зависит от качества данных и доверия к ним. Например, американские учёные обнаружили, что на успех ERP влияют точность данных и интеграция системы, а не формальные показатели вроде времени обучения или компетенции ИТ-отдела.
То есть: даже если отчёт работает как часы, он всё равно бесполезен без управленческой привязки. Улучшение ERP-интерфейса без изменения мотивации остаётся только косметикой, а не прорывом вперед.
Реактивная приоритизация вместо стратегического фокуса
Прошли месяцы стабилизации - и начинается вторая агония: погоня за срочными запросами.
Каждый отдел формулирует «КРИТИЧНУЮ» доработку:
- Финансы: «Нужна срочная переработка модели маржинальности к квартальному закрытию!»
- Производство: «Наше планирование не отражает реальную загрузку, надо переделать!»
- Коммерция: «Интеграция с CRM криво работает - менеджеры по-прежнему в таблицах!»
- Логистика: «Переработайте отчёт по оборачиваемости склада!»
Каждый запрос оправдан. Каждый «необходим». И каждый – срочен. Команда пытается оценивать, ставить в очередь… и наваливается лавина оперативных правок.
Через полгода выясняется, что никакая из крупных инициатив не дала прорыва. Планирование так и кромсали по частям, не доведя до конца. Новая модель маржинальности внедрена, но для «галочки» параллельно держат старый расчёт. 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 не в «платформу отчётов», а в настоящий инструмент цифровой трансформации.
WWW.АТОМСОФТ.РФ