Как ИТ‑компании выигрывать госзакупки и не терять деньги на приемке

По данным CNews за январь—август 2025 года объем ИТ‑закупок ПО и оборудования по 44‑ФЗ достиг 269,1 млрд рублей, что на 29,7% выше аналогичного периода 2024 года. Для многих ИТ‑компаний государство сегодня остается одним из крупнейших и наиболее стабильных заказчиков.

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

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

Через две недели мне позвонили с электронной площадки: “У вас несколько дней на обеспечение и подписание контракта. Вы в курсе, что победили?”

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

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

С тех пор прошло десять лет. За это время я прошел через сотни закупок по 44‑ФЗ и 223‑ФЗ, видел, как крупные компании теряли контракты из‑за формальной ошибки в заявке, а небольшие команды забирали миллионные ИТ‑проекты, потому что лучше готовились. За эти годы я собрал рабочую систему подготовки к ИТ‑госзакупкам. В статье собрал то, что действительно помогает снизить риск ошибок и повысить шансы на победу.

Почему ИТ‑госзакупки — это отдельная реальность

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

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

Какие ИТ‑закупки бывают

Если сильно упростить, в госсекторе есть три основных типа ИТ‑тендеров.

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

Внедрение, настройка и сопровождение, техническая поддержка. У заказчика уже есть система, а подрядчику нужно адаптировать ее под процессы: настроить роли, интеграции, миграцию данных, доработать отдельные модули, работать по строгому SLA оказывая услуги L1‑L3 технической поддержки. Риски выше, потому что в таких контрактах часто размыта граница между «настройкой», «сопровождением» и «разработкой». В итоге заказчик может ожидать больше, чем заложено в бюджет.

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

Почему самый трудоемкий этап — не подача заявки, а анализ ТЗ

Именно на этом этапе становится понятно, стоит ли вообще заходить в закупку.

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

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

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

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

Где в документации прячутся самые опасные «мины»

В ИТ‑закупках критичные требования редко лежат на поверхности. Они прячутся в сносках, приложениях, формах актов, проекте контракта и инструкциях по оформлению заявки.

Лицензии и требования по ИБ. Если проект связан с персональными данными, защищенными контурами, криптографией или интеграцией с госсистемами, могут внезапно всплыть требования к лицензиям ФСТЭК или ФСБ. В основном описании закупки про это иногда не сказано ни слова, зато в одном из приложений такое требование уже есть.

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

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

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

Требования к среде и совместимости. Заказчик может указать, что решение должно работать в определенной инфраструктуре, например на Astra Linux, с конкретной СУБД или в действующей информационной системе. Но не всегда указывает версию, ограничения или то, что среда еще даже не развернута.

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

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

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

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

Что особенно важно в закупках на разработку ПО и мобильных приложений

У разработки в госзакупках есть три слабых места:

1. ТЗ часто не покрывает реальную сложность проекта. Чем сложнее продукт, тем выше шанс, что в документации не будет критичных деталей: критериев производительности, ограничений по интеграциям, требований к отказоустойчивости, пострелизной поддержке и так далее. Если не прояснить их заранее, потом заказчик будет считать, что «это и так подразумевалось».
2. Мобильное приложение — это не только код. Для мобильной разработки финальная точка — не сборка, а публикация. И здесь начинаются вопросы: у кого аккаунт в сторе, кто оплачивает его обслуживание, кто проходит модерацию, кто отвечает за реджекты, что делать, если проверка магазина приложений затягивается, а срок контракта уже истекает.Если это заранее не зафиксировано, подрядчик может попасть в ситуацию, когда технически продукт готов, но юридически этап не сдан.
3. Самый опасный этап — приемка. В госконтракте приемка — это не формальность. Любой баг, даже косметический, может стать поводом не подписывать акт. А просрочка сдачи автоматически превращается в пени и штрафы.Поэтому еще на стадии подачи заявки важно думать не только о том, как сделать продукт, но и о том, как потом доказать, что он соответствует контракту.

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

Как заказчики выбирают победителей

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

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

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

Какие тренды будут влиять на ИТ‑госзакупки в ближайшие годы

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

Второй тренд — рост требований к кибербезопасности. Безопасность перестает быть отдельным разделом документации и становится частью всей архитектуры проекта: от инфраструктуры до процессов разработки. Это означает, что даже средним ИТ‑компаниям придется усиливать экспертизу по ИБ, если они хотят стабильно работать с государственными заказчиками.

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

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

Что реально помогает выигрывать чаще

За годы работы я пришел к нескольким практическим выводам.

Во‑первых, не стоит готовить каждую заявку с нуля. У компании должна быть библиотека типовых блоков: описание методологии, меры по ИБ, шаблоны резюме, типовые архитектурные схемы, сведения об опыте, комплект учредительных документов. Это экономит время и снижает вероятность формальных ошибок.

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

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

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

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

Финальный чек‑лист перед участием в ИТ‑тендере

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

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

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

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

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

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

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

Мой главный урок из той истории десятилетней давности простой: в тендерах побеждает не самый умный и не самый смелый. Побеждает самый подготовленный.