Портал №1 по управлению цифровыми
и информационными технологиями

Измеряем полезность 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. Нет, не курил.

Комментариев: 12

  • Вадим

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

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

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

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

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

    • Вадим, достойное продолжение начатой темы 🙂
      Сначала меня сбило на косинусах у Димы, а уж потом…
      Прекрасно, просто прекрасно. Особенно про 5Pi и военное время 🙂 🙂 🙂

  • “P.P.S. Нет, не курил.”
    Боюсь даже предположить, что же ты тогда делал?

  • К “доле правды”:

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

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

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

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

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

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

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

      • Вадим

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

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

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

          • Вадим

            ну ОК, количество бизнес-транзакций увеличилось на 10 процентов из-за:
            – сокращения общего количества инцидентов на 25 процентов
            – увеличение на 40 процентов количества инцидентов, разрешенных на первой линии
            – сокращение времени обработки инцидентов на 30 процентов в целом, в том числе сложных на 60 процентов
            – сокращение периода разрешения проблем на 50 процентов
            – количество курсов повышения квалификации пользователей – 7, в т.ч. обучено 54 человека

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

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

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

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

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

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

              • Вадим

                Ну вот и договорились


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM