Тендеры в ИТ-секторе: головная боль для заказчиков и исполнителей

В этой статье CFO DNA Team Дмитрий Забавин рассказывает о четырех системных проблемах, которые превращают работу с отделами закупок в бюрократический, юридический и репутационный ад как для заказчиков, так и для исполнителей на рынке программной разработки.

Тендеры в ИТ-секторе: головная боль для заказчиков и исполнителей

Демпинг — главная проблема в сегменте программной разработки

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

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

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

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

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

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

Вторая проблема — недостаточная квалификация в разработке ПО у организаторов тендеров

Абсолютное большинство тендеров на рынке программной разработки размещаются и контролируются людьми, которые ничего не понимают в специфике того, что им поручили закупить. Сегодня закупщику поручают закупать скрепки в «Комусе», завтра — бутилированную воду, послезавтра — услуги PR-агентств, а еще через день — услуги на разработку мобильного приложения.

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

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

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

В тендерной документации — особенно в сегменте разработки — важно каждое слово. За каждым термином, за каждым словом стоит конкретное значение. Указанные в качестве примера «приложение» и «платформа» — это две параллельные вселенные: два принципиально разных продукта с разными трудозатратами и бюджетами.

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

Отсюда вытекает третья проблема — сложности с коммуникацией

Запрос дополнительной информации не представлял бы собой проблему, если бы организаторы тендеров были постоянно на связи. Но зачастую за ними приходится бегать. Особенно в срочных тендерах, когда на подачу заявки отводится всего 5-7 дней.

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

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

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

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

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

Четвертая проблема — отсутствие базы знаний

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

Например, бывает так, что один и тот же заказчик спустя какое-то время размещает примерно одинаковые лоты на закупки. Сначала он хочет, допустим, разработать мобильное приложение, а потом открывает тендер на его доработку. И вместо того, чтобы в техническом задании в рамках второго тендера использовать наработки из первого тендера, который уже успешно прошел (где все уже прописано и на это откликнулись исполнители), заказчик пишет ТЗ с нуля.

И с запросом на разработку следующих версий продукта редко предоставляется подробное описание текущего продукта и его состояния. Доступ к кодовой базе как правило не дается и приходится делать оценку «вслепую».
И с запросом на разработку следующих версий продукта редко предоставляется подробное описание текущего продукта и его состояния. Доступ к кодовой базе как правило не дается и приходится делать оценку «вслепую».

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

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

Выводы

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

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

1010
22
Начать дискуссию