Требования к ERP часто начинают собирать слишком поздно. Уже выбрали платформу, посмотрели демонстрацию, получили коммерческое предложение, а потом выясняется простая вещь: отделы по-разному понимают один и тот же процесс. Продажи считают заказ согласованным после письма клиента, производство — после проверки материалов, склад — после резерва, финансы — после подтверждения оплаты.
В такой ситуации требования к ERP нужны не для формальности. Они помогают заранее договориться, как компания будет работать в системе. Не какие кнопки должны быть на экране, а какие решения система должна поддерживать каждый день: принять заказ, зарезервировать материалы, запустить производство, изменить срок, остановить отгрузку, увидеть отклонение по деньгам или срокам.
Не список модулей
Самая частая ошибка — начать с таблицы функций. Финансы есть. Склад есть. Закупки есть. Производство есть. Отчеты есть. На бумаге выглядит спокойно, но такой список почти ничего не говорит о пригодности ERP для конкретной компании.
Модуль “склад” может означать простой учет остатков. А может — партии, серии, ячейки, резервы под заказы, контроль сроков годности, связь с производством, запрет отгрузки при спорном статусе качества. Модуль “производство” может быть маршрутами и сменными заданиями, а может ограничиться списанием материалов по факту выпуска. Разница для предприятия огромная.
Поэтому требования лучше начинать с процесса. Если компания рассматривает ERP-систему как основу управления заказами, складом, закупками, производством и финансами, то первый вопрос звучит не “какие модули нужны”. Первый вопрос другой: где сейчас теряется управляемость?
Иногда проблема в том, что руководитель видит остатки на утро, а к обеду они уже не совпадают с реальностью. Иногда закупки узнают о потребности, когда материал уже нужен в цехе. Иногда производство работает по устным уточнениям, а в системе остается старое задание. Вот эти ситуации и должны становиться основой требований.
Начать с процесса
Хорошее требование описывает не желание, а рабочий сценарий. Например, “нужен учет производства” звучит слишком широко. Непонятно, кто создает задание, когда оно считается принятым в работу, как списываются материалы, что происходит при браке, кто меняет срок и как руководитель узнает, что план уже сорван.
Более полезная формулировка строится иначе: менеджер подтверждает заказ, система проверяет доступность материалов, планировщик видит ограничение по оборудованию, начальник смены получает задание, факт выполнения возвращается в ERP, а при отклонении появляется причина и ответственный. Это уже не абстрактный модуль. Это будущая работа компании.
На этом этапе не нужно стремиться описать все сразу. Лучше выбрать несколько процессов, где ошибка дороже всего обходится бизнесу. Для производственной компании это часто заказ, закупка материалов, производственное задание, склад, качество и отгрузка. Для торговой — закупка, резерв, склад, продажа, логистика и деньги. Для сервисной — договор, заявка, исполнение, трудозатраты и закрывающие документы.
Когда процесс описан, становится видно, где нужна разработка, где хватит настройки, а где компания сама не договорилась о правилах. Последний пункт неприятный, но полезный. ERP не исправляет противоречивый регламент. Она делает его видимым.
Роли и решения
Следующий слой требований — роли. Не должности из штатного расписания, а реальные участники процесса. Кто создает документ. Кто согласует. Кто имеет право изменить количество. Кто видит себестоимость. Кто может снять резерв. Кто отвечает за спорную партию. Кто закрывает период.
Если роли не описаны, система быстро превращается в общий доступ “для удобства”. Сначала так быстрее. Потом появляются исправления задним числом, непонятные версии документов, отчеты с разными цифрами и вопросы без ответственного. В ERP это особенно опасно, потому что одна ошибка тянет за собой склад, закупки, производство и финансы.
Ролевое требование должно отвечать на три вопроса:
- Кто выполняет действие в обычном сценарии.
- Кто принимает решение при отклонении.
- Что система должна запретить без отдельного права.
Так появляются не просто права доступа, а управленческая логика. Например, кладовщик может принять материал, но не может изменить цену. Начальник смены может зафиксировать отклонение, но не может списать лишний расход без причины. Руководитель отдела может согласовать заявку, но система должна сохранить историю решения.
При выборе ERP это помогает сравнивать решения. В требованиях задача еще практичнее: заранее показать, какие решения компания не готова отдавать на усмотрение пользователя.
Данные без споров
ERP держится на данных. Если в требованиях нет правил по данным, проект будет спорить об интерфейсе, хотя проблема лежит глубже. У одной и той же номенклатуры появятся разные названия, единицы измерения начнут расходиться, остатки будут сверяться вручную, а отчеты придется объяснять “особенностями учета”.
Для ERP особенно важен источник данных. Кто создает карточку номенклатуры. Где хранится спецификация. Как обновляется цена. Как меняется маршрут производства. Откуда берется статус качества. Какая система отвечает за клиента, если рядом уже есть CRM. Какие данные приходят из 1С, оборудования, складского терминала или другой системы.
Здесь не нужно писать сложный технический документ на старте. Достаточно честно перечислить данные, из-за которых уже возникают споры. Остатки. Резервы. Партии. Себестоимость. Сроки поставки. Нормы расхода. Статусы заказов. Затем по каждому пункту определить владельца и правило изменения.
Если данные нужны в нескольких системах, требования сразу выходят на интеграции. Это нормальная ситуация. ERP редко живет одна: рядом могут быть CRM, MES, складские терминалы, бухгалтерия, телефония, сайт, личный кабинет клиента или оборудование на производстве. Поэтому требования к данным должны быть связаны с требованиями к обмену.
Интеграции заранее
Интеграции опасно оставлять “на потом”. Формально ERP можно запустить и без них, но тогда сотрудники начинают переносить данные руками. Несколько недель это терпят. Потом ручной перенос становится частью процесса, а система уже не отражает реальную картину.
В требованиях к интеграции важно описывать не один факт обмена, а смысл события. Например, “передавать заказы из CRM в ERP” — слабое требование. Лучше указать, в какой момент заказ становится готовым к передаче, какие поля обязательны, что делать с изменением срока, кто видит ошибку обмена и как система не даст запустить производство по неполному заказу.
Для производственных компаний рядом с ERP часто появляется связка с MES, QAS или оборудованием. Тогда вопрос еще жестче: данные должны приходить вовремя. Если факт выпуска, простой, отклонение качества или перерасход материала попадают в ERP через день, управленческий отчет красивый, но бесполезный для оперативного решения.
Поэтому при подготовке требований полезно отдельно описать интеграцию ERP: какие события передаются, кто владеет ошибкой обмена, какие данные можно обновлять автоматически, а какие требуют подтверждения человека. Это снижает риск, что интеграция станет набором скрытых ручных операций.
Исключения важнее нормы
Нормальный процесс обычно описывают быстро. Заказ пришел, материал есть, производство выполнило, склад отгрузил, деньги поступили. Но ERP проверяется не на идеальном сценарии. Она проверяется на исключениях.
Материал пришел не полностью. Партия зависла на контроле качества. Клиент изменил срок. Производство выпустило меньше, чем планировалось. Нужно заменить материал. Станок встал. Закупка задержалась. Руководитель разрешил отгрузку при неполном комплекте документов. Именно такие случаи показывают, готова ли система работать с жизнью предприятия, а не с красивой схемой.
Поэтому в требованиях стоит выделять отдельный блок исключений. Не огромный перечень всех возможных проблем, а самые частые и дорогие для компании случаи. По каждому исключению нужно понять, что делает система: предупреждает, блокирует, требует согласования, создает задачу, фиксирует причину или меняет статус заказа.
Раздел исключений часто отличает индивидуальную разработку от простой установки готовой конфигурации. Если исключения компании типовые, готовое решение может подойти. Если именно исключения делают бизнес управляемым, потребуется настройка, доработка или разработка программного обеспечения под регламенты компании.
Отчеты после действий
Отчеты нельзя проектировать отдельно от процесса. Руководителю нужен не набор таблиц, а возможность принять решение без ручной сверки. Что отгрузим на этой неделе. Где не хватает материалов. Какой заказ задерживается. Где растет незавершенное производство. Почему себестоимость ушла от плана. Какие подразделения задерживают согласования.
Если такие вопросы не заложить в требования, отчетность часто собирают в конце проекта. Данные уже есть, но находятся не в том виде, не в той детализации или без нужной причины отклонения. Формально ERP работает, а управленческий отчет снова собирается в Excel.
Полезное требование к отчету должно объяснять управленческое действие. Не просто “отчет по остаткам”, а “руководитель закупок должен видеть материалы, которые могут сорвать заказы в ближайшие две недели”. Не просто “отчет по производству”, а “начальник производства должен видеть операции, где план не совпал с фактом, и причину отклонения”.
Так отчетность перестает быть украшением системы. Она становится проверкой качества требований. Если нужный отчет нельзя собрать из описанных данных, значит, в процессе не хватает события, статуса, причины или ответственного.
Приоритеты и этапы
Все требования не равны. Часть нужна к первому запуску, иначе система не сможет заменить текущий процесс. Часть можно перенести на следующий этап. Часть звучит полезно, но не влияет на запуск. Если не разделить эти группы, проект начнет раздуваться еще до начала разработки.
Удобно делить требования на три уровня:
- Обязательные требования, без которых нельзя запустить процесс в промышленную работу.
- Требования следующего этапа, которые улучшают управление, но не блокируют запуск.
- Пожелания, которые нужно сохранить, но не превращать в условие приемки.
Такой подход защищает проект от двух крайностей. Первая — запустить слишком мало и получить систему, которой неудобно пользоваться. Вторая — пытаться сделать все сразу и месяцами не доходить до реальной эксплуатации.
Для руководителя здесь важна простая проверка: каждое обязательное требование должно быть связано с риском. Что сломается, если его не сделать к запуску? Если ответа нет, требование, скорее всего, относится к следующему этапу или к пожеланиям.
Как принимать результат
Требование считается полезным только тогда, когда по нему можно принять работу. “Система должна быть удобной” принять невозможно. “Кладовщик должен принять поступление за три действия” уже можно проверить, но это все еще не вся картина. Нужно проверить, что после приемки данные попали в остатки, закупки видят закрытую потребность, а руководитель видит факт в отчете.
Поэтому для важных требований нужен сценарий приемки. Он описывает реальную последовательность действий и ожидаемый результат. Создали заказ. Проверили материалы. Сформировали производственное задание. Зафиксировали частичный выпуск. Указали причину отклонения. Обновили остатки. Получили отчет для руководителя.
Сценарии приемки лучше готовить до разработки или выбора подрядчика. Тогда обсуждение становится предметным. Видно, какие требования понятны, какие спорны, где не хватает данных, где нужна интеграция, а где компания еще не определила правило.
Именно так требования превращаются из документа “для проекта” в рабочий инструмент управления. Они помогают выбрать систему, спланировать доработки, оценить риски и не принять ERP только потому, что отдельные экраны открываются без ошибок.
Что фиксировать
Хороший набор требований к ERP не обязан быть огромным. Он обязан быть проверяемым. Если документ помогает понять, кто что делает, какие данные создаются, какие исключения бывают и как руководитель принимает решение, это уже сильная основа для проекта.
Минимальный состав требований можно описать так:
- Процессы, которые входят в первый этап.
- Роли и права на управленческие действия.
- Данные, их владельцы и правила изменения.
- Исключения, которые нельзя оставлять на устные договоренности.
- Интеграции и события обмена между системами.
- Отчеты, которые должны собираться без ручной сверки.
- Сценарии приемки для самых важных процессов.
Если после такой работы становится понятно, что готовая ERP закрывает большую часть процесса, ее можно брать и аккуратно внедрять. Если основная ценность компании держится на особых правилах, интеграциях и исключениях, логичнее рассматривать индивидуальную разработку или существенные доработки. Главное — принимать это решение до старта проекта, а не после того, как новая система уже начала повторять старые ошибки.