В ITIL роль менеджера услуги определяется нечетко и часто представляет собой общий термин для обозначения любого руководителя в организации поставщика услуг. В отличие от четкого описания менеджера процесса, в управлении услугами такой конкретики нет, что приводит к неоднозначности в интерпретации этой роли в реальной практике.

Относительные приоритеты бизнеса учитываются при расчете общего показателя качества через использование весовых коэффициентов. Например, при объединении показателей из различных групп услуг (mission-critical, business-critical и обычные) каждой группе присваивается вес, отражающий ее степень важности для бизнеса. При расчете общего интегрального показателя эти веса учитываются в формуле, например, при вычислении взвешенного среднего арифметического. Если mission-critical услуги имеют вес 0.5, business-critical — 0.3, а обычные — 0.2, то их показатели будут пропорционально учитываться в общем результате. Это позволяет управлять акцентами в оценке и более точно отражать стратегические приоритеты бизнеса.

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

Совместимость и правильную компоновку компонентов RBAC регулирует стандарт INCITS 459-2011 «Information Technology - Requirements for the Implementation and Interoperability of Role Based Access Control». Этот стандарт описывает допустимые сочетания компонентов (функциональных наборов) и интерфейсы, что обеспечивает правильную интеграцию различных элементов системы RBAC. В то время как INCITS 359-2012 определяет референтную модель и INCITS 494-2012 расширяет её возможностями по обработке динамических ограничений, INCITS 459-2011 отвечает за то, чтобы все эти компоненты могли работать вместе корректно и обеспечивать совместимость между различными реализациями систем управления доступом на базе RBAC.

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

Ускорение поставки возможно без увеличения числа разработчиков или рабочего времени благодаря тому, что в производственной системе много задач создают простои и замедляют общий процесс. Для отдельной задачи из всего времени, которое она находится в системе, в среднем 90% составляет время ожидания (для многих команд эта цифра достигает 95-97%). Сокращая количество работы в системе и фокусируясь на завершении текущих задач вместо начала новых, можно снизить время ожидания для отдельной задачи (например, с 95% до 70%), что приведет к повышению эффективности потока с типичных 3-10% до нормальных для гибких команд 30%. Это позволяет достичь кратного ускорения без увеличения ресурсов.

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

Проектирование ролей в RBAC является критически важной задачей, потому что от качества этой работы напрямую зависит эффективность всей системы управления доступом. Неправильно спроектированные роли могут привести к нарушению политик информационной безопасности, например, к возможности совмещения несовместимых полномочий одним пользователем. Это может создать риски для безопасности данных и нарушить принцип разделения обязанностей. Кроме того, неоптимальные роли могут усложнить администрирование системы, увеличить количество ошибок при назначении доступа и снизить эффективность бизнес-процессов. Хорошо спроектированные роли, напротив, обеспечивают баланс между безопасностью, удобством использования и эффективностью системы.

При выборе между переносом данных в CMDB и доступом к внешним источникам следует учитывать следующие факторы: необходимость выполнения операций поиска и фильтрации данных внутри CMDB; требования к построению отчетов; удобство использования для конечных пользователей; объем данных, необходимых для процесса управления конфигурациями; возможность потери контроля за историей изменений при автоматическом сборе данных; соответствие глубины и охвата данных требованиям бизнес-процессов.

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