Другие стандарты подходят к управлению доступностью иначе, чем ITIL. Например, ISO/IEC 20000 объединяет управление доступностью с управлением непрерывностью, COBIT5 и CMMI для сервисов связывают его с управлением мощностями, MOF включает его в функцию надежности вместе с управлением непрерывностью, мощностями и безопасностью. Авторы ISM Method относят управление доступностью к управлению качеством (Quality Management), наряду с другими аспектами, такими как безопасность и непрерывность. Это свидетельствует о том, что в других стандартах управление доступностью не выделено отдельно как самодостаточный процесс.

Значительная часть работ ИТ-команды не укладывается в конвейерный формат, так как они не имеют строго определенной последовательности операций. Например, RnD, диагностика проблем, рутинные работы по обслуживанию, формирование бэклога, управление активами. Некоторые задачи не имеют последовательности вовсе («взял-сделал»), другие требуют коллаборации с неизвестными заранее компетенциями. При этом лимиты работ и очереди теряют эффективность, так как разные задачи проходят через различные этапы обработки, а предсказуемость нагрузки снижается. Управление очередями становится затруднительным, так как для разных задач шаги и лимиты обработки различаются.

При переходе на продуктовый подход в организации появляются продуктовые роли: менеджеры, владельцы продуктов (product owners). Меняется структура отчётности и, возможно, подчинённости. Может быть проведена реорганизация структуры - например, создание продуктовых департаментов, где объединяются различные подразделения, работа которых ориентирована на конкретный продукт. В организации изменяется фокус управления: вместо оценки прибыльности отдельных проектов начинает учитываться жизненный цикл продукта и его общая прибыльность. Могут также появиться новые организационные механизмы, отвечающие за развитие продуктов.

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

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

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

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

В процессе непрерывного улучшения услуг (CSI - Continual Service Improvement) BRM играет важную инновационную роль. BRM определяет возможности по оптимизации ценности, которую сервис-провайдер несет заказчикам. BRM может выявлять возможности как в рамках текущей деятельности (благодаря постоянной осведомленности о задачах заказчика), так и в рамках периодических service reviews. BRM отвечает за документирование выявленных возможностей или потребностей и их передачу для дальнейшей проработки. BRM также отслеживает прогресс реализации улучшений и при необходимости выступает координатором деятельности, выполняемой в рамках других процессов, особенно в случаях риска потери фокуса на цели улучшения.

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

Мониторинг подвергается существенным изменениям при внедрении ITSM. Вместо традиционного наблюдения за компонентами инфраструктуры требуется измерение характеристик услуг и контроль сквозных (end-to-end) операций. Мониторинг фокусируется на том, как качество инфраструктуры влияет на конечные услуги, что необходимо для обеспечения заявленных уровней служб.