Риски при участии в госзакупках: что важно увидеть заранее

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

За годы работы компания Hands App накопила значительный опыт в выявлении рисков на ранних этапах разработки. Мы тщательно оцениваем следующие ключевые риски до подачи заявки на участие в государственных закупках:

Риск №1: Невыполнимое техническое задание (ТЗ)

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

Вопросы к заказчику:

● Какой стек технологий предполагается использовать (языки программирования, фреймворки, библиотеки)?

● Какая архитектура программного обеспечения (монолит, микросервисы, клиент-сервер, клиент-клиент и т.д.)?

● Какие требования к базам данных и форматам интеграции (REST, SOAP, XML, JSON и т.д.)?

● Можно ли ознакомиться с исходным кодом и технической документацией?

● Есть ли доступ к тестовому окружению и документации?

● Какие есть ограничения по технологиям и инструментам?

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

Риск №2: Низкая цена без достаточных резервов

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

Вопросы к заказчику:

● Как будет проходить пусконаладка и тестирование системы?

● Какой объем текущей поддержки и количество критических задач на момент начала проекта?

● Есть ли тестовый стенд или возможность его создания?

● Кто и как будет сопровождать систему после внедрения?

● Какие гарантии предоставляет заказчик на выполнение работ?

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

Риск №3: Контракт, не учитывающий реальные условия проекта

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

Вопросы к заказчику:

● Нужно ли присутствие на территории заказчика или возможно удалённое управление?

● На каких серверах планируется работать и какие у них характеристики?

● Какие лицензии и права на ПО используются в проекте?

● Кто правообладатель и какие права у заказчика на изменения и доработки?

● Какие критерии приёмки работ?

Риск №4: Недостаточная устойчивость команды

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

Вопросы, которые мы задаем внутри нашей команды:

● Есть ли дубли ключевых ролей и планы по их замене?

● Как передаётся информация при смене сотрудников и обеспечивается непрерывность работы?

● Кто управляет приоритетами и процессами в команде?

● Какие условия труда и мотивации предлагаются для сотрудников?

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

Финальный фильтр: стоит ли принимать участие в закупке?

Все вышеперечисленные риски сводятся к одному ключевому вопросу: сможем ли мы эффективно и качественно управлять результатом проекта?

Мы не участвуем в закупке, если:

● Техническое задание формально корректно, но не защищено на этапе приёмки и не учитывает реальные технические возможности.

● Цена подходит нам только в идеальном сценарии, без учета доработок и непредвиденных расходов.

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

● Поддержка и эксплуатационные риски фактически перекладываются на подрядчика без гарантий и ответственности со стороны заказчика.

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