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

Для демонстрации отделения сервисного и процессного подходов можно взять компанию, оказывающую два вида услуг: услуги эксплуатации информационных систем (ИС) и услуги заказной разработки программного обеспечения (ПО). Для этих видов услуг производственные процессы могут серьезно различаться: в разработке ПО лежит процессная модель ALM (или RUP, MSF и другие), а в эксплуатации ИС - операционные процессы ITIL. При этом управленческие процессы, такие как SLM (Service Level Management), будут общими для обоих видов услуг.

Контекстуальное качество процесса учитывает аспекты, связанные с рациональной организацией процесса в конкретной организации, в дополнение к прямому качеству, которое отражает выполнение основного назначения процесса. Это включает такие элементы, как доля стандартных изменений, доля экстренных изменений, доля изменений, реализуемых с первого раза, доля изменений, проходящих через CAB, и доля изменений, проходящих через PIR. Контекстуальное качество также учитывает вопросы доступности информации о процессе (accessibility) и конфиденциальности, то есть кто имеет право доступа к документации по процессу и записи изменений. Эти аспекты более специфичны для каждой организации и зависят от уровня ее зрелости в управлении ИТ.

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

В тексте упоминаются следующие семь руководящих принципов ITIL: 1) Сфокусируйтесь на ценности (семь раз отмерь – один отрежь); 2) Сотрудничайте и поощряйте прозрачность (доверяй, но проверяй); 3) Простота и практичность (не усложняйте себе жизнь); 4) Действуйте итерационно, используя обратную связь (как аукнется – так и откликнется). Названо только четыре принципа из семи, но текст указывает, что полный список описан в статье Игоря Гутника.

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

Авторский учебный курс от CleverKPI отличается возможностью детально обсудить тему измерения ИТ с экспертом напрямую. Он стоит 29 500 рублей и предназначен для тех, кому недостаточно информации из книги. На курсе участники получают углубленные знания и практические рекомендации, основанные на апробированной методике, которая проверена на реальных кейсах в течение 4-5 лет.

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

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

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