От вопроса до принятия решения. От чистого листа к выбору поставщика — под контролем человека на каждом шаге.
Девять взаимосвязанных инструментов ведут закупку от структурированного интервью до готового технического задания и его независимой проверки: содержимое пишется в диалоге с моделью, формат, схему данных и полноту — фиксирует код.
Где сегодня теряются время и качество
Каждый этап закупки обычно делается заново: данные из ТЗ перепечатываются в запрос предложений, из ответов поставщиков — в таблицу сравнения, оттуда — в материалы для стейкхолдеров. Ошибки накапливаются на каждой пересборке, а пробел в исходном ТЗ обнаруживается уже после получения оборудования.
ТЗ с пробелами
Пропущенные параметры и размытые формулировки — поставщик трактует их в свою пользу.
Ручные пересборки
Данные перепечатываются на каждом этапе — ошибки умножаются при каждой передаче.
Несравнимые предложения
Поставщики отвечают в разных форматах — сведение вручную занимает дни.
Записка «наспех»
Обоснование для стейкхолдеров готовится в последний момент, без полной аналитики.
Девять инструментов, три роли
Генераторы собирают содержимое. Библиотеки фиксируют формат и контракт данных. Аудитор — независимая вторая пара глаз.
tz-creator
Интервью и генерация ТЗ на оборудование, запчасти, материалы, НИОКР/ОКР. Автоопределяет направление по смыслу описания.
tz-services
Ремонт/ТО, монтаж/демонтаж/ПНР, транспорт и хранение, прочие услуги — со своим шаблоном объёма работ вместо товарного.
tz-core
Единый стандарт структурированного реестра извлечённых требований и автоматическая проверка: структура, анонимизация, соответствие ссылок пунктам документа.
docx-ru-business
Одна и та же информация всегда оформляется в документ одинаково — шрифты, отступы и структура задаются автоматически, а не пересобираются вручную каждый раз.
tz-parser
Читает готовый документ заново — как поставщик или другие стейкхолдеры процесса. Работает автономно или как опциональный шаг после генерации.
rfq → tkp → пз
Запрос предложений, техническое сравнение, пояснительная записка — тот же структурированный реестр требований, без повторного разбора документа.
Генератор — чтобы писать. Аудитор — чтобы проверять
Разные задачи, общий стандарт данных между ними.
tz-creator / tz-services
Ведёт диалог с тем, кто составляет ТЗ, — механиком, энергетиком, технологом, закупщиком — по заранее канонизированному реестру вопросов для каждого направления закупки. Не полагается на то, что автор сам вспомнит все обязательные параметры: система знает, что критично для данного класса оборудования или вида услуги, и спрашивает по порядку.
- 8 направлений: оборудование, запчасти, материалы, НИОКР — для товаров; ремонт/ТО, монтаж/ПНР, транспорт, прочие услуги — для услуг
- Формат документа и структура реестра требований — одни и те же независимо от автора и его опыта
- Персональные и идентифицирующие данные исключаются из документа автоматически, при оформлении, а не по памяти составителя
Раздел «Технические требования» — как он выглядит на выходе
Таблица критических параметров и анонимизированное поле заказчика — фрагмент реального ТЗ (данные, идентифицирующие предприятие, скрыты в соответствии с правилами инструмента).
| Параметр | Значение | Категория |
|---|---|---|
| Грузоподъёмность номинальная | не менее 1,0 т | критический |
| Вылет консоли | 4,0 м | критический |
| Высота подъёма крюка от уровня пола | не менее 4,0 м | критический |
| Режим работы крана | А4 по ГОСТ 34017-2016 (ISO M5) | критический |
tz-parser
Читает готовый документ — сгенерированный или загруженный в любом другом виде — так, как его прочитали бы поставщик или другие стейкхолдеры: без доступа к тому, как он составлялся. Ищет пропуски, расплывчатые формулировки, внутренние противоречия и слепые зоны, специфичные для роли эксперта и отрасли.
- Работает автономно с любым загруженным ТЗ — не обязательно созданным генератором
- Каждое замечание привязано к конкретному пункту документа, а не сформулировано общими словами
- Результат — отчёт аудита (.docx) и структурированный реестр извлечённых требований (.json) для передачи дальше
Часы ручной работы — в минуты структурированного диалога
Каждое ТЗ, которое сегодня пишется вручную с чистого листа, и каждый аудит, который начинается заново, — это повторяющаяся рутина. Пайплайн забирает её себе, оставляя людям то, что действительно требует экспертизы.
- Оформление ТЗ каждый раз заново — шрифты, отступы, нумерация решаются вручную
- Расплывчатые или пропущенные требования обнаруживаются на этапе исполнения договора
- Анонимизация данных зависит от внимательности составителя
- У каждого документа свой формат реестра требований — сверка со следующим этапом вручную
- Качество ТЗ зависит от того, кто именно его составлял и сколько у него было времени
- Оформление фиксирует код — время уходит только на содержание, не на вёрстку
- Валидатор проверяет пробелы и расплывчатые формулировки до выдачи документа поставщику
- Анонимизация — встроенное правило оформления, а не пункт, который можно забыть
- Один и тот же формат данных на каждом шаге — следующий этап получает их без пересборки вручную
- Реестр вопросов и шаблон направления одинаковы независимо от того, кто ведёт интервью
занимает автоматическое оформление готового документа — вместо часов ручной вёрстки под каждый случай
данные не перепечатываются между интервью, документом и реестром требований
момент, когда ловится пробел в требованиях — а не после получения оборудования
Меньше форматирования — больше закупки
- Готовый документ на выходе интервью — не нужно вспоминать структуру раздела и нормативные ссылки под каждое направление
- Анонимизация не требует внимания — идентифицирующие поля исключаются автоматически при оформлении, а не по чек-листу в голове
- Единый формат реестра требований — не нужно вручную сводить данные ТЗ с таблицей запроса предложений на следующем этапе
- Меньше возвратов на доработку — валидатор ловит пропуски до отправки поставщику, а не после его вопросов
Не нужно самому знать, как правильно писать ТЗ
- Структурированный диалог вместо чистого листа — систему не нужно ничего вспоминать, она сама спрашивает то, что критично для класса закупки
- Меньше циклов согласования — типовые замечания снимаются на этапе интервью, а не возвращаются с аудита через неделю
- Не требует опыта составления ТЗ — реестр вопросов одинаков для новичка и для инженера с 20-летним стажем
- Черновик сохраняется автоматически — прерванное интервью можно продолжить с того же места, не начиная заново
Меньше вычитки — больше содержательной экспертизы
- Документы приходят в одной структуре — сравниваете их между собой, а не разбираетесь заново с форматом каждого автора
- Рутинные замечания снимаются до вас — пропуски и расплывчатые формулировки ловит валидатор, время уходит на содержательную оценку
- Консультация становится точечной — тот, кто пишет ТЗ, получает структурированный диалог, а не объяснение формата с нуля
- Работает с любым документом — можно проверить и файл, написанный без инструмента, без доступа к тому, как он составлялся
Сколько это экономит в часах
иллюстративный расчёт — подставьте свои цифрыОценка построена на условных вводных ниже — они основаны на опыте, а не на измерениях конкретного отдела. Замените количество ТЗ и часы на свои, чтобы получить оценку для своей ситуации.
Сведение ТКП от поставщиков
Тот же принцип — для этапа сравнения предложений, где сегодня различия в формате ответов съедают больше всего времени.
Не абстракция: в реальном проекте с кранами консольными матрица соответствия включала 90 строк требований по 2 позициям оборудования — свести такой объём вручную по нескольким поставщикам за один вечер физически невозможно. Пример этой матрицы — ниже.
Рост качества — не декларация, а поиск слепых зон
Расплывчатые формулировки и пропущенные параметры обычно всплывают на этапе исполнения договора — когда цена ошибки уже не часы работы, а сорванный срок поставки или спор с поставщиком. Валидатор и опциональный независимый аудит (tz-parser) сдвигают этот момент на этап составления документа.
направлений закупки прошли сквозной тест «интервью → документ → валидация» без единой ошибки на выходе
ошибок и предупреждений в финальном прогоне каждого тестового сценария
ссылок из реестра требований на пункты документа подтверждаются механической кросс-проверкой, а не визуальной сверкой
Как выглядит замечание аудита
Фрагмент реального аудита ТЗ на консольные краны — не выдуманный пример, а настоящие находки, которые дал этот класс проверки перед выпуском в тендер.
Из 42 извлечённых требований — 15 пропусков, 5 из них критические
Технические параметры (грузоподъёмность, вылет, высота, режим работы) сформулированы в SMART-формате, все обязательные разделы на месте — но 5 критических пропусков блокировали выпуск ТЗ в тендер без доработки.
Цель закупки — разгрузка бухт, но самого технического средства захвата груза (траверса, С-образный захват, стропы) в ТЗ нет. Без этого пункта поставщик вправе не включать его в комплект поставки.
Не зафиксирована отметка низа ферм перекрытия в месте установки. Риск несоответствия габаритов — вплоть до невозможности монтажа на площадке.
При двух единицах на одной площадке схема с зонами обслуживания упомянута как опциональное приложение. Без нее невозможен контроль коллизий зон обслуживания между кранами — риск столкновения при одновременной работе.
Один проход — от вопроса до готового и проверенного файла
Каждый шаг можно проверить и воспроизвести отдельно — результат не зависит от того, кто и когда его получает.
Диалог по стандартным вопросам
Вопросы и их порядок закреплены для каждого типа закупки — формулировки не зависят от того, кто именно ведёт интервью.
черновик сохраняется автоматически после каждого блока вопросовОтветы превращаются в содержание документа
Ответы складываются в структуру разделов, полей и таблиц. Поля с личными данными помечаются как пустые — их заполняют от руки.
Документ оформляется автоматически
Форматирование, шрифты, отступы и футер задаёт программа — а не текстовое описание, которое пересказывается заново в каждой сессии.
Проверка перед выдачей
Полнота структуры, отсутствие персональных данных, соответствие ссылок реальному тексту документа — до того, как файл увидит поставщик, а не после.
Независимая проверка — по желанию
С согласия пользователя документ уходит на повторное, независимое прочтение — без участия в том, как он составлялся.
Восемь направлений в двух доменах
Каждое — со своим блоком интервью, шаблоном документа и чек-листом типичных ошибок.
Товары — tz-creator
- Оборудование протестировано
- Запчасти / ЗИП протестировано
- Материалы протестировано
- НИОКР / ОКР протестировано
Услуги — tz-services
- Ремонт и ТО протестировано
- Монтаж / демонтаж / ПНР протестировано
- Транспорт и хранение протестировано
- Прочие услуги протестировано
Дальше — запрос предложений, техническое сравнение, материалы для стейкхолдеров
Генератор и аудитор — первые два звена. Дальше тот же реестр требований REQ-ID едет по цепочке без пересборки вручную — и на каждом шаге решение остаётся за человеком.
rfq-generator
Собирает сущности требований из сгенерированного ТЗ или из версии, прошедшей независимый аудит, и формирует структурированную таблицу запроса предложений: каждая строка — отдельный REQ-ID с полем для ответа поставщика по этому конкретному пункту, а не сплошной текст. Поставщики отвечают в едином формате — их ответы сопоставимы между собой сразу, без ручной сверки различных Excel и писем.
Каждая строка — отдельный пункт ТЗ со своей категорией
Фрагмент реальной матрицы по проекту с кранами — колонки «Соответствие» и «Предлагаемое значение» заполняет поставщик уже вне этого инструмента.
| Параметр | Значение по ТЗ | Категория | Ответ поставщика |
|---|---|---|---|
| Грузоподъёмность номинальная | не менее 1,0 т | критич. | заполняет поставщик |
| Вылет консоли | 4,0 м | критич. | заполняет поставщик |
| Режим работы крана | А4 по ГОСТ 34017-2016 | критич. | заполняет поставщик |
| Скорость подъёма крюка | 8 м/мин основная | некритич. | заполняет поставщик |
tkp-comparator
Сравнивает не коммерческие предложения целиком, а существенные технические параметры ответов каждого поставщика против исходного ТЗ — построчно, по каждому REQ-ID. Коммерческая часть в это сравнение не входит, поскольку относится к чувствительной информации, которая не должна передаваться в модель. Все остальные данные передаются отдельным JSON без ручного переноса и, соответственно, без риска ошибки при копировании.
pz-writer
Готовит пояснительную записку с обоснованием именно технического решения — почему предложение соответствует ТЗ лучше остальных по существу, а не по цене. Это не факт совершённой закупки, а материал для дальнейшей оценки стейкхолдерами — окончательное решение принимают они, а не документ.
Почему выбор пал именно на это предложение
«Предложение Поставщика А полностью соответствует критическим параметрам ТЗ: грузоподъёмность, вылет консоли, высота подъёма крюка, режим работы А4 по ГОСТ 34017-2016. Отдельно отмечается включение грузозахватного приспособления для разгрузки бухт — критическое дополнение, отсутствовавшее в исходной редакции ТЗ и включённое по результатам технического аудита. С технической точки зрения предпочтительным является предложение Поставщика А.»
Human-in-the-loop сохраняется на каждой стадии
не автоматизация решенийНи один инструмент в этой цепочке не принимает решение вместо человека — каждый готовит структурированный материал, на основе которого решение принимает специалист. Это касается всех пяти этапов одинаково:
Черновик ТЗ по ответам заказчика — специалист проверяет и утверждает документ, а не публикует черновик как есть.
Замечания аудита — это находки для рассмотрения, не автоматическая правка документа: решение, что исправлять, за экспертом.
Запрос и сравнение параметров формируются автоматически, но состав запроса и итоговая оценка поставщика — решение специалиста.
Обоснование технического решения — входные данные для стейкхолдеров, а не сама закупка. Решение принимают они коллегиально.