Собственники небольшой сервисной ИТ-компании (30+ человек) с проектами полного цикла разработки в ЕС столкнулись с трудностями в поиске SQL-лидов, которые соглашались бы на созвоны. 

Три квартала подряд количество холодных звонков снижалось, что приводило к уменьшению конверсии сделок на 20-25% по сравнению с предыдущими периодами. 

В среднем из 100 лидов только 1-2 доходили до стадии заключения договора, и началось выяснение, на каком этапе теряются остальные 98-99 лидов. 

***

Историю одного из своих клиентов рассказывает Александр Ильиницкий, бизнес-консультант по стратегическому менеджменту (Strategy Business Growth Advisor). Александр уже более 20 лет помогает компаниям улучшать и оптимизировать бизнес-процессы, из которых более 10 лет занимал руководящие должности в ИТ на уровне C-level. 

В статье вы прочитаете:

• Предыстория
• Как исправляли ошибки в лидогенерации
• Что было с маркетингом не так?
• Что с сейлзами было не так у компании?
• Как взрастили проактивность среди сотрудников и коммуникацию между отделами
• Конкуренты подскажут
• Что еще откорректировали?
• Рекомендации

Участие в Road Show результатов не принесли, а бенч рос, что привело к расходованию резервов.

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

Как выяснилось, собственники (они же C-level в своем бизнесе) неправильно поставили цели, которые не соответствовали критериям SMART, и не проработали тактику их достижения. 

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

На вопросы лидогенераторов и сейлзов часто был ответ: “Чем больше, тем лучше”.

Компания была готова брать любой проект, который приносил бы минимум $20-30k к revenue.

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

Начали с анализа верхнего уровня воронки продаж.

Как исправляли ошибки в лидогенерации

Что было с маркетингом не так? 

Маркетолог была на аутсорсе и делала свою работу, как показл аудит, без чёткого плана и/или стратегии, полагаясь на свой опыт и видение.

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

В общем, классика жанра, когда маркетолог предоставлен сам себе. 

Как результат — снижение органического трафика на ~30% в inbound и снижение показателя открытия лидами email-рассылок на 22% из квартала в квартал. 

Также не были собраны все необходимые компании touchpoints для узнаваемости и роста показателя brand equity. 

Замена маркетолога и предложенные эффективные изменения дали позитивный результат. 

Новому маркетологу рассказали о целях компании и поставили маркетинговую цель — снизить CPL и увеличить CR, а для отдела продаж — повысить число закрытых сделок и сократить время цикла сделки.

Что с сейлзами было не так у компании?

История с сейлзами была тоже “классической”. Продажи вел один из собственников. Позже наняли сейлза, который девять месяцев имитировал деятельность, как потом показал анализ его работы. 

Хотя ему обещали даже позицию Head of Sales, результаты отсутствовали. 

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

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

Но сейлзов должно быть минимум двое в такой компании. 

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

Например, вы говорите, что будете расширяться в будущем: “будет не два менеджера по продажам, а 4-5 сейлзов и больше штат лидогенераторов. А значит, кто-то из вас станет Head of Sales”.

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

Как взрастили проактивность среди сотрудников 

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

Собственники не были против, но и никак не обозначили это сотрудникам. 

А те, в свою очередь, молчали. 

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

а) чтобы вы меня прокачали, или б) дали информацию дополнительно, т.к. … или в) надо поменять гипотезу или что-то еще, потому что…”

Я порекомендовал управленцам организовывать плановые 1-to-1 с ключевыми сотрудниками. Это не только элемент контроля, но и мотивации, который делает сотрудников более проактивными и результативными в работе. 

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

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

Конкуренты подскажут

Многие компании почему-то не видят смысла в анализе и сравнении себя с конкурентами. 

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

Вот понятная аналогия с командным спортом для тех, кто еще не понимает, почему надо мониторить “коллег по рынку”. 

Ваша команда не существует в вакууме. Она претендует на призовое место в соперничестве с другими командами.

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

В случае с ИТ-компаниями вы боретесь за долю рынка.

Когда в компании стали обращать внимание и на этот момент, то лидген- и сейлз-специалистам стало проще отстраиваться от конкурентов при коммуникации с лидами.

Что еще откорректировали? 

Продолжили разбираться дальше уже в финансовых показателях.

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

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

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

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

Например, постоянных затратах: зарплаты unbillable-сотрудников, аренда офиса и коммунальные и тд.

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

Собственники смогли выделить проекты с высокой рентабельностью и, наоборот, идентифицировать те, которые не оправдывали затраты. 

Естественно, это дало пищу для размышления: в каких направлениях им выгоднее развиваться и во что инвестировать, а какие приносят убытки — и, значит от них надо отказываться. 

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

Рекомендации

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

1. Четкость краткосрочных целей

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

Эти цели должны быть конкретными, измеримыми, достижимыми, реалистичными и ограниченными во времени (по методике SMART). 

Пример: не позднее 31 декабря 2024 года планируется: увеличение доли рынка не менее чем на 5%, выручка — не менее 3 миллионов долларов (по основному сценарию), а также расширение клиентской базы не менее чем на 20% (YoY).

2. Стратегия достижения целей

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

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

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

3. Постановка задач и показателей

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

Используйте не только KPI, но и OKR (Objectives and Key Results). 

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

4. Взаимосвязь стратегии компании и маркетинговой стратегии

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

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

5. Стратегия продаж и работа с ICP-лидами

Ваша стратегия продаж должна учитывать профиль идеального клиента (ICP) и быть нацелена на нахождение и привлечение подходящих лидов. 

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

Всем желаю удачи и да пребудет с нами сила !

Сообщение Из 100 лидов получали 1-2 контракта. Как небольшой IT компании удалось увеличить число закрытых сделок? появились сначала на Kraftblick.Media.

Делюсь инсайтами, которые получила от CIO крупного частного розничного банка.
 

Как в банке организован процесс поиска вендоров?

 
У банков схема стандартная:

1. Для каждой закупки мы проводим RFI (запрос информации).
2. Выбираем лидеров.
3. Пишем детальный RFP (Request for proposal, запрос предложения).
4. Выбираем поставщика.

Самый важный шаг в процессе закупки — это грамотное составление RFP.

Ошибка в RFP может стоить компании миллионы долларов.

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

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

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

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

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

Сейчас практический каждый большой вендор работает через локальных партнеров.

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

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

Выбираем поставщика, оплачиваем и закупаем все, что нужно, через него.
 

Какие у CIO полномочия по отбору финалиста процедуры выбора поставщика?

 
Задача CIO знать, что требуется от железа и софта, понимать все детали предложения.

Часто CIO назначают официальным председателем закупочного комитета.

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

Как часто банк обращается к кастомной разработке?

 
Бывает, но не много. В основном это доработки продуктов.

Например, наш банк достаточно нетипичный в этом плане.

95% разработки делаем своими силами.

Кастомная разработка для нас — это когда мы покупаем программный продукт и заказываем для него какие-то доработки и кастомизацию непосредственно у вендора.

Больше мы никакой кастомной разработки не заказываем.

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

Вам часто пишут аутсорсинговые компании, которые хотят стать вашими партнерами?

 
Пишут, у меня весь LinkedIn этим забит.

Я им не отвечаю.

Как объявляется отбор поставщика? На каких-то площадках публикуется информация или по известным поставщикам рассылаются запросы? Как ищутся участники для процесса?

Этот процесс относится к компетенции департамента закупок.

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

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

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

Ты всегда знаешь, что можешь выбирать, но выбор не очень большой.

Мы как-то пару лет назад решили заменить АБС. Производителей такого софта мало, их контакты известны.

Поэтому мы просто разослали им запросы и пригласили участвовать в процедуре выбора поставщика.
 

Какой средний чек проекта по замене АБС? О каком бюджете идет речь? Кто определяет этот бюджет?

Сообщение Как банки выбирают подрядчиков? Рассказывает CIO появились сначала на Kraftblick.Media.

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

При каких условиях бизнес-консалтинг может повысить чеки в 2-3 раза?

Своим опытом делится консультант по продажам и сопровождению проектов в Центральной Европе в IBA Group Юрий Рапацевич.

Ранее Юрий работал в финансовой отрасли (руководил корпоративными продажами в банках), но последние 7 лет сосредоточен на IT.

За это время в качестве консультанта он помог многим аутсорсинговым и продуктовым компаниям разного размера (от 20 до 3,000 человек) найти свою нишу, грамотно себя презентовать и таким образом повышать продажи.

Также Юрий Рапацевич занимается продажами и сопровождением проектов в странах Центральной Европы и Балкан в компании IBA Group (2,500+ человек), которая специализируется на разработке высоконагруженных корпоративных IT систем и мобильных приложений, а также продвигает собственные продукты.

Однако в этой статье он будет делится опытом, полученным на протяжении всех лет работы в IT.

Обратите также внимание на другие материалы Kraftblick.Media по теме:

Как быстро тестировать ИТ-нишу (услугу, технологию, продукт). С примерами на кошках.
Нишевание в аутсорсинге на примере e-learning. Как выстроить стратегию презентации отраслевой экспертизы через разные каналы.
Как EPAM продуктизирует внутренние разработки и делает из них акселераторы продаж сервисов.
Как наличие нишевой экспертизы помогает закрывать сделки и работать с клиентами вдолгую. Кейсы Belitsoft в e-learning.

В статье вы прочитаете:

• Что такое сервисная модель упаковки и какие проблемы она решает
• Как определить самый востребованный сервис и протестировать его
• Как оформлять IT решения в зависимости от их жизненного цикла и приоритетности
• Почему у одних метод сработал, а у других нет: кейсы из практики
• Как повысить чеки на 30% после прокачки сервисов

Что такое сервисная модель упаковки и какие проблемы она решает

Упаковка сервиса — это подход по структурированию какого-то рандомного набора услуг компании и формирование некоего востребованного решения.

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

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

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

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

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

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

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

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

Сообщение Сервисная модель упаковки: как повысить продажи на 25% и рейты на 30%. Кейсы IT компаний разных размеров появились сначала на Kraftblick.Media.

Сообщение Как Intetics (700+ человек) использует искусственный интеллект в компании и в маркетинге [с размышлениями о тенденциях развития AI] появились сначала на Kraftblick.Media.

Как выстроить работу над проектом при давлении со стороны другого вендора? А как взаимодействовать с клиентом через интегратора, вашего партнера, но в условиях организационного хаоса?

Как вообще обезопасить свою компанию при наличие третьей заинтересованной стороны?

Рассказывает Юлия Заярная — Global Head и PMO в EDETEK, которая имеет за плечами 13-летний опыт работы в аутсорсинговых и продуктовых компаниях.

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

А начало рассказа вы найдете здесь.

Рекомендуем также другие материалы Kraftblick.Media по теме:

Как проанализировать активность конкурентов. Разбор от маркетолога на примере EPAM и Yalantis.
Как IT интегратор создал свой партнерский клуб и передает лиды небольшим агентствам за комиссию. Опыт AGIMA.
Как привлекать энтерпрайз-клиентов для BPO компаний, которые не специализируются на IT решениях. Опыт Conectys (4,000+ человек).
Нишевание в действии: как компания Dedicatted выстроила взаимодействие с Amazon Web Services и увеличила рейты в два раза. Часть 1.

В статье вы прочитаете:

• Как управлять проектом при наличие вендора-конкурента
• Какие сложности возникают при работе с клиентом через посредника
• Как решать проблемные вопросы с интегратором
• Топ-5 правил работы на проекте при наличие третьей стороны

Как управлять проектом при наличие вендора-конкурента

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

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

1.Подберите опытных, профессиональных, с крутейшими soft и customer-facing skills Account Manager и Project Manager.

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

2.Проектный менеджер должен проявлять инициативу.

Надо организовывать общие митинги с заказчиком и вендором-конкурентом, писать (обязательно!) meeting notes и рассылать всем участникам, четко регистрировать и трекать активности и задачи команды на проекте.

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

3.Организуйте очень четкий репортинг.

Не только с метриками, KPIs, OKRs, но и risks and issues register (там как раз все проблемы и риски можно документировать, в том числе и те, которые пришли от конкурирующих вендоров).

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

И чем более топовому менеджеру репортится статус, тем лаконичнее и компактнее он должен быть.

4.Account Manager и PM должны работать в тесном сотрудничестве.

Это необходимо, чтобы понять потребности заказчика, проблемы, business value. И решая эти вопросы, строить очень доверительные отношения с клиентом.

Сообщение Как IT компании работать с клиентом, когда это не единственный стейкхолдер, влияющий на успех проекта. Часть 2 появились сначала на Kraftblick.Media.

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

Как выявить заинтересованных лиц внутри компании клиента, а также других подрядчиков? Что противопоставить их давлению?

Своим опытом делится Юлия Заярная — Global Head и PMO в EDETEK, эксперт в области проектного управления с 13-летним опытом работы в аутсорсинговых и продуктовых компаниях.

Юлия начинала свой путь в IT c позиции Junior Service Desk Technician (сотрудник колл-центра/первой линии поддержки) в EPAM Systems.

Через 4 года доросла до официальной позиции Project Manager, но по сути была Service Delivery Manager: организовывала все три уровня поддержки с нуля, трансформировала сервисы, брала проекты в красной зоне и выводила из кризиса.

За это время поработала с разными типами заказчиков (крупный и средний бизнес) и доменами: e-commerce, travel and hospitality, finances, marketing, charity, sales.

После такого опыта Юлия Заярная переключилась на управление именно проектами DevOps, Cloud Migration.

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

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

Так она оказалась в EDETEK — американской product development компании, которая разрабатывает свой продукт для автоматизации сбора, трансформации и валидации данных в клинических исследованиях.

И там же Юлия Заярная столкнулась со знакомыми по аутсорсу проблемами влияния на проект третьей стороны. Как их решали, она и расскажет в статье.

Обратите также внимание на другие материалы Kraftblick.Media по теме:
Как мы построили работу над проектом, который принес компании €5М за год. Опыт Helmes Bel.
Как банки выбирают подрядчиков? Интервью c CIO Хоум Кредит Банка.
Как проблемный клиент способствовал развитию маленькой IT компании. Кейс Advascale. Часть 1.
Что делать, если подрядчик начинает угрожать или саботирует работу. Рекомендации начальника юротдела Luxoft-Ukraine.

В статье вы прочитаете:

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

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

Когда я ушла из аутсорса в продукт, то была практически на 100% уверена, что больше никогда не буду взаимодействовать с клиентами через посредников-интеграторов.

Что больше не столкнусь с такой ситуацией, когда с конкурентами нужно бороться не только на этапе пресейла и тендерах, но и после подписания контракта.

Однако… Как говорят, “никогда такого не было и вот опять”.

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

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

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

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

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

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

Надеюсь, что эта статья, построенная на моем опыте, поможет вам понять следующее:

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

Думаю, материал будет полезен не только проектным менеджерам и руководителям PMO, но и всем, кто напрямую работает с клиентом: Presales, Sales, Account Managers, Product Owners, а также владельцам небольших IT компаний.

Сообщение Как IT компании работать с клиентом, когда это не единственный стейкхолдер, влияющий на успех проекта. Часть 1 появились сначала на Kraftblick.Media.

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

Что же делать с бенчем, чтобы свести к минимуму эти негативные факторы?

Как аутсорсеры помогают друг другу использовать свободных специалистов?

Рассказывает Олег Пузанов, Co-founder и CSO в Mad Devs.

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

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

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

Рекомендуем также другие материалы Kraftblick.Media по теме:

Как сервисно-продуктовая компания автоматизировала ключевые процессы, выросла до 250 человек за 4 года и считает рентабельность в один клик. Опыт Symfa Inc. Часть 2.
Как вырастить нишевую экспертизу внутри аутсорсинговой компании и продавать разработчиков в 3 раза дороже рынка.
Партнерская модель Revenue Share. Когда выгодно, как выбирать партнеров и что обсудить первым делом.
Как мы перестали менторить джуниоров и благодаря сетке компетенций сэкономили тимлидам 2 часа в день.

В статье вы прочитаете:

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

Как получить профит, отдавая разработчиков бесплатно

Первый и самый простой вариант — сдавать людей с бенча бесплатно своим текущим клиентам.

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

Но я считаю, что абсолютно нормально проговорить условия.

Если у вас есть Major Client, с которым работаете уже много лет, почему бы просто не дать ему людей бесплатно? Однозначно на проекте есть какие-то задачи, до которых просто еще не дошли руки или на которые у заказчика пока нет бюджета.

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

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

Сообщение Что IT компании делать с сотрудниками на бенче, чтобы не растерять таланты и получать профиты. Опыт Mad Devs. Часть 2 появились сначала на Kraftblick.Media.

Часть сотрудников скучает на бенче в ожидании новых проектов?

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

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

Своим опытом делится Co-founder и CSO в Mad Devs Олег Пузанов.

Mad Devs — аутсорсинговая IT компания (130+ человек) со штаб-квартирой в Лондоне. Основные клиенты — средний бизнес и энтерпрайзы из стран Европы, США и Юго-Восточной Азии.

На счету компании более 70 успешно реализованных проектов в таких областях, как Blockchain and Crypto, Fintech, Transportation, HealthTech, eCommerce, EdTech, AdTech, IoTs, BYOD и другие.

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

Но вместо массовых сокращений Mad Devs решили пережить сложный период с минимальными потерями по хэдкаунту.

О том, как этого удалось добиться, Олег Пузанов и расскажет в этом материале. 

Обратите также внимание и на другие статьи Kraftblick.Media по теме:

Как быстро распродать программистов с бенча? Подборка рекомендаций от четырех IT компаний со штатом от 35 до 250 человек.
Как дела с лидами и каково состояние рынка? Результаты опроса сервисных IT компаний (Часть 2).
Как IT компании построить прозрачные процессы, чтобы у стейкхолдеров не возникало вопросов, куда потрачены деньги. Опыт Mad Devs (130+ человек). Часть 2.
Как аутстафф-команда в кризис выросла в 6 раз, освоила новые технологии и рынки. Опыт TechinBy.

В статье вы прочитаете:

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

Как определить, какой бенч в процентном соотношении и по времени приемлем

Бенч в IT компании — своего рода скамейка запасных игроков. Это сотрудники, которые по разным причинам временно не задействованы в коммерческих проектах и не приносят профит компании.

Каких сотрудников вообще считать бенчевыми? Оговорюсь, что я беру расчет только тех, кто относится к профстаффу — те, кого компания продает клиенту (разработчики, тестировщики и др.).

Кроме того, существует два типа бенча:

• Тотальный — сотрудник вообще не задействован ни в каких коммерческих проектах, на 100% свободен.
• Частичный — сотрудник недостаточно загружен, его занятость не охватывает полный день.

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

Когда появится новый клиент или проект, будет преимущество — доступные и готовые к работе сию минуту сотрудники.

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

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

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

У каждого бизнеса есть свой запас прочности — процент сотрудников и в течение какого периода времени они могут быть не у дел.

Например, для нас 5-10% — это приемлемый запас. 30% уже считается критическим значением.

Но у крупных компаний внутренняя политика обычно позволяет держать бенч и до 30% профстафф-сотрудников в течение года. Тут помогает солидная финансовая подушка.

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

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

По истечению срока нужно принимать решение и кого-то увольнять. Это крайняя мера.

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

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

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

Если этого сделано не было, то можно попытаться считать вручную. Это долго и не очень приятно, ведь нужно учесть массу переменных и “если вдруг”.

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

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

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

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

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

Т.е. если условный Петя получает на руки зарплату $1k долларов, компании он может стоить все $3k. Это надо учитывать при планировании.

Кто в компании должен знать о простое команды и цене этого

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

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

Одно дело, когда мы знаем, что не у дел до 30% сотрудников и вроде ничего страшного. Другое, когда понимаем, что при этом за 1 месяц простоя компания теряет $300k.

А вот самим профстафф-сотрудникам не всегда стоит знать, во сколько компании обходится их режим ожидания.

На этот счет есть отличная статья Dark side of transparency от McKinsey.

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

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

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

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

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

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

У нас есть ежемесячные АМА-сессии, где ребята могут поднимать абсолютно любые вопросы и при этом оставаться анонимными.

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

На наш взгляд, пока это работает эффективно.

Как могут выгорать сотрудники, не работая

Предположим, мы решили, что готовы прожить с бенчем год, даже если не привлечем новые проекты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это показало, что нам надо продумывать тщательнее занятость во время бенч-периода. Например, делать ротацию сотрудников по командам, чтобы регулярно мелькали новые лица, чтобы человек за год “не-работы” не утратил социальные скилы.

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

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

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

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

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

Материал подготовлен при участии журналиста Kraftblick.Media Юлии Шрамковой.

Сообщение Что IT компании делать с сотрудниками на бенче, чтобы не растерять таланты и получать профиты. Опыт Mad Devs. Часть 1 появились сначала на Kraftblick.Media.

Что такое Sales Pods и чем хороша эта методика? Как ее внедрить в своей компании? 

Как управлять этой новой структурой и что делать с legacy-процессами? Как обеспечить мобильность и карьерный рост сотрудников внутри такой системы? 

Об этих и других аспектах работы малыми сейлз-группами расскажет Максим Голиков — бизнес-консультант, CBDO в Cortlex.

В IT продажах Максим больше 10 лет, из которых 7 лет занимает руководящие должности. Также в качестве консультанта помогает аутсорсинговым и продуктовым компаниям настраивать сейлз-процессы, нанимать хороших специалистов и обучать их.

Эта позиция позволяет Максиму увидеть рынок шире, чем многим. В текущих условиях кризиса он сталкивается с разными подходами к ведению бизнеса. Некоторые из них ему нравятся больше, например, Sales Pods как структурные решения.

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

Обратите также внимание на другие материалы Kraftblick.Media по теме:

Какие специалисты нужны в отделе продаж (и маркетинга) IT компании на каждом из этапов ее развития.
Как IT компании с нуля создать сейлз-отдел и за год увеличить продажи в 3 раза. Кейс Aspirity.
Как фаундеру IT компании рассчитать количество сотрудников сейлз-отдела, чтобы зарабатывать $3-5M в год.
Как IT компании выстроить отдел продаж с прогнозируемыми результатами: Action Plan, который позволит сделать х2 по выручке.

В статье вы прочитаете:

• Что такое Sales Pods и как это повышает эффективность продаж
• Как я начинал работать в малой сейлз-группе
• Какой может быть структура Sales Pods
• Как внедрить поды в компаниях разного размера

Что такое Sales Pods и как это повышает эффективность продаж

Это модель, где продажами занимается небольшая команда от 2 до 4 человек. Они работают на одну цель, с одними лидами.

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

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

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

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

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

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

Но что всегда хорошо работает — это разделение этой ноши с командой. Sales Pods как раз про это.

Сообщение Как IT компаниям с помощью Sales Pods масштабировать продажи и преодолевать кризисы. Рекомендации Максима Голикова появились сначала на Kraftblick.Media.

Как историю с проблемным клиентом превратить в импульс для развития компании: перестроить внутренние процессы, упорядочить условия сотрудничества и масштабироваться?

Как грамотно составить Service Level Agreement, чтобы предупредить возникновение конфликтных ситуаций, и как в целом выстраивать коммуникацию с заказчиками?

Своим опытом делится Co-founder и CEO в Advascale Илья Ничупиенко, который в свое время заполучил очень проблемного заказчика, повлиявшего на дальнейшую политику компании.

Начало этой истории вы можете найти здесь.

Обратите также внимание на другие статьи Kraftblick.Media по теме:

Service Level Agreement (SLA): самые важные условия, которые надо прописать IT компании.
Почему многие IT компании стремятся к модели оплаты Retainer или Time & Materials.
Как обезопасить компанию от оттока клиентов. Рекомендации IT менеджера с 30-летним бэкграундом.
Как общаться с клиентами, чтобы увеличить их Lifetime Value [кейсы Intspirit].

В статье вы прочитаете:

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

Какие пункты мы теперь прописываем в Service Level Agreement, чтобы обезопасить компанию

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

Теперь мы все это прописываем в Service Level Agreement и таким образом защищаем команду от целого ряда проблем.

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

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

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

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

Это все равно что механик разобрал двигатель в машине, а ты сел и поехал на ней. Как думаете, далеко доберетесь?

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

Например, кто-то от имени клиента начинает запускать пайплайны, которые нами еще не отстроены или даже не дописаны.

Сообщение Как проблемный клиент способствовал развитию маленькой IT компании. Кейс Advascale. Часть 2 появились сначала на Kraftblick.Media.