В документации закупки встречаются условия разного назначения. Одни описывают товар или работу, другие — исполнителя, третьи — способ оценки предложения. Если собрать их в одну неразмеченную таблицу, легко принять желательное преимущество за обязательное условие или перепутать проверку результата с проверкой участника.
Разделите условия по объекту
Начните с вопроса «к чему относится этот пункт?». Характеристика оборудования относится к предмету поставки. Подтверждение опыта может относиться к участнику. Описание порядка расчёта баллов относится к оценке предложения. Точная роль условия должна подтверждаться текстом документа, а не предположением по знакомому термину.
Если роль неясна, сохраните отдельную категорию. ИИ может предложить классификацию, но рядом должна быть цитата и причина. Не нужно автоматически устранять неоднозначность, чтобы таблица выглядела завершённой.
Установите степень обязательности
Ищите формулировки, которые прямо описывают требование, допустимый вариант, исключение или оценку. Сохраните соседний контекст: перечень может начинаться на предыдущей странице, а оговорка — находиться после таблицы.
Не назначайте всем числовым условиям одинаковый статус. Количество поставляемых единиц, порог показателя и пример расчёта имеют разное значение. Для каждого укажите единицу, направление сравнения и область применения.
Если документ ссылается на внешний нормативный акт или положение, не делайте правовой вывод только по пересказу. Запишите, что требуется проверка актуального источника ответственным специалистом. Эта статья помогает организовать чтение, но не устанавливает правомерность конкретного требования.
Сопоставьте с подтверждениями
| Вид условия | Что проверять |
|---|---|
| Предмет поставки или работ | Характеристики, объём и способ приёмки |
| Участник или исполнитель | Какими сведениями подтверждается соответствие |
| Состав предложения | Какие материалы названы в документации |
| Критерий оценки | Какие данные влияют на оценку и как описан расчёт |
| Исполнение договора | Какие действия нужны после выбора поставщика |
Присутствие документа в вашей компании не означает, что он подходит для любого пункта. Сверьте предмет, срок действия и содержание подтверждения. Если данных не хватает, статус должен быть «требуется проверка», а не уверенное «соответствует».
Пример матрицы без выдуманных выводов
Для каждой строки оставьте пять полей: условие, тип, источник, имеющееся подтверждение и вопрос. В поле источника сохраните файл и блок; в поле подтверждения — известный факт вашей команды. Предположение модели не должно выглядеть как уже существующий документ.
Например, если в ТЗ названа совместимость с конкретной системой, запросите сведения о вашей предлагаемой конфигурации. Не делайте вывод из одного названия продукта. Если описан опыт похожих работ, проверьте, какие признаки сходства перечислены именно в документации.
Задание для агента
Раздели условия закупки на требования к предмету, участнику, составу предложения, оценке и исполнению. Для каждой строки сохрани формулировку, файл и блок. Не назначай обязательность по догадке. Отдельно покажи неоднозначные пункты, отсутствующие подтверждения и вопросы для ответственного специалиста. Не оценивай наши шансы в процентах.
После первого ответа проверьте несколько строк из каждой категории. Это помогает обнаружить систематическую ошибку классификации: например, когда все условия о документах агент отнёс к допуску, хотя часть касается приёмки готовой работы.
Что сделать перед решением
Сопоставьте матрицу с техническим чек-листом и условиями оплаты. Противоречия между ТЗ и договором оформите как вопросы с двумя цитатами. Не выбирайте более удобную редакцию без подтверждённого основания.
Сохраните дату проверки и набор файлов. Итогом такого разбора является проверяемый список фактов и задач команды. Он не является гарантией допуска, победы или успешного исполнения закупки.