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

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

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

Внедрение проактивного управления проблемами может потребовать следующих организационных изменений: 1) Создание специализированных команд или выделение ответственных лиц за проактивную работу, которые будут фокусироваться на прогнозировании и предотвращении проблем, а не только на их устранении после возникновения. 2) Формирование кросс-функциональных рабочих групп, включающих специалистов из разных областей (инфраструктура, приложения, безопасность), для комплексного анализа потенциальных проблем. 3) Внедрение новых метрик и KPI, направленных на измерение эффективности проактивной работы, таких как количество предотвращенных инцидентов, снижение частоты повторяющихся инцидентов и т.д. 4) Изменение структуры отчетности и фокуса обсуждений на совещаниях - включение регулярного анализа трендов, потенциальных рисков и возможностей для улучшения. 5) Развитие компетенций сотрудников в области анализа данных, прогнозирования и управления рисками. 6) Интеграция проактивного управления проблемами с другими процессами, особенно с процессом управления изменениями и постоянным совершенствованием услуг. 7) Внедрение инструментов аналитики и мониторинга, способных выявлять аномалии и потенциальные проблемы до их превращения в инциденты. В крупных организациях может потребоваться создание выделенных структур, таких как отдел качества или управление методологии, которые будут координировать проактивную работу на уровне всей организации.

Специалисту для работы в соответствии с парадигмой ITSM необходимы как технические, так и мягкие навыки: знание стандартов и лучших практик ITSM (ITIL и других фреймворков), понимание бизнес-процессов компании, умение проектировать и оптимизировать процессы управления ИТ-услугами, навыки работы с системами управления сервисами (например, ServiceNow), коммуникативные навыки для взаимодействия с бизнесом и конечными пользователями, способность анализировать метрики и улучшать процессы, умение составлять и контролировать SLA-соглашения. Также важны аналитические способности для определения причин проблем и поиска оптимальных решений.

Пять основных областей применения руководителя проектов при переходе к гибким методам: 1) Управление работами команды - но эта роль обычно отводится владельцу продукта; 2) Построение работы команды - обычно осуществляется лидером команды или agile-коучем; 3) Управление проектом создания продукта - временная роль, необходимая только до создания MVP; 4) Управление результатами на более высоком уровне - в методологиях типа SAFe для этого разработаны другие механизмы; 5) Построение взаимодействия между старым и новым мирами - именно в этой области руководитель проектов может принести наибольшую ценность, обеспечивая координацию, синхронизацию, развитие и сопровождение процессов между традиционными и гибкими методологиями, особенно в бимодальных ИТ-средах.

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

Чтобы выявить и использовать стереотипы клиентов (Юг) для улучшения ИТ-услуг, следует: 1) Провести исследования и собрать информацию о существующих установках клиентов посредством опросов, интервью и анализа обратной связи. Например, для ИТ-поддержки стереотипом может быть мнение, что служба медленно реагирует на запросы. 2) Определить, какие из этих стереотипов негативны и влияют на восприятие услуги. 3) Разработать специальные мероприятия для разрушения негативных стереотипов: например, внедрить систему отслеживания времени ответа и гарантировать ответ в течение 15 минут. 4) Создать коммуникацию, демонстрирующую клиентам, что негативные стереотипы не соответствуют реальности вашей услуги. Например, сообщать клиентам при обращении в поддержку: "Спасибо за обращение, ваш запрос будет обработан в течение 15 минут". 5) Регулярно измерять, как изменяются восприятие и стереотипы после внедрения изменений. Это позволит целенаправленно улучшать восприятие вашей ИТ-услуги.

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

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