Завершение проекта — начало новой неопределённости
— Мы строили, строили
и наконец построили!
Чебурашка
Проект внедрения ERP закончился так, как заканчиваются многие крупные трансформации: с усталостью и одновременно с облегчением. Год напряжённой работы, сложные интеграции, компромиссные архитектурные решения, несколько волн доработок и постоянное давление сроков остались позади. Система запущена, ключевые процессы переведены в новый контур, подрядчики закрыли контракт и передали решение внутренней команде.
Казалось, что самое сложное уже позади - теперь система «своя», команда внутри компании, контроль в руках бизнеса. Логика ожиданий проста: после турбулентности наступит стабильность, а затем — планомерное развитие.
Однако первые месяцы эксплуатации показывают более сложную картину:
- Значительная часть времени уходит не на развитие, а на стабилизацию.
- В реальной работе проявляются сценарии, которые не были полностью учтены в проекте.
- Отдельные интеграции ведут себя нестабильно под нагрузкой.
В некоторых процессах выясняется, что формально описанный регламент расходится с фактической практикой бизнеса, и систему приходится адаптировать уже в рабочем режиме.
Параллельно растёт поток новых запросов. Руководители направлений ожидают, что теперь изменения будут внедряться быстрее, отчётность станет прозрачнее, а управленческие решения — опираться на данные из единой системы. Со стороны ИТ происходящее выглядит как закономерный этап выравнивания: есть список задач, есть релизы, есть движение вперёд. Со стороны бизнеса картина иная. Подрядчики ушли, система запущена, бюджет освоен — но качественного скачка в ощущении управляемости не произошло.
Автоматизация без изменения управленческой модели
— Рубль дал?
— Дал.
— Кефира не было?
— Не было.
— Где рубль?
— Какой рубль?
Ералаш
Через несколько месяцев после запуска ERP финансовый директор поднимает на совещании вопрос: управленческая отчётность по маржинальности направлений не даёт целостной картины. Цифры в системе есть, но на встречах всё равно используются сводные таблицы, которые собираются вручную.
Запрос формулируется чётко: необходимо доработать отчёт по маржинальности, добавить детализацию по проектам, пересобрать алгоритм распределения косвенных затрат и вывести итоговый показатель в единой форме.
Команда ИТ воспринимает задачу как техническую. Формируется ТЗ, перерабатываются запросы к базе, оптимизируются расчёты, добавляются аналитические разрезы. Проводится тестирование. Через несколько недель выходит релиз.
Отчёт стал удобнее. Данные подтягиваются автоматически. Время подготовки к совещанию сокращается. Формально — успех. Однако уже на следующем квартальном обсуждении выясняется, что часть руководителей продолжает использовать свои таблицы. Причина звучит знакомо: «Мы не до конца доверяем распределению затрат», «В нашей специфике расчёт должен быть чуть другим», «Нужно дополнительно корректировать вручную».
В результате на встрече появляются два набора цифр — «по системе» и «по направлению». И снова начинается обсуждение не результата бизнеса, а корректности расчётов.
Почему так происходит? Потому что в ходе доработки отчёта никто не зафиксировал управленческое решение: какой именно показатель является единственной версией правды. Не было согласовано, кто владелец метрики и кто принимает финальную трактовку. Не был пересмотрен сам формат управленческого обсуждения. Система стала считать быстрее и аккуратнее. Но модель управления осталась прежней.
В другом подразделении происходит похожая история. Руководитель продаж жалуется, что данные по воронке в ERP не отражают реальную картину. Инициируется доработка: добавляются статусы, расширяется аналитика, пересобирается отчёт по конверсии. После релиза цифры выглядят детальнее, но обсуждения по-прежнему строятся вокруг субъективных оценок менеджеров.
Проблема не в качестве отчёта. Проблема в том, что KPI по воронке не привязан к системе мотивации. Руководитель отдела оценивается по общему объёму продаж, а не по качеству этапов в ERP. Следовательно, поведение не меняется.
ERP фиксирует данные. Но она не меняет управленческие стимулы. Автоматизация даёт прозрачность только тогда, когда она встроена в управленческий контур:
- когда есть владелец показателя,
- когда зафиксирована методика расчёта,
- когда управленческое решение привязано к данным системы.
Если этого не происходит, доработка превращается в улучшение интерфейса, а не в изменение поведения.
Именно здесь возникает разрыв ожиданий. Бизнес считает, что, инвестировав ресурсы в доработку, он «заплатил рубль» за управляемость. ИТ демонстрирует выполненную работу. Но управленческий эффект не появляется, потому что он не может возникнуть только за счёт технического изменения.
ERP способна обеспечить данные. Но управляемость возникает только тогда, когда эти данные становятся обязательной основой решений. Без этого система остаётся источником информации, а не инструментом управления.
Реактивная приоритизация вместо стратегического фокуса
— Почему мне всегда достаётся не то, что я хочу?
— А чего ты хочешь?
— Ну… не знаю.
Анекдот
Когда система стабилизируется, начинается этап «развития». И именно здесь проявляется следующая закономерность. Инициативы появляются из разных направлений почти одновременно.
Финансовый блок просит автоматизировать консолидацию управленческой отчётности. Производство хочет пересобрать планирование, потому что текущий алгоритм «не отражает реальную загрузку». Коммерческий департамент настаивает на доработке интеграции с CRM — иначе менеджеры продолжают работать в параллельных таблицах. Логистика просит переработать отчёт по оборачиваемости.
Каждый запрос обоснован. Каждый подкреплён аргументами. Каждый звучит как «критичный».
На первом этапе команда пытается действовать рационально: задачи оцениваются, формируется очередь, согласовываются сроки. Начинается работа над крупной инициативой — например, переработкой механизма планирования производства. Проект рассчитан на три месяца. Архитектура затрагивается аккуратно, предполагается улучшить точность прогноза и сократить ручные корректировки.
Через месяц появляется срочный запрос от финансов: необходимо внести изменения в модель расчёта маржинальности к квартальному закрытию. Это связано с требованиями руководства. Задача получает высокий приоритет. Часть команды переключается.
Работа по планированию замедляется, но продолжается.
Спустя ещё несколько недель коммерческий блок инициирует доработку интеграции с CRM. Аргумент звучит убедительно: без корректных данных воронка продаж искажается, а значит, управленческие решения принимаются на неполной информации. Запрос снова признаётся важным.
Команда снова перераспределяется. Формально всё выглядит логично. Никто не принимает иррациональных решений. Каждый раз речь идёт о действительно значимых задачах. Но через полгода становится заметно, что ни одна из крупных инициатив не дала ощутимого эффекта.
Механизм планирования так и не был доведён до устойчивого состояния — его дорабатывали фрагментарно. Модель маржинальности внедрена, но параллельно продолжает использоваться старая версия расчёта «для проверки». Интеграция с CRM улучшена, но часть данных по-прежнему корректируется вручную.
При этом команда всё время занята. Релизы выходят. Задачи закрываются. В отчётах отражается движение. На уровне ощущений возникает странный парадокс: активности много, результата мало. Разбор ситуации показывает, что проблема не в качестве работы и не в компетенциях. Проблема в том, что у компании не было зафиксировано стратегического фокуса на период. Не было ответа на простой вопрос: что именно должно измениться в ближайшие шесть месяцев?
Если бы целью квартала было, например, сокращение производственного цикла на 10%, то приоритизация выглядела бы иначе. Инициативы, не влияющие напрямую на этот показатель, могли бы быть отложены. Если бы целью было повышение точности управленческой маржи, переработка планирования могла бы временно уступить приоритет. Но без явной рамки каждый аргумент звучит одинаково убедительно. В результате приоритизация становится реакцией на текущую управленческую боль. Срочность начинает подменять стратегическую важность. Команда живёт в режиме постоянного переключения контекста, а бизнес — в ощущении, что «всё делается, но ничего кардинально не меняется».
Именно здесь проявляется принципиальный момент: приоритет — это не список важных задач. Приоритет — это отказ от остальных задач. Пока этот отказ не оформлен осознанно и публично, компания будет продолжать двигаться фрагментарно, даже имея современную ERP и сильную команду.
Накопленный технический долг как фактор снижения скорости
— Доктор, помогите, печень болит.
— Одеколон пьёте?
— Пью. Не помогает…
Анекдот
Решения, принятые под давлением сроков проекта, начинают проявлять свои ограничения постепенно. Во время внедрения допустимо пойти на компромисс: реализовать интеграцию быстрее, упростить архитектуру, отложить оптимизацию. Главное — обеспечить запуск. Проект живёт сроками. Если нужно выбрать между идеальной архитектурой и соблюдением дедлайна, почти всегда выбирается второе. Интеграцию делают «временно напрямую». Отчёт пишут без оптимизации. Логику распределения затрат реализуют в одном месте, чтобы успеть к запуску, с мыслью «потом аккуратно переработаем».
Во время проекта это не ошибка. Это управленческое решение. Проблема начинается позже — когда «потом» так и не наступает.
Через полгода после запуска в компании появляется запрос на доработку механизма резервирования товара. Задача на первый взгляд локальная: изменить алгоритм так, чтобы приоритет отдавался заказам с предоплатой. Оценка — две недели. Однако в ходе анализа выясняется, что текущий механизм резервирования связан с логикой складского учёта, которая в проекте была реализована упрощённо. В свою очередь, складская логика напрямую влияет на расчёт себестоимости, а тот — на управленческую отчётность. Команда начинает аккуратно вносить изменения. В процессе всплывает, что в одном из модулей используется дублирующая логика распределения остатков, созданная «на время» во время проекта. Её приходится учитывать, чтобы не нарушить текущие процессы.
В итоге доработка, рассчитанная на две недели, занимает шесть. Не потому, что разработчики ошиблись в оценке. А потому что система стала сложнее, чем кажется на поверхности. Это и есть технический долг.
Он не всегда выражается в «плохом коде». Он проявляется в избыточных зависимостях, в дублирующих механизмах, в временных решениях, которые стали постоянными. В отсутствии архитектурной целостности, которую невозможно было обеспечить в рамках проектных сроков. Снаружи бизнес видит замедление. Внутри команда видит усложнение. Каждая новая инициатива требует всё больше анализа и проверки. Любой релиз становится более рискованным. Повышается чувствительность к изменениям. И в какой-то момент скорость разработки начинает снижаться даже при сохранении той же численности команды. Реакция руководства часто предсказуема: нужно усилить контроль. Добавить больше тестирования. Ввести дополнительные регламенты. Возможно, увеличить команду. Но это напоминает ситуацию из анекдота. Усилия увеличиваются, а улучшения не происходит. Потому что проблема не в интенсивности работы, а в структурном ограничении системы.
Технический долг редко выносится на уровень управленческой дискуссии. Его сложно показать в цифрах. Он не отражается напрямую в P&L. Однако он влияет на ключевой показатель — скорость изменений. А скорость изменений — это конкурентоспособность. Если доработка занимает шесть недель вместо двух, компания медленнее реагирует на рынок. Если релизы становятся более рискованными, бизнес осторожнее инициирует изменения. Если архитектура хрупкая, команда начинает избегать сложных инициатив. Постепенно система, созданная для повышения управляемости, начинает её ограничивать.
В этот момент роль Head of IS снова выходит за пределы технического управления. Необходимо не просто «чинить» отдельные участки, а осознанно признать технический долг как управленческий фактор. Зафиксировать его объём, определить приоритеты его снижения, объяснить бизнесу, почему часть ресурса направляется не на новые функции, а на повышение устойчивости. Без этого ERP превращается в систему, которая формально работает, но с каждым месяцем всё тяжелее адаптируется к новым требованиям. И именно тогда возникает ощущение: мы вложили силы, внедрили систему, а двигаться быстрее не стали.
Попытка лечить симптомы вместо определения направления
— Давайте отрубим Сусанину ногу!
— Постойте, ребята, я вспомнил дорогу.
Народное творчество
Когда компания не ощущает управляемости, это редко формулируется прямо. Обычно звучат другие фразы:
«Почему так долго?»
«Почему каждый раз оценки растут?»
«Почему отчёты снова нужно перепроверять?»
«Почему нельзя просто сделать быстрее?»
На этом этапе напряжение уже есть, но его источник ещё не определён.
Руководство видит симптомы:
— сроки сдвигаются;
— задачи “в работе” накапливаются;
— бизнес продолжает использовать Excel;
— команда ИТ просит дополнительные ресурсы или время на стабилизацию.
Естественная реакция — усилить контроль. Появляются дополнительные статусы в отчётах. Учащаются встречи. Запрашиваются более детальные оценки. Вводятся новые регламенты согласования. Иногда принимается решение «добавить людей», чтобы ускорить поток задач. С точки зрения логики это выглядит разумно. Если процесс буксует — его нужно дисциплинировать. Но если причина не в дисциплине, эффект оказывается обратным.
Например, в одной компании после серии сдвигов сроков было принято решение проводить еженедельный комитет по приоритетам с участием всех ключевых руководителей. Идея заключалась в том, чтобы оперативно принимать решения и ускорять движение задач.
Фактически произошло другое - каждое подразделение начало активно продавливать свои инициативы на комитетах. Появилась необходимость готовить обоснования, презентации, расчёты. Время на подготовку к совещаниям выросло. Команда ИТ стала тратить значительную часть ресурса на объяснение оценок и перерасчёт сроков под новые вводные. Количество решений увеличилось. Скорость реализации — нет. Потому что обсуждались не цели, а задачи. Не направление движения, а очередность конкретных доработок.
В другой ситуации руководство, недовольное качеством данных, потребовало ввести дополнительный уровень проверки перед каждым релизом. Формально риск снижался. Фактически время вывода изменений в эксплуатацию увеличилось, а команда стала осторожнее предлагать архитектурные улучшения — слишком высока стала цена ошибки.
Система становилась более зарегулированной, но не более управляемой. Лечение симптомов всегда направлено на видимую проблему: задержки, ошибки, несогласованность. Но если не определено направление движения — какие именно показатели должны измениться и в какой последовательности — усиление контроля лишь увеличивает нагрузку на систему.
В этот момент особенно важен управленческий разворот. Head of IS оказывается в сложной позиции. С одной стороны, от него ожидают ускорения и стабильности. С другой — он видит, что корень проблемы не в количестве встреч и не в детализации отчётов.
Корень в отсутствии зафиксированного вектора. Пока не определены 2–3 ключевые цели на период, пока не согласовано, какие инициативы являются стратегическими, а какие — вторичными, любые усилия по “оптимизации процесса” будут работать поверх хаотичной модели. И тогда система начинает напоминать организм, который лечат от симптомов, не поставив диагноз.
ERP не может сама определить маршрут. Она лишь обеспечивает инфраструктуру.
Направление задаётся управленческим решением — что именно компания хочет изменить в ближайший горизонт времени, и какие компромиссы она готова принять ради этого. Без такого решения можно долго усиливать контроль, добавлять регламенты и наращивать отчётность — и при этом продолжать ощущать, что управляемости больше не стало.
Переход от проекта к системной модели управления
Король умер.
Да здравствует король.
Французская поговорка
Проект завершён. Это всегда ощущается как финал. Есть точка запуска, есть зафиксированный результат, есть усталость команды и облегчение руководства. В проектной логике всё понятно: цель достигнута, система внедрена. Но именно здесь происходит самый незаметный и самый сложный переход. Пока шёл проект, управление строилось вокруг события - был план-график, бюджет, контрольные точки, была централизованная мобилизация ресурса, была единая цель — запустить систему, после запуска эта конструкция исчезает. Нет больше чёткой финишной линии, нет общего дедлайна, вокруг которого выстраивается дисциплина. Появляется поток инициатив — разнонаправленных, разной важности, разной срочности. Система начинает жить в режиме постоянных изменений.
Если в этот момент не возникает новая модель управления, компания остаётся в подвешенном состоянии: проект завершён, а операционная логика ещё не сформирована. Именно здесь меняется роль Head of IS - во время внедрения он управляет поставкой решения. Он отвечает за соблюдение сроков, за коммуникацию с подрядчиками, за минимизацию рисков запуска - его зона ответственности — довести систему до состояния «работает».
После запуска его зона ответственности смещается - теперь он управляет не проектом, а траекторией изменений. Это принципиально другой уровень. Он должен задать рамку: какие цели являются приоритетными в горизонте квартала или года, не список задач, а именно цели — сокращение цикла закрытия месяца, повышение точности планирования, снижение доли ручных операций, ускорение вывода продукта на рынок.
Далее — связать инициативы с этими целями. Если доработка не влияет на выбранный показатель, она либо откладывается, либо осознанно получает более низкий приоритет, это всегда болезненно, потому что требует отказа.
Параллельно необходимо определить архитектурные принципы, которые нельзя нарушать ради краткосрочной выгоды. Если в проекте допустимы компромиссы ради запуска, то в операционной фазе их цена выше - архитектура становится стратегическим активом.
Кроме того, технический долг должен быть выведен из тени. Пока он не признан как управленческий фактор, он будет восприниматься как «медлительность ИТ», но если он формализован — оценён, описан, включён в план развития — он становится частью осознанной стратегии.
Самое сложное — изменить характер коммуникации с бизнесом. Разговор перестаёт строиться вокруг отдельных задач - он строится вокруг направления. Вместо «когда будет эта доработка?» появляется вопрос «как это влияет на наши цели?», вместо «почему так долго?» — «какой компромисс мы готовы принять ради ускорения?».
ERP сама по себе не создаёт управляемость, она создаёт инфраструктуру, в которой управляемость может быть построена. Переход от проекта к системной модели — это не техническое действие, это управленческое решение. Решение зафиксировать вектор, принять ограничения и публично обозначить логику развития. Если этот переход не происходит, компания продолжает жить в проектной логике — бесконечно внедряя улучшения, реагируя на запросы и усиливая контроль.
Если он происходит — ERP перестаёт быть просто системой учёта и становится инструментом управления изменениями. Внедрение — это событие, системная модель управления — это процесс.
И именно этот процесс становится зоной ответственности Head of IS.
