Баланс между высоким уровнем контроля изменений (Change Control Level) и необходимостью ускорения процессов достигается через оптимизацию размера и частоты релизов. Высокий Change Control Level обычно приводит к увеличению времени обработки изменений (Process Time), поскольку требует тщательного планирования, оценки и тестирования. Однако, переход к частым малым релизам (высокий Release rate и низкий Release size) позволяет поддерживать высокий уровень контроля без значительного увеличения рисков и времени вывода решений. Частые малые внедрения уменьшают сложность каждого отдельного изменения, что делает процесс контроля более эффективным. Также повышение Change capability за счет накопленного опыта и автоматизации стандартных процессов (Standardization/automation) позволяет поддерживать высокий Change Control Level при снижении Process Time. В итоге, вместо жесткого выбора между контролем и скоростью, организация может достичь состояния, где высокий уровень контроля сочетается с высокой скоростью внедрения благодаря оптимизации процессов и непрерывному обучению.

Игра Grab@Pizza демонстрирует, что успешность бизнеса напрямую зависит от эффективной работы связки Business-SLM-Change. Участники учатся понимать, как изменения в системе управления уровнями сервиса (SLM) влияют на бизнес-процессы и как правильно организовать коммуникацию между бизнесом и ИТ для своевременного внедрения необходимых изменений. В ходе игры становится очевидно, что пренебрежение этими аспектами может привести к увеличению числа инцидентов, снижению качества услуг и негативно сказаться на общих бизнес-результатах.

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

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

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

Сервисный подход гораздо шире, чем SLM (Service Level Management). SLM представляет собой контрольный механизм, который системно обеспечивает оценку качества услуг путем сравнения достижений с взятыми обязательствами. Однако для создания измеримых обязательств необходимо сначала сформулировать работу в терминах ценности для заказчика и научиться измерять эту ценность. Обе задачи являются сложными для большинства компаний и требуют времени для реализации.

Incident Rate позволяет прогнозировать объем обращений пользователей в ИТ-службу, используя текущее количество пользователей системы. Умножив ожидаемое число пользователей на средний показатель Incident Rate (например, 0.8–1.2), можно рассчитать примерное количество инцидентов за месяц и спланировать необходимые ресурсы, такие как количество сотрудников в службе поддержки или объём автоматизации процессов управления инцидентами.

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

В ITIL 4 приоритизация не выделена как отдельный шаг в процессе обработки и решения инцидента, потому что она рассматривается как сквозной процесс управления, который может проводиться многократно в течение всего жизненного цикла инцидента. В отличие от ITIL v3, где приоритизация следовала сразу после классификации, в ITIL 4 она представлена как фактор успеха практики управления инцидентами, который необходим для выполнения основной цели — минимизации негативного влияния инцидентов. Приоритизация может происходить на разных этапах, когда возникает необходимость пересмотра порядка работы с инцидентами из-за появления новых инцидентов или изменения условий.

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