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

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

В ITIL рекомендуется использовать «marketing mindset» (маркетинговый способ мышления) при сборе и обработке требований заказчика. Сервис-провайдеру нужно отвечать не на вопрос «Что мы должны предоставить?», а на три ключевых вопроса: какие задачи выполняет заказчик и как ИТ может им в этом помочь; каких результатов хочет достичь заказчик; какие ограничения могут помешать заказчику достичь желаемого и как сервис-провайдер может снять эти ограничения. ITIL отмечает, что у сервис-провайдера часто нет руководств по сбору и обработке требований, что приводит к ситуации, когда заказчики предоставляют требования в произвольной форме без учета процессов. BRM играет ключевую роль в правильной интерпретации требований и обеспечении обратной связи между заказчиком и ИТ-специалистами.

Помимо традиционных показателей, связанных со временем решения инцидентов (например, MTTR — Mean Time To Resolution), для оценки эффективности управления инцидентами используются такие показатели, как FCR (First Contact Resolution) — доля инцидентов, решённых с первого обращения, что отражает эффективность коммуникации и полноту предоставления информации; доля инцидентов, возвращённых на доработку, которая показывает качество и окончательность решения; уровень проактивности оповещений и своевременности информирования пользователей; оценка удовлетворённости пользователей после закрытия инцидента. Эти показатели позволяют получить более полное представление об эффективности практики управления инцидентами, учитывая не только оперативность, но и качество обслуживания и коммуникации.

Публичные почтовые сервисы, такие как Gmail или Яндекс.Почта, как правило, не включают в свои соглашения об уровне обслуживания (SLA) штрафные санкции или даже четкие измерения и оценки уровня предоставления услуги. В таких сервисах пользователи часто сталкиваются с формулировками, что услуги предоставляются «как есть», без гарантий соответствия требованиям пользователей или обеспечения непрерывной, надежной работы. Это означает, что ответственность за предоставление услуг ложится в основном на пользователя, а поставщик не несет обязательств по компенсации за возможные перебои или недостатки.

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

Общее время вывода идеи на рынок (time-to-market) начинается с момента возникновения идеи (желтый флажок) - когда у бизнеса появляется видение проблемы, решив которую можно получить преимущества или снизить риски. Это время включает период, пока идея проходит эволюционный отбор и превращается в задачу для разработки (зеленый флажок), период ожидания выполнения задачи (Customer Lead Time) и непосредственно время производства - от точки принятия обязательств (красный флажок) до момента поставки результата.

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

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

Стандарт ISO/IEC 20000:2011, раздел 8.1, предъявляет следующие требования к управлению значительными инцидентами: поставщик услуг должен документировать и согласовать с заказчиком определение значительного инцидента; значительные инциденты должны классифицироваться и обрабатываться в соответствии с документированной процедурой; информация о значительных инцидентах должна доводиться до топ-менеджмента; топ-менеджмент должен назначить ответственного за управление каждым значительным инцидентом; после восстановления согласованного уровня услуг должен быть проведен анализ инцидента с целью определения возможностей по улучшению. Эти требования направлены на обеспечение четкого и эффективного управления кризисными ситуациями, которые существенно влияют на бизнес-процессы заказчика.