что делает сервис менеджер

Сервис-менеджер: обязанности, требования к работе

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

Определение

Основное

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

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

Должностная инструкция

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

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

Обязанности главные

Требований, предъявляемых к менеджеру, довольно много. Какие они? Среди основных функциональных обязанностей сервис-менеджера можно выделить следующие:

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

Обязанности второстепенные

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

Среди прочих обязанностей сервис-менеджера необходимо упомянуть:

Только выполняя весь спектр обязанностей, сервис-менеджер может сделать свою компанию лидером на рынке. Здесь важным фактом является оплата его услуг. Зарплата менеджера отражает объем выполняемых им функций.

Права

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

Сервис-менеджер обладает следующими правами:

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

Ответственность

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

Среди прочего обязанности сервис-менеджера выражены в следующих пунктах ответственности:

Основные задачи

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

Дополнительные задачи

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

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

Административные задачи

Не везде сервис-менеджер владеет этим участком ответственности, но все же стоит упомянуть кадровые и прочие задачи данной профессии:

Функции

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

Источник

ITSM-менеджер по счастью: как профессия будущего помогает расширить границы сервис деск

«Что за бред? Разве бывают менеджеры по счастью?» – спросит пессимист, прочитав название статьи. «А ведь идея вполне реальная! В ОАЭ давно настоящий министр счастья работает!» – парирует оптимист.

А причем тут информационные технологии? Обо всем по порядку. В начале этого года известная российская ИТ-компания предложила поучаствовать в серии тематических мероприятиях по применению принципов сервисного подхода вне ИТ в качестве эксперта. Общая цель мероприятий – поделиться опытом, как организовать эффективное взаимодействие между сервисными подразделениями компании и бизнесом, используя методы и инструменты сервисного подхода. Моей задачей было показать на реальных примерах, что и как сделать для достижения результата.

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

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

Часть первая. Что происходит в ИТ

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

Недавно попалась колонка в журнале о профессиях будущего. Приведу краткую выдержку: «Многое сводится к странному и вроде бы неэкономическому, если не сказать наивному, понятию – счастье. Счастье как удовлетворенность сегодняшним днем и вера в завтрашний. Счастье как фактор безопасности. Счастье как душевный и физический комфорт. Счастье как товар. Счастье как объект продаж. Это существует уже сейчас, просто не вполне сформулировано. Называют имена: Стив Джобс, Илон Маск, Ричард Бренсон. Иногда говорят: дизайнер. Или: маркетолог. Но все чаще сходятся на том, что «специалист по счастью» – это профессия. Одна из востребованных профессий будущего».

Не согласны? Но ведь фактор счастья может быть «зашит» в самые разнообразные вещи. В том числе в сфере ИТ. Например, в оптимизацию процессов с использованием знаний и инструментов ИТ.

На прошедшем в мае форуме ITMF-2018 один из спикеров, Андрей Заварзин, директор дивизиона «Массовая персонализация» Сбербанка, отмечал: «Многие инженеры, становясь менеджерами, поняли, что математика и системный анализ применимы для развития не только технических, но и организационных систем. И уж совсем неожиданно, что ITSM и Devops оказываются не только инженерными практиками, но и эффективными подходами к управлению «не ИТ-шными» бизнес-процессами. Поговорим про бизнес-карьеру вчерашних ИТ-шников и расширение применения процессных моделей и практик ИТ на весь бизнес».

Я не случайно выделил тут два момента:

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

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

По второму моменту. Не обязательно становиться «вчерашним ИТ-шником». Можно, оставаясь «сегодняшним», стать партнером бизнеса. Никто не говорит, что вы сразу станете «министром по счастью». Но вы сделаете к этому первые шаги. Ваш вес в глазах бизнеса вырастет. Деятельность вашего подразделения будет рассматриваться не как «постоянно убыточное ИТ», а как подразделение, помогающее бизнесу. Тут уже реально и повышение заработной платы и карьерный рост, и другие «плюшки».

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

Часть вторая. Кого осчастливили

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

Часто процессы, решаемые до старта проекта через электронную почту, автоматизируются с использованием инструмента класса сервис деск. Автоматизируются успешно и с положительными отзывами заказчиков. Вот из последних: «Дмитрий, если бы в нашей компании давали медали, то первый орден я вручила бы вам». Именно такой фразой несколько дней назад меня приветствовал руководитель крупного проекта в нашей компании. «За что?» – совершенно искренне удивился я. «За ваш сервис деск. Вы не представляете, как он сейчас нам помогает».

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

Еще один момент. Про правду. Помните, герой Сергея Бодрова произнес фразу: «Я вот думаю, что сила в правде. У кого правда – тот и сильнее».

О какой правде, с точки зрения помощи бизнесу, идет речь? О той, про которую молчат. А значит, делают свою компанию слабее. Правда о том, что:

В итоге бизнес работает не в полную силу. Несет потери ресурсов и скорости в базовых, рутинных операциях.

Поделюсь примерами успешных кейсов.

Кейс 1. Процесс подготовки к проверке предприятий надзорными и контролирующими органами

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

Ответов нет. Процесс нигде не велся. Из почты всего не вытащишь. Понятно, что надо как-то автоматизировать. Обращаются в ИТ. Ждут от них чуда. Быстро, дешево и качественно. И если такое оказывается возможным, вы становитесь специалистом по счастью для вашего заказчика. Вы реально освобождаете его от рутинной работы.

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

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

Функциональная схема процесса

В течение месяца процесс был подготовлен к тестированию в системе.

Диаграмма жизненного цикла заявки

Карточка зарегистрированной заявки

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

Заказчик в восторге. Бизнес доволен. ИТ объявили благодарность. Маленькое, но такое нужное счастье для всех.

Кейс 2. Управление обращениями розничных магазинов в отдел товародвижения

В ритейле много различных процессов, которые нуждаются в оптимизации. Я работал в крупных компаниях Вимм-Билль-Данн, Виктория, Дикси. Сейчас уже точно могу сказать, что наши команды не просто оптимизировали процессы. Мы помогали более эффективно выстраивать работу. Нас благодарили. Мы дарили маленькое счастье. Расскажу об одном из решений.

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

Бизнес обратился с запросом автоматизации процесса обращений магазинов в отдел товародвижения.

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

Реализация изменений в тестовой базе, тестирование и перенос в продуктив закончили в течение месяца.

Список зарегистрированных обращений

Аналитика учета обращений по услугам

Аналитика учета обращений по статусу

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

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

Вот так просто мы сделали немного счастливее своих коллег.

Часть третья. Что делать

Знакомый ИТ-аудитор, специалист с большим опытом работы, как-то сказал: «Обрати особое внимание, что когда процесс формализован с помощью сервис деск, существенно снижаются риски внутри процесса. Риск недостижения целей процесса, риск неэффективности процесса, риск сбоя, отказа в ходе процесса. Но часто для менеджеров в сфере ИТ это непонятно и не надо. Для менеджмента, тем более высшего, это всегда интересно и актуально. Так как его основная задача – достичь целей и при этом минимизировать риски».

Что дает перенос процесса в сервис деск? В первую очередь, оптимизацию и снижение рисков.

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

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

Принцип 1. Приглашайте экспертов

Не все надо пытаться делать самостоятельно. Это только кажется, что вы все можете сами. Можете, конечно. И многое. Дело в другом.

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

Поэтому так важно определить границу: когда можно и нужно делать своими силами, а когда эффективнее пригласить специалистов. В любом случае решать вам непосредственно на месте.

Принцип 2. Добивайтесь участия в проекте лиц, принимающих решение (ЛПР)

Не секрет, насколько важна в любом проекте поддержка «власть имущих»: это в дальнейшем «блат», бюджет и при необходимости защита. ЛПР будут убеждать бизнес в необходимости запрашиваемых изменений и будут заинтересованы в скорейшей реализации нового функционала.

По опыту последних проектов, все предложения, поддержанные ЛПР-ами, успешно воплощены в жизнь. Автоматизировать процессы без ЛПР-ов, непосредственно заинтересованных в результате, – неблагодарная задача. И не факт, что вообще нужная.

Принцип 3. Помните, что сыр не бывает бесплатным

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

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

Риски, риски, риски… Кто их оценивает? Вы обещаете бизнесу результат быстро и без затрат. Бизнес надеется. А что получаем в реальности? Конечно, есть примеры успешного внедрения бесплатных программ. Но это скорее исключение, чем устоявшаяся практика.

Я не агитирую покупать системы за миллионы. Тем более что в них основная цена – это консалтинг. Можно приобрести решение в коробке или в облаке, достаточно недорого, и потом его настраивать. Как правило, в таких системах есть набор готовых «пазлов», собирать из которых процесс можно на основании имеющихся инструкций и без программирования. Либо заказывать доработки по конкретным кейсам, что тоже будет дешевле. Основное преимущество такого решения – поддержка систем разработчиком, надежность, большие возможности для внесения изменений.

Так что же конкретно делать? Для начала понять: оно вам вообще надо? Может у вас в компании и без автоматизации рутины все хорошо. А вот если нет, то действуйте. Становитесь специалистами по счастью. Используйте свой шанс. Ведь у вас есть для этого все необходимое.

К выводам

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

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

Присоединяйтесь! Осваивайте профессию будущего!

Что почитать по теме:

Очевидное благо: как и зачем использовать сервисный подход за рамками ИТ:
Часть 1, Часть 2, Часть 3

Источник

SOC — это люди: суровые будни сервис-менеджера центра мониторинга и реагирования на кибератаки

Рассказывая о том, как устроена работа центра мониторинга и реагирования на кибератаки (SOC) изнутри, мы уже говорили об инженерах первой и второй линии и об аналитиках. Тогда же мы вскользь упомянули о сервис-менеджерах. Это сотрудники SOC, которые отвечают перед заказчиком за качество оказываемых услуг. За этим коротким определением фактически скрывается следующее: сервис-менеджер определяет практическую реализацию сервиса на площадке заказчика, должен быть готов в любой момент дня и ночи ответить на звонок заказчика или уведомление инженера мониторинга о критичном инциденте, собрать команду реагирования или расследования и выехать на площадку.

В большинстве своем сервис-менеджеры Solar JSOC — это мужчины в возрасте за 30 видавшие виды с разносторонним опытом в ИБ: от проектирования систем защиты информации до аудита процессов. Обязательно владение навыками перевода с птичьего на человеческий технического на бизнесовый и обратно.

Что и кому должен сервис-менеджер

От сервис-менеджера не требуется глубоких знаний конкретных средств защиты информации на уровне инженера эксплуатации. Но наличие широкого кругозора в области СЗИ и их производителей, минимальное знание сетевых протоколов и требований к специфическим информационным объектам типа АРМ КБР и т.д. — обязательно. А ещё в качестве обязательного требования — сформировавшееся и укоренившееся аки баобаб понимание того, что защищать надо в первую очередь не хосты, а бизнес-процессы. В теории все об этом знают, но на практике следовать этому принципу способен далеко не каждый.

Почему такой набор критериев? Сервис-менеджер — это единое окно для клиента. Вместе с аналитиком они составляют группу, которая непосредственно общается с заказчиком. Этакий фронт-офис в том виде, как мы его себе представляем. Именно сервис-менеджер определяет, как задачи заказчика будут решены на прикладном уровне. В контракте такие частности, как правило, не прописаны.

Хорошо, если у клиента есть четкое понимание, что он хочет получить от услуги (на этой строчке мои коллеги усмехнулись). В реальности это явление почти столь же редкое, как метеоритный дождь. И тут как раз не обойтись без человека, который обеспечивает развитие ИБ в рамках проекта. Для каждого конкретного клиента он выявляет критичные данные и процессы, а также средства их автоматизации; потенциальные точки компрометации на уровне инфраструктуры и организации взаимодействия систем и людей. И это только на стадии запуска сервиса. А потом наступают трудовые будни, во время которых сервис-менеджер постоянно держит руку на пульсе инфраструктуры заказчика. Необходимо помнить и учитывать кучу факторов: тип бизнеса, используемые сетевое оборудование и СЗИ, количество и типы субподрядчиков, уровни доступа к чувствительной информации и многое-многое другое.

Вполне закономерный вопрос: а зачем так сложно? Ведь можно подключить к SOC системы заказчика в качестве источников информации и на этом остановиться. Наверное, кто-то так и делает, но наш опыт показывает: то, что подойдет для банка, неприменимо для завода или лизинговой компании. Да и внутри банков нет одинакового подхода к безопасности, несмотря на то, что это одна из самых зарегулированных отраслей в нашей стране. А уж на заводах вообще тихий ужас: куча проприетарных протоколов, запредельное количество субподрядчиков, подключающихся к элементам инфраструктуры удаленно (зачастую не раскрывая этот факт перед заказчиком). И вот со всем этим знанием необходимо работать.

Как уже говорилось выше, под каждый контракт мы формируем команду из аналитика и менеджера, выступающих фронтом. Команды не являются постоянными и меняются от клиента к клиенту. Как правило, один сервис-менеджер обслуживает от трех до шести заказчиков — в зависимости от их объема контракта и уровня зрелости ИБ. А это три-шесть отличающихся друг от друга инфраструктур, различных конфессий подходов к информационной безопасности и другие «прелести» видового разнообразия. Справедливости ради стоит сказать, что у нас есть ряд крупных клиентов, которым выделен персональный сервис-менеджер, работающий только с ними (но ему от этого не легче).

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

Например, есть изолированный гостевой WiFi-сегмент без доступа к внутренним ресурсам, но заказчик хочет, чтобы, в случае, если мы фиксируем запуск RAT (Remote Access Tool), ему приходило уведомление с максимальным уровнем критичности. Однако по факту при получении подобного уведомления заказчик ничего не делает, т.к. у него нет плейбуков и не хватает своих ресурсов на реагирование. А удовлетворение подобных желаний увеличивает нагрузку на инженеров реагирования и не приносит пользы никому из участников процесса. В итоге мы не получаем ничего, кроме повышенных «социалистических обязательств», т.е. процесс реагирования и расследования инцидента в режиме High ничего не дает.

Или наоборот: заказчик из-за каких-то мало понятных суеверий не хочет ставить на мониторинг свою биллинг-систему (которая основная бизнес-система и вообще — КИИ). И приходится методично, фактически на пальцАх объяснять, почему мы должны защищать этот сегмент. У каждого из наших СМ-ов подобных историй масса, и, если их опубликовать, то получится хорошая такая книжка.

А на другой стороне медали находятся процессы Solar JSOC: непосредственно мониторинг и выявление инцидентов, аналитика, архитектура, форензика и т.д. и т.п. Вся эта немаленькая и разношерстная компания работает на заказчиков. Как в любом живом коллективе в нем есть свои векторы развития, предпочтения, личные коммуникации. И это не должно никак влиять на оказание сервиса. Это тоже головная боль СМ-а: необходимо перераспределить ресурсы на решение какой-то задачи, расставить приоритеты на выполнение так, чтобы это не сказалось на других заказчиках. Нескучное такое занятие получается.

Сон — для слабаков

В отличие от большинства сотрудников Solar JSOC, сервис-менеджер «работает круглосуточно»: без перерывов на ночь, выходной и обед. У всех остальных служб есть дежурные. Это не значит, что сервис-менеджер, как галерный раб, прикован к современному варианту вёсел — столу и компьютеру. Просто это тот человек, который должен ответить на звонок от заказчика или наших внутренних служб в любое время дня или ночи. В нашем понимании под термином «ответить» скрывается следующая последовательность действий (мы же за процессный подход): осознать вопрос/проблему, принять решение о дальнейших действиях и подключить требуемые службы внутри компании, проконтролировав по итогу результат.

Причины звонков могут быть разные — забавные и не очень. Самая распространенная и «любимая» у СМ-ов причина запускается на стороне форензеров. Они находят новый эксплоит, оценивают его с точки зрения возможных угроз и запускают в сервис-менеджеров (как это было недавно с BlueKeep-2).
А дальше — дискотека! Каждый из СМ-ов на всякий случай просматривает досье подопечных клиентов (хотя большинство помнит инфраструктуры наизусть), руководитель этих чудесных ребят формирует текст оповещения, который адресно отправляется заказчикам по всем доступным каналам.

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

Но есть и серьезные причины не поспать ночью. К таким однозначно относится атака на инфраструктуру заказчика. Случается и такая редкая, но не исключительная ситуация: ночью раздается звонок, и из трубки просят о содействии на физической площадке. За годы существования Solar JSOC схема обкатана: «в темпе вальса» собирается команда, в которой СМ выступает в качестве координатора, и дружно десантируется к клиенту. Иногда бывает, что мы подъезжаем раньше ответственных лиц, запустивших эту цепочку.

Отчеты — для сильных духом

Помимо бессонной ночи в таких ситуациях есть еще один огромный минус: все участники процесса могут уже отсыпаться, а сервис-менеджеру необходимо написать предварительный отчет по ситуации с указанием тайминга совершенных действий, описать сами действия и их результаты. Отчетность — это не дань формальностям, а реальный документ, который потом разбирают для выявления ошибок или, наоборот, удачных решений. Учитывается абсолютно весь опыт всех специалистов Solar JSOC, независимо от того, на какой позиции они работают.

Вообще отчетность — неотъемлемая часть работы сервис-менеджера. Отчетов много. Нет, не так. Их ОЧЕНЬ МНОГО. На любой вкус и цвет: от протоколов встреч, на которых фиксируется дальнейшее развитие услуги, до регулярной отчетности перед клиентами. Очень часто отчеты сопровождаются презентациями для топ-менеджмента, который желает знать о потраченных деньгах, но вникать в частности сервиса не готов. Соответственно презентация должна доходчиво подтверждать, что суммы потрачены не зря и от сервиса действительно есть польза. И все это делается абсолютно для всех заказчиков руками мужчин в возрасте за 30. Да, есть определенный уровень автоматизации, но создавать презентации в автоматическом режиме мы пока не научились.

Вообще хороший СМ умеет работать с любой аудиторией: доходчивость — наше всё

Но главное в другом

Очень часто можно услышать о том, что сервис-менеджер — это расстрельная должность и адская работа без возможности развития. Это очень сильное заблуждение. Один из наших СМ-ов говорит, что «результат работы всегда виден, то есть ты не работаешь в мусорную корзину, а это всегда классно».

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

Источник