В книге ITIL Service Strategy отсутствуют детальные рекомендации по реализации моделей аллокации затрат, представленной менее чем на одной странице в разделе 4.3.5.6. Также структура процесса управления финансами (Accounting, Budgeting, Charging) больше отражает области ответственности, чем конкретные процедуры, что затрудняет практическую реализацию процесса.

Опыт потребителя можно оценить через три основные категории: поведение потребителя в рамках использования услуги (например, объем усилий, затрачиваемых на выполнение операции, количество ошибок, обращений за помощью, длительность пауз и количество незавершенных действий), его мнение (например, уровень удовлетворенности, CSAT, NPS через опросы) и его действия (например, прекращение сервисных отношений, изменение объема потребления или каналов взаимодействия). Такая многогранная оценка позволяет получить полную картину восприятия услуги.

Преимущества использования CMDB для расчёта стоимости услуг заключаются в том, что CMDB уже содержит информацию о влиянии одних элементов на другие, что по своей сути имеет экономический смысл. Например, если сервер использует систему хранения данных, это влияние можно интерпретировать как использование ресурсов, что позволяет корректно распределить стоимость между элементами. Также CMDB может учитывать виртуальные ресурсы, которые не фиксируются в традиционных финансовых системах, но важны для расчёта полной стоимости владения. Это обеспечивает более полное и точное представление о затратах на услуги ИТ.

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

После разрешения ситуации с кодом Sev-B результаты работы проверяются по всей иерархической цепочке: от непосредственного руководителя сотрудника до самого первого лица компании. Первое лицо лично принимает отчет и участвует в обсуждении проблемы, часто проявляя высокую эмоциональную вовлеченность. Результат может быть как положительным (проблема решена, никто не наказан), так и отрицательным — увольнение сотрудников не исключено, особенно если будут выявлены грубые нарушения или системные ошибки. Кроме того, могут быть внесены изменения в процессы компании, чтобы предотвратить повторение подобных ситуаций.

Практики управления рисками интегрируются в процесс управления проблемами, особенно в его проактивной составляющей, следующим образом: 1) Идентификация возможных событий - в процессе управления проблемами происходит выявление потенциальных проблем, которые могут привести к инцидентам. 2) Оценка вероятности и степени влияния - каждая выявленная проблема оценивается с точки зрения ее серьезности и вероятности возникновения, что позволяет приоритизировать проблемы. 3) Контроль реестра событий и актуальных оценок - ведется систематизированный реестр проблем с периодическим пересмотром их приоритетов и статусов. 4) Разработка и реализация мер по предотвращению рисков - для критически важных проблем разрабатываются проактивные меры по их устранению или минимизации влияния. Проактивная составляющая управления проблемами фактически представляет собой специфический вариант управления рисками, сфокусированный на технических и операционных рисках в сфере предоставления услуг. Эта интеграция позволяет не только реагировать на возникающие инциденты, но и предотвращать их возникновение.

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

Уровень System Capacity Management определяется как управление мощностью на уровне информационных систем. Этот подпроцесс используется, когда ИТ-услуга ассоциируется с обеспечением работоспособности конкретных систем. Он включает в себя определение требований к производительности, надежности и доступности систем, а также трансляцию этих требований в ресурсные ограничения. System Capacity Management необходим при предоставлении услуг, ориентированных на систему (например, SaaS), но не требуется, если услуга определена напрямую как предоставление ресурсов.

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

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