Одним из столпов ITIL является Service Desk, единая точка контакта между пользователем и поставщиком услуг. В диспетчерскую службу Service Desk клиенты обращаются при возникновении инцидентов или проблем и вопросов, связанных с предоставляемой услугой. Служба регистрирует, отслеживает и управляет решением проблем, которые были доведены до ее сведения.
За долгую историю ITIL службу Service Desk внедрило множество компаний. Кто-то полагался на готовые инструменты, кто-то шел своим путем. У кого-то получилось с первого раза, а кто-то «набивал шишки». Опыт последних помог нам сформировать список самых распространенных ошибок при внедрении Service Desk — от банальных и легко устраняемых до вполне серьезных — которым мы и делимся в этой статье.
/ Wikimedia / Anthony DeLorenzo / CC
Линда Киркпатрик (Linda Kirkpatrick), старший консультант по управлению ИТ-услугами Flycast Partners, работавшая более чем с 300 различными компаниями, утверждает, что многие клиенты были попросту не готовы к внедрению инструментов ITSM. Или, ее словами, — «если бы мне давали четверть доллара каждый раз, когда я начинала работать с компанией, не готовой к внедрению ITSM, сейчас я сама могла бы нанять себе старшего консультанта по управлению ИТ-услугами».
Компании хотят, чтобы сторонний партнер внедрил Service Desk отдельно от других процессов. В результате организации получают подход, который противоречит ITIL, — вместо акцента на сервисе появляются разрозненные службы, совершающие несогласованные действия.
Решение. Важно работать в тесном контакте с поставщиками ITSM-инструментов и иметь целостное представление о происходящем в организации. Внедрение Service Desk должно стать не самоцелью, а частью плана непрерывного улучшения обслуживания. Для этого проектная команда должна работать вместе с сотрудниками компании, а они, в свою очередь, должны не только разбираться в новых политиках и инструментах, но и понимать, как устроен весь процесс оказания услуги. Так развитие всех служб будет двигаться по единому курсу, что обеспечит синергетический эффект и слаженную работу инструментов.
Внедрение Service Desk приводит к большим изменениям в организации с точки зрения культуры работы. Эти изменения персонал не всегда принимает безболезненно. Принципы ITIL, подразумевающие сервисный подход, понятны не всем. Подтверждением тому служит дискуссия на Reddit, в которой руководитель службы Help Desk жаловался на своих подчиненных: у них нет стремления учиться, проявлять инициативу и просить советов.
Переход к профессиональной системе Service Desk может вызвать скептицизм со стороны сотрудников. Так случилось у организаторов мероприятия EuroJam — волонтеры из службы поддержки не хотели пользоваться новым инструментом.
Есть несколько методов реакции на сопротивление сотрудников в такой ситуации: например, игнорирование, насильное внедрение или же убеждение подчиненных в пользе Service Desk. Первые два метода, как правило, не дают положительных результатов — технически Service Desk будет внедрен, но фактически люди продолжат сопротивляться нововведению. Если мнение сотрудников не учитывается, слаженной работы не получится.
В случае с EuroJam решить проблему помогло то, что нововведения внедрялись постепенно и с учетом особенностей мероприятия — руководство не требовало выстраивать весь процесс «идеально». Это же позволило упростить процесс внедрения — если представить изменение в виде нескольких несложных шагов и адаптировать их под особенности организации, шанс на успешное завершение процесса будет намного выше. Например, волонтеры EuroJam по завершении мероприятия стали буквально «евангелистами Service Desk».
Решение. Сотрудники не принимают новое, потому что не видят в нем ценность для себя. Важно объяснить, как новая служба поддержки улучшит результаты их работы. Следует указать на существующие проблемы и продемонстрировать, как Service Desk решит их и облегчит жизнь всей команды.
Управление инцидентами напрямую зависит от системы тикетов. Основная задача тикетов — управление всеми входящими запросами. Поскольку ИТ-отделы, как правило, имеют дело с большим количеством запросов, им требуется система для управления жизненным циклом каждого отдельного запроса — от формирования до разрешения. Эффективная система тикетов позволяет своевременно решать все проблемы. Она также облегчает работу отделов, так как вся информация сохраняется в едином центре для последующего использования.
Что бывает, когда система тикетов выстроена недостаточно основательно, демонстрирует опыт компании Warfare Plugins, разработчика плагинов для WordPress. Компания завела систему управления инцидентами, в которую направлялись вопросы пользователей. Простые запросы могли обслуживать все члены команды, а за сложные отвечал только один человек.
Однажды ему пришлось отлучиться на некоторое время. По возвращении он обнаружил огромное количество скопившихся тикетов. В итоге сотрудник потратил месяц на исправление ситуации. Это сказалось на среднем показателе обработки одного запроса и косвенно — на качестве продукта: тикеты указывали на недостатки плагинов, которые следовало устранить.
/ Wikimedia / Axel Boldt / CC
Решение. Разобрав почтовый ящик, команда ввела новое правило — разрешение любой проблемы в течение часа или двух даже в выходные дни. Это может показаться банальным, но еще на этапе внедрения следует устанавливать четкие KPI, среди которых обязательно должно быть время обработки тикета. Также следует выстроить грамотное распределение запросов между компетентными сотрудниками таким образом, чтобы разрешение инцидента не зависело от одного человека, и объем рабочей нагрузки соответствовал возможностям отделов.
ITIL предполагает, что у каждой команды и отдельного сотрудника в сервисно-ориентированной системе есть понятный набор обязанностей и полномочий. На этапе внедрения Service Desk важно грамотно распределять ответственные роли. ITSM позволяет комбинировать роли и зоны ответственности, но важно учитывать и компетенции сотрудников.
О важности этого, также довольно очевидного, нюанса пишут, например, исследователи из Университета Канадзава (Япония), которые совместно с китайскими коллегами из Shanghai Wicresoft изучали вопросы внедрения Service Desk в азиатских компаниях. Они приводят кейс одной из китайских организаций, где до полноценного внедрения Service Desk применялся собственный прототип системы управления инцидентами.
Непонимание компетенций и зон ответственности привело к тому, что простые запросы служба поддержи направляла квалифицированным инженерам. Проблема состояла в том, что на решение «дешевых» и «простых» вопросов тратилось время «дорогих» специалистов, которым приходилось отрываться от своих профильных обязанностей.
Решение повлекло за собой не только высвобождение времени у профильных специалистов, но и повышение других сопутствующих показателей: удовлетворенность VIP-клиентов (которыми должны были заниматься более квалифицированные сотрудники) возросла с 60 до 90%, в несколько раз более эффективно стала использоваться база знаний, сократилось время обработки запроса. Вот только на восстановление порядка из хаоса пришлось привлечь дополнительные силы, а весь процесс «реструктуризации Service Desk» занял полгода.
Решение. Введение автоматической сортировки запросов по сложности и направленности на этапе внедрения решает проблему загруженности команд. Автоматизированные инструменты мониторинга гарантируют, что все запросы будут обработаны — вне зависимости от сложности. А создание базы знаний помогает накапливать ответы на технические вопросы для того, чтобы сотрудники могли разрешать простые проблемы в штатном режиме, даже если необходимого специалиста нет на рабочем месте.
Конечно, это не все проблемы, с которыми сталкиваются компании при внедрении Service Desk. Однако они относятся к наиболее «популярным» и влекут за собой дальнейшие сложности. Поэтому здесь как никогда актуальна возможность «учиться на чужих ошибках» и заранее предусмотреть подобные варианты развития событий.
Дополнительные источники по теме из нашего корпоративного блога:
За долгую историю ITIL службу Service Desk внедрило множество компаний. Кто-то полагался на готовые инструменты, кто-то шел своим путем. У кого-то получилось с первого раза, а кто-то «набивал шишки». Опыт последних помог нам сформировать список самых распространенных ошибок при внедрении Service Desk — от банальных и легко устраняемых до вполне серьезных — которым мы и делимся в этой статье.
/ Wikimedia / Anthony DeLorenzo / CC
1. Изолированное внедрение
Линда Киркпатрик (Linda Kirkpatrick), старший консультант по управлению ИТ-услугами Flycast Partners, работавшая более чем с 300 различными компаниями, утверждает, что многие клиенты были попросту не готовы к внедрению инструментов ITSM. Или, ее словами, — «если бы мне давали четверть доллара каждый раз, когда я начинала работать с компанией, не готовой к внедрению ITSM, сейчас я сама могла бы нанять себе старшего консультанта по управлению ИТ-услугами».
Компании хотят, чтобы сторонний партнер внедрил Service Desk отдельно от других процессов. В результате организации получают подход, который противоречит ITIL, — вместо акцента на сервисе появляются разрозненные службы, совершающие несогласованные действия.
Решение. Важно работать в тесном контакте с поставщиками ITSM-инструментов и иметь целостное представление о происходящем в организации. Внедрение Service Desk должно стать не самоцелью, а частью плана непрерывного улучшения обслуживания. Для этого проектная команда должна работать вместе с сотрудниками компании, а они, в свою очередь, должны не только разбираться в новых политиках и инструментах, но и понимать, как устроен весь процесс оказания услуги. Так развитие всех служб будет двигаться по единому курсу, что обеспечит синергетический эффект и слаженную работу инструментов.
2. Трата времени на «войну с сотрудниками»
Внедрение Service Desk приводит к большим изменениям в организации с точки зрения культуры работы. Эти изменения персонал не всегда принимает безболезненно. Принципы ITIL, подразумевающие сервисный подход, понятны не всем. Подтверждением тому служит дискуссия на Reddit, в которой руководитель службы Help Desk жаловался на своих подчиненных: у них нет стремления учиться, проявлять инициативу и просить советов.
Переход к профессиональной системе Service Desk может вызвать скептицизм со стороны сотрудников. Так случилось у организаторов мероприятия EuroJam — волонтеры из службы поддержки не хотели пользоваться новым инструментом.
Есть несколько методов реакции на сопротивление сотрудников в такой ситуации: например, игнорирование, насильное внедрение или же убеждение подчиненных в пользе Service Desk. Первые два метода, как правило, не дают положительных результатов — технически Service Desk будет внедрен, но фактически люди продолжат сопротивляться нововведению. Если мнение сотрудников не учитывается, слаженной работы не получится.
В случае с EuroJam решить проблему помогло то, что нововведения внедрялись постепенно и с учетом особенностей мероприятия — руководство не требовало выстраивать весь процесс «идеально». Это же позволило упростить процесс внедрения — если представить изменение в виде нескольких несложных шагов и адаптировать их под особенности организации, шанс на успешное завершение процесса будет намного выше. Например, волонтеры EuroJam по завершении мероприятия стали буквально «евангелистами Service Desk».
Решение. Сотрудники не принимают новое, потому что не видят в нем ценность для себя. Важно объяснить, как новая служба поддержки улучшит результаты их работы. Следует указать на существующие проблемы и продемонстрировать, как Service Desk решит их и облегчит жизнь всей команды.
3. Неравномерная нагрузка на сотрудников
Управление инцидентами напрямую зависит от системы тикетов. Основная задача тикетов — управление всеми входящими запросами. Поскольку ИТ-отделы, как правило, имеют дело с большим количеством запросов, им требуется система для управления жизненным циклом каждого отдельного запроса — от формирования до разрешения. Эффективная система тикетов позволяет своевременно решать все проблемы. Она также облегчает работу отделов, так как вся информация сохраняется в едином центре для последующего использования.
Что бывает, когда система тикетов выстроена недостаточно основательно, демонстрирует опыт компании Warfare Plugins, разработчика плагинов для WordPress. Компания завела систему управления инцидентами, в которую направлялись вопросы пользователей. Простые запросы могли обслуживать все члены команды, а за сложные отвечал только один человек.
Однажды ему пришлось отлучиться на некоторое время. По возвращении он обнаружил огромное количество скопившихся тикетов. В итоге сотрудник потратил месяц на исправление ситуации. Это сказалось на среднем показателе обработки одного запроса и косвенно — на качестве продукта: тикеты указывали на недостатки плагинов, которые следовало устранить.
/ Wikimedia / Axel Boldt / CC
Решение. Разобрав почтовый ящик, команда ввела новое правило — разрешение любой проблемы в течение часа или двух даже в выходные дни. Это может показаться банальным, но еще на этапе внедрения следует устанавливать четкие KPI, среди которых обязательно должно быть время обработки тикета. Также следует выстроить грамотное распределение запросов между компетентными сотрудниками таким образом, чтобы разрешение инцидента не зависело от одного человека, и объем рабочей нагрузки соответствовал возможностям отделов.
4. Отсутствие логики в распределении полномочий
ITIL предполагает, что у каждой команды и отдельного сотрудника в сервисно-ориентированной системе есть понятный набор обязанностей и полномочий. На этапе внедрения Service Desk важно грамотно распределять ответственные роли. ITSM позволяет комбинировать роли и зоны ответственности, но важно учитывать и компетенции сотрудников.
О важности этого, также довольно очевидного, нюанса пишут, например, исследователи из Университета Канадзава (Япония), которые совместно с китайскими коллегами из Shanghai Wicresoft изучали вопросы внедрения Service Desk в азиатских компаниях. Они приводят кейс одной из китайских организаций, где до полноценного внедрения Service Desk применялся собственный прототип системы управления инцидентами.
Непонимание компетенций и зон ответственности привело к тому, что простые запросы служба поддержи направляла квалифицированным инженерам. Проблема состояла в том, что на решение «дешевых» и «простых» вопросов тратилось время «дорогих» специалистов, которым приходилось отрываться от своих профильных обязанностей.
Решение повлекло за собой не только высвобождение времени у профильных специалистов, но и повышение других сопутствующих показателей: удовлетворенность VIP-клиентов (которыми должны были заниматься более квалифицированные сотрудники) возросла с 60 до 90%, в несколько раз более эффективно стала использоваться база знаний, сократилось время обработки запроса. Вот только на восстановление порядка из хаоса пришлось привлечь дополнительные силы, а весь процесс «реструктуризации Service Desk» занял полгода.
Решение. Введение автоматической сортировки запросов по сложности и направленности на этапе внедрения решает проблему загруженности команд. Автоматизированные инструменты мониторинга гарантируют, что все запросы будут обработаны — вне зависимости от сложности. А создание базы знаний помогает накапливать ответы на технические вопросы для того, чтобы сотрудники могли разрешать простые проблемы в штатном режиме, даже если необходимого специалиста нет на рабочем месте.
Конечно, это не все проблемы, с которыми сталкиваются компании при внедрении Service Desk. Однако они относятся к наиболее «популярным» и влекут за собой дальнейшие сложности. Поэтому здесь как никогда актуальна возможность «учиться на чужих ошибках» и заранее предусмотреть подобные варианты развития событий.
Дополнительные источники по теме из нашего корпоративного блога:
