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

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

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

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

В ITIL риск определяется как потенциальное причина негативного воздействия на цели организации. Когда риск реализуется, он перестаёт быть потенциальным и становится фактом – наступает негативное событие, которое наносит ущерб или осложняет достижение целей. В этом случае в действие вступают процессы управления инцидентами, проблемами и рисками для устранения последствий и предотвращения повторения.

Метрика распределяет ответственность за нарушение срока обработки пропорционально доле участия каждой группы в общем времени обработки просроченного инцидента. Для этого используется формула, где для каждого просроченного инцидента (vi=1) вычисляется доля времени группы (ti/Ti), которую затем вычитают из единицы. Чем большую часть общего времени обработки инцидента занимала группа, тем больше ее ответственность за просрочку и тем ниже её KPI. Это позволяет избежать ситуаций, когда 'стрелочником' становится последняя группа, получившая уже просроченный инцидент.

Предлагаемая модель значительно снижает нагрузку на сотрудников первой линии, так как избавляет их от обработки 60% обращений, связанных со специфическими ИТ-системами. Им остаются только телефонные звонки (30% обращений), email-сообщения и те случаи, когда пользователь не смог правильно классифицировать проблему через портал. Это позволяет уменьшить стресс за счет снижения количества задач, повысить качество обработки оставшихся обращений и лучше сосредоточиться на тех задачах, с которыми первая линия действительно может справиться.

Основная тема книги - построение каталога ИТ-услуг и организация Service Level Management (SLM) в ситуациях, когда ИТ-подразделение находится в составе компании или группы компаний. Книга подробно рассматривает методы формирования каталога ИТ-услуг, разделения его на каталог для заказчиков (Service Catalog) и каталог для пользователей (Service Request Catalog), а также рекомендации по внедрению ITSM. Авторы предлагают рассматривать бизнес-процессы предприятия как основной источник информации для формирования бизнес-ориентированного каталога ИТ-услуг.

Основное сходство между IT4IT и ITIL v3 заключается в использовании концепции жизненного цикла услуги. В IT4IT сервисная модель (Service Model) построена вокруг четырех основных столпов и представляет собой Service Backbone, что по сути соответствует этапам жизненного цикла услуги в ITIL v3 - от концепции до оказания услуги. Обе модели рассматривают ИТ-услуги в разрезе процессов, и многие функциональные компоненты в IT4IT (такие как управление инцидентами, проблемами, изменениями) напрямую соответствуют стандартным процессам ITIL v3. При переходе к ITIL v4 видно еще больше общего, в частности, использование цепочки создания ценности (Value Chain), впервые предложенной Майклом Портером. Обе модели стремятся описать целостную картину ИТ-управления, а не просто набор разрозненных процессов.

ITIL выделяет три типа поставщиков услуг: Тип I и Тип II (внутренние поставщики) и Тип III (внешние поставщики). Для внутренних поставщиков (Тип I и Тип II) финансовые штрафы обычно отсутствуют, а ответственность выражается в виде уменьшения премий сотрудников ИТ-подразделения. Штрафы могут применяться автоматически или на усмотрение руководства, что делает применение санкций менее однозначным. Для внешних поставщиков (Тип III) предусматриваются реальные финансовые санкции, но их размер и применение часто ограничены. Например, сумма штрафов обычно не превышает 20–30% от суммы контракта, а в некоторых законах, таких как 44-ФЗ, штрафные санкции определены значительно ниже, в диапазоне от 0,5% до 2,5% от суммы контракта.