Скупой платит дважды, или трагические последствия «экономных» тендеров

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

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

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

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

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

Это происходит по нескольким причинам:

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

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

Я приведу лишь несколько примеров подобных историй и их последствий. 

Пример один. Контракт подписали, а делать некому.

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

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

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

Компания выигрывает тендер на переработку веб-сайта крупной организации. Контракт заключён на год, и его стоимость составляет 6 млн руб. Переработка включает в себя написание сайта с нуля без использования конструкторов, а также создание мобильного приложения на Flutter. Исходя из среднего размера команды, необходимого для реализации подобного проекта (аналитик, архитектор, бэк-енд, фронт-енд, тестировщик, РП, дизайнер), и некой зарплаты в 200.000 руб. в месяц на одного специалиста, мы получаем, что компания должна тратить на фонд оплаты труда людей, выполняющих проект – 1,4 млн руб. в месяц. Выходит, только себестоимость проекта составит около 17 млн.

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

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

Пример 3. Про коробки

И снова тендер. Исполнитель – разработчик ПО под заказ. Проработал ТЗ, обозначил риски, показал свою экспертизу. Заказчику всё-всё нравится. В общем, все прекрасно. Но в финале выигрывает исполнитель, владеющий коробочным решением со стоимостью, в три раза меньше указанной первым исполнителем. Потому что коробочное решение уже готово и требует минимум кастомизации, как обещает поставщик. Однако купить за такую стоимость можно лишь обещания. На самом деле, кастомизация коробочного решения – отдельная тема, еще неизвестно, будет ли это в итоге вообще дешевле разработки с нуля и под ключ.

Пример 4. Абстрактный

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

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

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

Вот так и с тендерами.

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

А еще лучше – пользуйтесь сервисом проектирования IT-решения до того, как объявить тендер, тогда и сюрпризов будет меньше.