EULA (End User License Agreement) - это лицензионное соглашение с конечным пользователем, которое определяет условия использования программного обеспечения. Оно включает в себя не только информацию о количестве лицензий, но и множество других условий и ограничений, таких как запреты на установку ПО на сервера, использование в коммерческих целях и другие правила, соблюдение которых критично для соответствия требованиям.

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

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

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

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

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

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

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

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

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