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

Что такое шаблон операционного соглашения?

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

Именно в OLA фиксируются эти внутренние элементы. Это не контракт: никто никому ничего не платит, а соблюдение обеспечивается исключительно управленческими механизмами — и это одновременно его слабость и причина, по которой OLA может быть честным так, как не может быть контракт.

Шаблон операционного соглашения — это повторно используемая структура: стороны, охватываемые услуги, обязательства, меры и порядок проверки. Такие шаблоны легко найти. Большинство из них позволяет написать OLA, которое формально полностью соблюдается, но всё равно приводит к провалу — и именно об этом остальная часть страницы.

OLA vs SLA: чему каждое из них на самом деле обязывает

В этой «семье» есть три документа, и если их перепутать, возникают реальные проблемы.

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

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

Поддерживающий контракт — это коммерческое соглашение с третьей стороной, вендором или аутсорс-провайдером, которое поддерживает ту же цепочку. У него есть юридическая сила, которой у OLA нет, и обычно он обладает наименьшей гибкостью из трёх, поэтому его следует согласовать до SLA, а не после.

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

Как настроить этот шаблон в Trupeer

Шаг 1: Откройте раздел «Шаблоны»

Перейдите в раздел «Шаблоны» из главного меню.

Шаг 2: Выберите и откройте шаблон

Нажмите на любой шаблон, с которым хотите работать, чтобы открыть его.

Шаг 3: Разверните просмотр шаблона

При необходимости разверните просмотр шаблона, чтобы увидеть полную раскладку и детали.

Шаг 4: Отредактируйте шаблон

Нажмите «Редактировать», чтобы начать изменять выбранный шаблон.

В редакторе вы можете:

• Добавлять новые разделы

• Задавать или обновлять правила форматирования

• Добавить логотип и настроить его положение и связанные параметры

Шаг 5: Сохраните настроенный шаблон

После того как вы внесёте все необходимые изменения, нажмите «Сохранить», чтобы сохранить обновлённый шаблон как ваш собственный.

Шаг 6: Предпросмотр и точная настройка шаблона

Когда вы захотите увидеть, как выглядит ваш настроенный шаблон, откройте «Предпросмотр».

На экране предпросмотра вы можете продолжить вносить правки напрямую при необходимости, чтобы шаблон выглядел ровно так, как вам нужно.

С шаблоном операционного соглашения вы можете:

• Экономить время на написании: пропускайте пустую страницу — структура для OLA уже готова.

• Выравнивать работу внутренних команд: встроенные поля гарантируют, что каждая команда знает свою ответственность.

• Оставаться в фирменном стиле: применяйте логотип, шрифты и цвета с помощью бренд-набора Trupeer.

• Защищать SLA клиентов: сильные OLA предотвращают поломку внешних обещаний из‑за внутренних передач.

• Стандартизировать по всем сервисам: используйте один и тот же шаблон OLA для каждого внутреннего соглашения.

• Подключать глобальные команды: переводите OLA на 65+ языков одним кликом.

Почему каждая команда выполняет свою OLA, а SLA всё равно нарушается

Это самый распространённый сценарий в управлении сервисами, и он выглядит как противоречие.

Все команды отчитываются зелёным. Сеть отвечает в пределах своего часа. Приложения закрывают задачу в пределах своих двух. Служба поддержки сортирует инциденты в течение тридцати минут. Ежемесячный отчёт о соблюдении OLA читается легко. И при этом SLA клиента нарушается в трети крупных инцидентов.

Объяснение в том, что OLA измеряют время внутри команд, а SLA — время от начала до конца. Разница между этими двумя числами — это транзит: тикет, который после переназначения стоит в очереди, ждёт, пока его возьмут в работу, или возвращается обратно за дополнительной информацией.

Это время не принадлежит никому. Оно не указано ни в чьей OLA, нигде не отражается и часто оказывается больше, чем всё рабочее время вместе взятое.

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

OLA управляет передачей, а не работой

Исправляющий взгляд — небольшой, но он меняет назначение документа.

OLA, написанная «как обычно», обязывает команду тому, сколько времени занимает её собственная работа. Это часть, которую команда контролирует, поэтому она готова это подписать — и это наименее полезная вещь для согласования, потому что это никогда не было переменной.

Хорошо написанная OLA обязывает команды интерфейсу между ними. Что должно быть в тикете до того, как его передадут. Сколько времени у принимающей команды есть, чтобы взять его в работу. Что происходит, если тикет неполный. Кто владеет тикетом в период «провала».

Как только предметом становится передача, два отсутствующих поля становятся очевидными. Критерии входа — то, что должно быть истинным до того, как начнётся отсчёт времени принимающей команды. И явное распределение самого транзитного времени, чтобы разрыв между командами был чьим-то числом, а не «ничьим».

Всё остальное в шаблоне OLA — это администрирование. Эти два пункта — и есть документ.

Критерии входа: что должно быть истинным до начала отсчёта

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

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

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

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

При этом принимающая команда сохраняет право отклонить, и оно должно быть узким: отклонение действительно только там, где конкретный критерий входа действительно отсутствует, и каждое отклонение фиксируется с причиной. Именно логирование превращает отфутболивание из невидимой привычки в число, которое кому-то придётся объяснять.

Бесплатный шаблон операционного соглашения: структура для копирования

Скопируйте отсюда. Поля, отмеченные звёздочкой, — это те, которые стандартные шаблоны пропускают.

Заголовок. Ссылка на OLA и версия. Стороны — то есть две команды поимённо. SLA или сервис, который это поддерживает. Дата вступления в силу, дата проверки и указанный владелец с каждой стороны.

Область действия. Какие услуги, системы или типы запросов это охватывает, и явно что именно не охватывает.

Часы сервиса. Покрытие для каждой стороны, включая договорённости вне рабочего времени и чем они отличаются. Несовпадение часов между двумя командами в одной цепочке — частая и тихо фатальная «дыра».

Таблица обязательств. Одна строка на тип запроса или приоритет, с: триггером, критериями входа, временем ответа, временем решения или возврата, выделенным транзитным временем и точкой эскалации.

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

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

Измерение. Что измеряется, из какой системы, кем и как часто это отчётно фиксируется. Включите rate отфутболивания вместе с временем ответа и решения, потому что это метрика, показывающая, работают ли критерии входа.

Исключения. Согласованные обстоятельства, когда обязательства не применяются, например во время объявленного крупного инцидента или при заморозке изменений.

Проверка. Даты и что запускает внеочередную проверку.

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

Как проверить, что OLA действительно складываются в SLA

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

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

Если сумма превышает SLA, у вас есть три честных варианта: пересогласовать SLA, сократить время команды за счёт чего-то, что делает это возможным, или убрать передачу. Нельзя подписывать OLA, которые гарантируют нарушение, а затем управлять производительностью по ним — именно так, к удивлению, поступают многие службы поддержки.

Ритейлер, у которого время транзита было дольше, чем работа

Rendlesham Group управляет несколькими розничными брендами с примерно шестью тысячами сотрудников и внутренней службой поддержки ИТ, которая обслуживает магазины и головной офис.

Её SLA для инцидентов P2 для бизнеса составляло четыре часа до решения. Доля нарушений по P2 держалась около тридцати восьми процентов в течение двух лет. Соблюдение OLA каждой команды сообщалось ежемесячно, и все команды были зелёными.

Наконец кто-то проставил временные метки для каждого изменения состояния по ста двадцати инцидентам P2 с нарушениями.

Медианное общее прошедшее время составило шесть часов пятьдесят один минуту. Из них три часа двенадцать минут — время внутри команды, которая активно работала с тикетом. Три часа тридцать девять минут — транзит: ожидание в очереди после переназначения, ожидание, пока его возьмут в работу, или возврат.

Более половины прошедшего времени по инциденту с нарушением принадлежало никому и не было отражено нигде.

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

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

В течение следующих двух кварталов доля отфутболиваний снизилась с тридцати четырёх процентов P2 до девяти. Медианное время транзита снизилось с трёх часов тридцати девяти минут до одного часа шести. Доля нарушений по P2 снизилась с тридцати восьми процентов до одиннадцати.

Внутреннее время решения ни одной команды существенно не изменилось. Никто не работал быстрее. Просто время, которое принадлежало никому, отдали кому-то.

Как составить операционное соглашение, шаг за шагом

Начните с SLA, а не с шаблона. Запишите, что обещано клиенту, от начала до конца, с определением времени.

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

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

Теперь согласуйте времена, работая с арифметикой выше, а не по командам. Если сделать это как единый разговор со всеми участниками, это займёт час и полностью предотвратит проблему суммы.

Явно распределите транзит и решите, кто им владеет. Пятнадцать минут на каждую передачу — разумная отправная точка, и это время должно засчитываться принимающей команде.

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

Затем прогоните это в течение квартала, прежде чем формализовать. Первые версии обычно неверны в одном-двух местах, и их проще исправить до того, как появятся подписи.

Частые ошибки в OLA и что каждая из них стоит

Измерять команды, а не цепочку. Все зелёные, а SLA нарушается. Самая частая ошибка и тема этой страницы.

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

Времена не складываются. Набор OLA гарантирует нарушение, и никто никогда не посчитал сумму.

Несовпадающие часы сервиса. Одна команда покрывает до шести, следующая — до пяти. Всё, что приходит после пяти, остаётся на ночь, и ни один отчёт этого не показывает, потому что обе команды находятся внутри своих часов.

Копирование формулировок SLA в OLA. Штрафы, кредиты и юридические формулировки здесь неуместны, и если их импортировать, команды начинают вести переговоры оборонительно вместо того, чтобы честно.

Написание OLA с третьей стороной. Если деньги переходят из рук в руки, это поддерживающий контракт, и он требует участия закупок и юристов, а не шаблона. Наш шаблон политики закупок ИТ описывает путь согласования.

Подписание и подшивка. OLA, которую никто не проверяет, описывает цепочку сервиса, которой примерно через год уже не существует.

Как управлять и пересматривать OLA, когда они уже есть

Отчитывайтесь о цепочке, а не о компонентах. Важна одна цифра — производительность от начала до конца относительно SLA, и метрики OLA существуют, чтобы объяснять её, а не существовать сами по себе.

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

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

Запускайте внеочередной пересмотр, когда команда реорганизуется, когда система переходит между командами, когда в цепочку входит новая третья сторона или когда меняется лежащий в основе SLA. Все четыре события происходят чаще, чем предполагает годовой цикл пересмотра.

OLA, SLA или поддерживающий контракт: что вам нужно?

Если обязательство дано кому-то за пределами вашей организации поставки — будь то внешний клиент или внутреннее бизнес-подразделение, которое обслуживают, — это SLA.

Если обязательство между двумя командами внутри одной и той же организации и при этом деньги не переходят из рук в руки, это OLA.

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

Сложный случай — центр совместных услуг или внутренняя команда с моделью chargeback, которая находится между OLA и SLA. Практический ответ — написать это как OLA и убрать любые формулировки о штрафах, потому что внутренние штрафные режимы стабильно порождают оборонительное поведение и худший сервис.

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

Могу ли я получить шаблон OLA в Word или Excel?

Word — для соглашения, потому что область действия, исключения и разделы проверки — это текст, и документ нужно разослать для согласования и подписания.

Excel — для двух частей. Таблица обязательств, где вы хотите видеть критерии входа, времена и распределение транзита в колонках, которые можно сортировать и проверять. И лист с арифметикой, где каждая цепочка суммируется относительно своего SLA и подсвечивает всё, где нет запаса. Второй лист — тот, который стоит собрать первым, потому что он часто меняет то, что вы собирались согласовать.

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

Как держать OLA и реальность в одном шаге

OLA описывает цепочку работ, которая постоянно меняется. Команды реорганизуются, системы перемещаются, инструменты обновляются, и документ — последняя вещь, которую кто-то обновляет.

Быстрее всего устаревают критерии входа, потому что они описывают, что должен содержать тикет, а то, что должен содержать тикет, зависит от того, как сейчас реально работают текущие инструменты и текущий процесс.

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

Запишите. Оформите в бренде. Переведите. Trupeer it.

SOP creator охватывает процедуры, от которых зависит OLA, а наш шаблон SOP для ИТ описывает, как решить, какие из них стоит поддерживать. Документация хранит соглашения и процедуры вместе, а инструкции по настройке находятся в руководстве по настройке шаблона документа.

Часто задаваемые вопросы

Есть ли бесплатный шаблон операционного соглашения в Word?

Структура выше вставляется прямо в Word или Google Docs, включая поля критериев входа и распределения транзита, которые стандартные шаблоны пропускают. Нет ограниченной загрузки и нет формы. Держите таблицу обязательств в таблице (spreadsheet) и ссылайтесь на неё, потому что именно её нужно сортировать и суммировать.

Есть ли бесплатный шаблон операционного соглашения в PDF?

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

Есть ли бесплатный шаблон операционного соглашения в Excel?

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

Где найти пример операционного соглашения в PDF?

Несколько вендоров ITSM и госорганов публикуют шаблоны OLA и SLA в виде документов, и они подходят по структуре. Читайте их по разделам, а не по содержанию, потому что обязательства в любом опубликованном примере — это чужая цепочка, а времена не имеют смысла вне SLA, для которого они были сделаны.

Кто подписывает операционное соглашение?

Указанный владелец с каждой стороны — это должен быть менеджер, ответственный за поставку этой команды, а не функция по управлению сервисами. OLA, подписанная только службой управления сервисами, — это скорее пожелание, потому что человек, который должен выделить ресурсы, не был в комнате.

Сколько OLA нужна службе поддержки?

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

Нужно ли включать в операционное соглашение штрафы?

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

Как часто нужно пересматривать OLA?

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