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

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

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

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

1. Размытое или противоречивое ТЗ

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

На что смотреть:

• Формулировки типа «в соответствии с лучшими практиками» без ссылки на стандарт. Кто решает, что считать лучшей практикой?
• Несоответствие в объёмах: в одном разделе написано «10 форм», в приложении — «20 форм». Какое число верное — узнаете уже после подписания.
• Отсылки к документам, которых нет в приложениях: «интеграция с действующей АС» без описания этой самой АС, её API и форматов данных.
• Скрытые требования в тексте: за стандартной фразой «соответствие требованиям безопасности» может скрываться аттестация по ФСТЭК, которая стоит денег и занимает месяцы.

Хороший тест — попробуйте ответить на вопрос «что именно я сдам заказчику через N месяцев?». Если однозначного ответа нет — это красный флаг. Запрос на разъяснения через ЕИС обязателен; если заказчик отвечает уклончиво или не отвечает совсем — сигнал ещё тревожнее.

Для digital-проектов особенно коварны ТЗ, написанные «под конкретного подрядчика». Внешне они выглядят нормально, но содержат требования, которые выполнимы только одним способом — тем, что уже согласован за кулисами. Проверка тендерной документации на избыточную специфичность требований (конкретная версия ПО, узкий стек, уникальный формат выгрузки) — часть обязательного анализа закупки.

2. Кабальный проект договора

Технических требований нет без договора. Анализ тендера без чтения проекта контракта — половина работы.

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

Что ещё проверять:

Особое внимание — пункт о праве на односторонний отказ. Если заказчик может расторгнуть договор без нарушения с вашей стороны, вы рискуете потратить ресурсы на разработку и уйти ни с чем. По 223-ФЗ такие условия встречаются чаще, чем по 44-ФЗ.

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

3. Нереальные сроки и этапы

IT-проект с конкретными сроками — не редкость. Сроки, в которые физически невозможно уложиться, — отдельная история.

Типичные сигналы:

• Контракт на три месяца, первый месяц — согласование ТЗ с заказчиком. Это не анекдот. Если согласование идёт в счёт срока исполнения, у вас реально два месяца на разработку.
• Этап 1 заканчивается через две недели после подписания, включает «разработку архитектуры, прототипа и согласование». Ни один разумный проект столько не делается за две недели.
• Дата сдачи — 25 декабря. Бухгалтерия, праздники, ключевые сотрудники в отпуске — а штрафы за просрочку начнут капать с 26-го.

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

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

4. Сомнительная история заказчика

Проверка заказчика по 44-ФЗ — отдельный, но обязательный шаг. Один и тот же заказчик может проводить десятки закупок в год и при этом системно иметь проблемы с исполнением.

Что смотреть:

• Расторжения контрактов. Открытые данные ЕИС показывают, сколько контрактов расторгнуто по инициативе заказчика. Один-два за год — норма. Пять-десять — паттерн.
• Жалобы в ФАС. Жалобы поставщиков, которые признаны обоснованными, говорят о том, что заказчик нарушает процедуру. Регулярные жалобы — что это уже стиль работы.
• Суды с подрядчиками. Арбитражные дела — публичные. Если по заказчику регулярно судятся именно из-за отказа платить или приёмки — это не случайность.
• Задержки оплаты. Это сложнее проверить до начала работы, но в профессиональном сообществе репутация расходится быстро.

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

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

5. Экономика на грани

Риски участия в закупках часто скрыты не в тексте ТЗ, а в финансовых условиях контракта. Особенно это касается IT-проектов, где основной ресурс — люди, а люди получают зарплату ежемесячно, а не по факту сдачи.

Проверяйте:

• Размер обеспечения. Обеспечение заявки по 44-ФЗ обычно невелико — 0,5–1% НМЦК (до 5% для крупных закупок). А вот обеспечение исполнения контракта доходит до 30% НМЦК — это уже серьёзная заморозка оборотных средств. Считайте стоимость банковской гарантии или замороженного депозита по обоим.
• Аванс. Есть ли он? Какой процент? По 44-ФЗ аванс необязателен, многие заказчики работают без него. Полгода разработки без аванса — это кредитование заказчика за ваш счёт.
• Отсрочка оплаты. «Оплата в течение 30 дней после приёмки» — стандарт. «В течение 30 дней с даты поступления лимитов из министерства» — это может означать оплату через шесть месяцев.
• Демпинг конкурентов. Если по похожим закупкам побеждают с ценой минус 40% от НМЦК — либо там серые схемы, либо исполнение заведомо некачественное. Опускаться туда же без запаса — прямой путь к убыткам.

Хорошая проверка тендерной документации включает расчёт реальной маржи: берёте цену, вычитаете обеспечение (его стоимость), налоги, прямые затраты и стоимость денег за период отсрочки. Если остаётся меньше 10% — думайте дважды.

6. Рискованная приёмка работ

Это самый недооценённый флаг, особенно для IT. Разработку можно сдать, но не принять — и ни один суд не поможет быстро, если критерии приёмки размыты.

На что смотреть в разделе «Приёмка»:

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

Хорошая практика — до подачи заявки направить вопрос о методике приёмки. Ответ (или его отсутствие) скажет много о зрелости заказчика.

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

7. Несоответствие требованиям вашей компании

Последний флаг — самый простой, но его часто игнорируют под давлением «интересного» проекта.

Требования к участникам по 44-ФЗ и 223-ФЗ бывают формальными и фактическими. Формальные — лицензии, допуски, членство в СРО. Фактические — опыт аналогичных работ, наличие специалистов с конкретными сертификатами, включение ПО в реестр российского ПО (если это требование закупки).

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

Проверяйте:

• Все ли требованные лицензии есть у вас прямо сейчас (не «в процессе получения»)?
• Есть ли контракты аналогичного профиля и объёма, если заказчик требует опыт?
• Соответствует ли ПО, которое вы будете поставлять, статусу из реестра?
• Если требуется членство в СРО — оно есть, и допуск распространяется на нужный вид работ?

Анализ тендера по этому пункту занимает пять минут, а сюрприз при отклонении заявки — потерянные дни подготовки.

---

Что делать с этим на практике

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

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

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

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

Хотите проверять каждый тендер по этим семи пунктам за несколько минут, а не за несколько часов? Попробуйте Систему Анализа Закупок — 3 дня бесплатно, банковская карта не нужна.