Думаю, следует сразу уточнить, что рассматривать соотнесение ролей будем в контексте ITIL V3. В ITIL4 Foundation детального описания ролей, участвующих в практиках, нет, так что ждём.
Мысль рассмотреть эти две роли, что называется, в связке, возникла не просто так. На неё навели вопросы слушателей курсов линейки ITIL Intermediate. Многих по-прежнему несколько сбивает с толку обилие вариаций названий ролей, начинающихся со слова “service”. А также до сих пор в некоторых компаниях циркулирует словосочетание “Service Manager”, которого в ITIL уже давно нет. Апофеоза эта путаница достигает в контексте процесса управления уровнем услуг (Service Level Management). Попробую структурировать информацию из первоисточника.
Итак, согласно ITIL V3 в процессе SLM участвуют следующие ключевые роли:
- Владелец процесса (Service level management process owner)
- Менеджер процесса (Service level management process manager)
- Владелец услуги (Service owner)
- Менеджер по взаимоотношениям с бизнесом (Business relationship manager)
BRM-а в рамках данной статьи рассматривать не будем, хотя роль, безусловно, крайне важная. Но у нас сейчас другая задача.
Владелец процесса, напомню, отвечает (accountable) за то, чтобы процесс соответствовал назначению (fit for purpose). Его обязанности охватывают постановку процесса, разработку политик и стандартов, обеспечение процесса ресурсами, определение целевых показателей для процесса (не для SLA), настройку качественного взаимодействия с процессом BRM, периодический аудит и совершенствование. То есть владелец “говорит, куда идём”, обеспечивает и контролирует.
Менеджер процесса (роль, которая может быть совмещена с Владельцем) обеспечивает операционное управление процессом. Сюда входит планирование (совместно с Владельцем) и координация всех активностей процесса в соответствии с политиками и регламентами, назначение исполнителей на роли, непосредственное управление этими исполнителями, мониторинг и отчётность по работе процесса, и, в том числе (внимание!), взаимодействие с Владельцами услуг (Service owners) и менеджерами других процессов (в первую очередь здесь речь о Service catalogue management, Service portfolio management, Business relationship management, Supplier management) с целью обеспечения качественного предоставления услуг (smooth running of services). Применительно к соглашениям об уровне услуг (SLA) обязанности Менеджера процесса следующие – он не только должен обеспечить их наличие, но непосредственно участвует в обсуждении и согласовании требований к уровню услуг с заказчиком и подготовке самих соглашений. У него есть ещё ряд интересных обязанностей, но мы в них сейчас погружаться не будем, а посмотрим на роль Владельца услуги.
Владелец услуги является единой точкой ответственности за конкретную услугу на протяжении всего её жизненного цикла, вне зависимости от географического расположения её компонентов и обслуживающего персонала. В его обязанности (responsibilities) входит контроль соответствия уровня предоставления и поддержки конкретной услуги согласованным параметрам трансляция требований бизнеса (полученных через BRM-а) в понятные ИТ-задачи, обеспечение прозрачных коммуникаций с заказчиком по запросами и инцидентам в контексте конкретной услуги, помощь процессу управления портфелем в разработке модели услуги, помощь при оценке влияния изменений на услугу, обеспечение актуальности сведений об услуге в каталоге услуг, представление услуги в рамках всей организации в принципе и на CAB-ах в частности, мониторинг и отчётность по услуге. В отношении SLA его обязанности обозначены следующим образом: участие в обсуждении SLA/OLA применительно к услуге к его зоне ответственности.
Итак, две роли, которые упомянуты в заголовке – Service level manager и Service owner, – тесно связаны между собой. Они должны плотно взаимодействовать. Но есть довольно чёткая граница в их зонах ответственности: Менеджер процесса SLM отвечает за процесс в целом, за наличие и выполнение всех SLA в компании. А Владелец услуги отвечает за конкретные услуги, но не только за их уровень, а также несёт ряд обязанностей в контексте других процессов – таких, как управление изменениями, инцидентами, запросами и прочих.
Коллеги, если нужны дополнительные пояснения – пишите, постараюсь ответить в комментариях.
