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

Разрушители легенд: документы SLM

Опубликовано 9 апреля 2012
Рубрики: SLA, SLM, BRM
Комментарии

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

Начнём с технических услуг и OLA. По-серьёзному это конечно разговор не на 5 минут. Но если быть кратким, наличие каталога технических услуг и OLA почти всегда недооценивается по последствиям в виде влияния на другие процессы, отношения между подразделениями и даже на оргструктуру. Такая практика управления применима далеко не ко всем компаниям. То есть уточню: сервисный подход вообще применим лишь к небольшому количеству компаний (из тех, что известны мне), и только к очень небольшой доле из этого маленького количества компаний применима практика ведения каталога технических услуг и OLA. О том, что с этим надо быть осторожнее, как-то давно (2006?) писал Pink elephant, а относительно недавно (2011) – IT Skeptic. Подтверждает это и наша проектная практика.

Теперь про каталог бизнес-услуг и SLA. Здесь тоже нет единственно верной дороги. Сам по себе каталог услуг с различными уровнями обслуживания по каждой услуге фактически востребован только в сценариях массового обслуживания – когда у одной услуги может быть множество заказчиков, каждый – на своём уровне. В случае внутреннего ИТ-подразделения довольно часто мы имеем одного заказчика, в качестве которого выступает основной бизнес (в виде одного или нескольких подразделений). Да и технические возможности по варьированию уровня услуги также ограничены (поскольку используется единая инфраструктура). В этом случае отделение бизнес-услуг от SLA может быть излишним. Фактически сам каталог услуг становится «каталогом SLA» (а приложением к SLA идут внешние спецификации услуг).

Поэтому стандартное восприятие продуктов (outcomes) SLM как «два каталога услуг + SLA + OLA» имеет довольно ограниченное применение. Это вдвойне важно осознавать в случае, когда сам процесс управления уровнем услуг в основном воспринимается как процесс, который готовит и актуализирует эти документы. Хотя, на мой взгляд, это не составляет и половины содержания SLM как процесса 🙂

«Контора пишет!», как говорил один известный персонаж.

«VAP: Управление уровнем услуг и каталогом услуг»
Разработка каталога, SLA, метрик качества, расчёт доступности

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

  • Георгий

    что-то я в понедельник не уловил глубокую мысль статьи ? 🙂
    SLM – это нечто большее чем каталог услуг + SLA + OLA ? это идея?

    • Может я в понедельник не сформулировал 🙂

      Идеи две:

      1. Отдельный каталог бизнес-услуг и SLA, каталог технических услуг, OLA нужны далеко не всегда и не являются неотъемлемыми артефактами SLM.
      2. И да, конечно, “SLM — это нечто большее чем” набор документов.

      Навеяло очередными обсуждениями.

      • Георгий

        Ага, так понятнее 🙂

        По идее №1. Конечно, тут невозможно спорить, каталог услуг не является неотемлемым понятием SLM, как минимум с той поры, как в ITILv3 был включен процесс управления каталогом услуг 🙂
        По идее №2. Да, SLM – это не набор документов, это, если хочешь, образ жизни и образ мыслей (что там первично, бытие или сознание? :))
        Но, эту мысль надо повторять для каждого процесса, ибо любой процесс это не набор документов, ну я по крайней мере так считаю 🙂

        • “каталог услуг не является неотемлемым понятием SLM, как минимум с той поры, как в ITILv3 был включен процесс управления каталогом услуг”

          ОК, соответственно, если продолжать мысль топика на эту тему, выделение SCM как отдельного процесса также актуально только в случаях массового обслуживания, когда у одной услуги может быть много (несколько?) различных заказчиков. Ведь по сути отделение каталога услуг, как объекта управления, от SLA, это отделение маркетинга от продаж.
          Для внутренних ИТ-подразделений такая ситуация, хоть и возможна, представляется относительно редкой. Она будет чаще встречаться в крупных холдинговых структурах (о чём ниже пишет Станислав). Но в монолитных компаниях, даже большого размера, такое деление может быть излишним усложнением, не приносящим никакой ценности.
          Вместе с тем набор “2 каталога + SLA + OLA” является весьма распространённым представлением о результатах (deliverables) _типичного_ проекта по организации управления уровнем услуг. Об этом несоответствии я и писал.
          P.S. Также распространено мнение, что выделение двух “слоёв” услуг – “бизнесовых” и технических – полезно для расчёта стоимости услуг. На мой взгляд, это также неверно. То есть это помогает посчитать стоимость услуг только в тех случаях, когда такое деление оправданно с точки зрения общего управления услугами (например, это соответствует структуре распределения ответственности за предоставление услуг). Вводить же такое деление специально для обеспечения расчёта стоимости услуг – бессмысленно. Но это, видимо, тема для отдельного топика.

          • Георгий

            Расчет стоимости сервиса – тема даже не для топика, а для серии топиков

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

            По поводу того, в каких структурах актуален SLM и SCM – да, не во всех. Да ты совершенно прав, что сам по себе сервисный подход в моем понимании необходим очень ограниченному кругу компаний. Однако это не обозначает, что вне этого круга компаний нет таких, которые получат пользу от каталога услуг, от процесса SLM (как ни кощунственно прозвучит, но в практике были случаи, когда сама деятельность по описанию услуг, по выявлению текущих и желаемых метрик услуг приносила существенную пользу организации, тк помогала более трезво взглянуть на окружающий мир, при этом итогом деятельности не становились SLA в привычном нам понимании, скорее некие понятийные документы, но этого было достаточно)

            • “как ни кощунственно прозвучит, но в практике были случаи, когда сама деятельность по описанию услуг, по выявлению текущих и желаемых метрик услуг приносила существенную пользу организации”

              Так и я про то. Для меня это кощунственно не звучит: есть заказчик, есть задача, есть решение. Кощунственно когда независимо от задачи (и даже при её отсутствии) требуется “каталог + SLA + OLA, со всеми!”, потому что “это и есть SLM”.

              • Георгий

                мда 🙂 что ни разговор, все равно оказывается мысли схожие

  • Просто эту тему нужно обыгрывать через наличие в Холдинге “Службы заказчика” – владельца каталога Бизнес-услуг и “Сервисной ИТ-компании” – владельца каталога Технических ИТ-услуг.

    Ежели в этот котел добавить дивное понятие “Управление сервисными цепочками” – то все станет вообще на свои места, но при этом, стане до удивления неординарным.

  • “О том, что с этим [OLA] надо быть осторожнее, как-то давно (2006?) писал Pink elephant…”

    Материал Pink’ов я отыскать так и не смог (хотел привести ссылку). Однако нашёл ещё один материал, в котором я об этом читал: G00163050 “Effective IT Organizational Design” (Гартнер, 2008 год).


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM