Российский рынок SRM за последние несколько лет заметно изменился. После ухода зарубежных решений основной вопрос звучал как «чем заменить SAP Ariba?». Сегодня выбор значительно шире: специализированные SRM-платформы, решения на low-code, собственные разработки и системы, максимально интегрированные с корпоративной ERP.
Для компаний, работающих на 1С, возникает отдельный вопрос: нужна ли самостоятельная SRM-платформа или закупочный контур целесообразнее строить внутри существующей архитектуры 1С? Разберем основные подходы и посмотрим, для каких задач подходит каждый из них.
Что сегодня автоматизируют SRM-системы
SRM (Supplier Relationship Management) уже давно не ограничивается базой поставщиков или проведением тендеров. В зависимости от продукта и архитектуры система может охватывать:
- сбор и консолидацию потребностей;
- планирование закупок;
- поиск и квалификацию поставщиков;
- проведение конкурентных процедур;
- управление договорами;
- контроль исполнения поставок;
- оценку поставщиков;
- управление рисками;
- аналитику закупочной деятельности.
Рынок постепенно движется в сторону концепции Source-to-Pay — сквозного управления процессом от возникновения потребности и выбора поставщика до исполнения обязательств и оплаты. При этом на практике автоматизировать весь цикл в одной системе требуется далеко не всегда. Если предприятие уже использует 1С или несколько решений 1С, часть необходимых данных и процессов существует в учетном контуре. И здесь появляется архитектурный вопрос: что действительно следует переносить в SRM, а что разумнее оставить в ERP?
Три подхода к построению SRM
Условно существующие решения можно разделить на три группы.
1. Специализированная SRM-платформа
Это самостоятельная система, изначально разработанная для управления закупками. На российском рынке к этому классу можно отнести B2B Altis, «ЛотЭксперт», AGORA и ряд других продуктов.
Главное преимущество такого подхода — глубина специализированного функционала. Система может охватывать значительную часть Source-to-Pay: работу с поставщиками, конкурентные процедуры, договоры, закупочную аналитику и другие процессы. Но появляется дополнительный интеграционный контур. SRM необходимо связать с ERP, НСИ, бухгалтерией, складским учетом, ЭДО, электронными торговыми площадками и другими корпоративными системами. Поэтому при выборе такого продукта стоит оценивать не только функциональную карту SRM, но и будущую архитектуру обмена данными.
2. SRM на low-code/BPM-платформе
Второй подход — построение закупочного решения на базе универсальной low-code-платформы. Примеры — Norbit SRM на BPMSoft и ELMA365 Закупки.
Преимущество low-code — возможность относительно быстро менять процессы, формы, маршруты согласования и пользовательские сценарии. Это может быть особенно полезно организациям, где закупочные процессы часто меняются или существенно различаются между подразделениями.
Но гибкость платформы сама по себе не означает наличия необходимой глубины закупочного функционала. Поэтому при выборе важно отдельно оценивать, какие процессы уже реализованы в продукте, а какие придется проектировать и настраивать.
3. Закупочный контур, интегрированный с ERP
Третий подход — автоматизация закупок максимально близко к корпоративной ERP. На российском рынке особенно актуальны решения, построенные на платформе «1С:Предприятие». Такой вариант востребован в компаниях, где значительная часть бизнес-процессов уже работает в экосистеме 1С и важно минимизировать количество дополнительных интеграционных слоев. Пример такого подхода — АСУЗ (автоматизированная система управления закупками), разработанная на платформе «1С:Предприятие».
Как устроена АСУЗ
АСУЗ создавалась для следующего сценария: распределенная компания или холдинг, в котором подразделения работают в разных информационных базах 1С, а закупочные данные необходимо консолидировать на корпоративном уровне.
Поэтому архитектура системы двухуровневая.
Нижний уровень — автоматизированные рабочие места закупщиков непосредственно в учетных системах 1С подразделений.
Верхний уровень — централизованная система сбора и хранения закупочных данных для управления и аналитики на уровне холдинга.
Такой подход позволяет не переносить всю операционную деятельность в отдельную внешнюю систему. Пользователи продолжают работать с учетным контуром, а необходимые данные передаются на корпоративный уровень.
АСУЗ позволяет решать несколько задач:
- вести централизованные данные по поставщикам;
- регистрировать и контролировать тендерные процедуры;
- прослеживать цепочку документов от потребности до поступления товара;
- контролировать соответствие договоров проведенным закупочным процедурам;
- консолидировать информацию по закупкам различных подразделений;
- получать информацию об остатках ТМЦ и использовать ее при планировании закупок.
Последняя задача особенно интересна для распределенных компаний. Если одно подразделение собирается закупать материал, который фактически находится в невостребованных остатках другого подразделения, централизованный контур позволяет увидеть это до проведения новой закупки.
Когда такая архитектура действительно имеет смысл
Сам факт использования 1С еще не означает, что компании необходимо строить SRM на этой же платформе. Архитектурный подход особенно оправдан, если одновременно присутствует несколько условий:
Несколько подразделений или юридических лиц. Закупки распределены, но управляющей компании необходима единая картина.
Разные базы 1С. Дивизионы могут использовать различные конфигурации или самостоятельно вести учет.
Большая часть исходных данных уже находится в 1С. Потребности, номенклатура, остатки, поступления и другие данные не требуется повторно создавать в отдельной системе.
Необходима сквозная прослеживаемость. Нужно видеть не только сам тендер, но и связь между потребностью, закупочной процедурой, договором и фактическим поступлением.
Есть проблема невостребованных запасов. Перед новой закупкой необходимо проверять наличие соответствующих ТМЦ в других подразделениях.
Для компании с одной информационной базой и относительно простым процессом закупок часть преимуществ такой архитектуры, наоборот, может оказаться невостребованной.
Практический пример: закупки в распределенном холдинге
Именно такой сценарий был реализован при автоматизации закупок «ТаграС-Холдинга». До внедрения закупочные процессы различных дивизионов отличались друг от друга. Информация находилась в нескольких учетных системах, а часть взаимодействия происходила через электронную почту, телефон и Excel.
Задача заключалась не просто в автоматизации тендеров, а в создании общего информационного пространства для закупочной деятельности холдинга. Был создан двухуровневый контур: подразделения сохранили работу в своих учетных системах, а данные стали консолидироваться централизованно.
В результате появилась возможность прослеживать закупочный процесс, централизованно работать с данными поставщиков, контролировать связь договоров с проведенными процедурами и учитывать остатки различных подразделений.
Проект охватил около 2000 автоматизированных рабочих мест и в 2025 году стал победителем конкурса «1С:Проект года» в номинации «Закупки, снабжение и управление отношениями с поставщиками».
Где должна находиться мастер-система
Это один из вопросов, который стоит решить до выбора конкретного SRM-продукта. Предположим, номенклатура ведется в ERP, информация о поставщике одновременно присутствует в ERP и SRM, договор проходит согласование в СЭД, тендер проводится в SRM, а поступление отражается снова в ERP.
Без заранее определенной архитектуры быстро возникают вопросы:
- где создается поставщик;
- какая система хранит эталонные данные;
- кто отвечает за их изменение;
- откуда SRM получает остатки;
- куда передается результат тендера;
- где формируется договор;
- каким образом закупочная процедура связывается с фактическим поступлением.
Поэтому при выборе SRM функциональное сравнение продуктов — только часть задачи. Не менее важно сначала определить целевую архитектуру закупочного процесса и распределение ответственности между системами.
А нужен ли вообще весь Source-to-Pay?
Еще одна распространенная ошибка — стремление автоматизировать весь закупочный цикл сразу. Если основная проблема компании заключается, например, в отсутствии единой информации о поставщиках или невозможности консолидировать закупки подразделений, внедрение десятка дополнительных модулей само по себе не увеличит эффект проекта. И наоборот: если закупочная функция уже достаточно зрелая, автоматизация только проведения тендеров может не решить проблему отсутствия сквозного управления. Поэтому начинать стоит не с перечня функций конкретной SRM, а с трех вопросов:
- Какие проблемы закупочного процесса мы хотим устранить?
- Какие данные и процессы уже автоматизированы в существующих системах?
- Как должна выглядеть целевая архитектура после внедрения?
Только после этого имеет смысл сравнивать продукты.
А что с взаимодействием с поставщиками?
Цифровизация внутренних закупочных процессов — только часть задачи. Если значительный объем коммерческих предложений, документов и уточнений по-прежнему поступает по электронной почте, сотрудникам приходится вручную переносить информацию в корпоративные системы. Поэтому все большее значение приобретает цифровизация взаимодействия с поставщиками: получение структурированных данных, сокращение ручного переноса информации, автоматизация проверки документов и интеграция с внешними сервисами. Конкретный механизм такого взаимодействия зависит от архитектуры выбранного решения и процессов компании.
ИИ в закупках: следующий слой автоматизации
Разработчики SRM активно внедряют или тестируют искусственный интеллект для классификации заявок, анализа документов, поиска аналогов номенклатуры, оценки поставщиков, выявления рисков и прогнозной аналитики. Но для корпоративной системы есть важное ограничение: ИИ не исправляет плохую архитектуру и некачественные данные. Если один и тот же материал существует под несколькими наименованиями, поставщики задублированы, закупочные категории не структурированы, а часть данных хранится в Excel, интеллектуальный алгоритм получает на вход тот же информационный хаос. Поэтому логичная последовательность автоматизации выглядит так:
процессы → архитектура → данные → интеграции → интеллектуальная автоматизация.
Что в итоге выбрать
Универсально лучшей SRM-системы не существует. Специализированная платформа может быть оптимальной, если компании нужен широкий Source-to-Pay и развитый внешний контур работы с поставщиками. Low-code может оказаться сильным вариантом, если приоритетом является гибкость процессов. Интегрированное с ERP решение имеет преимущества, когда закупки тесно связаны с существующим учетным контуром, а значительная часть необходимых данных уже находится в 1С. Для распределенного холдинга появляется еще один критерий: насколько хорошо система умеет консолидировать закупочные процессы разных подразделений, не заставляя полностью перестраивать их существующие учетные системы.
Поэтому выбирать SRM стоит не с демонстрации интерфейса и не с подсчета функций. Сначала — процессы и целевая архитектура. Затем — требования к данным и интеграциям. И только после этого — конкретная технологическая платформа.