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