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

Чек-лист для тех, кто хочет заходить в тендеры системно, а не рассчитывать на удачу.

Автор: Владимир Белозеров, заместитель коммерческого директора KODE.

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

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

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

Через две недели мне позвонили с электронной площадки:

— У вас несколько дней на обеспечение и подписание контракта. Вы вообще в курсе, что победили?

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

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

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

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

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

Госзакупки в ИТ довольно сильно отличаются от обычных коммерческих тендеров. В B2B-проектах заказчик в первую очередь хочет получить работающий результат и обычно готов обсуждать какие-то изменения и компромиссы по ходу работы.

В госконтракте, особенно по 44-ФЗ, все устроено жестче. Сроки, объем работ, порядок приемки, штрафы — основные условия зафиксированы заранее, а менять их уже после старта проекта бывает сложно.

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

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

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

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

Поставка коробочного ПО

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

Здесь рисков обычно меньше. Основная задача подрядчика — подтвердить право поставки, соответствие требованиям и наличие ПО в необходимых реестрах.

Внедрение, настройка, сопровождение и техническая поддержка

У заказчика уже есть система, а подрядчику нужно адаптировать ее под существующие процессы: настроить роли, интеграции, провести миграцию данных, доработать отдельные модули, а затем работать по установленному SLA и оказывать техническую поддержку L1—L3.

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

Разработка под заказ

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

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

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

До сих пор встречается представление, что участие в тендере — это в основном заполнить форму на площадке, приложить несколько документов и нажать кнопку «отправить».

Но в ИТ-госзакупках до 80% времени может уходить именно на анализ технического задания, проекта контракта и всех связанных с ними документов.

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

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

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

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

Есть и другая сложность — найти баланс между соответствием документации и свободой маневра.

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

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

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

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

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

Лицензии и требования по ИБ

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

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

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

Права на исходный код

В проектах контрактов нередко встречается формулировка вроде «передать все исключительные права в полном объеме».

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

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

Требования к среде и совместимости

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

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

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

Скрытые критерии приемки

Для меня это один из самых опасных моментов.

В основном ТЗ может быть одна строка: «приложение должно пройти функциональное тестирование». А где-нибудь в приложении к контракту лежит методика испытаний на 200 тест-кейсов с конкретными требованиями к интерфейсу, поведению системы и времени отклика.

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

Формальные требования к заявке

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

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

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

У разработки в госзакупках я бы выделил три особенно уязвимых места.

1. ТЗ не всегда отражает реальную сложность проекта

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

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

И вот эта фраза способна очень дорого обойтись подрядчику.

2. Мобильное приложение — это не только написанный код

В мобильной разработке финальная точка — это не просто готовая сборка. Приложение еще нужно опубликовать.

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

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

3. Самый опасный этап — приемка

В госконтракте приемка — далеко не формальность. Любой баг, иногда даже косметический, может стать поводом отложить подписание акта. А просрочка сдачи — это уже пени и штрафы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Перед решением об участии

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

При анализе документации

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

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

При подготовке технической части

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

При расчете цены

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

Перед подачей

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

Особенно настройки уведомлений.

После подачи

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

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

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

Чаще побеждает тот, кто лучше подготовился.

___________________________________________________________________________________

KODE — №1 в мобильной разработке по версии всех рейтингов России.
kode.ru | Телеграм
+7 (905) 241-33-95
slurm@kode.ru