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

В некоторых моделях, например в IBM Tivoli Unified Process, роль координатора изменений называется 'Владелец изменений'. Это создает терминологическую путаницу из-за многозначного использования слова 'Owner' в ИТ-управлении. Слово 'Owner' уже используется в других контекстах, например, в управлении конфигурацией или в бизнес-аналитике, что может привести к недопониманию при коммуникации между различными подразделениями или при использовании разных методологий. Хотя эта неоднозначность не влияет напрямую на функциональные обязанности, она может создавать сложности в обучении персонала и при переходе между различными процессными моделями

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

Полных аналогов самоорганизующихся структур в реальном бизнесе пока немного, и они часто остаются предметом теоретических обсуждений. Некоторые компании, такие как Valve и GitHub, известны своими попытками внедрить более гибкие структуры, но даже в этих случаях полностью отсутствующая иерархия встречается редко. Чаще всего такие модели применяются в сочетании с традиционными элементами управления. Описания успешных внедрений новых структур часто не подкреплены долгосрочными результатами, что затрудняет оценку их реальной эффективности. Большинство примеров остаются в рамках гипотез и обсуждений, не имея под собой устойчивой практической базы.

Основные недостатки MAC-модели: 1) Низкая гибкость — все ресурсы одного уровня допуска (например, 'секретно') доступны всем, у кого есть мандат на этот уровень, что не учитывает индивидуальные обязанности пользователей. 2) Сложность управления при увеличении количества классов секретности: если добавить новый гриф (например, 'для внутреннего пользования'), система становится громоздкой и менее наглядной. 3) Необходимость жёсткой классификации всех данных, что требует постоянного мониторинга и обновления грифов при изменении важности информации. 4) Несоответствие бизнес-логике — модель подходит для военных и государственных структур, но слабо применима в коммерческих организациях, где доступ должен учитывать функции сотрудников, а не статус секретности.

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

Для агрегации различных показателей доступности (суммарное время простоев, максимальный разовый простой, количество нарушений) в единую метрику можно применить следующий подход: 1) Нормировать каждый показатель относительно целевого значения или максимально допустимого уровня. 2) Назначить веса каждому показателю в соответствии с их значимостью для конкретного бизнес-процесса. 3) Выполнить взвешенное суммирование нормированных показателей. 4) Преобразовать результат в процентную шкалу или иную удобную для восприятия форму. Например, можно определить, что для данного бизнес-процесса максимальный разовый простой имеет вес 50%, суммарное время простоя - 30%, а количество нарушений - 20%, и рассчитать итоговую метрику на основе этих весов и отклонений от целевых значений.

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

В рекомендациях ITIL 4 к применению принципа "Отталкивайтесь от текущей ситуации" (Start where you are) указано, что при оценке текущей ситуации следует использовать непосредственные наблюдения, и этим наблюдениям следует отдавать предпочтение перед другими методами сбора информации. В частности, в разделе 4.3.2.2 ITIL 4 прямо указано, что "прямое наблюдение всегда должно быть предпочтительным вариантом" ("direct observation should always be the preferred option"). Это подтверждает важность элемента, который ранее был выделен как отдельный принцип "Приоритет прямого наблюдения" (Observe directly) в ITIL Practitioner Guidance 2016 года, но в ITIL 4 интегрирован в рекомендации по применению другого принципа.

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