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

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

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

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

 

27 контрактов на 168 млн рублей: почему опыт не засчитали

В первом конкурсе цена имела вес 30%, а квалификация участника — 70%. Для оценки квалификации требовалось подтвердить опыт выполнения работ с информационными или автоматизированными информационными системами, используемыми для предоставления государственных услуг в электронной форме.

Под этот критерий Энсайн представила 27 исполненных контрактов общей стоимостью около 168 млн рублей.

Среди проектов были сопровождение Портала административной реформы Минэкономразвития, развитие официального сайта Ростуризма и разработка Единой автоматизированной информационной системы Уполномоченного при Президенте РФ по правам ребенка.

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

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

Комиссия оценила его иначе.

 

Почему функционального сходства оказалось недостаточно

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

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

Такого прямого подтверждения в наших материалах не было.

В результате все 27 контрактов общей стоимостью около 168 млн рублей не принесли баллов по квалификации. Более низкая предложенная цена уже не могла компенсировать этот разрыв. Итоговая оценка Энсайн составила около 30 баллов против примерно 88 баллов у участника, опыт которого комиссия признала соответствующим критериям.

 

Участник	Снижение цены	Заявленный опыт	Подтвержденный опыт	Стоимость контрактов	Оценка квалификации
Победитель	около 5%	29 контрактов	26 контрактов	более 300 млн руб.	100 баллов
Энсайн	около 30%	27 контрактов	не засчитан	около 168 млн руб.	0 баллов

 

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

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

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

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

 

Когда работающий WebGL-интерфейс не заменил отдельный макет

Во втором конкурсе структура оценки была другой. Цена имела вес 60%, качественные характеристики предложения — 30%, квалификация участника — 10%.

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

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

Во второй характеристике нужно было разработать решение для раздела «Мегаполисы мира» и представить сразу три результата:

1. макет интерфейса;
2. HTML-верстку;
3. фронтенд-приложение с интерактивными 3D-элементами на WebGL.

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

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

Комиссия пришла к другому выводу.

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

 

Почему готовый интерфейс оказался недостаточным

Ошибка стала очевидна уже после конкурса.

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

Для оценки этого оказалось недостаточно.

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

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

 

Что объединяет два тендера

На первый взгляд ошибки совершенно разные.

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

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

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

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

Именно поэтому сегодня при подготовке конкурсных заявок мы стараемся разделять два вопроса:

Соответствуем ли мы требованию фактически?

и

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

Это не одно и то же.

 

Как мы теперь проверяем конкурсные заявки

После этих историй подход Энсайн к участию в ИТ-тендерах стал гораздо формальнее.

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

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

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

 

Проблема старых контрактов: нужной формулировки в документах может не быть

У формального подхода есть и обратная сторона.

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

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

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

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

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

 

Что важно учитывать при участии в ИТ-тендерах

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

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

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

Хорошая конкурсная заявка — это заявка, в которой комиссии не нужно ничего додумывать за участника.