Вы успешно подписались на Блог Naumen
Great! Next, complete checkout for full access to Блог Naumen
Добро пожаловать! Регистрация прошла успешно.
Отлично! Ваш аккаунт активирован, контент доступен.
Success! Your billing info is updated.
Billing info update failed.
Как вытащить менеджеров услуг из «бункера» и не навредить услуге

Как вытащить менеджеров услуг из «бункера» и не навредить услуге

10 минут чтения

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

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


1 Что скрывают за собой бункеры
2 Стремление к формализации
3 Под маской конструктивных предложений
4 Внедрить и не изменить
5 Постройка бункера
6 Как действовать безопасно, но эффективно
7 Чем помогает система автоматизации
8 К выводам


Что скрывают за собой бункеры

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

Рассмотрим на примере. В бизнес-приложении возникла ошибка. Чтобы ее устранить, нужно подключить к вопросу команду администраторов баз данных. Предположительно, сбой на стороне СУБД, в которой эта база расположена. Администраторы приложения обращаются к администраторам СУБД, но долго не могут получить от них ответ. В итоге запрос просрочен, пользователь недоволен. Команды-исполнители высказывают взаимные претензии: первые жалуются на долгий ответ, вторые объясняют это тем, что не наблюдали проблем с СУБД, а сам запрос к ним составлен некорректно.

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

  • формализуют способ обращения и набор требуемой для получения ответа информации;
  • вносят в SLA исключения: предоставлять ответ за 8 часов, если не нужны работы на стороне СУБД.

При этом услуги для пользователей формулируются максимально автономно: «Поддержка рабочего места», «Поддержка удаленного рабочего стола Citrix», «Управление доступами к приложениям», «Поддержка бизнес-приложения». Как в данном случае организовать запрос доступа к приложению, интересная задача.

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

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

Так и образуются обособленные «бункеры» услуг. Горизонтальные коммуникации между такими бункерами, по сути, обрубаются и осуществляются «поверху»: через руководство или пользователя.

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

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


Стремление к формализации

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

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

На данном этапе появляется готовность:

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

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

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

Под маской конструктивных предложений

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

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

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

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

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

Спустя 10 лет после запуска портала госуслуг эта картина, мягко говоря, удивляет. Такую же разницу видит сотрудник организации и клиент, если до этого он пользовался внутрикорпоративными сервисами и услугами на интернет-портале.


Внедрить и не изменить

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

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

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

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

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

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

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

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


Постройка бункера

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

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

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

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

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

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

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

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

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

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

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

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


Как действовать безопасно, но эффективно

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

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

Но как добиться этого? В первую очередь, переформатировать само понятие услуги, куда включается два компонента:

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

Чем помогает система автоматизации

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

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

Этот принцип имеет идеологическое значение: поставщик оказывается в позиции заказчика; и техническое: взаимодействие регулируется между поставщиками услуг (например, между ИТ и АХО) и внутри самого поставщика услуг (разработчики и администраторы инфраструктуры) через потребляемые услуги.

Взаимосвязь предоставляемых услуг по принципу единого потока создания ценности

2. Запросы вместо задач. Фокус смещается с выполнения отдельных активностей на оказание услуг, что позволяет:

  • контролировать выполнение SLA на каждом шаге;
  • использовать унифицированные механизмы: определение ответственного, привязка к услуге;
  • стандартизировать интерфейс исполнителя, объединив разные потоки задач и запросов в единый;
  • упростить сбор отчетности.

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

Сервисное взаимодействие получателей и поставщиков услуг через головные и дочерние запросы

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

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

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

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


    К выводам

  1. Внедрение лучших практик сервисного управления часто сталкивается с сопротивлением под маской добрых намерений. Это влечет за собой неуспех проекта, который формально признается удачным и завершенным.
  2. Уход в бункер — это попытка менеджера услуги обезопасить себя и команду от влияния ошибок исполнителей, предоставляющих смежные услуги. Подобный подход реализуется через формализацию взаимодействия между командами.
  3. Стремление менеджеров услуг формализовать процессы и разграничить ответственность логично. В то же время эти действия должны способствовать развитию коммуникации, а не выстраивать обособленные «княжества-бункеры» внутри поставщика услуг. Отвечать за плохую услугу должны все участники, нарушившие SLA.
  4. Требования менеджеров услуг к системе автоматизации приводят к временному улучшению удобства работы исполнителей, но ухудшают качество услуг и гасят коммуникации между командами. Защищая интересы отдельных менеджеров услуг и сервисных команд, можно навредить интересам получателей, заказчиков и поставщиков услуг.
  5. Чрезмерная формализация и обособление команд убивает инициативу. Сервисная культура деградирует. Эта деградация поддерживает себя сама и, возможно, за счет инструмента автоматизации. Как итог — агрессивное отношение к получателю услуги и негативные последствия, которые сказываются на общем результате компании.
  6. Оптимально выстраивать процессы, поддерживающие сервисную культуру и стимулирующие коммуникации между менеджерами услуг. Важно предоставить участникам инструмент, который сделает эту коммуникацию удобной, а оценку качества сервиса справедливой.
  7. Необходимо взвешенно подходить к выбору, когда обсуждается вопрос разграничения ответственности и автоматизации этого разграничения. Придется определить, что важнее: удовлетворить желание безопасности и спокойствия менеджера или обрести свое спокойствие в виде выстроенной коммуникации и работающих услуг.

Наверх ↑