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

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

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

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

Для успешного внедрения анализа по модели Compass Model в организации необходимо предпринять следующие шаги: 1) Обучение персонала принципам модели и её применению в рамках customer journey. 2) Выбор ключевых услуг или процессов для первоначального анализа. 3) Сбор данных о клиентах через интервью, опросы, анализ существующей обратной связи. 4) Проведение анализа по четырём аспектам (Север, Запад, Юг, Восток) для каждой выбранной услуги. 5) Разработка рекомендаций по улучшению на основе выявленных аспектов. 6) Внедрение пилотных изменений и измерение их эффективности. 7) Интеграция Compass Model в регулярные процессы анализа и улучшения клиентского опыта. 8) Создание системы постоянного отслеживания изменений в потребностях, желаниях, стереотипах и эмоциях клиентов. Важно помнить, что практическое применение требует определенной тренировки, и первые анализы могут быть неточными, но с опытом качество анализа будет возрастать.

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

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

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

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

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