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

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

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

• Какова стоимость простоя? Сюда входит потеря производительности, прибыли и покупателей.
• Какова стоимость повторного выполнения работ? Как много неудавшихся изменений должны быть отменены и повторно выполнены?
• Какова стоимость излишней работы? Организации с нечеткими процессами и плохой связью между ними вынужденно выполняют много лишней/дублирующей работы.
• Какова стоимость проектов, которые не принесли ценности? Многие проекты, которые были полностью профинансированы и выполнены, в конечном итоге не принесли организации ценности, например, ввиду изменения требований.
• Какова стоимость задержки в предоставлении приложений? Влияет ли она на способность предоставления новых услуг?
• Какова стоимость передачи инцидентов на вторую и третью ступень поддержки в сравнении с их разрешением на первой ступени?
• Какова средняя стоимость часа работы для сотрудников?

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

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

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

Можно разбить влияние на пользователей по компонентам (табл. 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 не может посчитать все выгоды, которые получит бизнес от реализации улучшения.

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

• были ли реализованы все предусмотренные улучшения?
• были ли получены выгоды от улучшений?
• было ли достигнуто целевое значение ROI?
• было ли достигнуто запланированное увеличение ценности (VOI)?
• свидетельствуют ли полученные результаты о необходимости повторных действий по улучшению?
• достаточно ли прошло времени для того, чтобы измерять выгоды? Не все выгоды от улучшений проявляются и появляются сразу.

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

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

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

• Где мы сейчас? С этого вопроса бизнес должен начинать любой процесс по оценке инициативы улучшения. Ответ на этот вопрос даст основу для построения базового состояния услуг, которые предоставляются на текущий момент времени. Базовое состояние придает значение будущим измерениям, так как является точкой сравнения того, что было, с тем, что получилось в итоге.
• Что мы хотим? Ответ обычно заключается в требованиях бизнеса, например, 100 % доступность услуг или неограниченная мощность. При этом важно также установить причины этих требований, например, удовлетворенность потребителей или конкурентное преимущество. Так, отдел продаж может хотеть увеличить доступность веб-услуг на 25 % и тем самым увеличить удовлетворенность покупателей, увеличить вероятность продаж и конкурентное преимущество.
• Что нам на самом деле нужно? В рамках обсуждения SLA бизнес может понять, что на самом деле ему не нужна 100% доступность услуг.
• Что мы можем позволить себе? Возможности бизнеса ограничены и не всегда он может позволить себе всё, что хочет. Бизнес должен в первую очередь исходить из своих финансовых возможностей. Именно на этом этапе чаще всего происходит переоценка "то, что мы хотим" в "то, что нам действительно нужно". Например, организация хочет увеличить доступность услуги с 98% на 99%. Но это стоит 3000 000 рублей. Стоит ли 1 % увеличения доступности этих денег? Может ли бизнес позволить себе такие траты? Действительно ли данная услуга критична?
• Что мы получим? Ответ на этот вопрос заключается в SLA в виде целевых показателей и согласованных уровнях услуг.
• Что мы получили? Ответ на тот вопрос находится в результатах мониторинга, отчетах, обзорах о работе услуг.

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

увеличить изображение
Рис. 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.