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

Связи между элементами CMDB должны содержать атрибуты и логику, которые позволяют переносить потребность в мощностях от ресурсов верхнего уровня к поддерживающим ресурсам. Например, если верхний уровень требует определённого объёма вычислительных мощностей или объёма хранимых данных, эта потребность должна быть корректно распределена между всеми связанными ресурсами. В обратном направлении, связи передают стоимость обеспечения каждой единицы мощности, что позволяет отслеживать экономику сервиса. Это делает возможным анализ как текущих, так и будущих потребностей в мощностях и ресурсах.

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

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

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

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

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

Для определения этапов, где теряется время при решении инцидентов, следует применить метод Expanded incident lifecycle из ITIL Service Design. Этот метод описывает все основные этапы обработки инцидента, включая выявление, регистрацию, диагностику, решение и закрытие. Проанализировав время, затрачиваемое на каждый этап, можно выявить узкие места. Например, если значительная часть времени уходит на диагностику, возможно, требуется улучшить документирование решений или внедрить системы автоматического анализа. Если проблемы возникают на этапе передачи инцидентов между командами, стоит оптимизировать маршрутизацию и коммуникацию. Стоит помнить, что анализ должен быть целенаправленным, фокусируясь именно на поиске наиболее затратных областей для получения максимального эффекта от оптимизации.

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

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