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

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

В интернете часто встречаются цифры, которые утверждают, что внедрение ITSM-программ (независимо от конкретного названия) повышает эффективность персонала более чем на 80%. Также упоминается, что внедрение процесса управления инцидентами якобы сокращает количество инцидентов на 40%, несмотря на то, что основная цель этого процесса — не предотвращение инцидентов, а оперативное реагирование и минимизация их влияния.

Прозрачность результатов работы команды важна потому, что это помогает всем участникам процесса совместно и согласованно понимать, какую ценность они создают. Когда разработчики видят реальные реакции пользователей на их работу (негативные отзывы, запросы на новые возможности, положительный отклик на митапах), это значительно повышает их вовлеченность, по сравнению с абстрактными показателями типа "увеличение конверсии на 0,07%". Это позволяет команде осознанно определять приоритеты, оценивать результаты своих решений, понимать, почему одни задачи более важны, чем другие. Прозрачность предотвращает ситуацию, когда разработчик просто разрабатывает фичи по очереди и забывает о них, не видя их реального эффекта.

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

Роль владельца услуги в ITIL аналогична роли владельца процесса: он занимается целеполаганием и определяет, что нужно достичь через предоставление услуги. Владелец заинтересован в результатах услуги, отвечает за стратегические аспекты и инвестиции, задает цели и ожидания от услуги для бизнеса.

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

Снижение количества инцидентов через управление проблемами часто более эффективно, чем повышение производительности персонала, из-за нелинейности зависимости между количеством инцидентов и средним временем их решения. Например, при 24 инцидентах в день со средней производительностью 20 минут на инцидент среднее время решения может составить 4 часа 10 минут из-за эффекта очереди при неравномерном поступлении. Если уменьшить количество инцидентов вдвое (до 12), среднее время решения сократится до 2 часов 10 минут - в два раза, хотя производительность персонала останется неизменной. Это происходит потому, что меньшее количество инцидентов уменьшает перегрузки и накопление очереди в пиковые часы. Таким образом, даже небольшое снижение количества инцидентов дает значительный эффект для сокращения среднего времени их решения.

Важно получать обратную связь от пользователей с умеренной удовлетворенностью, так как именно они составляют большую часть аудитории и их опыт наиболее близок к среднему уровню качества обслуживания. Если система обратной связи настроена так, что собирает только крайние оценки (очень довольные или очень недовольные), организация не сможет понять, насколько ее услуги удовлетворяют основную массу клиентов. Это приведет к искаженной картине и неправильным решениям при улучшении услуг. Баланс всех типов отзывов дает более полное представление о реальном состоянии дел.

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