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

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

Фиксированная эскалация создает четкие границы ответственности между бизнес-аналитиками и разработчиками в процессе обработки инцидентов. Бизнес-аналитики, выступающие в роли третьей линии поддержки (L3), получают инцидент после предварительной диагностики на уровне L2 и определяют, связана ли проблема с ошибками программного обеспечения или с некорректными требованиями к алгоритмам от бизнес-подразделений. Если требования были сформулированы верно, инцидент передается на уровень L4 к разработчикам для внесения исправлений в код. Такая структура предотвращает ситуацию, когда разработчики тратят время на анализ требований, и наоборот, бизнес-аналитики не тратят время на отладку программного кода, что повышает эффективность работы обеих групп.

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

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

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

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

Помимо USM (Universal Service Management) и eSCM-SP (eSourcing Capability Model for Service Providers), в тексте упоминается подход, аналогичный eTOM (Enhanced Telecom Operations Map), но адаптированный для более широкого спектра услуг. Автор полагает, что существует потребность в промежуточном варианте между USM и eSCM-SP - уровне сложности, близком к eTOM, но с обобщением на различные виды услуг. Такой подход должен сохранять простоту понимания, присущую USM, но иметь большую детализацию, чем это предлагается USM, и в то же время быть менее сложным, чем eSCM-SP.

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

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