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

OLA-la

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

В последние годы я довольно много сталкиваюсь с практическими вопросами организации SLM и построения каталога ИТ-услуг. Одним из актуальных вопросов в этой области является назначение и содержание такого документа как Operational Level Agreement (OLA).

Есть бородатый анекдот про хозяйку, которую соседка обвинила в том, что когда та брала у неё горшок, она вернула его треснувшим. Ответ был таков: «Во-первых, это неправда – я вернула его целым. Во-вторых, когда я брала горшок, он уже был треснувшим. И в-третьих, я вообще его не брала». Так вот, про OLA я могу сказать буквально следующее: во-первых, такого документа не существует, а во-вторых применение OLA на практике требует серьёзного анализа целесообразности.

Тезис первый: OLA не существует

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

Поэтому OLA как самостоятельный документ не существует – это то же SLA, только с точки зрения другого субъекта сервисных отношений. И наличие термина OLA в тех же книжках ITIL вызывает вопрос о целесообразности. Более того, если посмотреть на предлагаемые в книжке ITIL Service Design примеры SLA и OLA (приложение F), мы увидим, что они очень и очень похожи.

Тезис второй: применение OLA требует анализа целесообразности

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

Дело здесь в том, что OLA является соглашением о предоставлении услуг. То есть введение OLA означает, что Вы «включаете» сервисные отношения внутри ИТ-подразделения. Это имеет довольно серьёзные последствия:

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

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

Практика

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

Лично мне термин OLA представляется просто лишним – SLA и UC абсолютно достаточно. Поэтому берём бритву Оккама и аккуратно отрезаем по шву.

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

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

  • Vladimir Lyaleko

    “OLA является соглашением о предоставлении услуг” – спорно.
    Не всегда, даже в глоссарии ITILv3 написано “ИЛИ услуг”.

    Следовательно, не всегда заключение формальных ОПЕРАЦИОННЫХ соглашений является “включением” сервисных отношений.

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

    “OLA – это документ” – не обязательно. OLA соглашение на операционном уровне. Соглашение может быть оформлено, регламентом, договором… в устной форме если это зафиксировано в “специальной” системе (о ней вроде в книжке Service Strategy написано).

    ИМХО Правила взаимодействия определять нужно всегда.

    На практике вспоминается случай, когда OLA действительно “включил” сервисные отношения между ИТ и АХО. Польза от этого соглашения была очевидна. В том случае OLA по своей структуре действительно оказался похожим на UC, из которого убрали финансовую составляющую.

    • “Не всегда, даже в глоссарии ITILv3 написано «ИЛИ услуг».”
      Да, но “ИЛИ” используется по отношению к товарам, а не сквозным процессам.

      “Следовательно возможны OLA, которые будут схожи как с SLA, так и с регламентом внутреннего взаимодействия.”
      Тогда в первом случае этот документ будет называться SLA, а во втором – регламентом взаимодействия. OLA, как самостоятельная сущность, не появилась.

      “На практике вспоминается случай, когда OLA действительно «включил» сервисные отношения между ИТ и АХО”
      Конечно. Или с безопасниками. Но я специально указал уточнение в тексте поста: “Особенно если речь идёт об OLA в пределах ИТ-подразделения”.

    • Самое забавное, что если бы слово OLA (кстати дословно – соглашение о параметрах операций, а не услуг) означало регламент, поддерживающий предоставление бизнес-услуг, но не “включающий” внутренние сервисные отношения, оба приведённых мной тезиса про OLA решились бы сами собой:
      1. В таком виде OLA в триаде SLA-OLA-UC обладал бы самостоятельным смыслом. OLA бы не являлся взглядом на SLA “из другого окопа”.
      2. Замена внутренних сервисных соглашений на регламентацию операционного взаимодействия несла бы в себе существенно меньше организационных рисков.
      Любопытно, что англоязычная wikipedia трактует OLA именно так – регламентация взаимодействия внутренних групп, направленная на обеспечение SLA. Без всякого упоминания внутренних сервисных отношений.
      Но в ITIL OLA в основном упоминается именно в контексте внутренних (технических) услуг. Это говорит и текст, и разные картинки. Да и в ISO 20000 (включая вторую часть) OLA явно не упоминается, в отличие от SLA. За ненадобностью?

  • Андрей В.

    “…многие компании называют словом OLA внутренние регламенты взаимодействий, не связанных с сервисными отношениями.”

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

  • Pavel Solopov

    А что имеется в виду под сервисными отношениями в фразе: “Наконец многие компании называют словом OLA внутренние регламенты взаимодействий, не связанных с сервисными отношениями.”

    Если например будет некий документ между группой системных администраторов и группой бизнес-приложений, в котором будет сказано:
    Группа системных администраторов заменяет вышедший из строя сервер не более чем за 3 часа.
    Это связано с сервисными отношениями? Это является внутренним регламентом?

    • Юлия Солодяшкина

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

  • zevekar

    Спасибо за статью. Интересные мысли. Все комментарии и обсуждения ITIL рассматриваю исключительно как шаринг своего личного опыта – что очень всегда интересно и важно с практической точки зрения. ITIL и есть лишь набор лучших, с точки зрения бритишей, практик, не является стандартом как ISO20000, например. По OLA со своей стороны замечу, что он становится более актуальным в крупных корпорациях, где каждый отдел является отдельной организацией. По своему опыту, я обязательно имел OLA с подразделениями Office Management, Contract & Procurement, то есть тех, кто напрямую мог влиять на наши ИТ SLA, например, при переездах рабочих мест и офиса наши действия напрямую зависят от административных служб, которые перевозят барахло, включая ИТ составляющее, или Логистика, которая доставляет наше ИТ об-ие в/из различные далекие региональные сайты организации, которые имеют свои SLA и свои правила! И все это необходимо учитывать при формировании SLA/OLA.


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;