Основные недостатки 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. Такой подход может быть более сложным в реализации, если связи между инцидентами используются также для других целей.

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

Практика ведения каталога технических услуг и OLA не применима ко всем компаниям, потому что сервисный подход вообще реализован лишь в небольшом количестве организаций, и только к очень небольшой доле этих организаций применима именно практика ведения каталога технических услуг и OLA. Это связано с тем, что такие документы и практики значительно влияют на другие процессы, отношения между подразделениями и оргструктуру, и их введение может быть избыточным или неоправданным в компаниях с простой структурой или без четкого сервисного подхода. О необходимости быть осторожнее с внедрением таких практик уже писали Pink Elephant (около 2006 года) и IT Skeptic (около 2011 года).

Для успешной реализации ITSM проекта необходимы три основных типа ресурсов: временные, человеческие и финансовые. Временные ресурсы требуются для правильного планирования сроков и этапов проекта. Человеческие ресурсы включают в себя как специалистов проектной команды, так и всех задействованных в изменении процессов сотрудников. Финансовые ресурсы нужны для оплаты труда, обучения, возможных инструментов автоматизации и других расходов. Важно учитывать, что все эти ресурсы понадобятся задолго до фактического запуска процессов - на этапах анализа, проектирования, обучения и подготовки. Недостаток ресурсов на этих ранних этапах может привести к поверхностному проектированию, недостаточному обучению персонала и, как следствие, к провалу внедрения процессов.

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