Ценность прямого измерения удовлетворенности заказчика услугами заключается в том, что оно дает оценку степени соответствия результатов деятельности поставщика услуг непосредственно из уст заказчика, обеспечивая более точную обратную связь. Подход позволяет учитывать как warranty (гарантийные показатели качества обслуживания), так и utility (полезность услуги), что не всегда отражается в традиционных количественных показателях SLA. Таким образом, поставщик услуг получает более полное представление о реальном восприятии качества его услуг.

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

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

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

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

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

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

Формулировки типа «внедрить процесс управления изменениями» не отражают реальную ценность проекта для бизнеса и могут привести к ситуации, когда проект «живет своей жизнью» без четкого измерения результатов. Такой подход не отвечает на вопросы: для чего нужен этот процесс, какие проблемы он решает, какую пользу приносит бизнесу. Постановка цели как «внедрить процесс» фокусируется на инструменте, а не на результате. Вместо этого стоит формулировать цели через конкретные результаты и их влияние на бизнес, например: «Снизить количество аварийных изменений на 30% за счет внедрения структурированного процесса управления изменениями» или «Сократить время на утверждение изменений на 25%».

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

Необходимо: 1) Чётко разделять сценарии создания инцидентов (внешние сбои) и проблем (анализ корневых причин по группе инцидентов); 2) Внедрить отдельные этапы для проблем (диагностика, утверждение решения); 3) Обучить персонал специфике процессов; 4) Настроить ITSM-систему для поддержки уникальных атрибутов проблем (например, этапы обработки); 5) Ввести метрики, отличные от инцидент-менеджмента. Ключевой момент — не создавать запись о проблеме 'для галочки' после инцидента, а запускать полноценный анализ причин.