В закупках часто возникает спор: если в компании уже есть ERP, нужна ли отдельная SRM-система. На первый взгляд ERP умеет создавать заявки, заказы поставщикам, приходы, счета и документы. Но закупочный процесс не заканчивается документом. До заказа есть поиск поставщика, согласование условий, сравнение предложений, квалификация, договоры и коммуникации. После заказа — подтверждение сроков, изменения, рекламации, оценка качества и история надежности.
ERP и SRM не должны конкурировать. ERP отвечает за учетный и финансовый каркас предприятия. SRM отвечает за управление поставщиками и закупочным взаимодействием. Когда закупки простые, ERP может быть достаточно. Когда поставщиков много, условия сложные, сроки критичны, а качество поставки влияет на производство, связка SRM и ERP дает гораздо более устойчивый процесс.
Что делает ERP в закупках
ERP-система хранит потребности, номенклатуру, остатки, заказы, складские движения, счета, оплаты, договоры и финансовые обязательства. Она связывает закупки с производством, складом, бухгалтерией, продажами и управленческой отчетностью. Для компании это источник истины по учету: что заказано, что пришло, что оплачено, сколько осталось на складе и какие обязательства открыты.
В статье об ERP для закупок эта роль раскрывается подробно. ERP особенно сильна там, где закупка уже принята к исполнению и должна пройти через учетный контур. Но ERP не всегда удобна для живого взаимодействия с поставщиками: переписка, уточнения, тендеры, сравнение условий, квалификация, документы поставщика, претензии и рейтинг часто оказываются за пределами учетной логики.
Что делает SRM
SRM-система работает вокруг поставщика. Она хранит карточку поставщика, контакты, категории, квалификацию, документы, статусы допуска, историю предложений, коммуникации, договорные условия, сроки, рекламации, качество, рейтинги и риски. Для закупщика это рабочий контур взаимодействия: кому отправлен запрос, кто ответил, какие условия предложены, какие документы просрочены, кто надежен по срокам и качеству.
SRM помогает не держать закупки в почте и таблицах. Если поставщик переносит дату, подтверждает количество, присылает сертификат, отвечает на претензию или участвует в сравнении предложений, это событие должно быть связано с конкретной закупкой и историей поставщика. В ERP обычно хранится результат, а в SRM — процесс взаимодействия.
Где проходит граница
Граница проходит между учетным фактом и отношениями с поставщиком. ERP важно знать, что создан заказ, ожидается поставка, материал принят, счет получен и оплата выполнена. SRM важно знать, как поставщик был выбран, как он подтвердил условия, какие риски возникли, какие документы он предоставил, как быстро ответил на рекламацию и как изменился его рейтинг.
Эта граница не абсолютна. В некоторых компаниях SRM-модуль встроен в ERP. В других SRM работает как отдельная система с интеграцией. Важнее не название поставщика ПО, а то, есть ли в процессе нужные функции и не заставляют ли сотрудников дублировать данные вручную.
Когда достаточно ERP
ERP может быть достаточно, если закупки простые, поставщиков немного, условия стабильны, качество поставок редко вызывает вопросы, а коммуникации не требуют сложного согласования. Например, компания закупает повторяемые позиции у ограниченного числа надежных поставщиков, а основной контроль нужен по остаткам, заказам, приемке и оплате.
В такой ситуации отдельный SRM может быть избыточным. Достаточно хорошо настроить заявки, согласования, лимиты, заказы поставщикам, складскую приемку, документы и отчеты в ERP. Важно не усложнять архитектуру там, где процесс еще не требует отдельного контура поставщиков.
Когда нужен SRM
SRM становится полезным, когда закупочный процесс выходит за рамки учетного документа. Например, много поставщиков по одной категории, регулярные тендеры, сложные согласования условий, необходимость квалификации и аудита, критичные сроки поставки, входной контроль качества, претензии, документы поставщиков, риски зависимости от одного источника.
Если закупщик постоянно ищет письма, вручную собирает предложения, держит сроки в таблице, спорит с поставщиком о подтверждениях и не видит историю качества, это сигнал для SRM. Здесь нужны инструменты управления поставщиками, а не только регистрация заказа.
Какие данные синхронизировать
- Из ERP в SRM. Номенклатура, потребности, заявки, остатки, заказы, договоры, цены, статусы приемки, платежные ограничения.
- Из SRM в ERP. Выбранный поставщик, подтвержденные условия, дата поставки, изменения, согласованные цены, документы, статус поставщика.
- В обе стороны. Карточки поставщиков, контактные лица, категории, договоры, история закупок и закрытие документов.
- Из QAS и логистики. Качество поставки, рекламации, задержки, фактические даты и причины отклонений.
Например, материал о контроле сроков поставки показывает, что обещанная дата поставщика должна быть видна не только закупщику. Она влияет на производство, склад и планирование. Поэтому дата может подтверждаться в SRM, но результат должен возвращаться в ERP и производственный контур.
Качество поставщиков
Отдельная зона SRM — качество и надежность поставщика. Цена закупки может быть привлекательной, но если поставщик регулярно задерживает поставку, присылает неполные документы или дает высокий процент несоответствий, реальная стоимость для бизнеса растет. Поэтому в закупочном контуре нужны рейтинги и история качества.
В статье об управлении качеством поставщиков эта логика рассматривается через входной контроль и рекламации. Для связки SRM и ERP важно, чтобы такие данные влияли на выбор поставщика, а не оставались в отдельной системе качества.
Как выбирать архитектуру
- Описать закупочный процесс от потребности до закрытия документов.
- Отделить учетные операции от коммуникаций с поставщиком.
- Понять, где сейчас данные теряются: предложения, сроки, качество, документы, согласования.
- Оценить, можно ли закрыть проблему настройкой ERP или нужен отдельный SRM-контур.
- Определить источники истины: поставщик, номенклатура, заказ, дата, цена, документ, рейтинг.
- Запускать интеграцию с минимального набора данных, который сразу снижает ручной труд.
Практический вывод
ERP нужна закупкам для учета и связи с предприятием. SRM нужен закупкам для управления поставщиками и процессом взаимодействия. Если пытаться все сделать в ERP, закупки могут остаться формально автоматизированными, но фактически продолжать жить в почте и таблицах. Если запустить SRM без связи с ERP, появится еще одна система с дублированием данных.
Рабочая схема строится от процесса. ERP отвечает за учетную правду, SRM — за поставщика и закупочное взаимодействие, а интеграция связывает их без ручного переноса. Тогда закупки видят не только заказ и счет, а полный путь: потребность, выбор поставщика, условия, срок, поставка, качество и результат для бизнеса.