Как стать хорошим подрядчиком для крупного клиента. И что отличает хорошего подрядчика от плохого
patpitchaya/shutterstock.com
Как сделать свою компанию успешной, выигрывающей тендеры? Каковы основные критерии выбора подрядчика? Разбирался IT-World.
Для темы сегодняшней статьи важны не занимаемые мной позиции, количество сотрудников в подчинении и бюджеты под моим управлением, а важен тот факт, что практически все это время я был связан с заказной разработкой ПО. Что особенно ценно: в разное время, в разных странах, в разных индустриях и «по разные стороны баррикад».
Был на стороне вендора, дорабатывая собственный продукт компании и интегрируя его в ИТ-ландшафт заказчика. Был на стороне вендора, предоставляющего услуги outstaff и outsource. Был на стороне заказчика, работающего с внешними подрядчиками и покупающего у них:
Принимал участие во множестве конкурсов на выбор поставщика, наблюдал развитие отрасли заказной разработки России в динамике и потому могу сравнивать особенности компаний и делать выводы «что такое хорошо и что такое плохо».
Содержание:
Типология заказной разработки
Раз уж я употребил понятия «outstaff», «outsource», «интеграция», то предлагаю зафиксироваться по терминам и признать, что 99% всего того, что мы называем заказной разработкой ПО, состоит из этих трех категорий.
Казалось бы, зачем я рассказываю очевидные вещи? Затем, что многие BDM (Business Development Manager), выходящие на CIO/CTO заказчика — на сотрудника, так или иначе влияющего на отдачу заказов внешним вендорам, до сих пор путаются в том, что же они предлагают: аутстаф, аутсорс, интеграцию или три услуги сразу.
Как мы выбираем ИТ-подрядчика
И отсюда мы плавно переходим к тому, что ожидают заказчики, что предлагают подрядчики, в чем они расходятся в своих ожиданиях и как эти ожидания совместить. Но для начала поностальгируем.
Прекрасные старые времена
Когда на нашем рынке присутствовали Oracle, SAP, Microsoft, IBM и другие, их сейлзы водили ЛПР (Лица Принимающие Решения) на стороне заказчиков в рестораны, возили на конференции, приглашали на выставки. Чего греха таить, мне это нравилось.
Российские ИТ-компании не умеют продавать
Как же продают представители российских компаний (слава богу, не всех)?
Ко мне постоянно приходят сейлз-менеджеры, называя меня другим именем, путая компании, в которых я работаю; вишенка на торте — сообщают, что готовы прямо вот сегодня уделить мне в такое-то время полчаса, чтобы осчастливить рассказом о своих продуктах. А если не сегодня, то в крайнем случае на этой неделе, а со следующей недели скидка, которую они хотели мне дать, превратится в тыкву.
Понятно, что это совсем уж какой-то экстремум непонимания механизмов корпоративных продаж. Более стандартной историей является следующая.
Стоит компании выложить какую-то информацию на тендерную площадку, так телефон сразу начинает разрываться от звонков аккаунт-менеджеров подрядчиков, внезапно горячо и искренне тебя возлюбивших, давно хотевших тебе позвонить, познакомиться, но все было как-то некогда, а тут такой повод… Эти судорожные контакты очень напоминают сюжет мультфильма «Возвращение блудного попугая».
И конечно, обязательно кто-нибудь из звонящих выразит сожаление по поводу тендера и задаст уточняющий вопрос «можно ли как-то без него?» и что благодарность совершенно точно не заставит себя ждать.
Вишенка на торте — вести коммуникацию в LinkedIn таким образом, чтобы я заблокировал продавца на этой площадке… а потом проявиться у меня в Telegram. После блокировки в Telegram — позвонить мне на сотовый…
Общие критерии выбора подрядчика
Несмотря на то, что к разным моделям взаимодействия (outstaff, outsource, интегратор) применимы различные критерии выбора подрядчика, базово они сводятся к трем основным:
И если со стоимостью для всех трех моделей история абсолютно понятна для обеих сторон, и для заказчиков, и для подрядчиков: чем дешевле, тем лучше. Со сроками также справедлив подход «быстрее — значит лучше», хотя в аутстаф-бизнесе срок — это срок вывода инженера на проект у заказчика, а в других моделях взаимодействия — это срок реализации проекта. А вот на третьем критерии стоит остановиться подробнее.
Я не нашел подходящего термина в российском корпоративном сленге, чтобы кратко и емко выразить веру ЛПР потенциального заказчика в способность компании-подрядчика выполнить взятые на себя обязательства. Но почти всегда данный параметр влияет на то, что при плюс-минус равных цене и сроках потенциальный заказчик выбирает вместо компании А компанию Б. Читайте также
Алексей Голенищев: о безопасности криптовалют, дипфейках и новых каналах атак Один из видных в РФ экспертов в сфере безопасности платежных систем Алексей Голенищев в своем интервью порталу IT-Word рассказывает о том, с какими новыми рисками столкнутся участники криптовалютных платежей, почему заботиться о криптозащите нужно не только банкам, что нового в социальной инженерии и почему мошенника так трудно распознать.
И именно этот критерий ответственен за тот факт, что если потенциальный подрядчик вдруг выставит цену вдвое ниже рынка — он не выиграет.
Когда вы аутстафер
Чтобы убедить заказчика в своей способности выполнить взятые на себя обязательства и отстроиться от конкурентов, компании, предоставляющие ИТ-специалистов на аутстаф, обычно используют две метрики:
И именно с этими метриками связаны расхождения в ожиданиях заказчиков и подрядчиков.
Как обычно происходит стаффинг проекта у заказчика сотрудниками подрядчика? Отправляется запрос: нам нужен senior analyst с таким-то опытом работы в такой-то индустрии на таких-то проектах. У подрядчика есть описанный профиль senior analyst, есть специалисты в штате (или пул кандидатов), соответствующие этому профилю, дальше на них накладывается фильтр работы с индустрией и проектами — и вот тебе специалист, уважаемый заказчик.
Все здорово, только не работает: профили senior analyst у подрядчика и заказчика — разные. И начинаются бесконечные собеседования, отказы, уточнения, повторные поиски и прочее… А проект стоит. А те самые сроки предоставления сотрудника, которые «чем меньше, тем лучше» — растут! Сроки вывода специалиста, которые часто менеджеры подрядчика воспринимают почему-то как «предоставили заказчику для собеседования», по факту превращаются в кратно более длительные сроки «завершения бесконечной череды собеседований и таки взятия специалиста на проект».
Теперь представьте, а если еще и критерии оценки аналитика (оси в этом графике) у подрядчика и заказчика разные…
Рис. 1. Расхождение профилей аналитика у заказчика и подрядчика
Поэтому правильный критерий вместо абстрактной «суммы экспертизы» — это соответствие профилей специалистов подрядчика профилям специалистов заказчика. Да, и развитие специалистов под заказчиков. Понятно, что все заказчики разные, но собрать потребности, сгруппировать их по индустриям и привязать профили к индустриям, а также выстроить план развития сотрудников в зависимости от индустрии — вполне себе метод. А если заказчик большой и очень большой, сотрудничество тесное и долгое, то можно и конкретно под него профиль создать.
Теперь поговорим про скорость замены специалиста. Компания-подрядчик искренне считает, что чем быстрее она заменит на проекте у заказчика своего сотрудника, который уволился, перешел на другую позицию, длительно заболел, запил и т. п. — тем лучше.
В то время как заказчик заинтересован не в быстрой замене. Заказчик заинтересован в том, чтобы из компании-подрядчика люди не уходили, и она удерживала их всеми легальными способами. Способность к удержанию сотрудников — это ключевая компетенция компании-аутстафера. И именно эффективностью механизмов удержания сотрудников одна компания-аутстафер должна конкурировать с другой, и показатель текучки (attrition по-импортному) — важный фактор при составлении тендерного задания и последующего принятия решения менеджерами компании заказчика.
Может возникнуть резонный вопрос: но как менеджеры потенциального заказчика могут узнать о механизмах удержания специалиста внутри компании-аутстафера? Или о том, что профиль ведущего аналитика у них в компании и у поставщика не совпадают?
Неопытные менеджеры узнают об этом на практике, уже после заключения контракта с компанией-аутстафером. А через год, на следующем тендере, набивши шишек, начинают включать соответствующие требования в задание на тендер и терроризировать аккаунт-менеджеров подрядчиков.
А опытные ходят по референс-визитам и общаются с потенциальным подрядчиком, ценя его открытость и прозрачность. Заранее. Ибо знают и предвидят. Поэтому вновь общение выходит на первый план.
Когда вы аутсорсер и интегратор
Значимость зрелости и предсказуемости компании-подрядчика существенно возрастает при увеличении рисков: очевидно, что последствия в случае «когда что-то пошло не так», если компания-подрядчик создает решение под ключ или занимается интеграцией (часто совместно с кастомизацией) продукта в ИТ-ландшафт заказчика, намного выше, чем в случае «один из 30 аутстаферов ушел в запой и не вышел на работу».
И когда общаешься с представителями подрядчика (потенциального или уже даже законтрактованного) — всем все понятно. А когда доходит до совместной работы, то заказчик сталкивается с одной из стандартных проблем, причем даже работа по итеративным методологиям разработки ПО ее никак не решает.
Низкое качество технического решения
Часто выглядит всё так, как будто у подрядчика либо в принципе отсутствует роль выделенного solution architect, и его обязанности закрываются коллегией разработчиков (в результате чего архитектурное решение имеет вид простоквашинского письма-франкенштейна «ваш сын Дядя Шарик»), либо отсутствуют процедуры валидации и контроля принятых архитектором решений. В результате, когда проект решения попадает на утверждение заказчику, возникают коллизии типа «все очень круто, но надо переделать».
Что ожидает заказчик? Наличия solution-архитекторов с необходимой квалификацией и достаточным опытом, а также выстроенного процесса подготовки и утверждения архитектуры решения со своевременным включением в эти процессы архитекторов заказчика. Читайте также
BIM в российской стройке: есть или нет? BIM (Building information modeling) – пожалуй, главный термин в российской стройке в уходящем году: с июля использование технологий информационного моделирования стало обязательным условием почти для всех участников строительного рынка. Но какова эффективность BIM на практике и многие ли используют его в реальности? Рассказывает Кирилл Поляков, сооснователь цифровой платформы для управления стройкой Pragmacore.
Аналогичная история — с проектным управлением
Давайте вспомним классический кейс проектного управления и для наглядности его слегка гиперболизируем:
- Подрядчик называет сроки, в которые в итоге он не попадает.
- За день до дедлайна называются новые сроки.
- Он в них снова не укладывается, и так несколько раз. Что интересно, каждый раз при сдвиге сроков у проекта статус «выполнен на 99%».
- Начинаются эскалации, подключается топ-менеджмент заказчика, и проект переходит на нервную стадию ручного управления и микроменеджмента. Стадию, заканчивающуюся заменой проектного менеджера на стороне подрядчика, переоценкой проекта, увеличением бюджета и сдвигом сроков очень сильно вправо. А также минусами в карму менеджеров на стороне заказчика: за допфинансированием на инвесткомитет сходи, объясни финконтролю и экономической безопасности увеличение бюджетов, срыв сроков. А уж если в результате катастрофы на проекте заказчик не может своевременно требование регулятора выполнить…
Что видят в качестве целевой истории ЛПР на стороне заказчика, когда привлекают внешнего подрядчика на проекты по разработке и/или внедрению ПО? Выстроенные процессы проектного управления, которые включают:
- Способность адекватно оценивать объем трудозатрат по проекту.
- Управление объемом работ и вносимыми в проект по ходу его реализации изменениями.
- Управление рисками проекта.
- Управление ожиданиями заказчика.
- Грамотно выстроенные коммуникации в проектной команде и вовне её. Отдельно отмечу «проактивность» коммуникаций: не заказчик должен бегать за руководителем проекта от подрядчика с вопросом «ну что?», а руководитель проекта от подрядчика должен стремиться рассказать о своем проекте как можно больше, лишив заказчика «права на незнание».
И это не говоря уже об умении команды разработки на стороне заказчика попадать в свои оценки и выдавать функционал с нужным уровнем качества. Эти процессы выстроены мало где. Их выстраивание — приоритетная задача для компаний, берущих проекты под ключ! Но необходимо помнить, что важнее процессов — люди, и поэтому особо хочу сказать про руководителей проекта со стороны подрядчика.
Наблюдаю уже много лет ситуацию, когда на стороне подрядчика руководитель проекта разработки ПО или руководитель проекта внедрения воспринимается как некая административная роль. И в то время как технические специалисты в команде могут быть достаточно сильными, позицию руководителя проекта занимают сотрудники, откровенно всю эту историю не вывозящие. Несовпадение ожиданий заказчика с реальностью подрядчика проявляется в том, что на стороне заказчика (компании, разработка/внедрение ПО для которой не является ее основной деятельностью) руководитель проекта часто сильнее, чем на стороне подрядчика. Это путь не то чтобы в никуда — это путь к штрафным санкциям и расторжению контракта.
Выводы
Соберем все ранее сказанное в удобный todo list. Итак, чтобы быть успешной компанией, выигрывающей тендеры, нужно делать хорошо, а плохо — не делать. А именно:
Хочу особо подсветить последний пункт, так как credibility работает и в обратную сторону: при плюс-минус равной вере заказчиков в способность подрядчиков выполнять взятые на себя обязательства тендер выиграет та компания, что предложит более привлекательные финансовые условия.
И в завершение статьи приведу высказывание фон Клаузевица: «Военное дело просто и вполне доступно здравому уму человека. Но воевать сложно».
В полной мере относится также и к аутстафу, и аутсорсу и интеграторскому бизнесу.
Тарас Сороканезависимый ИТ-эксперт, консультант