Процессный и сервисный подходы в ИТ-управлении могут быть разделены друг от друга. Сервисный подход связан с управлением качеством услуг (SLM), тогда как процессный подход касается методологий выполнения конкретных задач (ITIL, ALM, RUP). Сервисные аспекты являются частью управленческих процессов, которые имеют общий характер для разных типов услуг, тогда как процессные аспекты относятся к производственным операциям, которые могут значительно отличаться в зависимости от типа предоставляемых услуг.

Менеджеру процесса управления релизами в ITIL V3 вменяются следующие обязанности: координация ресурсов, необходимых для построения, тестирования и развёртывания каждого релиза; контроль получения необходимой авторизации на выполнение действий; координация взаимодействия с другими процессами управления службами; обеспечение эффективного планирования релизов и управления их жизненным циклом от этапа подготовки до закрытия. Эта роль выступает центральной в обеспечении сквозной ответственности за весь процесс релиза, что особенно важно при взаимодействии с другими процессами, такими как управление изменениями.

В гибком управлении ИТ-разработкой сложно предсказывать сроки без дорожной карты потому что при попытке натянуть даты начала и завершения работ на бэклог приходится выстраивать сложные логические схемы взаимосвязей между задачами, что ограничивает планирование парой недель вперед, так как точность прогноза быстро теряется. Бэклог, будучи инструментом краткосрочного планирования, не дает достаточной визуализации для прогнозирования более длительных периодов. Дорожная карта решает эту проблему, так как фокусируется на целевых состояниях и сроках их достижения, а не на детализированных задачах. Она включает в себя все необходимые действия и согласования, связанные с достижением определенного состояния продукта, что позволяет более реалистично оценить временные рамки. Благодаря такому подходу можно учитывать не только сложность задач, но и дополнительные факторы, такие как время на согласования, синхронизацию со смежными командами и резервирование ресурсов, что приводит к более точным срокам реализации требований.

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

Обеспечение учета затрат и доходов включает определение и контроль соблюдения правил учета затрат и доходов. Фактическая регистрация осуществляется в операционных процессах: управление конфигурациями, управление проектами, планирование и выполнение продаж, ведение договоров.

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

Путаница с ролями, начинающимися со слова 'service', возникает из-за обилия вариаций названий и исторических изменений в ITIL. В частности, в некоторых компаниях до сих пор используется термин 'Service Manager', который в ITIL уже давно не применяется. Дополнительную сложность создает то, что ITIL4 Foundation не содержит детального описания ролей, участвующих в практиках, в отличие от ITIL V3. Эта путаница особенно заметна в контексте процесса управления уровнем услуг (Service Level Management), где требуется чёткое понимание обязанностей различных ролей, таких как Service level manager и Service owner.

Первым кандидатом на роль Service Owner в организации изначально является руководитель всей ИТ-организации, обычно это CIO (Chief Information Officer). Поскольку именно он несет окончательную ответственность за все ИТ-услуги в организации. Позже, когда масштаб организации растет, и объем управления становится слишком большим, CIO может делегировать эту ответственность конкретным управляющим услугами.

Регламентация ответственности за консистентность финансовой информации включает: определение конкретных ролей в процессе управления активами и конфигурациями, четкое описание обязанностей и зон ответственности каждой роли, включение в регламент процесса процедур проверки и сверки данных, установление периодичности проверок консистентности данных между системами, создание механизмов оповещения и устранения выявленных расхождений. Особенно важно, чтобы за поддержание актуальности и точности финансовой информации отвечали специалисты, имеющие доступ к первоисточникам данных и понимающие особенности учёта в каждой системе. Это позволит минимизировать ошибки и обеспечить надежную основу для финансовой модели услуг.

В ITIL Service Design примеры SLA и OLA очень похожи потому, что содержательно эти документы практически не отличаются. OLA формально описывает внутренние обязательства, которые поддерживают выполнение SLA, но структура и содержание этих документов таковы, что их можно заменить друг на друга без потери смысла. Это свидетельствует о том, что нет принципиальной разницы между SLA и OLA, а различие заключается лишь в том, с чьей точки зрения рассматривается документ. Отсюда следует, что термин OLA не добавляет существенной ценности и может быть избыточным.