Тендерная документация: из чего собирается пакет и где он разваливается

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

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

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

«Тендерная документация» означает две разные вещи

Разночтение снимается одной фразой: документация заказчика и пакет участника — это разные документы с разными авторами, и в текущей редакции 44-ФЗ они устроены по-разному ещё и структурно.

Со стороны заказчика. С 1 января 2022 года для открытых конкурентных способов закупки — открытого аукциона, открытого конкурса, запроса котировок — отдельная «документация о закупке» больше не составляется. Всё, что раньше было отдельным документом, теперь размещается заказчиком в извещении об осуществлении закупки (статья 42 44-ФЗ) и приложениях к нему: описание объекта закупки — по сути техническое задание (статья 33), обоснование начальной (максимальной) цены контракта, проект контракта, требования к участникам (статья 31). Термин «документация о закупке» в законе сохранился, но применяется только к закрытым процедурам — закрытому конкурсу и закрытому аукциону. Практическое следствие: если участник хочет что-то уточнить у заказчика, он теперь подаёт «запрос на разъяснение положений извещения», а не «запрос на разъяснение документации» — формулировка мелкая, но именно на таких деталях спотыкается человек, который последний раз готовил заявку до 2022 года.

Со стороны участника. Здесь термин обозначает пакет, который поставщик формирует и подаёт в ответ: заявку установленной структуры (статья 43 44-ФЗ), уставные документы, подтверждения правоспособности, техническое предложение и, где применимо, смету. Именно об этом пакете — весь дальнейший текст.

Последствие смешения этих двух пакетов — не абстрактное. Специалист, который открывает статью «что входит в тендерную документацию» и находит там описание извещения заказчика — обоснование НМЦК, проект контракта, требования к участникам, — иногда переносит этот список себе в чек-лист буквально, как будто это и есть перечень того, что нужно подать. Итог — заявка, собранная по неверному образцу: часть реально нужных документов участника (декларации, техническое предложение) в такой чек-лист не попадает, потому что она из другого документа с другим автором.

То, что запрос «тендерная документация заказчика» вообще существует как отдельная поисковая фраза, — не случайность. Он существует, потому что базовый запрос «тендерная документация» отвечает на два разных вопроса одновременно, и площадки, форумы закупок и вендорские блоги эту двусмысленность годами не разрешали, предпочитая писать общий текст, подходящий обеим аудиториям сразу. Как устроена документация по 223-ФЗ — где требования поверх федерального минимума задаёт собственное положение о закупке заказчика — разобрано в отдельном материале цикла.

Четыре слоя пакета участника

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

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

Слой 1 — уставные документы. Устав, ОГРН, ИНН, решение или протокол об одобрении крупной сделки, документы, подтверждающие полномочия подписанта. Меняются редко — по сути, только когда меняется сама компания: устав, директор, юридический адрес. Для большинства участников это статичный набор, который можно собрать один раз и обновлять по факту события, а не по расписанию.

Слой 2 — подтверждение правоспособности. Лицензии на вид деятельности, членство в СРО, аттестаты, банковские документы — выписки, справки об отсутствии картотеки, гарантийные письма банка. Этот слой обновляется периодически, но не по календарю тендера, а по собственному циклу: банковская справка устаревает через несколько недель независимо от того, идёт ли сейчас закупка. Это самый коварный слой пакета, и ему посвящён следующий раздел.

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

Слой 4 — смета. Расчёт цены под конкретный объект закупки — тоже заново под каждый тендер, с привязкой к позициям технического задания и, часто, к формам, которые заказчик прикладывает как отдельный файл.

Слои 3 и 4 болят предсказуемо: их видно, потому что без них заявку физически не подать. Слой 2 болит незаметно — документ формально есть, лежит в папке, но на момент подачи может быть уже неактуальным. Об этом — следующий раздел. Полный перечень уставных документов по 44-ФЗ и то, как правильно собрать слой 1 с нуля, — предмет отдельного материала , а разбор того, как читается смета заказчика построчно, — ещё одного.

Куда на самом деле уходит время

Ответ короткий: не на написание. По нашим замерам, коммерческий тендер — то есть закупка по правилам самого заказчика, без привязки к 44-ФЗ или 223-ФЗ, — занимает у собирающего пакет специалиста около 8 часов. Государственный тендер — около 40 часов, то есть больше рабочей недели на один пакет. Разница не в объёме текста технического предложения — она в объёме поиска и проверки того, что уже существует.

Один из пользователей системы формулирует эту разницу так: «Есть два вида условно тендера. Один, такой государственный, крупный, где надо просто всю поднагодную собрать.» Собрать всю подноготную — это и есть весь государственный тендер в трёх словах: не написать, а собрать — найти, проверить, приложить каждую бумагу, которую заказчик формально вправе потребовать.

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

На практике специалист редко ведёт тендеры одного типа последовательно — коммерческие и государственные приходят вперемешку, с разными сроками подачи. Государственный тендер с недельным циклом сборки, поставленный поперёк недели с тремя коммерческими, съедает весь остаток времени, и коммерческие начинают собираться в спешке — именно там, где цена ошибки в актуальности документа выше всего, потому что времени на проверку не остаётся.

Почему актуальность важнее полноты

Полный пакет, собранный из устаревших документов, срывается точно так же, как неполный, — просто позже, ближе к рассмотрению заявки, когда цена ошибки выше. Это не гипотеза: тот же пользователь, который описывал два вида тендеров, формулирует требование к себе так: «Главное, чтобы они были актуальны. Например, банковские документы должны быть актуальны.»

Здесь стоит закрыть вопрос, который до сих пор кочует по тендерным блогам как будто он актуален: требование «выписка из ЕГРЮЛ не старше шести месяцев» в действующей редакции 44-ФЗ как отдельная обязанность участника не встречается. В перечне содержимого заявки — статья 43 44-ФЗ — такого пункта нет. Эта норма восходит к прежней статье 61 44-ФЗ, которая требовала выписку из ЕГРЮЛ или ЕГРИП, полученную «не ранее чем за шесть месяцев» до даты обращения, — для аккредитации участника на электронной площадке. Статья 61, которая её содержала, из закона исключена. Сейчас порядок задаёт статья 24.2: участник один раз регистрируется в ЕИС, и данные из ЕГРЮЛ/ЕГРИП заказчик и площадка получают автоматически через ФНС. Регистрация в ЕИС действует три года, а выписку, которую участник обязан приносить и обновлять самостоятельно, с этого момента заменяет межведомственное взаимодействие.

Это на самом деле усиливает, а не ослабляет тезис раздела. Для регистрационных данных компании система сама гарантирует актуальность — участнику больше не нужно об этом думать. А вот банковские справки, лицензии, членство в СРО автоматически никто не обновляет: они лежат там, куда их положили в прошлый раз, и устаревают молча. Ровно об этом слое — «Правоспособность» из предыдущего раздела — и предупреждает пользователь, говоря про банковские документы.

Текущее решение этой проблемы в отрасли — не система, а человек. «У меня собрана одна папка со всеми вот этими базовыми документами», — так описывает свой рабочий процесс тот же специалист. Это рабочий, но хрупкий паттерн: личная папка держится ровно до тех пор, пока её владелец помнит, какой файл в ней актуален, а какой — версия трёхмесячной давности. Индекс существует, но живёт в голове одного человека, а не в общем хранилище команды.

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

Что читается машиной, а что нет

Ограничение здесь — не качество модели, а то, в каком виде документ вообще попадает в систему. Проще всего описать это как контракт из трёх уровней.

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

Уровень 1 — цифровой текст. PDF с текстовым слоем, DOCX, XLSX — документы, которые изначально созданы в цифровом виде, а не отсканированы. Здесь текст извлекается напрямую (на практике — через PyMuPDF), быстро и с высокой уверенностью. Это должно работать всегда, без исключений — на этом уровне отказ недопустим.

Уровень 2 — сканы и изображения внутри поддерживаемых форматов. Отсканированная страница, фотография документа, скан с рукописной пометкой. Здесь включается каскад: сначала распознавание страницы и текста через Yandex Vision, при необходимости — отдельный режим для таблиц и отдельный для рукописного текста; если и это не даёт уверенного результата — Tesseract на CPU как последний резервный вариант перед отказом. Каждый уровень каскада возвращает свою оценку уверенности; при низкой уверенности система не блокирует загрузку, а помечает документ значком «проверьте распознавание» — решение остаётся за человеком, а не скрывается за красивым, но ошибочным текстом. Если после всех трёх попыток текст извлечь не удалось, система отказывает открыто, а не отдаёт пустой результат, который выглядит как успех.

Уровень 3 — форматы, которые пайплайн сознательно не разбирает. PPTX, ODT, RTF, архивы — вне контура. Это не временное ограничение, а осознанная граница: система честно отказывается от форматов, где качество извлечения нельзя гарантировать, вместо того чтобы выдавать результат сомнительного качества под видом обработанного документа. Обещание «мы обрабатываем документы без ограничений по формату», которое иногда встречается у вендоров в этой категории продуктов, стоит воспринимать с подозрением — либо вендор не сталкивался с реальным разнообразием тендерных приложений, либо он не готов признать, где заканчивается его контур. Когда и почему включается OCR, а когда достаточно текстового слоя — подробнее в отдельном материале.

Формы внутри ТЗ: отдельная проблема

Отдельная категория сбоев — не про распознавание текста, а про то, что текст вообще не единственное, что нужно найти в документе. Технические задания заказчиков часто содержат формы для заполнения — таблицы, куда участник должен вписать свои данные, — но эти формы напечатаны как обычная сетка на странице PDF, без полей AcroForm и без какой-либо метки «это форма». Для обычного парсера это просто текст и линии; для человека, который открывает документ глазами, — очевидная форма, которую нужно заполнить и приложить отдельным файлом.

Причина в том, как такие технические задания обычно готовятся: заказчик собирает документ в Word, вставляет таблицу-форму как обычную таблицу и экспортирует итог в PDF. На выходе получается страница, которая выглядит как форма для человека, но для машины — просто набор линий и текстовых блоков без разметки «это поле для заполнения». Ни один парсер, ориентированный на обычный текст ТЗ, не выделит такую таблицу как нечто, требующее отдельного действия — она просто утонет среди остального содержания технического задания, а участник заметит её пропажу, только когда заявку вернут с замечанием о неполном комплекте.

Именно так это заметил пользователь системы, наткнувшись на реальное техническое задание: «В этом ТЗ прикреплены сразу формы для заполнения, и он их не видит, их надо туда вытаскивать отдельно.» Это ценный тип обратной связи — не жалоба на то, что система не работает, а точное указание, где заканчивается её текущая граница. Дальше это стало отдельным шагом в пайплайне: распознать такие блоки именно как формы, а не как обычный текст ТЗ, и вынести их отдельно для последующего заполнения — вместо того чтобы полагаться на то, что специалист сам заметит форму где-то на двенадцатой странице приложения. Как устроено автоматическое заполнение форм внутри .docx и .xlsx после того, как форма найдена и вынесена отдельно, — тема другого материала.

Где это ломается: 2 из 43

Самый честный абзац в этом тексте — не про успех, а про сбой. На одном из рабочих прогонов система распознала только 2 из 43 пунктов чек-листа заявки. Причина была не в качестве парсинга: в хранилище на тот момент было загружено только 4 из 41 документа, которые вообще нужны для этого тендера.

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

Это стоит держать в голове при оценке любого подобного инструмента, не только этого: демонстрация на чужом, заранее наполненном хранилище всегда выглядит убедительнее, чем первый запуск на своём. Разница — не в качестве инструмента, а в том, сколько документов в него уже загружено. Честный вендор скажет это прямо и заранее; менее честный — покажет чек-лист на 43 из 43 в демо и оставит владельца хранилища выяснять разницу самостоятельно, уже после оплаты внедрения. Разбор этого сбоя целиком — вместе с тем, что мы сознательно отказались строить, — в отдельном материале: «Что мы пробовали автоматизировать в документах — и отказались».

Второй принцип, который работает вместе с первым: совпадения — это всегда предложение, а не автоматическая привязка. Найденный документ подсвечивается как вероятное соответствие пункту чек-листа, но окончательное решение — приложить его или нет — остаётся за человеком. Причина простая: ошибочная автоматическая привязка обходится дороже, чем пропущенная подсказка. Если система молча подставит не тот банковский документ вместо актуального, ошибку заметят в лучшем случае на этапе рассмотрения заявки заказчиком — то есть слишком поздно, чтобы её исправить. Пропущенная подсказка стоит нескольких секунд внимания специалиста; неверная автоматическая подстановка стоит всей заявки. Как устроены сами механизмы сопоставления — и где нейросеть в документах систематически ошибается — отдельный разбор класса технологий. Что именно в этом контуре сознательно не стали автоматизировать и почему — отдельный разбор .

Что автоматизируется, а что остаётся человеку

Граница проходит не между «сложным» и «простым», а между тем, что можно проверить формально, и тем, что требует суждения. Извлечение текста, поиск нужного документа в хранилище, сопоставление найденного с пунктом чек-листа, подстановка данных в форму — всё это механизируется и уже механизировано. Решение о том, стоит ли вообще участвовать в конкретном тендере — по цене, по срокам, по репутационному риску, — не механизируется и не должно.

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

Оценочно, после внедрения система сокращает сборку коммерческого тендера примерно до 2 часов, государственного — примерно до 12. Это модельная оценка, выведенная из охвата продукта, а не результат хронометража: часть работы — согласование условий с клиентом, финальная проверка менеджером, для госзакупок ещё и физическое сканирование и нотариальное заверение отдельных документов — по-прежнему выполняется вручную и в оценку не включена так же аккуратно, как измеренные допродуктовые часы из раздела выше. Планируем двухнедельный хронометраж, прежде чем говорить об этих цифрах как об измеренном результате, а не оценке.

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

Есть вещи, которые в контур сознательно не добавлялись, потому что они там просто не нужны. Электронные подписи — характерный пример. Как формулирует один из руководителей, которые пользуются системой: «99 процентов случаев тендеры идут через тендерные площадки. Там не ставится никаких подписей.» Строить функциональность под то, что происходит на площадке, а не в документе, — потратить ресурс не туда. Инфраструктура, на которой всё это работает, — три виртуальные машины на Yandex Cloud, порядка 10 500 рублей в месяц по факту, — не то, что определяет экономику продукта; определяет её то, сколько часов специалиста высвобождается на слоях 2–4 из первого раздела. Полная структура эксплуатационного счёта — и, что важнее, честный список того, чего в этой цифре нет, — в «Сколько стоит эксплуатировать ИИ-обработку документов». Что ещё входит в этот контур автоматизации — четвёртый материал цикла .

Что дальше

Ключевое из этого текста: «тендерная документация» — это две разные вещи, и путать их — уже ошибка. Пакет участника раскладывается на четыре слоя с разной частотой обновления, и самый коварный из них — не техническое предложение, а подтверждение правоспособности, которое устаревает молча. Узкое место — не написание текста, а розыск и проверка того, что уже существует. И насколько полно наполнено хранилище документов, определяет качество всего, что происходит дальше, — честнее это признать сразу, чем обнаружить на 2 из 43.

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