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

Данные размышления, в основном, базируются на многолетнем опыты работы компании ADV/web-engineering. За годы работы и на разных этапах развития компании нами были перепробованы почти все схемы организации “треугольника”.

Описание ролей “треугольника”, зоны ответственности

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

Sales. Менеджер по продажам. Отвечает за продажи проектов по входящим запросам – первый контакт, подготовку и презентацию предложения и сметы, заключение контракта. Иногда также занимается разработкой “холодных” контактов – то есть ищет клиентов самостоятельно (или через каналы, такие как крупные РА, системные интеграторы и пр.).

PM. Менеджер проекта. Отвечает за производство проекта, контролирует сроки-цену-качество. Руководит проектной группой в рамках производства проекта, решает производственные вопросы с представителями заказчика.

Account. Менеджер по работе с клиентами. Осуществляет клиентский сервис, развивает стратегические отношения с клиентом, реагирует на рекламации, старается, чтобы на всем этапе существования клиента в компании ему было комфортно и легко. Как правило, мотивирован на продажу проектов и услуг уже существующим клиентам. Во многом роль аккаунта является промежуточной между PM и Sales.

Мотивация

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

Sales ориентирован на продажу конкретного проекта. Ему не столь важно, что будет происходить на этапе производства, ему важно продать. Поэтому Sales зачастую склонен занижать сметную стоимость (так легче продать) и обещать клиенту золотые горы. Чем, зачастую, бывает весьма недоволен PM.

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

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

Деятельность

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

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

Деятельность PM измеряется проектным циклом. У менеджера есть один или несколько проектов в производстве, и он нацелен на эффективную реализацию каждого отдельно взятого проекта. Временные интервалы PM рассматривает именно в разрезе проекта, его этапов. Таким образом, PM “бежит” на среднюю дистанцию – в его поле зрения проект (продолжительность больше, чем этап продажи, но меньше, чем весь жизненный цикл клиента в компании).

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

Варианты организации “треугольника”

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

1. Sales&PM&Account “Все в одном”

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

Преимущества:

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

Недостатки:

Сильный внутренний конфликт “Sales-PM” из-за разной мотивации и разный целей. Менеджер является единой точкой входа для клиента, поэтому неизбежно возникающие мелкие косяки на этапе производства проецируются клиентом и на стратегические отношения. При росте объема входящих запросов и проектов в производстве менеджера просто не хватает на все.

2. Sales + PM&Account

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

Основная задача PM&Account — все-таки производство проектов. Функция развития отношений с клиентом идет скорее в нагрузку.

Преимущества:

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

PM&Account является носителем знаний и по клиенту, и по проектам – он всегда в курсе, что происходит.

Недостатки:

Из-за того, что Sales – отдельный менеджер, возникает проблема передачи проекта, поэтому PM&Account приходится привлекать на ранних стадиях пресейла. С точки зрения Sales минусом является отсутствие ответственности за свои действия, есть соблазн “наобещать клиенту с три короба”, поскольку потом все равно возиться с этим производству.

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

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

* Могу сказать, что компания ADV/web-engineering просуществовала в такой парадигме организации “треугольника” более 8 лет. Но это было возможно только благодаря весьма высокой компетенции и ответственности сотрудников на должности PM&Account.

3. Account + Sales&PM “Клинический”

Это весьма странный вариант, который мы рассматриваем только для полноты выборки. Мотивации PM и Sales диаметрально противоположны, поэтому объединять их в одном человеке при наличии отдельного аккаунта просто бессмысленно. На практике я, к счастью, ни разу не сталкивался с таким вариантом.

4. Sales&Account + PM

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

Преимущества:

Не возникает проблемы передачи проекта (клиента) и знаний по нему. Менеджер, продавший первый проект клиенту, продолжает с ним работать и дальше. Sales&Account является входной точкой для клиента по всем услугам компании.

Конечная цель и Sales, и Account – продажи, что позволяет локализовать эту задачу в рамках одного человека. Так же схема позволяет стабилизировать “дискретный характер” работы Sales за счет постоянного и хорошо прогнозируемого объема заказов от постоянных клиентов.

Недостатки:

У Sales и Account разный ритм деятельности, возникает внутренний конфликт. У Sales много входящих, быстро заканчивающихся “отбоем”, малый цикл взаимодействия, а у Account есть постоянные клиенты, с которыми надо кропотливо выстраивать отношения.

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

5. Account + Sales + PM “Лебедь, рак и щука”

Казалось бы, схема с максимальным “разделением труда” должна быть максимально эффективной и идеально подходить для крупной компании. Однако все не так просто.

Преимуществом такой схемы является выполнение менеджерами “чистых” ролей, что сводит на нет все внутренние конфликты человека.

Недостатков больше:

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

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

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

* Мы просуществовали в рамках такой схемы менее года и сменили ее на показавшую (для нас, все ведь индивидуально) большую эффективность схему “Account&Sales + PM”.

Заключение

Тема весьма обширна, и, как я заметил в самом начале, в рассматриваемой модели сделан ряд упрощений. Например, в большинстве крупных компаний присутствует дополнительная роль “менеджер поддержки”, у которой так же есть свои тонкости, и эту роль можно объединять с другими (а можно и не объединять), превращая “треугольник” в “квадрат”. Помимо этого, если в компании сформирована линейка диверсифицированных продуктов, можно говорить и о включении в схему роли “Product Manager”.

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

Спасибо за внимание, надеюсь, этот материал поспособствовал полезным размышлениям ;)

Терехов Андрей