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

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

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

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

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

Поэтому главный вопрос звучит не «сможем ли мы выиграть?», а «сможем ли мы выполнить контракт, пройти приёмку и сохранить прибыль?».

Один пропущенный email мог стоить компании двух лет

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

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

Мы успели оформить банковскую гарантию, собрать документы и подписать контракт. Но опоздание могло привести к признанию компании уклонившейся от заключения контракта. Статья 104 44-ФЗ предусматривает включение сведений об уклонившихся участниках в реестр недобросовестных поставщиков. Сведения исключаются из него через два года.

С тех пор я прошёл через сотни закупок по 44-ФЗ и 223-ФЗ. Главный урок простой: в тендере можно потерять контракт не только из-за цены или слабого решения. Иногда достаточно пропустить одно уведомление.

Какие IT-закупки бывают и где больше рисков

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

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

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

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

До 80% подготовки занимает анализ документов

Заполнение формы на площадке не самая трудная часть участия. По нашему опыту, до 80% времени подготовки IT-заявки уходит на чтение технического задания, проекта контракта, приложений и форм документов.

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

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

Где в документах прячутся самые дорогие риски

Лицензии и информационная безопасность

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

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

Права на код и внутренние разработки

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

В договоре нужно разделить результат госконтракта и ранее созданные компоненты, определить порядок передачи исходников, доступов и документации. Это также снижает зависимость продукта от одной команды. Подробнее об этом рассказали в статье «Как избежать vendor lock-in».

Среда и совместимость

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

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

Критерии приёмки

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

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

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

Заявку могут отклонить из-за неправильного формата файла, пропущенной подписи, нарушенной нумерации или отсутствия документа. Содержание и оформление должны проходить две отдельные проверки разными сотрудниками.

Что учесть в тендере на разработку ПО

ТЗ почти всегда требует уточнения

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

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

Приёмку нужно проектировать вместе с продуктом

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

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

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

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

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

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

Как рассчитать цену и не потерять маржу

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

• анализ и уточнение требований;
• проектирование и дизайн;
• разработку и тестирование;
• настройку среды и интеграций;
• документацию и обучение;
• исправление ошибок;
• публикацию приложения;
• гарантийную поддержку;
• обеспечение заявки и контракта;
• возможные задержки доступа и приёмки;
• риск штрафов и переделок.

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

Что помогает выигрывать IT-тендеры системно

1. Библиотека готовых материалов

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

2. Карта соответствия

Свяжите каждое требование с ответом, подтверждением и риском. Эта таблица становится общей рабочей картой для менеджера, юриста и технической команды.

3. Запросы разъяснений

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

4. План приёмки до старта

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

5. Контроль после подачи

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

Как пройти приёмку и получить оплату

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

К каждому этапу стоит заранее подготовить:

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

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

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

Что делать, если требования меняются во время проекта

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

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

При появлении нового требования нужно:

1. Сопоставить его с ТЗ и договором.
2. Определить, входит ли оно в первоначальный объём.
3. Оценить влияние на сроки, стоимость и другие функции.
4. Зафиксировать позицию письменно.
5. Использовать допустимый законом и договором порядок изменений.

Главная задача — не конфликтовать с заказчиком, а сохранить однозначную связь между обязательствами и результатом.

Как оценить тендер до участия

До подготовки полной заявки полезно провести короткую проверку процедуры.

Шаг 1. Проверить соответствие формальным требованиям

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

Шаг 2. Разобрать техническое задание

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

Шаг 3. Проверить договор

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

Шаг 4. Рассчитать экономику

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

Шаг 5. Проверить приёмку

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

Шаг 6. Принять решение об участии

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

Чек-лист перед подачей заявки

• Все требования документации распределены между ответственными.
• Проверены обязательные лицензии, допуски и подтверждения опыта.
• Неоднозначные пункты ТЗ вынесены в запросы разъяснений.
• Техническая команда оценила интеграции, нагрузку и среду.
• Юристы проверили права, ответственность, штрафы и порядок оплаты.
• Рассчитана полная стоимость исполнения контракта.
• Определена минимальная цена для торгов.
• Критерии приёмки связаны с конкретными результатами и документами.
• Проверены форматы, подписи и комплектность заявки.
• Назначены основной и резервный ответственные за уведомления площадки.
• Команда знает порядок действий после победы.
• Подготовлены обеспечение и документы для быстрого подписания контракта.

Почему победа в тендере — только половина результата

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

Поэтому полезно считать не только win rate, но и:

• маржинальность контрактов;
• отклонение фактических затрат от оценки;
• долю проектов, сданных в срок;
• длительность приёмки;
• число замечаний;
• стоимость гарантийной поддержки;
• долю повторных заказчиков.

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

Главное

В IT-госзакупках выигрывает не компания, которая сильнее всех снижает цену. Устойчивый результат получает подрядчик, который умеет заранее находить риски, задавать вопросы, считать полную стоимость и проектировать приёмку вместе с продуктом.

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

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

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

FAQ об IT-госзакупках

Чем отличаются закупки по 44-ФЗ и 223-ФЗ?

44-ФЗ подробно регулирует процедуры государственных и муниципальных закупок. 223-ФЗ применяется к закупкам отдельных видов юридических лиц и оставляет заказчикам больше возможностей определять правила в собственных положениях о закупке. Конкретные требования всегда нужно смотреть в документации процедуры.

Как понять, стоит ли участвовать в IT-тендере?

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

Почему нельзя просто предложить самую низкую цену?

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

Что делать, если в ТЗ есть непонятное требование?

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

Когда нужно готовиться к приёмке?

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

Можно ли изменить требования после подписания госконтракта?

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

Какие показатели использовать для оценки тендерного направления?

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