Я попробовал оценивать тендеры по баллам: что из этого получилось и где без человека всё равно не обойтись

Когда закупок становится много, обычный подход «открыть, почитать, подумать» начинает плохо работать. Не потому что он неправильный, а потому что он не масштабируется.

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

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

В какой-то момент я решил попробовать более формальный подход: оценивать закупки по баллам.

Не для того, чтобы машина принимала решение вместо человека. А чтобы быстрее увидеть, какие закупки стоит разбирать глубже, а какие можно отложить.

Идея простая: у каждой закупки есть набор параметров, которые влияют на привлекательность и риск. Если эти параметры разложить по шкале, получится первичный рейтинг. Не идеальный, но полезный.

Сначала я выделил несколько критериев.

Первый — соответствие профилю команды. Если закупка точно попадает в компетенции, высокий балл. Если частично — средний. Если предмет размытый или не наш — низкий.

В IT это особенно важно. Например, для команды, которая занимается веб-разработкой, хорошими признаками будут сайт, портал, личный кабинет, веб-сервис, API, интеграции, frontend/backend, CMS, базы данных. А если речь только о поставке лицензий или абстрактном сопровождении без разработки, это уже другой профиль.

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

Третий критерий — сроки. Здесь важно не просто количество дней, а реалистичность относительно объёма. Небольшая доработка за две недели может быть нормальной. Разработка сложного портала за те же две недели — риск.

Четвёртый критерий — условия оплаты. Этапная оплата или понятный порядок закрытия работ повышают привлекательность. Оплата только после полного исполнения, долгий срок оплаты или зависимость от длительной приёмки — снижают.

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

Шестой критерий — ограничения по субподряду. Если команда может привлекать специалистов, проект гибче. Если субподряд запрещён, а объём широкий, риск выше.

Седьмой критерий — права и исходники. Если нужно разрабатывать с нуля и условия передачи результата понятны, это одно. Если нужно дорабатывать чужую систему, но права, доступы и исходный код описаны мутно, это уже риск.

Восьмой критерий — приёмка. Чем понятнее критерии сдачи, тем выше балл. Если приёмка размыта и завязана на «все замечания заказчика», балл ниже.

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

Десятый критерий — общая экономическая привлекательность. Сумма сама по себе не решает всё. Важно соотнести цену, срок, объём, риски и ресурсы команды.

Когда я начал раскладывать закупки по этим критериям, быстро стало видно: субъективное ощущение часто обманывает.

Иногда закупка с хорошей суммой получает низкий балл из-за мутного ТЗ, коротких сроков и оплаты в конце. А менее крупная закупка оказывается интереснее, потому что там понятный объём, нормальная приёмка и меньше скрытых рисков.

Это был первый полезный эффект: таблица заставляет смотреть не только на цену.

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

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

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

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

После этого оценка стала намного полезнее. Не потому что ИИ стал безошибочным, а потому что появилась проверяемость.

Я не воспринимаю такой скоринг как истину. Для меня это фильтр. Он помогает быстро разделить закупки на три группы.

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

Вторая группа — явно слабые. Не наш профиль, плохие условия, неподтверждаемые требования, мутное ТЗ, высокий риск. Их можно быстро отложить.

Третья группа — спорные. Здесь и нужна человеческая проверка. Например, профиль подходит, но есть вопросы по правам. Или сумма хорошая, но сроки сжатые. Или ТЗ понятное, но приёмка размытая.

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

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

Поэтому я стал использовать скоринг не как замену экспертизы, а как способ структурировать первичный взгляд.

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

Так обсуждение становится предметным. Люди спорят не об ощущениях, а о критериях.

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

Так скоринг постепенно становится не просто таблицей, а инструментом обучения.

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

Мне нравится подход, где итоговый балл не существует отдельно от объяснения. Например, не просто «72 из 100», а разбор: высокий балл за соответствие профилю, средний за понятность объёма, низкий за сроки, нужна проверка по правам, есть вопрос по субподряду.

Такой формат намного честнее. Потому что цифра без расшифровки в закупках опасна. Она создаёт иллюзию точности.

Если система ставит закупке высокий балл, но не показывает основания, ей нельзя доверять. Если показывает основания, человек может быстро проверить спорные места.

Для меня идеальный сценарий выглядит так: ИИ делает первичный разбор и скоринг, показывает цитаты и риски, а специалист принимает решение. То есть машина ускоряет рутину, но не забирает ответственность.

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

Документы могут выглядеть нормально, но если команда уже перегружена, закупка всё равно может быть плохой идеей. Или наоборот: закупка средняя по баллам, но стратегически полезная, потому что открывает вход в нужную отрасль.

Поэтому финальное решение всё равно человеческое.

Но как инструмент первичного отбора скоринг оказался полезным. Он дисциплинирует. Заставляет смотреть на закупку системно. Помогает не влюбляться в сумму. Показывает, где именно риск. Ускоряет сравнение нескольких процедур.

Главное — не относиться к баллам как к математической правде. Это не точная наука. Это способ сделать субъективную оценку более прозрачной.

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

Потому что основная боль не в том, что специалист не умеет читать документацию. Умеет. Просто документации много, времени мало, а цена невнимательности высокая.

Если ИИ помогает быстрее добраться до сути и не пропустить важные пункты, это уже реальная польза.

Я бы не доверил ему финальное «участвовать / не участвовать». Но доверил бы первую сортировку, поиск оснований и подготовку чернового анализа.

И, кажется, именно в таком формате ИИ в тендерах выглядит наиболее здраво: не волшебный эксперт, а быстрый аналитический слой перед человеческим решением.

А вы бы доверяли закупке балл от ИИ, если рядом есть расшифровка и ссылки на конкретные пункты документации?