Группа процессов представляет собой следующий уровень декомпозиции после категории процессов в структуре PCF. Группы обозначаются двумя цифрами, разделенными точкой (5.2, 8.3, 11.2). Примеры групп процессов, указанные в тексте: Планирование и управление обслуживанием клиентов (в рамках категории Управление обслуживанием клиентов), Ведение общего бухгалтерского учета и отчетности (в рамках категории Управление финансовыми ресурсами), Управление государственными и отраслевыми отношениями (в рамках категории Управление внешними связями). Этот уровень предоставляет более детализированный взгляд на основные категории процессов.

В PCF уровень, соответствующий непосредственно исполняемым процессам, обозначается как "процесс". Этот уровень находится третьим в иерархии и обозначается тремя цифрами, разделенными точками (5.2.3, 8.3.4, 11.2.1). Примеры процессов, приведенные в тексте: Управление жалобами клиентов (в рамках группы Планирование и управление обслуживанием клиентов), Ведение финансовой отчетности (в рамках группы Ведение общего бухгалтерского учета и отчетности), Управление связями с правительством (в рамках группы Управление государственными и отраслевыми отношениями). Этот уровень представляет собой конкретные исполнимые процессы предприятия.

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

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

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

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

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

Руководителю, отвечающему за развитие, сложнее использовать отговорку «Я бы рад, да ресурсов нет», потому что именно он сам распределяет ресурсы в организации. Если руководитель не может выделить ресурсы на развитие, это ставит под сомнение его способность эффективно управлять компанией и расставлять приоритеты.

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

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