7 красных флагов в тендере: как оценить риски закупки до подачи заявки

Как digital- и IT-подрядчику быстро понять, стоит ли участвовать в тендере. Разбираем 7 признаков рискованной закупки: ТЗ, штрафы, сроки, требования, заказчик и экономика проекта.

Ключевые фразы: анализ тендеров, риски тендера, проверка тендерной документации, участие в госзакупках, анализ закупок, ИИ анализ тендеров, 44-ФЗ, 223-ФЗ, gos-tender-ai.

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

Проблема не только в конкуренции. Часто риски спрятаны в документации: в техническом задании, проекте договора, требованиях к участнику, сроках исполнения, штрафах, порядке приемки и истории заказчика.

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

Ниже — 7 красных флагов, которые помогают digital- и IT-командам отсеивать рискованные тендеры до того, как они потратят время на заявку.

1. Расплывчатый предмет закупки

Первый тревожный признак — закупка описана слишком общо.

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

Для IT- и digital-проектов это особенно опасно. Если в техническом задании нет конкретных требований к функциональности, интеграциям, ролям пользователей, макетам, метрикам, отчетности и порядку согласования, подрядчик фактически заходит в проект с открытым объемом работ.

На этапе подачи заявки это может выглядеть терпимо. Но на этапе исполнения появляются дополнительные ожидания:

«А мы думали, что это тоже входит в контракт». «Нужно добавить еще один модуль». «Это же очевидная часть системы». «Без этого результат нельзя принять».

В итоге подрядчик оказывается в ситуации, где цена зафиксирована, сроки зафиксированы, а объем работ продолжает расти.

Что проверить до участия:

есть ли конкретный перечень работ;

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

Если после чтения ТЗ команда не может точно оценить трудозатраты, это не просто «нужно уточнить». Это риск неправильной экономики всего проекта.

2. Жесткие штрафы и неустойки при неясных условиях

Вторая зона риска — проект договора.

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

Особенно опасно сочетание двух факторов: жесткие штрафы и нечеткие обязательства.

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

Для digital- и IT-подрядчика это типовая проблема. Исполнение почти всегда зависит от взаимодействия с заказчиком: доступов, API, брендбука, контента, согласований, тестовых контуров, ответственных лиц. Если эта зависимость не отражена в договоре, все риски могут оказаться на исполнителе.

Что проверить до участия:

1. размер штрафов и неустоек;
2. условия одностороннего отказа;
3. порядок приемки результата; 
4. сроки предоставления доступов и материалов со стороны заказчика;
5. есть ли процедура фиксации задержек не по вине исполнителя;
6. можно ли продлить сроки при объективных препятствиях.

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

3. Избыточные требования к участнику

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

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

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

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

Что проверить до участия:

1. соответствуют ли требования реальному предмету закупки;
2. можно ли подтвердить опыт без искусственных ограничений;
3. нет ли требований под конкретного поставщика; 
4. не завышен ли объем подтверждающих документов;
5. есть ли риск отклонения заявки из-за формального несоответствия.

Главный вопрос: требование помогает заказчику выбрать квалифицированного исполнителя или искусственно сужает конкуренцию?

4. Нечеткие или оценочные критерии приемки

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

Красный флаг — формулировки вроде:

«дизайн должен быть современным»; «интерфейс должен быть удобным»; «система должна быть интуитивно понятной»; «материалы должны соответствовать ожиданиям заказчика»; «качество услуг оценивается заказчиком самостоятельно».

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

В digital-проектах это особенно рискованно. Дизайн, тексты, рекламные гипотезы, интерфейсы, аналитические отчеты и UX-решения часто содержат субъективный элемент. Поэтому критерии приемки должны быть максимально конкретными: состав работ, форматы файлов, количество итераций, сроки согласования, метрики, сценарии тестирования, перечень отчетов, требования к документации.

Что проверить до участия:

есть ли объективные критерии приемки; сколько итераций правок предусмотрено; описан ли порядок согласования спорных результатов; есть ли тестовые сценарии для IT-систем; зафиксированы ли форматы и состав передаваемых материалов; может ли заказчик бесконечно отправлять результат на доработку.

Если результат зависит от субъективного «нравится / не нравится», подрядчик должен заранее понимать, как ограничен этот риск.

5. Нереалистичные сроки

Сроки — один из главных источников проблем в тендерах.

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

В IT и digital есть этапы, которые сложно ускорить без потери качества: сбор требований, проектирование архитектуры, согласование макетов, разработка, тестирование, исправление ошибок, миграция данных, настройка аналитики, обучение пользователей.

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

Что проверить до участия:

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

Особенно внимательно стоит смотреть закупки, где срок исполнения начинается сразу после подписания контракта, а доступы, материалы и вводные заказчик должен предоставить «в процессе».

6. Экономика не сходится после скрытых затрат

НМЦК или цена договора может выглядеть привлекательной, но это не означает, что проект выгоден.

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

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

Что проверить до участия:

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

Хорошая практика — считать не только «можем ли выполнить», но и «что мы потеряем, если возьмем этот контракт».

7. Заказчик с проблемной историей

Даже идеально оформленная документация не гарантирует спокойного исполнения. Важно смотреть на историю заказчика.

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

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

Для digital- и IT-проектов репутация заказчика особенно важна, потому что результат зависит от коммуникации. Если заказчик плохо формулирует требования, долго согласует этапы, часто меняет позицию или формально подходит к приемке, риски исполнения растут.

Что проверить до участия:

историю закупок заказчика; количество участников в похожих процедурах; частоту жалоб и расторжений; с кем заказчик обычно заключает контракты; есть ли повторяющиеся победители; как часто закупки признавались несостоявшимися; были ли судебные споры с подрядчиками.

Иногда проверка заказчика дает больше информации, чем само техническое задание.

Как быстро оценить тендер перед участием

Полноценный анализ закупки может занимать несколько часов. Нужно открыть извещение, прочитать техническое задание, изучить проект договора, проверить требования к заявке, посмотреть НМЦК, оценить заказчика, найти риски и передать выводы команде.

Если тендеров много, ручной подход быстро становится узким местом. Специалисты тратят время не только на перспективные закупки, но и на те, которые нужно было отсеять за первые 15–30 минут.

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

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

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

Что должно быть в нормальном чек-листе проверки

Перед подачей заявки digital- или IT-подрядчику стоит пройти минимум по пяти блокам.

Первый блок — предмет закупки. Нужно понять, что именно хочет заказчик, какой результат должен быть передан и можно ли оценить объем работ.

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

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

Четвертый блок — экономика. Нужно считать не только цену контракта, но и себестоимость, обеспечение, поддержку, документооборот и риски переработок.

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

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

Когда от тендера лучше отказаться

Есть закупки, в которые не стоит заходить даже при привлекательной цене.

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

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

Поэтому зрелый подход к тендерам строится не на принципе «подаемся везде, где подходит ОКПД2», а на принципе отбора: какие закупки соответствуют компетенциям, экономике и допустимому уровню риска.

Вывод

Тендерная работа для digital- и IT-компаний — это не только поиск закупок и подготовка заявок. Это управленческое решение: стоит ли тратить ресурс команды на конкретную процедуру.

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

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

ИИ-инструменты вроде gos-tender-ai полезны именно на этом этапе: они помогают быстро разобрать документацию, подсветить риски и подготовить основу для экспертного решения. Но финальный выбор остается за командой — участвовать, уточнять условия или не заходить в закупку вовсе.