operational level agreement, OLA

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

Частая ошибка — воспринимать OLA как «внутренний SLA один в один». SLA ориентировано на ценность и результаты для заказчика и формулируется языком услуги, тогда как OLA привязывает внутренние обязательства к операционным возможностям и зонам ответственности подразделений. Из-за этого OLA нередко пишут слишком общо («поддержка 24/7»), не определяя конкретные выходы, критерии завершения и измеримые параметры, и в результате оно не помогает ни управлению инцидентами, ни эскалации. Ещё одна типичная путаница — считать OLA договором с третьей стороной: внутреннее соглашение не может принудить внешнего поставщика, поэтому зависимости от поставщиков должны быть покрыты отдельными соглашениями и управлением поставщиками, а затем «приземлены» в OLA как внутренние обязательства по координации и контролю. Также важно не подменять OLA описанием процесса или рабочей инструкцией: процесс отвечает на вопрос «как работаем», а OLA — «что именно и в какие сроки обязаны предоставить друг другу». Наконец, нужно избегать метрик, которые оптимизируют локальную рациональность в ущерб услуге, например требовать от команды поддержки «закрывать инцидент за 15 минут» без учёта качества разрешения и влияния на результат.