Как бизнес сам закладывает слабые места в ERP

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

Так бывает, если бизнес запускает изменения своими силами или сразу переходит к доработкам без полноценного обследования процессов.

Запросы пользователей звучат логично: «сделайте как было в старой системе», «перенесите расчет из Excel в ERP», «уберите и/или добавьте новые обязательные поля», «разрешите проводить документ без части проверок», «дайте возможность исправить данные задним числом».

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

Самый узнаваемый пример — перенос расчетной логики из Excel без пересмотра самой модели.

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

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

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

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

В таком случае бизнес получает рабочий контур для массовых начислений, понятные правила контроля и меньшую стоимость поддержки. Редкие сценарии остаются в отдельном порядке: с владельцем, сроком пересмотра и понятным способом проверки результата.

Такой подход защищает архитектуру. Система закрывает основной поток операций, а не усложняется ради исключений, которые пока не дают сопоставимого управленческого эффекта.

Риск появляется при другом подходе: компания просит перенести Excel как есть, не фиксирует источник данных, правила проверки и ответственность за результат. Тогда проблема переезжает в ERP и начинает влиять на расчет маржи, бонусов, скидок, закрытие периода и доверие к отчетности.

Проблема обычно связана не с ERP как инструментом. Чаще компания приносит в новую систему старую неразобранную логику.

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

Компания платит за перенос привычного интерфейса вместо решения бизнес-задачи. В результате новая система наследует ограничения старой, а стоимость внедрения растет.

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

Сначала стоит проверить, какую часть процесса можно закрыть типовым функционалом без потери контроля. Доработка нужна там, где стандартный сценарий действительно не покрывает важную для бизнеса логику. В остальных случаях она закрепляет старую проблему в новой системе.

Еще один показательный случай — запрос на автоматизацию сложной цепочки документов без ясных границ процесса.

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

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

Для бизнеса это означало бы не просто одну доработку. Редкий сценарий начал бы менять правила для основного потока операций: усложнял бы работу склада, логистики, учета и контроля остатков. Стоимость разработки выросла бы, а поддерживать такую логику пришлось бы постоянно, хотя сам сценарий возникал нерегулярно.

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

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

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

Бизнес часто приходит не с готовой формулировкой задачи, а с симптомом.

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

Каждая фраза звучит как повод для доработки. Но причина может быть в другом месте: в неясном правиле, лишнем согласовании, неполных данных, устаревшей роли или привычке обходить контроль.

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

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

После такого разбора часто видно: один участок просит упростить себе работу, а последствия уйдут дальше — в финансы, логистику, производство, коммерческий блок или ИТ-поддержку.

Самые рискованные просьбы обычно звучат мягко: убрать обязательное поле, разрешить проведение документа без проверки, сократить шаг согласования, снять блокировку, расширить права доступа, разрешить редактирование задним числом.

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

Пользователь проходит свой шаг быстрее. Следующий отдел получает неполные данные, спорный статус или документ без нужной проверки. Финансы тратят время на уточнения. Руководитель открывает отчет и не понимает, можно ли принимать по нему решение. ИТ получает срочные обращения, потому что процесс формально есть, а пользователи снова ищут обходные действия.

Система не исправляет слабую постановку задачи автоматически.

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

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

Команде проекта важно проверять каждую задачу через процесс, роли, данные, контрольные точки и стоимость поддержки.

Перед любой доработкой стоит понять не что хочет пользователь, а какое правило процесса он пытается изменить.

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

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

Клиенту на старте проекта важно принести не только список пожеланий к системе. Нужен контекст управленческой задачи.

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

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

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