Миссия выполнима: как окупить инвестиции в ERP с помощью «быстрых побед»

В основе успешного ИТ-проекта лежат не технологии, а организационные изменения. Разбираем, как превратить развитие учетной системы из статьи расходов в инвестиционный инструмент. Делимся проверенной методикой предпроектного обследования, которая гарантирует возврат инвестиций в ERP-решение. 

Статья будет полезна:

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

В компаниях со штатом более 200 сотрудников мы часто видим одну и ту же проблему. Формально порядок наведен: процессы отрисованы в BPMN, описаны должностные инструкции, зафиксированы KPI. Однако на практике — хаос. Сотрудники вносят данные в учетную систему с опозданием, правят задним числом, и в итоге руководство получает отчетность лишь к 15-му числу следующего месяца.

Регламенты и локальные KPI заставляют сотрудников защищать интересы своего отдела вместо того, чтобы работать на общий результат. Это напоминает басню Крылова «Лебедь, Щука и Рак». Решение — дать команде, от генерального директора до владельцев процессов, целостный взгляд на цели бизнеса.

Исследования доказывают, что около 80% провалов ERP-проектов связаны не с техническими ошибками, а с организационными и управленческими проблемами (Standish Group, PMI, Gartner, McKinsey, Panorama Consulting Group). То есть, даже при наличии зрелых платформ проекты часто буксуют. Почему так происходит?

Слабая проработка бизнес-требований, ошибки планирования проекта и несогласованность действий команды влекут за собой превышение бюджета на 50% или даже 100%, необходимость бесконечных доработок и в конечном счете срыв инициативы.

Помимо этого, в 2026 году реализация ИТ-проектов усложнилась еще несколькими факторами:

1. Урезание бюджетов: защитить финансирование на масштабную автоматизацию становится все сложнее.
2. Импортозамещение: переход на отечественные решения корпоративного сектора, субъектов КИИ и компаний, которые хотят снизить риски остановки бизнеса.
3. Сокращение штата: ИТ-подразделениям необходимо демонстрировать высокую ценность для бизнеса в условиях дефицита ресурсов.
4. Постоянные изменения законодательства: системы требуют регулярной и быстрой адаптации.
5. Прекращение поддержки систем: западные системы уже давно потеряли поддержку вендоров, а исторические продукты вроде «1С:УПП» планомерно выводятся из эксплуатации.

Все это создает серьезные вызовы для топ-менеджмента и ИТ-директоров. По нашему опыту, основная причина — ловушка функциональных «колодцев».

Проследим классический путь формирования требований к проекту. ИТ-департамент запрашивает потребности у всех подразделений. Каждый отдел (финансы, продажи, логистика, производство и так далее) формирует свой список, опираясь на собственные приоритеты. Здесь и возникает эффект «колодцев» — каждый отдел сфокусирован на своих KPI и не видит, как его работа влияет на общие цели компании.

Все требования собираются в единое огромное техническое задание, в котором бизнес описывает идеальную картину, а не реальные процессы. Когда дело доходит до оценки, компания получает неподъемный бюджет. Руководство требует его урезать. Из ТЗ начинают хаотично вычеркивать задачи, что неминуемо ведет к саботажу со стороны отделов, чьи требования убрали. В итоге проект либо замораживается, либо движется с огромными проблемами.

4 сценария — 1 решение

1. Сценарий 1. Хочется порядка, но нет бюджета на большую ERP. Предприятие понимает, что текущие процессы устарели и нужны изменения. Однако при попытке рассчитать стоимость внедрения получается неподъемная сумма. Защитить такой бюджет невозможно, а «костыли» уже не спасают ситуацию.
2. Сценарий 2. Есть проблемы, но не понятны источник и решение. Планы производства постоянно срываются, себестоимость считается некорректно, сроки поставок переносятся. Подразделения обвиняют друг друга в некорректном вводе данных. Никто не понимает истинных причин хаоса и не знает, как распутать этот клубок.
3. Сценарий 3. Проект автоматизации «завис». Внедрение стартовало, но на этапе моделирования застопорилось. Команды тянут одеяло на себя, формируя противоречивые требования. Бюджет раздувается, сроки переносятся, руководство теряет доверие к ИТ-службе, интегратор и заказчик вязнут в согласованиях.
4. Сценарий 4. Нет бизнес-эффекта после внедрения. Миллионы рублей освоены, но для бизнеса ничего глобально не изменилось. Операционные затраты не снизились, показатели не выросли. Более того, появились новые трудозатраты на администрирование системы, а пользователи продолжают вести реальный учет в теневых Excel-таблицах.

Проблема — не в системе и не в людях. Часто в проекте автоматизации каждое подразделение пытается оптимизировать свой кусок бизнес-процессов, при этом никто не контролирует сквозной поток создания ценности. Решение проблемы кроется в переходе к процессному подходу.

Основная ценность компании создается горизонтально — через сквозной бизнес-процесс (поток создания ценности). Представьте его в виде трубопровода, например: заказ закупка производство продажа. Главная задача — обеспечить максимальную пропускную способность. Если на одном из этапов (например, при согласовании договора) труба сужается, то пропускная способность всего предприятия падает, как бы идеально ни работали другие отделы.

Рассмотрим применение методики на примерах.

Пример 1. Разморозка проекта и оптимизация бюджета

Компания — производитель сложного электрооборудования под заказ.

Проблема — руководство заморозило проект внедрения ERP-системы из-за раздутого бюджета, состоящего из конфликтующих задач. В текущих бизнес-процессах хаос: планы производства регулярно срываются из-за внезапных дозакупок.

Решение — в рамках обследования описали сквозной бизнес-процесс. Выявили основное ограничение пропускной способности: отдел продаж выдавал технико-коммерческие предложения (ТКП) без достаточной конструкторской проработки. Из-за этого приходилось все пересогласовывать, срочно докупать комплектующие и разбираться с рекламациями. Посчитали, сколько времени и денег уходит на эти переделки. Бизнес принял решение разделить заказы по категориям и к некоторым из них подключить конструкторов еще на этапе согласования работ.

Результат — цикл реализации заказа сократился со 110 до 95 дней еще до внедрения новой ERP-системы. Бюджет автоматизации был строго обоснован и согласован, проект разморожен, через год после внедрения показатель достиг 85 дней.

Пример 2. Устранение проблем в текущих бизнес-процессах

Компания — крупный оптовый дистрибьютор.

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

Решение — вывели проблему на уровень сквозного бизнес-процесса. Локальные метрики продавцов и финансистов были пересмотрены, «ослаблены» и подчинены единой главной цели — скорости отгрузки товара со склада.

Результат — пересмотрели алгоритмы резервирования запасов и кредитных лимитов. Устранили искусственный дефицит, разблокировали отгрузки, отделы начали работать на единый бизнес-результат.

Методика STARTERP — это проектирование и диагностика сквозных бизнес-процессов, которая позволяет обнаружить возможности для быстрых побед. Она помогает:

• Создать общее понимание сквозного процесса: чтобы сотрудники видели не только свой участок, но и конечную цель бизнеса,
• Выявить «низковисящие фрукты» — проблемы, которые можно решить организационными мерами прямо сейчас,
• Обосновать бюджет ИТ-проекта, который можно легко защитить перед руководством компании,
• Убрать избыточные требования до старта разработки.

STARTERP занимает в среднем 1-2 месяца. Стоимость составляет не более 5% от общего бюджета внедрения ERP-системы. При этом требуется минимальное, но сфокусированное вовлечение бизнеса.

Состоит из 5 этапов:

Этап 1. Карта сквозного процесса

Цель: создать среду, в которой все смогут договориться.

Собираем единую рабочую группу по всем департаментам: руководитель и ключевой пользователь (обычно, самый инициативный сотрудник). Рисуем сквозной бизнес-процесс компании как трубопровод, например, от заказа до получения денег. В компании может быть несколько таких бизнес-образующих потоков, обычно не более 3.

Например:

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

Каждый участок трубы — это отдельный департамент и процесс 1-ого уровня (продажи, закупки, склад, производство и т.д.), и обычно таких участков не более 10.

Этап 2. Метрики процесса

Поток ценности нужно измерять, а для этого — договориться, чтобы все одинаково понимали метрики. Денежное выражение очевидно финансисту, но остальные быстро потеряют к нему интерес. Поэтому лучше использовать самые простые нефинансовые показатели.

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

Cроки выполнения заказа (Скорость),

Удовлетворенность клиента (Качество),

Маржинальность в процентах (Стоимость).

Этап 3. Аудит реальности (моделирование в текущей системе)

Отдельно по каждому участку трубы проводим встречи с владельцами и ключевыми пользователями. Каждый шаг демонстрируется «от и до» в тестовой системе. Заказчику нужно показать, как все работает в реальности, а не «как должно быть». Так, команда выявляет теневые шаги: когда данные берутся из личных Excel-файлов, писем, звонков, а не из системы. Все шаги (включая теневые) заносятся в таблицу. Так формируется список бизнес-процессов 2-ого уровня.

Выстраиваем логику «внутренний заказчик — внутренний поставщик»: каждый «процесс-клиент» выдвигает требования к «процессу-поставщику».

Этап 4. Согласование модели

Проходим весь сценарий сквозного процесса в тестовой системе. Присутствуют все представители департаментов одновременно.

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

На этом этапе мы исключаем из обсуждения эмоции и субъективные оценки. Любой конфликт интересов (например, когда продажам нужна гибкость, а финансам жесткий контроль) фильтруется через призму метрик из Этапа 2.

Результат — единая согласованная таблица бизнес-процессов 2-ого уровня и требований к ним, где каждый шаг привязан к метрике.

Этап 5. План быстрых побед

Все обнаруженные несостыковки между отделами и требования делим на 3 блока:

Можно решить с помощью организационных изменений,

Сигнализируют о необходимости доработать текущую систему,

Послужат требованиями к новой ERP-системе.

Каждое требование оцениваем по показателям влияния на метрики и стоимости реализации. Формируем план быстрых побед со сроками и ответственными. Считаем экономический эффект.

Далеко не всегда решением становится проект автоматизации или внедрение новой ERP-системы — иногда достаточно организационных изменений и точечных доработок текущей системы. Но если автоматизация нужна, то теперь компания точно знает зачем и что получит взамен.

Главная ценность процессного подхода в том, что команда учится договариваться. Когда требования к ИТ-ландшафту оцениваются через общую метрику, исчезают конфликты, поиск виноватых и бесконечные согласования. Сначала необходимо навести порядок в сквозном процессе, потом — думать об автоматизации. В обратной последовательности бизнес рискуете получит дорогую систему, в которой никто не работает.