В холдинговых структурах одна из ключевых задач — выстроить управляемую, прозрачную и масштабируемую систему закупочной деятельности. При этом важно сохранить операционную самостоятельность филиалов и дочерних обществ: они должны продолжать работать со своими потребностями, поставщиками и первичными документами, но в рамках единых правил и общего контура контроля.
В этой статье рассмотрим подход к построению единого контура управления закупками в холдинге на базе платформы «1С:Предприятие». В основе решения — распределённая архитектура, при которой филиалы сохраняют самостоятельность в операционной работе, а управляющая компания получает инструменты контроля, аналитики и консолидации данных.
Централизованные закупки и централизованное управление закупками
При проектировании системы важно разделять два подхода: централизованные закупки и централизованное управление закупками.
Классическая централизация предполагает, что все филиалы или дивизионы проводят закупки через головной офис. Такой подход может обеспечить высокий уровень контроля, но часто замедляет операционную деятельность: увеличивается количество согласований, возрастает нагрузка на управляющую компанию, а филиалы теряют гибкость в решении текущих производственных задач.
Альтернативный подход — построение единого управленческого контура. В этом случае филиалы сохраняют операционную самостоятельность: оформляют заявки, работают со своими поставщиками, ведут первичные документы и проводят закупочные процедуры. При этом их деятельность подчиняется единым правилам, а ключевые данные передаются в централизованную систему уровня холдинга.
Такой подход позволяет:
1. Сохранить гибкость и скорость работы дочерних зависимых обществ (ДЗО).
2. Обеспечить прозрачность закупочных цен и условий для управляющей компании.
3. Создать единую базу ресурсов: свободных остатков ТМЦ, проверенных поставщиков, результатов торгов и протоколов тендерных комиссий.
Требования к системе управления закупочной деятельностью
При построении единого контура управления закупками можно выделить несколько ключевых требований к системе.
1. Унификация процедур.
Необходимо обеспечить единые формы подачи заявок, единые правила проведения торгов, унифицированные протоколы тендерных комиссий и общие требования к согласованию закупочных решений.
2. Сквозной контроль.
Система должна позволять отслеживать полный цикл закупки: от возникновения потребности и подачи заявки до проведения торгов, заключения договора, поступления товара и оплаты.
3. Автоматизация аналитики.
Важной задачей является автоматическая сверка цен, указанных в протоколах, с фактическими ценами закупки, а также анализ эффективности торгов и уторговывания.
4. Управление ликвидностью.
Для холдинга важно видеть невостребованные и необорачиваемые запасы в разрезе филиалов, чтобы использовать внутренние ресурсы до размещения новых закупок у внешних поставщиков.
5. Единый реестр поставщиков.
Управляющая компания должна иметь возможность консолидировать сведения о поставщиках, результатах проверок, техаудитах, отзывах и ограничениях на работу с контрагентами.
Распределённая архитектура решения
Архитектура решения строится на распределённой модели, где каждый уровень выполняет свои задачи, но взаимодействует с остальными через единый центр обмена данными.
Уровень холдинга
На уровне холдинга размещается АСУЗ (автоматизированная система управления закупками) на базе платформы «1С:Предприятие». Она выступает в роли интеграционного ядра и центра аналитики.
В этой системе хранятся:
- реестры протоколов тендерных комиссий;
- единый реестр поставщиков;
- консолидированные сведения о свободных остатках филиалов;
- данные о закупочных процедурах;
- информация для контроля и аналитики закупочной деятельности.
Уровень филиала
На уровне филиала используется существующая учетная система предприятия, например 1С:ERP.
На этом уровне ведется операционный учет:
- формируются заявки на закупку;
- создаются заказы поставщикам;
- отражается поступление ТМЦ;
- ведутся договоры;
- оформляются документы, связанные с проведением торгов и исполнением закупочных решений.
Внешние системы
В контур также могут входить внешние системы:
- системы электронного документооборота филиалов, например СЭД «Практика» или «1С:Документооборот»;
- электронные торговые площадки;
- сервисы и внешние источники данных, используемые для проведения закупочных процедур и согласований.
Такая архитектура позволяет избежать тяжелого перехода всех филиалов на единую платформу и снизить риски остановки бизнеса. Каждый филиал продолжает работать в своей учетной системе, а управляющая компания получает централизованный контур контроля.
Рис. 1. Распределенная архитектура
Основные модули системы
1. Невостребованные остатки
Модуль предназначен для снижения складских запасов и высвобождения оборотных средств.
Система определяет невостребованные остатки по заданному алгоритму и выявляет товары, которые длительное время находятся на складах без движения. Филиал принимает решение, какие позиции можно передать для внутренней реализации, устанавливает статус «Невостребованный остаток» и внутреннюю цену продажи.
После этого данные передаются в центральную систему. Другие филиалы могут видеть такие остатки, использовать их для закрытия собственных потребностей и оформлять внутренние сделки.
2. Исполнение заявок на закупку
Модуль помогает выбрать оптимальный источник закрытия потребности.
Сотрудник филиала создает запрос на необходимый товар. Система выполняет поиск по доступным данным: собственным остаткам, свободным остаткам других филиалов, сведениям о поставщиках и результатам предыдущих закупок.
Если потребность можно закрыть за счет внутренних ресурсов холдинга, система помогает выбрать подходящий вариант. Если такой возможности нет, инициируется стандартная закупочная процедура, в том числе проведение торгов при необходимости.
3. Проведение торгов
Модуль обеспечивает документирование и централизованное согласование результатов торгов.
В системе создается протокол тендерной комиссии. В него заносятся данные об участниках, предложениях, условиях поставки, этапах торгов и решении комиссии. Часть данных может заполняться автоматически на основании файлов, полученных с электронных торговых площадок.
После выбора победителя протокол направляется на согласование. После утверждения на уровне холдинга он получает официальный регистрационный номер, который затем используется в дальнейших документах, включая договоры и заказы поставщикам.
4. Единый реестр поставщиков
Единый реестр поставщиков позволяет использовать опыт всех подразделений холдинга.
Информация о поставщиках автоматически поступает из филиалов в АСУЗ. К карточке поставщика могут прикрепляться документы проверки благонадежности, результаты техаудита, отзывы и иные материалы.
Если один филиал уже проводил проверку поставщика, другие подразделения могут использовать эти данные без повторного прохождения полного цикла проверки. При необходимости поставщик может быть добавлен в стоп-лист на уровне холдинга, что ограничит работу с ним во всех филиалах.
5. Интеграция с электронными торговыми площадками
Интеграция с электронными торговыми площадками позволяет сократить ручной перенос данных.
После завершения торгов площадка формирует файл с данными о номенклатуре, поставщиках, ценах и этапах торгов. Этот файл загружается в протокол тендерной комиссии. Далее данные используются в учетной системе филиала и центральной системе холдинга.
Такой подход снижает трудозатраты менеджеров по закупкам и уменьшает риск ошибок при ручном вводе информации.
6. Отчеты и аналитика
Отчетность используется для контроля и анализа закупочной деятельности.
В системе могут быть реализованы:
- отчет по результатам торгов;
- реестр протоколов тендерных комиссий;
- отчет по свободным остаткам филиалов;
- аналитика эффективности закупочного процесса;
- контроль соответствия фактических закупочных цен утвержденным условиям.
Общая схема всех взаимодействий представлена ниже.
Рис. 2. Общая схема процессов
Интеграция АСУЗ и ERP-систем филиалов
Интеграция между АСУЗ (холдинг) и учетной системой филиала реализована через HTTP-сервисы, что обеспечивает асинхронный и безопасный обмен данными. Ключевым принципом является то, что филиалы не обмениваются данными напрямую друг с другом; вся информация проходит через ядро АСУЗ. Это упрощает контроль версий данных и повышает информационную безопасность.
Основные потоки интеграции включают:
1. Передачу данных о свободных остатках: Автоматизированная выгрузка данных из ЕРП-системы в систему АСУЗ о свободных остатках ТМЦ филиала (неликвидных и невостребованных), которые доступны для реализации организациям всех филиалов холдинга. В ERP-системе филиала доступен просмотр свободных остатков ТМЦ всех филиалов холдинга и поиск по общей базе свободных остатков.
2. Передачу заявок на закупку: Филиалы отправляют в АСУЗ списки номенклатуры, подлежащей закупке. АСУЗ присваивает этим заявкам регистрационные номера для последующего анализа и эффективности поиска ресурсов.
3. Обмен документами «Протокол тендерной комиссии»: После согласования в учетной системе филиала протокол отправляется в АСУЗ, где получает уникальный номер холдинга. Затем этот номер возвращается обратно в ERP-систему филиала, закрывая цикл «тендер — договор».
4. Синхронизацию контрагентов: Карточки поставщиков с прикрепленными файлами проверки благонадежности и техаудита передаются в АСУЗ для формирования единого реестра.
Контроль протоколов и согласований
Одним из самых сложных элементов в управлении закупками является контроль исполнения принятых тендерных решений. В архитектуре это реализовано через механизм связывания ключевых документов в модуле «Тендерные закупки»:
1. «Протокол тендерной комиссии»: Новый объект в 1С:ERP. Он формируется на основании заявок на торги, прошедших на ЭТП. Включает в себя вкладки: участники торгов, обеспечение потребности (заявки на потребность), этапы торгов (с расценками победителей), условия поставки, решение комиссии, договоры протокола. Данный документ фиксирует все данные по торгам и направляется на централизованное утверждение и получает официальный номер.
Рис. 3. Протокол тендерной комиссии
Для фиксации статуса согласования протокола внутри филиала предусмотрен реквизит «Статус».
Для фиксации состояния согласования протокола холдингом предусмотрен реквизит «Состояние».
История движения документа фиксируется в регистре.
Рис. 4. История состояний ПТК
Таким образом обеспечивается контроль движения и согласования протоколов.
2. Контроль договоров: При создании договора в рамках тендера система требует обязательной ссылки на утвержденный протокол. Если у протокола отсутствует номер регистрации из АСУЗ (признак того, что тендер прошел и утвержден на уровне холдинга), запись договора блокируется.
Рис. 5. ПТК, вкладка Договоры протокола
Также реализована возможность прослеживать наличие текущих договоров победителей торгов непосредственно в самом протоколе.
Рис. 6. Действующие договоры
3. «Ценовая книга»: На основании согласованных протоколов формируется документ «Установка цен номенклатуры». Это исключает ручной ввод цен при создании заказов поставщикам, гарантируя, что закупка идет по утвержденной цене тендера.
Механизм передачи остатков
Для снижения закупок «со стороны» и повышения оборачиваемости внутри холдинга реализован модуль «Невостребованные остатки». Механизм работы включает:
1. Формирование «Свободных остатков»: Условия определения свободных остатков устанавливает холдинг. В нашем примере, к свободным остаткам относятся невостребованные запасы, которые хранятся на складе без движения дольше определенного срока (обычно 180 дней) или меньше определенного срока, но филиал готов их продать. По данному алгоритму в ERP-системах филиалов отдел закупок или сотрудники склада формируют документ «Реестр невостребованных остатков».
Рис. 7. Реестр невостребованных остатков
2. Филиал принимает решение: Ответственный сотрудник устанавливает статус «Невостребованный остаток» для позиций к продаже и устанавливает внутреннюю цену продажи.
3. Агрегация: Регламентное задание (раз в сутки) ЕРП-система отбирает номенклатуру, готовую к перепродаже и отправляет в АСУЗ. АСУЗ собирает эти данные в единую таблицу.
4. Гибкий поиск и резервирование: Менеджер по закупкам, работая в своем «АРМ менеджера по закупкам», видит потребность. Если товара нет на своем складе, он запускает процедуру гибкого поиска по остаткам других филиалов. Система строит рейтинг совпадений.
Рис. 8. Поиск в АСУЗ
Реестр поставщиков и стоп-лист
Архитектура предусматривает переход от разрозненных баз контрагентов к единому реестру поставщиков уровня холдинга.
Каждый филиал при заключении договора (особенно по итогам тендера) отправляет в АСУЗ карточку поставщика вместе с пакетом проверочных документов («Проверка благонадежности», «Техаудит», «Отзыв о поставщике»). Если в системе уже есть такой поставщик, данные обновляются, а новые файлы подшиваются к существующей карточке.
Рис. 9. Карточка поставщика
Любой филиал, планируя закупку, может запросить в АСУЗ данные о поставщике, включая историю работы с ним в других обществах холдинга.
Рис. 10. Обработка «Реестр поставщиков»
Это позволяет выявлять недобросовестных контрагентов и формировать «Стоп-лист» на уровне всей группы компаний, запрещающий взаимодействие с ними.
Безопасность и масштабируемость
Распределённая архитектура обеспечивает высокий уровень безопасности и готовность к расширению.
Разделение данных
Филиалы работают в своих изолированных базах 1С. Они не имеют прямого доступа к операционным данным других филиалов. Через центральную систему им доступны только те сведения, которые необходимы для выполнения закупочных процессов: агрегированные свободные остатки, публичная информация о поставщиках, данные по согласованным закупочным процедурам.
Прямого обмена между филиалами нет. Все взаимодействие проходит через АСУЗ, что повышает управляемость и снижает риски неконтролируемого распространения данных.
Клиент-серверная архитектура
Для стабильной работы при интенсивном обмене данными АСУЗ и базы филиалов должны работать в клиент-серверном режиме. Это особенно важно при использовании веб-серверов, HTTP-сервисов и регулярных обменов между системами.
Масштабируемость
Подключение нового филиала не требует изменения общей архитектуры. Достаточно развернуть необходимые HTTP-сервисы на стороне нового общества, настроить обмен с центральной системой и выполнить сопоставление локальных справочников.
АСУЗ при этом остается единым ядром, которое может обрабатывать возрастающий поток данных и подключать новые подразделения без перестройки всей модели.
Практический эффект от единого контура управления закупками
Внедрение такого подхода позволяет холдингу получить управляемую систему закупок без полной централизации операционной деятельности.
Основные эффекты:
- филиалы сохраняют самостоятельность в ежедневной работе;
- управляющая компания получает прозрачность закупочных процедур;
- снижается объем ручного ввода данных;
- уменьшается риск заключения договоров без утвержденных тендерных решений;
- появляется возможность использовать свободные остатки внутри холдинга до закупки у внешних поставщиков;
- формируется единая база поставщиков и результатов проверок;
- повышается качество контроля закупочных цен и условий поставки.
Заключение
Разработанная архитектура представляет собой компромиссное, но высокоэффективное решение. Она позволяет сохранить операционную автономность бизнес единиц, обязательных для быстрого реагирования на рыночные условия, но при этом выстраивает жесткий управленческий контур. За счет внедрения сквозных механизмов контроля (связка протокол — договор — ценовая книга), перераспределения внутренних ресурсов (модуль остатков) и централизации компетенций по работе с поставщиками, холдинг получает прозрачную, контролируемую и масштабируемую систему управления закупками на базе платформы 1С.