Service desk in ITIL 4: что изменилось?

Я работаю в компании Axelos, которая владеет и управляет ITIL. В компании Axelos я работаю с 2016-го года – все, что написано в ITIL 4, которая опубликована в феврале 2019-го года, так или иначе находится в моей зоне ответственности. Если вам что-то не нравится в ITIL 4, то я именно тот человек, которого надо за это ругать. Если вам что-то нравится в ITIL 4, в конце каждой книжки есть длинный список соавторов, и они все молодцы.

Сразу хочу уточнить, что не могу квалифицированно комментировать вопросы, связанные с коммерческой стороной ITIL – с аккредитациями, сертификациями, курсами и прочим. Этим занимаются другие люди. Я отвечаю только за содержание книг ITIL.

Сегодня я буду говорить о практиках (раньше они назывались процессами) ITIL 4, и, в частности, расскажу о практике Service Desk.

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

 

Ситуация с процессами ITIL до четвертой версии

 

Те, кто знакомы с ITIL, знают, что до четвертой версии процессы составляли наиболее существенную часть всех книг ITIL. Авторы третьей версии сгруппировали процессы по книжкам – каждая из пяти книг третьей версии на 80% состояла из описания процессов.

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

Кроме того, многие решили, что, например, процесс Change Management, описанный в книжке Service Transition, относится исключительно к одноименному этапу жизненного цикла услуг, и ему совершенно незачем быть на этапах до и после (Service Design и Service Operation).

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

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

Далее все это усилилось требованиями профессиональной сертификации, и потом некоторые сертифицированные ИТ-консультанты советовали компаниям, что надо построить у себя департамент Service Design, департамент Service Transition, департамент Service Operation, и устроить в них отделы и группы, названные по имени процессов.

Я сейчас, конечно, преувеличиваю, но, к сожалению, не очень сильно.

 

Смена подхода к процессам (практикам) ITIL в четвертой версии

 

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

• Первая задача, которую мы пытались решить, когда выносили практики из книжек – это смена подхода к реализации рекомендаций ITIL. ITIL гораздо полезнее, если не точечно реализовывать какие-то советы из книжек – организовывать отдельные процессы, практики или функции, – а организовать целостные потоки формирования ценности – то, что в ITIL 4 называется Service Value Stream. В формировании ценности участвуют разные подразделения и, как правило, разные практики. И важно организовать их эффективное взаимодействие в условиях конкретной компании.

• Вторая задача – не менее важная. Сейчас практики публикуются только в электронном виде, они не будут публиковаться на бумаге. Мы хотели сохранить возможность обновлять практики в библиотеке по мере их обновления в реальной жизни. Если завтра появится что-то новое и интересное в части организации служб поддержки, важно иметь возможность не ждать еще десять лет, пока мы всю библиотеку обновим, а взять практику Service Desk и дописать туда нужные слова. Например, первые практики ITIL 4 мы выпустили в мае 2019 года, а сейчас (в сентябре 2020 года – прим. ред.) выяснилось, что там есть какие-то ошибки и опечатки, и мы можем обновить отдельную практику или несколько, не дожидаясь какого-то масштабного релиза. ITIL 4, как продукт, имеет более гибкую архитектуру в отличие от более монолитных прошлых версий.

 

Работа над созданием практик ITIL 4

 

 

Книги ITIL четвертой версии, начиная с Foundation, публикуются с февраля 2019-го – в конце сентября 2020 года опубликована шестая книга, которая завершает картинку общей сертификации.

Параллельно этому, начиная с мая 2019, мы в несколько заходов (за четыре маленьких релиза) публиковали эти самые Practice Guides – практические руководства по отдельным «менеджментам», которые многие знают, начиная со второй версии.

Всего этих Practice Guides 34 штуки, и про одну из описанных практик – Service Desk – я сейчас расскажу.

 

 

Кто все это писал? Важный вопрос, который я никак не могу обойти. Это большая коллективная работа, в ней участвовали больше 50 авторов.

На слайде показаны не все участвовавшие – некоторые лица вам знакомы, потому что они активно работают в российском ITSM-сообществе.

Это люди из разных стран, люди с разным опытом – специалисты в отдельных практиках, специалисты в ITSM в целом, специалисты не в ITSM, а например, в информационной безопасности, разработке, управлении персоналом или управлении проектами.

 

 

Всего их было чуть больше 50 авторов на 34 практики и чуть больше 100 рецензентов.

Всем этим созвездием звезд героически управляла Динара Адырбай, которую тоже те из вас, кто в российском ITSM-сообществе давно, знают и помнят – она первый сертифицированный IT Service Manager, а потом ITIL Expert по второй версии ITIL в Казахстане. Сейчас живет в Ирландии, а управляла всем этим в основном из Австралии.

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

Все эти люди в итоге написали 34 документа примерно 30-40 страниц каждый.

 

Условная группировка практик ITIL 4

 

 

Эти 34 документа мы все-таки вынуждено сгруппировали в 3 группы еще когда работали над ITIL Foundation. Я про эту группировку хочу отдельно сказать, мне кажется, что это очень важный момент, который не стоит упускать.

Практики сгруппированы по принципу происхождения.

• Первая группа (левая на картинке), которая называется General management practices – это практики, которые широко применяются в управлении организациями независимо от того, насколько эти организации думают про информационные технологии и про сервисы..

• Вторая группа – это традиционные ITIL-практики, мы их назвали Service management practices. Они получили свое развитие и известность во многом в контексте ITSM.

• Третья группа самая маленькая – это Technical management practices, технические практики, которые развивались в компаниях вне зависимости от бизнес-контекста (что не очень хорошо) и ITSM-контекста. То есть если у нас есть софт, то мы занимаемся разработкой, поддержкой и управлением этим софтом. Если у нас есть инфраструктура, мы инфраструктурой занимаемся, независимо от того, учитываем мы сервисный контекст или нет. И в дальнейшем они были как бы подняты с технического уровня на более высокий сервисно-ориентированный и бизнес-ориентированный уровень.

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

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

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

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

С практиками примерно такая же история. Они не работают в изоляции.

Практики – это функциональные элементы, которые складываются в более длинные цепочки, в новой архитектуре ITIL 4 именуемые Service Value Stream.

Например, практика, которая называется Service Desk в ITIL 4, выросла из одноименной функции и сводится к первичной обработке поступающих заявок всех видов.

При этом практика Service Desk не работает в изоляции. Например, при обработке заявок, которые оказываются инцидентами, к деятельности, описанной в практике Service Desk, добавляется деятельность, описанная в практике Incident Management – она может выполняться теми же людьми (первой линией поддержки), но это уже другая практика в контексте того же потока формирования ценности.

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

 

Структура практик ITIL 4

 

 

Я упомянул, что практика Service Desk выросла из одноименной функции, а все прочие практики (в том числе, перечисленные на обложках на слайде – Strategy management, Organizational change management, Workforce and talent management – последние две отсутствовали в предыдущих версиях ITIL) в основном выросли из процессов, которые мы знали в ITIL 3.

 

Почему мы придумали другое название – почему это теперь не процессы, а практики?

Service Desk, как и любой другой «менеджмент» из этого набора, – это больше чем процесс.

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

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

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

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

Это значит, что, когда мы строим практику Service Desk, мы оптимизируем потоки работ, организуем команду, автоматизируем процессы и взаимодействуем с партнерами.

Все эти четыре аспекта Service Desk называются термином «Four dimensions of service management» – четыре измерения (перспективы, аспекта) управления услугами.

Этот комплекс из четырех элементов легко соотносится с четырьмя Р (4Ps) при проектировании услуг из ITIL версии 3 – People, Processes, Products, Partners, хотя гораздо логичнее соотносить его с теми 10 «сервисными активами» (ресурсами и способностями), которые тоже были описаны в третьей версии.

Но даже не важно, из чего это вырастало – важно, что мы описываем комплексный подход, и любая практика включает в себя:

• организационное решение;

• потоки работ и интеграцию в потоке формирования ценности;

• технические решения, потоки информации;

• и взаимодействие с третьими сторонами.

Все это вместе – больше, чем процесс.

Процессы остались, но они включены в описание практик. Каждая практика содержит как минимум два процесса, некоторые до четырех процессов. Я покажу на примере Service Desk, как они выглядят.

 

Почему в ITIL 4 включены именно эти практики?

Во-первых, мы взяли все, что было в ITIL 3, и все, что важно для сервисной организации.

А во-вторых, мы постарались закрыть провал в жизненном цикле, который существовал в третьей версии, где после этапа Service Design следовали Service Transition и Service Operation, а этап собственно создания продукта отсутствовал. Потому что где-то между Service Design и Service Transition существует еще Development и/или Procurement, где компоненты приобретаются и складываются в сервисное решение. А уже потом возникает Transition.

Именно поэтому когда-то возникло, к сожалению, противопоставление DevOps и ITIL, где ITIL – это как бы про Operation, а DevOps – это как бы про Development.

И, хотя ITIL содержит полезные рекомендации по организации разработки, а DevOps включает в себя «Ops», изначальное позиционирование во многом противопоставляет эти подходы.

В ITIL 4 мы очень постарались сделать цикл более полным и целостным. Поэтому там появились, например, такие практики как Software Development and Management.

 

Где теперь функции из v3?

Все функции есть в практиках:

Service Desk – это Service Desk, а IT Operation Management, Technical Management и Application Management – в основном в технических практиках (в Infrastructure and Platform Management и Software Development and Management). И они серьезно расширены.

 

Что нового в структуре?

Хорошая новость: все 34 практики описаны очень единообразно – они все следуют единому шаблону. Этот шаблон довольно целостный, он мне нравится. Я про него сейчас немножко расскажу, а потом расскажу, что ITIL v4 предлагает в соответствии с этим шаблоном для Service Desk.

 

 

Итак, у нас есть 34 практики по 30-40 страниц каждая, и все они следуют единой структуре.

Структура такова:

• Мы начинаем с общей информации – формулировка, назначение и общее описание того, чем она занимается.

• Следующий раздел – ключевые понятия и терминология.

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

• Дальше мы идем по тем четырем группам, которые я перечислил:

  • сначала мы говорим про процессы;

  • потом про людей, их роли и компетенции;

  • затем про информацию и технологии, т.е. про автоматизацию практики;

  • и в конце самый маленький раздел, которому еще предстоит развиться, – про партнеров и сорсинг.

Весь этот набор из 34 документов доступен по подписке.

Онлайн-подписка на год стоит около 60 фунтов, это почти 6 тысяч рублей.

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

Если вы сдавали экзамен ITIL в этом году или в прошлом и не получили такую подписку, вы по-прежнему можете это сделать.

• Самый простой способ – спросить вашего тренинг-провайдера про это. Если вы сдавали «основы» напрямую в PeopleCert и не пользовались тренингами для этого, можно спросить у них.

• Можно зайти на сайт realitsm.ru – там есть заметка на русском языке про то, как получить этот доступ.

• Еще один вариант – можно воспользоваться QR-кодом на слайде. Это то место, где подписка оформляется, а если она у вас уже есть, то это то место, где вы найдете все 34 практики.

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

 

Что изменилось в Service Desk

 

Теперь перейдем конкретно к практике Service Desk, потому что это тема сегодняшнего митапа.

 

Назначение Service Desk

 

 

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

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

• Но мне больше импонирует альтернативная версия, которая на слайде переведена на русский язык: те же два предложения, но в другом порядке.

  • Первая наиболее важная часть – это быть единой точкой входа для пользователей, единой точкой контакта с поставщиком. Это основа.

  • Второе – собирать запросы на решение инцидентов и обслуживание. Слово «собирать» – не самый удачный перевод, но лучшего для «capture» я не нашел.

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

 

Ключевые понятия Service Desk

 

 

Практика Service Desk содержит довольно большой раздел про ключевые понятия. Я не буду все их здесь перечислять, приведу только два основных:

• В первую очередь, практика Service Desk направлена на обеспечение результативных и рациональных (effective and efficient) каналов коммуникации между пользователями и поставщиком услуг.

• И второе – эти каналы коммуникации должны быть удобными (convenient).

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

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

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

• Assurance – довольно широкий термин, относящийся к безопасности, подлинности, соответствию политикам. Люди должны быть уверены, что они общаются с реальным Service Desk, а не с пресловутой службой безопасности Сбербанка, о которой все шутят.

• Availability, доступность по времени и месту – очевидное требование. Канал связи с поставщиком должен быть доступен пользователю.

• Contextual intelligence, – это релевантность, отсутствие дублирования, когда вам не приходится по 5 раз повторять одну и ту же информацию, потому что ее потеряли на предыдущих шагах или потому что она бессмысленно накапливается на стороне провайдера. Сюда, в том числе, относятся и вопросы машинного обучения. Нам всем, как пользователям, наверняка приходилось сталкиваться с отсутствием такого контекстного интеллекта (неважно, чем он обеспечен – процедурами, компетенцией или автоматизацией).

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

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

• Integration – интеграция. Здесь мы приходим к важной современной и больной теме омниканальности – бесшовного переключения между каналами. Омниканальность тесно связана с контекстным интеллектом, который был в списке четвертым – я вроде уже все рассказал по телефону, а, оказывается, теперь все это нужно повторить в веб-интерфейсе. И конечно, интеграция с пользовательскими системами там, где это релевантно, чтобы люди могли получать поддержку из привычных интерфейсов. Это еще один немаловажный фактор удобства.

• И, наконец, Usability (удобные интуитивные интерфейсы), что крайне важно для живых пользователей. Тем более, что системы Service Desk (и для тех, кто ими пользуется на стороне провайдера, и для тех, кто ими пользуется на стороне заказчика) нередко выглядят как системы, которые программисты написали для программистов.

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

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

 

Сервисная эмпатия

 

 

Это приводит нас к следующему термину – сервисной эмпатии.

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

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

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

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

Service empathy – это не просто декларация и определение, на эту тему есть много дополнительного материала в ITIL. Когда мы развиваем службу поддержки, надо подумать, как мы можем обеспечить эту сервисную эмпатию и как за счет развития сервисной эмпатии мы сможем улучшить качество наших сервисных отношений с заказчиками и пользователями.

 

Факторы успеха Service Desk

 

 

Второй важный кусочек, который описан в каждой практике, – это так называемые Practice Success Factors.

Термин «Факторы успеха» в целом очень мутный. Мы проводили специальный опрос, когда думали, использовать ли в принципе этот термин в ITIL 4, и очень много людей понимают его по-разному.

• Есть люди, которые думают, что факторы успеха – это некие необходимые пререквизиты успеха. Например, чтобы Service Desk успешно заработал в нашей компании, нужны: поддержка руководства, необходимые навыки коммуникации, прочие soft skills, финансовая поддержка. Все это очень верно, но вообще не специфично – эти факторы успеха применимы вообще для любой инициативы. Поэтому странно описывать их для каждой практики (как это было сделано во второй и частично в третьей версии ITIL).

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

Поэтому мы постарались почти не использовать в ITIL термин CSF (Critical Success Factors – критический фактор успеха). Он немного использован только в одной книге – Digital and IT Strategy.

А для практик мы ввели новый искусственный специфический термин PSF (Practice Success Factor – фактор успеха практики). Определение PSF говорит о том, что это комплексная функциональность внутри практики, необходимая для реализации назначения практики.

В каждой практике таких факторов успеха несколько – от 2 до 4. Для Service Desk их 2.

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

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

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

Если мы представим себе классический поток работ по управлению инцидентами, то:

• В зависимости от того, откуда пришла информация про инцидент (это крики жертв или это система мониторинга) поток работ по управлению инцидентами начинается либо с практики Monitoring and Event Management, либо с практики Service Desk. Если это крики жертв, то первая практика, вовлеченная в поток, будет Service Desk.

• Далее, скорее всего, в этом потоке будет практика управления инцидентами (Incident Management).

• Не исключено, что там будет практика управления изменениями (Change Enablement), а значит развертывание (Deployment Management), и, может быть релизы (Release Management).

• Может участвовать практика управления проблемами (Problem Management).

• И весь этот поток будет поддержан информацией из практик:

  • по управлению уровнем услуг (Service Level Management),

  • конфигурациями (Service Configuration Management),

  • ИТ-активами (IT Asset Management),

  • финансами (Service Financial Management),

  • персоналом (Workforce and Talent Management), если вы к тому же мониторите рабочее время,

  • взаимодействием с поставщиками и партнерами (Supplier Management), если у вас в решение инцидента вовлечены и третьи стороны.

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

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

Так Service Desk помогает решать инциденты. Аналогичным образом каналы коммуникации Service Desk должны эффективно встраиваться:

• в потоки управления изменениями;

• в потоки обработки запросов на новую функциональность приложения;

• в потоки обработки запросов на обслуживание;

• в потоки массового информирования пользователей о чем-нибудь;

• и в другие потоки формирования ценности, в которых за Service Desk идут другие практики, а в каких-то местах снова появляется Service Desk – там, где нужны коммуникации.

 

 

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

Например, если у нас цель по своевременному решению установлена на уровне 95%, то:

• если в соответствии с SLA решается больше 95% инцидентов – то показатели сервиса находятся в зеленой зоне;

• если меньше 95%, но больше 90% – в желтой;

• а если меньше 90% – в красной.

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

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

Ключевые метрики – это полезные с точки зрения измерения характеристики, которые помогают оценить, насколько практика реализована в терминах факторов успеха.

Ключевые метрики фактора успеха «Обеспечение эффективного интерфейса» приведены на слайде.

• Первая метрика – это качество информации, которое обеспечивает Service Desk. Ее значение может складываться из объективных и субъективных оценок качества в соответствии с оговоренными критериями, например:

  • полнота заполнения заявок;

  • корректность заполнения заявок – неважно каким способом они заполнялись (вручную или автоматически);

  • корректность маршрутизации и т.д.

• Вторая метрика – это удовлетворенность потребителей этой информацией. Насколько качеством информации, которую предоставляет Service Desk, довольны люди на следующих линиях поддержки, или люди, которые проводят анализ, или те, кто отвечает за обучение нашего Machine Learning, за использование этих данных для обучения и лучшей автоматизации.

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

Для этого используется очень распространенный в англоязычном мире термин triage, который редко используется в российском сообществе, – первичная категоризация поступающих запросов и их направление для дальнейшей обработки. Это – важная часть работы Service Desk, и корректность этой маршрутизации – один из важных критериев успешной интеграции Service Desk в соответствующие потоки формирования ценности.

На этом вводная часть Service Desk в ITIL заканчивается, и мы переходим к процессам.

 

Четыре измерения Service Desk. Первое – процессы

 

 

В практике Service Desk описано три процесса, в моем вольном переводе это:

• обработка запросов пользователей;

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

• оптимизация практики Service Desk – регулярный обзор того, как мы работаем и улучшение этой работы.

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

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

 

 

Для каждого процесса описаны:

• перечень видов деятельности – они приведены в блоках диаграммы;

• входы в этот процесс и выходы из этого процесса;

• а дальше каждый вид деятельности описан на одном или двух примерах – кто и что делает:

  • кто подтверждает и регистрирует получение заявки;

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

  • кто выполняет первичную категоризацию (triage) и направление в следующий процесс (скорее всего, из какой-то другой практики, например, из Incident Management).

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

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

 

 

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

• идентификация и подтверждение целевой аудитории, чтобы мы не спамили всех обо всем;

• идентификация и подтверждение каналов коммуникации, релевантных для сообщения и целевой аудитории;

• пакетирование информации в нужный формат в соответствии с каналами и аудиторией;

• рассылка информации;

• сбор и обработка подтверждений и обратной связи – подтверждений о получении, если мы их запрашивали, и обратной связи, если она нужна по этим оповещениям.

Этот процесс используется, например, для оповещений о плановых работах, для оповещений о завершении инцидентов, для оповещений о новых услугах. Их может инициировать любая другая практика, но практика, непосредственно коммуницирующая все это, – это Service Desk. Именно здесь появляется соответствующий поток работ, который обеспечивает эффективные коммуникации в нужных пользователей, в нужном формате.

Третий процесс добавлять для иллюстрации я не стал – подход к описанию и так понятен.

Я еще раз подчеркну, что для каждого шага каждый документ, каждый Practice Guide, содержит еще и разные примеры. Например, последний процесс можно по-разному описать для внутреннего Service Desk в малом бизнесе и для компании типа Мегафона или Вымпелкома, когда речь идет о коммуникациях в миллионы людей. Поскольку люди, которые выполняют эти шаги, и сами процедуры выполнения немного отличаются.

ITIL описывает примеры – во-первых, чтобы было понятно, насколько это универсальный поток и процесс, а во-вторых, чтобы было видно, что они отличаются, и надо адаптировать их под себя, а не копировать.

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

 

Второе измерение Service Desk – роли и компетенции

 

 

После процессов ITIL, следующий большой кусок – роли и компетенции.

ITIL 4 почти не дает новых ролей, мы очень постарались не придумывать новые роли, не вводить новые сущности без надобности.

Основной материал, описывающий роли и компетенции в ITIL 4 для каждой практики, включая Service Desk, выглядит так: мы взяли модель ключевых компетенций, необходимых в сервис-менеджменте. Это:

• лидер – тот, кто управляет;

• администратор – тот, кто порядок поддерживает;

• координатор / коммуникатор – тот, кто управляет множественными участниками и поддерживает эффективные коммуникации;

• методист – тот, кто обеспечивает создание новых процедур и новых правил, он не столько знает, сколько умеет их развивать (знать должны все остальные);

• технический эксперт, предметник – в большинстве случаев это айтишник, но не всегда. Например, в практике Workforce and Talent Management – это специалист по рекрутингу, специалист по управлению персоналом.

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

• Название вида деятельности.

• Вероятный исполнитель в компании – в данном случае это оператор Service Desk (Service desk agent). Для некоторых шагов в отдельных практиках нет выделенной позиции исполнителя – там это может быть длинный список, потому что дела могут делать разные люди в зависимости от оргструктуры и масштаба компании.

• Требуемые компетенции.

  • Чтобы идентифицировать и подтвердить целевую аудиторию для будущих коммуникаций (вид деятельности «Идентификация и подтверждение целевой аудитории»), нужно обладать, в первую очередь, компетенциями в области коммуникации и координации (C), и во вторую – компетенциями в области организации и методик работы (М). Поэтому для первой строки в третьей колонке у нас указано C и M.

  • Для деятельности «Идентификация и подтверждение каналов коммуникации» – это C, T и M. Первое важнее, последнее менее важно, а не упомянутые – не критичны для этой деятельности;

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

Это то, что касается человеческой составляющей.

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

 

Третье измерение Service Desk – автоматизация

 

 

Следующий раздел касается информации и технологий.

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

• В первой колонке описаны те же виды деятельности из процессов третьей главы

• Во второй колонке – для каждого вида деятельности описаны типы средств автоматизации. В ней не названия конкретных продуктов, а их типы, например: средства совместной работы (Collaboration tools), средства управления потоками работы и обработки запросов (User query management and workflow tools), средства управления знаниями. Это типы средств автоматизации, которые могут быть полезны для соответствующих шагов.

• Дальше – ключевая функциональность. Например, для идентификации пользователя средство автоматизации – это средство управления потоками работы и обработки запросов (какой-то тикет-менеджмент), а ожидаемая функциональность – это многофакторная аутентификация пользователя.

• Последняя колонка – насколько это важно для успешного решения, для успешного выполнения этого вида деятельности. Например, многофакторная аутентификация – важна.

Если рассмотреть последнюю строку в табличке, то здесь:

• Для вида деятельности «Классификация запросов и заявок для последующей обработки» ключевые средства автоматизации:

  • средство обработки потоков работы заявок;

  • средство управления коммуникациями и совместной работой;

  • средства управления конфигурациями, основанные на средствах искусственного интеллекта;

  • механизмы классификации.

• Чего мы от них ждем? Быстрой корректной категоризации и назначения запросов пользователей.

• Насколько это важно? Это очень важно и тем важнее, чем больше запросов мы обрабатываем.

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

 

Четвертое измерение Service Desk – партнеры и сорсинг

 

 

Четвертое измерение Service Desk – партнеры и сорсинг.

На эту темы написано не очень много, в основном, про то, что раз Service Desk относится к алгоритмизированным работам, то давайте мы все переведем на аутсорсинг в какой-нибудь условный Нижний Новгород. И пусть у нас там какие-то посторонние люди работают по нашим скриптам, а параллельно по скриптам еще десятка клиентов. Главное, чтобы они эти скрипты не перепутали.

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

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

 

Семь основных принципов ITIL

 

 

Каждая практика завершается напоминанием о необходимости следовать семи основным принципам ITIL:

1. Focus on value – Думайте о ценности, ориентируйтесь на предоставление конечной ценности, помните, зачем вы это делаете.

2. Start where you are – Понимайте и используйте текущее состояние. Не надо разрушать весь мир вокруг до основания, чтобы потом что-то новое строить. Развивайте то, что у вас есть.

3. Progress iteratively with feedback – Развивайте это итеративно и постоянно, слушайте обратную связь.

4. Collaborate and promote visibility – Сотрудничайте, поддерживайте прозрачность ваших дел, намерений.

5. Think and work holistically – Думайте и действуйте системно, понимайте общую картину.

6. Keep it simple and practical – Будьте проще и практичнее!

7. Optimize and automate – Перед тем, как автоматизировать, оптимизируйте. Не надо автоматизировать хаос.

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

 

Вопросы

 

Эти книги будут переведены на русский язык?

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

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

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

Кто придумал Value Stream и Value Co-Creation?

Не ITIL и не Axelos. И то, и другое – достаточно давние концепции, мы вообще довольно мало придумываем.

Value Stream – это Lean Production, из бережливого производства, а Co-Creation – понятие из сервисной экономики, сервисного взаимодействия. Оно тоже довольно давнее, на уровне того, как мир меняется и превращается в сервисный, а не в товарный. И то, и другое было с удовольствием принято авторами, архитекторами ITIL, когда мы делали ITIL Foundation.

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

ITIL – это про выстраивание бизнес-процессов на предприятии?

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

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

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

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

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

Я знаю, что в чате есть молодые руководители Service Desk. Может, вы дадите рекомендации, с чего им начать организацию Service Desk в какой-нибудь компании, если они, допустим, сейчас услышали первый раз про практику Service Desk, про ITIL?

Имеет смысл начинать работу с упомянутых семи принципов.

• То есть мы сначала получаем ответ на вопрос, чего мы, собственно, хотим добиться (принцип «Думайте о ценности»).

• Потом мы понимаем, где мы находимся (принцип «Понимайте текущее состояние»).

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

• При этом мы не сможем сделать это сами, поэтому нам нужно поддерживать коммуникации, сотрудничество и прозрачность (принцип «Сотрудничайте, поддерживайте прозрачность»).

• При этом надо не уходить в детали, а научиться видеть целостную картину, что очень перекликается с первым принципом про ценности (принцип «Думайте и действуйте системно»).

• А дальше, когда вы дойдете до уровня описания процессов, придумывания SLA или каталога услуг, вам очень сильно пригодится принцип Keep it simple and practical (Будьте уже проще и практичнее!), потому что удивительные по сложности конструкции иногда городятся без всякой ценности для организации.

• И перед тем, как автоматизировать, максимально оптимизируете то, что есть (принцип «Оптимизируйте и автоматизируйте»). Это тоже очень важная история. Не нужна автоматизация ради автоматизации.

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

Интересный момент. Вы сказали «внедрить ITIL» и потом добавили, что его нельзя внедрить. Это известное заблуждение. Вы можете рассказать, почему некорректно употреблять это словосочетание?

По той же самой причине: ITIL – не цель, а средство. Надо строить эффективную систему менеджмента у себя в организации. А эффективная система менеджмента определяется целями и задачами, ограничениями этой организации.

В английском языке есть мантра «Should be adopted and adapted» – следует принять и адаптировать под свои нужды.

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

Поэтому решайте те задачи, которые у вас есть, используя ITIL как инструмент. Чтобы ориентироваться в этом инструменте, можно почитать эти практики, почитать ITIL Foundation. Если надо, почитать более глубокие книжки ITIL. Это все – полезная информация в смысле понимания собственных возможностей.

Но если у проекта цель – внедрить ITIL, то это проект, который не связан с формированием ценности для компании. Поэтому не надо внедрять ITIL, это вам не нужно.

Сейчас в четвертой версии у ITIL появилась связь с другими методологиями, в том числе с проектными, например, с Agile. Можете рассказать об этом?

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

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

Кроме этого, в ITIL 4 есть практика Project Management, где описано управление программами и проектами. И понятно, что мы не претендуем на то, чтобы дать исчерпывающее описание тому, для чего есть специальная область знаний – целая индустрия вокруг этой области знаний.

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

Все эти области являются важными практиками сервисной организации, и знатоки этих областей имеют, помимо 30 страниц в ITIL, еще 3 000 страниц в других важных полезных книжках. Цель 30 страниц в ITIL – помочь в интеграции этой деятельности, чтобы не оказалось, что люди, которые занимаются информационной безопасностью, живут в мире, отдельном от мира, в котором живет весь остальной бизнес. А они нередко это делают. То же самое касается людей, управляющих, например проектами.

Чтобы было понятно, как это все встраивается в те самые пресловутые потоки формирования ценности, где Information Security Management, Risk Management, Project Management помогают компании формировать ценность для себя, заказчиков и других заинтересованных лиц.

Поэтому это – важные элементы пазла. Раньше в ITIL это выглядело так: представьте себе картину, которая состоит из 100 деталей. Из них примерно 20 – серые дырки, про которые сказано, что об этом надо читать в другом месте. Из-за этого картинка как бы не складывалась.

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

Могут ли с точки зрения поддержки практики ITIL сосуществовать с практиками DevOps?

Практики ITIL могут сосуществовать с любыми практиками – с того момента, как мы договорились про терминологию.

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

Если говорить конкретно про DevOps, Agile и прочие вещи, которые пришли во многом из разработки или развились в разработке, придя из проектного управления, вся эта интеграция очень красиво описана в одной из книжек ITIL, которая называется High-velocity IT (высокоскоростные информационные технологии). И она как раз про то, как обеспечить систему управления сервисной организации с высокой скоростью изменений.

Там очень многие вещи, которые изначально описаны в том же «The DevOps Handbook», или в каком-нибудь «The Phoenix Project», или в Agile-манифесте, или в Scrum – интегрированы в единую картинку, которая, как мне кажется, очень неплохо объединяет разработческую и операционную части, и делают это без излишнего акцента на одну из сторон.

Мы очень старались сделать это сбалансированным описанием. Книжка называется High-velocity IT, и это достойное чтение для тех, кому интересно, как развивается сервис-менеджмент в организации, которая постоянно и быстро меняет свои цифровые продукты.

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Service Desk".