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

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

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

Для эффективного управления проблемами необходимо: 1) Четко отличать проблемы от инцидентов и не смешивать эти понятия; 2) Сформулировать бизнес-ценность управления проблемами и оценить негативное влияние от инцидентов; 3) Сфокусироваться на проактивной деятельности, а не только на реактивной; 4) Обеспечить доступ сервисных команд к базе известных ошибок (KEDB); 5) Регулярно измерять эффективность работы в управлении проблемами; 6) Инвестировать в устойчивость систем и обучение персонала; 7) Постоянно анализировать эффективность обходных решений и оценивать целесообразность применения постоянных решений.

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

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

Это разделение необходимо для правильного распределения ответственности и уровня контроля: Change proposal фокусируется на стратегических, масштабных изменениях с бизнес-ориентированным обоснованием, тогда как RFC решает оперативные технические задачи. Такой подход обеспечивает четкое разделение между уровнем стратегического планирования и оперативной реализацией, предотвращает ошибки из-за недостаточного обоснования крупных изменений.

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

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

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