99,9% доступности может быть недостаточно для бизнес-процессов по нескольким причинам. Во-первых, этот показатель не учитывает распределение простоя: 0,1% от года составляет около 8,76 часов, что может быть критично, если эти часы приходятся на пиковую нагрузку. Во-вторых, для некоторых бизнес-процессов (например, финтех, здравоохранение) даже короткие простои могут привести к серьезным последствиям. В-третьих, бизнес зачастую зависит от непрерывности процессов: если 8,76 часов простоев приходятся на один раз, это может привести к утрате контрактов и репутационному ущербу, чего не отражает процентный показатель. В-четвертых, заказчик и поставщик услуг могут по-разному интерпретировать этот показатель (в год, месяц, неделю), что создает неопределенность.

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

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

Пользователь (user) - это тот, кто непосредственно пользуется ИТ-услугами в своей работе. Заказчик (customer) - это тот, кто определяет потребности, формирует задачи и, главное, оплачивает услуги. Заказчик может не использовать услугу напрямую, но влиять на формирование каталога услуг и бюджета. Например, руководитель подразделения может являться заказчиком для ИТ-службы, даже если он лично не использует все предоставляемые услуги.

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

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

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

Учет «человеческого фактора» в системном подходе к ITSM критически важен, потому что технологии могут работать идеально в изоляции, но когда их начинают использовать люди, возникает множество непредвиденных проблем. Люди имеют свои ценности, интересы, привычки и особенности поведения, которые игнорирование может привести к провалу любого преобразования. Модель системного подхода подчеркивает необходимость оценки удобства и полезности инструментов для пользователей, достаточности знаний и навыков сотрудников для использования новых технологий, а также наличия механизмов обеспечения надлежащего использования инструмента и контроля ошибок. Без учета человеческого фактора даже самые продуманные процессы и технологии могут не принести ожидаемого результата.

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

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