Система управления закупками: из чего состоит

Система управления закупками — это шесть связанных частей: заявка подразделения, маршрут согласования, выбор поставщика, заказ, приёмка и сверка счёта с заказом и приёмкой, плюс обмен с учётом, где остаются справочники, договоры и деньги. Цель системы в том, чтобы каждая закупка имела одну цепочку записей от потребности до платежа.

Заметная часть работы скрыта в связях между частями: в статусах, правилах и ролях. Ниже описано, как это устроено внутри; что вы получаете как заказчик и сколько это стоит, показано на странице «Разработка системы управления закупками».

Шесть частей системы и что в каждой хранится

Части можно собирать по одной, и многие компании начинают с двух-трёх. Таблица показывает, что делает каждая часть и откуда берёт данные.

Справочники остаются в учёте, потому что их менять придётся не только закупщикам. Если система закупок заведёт собственную номенклатуру, у позиции появятся два хозяина, как описано в статье про нормативно-справочную информацию.

Модель данных: почему главное — строки, а не документы

Заявка, заказ, приёмка и счёт — документы, но сверяются они по строкам. Одна строка заявки может превратиться в строку заказа одному поставщику, а другая в строку заказа другому. Часть строки заказа придёт одной приёмкой, остальное другой, счёт покроет две приёмки сразу. Если связывать только документы, ничего из этого не сверить.

Поэтому система хранит цепочку на уровне строк:

1. Строка заявки — что и сколько нужно, к какому центру затрат относится.
2. Предложение — что и по какой цене предложил поставщик на эту строку.
3. Строка заказа — выбранное предложение или позиция по рамочному договору, со ссылкой на строку заявки.
4. Строка приёмки — сколько фактически пришло, со ссылкой на строку заказа.
5. Строка счёта — что и по какой цене выставил поставщик, со ссылкой на приёмку или заказ.

По такой цепочке отвечают на вопросы, ради которых система и нужна: за что и кому заплатили по этой заявке, чем закрыта потребность подразделения, какие строки заказа остались невыполненными. Заранее проверьте, что учёт умеет отдавать идентификаторы строк, иначе связь придётся строить по эвристикам, а они дают сбои.

Статусы заказа поставщику: кто переводит и куда дальше

Статусы нужны не для красоты: по ним запускаются напоминания, сверка и отчёты. Правило одно: каждый переход делает конкретная роль или событие, и всё записывается в журнал. Пример набора статусов, который корректируется под процесс компании.

Отдельно хранится причина каждого отклонения и возврата. Через несколько месяцев это самый ценный источник для разбора: видно, какие заявки возвращают чаще всего, какие поставщики срывают сроки и на каком этапе встают закупки.

Правила согласования как данные, а не код

Маршруты меняются чаще, чем кажется: меняется структура, порог, согласующий, появляется новая категория. Если правила зашиты в код, каждое изменение превращается в доработку. Поэтому правила хранят как данные, которыми может управлять уполномоченный сотрудник заказчика.

• Условие. Сумма, категория, центр затрат, поставщик, признак срочности. Условия можно комбинировать.
• Действие. Кого подключить, в каком порядке, параллельно или последовательно, сколько времени отвести.
• Версия. Каждое изменение маршрута получает версию и дату. Заявки, которые уже в пути, дорабатываются по версии, действовавшей на момент подачи, если вы не решите иначе.
• Проверка. Перед сохранением маршрут прогоняется на примерах: что будет с заявкой на такую-то сумму от такого-то подразделения. Это защищает от дыр, когда заявка не подходит ни под одно условие.
• Исключения. Ручное вмешательство возможно, но записывается: кто, когда и почему изменил маршрут конкретной заявки.

Свобода правки имеет границу: правила, затрагивающие деньги и разделение обязанностей, меняет роль с отдельными правами, и такие изменения попадают в журнал. Иначе систему можно «настроить» так, что заявитель согласует собственную заявку.

Роли и разделение обязанностей

Роль определяет, что человек может сделать, а разделение обязанностей — какие роли нельзя совмещать в одной закупке. Второе важнее, и его проверяет система, а не регламент.

Права проверяет сервер на каждый запрос, а не только интерфейс. Приёмка включает отдельный прогон: из-под каждой роли пробуем сделать то, что ей не положено, в том числе по прямым адресам. Внешним пользователям (поставщикам) отдельная роль с доступом только к их заказам; такой кабинет описан на странице личных кабинетов.

Обмен с 1С и ERP: что и в какую сторону

Система закупок не заменяет учёт, и поэтому ключевой вопрос — как они обмениваются данными. Принцип: у каждого поля один хозяин. Справочники и договоры ведёт учёт, заявки и согласования ведёт система закупок, заказ рождается в системе и уходит в учёт, приёмка и оплата рождаются в учёте и возвращаются в систему.

• Копии, а не запросы на каждый клик. Справочники и бюджеты система закупок хранит копией, обновляемой по изменению. Закупщик не должен ждать ответа 1С при каждом открытии формы.
• Очередь и повтор. Если учёт недоступен, заказ ждёт в очереди. Повторная отправка не создаёт второй документ, потому что у заказа есть идентификатор, по которому учёт распознаёт дубль.
• Журнал обмена. По нему видно, что отправлено, что принято, что отклонено и почему. Без журнала разбор сбоя превращается в догадки.
• Ежедневная сверка. Количество заказов, суммы, выборка статусов. Расхождения разбирает названный человек.

Схемы обмена зависят от версии и настроек вашей учётной системы. Типовые варианты описаны на странице интеграции 1С, а принципы проектирования программного интерфейса для обмена между системами в статье «Проектирование API для интеграций».

С чего начинать внедрение и когда хватит 1С

Включать все части сразу не нужно. Порядок, который чаще всего оправдывается:

1. Одна категория закупок. Например, расходные материалы или ИТ-оборудование: понятные позиции, небольшое число согласующих, быстрый результат.
2. Заявка и маршрут. Первый эффект даёт прозрачность: видно, где заявка стоит и почему.
3. Заказ и приёмка с обменом. Закупщик перестаёт перепечатывать данные в учёт.
4. Сверка. Подключается, когда накоплена история приёмок и ясны допуски.
5. Запросы предложений и кабинет поставщика. После того, как внутренний процесс стабилен.
6. Отчёты. Когда понятно, какие решения по ним принимаются.

Заказная система не всегда нужна. Модуля закупок в 1С или ERP обычно достаточно, если контур один, согласующих немного, а маршрут не зависит от категории и суммы. Заказная система оправдана, когда маршрут нетиповой, нужен выбор поставщика по критериям, кабинет поставщика или несколько юридических лиц. Логика выбора между готовым и своим та же, что в статьях «Коробочное ПО или заказная разработка» и «Как выбрать ERP-систему».

Признаки, что процесс ещё не готов к автоматизации

Система делает процесс видимым и исполнимым, но не придумывает его за вас. Три признака, что сначала нужен порядок на бумаге.

Это не повод откладывать проект. Работу с правилами и справочниками удобно сделать в обследовании: её результат нужен и для системы, и для самой компании.

Что делаем мы и с чего начать

Начинаем с обследования: 200 000 ₽ и 2–3 недели за один-два процесса, 350 000 ₽ и 3–4 недели, если закупки связаны с несколькими системами и подразделениями. На выходе схема этапов, правила маршрутов в проверяемом виде, таблица источников данных и вилка бюджета. Стоимость вычитается из первого этапа, если продолжаете с нами, а документом можно пользоваться и без нас.

Дальше лёгкий пилот на одном маршруте (150 000–400 000 ₽, 2–8 недель) или первая версия для одной группы закупок как тяжёлый пилот (400 000–1 200 000 ₽, 2–3 месяца), на любой ступени можно остановиться. Мы работаем рядом с вашим учётом и не заменяем его, не подключаем торговые площадки, не принимаем платежи и не дежурим круглосуточно. Исходники лежат в вашем репозитории с первого коммита. Все цены и сроки — на странице «Тарифы», описание услуги — на странице «Разработка системы управления закупками».