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

Как соотносятся роли Service Owner и Service Level Manager

Думаю, следует сразу уточнить, что рассматривать соотнесение ролей будем в контексте 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 в компании. А Владелец услуги отвечает за конкретные услуги, но не только за их уровень, а также несёт ряд обязанностей в контексте других процессов — таких, как управление изменениями, инцидентами, запросами и прочих. 

Коллеги, если нужны дополнительные пояснения — пишите, постараюсь ответить в комментариях.

ITIL 4 Foundation, MPT, DSV, DPI, CDS, HVIT, DITS
и другие интересные аббревиатуры от участников разработки

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

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • FinOps с помощью Governance-as-Code
      Масштабы и сложность решений, основанных на облачных технологиях, продолжают расти. Слишком часто это расширение также означает, что затраты продолжают выходить из-под контроля. В
    • Применима ли концепция «сдвиг влево» (shift left) для инженеров по надёжности систем (SRE)?
      Концепция «сдвига влево» помогает упростить некоторые аспекты разработки программного обеспечения. Но предназначена эта концепция не только для разработчиков. Она
    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT