Алексей:
Смотрите какая история, у нас есть оно преимущественно занимается эксплуатацией сервиса и конечно развитие оно присутствует, но базово это всё-таки эксплуатация. И когда мы расширяем свой набор пакет услуг, чем больше услуг, тем сложнее начинаются проблемы, с управлением этих услуг, например появляется клиенты которые берут почти все услуги, это может быть облако, Колокейшн, интернет, хранилище, базы данных как сервис и представляете всем этим надо управлять, всё это надо соединить в одно единое и чтобы оно работало качественно. При этом при всём у клиента постоянно возникает необходимость в изменениях этих схем взаимосвязь, добавление новых услуг, удаление новых услуг, какой-то переделывание, миграции из их офиса к нам и кучи всего другого. Нам до появления тамов приходилось подключать архитекторов, потому что у нас институт архитекторов это ребята которые подключаются к работе на этапе проселенга заказчика, то есть заказчик приходит извне и он говорит мне нужно то и то и мы подключаем архитектора – если это сложный кейс, если это сложный запрос. Архитектор начинает прорабатывать на этапе продажи набор услуг начинается огранка этого вида инфраструктур, как оно будет после того как заказчик подпишет заказ. А когда уже заказчик в эксплуатации, совершенно и возникает какая-то необходимость комплексного мнения, нам приходилось снова подключать архитекторов, при этом нужно было подождать время для понимания а как сейчас у него есть, потому что он на этапе продаж подключался, но прошел год или полгода и человеку нужно опять изучать инфраструктуру, чтобы предложить какие-то изменения, чтобы провести все это бесшовно, без проблем. Для того чтобы решить эту задачу, мы пошли решили пойти на эксперимент, забегаю вперёд и скажу что это успешный эксперимент. Два года назад мы решили рассмотреть такую возможность, когда мы берём среднего инженера и ведущего инженера, которая обладает определенными софт скилами, которым хочется общаться с внешним миром, заказчиком. Мы говорим 30 % времени теперь будешь уделять вот этому конкретному заказчику. Мы берём конкретного инженера, проводим с ним собеседование, подбираем его, когда обучаем и дальше мы его прикрепляем к одному из наших комплексного заказчика, у нас есть список заказчиков которые совсем совсем комплексный и при любом изменение требуется подключать много людей и чтобы этого не делать, мы берём инженера, закрепляем за этим заказчиком и он его постоянно ведёт, по техническим вопросам и это называется техникал аккаунт менеджер.И когда он уже постоянно в теме, когда у заказчика возникает тот или иной вопрос та или иная проблема, это потребность в изменениях и он знает, он отслеживает каждый шаг ему гораздо проще провести эти изменения, он видит все проблемы этого заказчика и более того он постоянно общается заказчиком, на разные проблемы, и постоянно держит руку на пульсе. Поэтому даже когда у заказчика возникает какой-то вопрос, он может адресовать это нашему таму и наш инженер всегда ему поможет, причём оперативно и быстро, в комфортные сроки, потому что он погружен в особенности и проблемы этой инфраструктуры заказчика. Если говорить о этой функции техникал аккаунт менеджер, у неё три задачи. Первое, это функционал проджект менеджера этого заказчика, персонально выделенный, которые помогают Бесшовная провести какие-то изменения, решить проблему, какие-то вопросы. А второе, это контроль качества по услугам, которые предоставляет заказчик, он раз в месяц берет и составляет сервис дсг, анализирует все тикеты, подбивает, что можно улучшить, какие были проблемы, а здесь быстро ответили, здесь медленно, вот здесь сломалось, что мы будем делать. На этой почве он коммуницирует с заказчиком и таким образом мы помогаем заказчику и мы развиваем в его инфраструктуре, в его сервисе, в его потребности, мы развиваем и в этом основная роль техникал аккаунт менеджера. Третье, это такой мостик между сервисом менеджером нашим, между аккаунтов менеджером, между заказчиком, между техническим и производством, то есть подразделением IT сервисов, до этого бывали такие разрывы, есть клиент есть сервис менеджер и много наших технических подразделений и сервис менеджер не всегда просто с координируют действия, потому что у него задача больше про бизнес. По истечении двух лет у нас порядка 20 человек имеет такой функционал, 20 инженеров, которые помогают нашим топовым заказчикам развивать свои сервисы, мы помогаем развивать эко системы заказчиков, основной прикольный бонус от этой функции, что техника аккаунт менеджер позволяет нам выявлять потребности заказчика, даже те услуги потребности которые сейчас мы не можем предоставить. Например, в перечне наших услуг Чего-то нет и тогда техникал аккаунт менеджер поднимает флаг и говорит, у заказчика есть такая потребность, у нас такого нет чем можем помочь. Мы все начинаем думать как нам помочь, даже бывает доходит до того, что мы внедряем какой-то новый тип услуги, которые потом с удовольствием потребляют ещё ряд заказчиков, не только этот заказчик.
Эти три основные вещи которые делает там он реализует, особенности этой штуки, что инженер тратит свое время, мы говорим примерно в какое время, примерно 30 % своего времени рабочего и он уделяет это время клиентам в рамках функционала, как там, остальное свое время он работает в своей системной группе, по своим задачам инженерским. Таким образом, мы позволяем ребятам попробовать себя в какой-то другой ипостаси и вот он был инженером, больше работал внутри, здесь есть отличная возможность попробовать себя и показать свои софт скилы. Софт Скилл это коммуникация, навыки презентации, навыки координации, навыки проджект, менеджмента это позволяет не отрываясь от своей какой-то текущей базовой истории, не выходя из зоны комфорта, попробовать себя в новом направлении. Это в целом позволяет нам повысить клиентоориентированность против заказчиков это прикольная штука.