Иерархия боли в закупках: от НМЦК до compliance

Где в закупках теряются деньги и время: ТЗ, НМЦК, проверка норм (44-ФЗ / 223-ФЗ). Как автоматизировать после аудита, без выноса пакетов в чужие чаты.

Коротко

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

  • Деньги. НМЦК завышена, занижена или не обоснована.
  • Подрядчики. Кто прошёл, кто нет, почему.
  • Документы. Скорость и качество ТЗ, спецификаций, обоснований.
  • Люди. Кто готовит, кто проверяет, кто подписывает.
  • Системы. Связаны ли 1С, Excel, почта и нормативная база.

Автоматизировать имеет смысл после того, как понятно, где именно потери. Та же рамка, что на всём сайте: аудит → реинжиниринг (схема) → инструменты → пилот.

Про «Axis» в этом тексте

Axis здесь пример архитектуры (референс), как может выглядеть локальная система для смет и обоснования НМЦК в логике 44-ФЗ / 223-ФЗ.

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

Что такой контур обычно умеет:

  • разбор ТЗ: вытащить позиции сметы из нормальных и «кривых» документов;
  • рыночные опоры: цены из доступных источников и баз контрактов (в рамках права доступа);
  • НМЦК: расчёт по утверждённым методикам, а не «от руки в Excel»;
  • проверка норм: сопоставить пункт ТЗ с нормой и показать расхождение (поиск по своей нормативной базе + языковая модель в вашем контуре);
  • отчёты: обоснования и спецификации в Word/Excel без бесконечного копипаста.

Иерархия боли в закупках

1. Деньги / НМЦК

НМЦК это итог цепочки: ТЗ → рыночные цены → методика → нормативы. Если на шаге есть обходы или неформальные договорённости, цена потом не устоит в проверке.

Симптом: закупка прошла, претензии контролирующих органов пришли позже.

2. Подрядчики / отбор

Кто отсеивается, кто проходит, почему. Если критерии не формализованы или проверка вручную, теряется время и растёт риск необъективности.

Симптом: похожие заявки проверяют по-разному; проверка тянется неделями.

3. Документы и заявки

ТЗ, спецификации, обоснования. Если всё в Word/Excel, а норма лежит в PDF и бумажных справочниках, скорость падает, ошибки копируются.

Симптом: исполнитель дольше ищет норму, чем анализирует содержание.

4. Роли

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

Симптом: один человек и пишет ТЗ, и «проверяет» цены, и закрывает заключение.

5. Связка систем

1С, Excel, почта, нормативная база, система закупок. Одна картина или пять файлов «как договоримся».

Симптом: данные не сходятся; решение принимают «по последнему файлу в переписке».

Как это автоматизируется (после диагноза)

Своя база нормативных актов + поиск + языковая модель в локальном контуре. Не «нашёл статью в интернете». Связал норму с пунктом ТЗ и показал, где расхождение.

Разбор пакета несколькими шагами

Один контур ставит задачу, другие тянут цены, нормы, черновик обоснования; есть лимит на «перепридумать» и эскалация ошибок. Подписывает человек, модель готовит.

Интерфейс для отдела

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

Безопасность

  • работа в периметре заказчика;
  • роли и ограниченные права;
  • ТЗ и закупочные пакеты не уезжают во внешний API «потому что удобно».

Что получает предприятие

Этап Результат
Аудит (как есть) Карта узких мест и рисков в закупках
Схема (как станет) Вердикты по узлам + целевой маршрут
Инструменты Разбор ТЗ, проверка норм, опоры для НМЦК, отчёты
Пилот Один участок, метрика «было / стало», решение о масштабе

Где это уместно

  • гос- и корпоративные закупки в логике 44-ФЗ / 223-ФЗ;
  • обоснование НМЦК (строительство, IT, услуги, поставки);
  • контроль спецификаций и ТЗ;
  • разбор цен и КП без выноса чувствительных пакетов наружу.

Дальше по сайту

Павел Наумов, Санкт-Петербург.

← Все материалы Запросить разбор: +7 921 780-97-40 Принцип метода APRE