Запрос «нам нужна другая система» чаще всего приходит не от того, что текущая не умеет чего-то нужного. Он приходит от накопленного раздражения: отчёты не сходятся, данные вносят с опозданием, каждая доработка занимает месяцы. Это симптомы, и они одинаково выглядят при обеих причинах — и когда система действительно не подходит, и когда она просто не настроена.
Ниже — признаки, которые позволяют развести эти случаи, и то, что стоит за каждым из двух решений на практике.
Когда доработка почти наверняка достаточна
Есть набор ситуаций, в которых замена системы не даст ничего, кроме нового проекта с теми же проблемами через год.
Проблема в данных, а не в функциях
Система умеет то, что нужно, но справочники устарели, нормы не заполнены, а фактические данные вносятся выборочно. Замена платформы не меняет здесь ничего: новая система получит те же неполные данные и будет показывать ту же искажённую картину.
Процессы в системе не совпадают с реальными
Конфигурация делалась под процесс, который на производстве уже не выполняется — или не выполнялся никогда. Сотрудники обходят систему не потому, что она плохая, а потому, что она требует действий, не имеющих отношения к их работе. Это лечится перенастройкой, и обычно заметно дешевле замены.
Не хватает конкретного контура
Учёт и склад ведутся, а производственного планирования нет. Если платформа поддерживает нужный контур, разумнее достроить его, чем переносить работающие участки на новое место.
Никто не отвечает за систему внутри компании
Самый частый и самый недооценённый случай. Без внутреннего владельца процесса любая система деградирует за несколько месяцев: настройки устаревают, вопросы пользователей остаются без ответа, доверие к данным падает. Замена платформы при сохранении этого условия воспроизведёт ситуацию в точности.
Когда замена действительно неизбежна
Платформа не поддерживает обязательный для отрасли контур
Партионный учёт со сроками годности, многоуровневые спецификации с версиями, серийный учёт — там, где это требование отрасли, а не пожелание, отсутствие поддержки закрывает вопрос. Достроить такой контур доработками поверх системы, спроектированной без него, обычно дороже замены и всегда хрупче.
Систему невозможно сопровождать
Вендор ушёл с рынка, поддержка версии прекращена, а исходная команда внедрения недоступна. Функционально всё может работать, но любая проблема превращается в остановку без срока восстановления. Здесь решение принимается по величине риска, а не по возможностям.
Стоимость доработки сравнялась со стоимостью замены
Признак — накопленный объём индивидуальных доработок, из-за которого каждое обновление превращается в отдельный проект. В какой-то момент поддержка такой конфигурации начинает стоить дороже, чем переход на типовое решение.
Требования к локализации данных или к реестру ПО
Внешнее ограничение, которое не обсуждается: если система не соответствует требованиям, при которых вы обязаны работать, выбор сделан за вас. Это единственный случай, где решение не зависит от экономики проекта.
Что стоит за каждым решением, кроме денег
Сравнивать эти пути по стоимости лицензий бессмысленно — основные затраты лежат в другом месте.
Доработка сохраняет накопленные данные, справочники и привычки сотрудников. Это её главное преимущество и одновременно ограничение: вместе с данными сохраняются и заложенные в них ошибки. Риск здесь в том, что доработка может не решить проблему, если её причина глубже настройки, — и тогда время потрачено, а вопрос вернулся.
Замена даёт возможность перепроектировать процессы, но требует заново пройти всё: перенос данных, описание маршрутов, обучение, период двойного ввода. Основной риск — не техническая миграция, а то, что предприятие не выдержит нагрузки параллельной работы и вернётся к старым процессам на середине пути.
Общее для обоих путей: без внутреннего владельца процесса и без изменения момента внесения факта результата не будет ни при доработке, ни при замене.
Как принять решение, если признаки смешанные
У большинства предприятий часть признаков указывает в одну сторону, часть — в другую. В этой ситуации помогает не выбор из двух вариантов, а порядок действий: сначала разобрать, что именно не работает, и только потом решать, чем это чинить.
Именно это и делает аудит существующей системы: показывает, где рвётся цепочка данных, какие проблемы устраняются настройкой, а какие упираются в ограничения платформы. По опыту большинство случаев после разбора оказывается ближе к доработке, чем предполагали на входе, — но выясняется это на данных, а не в разговоре.
Если разбираться самостоятельно, минимальный набор вопросов такой: попадает ли факт в систему в момент операции, заполнены ли нормы и маршруты, есть ли человек, отвечающий за настройки, и поддерживает ли платформа контур, который вам обязателен по отрасли. Три ответа «нет» из четырёх означают, что проблема не в системе.