Важно учитывать как warranty, так и utility при оценке качества ИТ-услуг, потому что они охватывают разные, но взаимодополняющие аспекты восприятия качества. Utility отвечает за соответствие услуги бизнес-потребностям и функциональным требованиям заказчика, а warranty гарантирует стабильность, доступность и безопасность предоставления услуги. Наличие только одного аспекта недостаточно: даже самая функциональная услуга (высокая utility) будет непригодна, если она ненадежна (низкая warranty), и наоборот – надежная, но ненужная услуга (высокая warranty, низкая utility) не будет удовлетворять потребности заказчика.

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

Процесс Управления инцидентами обеспечивает прозрачность в работе за счёт своевременной и эффективной передачи информации об инцидентах и их статусах. Для этого процесс должен быть построен так, чтобы пользователь получал нужную информацию в согласованные с заказчиком моменты времени и в согласованном формате через согласованные каналы. Это могут быть электронные письма, SMS, информация на портале самообслуживания (в личном кабинете), телефонные звонки или даже личные визиты в случае работы с VIP-пользователями. Процесс INC должен минимизировать количество повторных обращений пользователей по тем же инцидентам за счёт качественного информирования, что отражается в KPI: «Среднее число звонков на Service Desk и прочих контактов со стороны бизнес-пользователей по поводу уже зарегистрированных инцидентов».

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

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

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

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

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

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

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