Процессы в рамках Непрерывного улучшения услуг

15.1. 7-шаговый процесс улучшения

Мы уже рассматривали основные шаги этого процесса улучшения в предыдущей лекции. В этой лекции мы рассмотрим его более детально (рис. 15.1).

Шаги 1 и 2 циклически повторяются и тесно связаны со стратегическими, тактическими и операционными задачами организации. Для поддержки деятельностей по улучшению, организация может заказать и внедрить новую технологию по сбору и обработке данных или нанять персонал с необходимой квалификацией. Организация часто пренебрегает первыми шагами из-за ряда ошибочных утверждений:

Рассмотрим 7 шагов процесса улучшения.

Шаг 1 - Определить то, что необходимо измерить

Шаг 1 представляет собой диалог между поставщиком и заказчиками, который позволит избежать разногласий в будущем. Здесь они договариваются о целях и задачах, в соответствии с которыми решается, что необходимо измерять. Стартовой точкой для обсуждения является Каталог услуг и требования уровня услуг различных заказчиков. Здесь поставщик услуг как бы говорит себе:"Что я бы измерял в идеальном мире? Что наиболее важно для бизнеса?".

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

Шаг 2 - Определить то, что можно измерить

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

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

Шаг три - Сбор данных

Сбор данных предполагает наличие установленного механизма мониторинга в рамках организации. Он может быть как автоматическим, так и ручным. В контексте CSI упор в мониторинге должен быть сделан не на актуальном состоянии объектов, а на поиске мест, где требуются улучшения или где они возможны. Для поддержки CSI организация должна собирать значения следующих метрик:

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

Шаг 4 - Обработка данных

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

Шаг 5 - Анализ данных

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

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

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

Шаг 6 - Использование и предоставление информации

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

В ITIL выделено три основные аудитории:

Шаг 7 - Реализация корректирующих действий

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

Рассмотрим пример из публикации "ITILv3.Continual Service Improvement".

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

Ни один из рассмотренных выше семи шагов не должен быть упущен или недостаточно проработан. Ошибки и недоработки могут привести к неэффективности всего процесса CSI.

15.2. Формирование отчетности

При формировании отчетности IT необходимо:

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

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

15.3. Измерение услуг

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

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

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

Для построения Системы измерения услуг необходимо определить, что именно будет измеряться:

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

Система измерения услуг предназначена для объединения различных мер и метрик. Конечным результатом является формирование общего взгляда на услуги в контексте измерения их компонентов. Эта информация станет основой для построения оценочной ведомости услуг и формирования системы сбалансированных показателей. Оценочная ведомость услуг является своего рода карточкой состояния услуги за определенный промежуток времени - недели, месяца, квартала. Система сбалансированных показателей (Balanced Scorecard) - инструмент управления, разработанный докторами Робертом Капланом (Гарвадская бизнес-школа, Harvard Business School) и Дэвидом Нортоном. Система сбалансированных показателей позволяет декомпозировать Стратегию до Ключевых показателей производительности (KPI). Соотнесение Производительности с KPI используется для демонстрации успешности исполнения Стратегии. Сбалансированный показатель состоит из 4-х главных блоков (областей, направлений), каждый из которых включает в себя небольшое количество KPI[1]. На рис. 15.6 представлены различные уровни, которые должны быть рассмотрены в рамках построения Системы измерения услуг.

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

Эффективное измерение услуг должно быть сконцентрировано вокруг нескольких важных индикаторов, которые будут полезны для достижения желаемых результатов. Если таких индикаторов будет много, процесс измерения потеряет эффективность, понятность и лаконичность. На уровне измерения услуг IT должно представлять результаты в понятном для бизнеса виде. ITIL не рекомендует использовать процентные показатели доступности, надежности и производительности. Они используются на уровне отдельных компонентов. Ниже приведены показатели, которые имеют значение для заказчиков:

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

После определения мер, необходимо установить целевые показатели. Целевые показатели являются количественным отображением целей, которые должны быть достигнуты. Обычно они определяются исходя из требований бизнеса или требований регуляторов и включаются в SLA. При определении целевых показателей необходимо учитывать фактические возможности IT. ITIL рекомендует применять пофазовый подход, который заключается в том, что для первой фазы целевые показатели будут ниже, чем для второй, и т.д. Целевые показатели должны удовлетворять принципу SMART (specific - индивидуальный, measurable - измеряемый, achievable - достижимый, relevant - значимый, timely - своевременный). Они должны быть достижимы и понятны для тех, кто будет с ними работать. Определение целевых показателей является стартовой точкой для построения базового состояния, с помощью которого в дальнейшем будет измерена эффективность улучшения.

Для измерения процессов сервис-менеджмента применяется такой же подход. На уровне деятельностей процесса определяется то, что будет измеряться на основе ключевых показателей производительности (KPI). KPI в свою очередь должны поддерживать цели высокого уровня. Рассмотрим пример из публикации "ITILv3. Continual Service Improvement". Процесс Управления изменениями предназначен для повышения качества услуг. Одна из основных проблем с качеством услуг - простой услуг в результате неудавшихся изменений. Основная причина неудавшихся изменений - большое количество срочных изменений, которые проводятся в обход формального процесса реализации изменений. В этом контексте предлагаются следующие метрики деятельности:

Четыре главных уровня для ведения отчетности. Нижний уровень содержит метрики деятельностей процесса, например, количество утвержденных Запросов на изменение (RFC) или количество успешно реализованных изменений. Следующий уровень содержит ключевые показатели производительности для каждого процесса. Метрики деятельностей процесса должны поддерживать KPI. KPI в свою очередь поддерживают цели высокого уровня, например, повышение качества услуг, уменьшение затрат или увеличение удовлетворенности пользователей. В итоге все попадает в Систему сбалансированных показателей (рисунок 15.7).

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

Можно выделить следующие категории KPI:

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

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

Другой точкой применения является сравнение. Результаты измерения могут нести в себе мало смысла без последующего сравнения со стандартом или базовым состоянием. Используются следующие сравнения:

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

На основе результатов сравнения создаются отчеты. Они создаются для :

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

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

15.4. ROI для Непрерывного улучшения услуг

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

Выше перечислены только основные вопросы, которые необходимо рассмотреть в рамках анализа ROI.

Существует множество методов измерения доступности и ведения соответствующих отчетов:

Можно разбить влияние на пользователей по компонентам (табл. 15.2).

При сбое необходимо определить продолжительность простоя, количество людей, которых он затронул, и, с помощью стоимости часа работы, посчитать издержки в результате потери производительности. Например, приложение из табл. 15.2 вышло из строя и это негативно отразилось на 7 354 пользователях. Время простоя составило 39 минут. Средняя стоимость часа работы 100 рублей. Тогда количество пользователей умножаем на 39 минут, и делим на 60 (переводим в часы) и все это умножаем на стоимость часа (100 рублей). Получаем стоимость простоя -(7354*39/60)*100=478010 рублей. Подсчет стоимости простоя является ключевым для определения потерь бизнеса в случае недоступности услуги.

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

Допустим, на улучшение услуг потрачено 300 000 рублей (табл. 15.4).

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

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

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

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

15.5. Вопросы бизнеса к CSI

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

На рис. 15.8 схематически изображен подход бизнеса к улучшению.

15.6. Управление уровнем услуг (SLM)

В предыдущих лекциях мы уже не раз говорили об этом процессе, тем не менее, вспомним его определение еще раз. Управление уровнем услуг (Service Level Management) - процесс, ответственный за обсуждение Соглашений об уровне услуг, и гарантирующий их выполнение. SLM ответственен за то, что процессы Управления услугами, соглашения операционного уровня и внешние договоры будут соответствовать согласованным целевым показателям уровня услуги. SLM отслеживает и отчитывается по уровням услуг, выполняет регулярные обзоры для Заказчиков[1]. SLM помогает CSI тем, что определяет требования к мониторингу и объекты мониторинга - то, что необходимо контролировать. С помощью SLM бизнес "доносит" до IT свои желания, потребности и новые требования к услугам. Это дает старт CSI и помогает ранжировать проекты и инициативы по улучшению.

SLM создается на этапе Проектирования жизненного цикла услуг. CSI должен принимать участие в создании SLM, чтобы в нем были определены достижимые цели, от которых будут определяться возможности для улучшения услуг. SLM, в свою очередь, является триггером для создания Плана улучшения услуг (SIP). IT и бизнес следят за тем, чтобы SLM выполнялся, и услуги предоставлялись на согласованных уровнях. В случае появления несоответствий, возникает необходимость в улучшениях.

Заключение

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

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