«Подготовить тендерную документацию» звучит как одна задача, а на практике это четыре разные: понять, кто вообще имеет право подать заявку, собрать состав заявки, разобрать техническое задание и правильно оформить формы. Спутать эти четыре задачи местами — не тонкость методологии, а причина конкретных потерь времени: специалист открывает самый длинный раздел закупки первым, потому что он выглядит как содержательная работа, и находит причину для отказа уже после того, как часы потрачены.
Часть тендерных специалистов такую подготовку не делает сама — отдаёт её на аутсорс или нанимает отдельного человека под конкретную закупку, и это рабочий вариант: маршрут ниже одинаково применим и к своей команде, и к подрядчику, которому нужно объяснить, в каком порядке действовать.
Коротко. Подготовка пакета — это маршрут с фиксированным порядком, а не список дел в произвольной последовательности: сначала требования к участникам (кто вообще может подать), затем состав заявки (что подать), затем разбор технического задания (что предложить), и только в конце — формы и оформление. Обратный порядок — частая практическая ошибка: специалист садится за самый объёмный раздел первым и находит стоп-фактор допуска, когда часы над техническим предложением уже потрачены. По нашей оценке — не по хронометражу — коммерческий тендер занимает порядка 8 часов, государственный — порядка 40, и большая часть этого времени уходит не на работу с ТЗ, а на розыск и проверку уже существующих документов. Автоматизация встроена в маршрут точечно: извлечение, раздельный чек-лист и сопоставление — за системой, решения и подтверждение — за человеком.
Что на самом деле входит в «подготовку»
«Подготовка» — это не одна операция, а как минимум два разных источника информации и один пакет, который из них собирается. Первый источник — где лежат требования к самой возможности участвовать. По 44-ФЗ для открытых процедур это извещение об осуществлении закупки: статья 42 закона с 2022 года объединяет описание объекта закупки, требования к участникам и критерии оценки в одном документе, отдельно готовящейся документации здесь больше нет. По 223-ФЗ — наоборот: документация о закупке существует как отдельный обязательный документ для конкурса и аукциона, а конкретный состав требований поверх закона задаёт положение о закупке заказчика, и у каждого заказчика оно своё. Маршрут ниже работает для обоих случаев одинаково — разница только в том, где именно искать первый источник: в одном файле или в двух.
Второй источник — то, что участник собирает в ответ. В материале о структуре пакета участника этот пакет разложен на четыре слоя с разной частотой обновления: уставные документы (меняются раз в год и реже), подтверждение правоспособности — лицензии, СРО, банковские справки (обновляются каждые несколько месяцев независимо от календаря тендера), техническое предложение и смета (собираются заново под каждую закупку; как разбирается смета заказчика построчно — отдельная тема). Тот материал — про то, откуда берутся сами слои; этот — про то, в каком порядке к ним подступаться, чтобы не терять время впустую.
Подготовка пакета путает эти два вопроса местами, когда специалист садится читать закупку с самого длинного раздела вместо самого важного. У этой путаницы есть и третье измерение — разное по трудоёмкости содержание разных категорий закупок. Небольшая коммерческая закупка с типовым техническим заданием и десятком уставных документов проходит весь маршрут быстро именно потому, что каждый шаг короткий; крупная государственная закупка с развёрнутыми требованиями к участникам, объёмным техническим заданием и отдельными формами для каждого раздела растягивает тот же маршрут в несколько раз дольше — не потому что логика меняется, а потому что каждый шаг становится длиннее. Маршрут остаётся одним и тем же в обоих случаях — разным оказывается только объём работы внутри каждого шага. Дальше — про перестановку шагов местами и про то, как маршрут её снимает.
Правильный порядок: почему не с ТЗ
Порядок сборки — не рекомендация для новичков, а простая логика затрат: дешёвые по времени проверки идут первыми, дорогие по трудозатратам — последними. Четыре шага друг за другом: требования к участникам (годитесь ли вы вообще для подачи) → состав заявки (что нужно собрать и приложить) → техническое задание (что конкретно предложить) → формы и оформление (как это упаковать). Каждый следующий шаг имеет смысл только при условии, что предыдущий пройден. Это порядок сборки собственного пакета; порядок чтения самой публикации заказчика — требования, ТЗ, проект контракта, критерии оценки — разобран в материале про извещение по 44-ФЗ.
Правильный маршрут отсекает недопустимые закупки на первом шаге; обратный порядок находит ту же причину отказа только после часов работы над ТЗ.
Чаще всего порядок ломается на первом шаге — не потому что требования к участникам сложны, а потому что они короткие и скучные на фоне технического задания. ТЗ выглядит как содержательная работа: там объём, там конкретика, там понятно, с чего начать печатать текст предложения. Требования к участникам — несколько абзацев про лицензии, опыт аналогичных контрактов, форму обеспечения заявки — легко пролистать по диагонали и вернуться к ним позже, когда «станет время».
Цена такой перестановки асимметрична. Стоп-фактор в требованиях к участникам, найденный в первую очередь, отсеивает закупку за несколько минут чтения — компания либо подходит по формальным критериям, либо нет, и вопрос об участии закрывается сразу. Тот же стоп-фактор, найденный после нескольких часов работы над техническим предложением, отсеивает уже потраченное время: цена ошибки не в самом факте несоответствия, а в том, на каком шаге маршрута его обнаружили. Требования к участникам не важнее остального пакета по содержанию — они просто дешевле для проверки первыми, и маршрут использует именно эту дешевизну.
Разбор ТЗ: чек-лист документов и технические требования — это два разных списка
Второй источник потерь — не то, что ТЗ читают, а то, что его читают один раз вместо двух. Техническое задание в закупке одновременно отвечает на два разных вопроса: что нужно приложить к заявке (список документов, форм, деклараций) и что нужно предложить по существу (характеристики, объёмы, сроки, показатели эквивалентности, если допускаются аналоги). Смешать эти два списка в один проход — обычный источник потерянных пунктов: специалист читает ТЗ линейно, попутно отмечая то одно, то другое, и часть требуемых документов остаётся не выписанной отдельно, потому что внимание в момент чтения было занято техническими показателями.
Ручная дисциплина здесь простая — два прохода вместо одного. Первый проход — только чек-лист документов: что заказчик требует приложить, в каком формате, к какому сроку. Второй — только технические требования: характеристики предмета закупки, объёмы, сроки исполнения. Каждый проход держит один список активным, а не оба сразу — смешивать их снова означает возвращаться к той же ошибке, только на бумаге вместо экрана.
Ровно эту дисциплину мы автоматизировали в системе, которая с 8 апреля 2026 года ежедневно разбирает поступающие ТЗ в производстве: она извлекает из технического задания чек-лист требуемых документов отдельно от списка технических требований — двумя параллельными списками, а не одним смешанным. Там, где извлечение получилось с сомнением — нечёткий скан, двусмысленная формулировка пункта, — система помечает пункт как требующий проверки, а не отбрасывает его молча: непроверенный пункт остаётся видимым в результате, а не пропадает из него. Повторный разбор того же технического задания — например, после уточнения от заказчика — не стирает уже собранный чек-лист заново, а дополняет его: результат идемпотентен относительно неизменной части документа.
Что можно сделать один раз заранее
Не весь маршрут одинаково срочный. Слой уставных документов и часть подтверждения правоспособности — в материале о структуре пакета участника это самый медленно обновляемый набор — можно закрыть один раз, а не собирать заново под каждую закупку. Устав, ОГРН, решение об одобрении крупной сделки, типовые справки, шаблон технического предложения под повторяющиеся категории закупок — весь этот набор безопасно держать готовым в хранилище и обновлять по факту события (смена директора, юридического адреса), а не по расписанию тендера.
Единственная ловушка здесь — не полнота набора, а его актуальность на дату подачи. Банковские справки и подобные документы устаревают молча: они физически лежат в папке, выглядят как готовые, но к моменту очередной подачи могут оказаться просроченными на несколько недель. Пользователь системы отдельно предупреждает именно про этот слой — про банковские документы, которые нужно держать актуальными, а не просто иметь в наличии: актуальность здесь важнее полноты, и проверка даты выдачи должна быть отдельным шагом маршрута, а не подразумеваться автоматически потому что документ в принципе существует.
Практический вывод простой: инвентаризация хранилища — до, а не во время подготовки конкретной заявки. Специалист, который один раз навёл порядок в наборе типовых документов и завёл привычку проверять сроки их действия, тратит на первый шаг маршрута минуты, а не часы; специалист без такого хранилища каждую подготовку начинает с розыска того же самого набора заново.
Формы и оформление: последняя миля
Формы — последний шаг маршрута не случайно: до них есть смысл добираться только тогда, когда допуск подтверждён, состав заявки понятен, а техническое предложение готово по существу. Но именно на этом шаге чаще всего теряют время те, кто уверен, что самая трудная часть уже позади.
Проблема в том, что часть форм, которые нужно заполнить, физически встроена в текст технического задания как обычная таблица внутри PDF — без полей для ввода и без какой-либо разметки, отличающей её от остального текста. Для человека, читающего документ глазами, это очевидная форма для заполнения. При беглом просмотре — просто ещё один блок текста среди десятков страниц приложения, который легко не заметить до момента, когда заявку возвращают с замечанием о неполном комплекте. Как такие формы находятся и заполняются автоматически внутри .docx и .xlsx — отдельный разбор.
Дальше — механика заполнения: перенести данные компании и предложения в форму .docx или .xlsx, соблюдая точную структуру, которую задал заказчик. Это не творческая задача, а точная, и именно поэтому она отнимает непропорционально много времени относительно своей содержательной сложности: ошибиться в ячейке легче, чем в абзаце свободного текста, а проверить итог перед подачей — дольше.
Последняя миля маршрута съедает время не потому что формы сложны сами по себе, а потому что до них добираются в конце — уже после часов работы над техническим предложением и сметой, когда внимание не такое свежее, как в начале. Именно тогда легче пропустить форму, спрятанную внутри ТЗ.
Есть и обратная ошибка — начать с форм, потому что они выглядят как самая понятная, механическая часть работы, которую приятно закрыть первой. Проблема та же, что и с обратным порядком в начале маршрута: заполненная форма, в которую позже придётся вносить правки из-за уточнённого технического предложения или изменившегося состава заявки, — это форма, заполненная дважды. Оформление имеет смысл делать один раз и в конце, когда остальные три шага уже устоялись и переделывать под них ничего не придётся.
Где в маршруте помогает автоматизация — и где нет
Граница между тем, что стоит автоматизировать, и тем, что должно остаться за человеком, проходит не по сложности задачи, а по тому, опирается ли она на проверяемый факт или требует суждения. Извлечение текста из ТЗ и извещения, раздельный чек-лист документов и технических требований, поиск подходящего документа в хранилище и предложение вероятного соответствия пункту чек-листа — всё это опирается на факты, которые можно проверить, и поддаётся автоматизации без потери качества решения.
Граница проходит не по сложности задачи, а по тому, опирается ли она на проверяемый факт или требует суждения.
Решение о том, приложить ли найденный документ, участвовать ли вообще в конкретной закупке, как оформить неоднозначный пункт технического предложения, — это суждение, а не факт, и оно остаётся за специалистом. Найденное системой соответствие — это всегда предложение, а не автоматическая подстановка: ошибочная привязка не того документа обходится дороже, чем момент, потраченный человеком на подтверждение правильной.
Мы в Кельве строим систему именно вокруг этой границы: с 8 апреля 2026 года она ежедневно разбирает поступающие ТЗ в производстве, разделяя чек-лист документов и технических требований и предлагая найденные документы как кандидатов для подтверждения, а не как готовое решение. Маршрут — требования к участникам → состав заявки → ТЗ → формы — работает одинаково независимо от того, ведёте вы его вручную, силами подрядчика или с системой: она ускоряет розыск и сопоставление внутри каждого шага, но не меняет сам порядок шагов и не берёт на себя решения, которые вы принимаете сами. Похожая логика применима и после подачи заявки, если объявлен повторный раунд снижения цены: что такое переторжка и сколько она стоит по времени — отдельный разбор в этом же цикле.
Из всего маршрута один вывод стоит держать в голове дольше остальных: правильный порядок не сокращает объём работы — он сокращает количество работы, которую пришлось переделать.
