Меня зовут Алексей Постригайло, я управляющий партнер ИТ-компании Энсайн. В этом кейсе расскажу о двух тендерах, после которых мы заметно изменили подход к подготовке конкурсных заявок. В одном конкурсе мы подтвердили квалификацию 27 исполненными контрактами общей стоимостью около 168 млн рублей. В другом подготовили работающий интерфейс с интерактивными 3D-элементами на WebGL, который можно было запустить и проверить.
Обе части заявки мы считали сильными, но в обоих случаях получили 0 баллов именно по тем критериям, на которые рассчитывали. Причина оказалась не в качестве выполненных проектов и не в техническом уровне решения. Мы слишком широко трактовали, что именно комиссия может считать подтверждением требования.
В первом конкурсе цена имела вес 30%, квалификация участника — 70%. Для оценки квалификации заказчик требовал подтвердить опыт выполнения работ с информационными или автоматизированными информационными системами, используемыми для предоставления государственных услуг в электронной форме.
Мы представили 27 исполненных контрактов общей стоимостью около 168 млн рублей. Среди них были сопровождение Портала административной реформы Минэкономразвития, развитие официального сайта Ростуризма и разработка Единой автоматизированной информационной системы Уполномоченного при Президенте РФ по правам ребенка.
Это были не только информационные ресурсы. В технических заданиях предусматривались формы записи на прием, подачи обращений и обратной связи, работа с услугами, формы заявок и другие пользовательские сценарии. Поэтому мы считали такой опыт соответствующим критерию конкурса.
Комиссия подошла к вопросу иначе. Она оценивала не функциональное сходство проектов с требуемыми системами, а наличие в договорах и технических заданиях прямого подтверждения конкретного признака: система используется для предоставления государственных услуг в электронной форме.
Наличие записи на прием, обращений, заявок и других функций само по себе такого подтверждения не давало. В представленных документах нужный признак не был зафиксирован достаточно однозначно, поэтому все 27 контрактов примерно на 168 млн рублей не принесли нам баллов по квалификации.
При этом наша цена была заметно ниже: снижение составляло около 30%, у победителя — около 5%. Но квалификация имела вес 70%, поэтому компенсировать разрыв ценой уже было невозможно. Итоговая оценка составила около 30 баллов у нас против примерно 88 у победителя.
Именно после этого конкурса для нас окончательно разделились два понятия: иметь подходящий опыт и иметь документы, которыми этот опыт можно однозначно подтвердить, — не одно и то же. Теперь каждый контракт перед включением в тендерную заявку мы отдельно сопоставляем с формулировкой критерия. Если соответствие приходится доказывать через функциональность системы, статус заказчика или общий контекст проекта, считаем такой контракт рискованным.
Во втором конкурсе ситуация была другой. Цена имела вес 60%, качественные характеристики предложения — 30%, квалификация — 10%.
Одна из характеристик предусматривала подготовку не менее пяти технических и дизайн-макетов страниц. Мы сделали требуемые макеты, приложили их к заявке и получили максимальную оценку.
Следующий критерий был сложнее. Для раздела "Мегаполисы мира" требовалось представить три самостоятельных результата: макет интерфейса, HTML-верстку и фронтенд-приложение с интерактивными 3D-элементами на WebGL.
Мы подготовили работающий интерфейс, HTML-верстку, само WebGL-приложение, инструкцию по запуску и скриншот готового результата. То есть техническое решение существовало не в виде концепции: его можно было запустить и проверить. Мы решили, что скриншот работающего интерфейса одновременно подтверждает и наличие макета.
Это решение оказалось ошибочным. HTML-верстку и WebGL-приложение комиссия засчитала, а скриншот отдельным макетом не признала. Инструкция по запуску тоже не изменила ситуацию. Поскольку в конкурсной документации макет был указан как самостоятельный результат наряду с версткой и приложением, отсутствие отдельного макета привело к обнулению всей характеристики.
Получилась парадоксальная ситуация: более законченный технический результат не заменил формально требуемый промежуточный материал.
Сами кейсы были совершенно разными. В первом речь шла о подтверждении опыта по десяткам уже выполненных проектов, во втором — о составе технического предложения для конкретного конкурса.
Но ошибка оказалась одинаковой: мы сами решили, что именно можно считать достаточным подтверждением требования. С контрактами исходили из того, что функциональность систем доказывает требуемый вид опыта. С WebGL решили, что работающий интерфейс и его скриншот могут заменить отдельный макет.
В обоих случаях мы смотрели на содержание результата. Комиссия смотрела прежде всего на соответствие конкретному критерию и комплектность представленных материалов.
После этих историй у нас появился простой принцип проверки любой конкурсной заявки. Мы задаем два разных вопроса: соответствуем ли мы требованию фактически и какой конкретный документ или материал в заявке это доказывает. Если на второй вопрос нет короткого и однозначного ответа, значит в заявке остается риск.
Для разработчика или интегратора некоторые вещи действительно выглядят очевидными. Если приложение уже работает, кажется странным отдельно доказывать существование его макета. Если информационная система включает запись на прием, обращения, заявки и работу с услугами, кажется логичным считать ее соответствующей определенному классу систем.
Но комиссия не участвовала в проекте и не знает того контекста, который известен подрядчику. Она работает с ограниченным комплектом документов и материалов, поэтому фраза "из этого же и так понятно" для тендерной заявки фактически означает наличие риска.
Сейчас при подготовке заявок мы используем более формальную схему: требование → подтверждение → конкретный документ или файл. Если документация отдельно требует макет, прикладываем отдельный макет. Если перечислено несколько результатов, каждый из них должен существовать самостоятельно. Если оценивается определенный вид опыта, ищем прямое подтверждение нужного признака в договоре, техническом задании или другом допустимом документе.
Такой подход не делает сам проект лучше. Но он делает конкурсную заявку значительно устойчивее к разным трактовкам.
Есть ограничение, которое невозможно полностью устранить даже очень внимательной подготовкой. Квалификацию в новом тендере часто приходится подтверждать проектами, выполненными три, пять или больше лет назад.
Документы по таким контрактам создавались для совершенно другой закупки. Формулировки договора и технического задания определялись требованиями того заказчика и того проекта, а исполнитель не мог заранее знать, какой именно термин понадобится через несколько лет для участия в другом конкурсе.
Из-за этого возникает странная ситуация. Проект реально выполнен, система работает, требуемая функциональность существует, заказчик принял результат. Но если определенный признак когда-то не был достаточно явно зафиксирован в документации, для новой комиссии подтвердить его может оказаться невозможно.
С фактической точки зрения опыт есть, а с точки зрения процедуры оценки его могут не засчитать.
Мы не пришли к такому выводу. Без формальных критериев появляется другая проблема: оценка слишком сильно зависит от субъективного мнения комиссии.
Если один участник называет проект информационной системой, второй — цифровой платформой, третий — порталом государственных услуг, нужен способ сопоставить эти проекты по единым правилам. Поэтому сам принцип документального подтверждения понятен.
Проблема возникает тогда, когда фактическое содержание проекта можно подтвердить только одной конкретной формулировкой из документов прошлых лет. Со стороны участника полностью решить это невозможно, но можно значительно уменьшить количество собственных ошибок при подготовке заявки.
Теперь перед подачей конкурсной заявки мы отдельно проверяем каждый оцениваемый критерий. Не спрашиваем только: "У нас это есть?" Смотрим, где именно это подтверждено, можно ли увидеть соответствие без дополнительных объяснений, каждому ли отдельно указанному результату соответствует отдельный материал и не пытаемся ли мы заменить требуемый документ чем-то, что кажется нам более содержательным.
Этот подход выглядит значительно формальнее привычной работы над ИТ-проектом. Но именно он помогает не терять баллы там, где сам опыт, компетенции и технический результат уже есть.
После двух конкурсов, в которых 27 контрактов на 168 млн рублей и работающий WebGL превратились в два нуля, главный вывод для нас довольно простой:
хорошая тендерная заявка — это заявка, в которой комиссии не нужно ничего додумывать за участника.
Здесь я обычно пишу про проекты, кейсы и ИТ-практику. А если хочется увидеть меня не только в рабочих текстах — приходите в мой ТГ https://t.me/alekseypostrigaylo. Там — сын, поездки, работа за кадром, личные наблюдения и попытка жить так, чтобы было что вспомнить.