Профессия сервис-менеджер. Истоки, суровая реальность и путь к созданию команды мечты
Super Mario Bros. Скриншот NINTENDO
Хороший сервисный менеджер — залог спокойного сна заказчика (как внешнего, так и внутреннего). Для меня это уже лет 20, как аксиома. И хотя должность давно прижилась на рынке, до сих пор часто встречаю вопрос «Зачем вообще нужны сервис-менеджеры, если в компании и так отлично работают процессы и сотрудники?» В этой статье я не только отвечу на этот вопрос, но и коснусь истории, поделюсь разочарованиями, а также своим видением о том, как создать и вырастить крутую команду сервис-менеджеров.
Немного истории. Откуда вообще появились сервис-менеджеры
Самый точный ответ на вопрос о том, зачем нужны сервис-менеджеры, на мой взгляд, лучше всего искать в истории их появления. В моей практике термин «сервисный менеджер» (далее СМ) появился примерно 20 лет назад. Тогда я работал в компании, занимавшейся интеграцией ИТ-решений Cisco, и ко мне обратился один из ведущих менеджеров с просьбой от заказчика выделить отдельного управленца для крупного сервисного контракта. Этот управленец должен был стать единой точкой входа для заказчика, понимать его внутреннюю «кухню», координировать инженеров и контролировать вендора. А заодно формировать нестандартный комплект отчётности по сервисному контракту. Ну что было ему ответить, кроме как «любой каприз за ваши деньги»? :) Выделили, как потом оказалось, прекрасного сервисного менеджера, заказчик остался доволен. Он и в хитросплетениях оргструктуры заказчика разобрался, и вовремя «подсветил» тонкие места в наших внутренних процессах, и замкнул на себя часть административных задач. А когда получилось, что все околопроизводственные вопросы перестали касаться инженеров, и они, инженеры, смогли больше концентрироваться на технических задачах, то и качество обслуживания возросло, и люди стали получать больше удовольствия от работы. Посмотрев на такой win-win, мы стали эту историю успеха масштабировать.
Через несколько лет я оказался в крупной, ныне покинувшей нас, вендорской компании, и обнаружил там аналогичную роль с примерно таким же функционалом, но с фокусом на знание внутривендорской «кухни». В крупных международных компаниях, к слову, есть прям масса заковыристых нюансов, без знания которых срок решения проблем увеличивается в разы. И это еще один плюс в список ответов на вопрос «зачем?». Параллельно я узнал, что такие же роли появились почти во всех крупных вендорах, а потом и в интеграторах по всему миру.
Софт-скиллы СМ-ов. На что смотреть руководителю
Прежде чем идти дальше, я бы попробовал сформулировать ожидания от СМ-ов. Сразу оговорюсь, что если речь идет о команде СМ-ов, то и подбирать туда желательно людей с разными психологическими и техническими профилями. Например, если заказчик требователен к мелочам и ожидает от сервисной компании мегапедантичности, то легкий в общении, но недостаточно скрупулезный СМ ему не подойдет. Не сработаются. А кому-то, наоборот, требуется душевность и верхнеуровневое мышление:). Но есть навыки, обладание которыми существенно упрощает дальнейшую работу в роли СМ-а:
— Коммуникабельность и эмпатичность. Базовые софт-скиллы для СМ-а. Объясняется просто: требуется общаться с разными людьми и находить общий язык и с руководителями, и с инженерами, и с бэкофисом как на стороне исполнителя, так и заказчика.
— Стрессоустойчивость. Еще один немаловажный фактор. Нужно понимать, что когда все идет хорошо, СМ, скорее всего, работает в фоновом режиме, но вот случается неприятность (а скорее всего, по закону пакости, сразу несколько неприятностей) и нужно в параллельных диалогах фильтровать только суть и дожимать решение проблем без излишних эмоций. Хороший СМ в такой ситуации и заказчику поможет, и инженеру создаст условия для продуктивной работы, и вендора проконтролирует. А если потребуется нестандартное решение, замкнет на себя его организацию. Тут впадать в панику совсем нельзя.
— Техническая грамотность и быстрое мышление (хваткость). Способность сходу понять суть проблемы и суметь поговорить на одном языке как с заказчиком, так и с инженером в моей практике не раз играла важнейшую роль в выстраивании взаимодействия в рамках сервисного контракта.
— Аккуратность. Это уже про рутинную деятельность, но именно тут мелкая ошибка в одной цифре может привести к долгим разбирательствам и ухудшению отношений с заказчиком или с внутренними службами компании-исполнителя. Этот навык легко проверяется на старте с помощью, например, корректурной пробы или аналогичных тестов.
Возможно, это не весь список. И более того, лично у меня есть целый ряд примеров, когда люди, не обладающие этими навыками в полной мере, становились прекрасными СМ-ми. Поэтому тут можно говорить о том, на что имеет смысл обращать внимание, но окончательное решение лежит в зоне ответственности руководителя, принимающего людей в конкретную команду под конкретные задачи в специфичной среде.
Искать или качать? Как создать хорошую команду СМ-ов
Казалось бы, всё прекрасно — нанимаем подходящих кандидатов и «золотой ключик у нас в кармане». Но, как водится, любая классная идея может быть похоронена рутиной. Об этом я в качестве неприятного сюрприза (то самое, обещанное в начале статьи разочарование) узнал, когда искал специалистов на рынке. В большинстве компаний роль СМ-а свелась к административной работе, контролю костов, бездумному рисованию отчётов и бесконечному контролю показателей качества. Кто-то вообще не общается с заказчиками, кто-то не вникает в технику даже на базовом уровне и т. п. В итоге появляются дополнительные роли — помощников СМ-ов, старших СМ-ов, технических аккаунт-адвокатов и масса других названий разных граней одной и той же сущности и, как следствие, ключевые компетенции размываются. А попробуй предложить роль СМ-а тому, кто на предыдущем месте назывался более значительно, выполняя при этом гораздо меньше функций, чем от него требуется на новом месте. И это не считая того, что от СМ-а ожидается, что он здорово ориентируется в процессах своей компании и пришлый человек тут мало чем поможет.
Вот и получается, что растить СМ-ов с нуля проще и, кстати, дешевле, чем искать на стороне. Сначала стажировка с наставником, потом курс ITSM для погружения в логику происходящего в сервисе (начинать с курса до получения практического опыта — утопия), сертификат ITIL Foundation (версия сути не меняет) и дальше «по накатанной». Прекрасный вариант, если основа команды уже имеется в наличии. А вот если команду нужно построить «с нуля», то искать придется на рынке. И я бы тут предложил ориентироваться на СМ-ов из небольших интеграторов, там хочешь не хочешь, а приходится заниматься всем спектром задач — от общения с заказчиком до координации инженеров.
Super Mario Bros
Так или иначе, если мы пришли к модели, когда, казалось бы, можно уже не искать людей на стороне и качать своих стажеров, то важно не забывать, что если двигаться только в рамках отлаженной и устоявшейся модели, появляется риск потерять понимание того, что творится вокруг, и отстать от рынка. А еще попутно придется решать проблемы, связанные с прогнозированием нагрузки — под регулярное расширение нужна стабильно растущая ниша рынка. При этом прокачку специалистов остановить нельзя — получим гэп между экспертами и джуниорами и учить станет гораздо сложнее. Поэтому в идеале периодически запускать свежую кровь или социализироваться с СМ-ми из других компаний. Понятно, что тут нужно быть готовым к работе с риском хантинга. Кстати говоря, уход сильного СМа в компанию-конкурент практически всегда несет на себе высокую вероятность ухода заказчиков, чьим единым окном был этот СМ. И это еще одна причина того, почему качать своих, изначально лояльных стажеров предпочтительнее найма со стороны. Но с другой стороны, поиск баланса в такой области- сама по себе интересная управленческая задача. Волшебной пилюли в этом вопросе, как и в большинстве тем, связанных с образованием команд профессионалов, нет.
Как оценивать
Теперь, наверное, о самой тонкой теме. Как измерить успешность СМ-а? Это не всегда чёткий KPI. Лично я вообще больше про культивацию подхода к работе, а не трекинг показателей. Но все равно для руководителя нужен какой-то инструмент, чтобы понимать, кто хорош, а чей подход нужно скорректировать. Для меня ключевым критерием хорошей работы СМ-а является готовность заказчика регулярно покупать эту услугу в виде отдельной строчки в КП. Разумеется, при соблюдении финансовых показателей и сохранении позитивной атмосферы в команде. Но, конечно, оценку качества работы СМа можно разделить на составляющие. Например:
Контроль плановой себестоимости.Это по классике. На практике всё зависит от степени влияния СМ-а на внутренние процессы (можно и на маржинальность или рентабельность смотреть).
Объемы апсейлов в текущих контрактах. Если заказчик нам доверяет, то он точно будет расширять контракт.
Регулярные положительные отзывы.Как со стороны заказчика в сторону компании-интегратора, так и со стороны инженеров или производства (всех тех, кто оказывает сервисные услуги),
Сертификация (ITSM и т.п)
Участие в автоматизации процессов. Признак активной роли и готовности — не просто реагировать на изменения требований и ожиданий заказчика, но и оптимизировать процессы и масштабировать полученный опыт.
Но тут каждый руководитель, естественно, волен выбирать свой набор показателей. Главное, не скатиться в бесконечный контроль KPI и не потерять баланс (и это ключевое слово) между парадигмами «сервис оказывается людьми для людей» и «бизнесом для бизнеса».
Куда растить
Итак, взяли мы на работу молодое дарование, прокачали, дали вести собственные контракты. А что дальше? Как ответить на его вопрос «я тут уже все знаю, куда мне дальше расти?» Причем, если на ранней стадии прокачки цепочка «джун-мидл-ведущий» (кстати говоря, сертификация ITSM уже достаточно локализована, чтобы привязать опыт и сертификаты к переходу на следующую ступень) воспринимается вполне адекватно, то что делать с далекой перспективой? Кем в будущем может стать прокаченный СМ?
Super Mario Bros. (Скриншот NINTENDO)
Очевидный вариант про рост в сторону управления людьми пропущу: тут всё более или менее понятно — звучит красиво, но по сути применимо к единицам. Во многом, из-за того, что на рынке, если и есть спрос на управленцев, то касается он руководителей, ориентированных, в первую очередь, на зарабатывание денег для компании, а хороший СМ — это больше про людей и клиентоориентированность. Вот и остается сравнительно небольшая ниша роста через управление командой СМ-ов или смежными ролями в рамках сервиса.
Из более реалистичных вариантов — управление проектами. Навыки похожие, но тут есть один, на мой взгляд, прям стоп-фактор. Управление проектом — это, по сути, задача, имеющая конечную цель и требующая от менеджера проекта умения вовремя остановиться. Управление сервисным контрактом (при качественном подходе к оказанию сервиса такие контракты, как правило, продлеваются) — это про равномерное движение с соблюдением правил и с целью продлиться. По моим наблюдениям, переключиться с одного типа мышления на другой очень трудно.
Поэтому путь через управление проектами, с моей точки зрения, имеет смысл формировать только для сервис-менеджеров, мыслящих категориями постановки конечных целей и их, целей, дальнейшей реализации в поставленные сроки и с минимальными костами.
Другой путь — в BDM сервиса. Тут и знание области отличное, и спрос на рынке есть, и навык переговорщика у любого классного СМ-а уже в базе. Единственное «но» — это способность продавать. В роли СМ-а эта суперсила не особенно качается, но если в человеке изначально заложен талант, то в этой роли можно расти. Не могу не оговориться, что в моей практике успешных примеров крайне мало, хотя есть примеры перехода в аккаунт-менеджеры и дальнейшего роста по линии продаж.
Еще один вариант — это продакт-оунеры. Роль на нашем рынке сравнительно молодая и требует умения работать на стыке заказчика и производства с эмпатией и организованностью в обойме. Вот тут успешных примеров ощутимо больше.
Типичные проблемы СМ-ов и как они лечатся
Как и в любой профессии, в роли СМ-а есть специфические проблемы, с которыми постоянно сталкиваются и сами СМ-ы, и те, кто с ними регулярно взаимодействует. Тут я не говорю о том, насколько может отравить атмосферу в коллективе слабый или постоянно «включающий начальника» СМ. Это, по-моему, лучше лечить хирургическим путем. А вот в остальных случаях встречаются две группы проблем — «скиловая» и «рутинная».
С навыками обычно связаны:
— сложность переключения с манеры общения с заказчиком (иногда прям жесткая и всегда иерархически четкая со стороны заказчика, разумеется) на внутрикомандную коммуникацию (в сильных компаниях это, как правило, легкая риторика с долей юмора на грани сарказма),
— постоянная нацеленность и на то, как бы осчастливить заказчика, оставаясь в рамках финансовых планов и при этом не допустить выгорания команды,
— необходимость хотя бы поверхностно, но вникать в технику.
К «рутинным» я бы отнес:
— контроль заявок и доступности инженеров,
— бесконечное подстраивание под процессы заказчиков,
— встречи. Бесконечные встречи, в том числе «ни о чем».
— отчеты. Иногда простая любознательность заказчика приводит к загрузке не только СМ-а, но и всей команды администраторов и инженеров.
Хорошая новость — оба вида описанных проблем лечатся. Первая часть — прокачкой софт и хард-скилов, а вторая — за счет автоматизации. И если по скилам есть масса курсов и что с ними делать, более-менее понятно, то на автоматизации я бы остановился несколько подробнее.
Уход от рутины. Автоматизация работы СМ-а.
Из моей практики, на команду не менее 3-х СМ-ов нужен минимум один разработчик на фул-тайм. Главное, начать автоматизацию с простых вещей, в которых все, и СМ-ы, и разраб увидят реальную пользу, а дальше покатится само собой.
Чего хочется от автоматизации прежде всего? Скинуть рутину с СМ-а и упростить сбор аналитической информации, чтобы можно было в отчетах радовать заказчиков не сухими цифрами, а продвинутыми рекомендациями. Можно до какого-то момента делать все вручную, но например, в моей практике был сложно-выдуманный отчет, в котором заказчик хотел видеть финансы, распределенные по регионам в зависимости от количества и сложности запросов. Кого и когда это пугало? Вручную собирается за несколько часов. Но при согласовании отчета заказчик на каждом этапе просил поменять те или иные данные по конкретным заявкам и каждый раз отчет приходилось пересобирать. В итоге несколько часов превратились в дни нервотрепки. Автоматизировали — и процесс свелся к разумным цифрам.
Super Mario Bros. (Скриншот NINTENDO)
Однако, в большинстве случаев реализовать автоматизацию аналитики удается не так оперативно, как хотелось бы. Понятно, что есть целый ряд софтин ITSM-фрэндли, в которых отражены все основные процессы. Но нюанс в том, что при внешней похожести процессов на рынке крайне редко можно найти сервисную службу, которой будет достаточно развернуть решение из коробки. Хотим мы того или нет, но для кастомизации всегда нужна команда собственных разработчиков и аналитиков. Иногда эту роль удаётся совместить с текущим функционалом какого-то сотрудника, но это только в небольших компаниях. Дальше-больше. Развернули мы такую систему, адаптировали её под наши бизнес-процессы, скорректировали процессы (иногда это необходимо), обучили или переучили персонал, внесли данные (каждый шаг может растянуться на месяцы), научились работать с системой не раз в месяц, а на постоянной основе, оказываем сервис и тут выясняется, что кого ни спросишь из рядовых исполнителей, каждый все равно хоть чем-то, да недоволен. А уж, например, про то, чтобы из системы генерить отчёты в формате, пригодном для отправки заказчикам с их бесконечной спецификой, вообще лучше умолчим. Появляется масса надстроек. И даже если мы сможем выделить под них отдельную команду разработчиков, то единственная среда, откуда можно взять аналитика, а скорее всего и тестировщика — это, опять же, СМ-ы. И получается, что классный СМ кроме своих обычных навыков должен уметь формулировать задачи разрабам и разбираться в архитектуре ITSM-систем. И тут частенько возникает предательская идея привлечь к задаче пару-тройку стажеров, вооружить их инструкциями и будет всем счастье. Не будет. Даже если они справятся, то это точно не добавит значимости для заказчика, который подумает «если вы так смогли, то и любой другой интегратор справится». А вот если вы показали заказчику команду сильных СМ-ов, имеющих расширенные возможности по автоматизации пусть даже и просто отчётов, то и конкурировать с вами будет трудно, и заказчик никуда не захочет уходить.
Так зачем же нужны СМ-ы? Послесловие
Подводя итог можно сказать, что из-за большого разнообразия технологий и бизнес-процессов — и в заказчиках, и в интеграторах — в современном мире при оказании сервисного обслуживания практически невозможно обойтись без команды СМ-ов. При этом, естественно, не стоит ожидать даже от самого высококлассного СМ-а, что он заменит собой всю команду инженеров и администраторов или хорошо выстроенные процессы. И если уж планируется запуск такой роли, как СМ, то под нее нужно и процессы прорабатывать, и автоматизацию затачивать. А если бы нужно было посоветовать кому-то выстроить команду с нуля, то я бы предложил сначала сформировать команду СМ-ов (тут денег жалеть не надо — нужен сильный костяк), включающую и джуниоров, и мидлов, и синьоров, и расширять эту команду за счет стажеров и, возможно, единичных экспертов, ориентированных на специфичных заказчиков (в банках, госах и телекоме совершенно разный подход к работе и ожидания от сервисных компаний, например). Остается хорошо понимать самому и культивировать в команде понимание того, как качать СМ-ов с нуля, какие задачи давать стажерам для плавного погружения в мир сервисного обслуживания, как контролировать, не обрубая инициативность, как мотивировать и куда растить. Собственно, как и в большинстве ролей не только в ИT.
