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