Измеряем полезность SLM

Доля правды

Для того, чтобы измерить пользу, которую приносит тот или иной процесс управления организации, разумно отталкиваться от назначения процесса (подробнее о назначении процесса смотри https://realitsm.ru/2011/07/purpose-goals-and-objectives).

Для процесса управления уровнем ИТ-услуг назначение может быть сформулировано следующим образом: обеспечение качества ИТ-услуг за счёт согласования и контроля соблюдения обязательств поставщика ИТ-услуг, а также организации устранения выявленных несоответствий. В такой редакции SLM ответственен за реализацию цикла PDCA над оперативной деятельностью в рамках жизненного цикла услуг, направленного на постепенное устранении несоответствий между ожиданиями заказчика услуг и реальными показателями предоставляемых услуг. Именно такой подход (без привязки к ИТ) зафиксирован в разделе 0.2 «Process approach» стандарта ISO 9001:2000 «Quality management systems – Requirements».

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

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

  1. Степень удовлетворённости достигаемой utility услуг?
  2. Степень удовлетворённости достигаемой warranty услуг?
  3. Степень соответствия показателей warranty реальным потребностям заказчика?

Ответы даются по шкале 0-1 (0 – полное несоответствие, 1 – полное соответствие). Для определения итогового показателя можно использовать взвешенное арифметическое усреднение.

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

Доля шутки

У такого подхода также есть весьма забавная геометрическая интерпретация. Обозначим ответы на вопросы 1-3 в примере выше как Xi. Поскольку Xi изменяется от 0 до 1, можно представить его в виде косинуса некоторого угла Фi (изменяемого от 0 до Pi/2). Тогда:

  • если Xi = 1 (поставщик полностью соответствует ожиданиям заказчика по i-тому показателю), то Фi = 0. Фактически, заказчик и поставщик смотрят в одну сторону, воспринимают происходящее «под одним углом»;
  • если же Xi = 0 (полное рассогласование), то Фi = Pi/2. То есть заказчик и поставщик воспринимают происходящее абсолютно по-разному, перпендикулярно друг другу;
  • промежуточные значения 0<Xi<1 соответствуют «некоторому повороту» 0<Фi<Pi/2 взгляда поставщика относительно взгляда заказчика.

Идеальной ситуации соответствует равенство Фi=0 для всех i. То есть имеет место полное «выравнивание» между поставщиком и потребителем. Вот вам наглядная геометрия BITA 😀

P.S. Да, придумал сам.

P.P.S. Нет, не курил.

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

CleverKPI Сбалансированная система управления информационными технологиями по KPI

Измерение и оценка эффективности ИТ-процессов, проектов и услуг.
 

Узнайте больше!

Комментарии и мнения

  1. Вадим

    IMHO что-то сильно хромает «геометрия» в предложенном варианте математической интерпретации.

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

    во-вторых, с чего это на арене математических экзерсисов появляется косинус? где тут прилегающий катет? и где гипотенуза? которые как известно людям, сведущим в математике, определяют значения косинуса угла между ними. и почему область значений Фi — только от 0 до Pi/2? это случаем не намек на неразвитость российской сферы услуг в целом, и ИТ-услуг в частности? Тогда, коллега, Вы политически неверно поступаете! Нет бы измерять Фi от того же Pi/2 (скажем так, современный уровень российского сервиса) до 4 или даже 5Pi, соответствующий аналогичному показателю в развитых странах (про военное время я уж и не говорю). Тем самым открывая широкие перспективы настоящим измерениям качества, которое, получается, в перспективе будет практически постоянно расти без каких-либо искусственных границ! А тут какое-то сра... невнятное Pi/2. Как этим мотивировать других читающих эту ахинею коллег предлагаете, а?

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

    ;о)))))))))))))))))))

    0
    0
  2. Роман Журавлёв

    К «доле правды»:

    Дим, мне кажется, ты немного лукавишь. Качество услуг и полезность SLM — не одно и то же, верно? (В любимой Gartner Business Value Model одна метрика — system performance, вторая — service level effectiveness.)

    Заметка — в основном про качество услуг и варианты его оценки; Заголовок — про полезность процесса.

    IMHO, c назначением процесса связана не столько его полезность, сколько его результативность. Полезность же — скорее с целью, мне кажется (различия между назначением и целью — по версии того же поста, www.realitsm.ru/2011/07/p... -and-objectives/).

    ****

    Что же касается качества услуг, то обычно мы рассказываем о необходимости совместно использовать метрики качества в сравнении с SLA, удовлетворенности потребителей и качества работы инфраструктуры. Эти три оценки могут давать пересекающиеся результаты, но в чем-то будут расходиться. Собственно, мы говорили об этом полгода назад: www.realitsm.ru/2010/11/metrics/#comment-1158

    0
    0
    1. Дмитрий Исайченко Автор

      «Качество услуг и полезность SLM — не одно и то же»

      Почему? Мне казалось, что полезность SLM как раз в стабильно высоком качестве услуг.

      «IMHO, c назначением процесса связана не столько его полезность, сколько его результативность»

      Допустим. Тогда предложи, пжл, метрику полезности SLM.

      0
      0
      1. Вадим

        IMHO

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

        SLM по сути определяет необходимые (т.е. востребованные) уровни обслуживания, связанные с целями бизнеса (вот и первая польза), контролирует (измеряет) соответствие фактического качества услуг с плановыми уровнями обслуживания (вот и вторая польза), формирует отчетность, демонстрирующую это самое фактическое качество услуг (вот и третья польза). а вот если каждая из этих «польз» сформулирована в терминах бизнеса, то может это и даст искомые метрики? например, за счет таких-то и таких-то мероприятий по управлению услугами количество бизнес-транзакций увеличилось на 10 процентов — чем не метрика?

        0
        0
        1. Дмитрий Исайченко Автор

          «например, за счет таких-то и таких-то мероприятий по управлению услугами количество бизнес-транзакций увеличилось на 10 процентов — чем не метрика?»

          Только тем, что это не метрика SLM. Во всяком случае, в классическом ITIL-овском понимании SLM.

          0
          0
          1. Вадим

            ну ОК, количество бизнес-транзакций увеличилось на 10 процентов из-за:

            — сокращения общего количества инцидентов на 25 процентов

            — увеличение на 40 процентов количества инцидентов, разрешенных на первой линии

            — сокращение времени обработки инцидентов на 30 процентов в целом, в том числе сложных на 60 процентов

            — сокращение периода разрешения проблем на 50 процентов

            — количество курсов повышения квалификации пользователей — 7, в т.ч. обучено 54 человека

            Если же говорить непосредственно о процессе SLM, т.е. разработке, согласовании и контроле SLA, OLA, UC etc то здесь можно контролировать сроки и количество итераций прохождения документов.

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

            0
            0
            1. Дмитрий Исайченко Автор

              «Т.е. отработали ли в рамках заданных временных параметров ИТишники конечно важно, но не является определяющим, как это ни странно»

              Вот именно! Потому что сокращение времени инцидентов и прочие операционные параметры «растят» соответствующие операционные процессы. Но «растят» в отрыве от работы с заказчиком услуг, т.е. работа над качеством ИТ-услуг выполняется наполовину — повышение возможностей ИТ. SLM как раз и добавляет вторую половину — работу с заказчиком, работу с его ожиданиями и оценкой результатов.

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

              В этом и есть суть подхода, сформулированного в разделе «Доля правды».

              0
              0

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ОКТ
23
ОКТ
26
Учебный курс:
Основы DevOps