Вывод о целесообразности внедрения управления уровнями ИТ-услуг зависит от стадии зрелости организации и её стратегических целей. Если компания не планирует расширять сервисный подход на разработку и останется на разделении ALM и ITSM как постоянном решении, то управление уровнями услуг может принести меньше пользы, чем ожидается. В этом случае организация может ограничиться реализацией операционных процессов управления на уровне зрелости «Controlled», что будет более адекватным решением. Однако для компаний, где зависимость от ИТ высока и требуется постоянное развитие систем, необходим переход к интегрированному подходу с полной сквозной ответственностью за услуги.

Существующие бизнес-приложения обычно не полностью отвечают потребностям в расчете ИТ-бюджетов. Хотя отдельные решения могут хорошо справляться со своими узкими функциями (например, учет затрат в ERP-системах), они часто не предоставляют комплексного подхода, необходимого для полного цикла ИТ-бюджетирования по ITIL. Особенно слабо обеспечены этапы формирования альтернативных бюджетных сценариев и сквозная интеграция данных от бизнес-планов до окончательного расчета стоимости услуг.

Смена состава команды в условиях отсутствия явного лидерства не обязательно ухудшает работу команды, а в некоторых случаях даже усиливает её эффективность. В описанной игре произошла полная смена состава исполнителей посередине игры (когда прошло 12 из 24 игровых лет): те, кто строил пирамиды, стали контролировать качество, а архитекторы стали строителями. Эта перемешка ролей не только не снизила качество работы, но в одной из двух команд значительно улучшила её, без традиционного провисания качества, которое обычно наблюдается в подобных ситуациях. Это демонстрирует, что при прочих равных условиях (хорошая коммуникация, взаимопонимание, отсутствие конфликтов) команда может сохранять и даже повышать свой уровень эффективности при смене ролей участников, не имея явного лидера.

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

Принцип "Сотрудничайте" (Collaborate), который существовал в ITIL Practitioner Guidance 2016 года, был объединен с принципом "Будьте прозрачны" (Be transparent) в один принцип в ITIL 4 2019 года под названием "Сотрудничайте и поощряйте прозрачность" (Collaborate and promote visibility). Это объединение отражает важность не только сотрудничества между различными участниками процессов, но и открытости информации как неотъемлемой части эффективного взаимодействия. Авторы ITIL 4 видят эти два аспекта взаимосвязанными и считают, что прозрачность способствует более продуктивному сотрудничеству.

Принцип "Упрощайте" (Keep it simple), описанный в ITIL Practitioner Guidance 2016 года, был расширен в ITIL 4 до формулировки "Простота и практичность" (Keep it simple and practical). Это изменение отражает важность не только простоты решения, но и его практической применимости. В ITIL 4 подчеркивается, что слишком сложные решения затрудняют внедрение и эксплуатацию, однако простота ради простоты тоже не имеет смысла, если решение не решает поставленные задачи. Таким образом, акцент смещен с простого упрощения на поиск оптимального баланса между простотой и практической пользой.

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

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

При правильно организованном процессе учета времени на саму процедуру учета тратится значительно меньше времени, чем многие предполагают. По приведенным данным, за весь 2014 год на учет времени ушло 6 часов 4 минуты, что составляет 0,32% всего рабочего времени за год. Это означает, что даже при тщательном учете по множеству категорий временные затраты на ведение учета минимальны и составляют доли процента.

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