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

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

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

Гибридные модели управления, сочетающие элементы проектного и гибкого подходов, создают несколько существенных рисков. Основной риск заключается в том, что частичная трансформация процессов ведет к снижению пользы от перехода к гибкому управлению. Разработчики могут ускорить внутренние процессы, но на этапе внедрения возникают задержки из-за сохранения проектных элементов вроде релизных циклов и длительного приёмочного тестирования. Это приводит к потере преимуществ гибкого управления — кратного ускорения Time-to-Market. Другой риск — отсутствие совместной ответственности за конечный результат, когда каждая сторона перекладывает ответственность за задержки на другую. Также гибридные модели затрудняют точное прогнозирование сроков реализации требований, так как невозможно определить пропускную способность потока из-за разрывов в процессе.

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

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

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

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

Управление проблемами включает следующие ключевые процессы: проактивная идентификация проблемы — процесс выявления потенциальных ошибок в продуктах организации на основе источников, отличных от записей об инцидентах; реактивная идентификация проблемы — процесс использования информации о прошлых и текущих инцидентах для расследования их причин; контроль проблем — процесс, фокусирующийся на расследовании проблемы; контроль ошибок — процесс, направленный на мониторинг и контроль состояния известных ошибок (проблем, которые проанализированы, но не решены) и их решение. Эти процессы направлены на выявление и устранение коренных причин инцидентов.

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