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

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

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

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

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

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

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

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

Изменение системы поощрений с фокуса на выходах на фокус на результатах кардинально влияет на поведение команд. Например, вместо премирования за 99,9% uptime сервера (выход), который может не учитывать реальный пользовательский опыт, поощрения привязываются к результату: «95% пользователей не сталкиваются с задержками > 2 сек». В компании Ford замена KPI «количество строк кода» на «снижение времени сборки авто» повысила эффективность ИТ на 200%. Такие изменения стимулируют команды думать о конечной ценности своей работы, а не просто о количестве выполненных задач или технических показателях.

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