В последние годы я довольно много сталкиваюсь с практическими вопросами организации 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 означает, что Вы «включаете» сервисные отношения внутри ИТ-подразделения. Это имеет довольно серьёзные последствия:
- создаётся риск излишней автономности внутренних подразделений, ведь отношения с ними будут строиться почти как с внешними поставщиками услуг, и при этом не будут подкреплены аналогичными средствами влияния (конкуренцией, денежными расчётами или административным влиянием);
- потребуется серьёзно пересматривать все процессы, в которые вовлечено новое внутреннее сервисное подразделение (фактически оно вообще может исключаться из единых процессов управления, требовать изменения порядка функциональной эскалации и так далее);
- возникнет отдельная (часто игнорируемая на практике) задача контроля исполнения внутренними сервисными подразделениями своих обязательств. Задача осложняется тем, что у одного внутреннего потребителя будет несколько внутренних поставщиков и наоборот;
- вероятно, понадобятся изменения в организационной структуре, поскольку решение задач 2 и 3 потребует арбитра – третьей стороны, обладающей и функцией контроля, и соответствующими полномочиями.
Принимать или не принимать эти последствия решать Вам (это отдельный вопрос в каждом конкретном случае, здесь не может быть универсальной рекомендации). Но осознавать их при принятии решения о применении каталога технических услуг и OLA крайне важно.
Практика
На практике есть компании, которые пытались делать OLA, но они не оправдали надежд. Есть компании, которые обожглись на применении OLA (то есть они не просто не помогли, а помешали). Наконец многие компании называют словом OLA внутренние регламенты взаимодействий, не связанных с сервисными отношениями. То есть, не будучи ясно определён и аргументированно обоснован в первоисточниках, термин OLA вызывает путаницу в реализации.
Лично мне термин OLA представляется просто лишним – SLA и UC абсолютно достаточно. Поэтому берём бритву Оккама и аккуратно отрезаем по шву.
“OLA является соглашением о предоставлении услуг” – спорно.
Не всегда, даже в глоссарии ITILv3 написано “ИЛИ услуг”.
Следовательно, не всегда заключение формальных ОПЕРАЦИОННЫХ соглашений является “включением” сервисных отношений.
Следовательно возможны OLA, которые будут схожи как с SLA, так и с регламентом внутреннего взаимодействия. В принципе называть операционные соглашения можно как угодно.
“OLA – это документ” – не обязательно. OLA соглашение на операционном уровне. Соглашение может быть оформлено, регламентом, договором… в устной форме если это зафиксировано в “специальной” системе (о ней вроде в книжке Service Strategy написано).
ИМХО Правила взаимодействия определять нужно всегда.
На практике вспоминается случай, когда OLA действительно “включил” сервисные отношения между ИТ и АХО. Польза от этого соглашения была очевидна. В том случае OLA по своей структуре действительно оказался похожим на UC, из которого убрали финансовую составляющую.