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

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

Согласно ISM Method, Quality Management включает в себя управление доступностью как часть своих задач. Quality Management отвечает за сдерживание рисков, которые угрожают предоставлению ИТ-услуг, и обеспечение совершенствования предоставления ИТ-услуг. В контексте управления доступностью это означает разработку и внедрение контрмер для минимизации рисков недоступности, а также анализ отклонений и разработку улучшений. Quality Management объединяет управление доступностью с другими процессами, такими как управление безопасностью, мощностями и непрерывностью.

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

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

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

Из позиции технической поддержки в игре Grab@Pizza можно извлечь важный урок о том, что она не должна пассивно ожидать информации о предстоящих изменениях от бизнеса, а должна активно участвовать в процессе коммуникации. Техническая поддержка должна сама инициировать диалог с бизнесом для получения информации о грядущих изменениях и своевременно готовиться к возможным последствиям. Это помогает предотвратить всплеск инцидентов после внедрения изменений и обеспечивает стабильность работы системы в долгосрочной перспективе.

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

Классический подход предполагает полное согласование SLA со всеми бизнес-заказчиками до его введения в действие, что часто приводит к задержкам и сложностям с получением согласий. Альтернативный метод 'AS IS' заключается во введении базового SLA, отражающего текущее положение дел, без предварительного согласования со всеми сторонами. Такой подход позволяет быстрее запустить процесс управления сервисами, а бизнесу предоставляет возможность вносить изменения в соглашение по мере необходимости через механизм дополнительных соглашений.

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