Что такое OLA, чем отличается от SLA и зачем нужно бизнесу: гайд для команд

Кайтен

Управляйте задачами, проектами и командой в одном месте

Попробовать бесплатно

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

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

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

Для этого используют SLA и OLA. В статье разберем, что такое OLA, чем оно отличается от SLA и где применяется.

Что такое OLA

OLA (Operational Level Agreement) — внутреннее соглашение между отделами об уровне сервиса и правилах взаимодействия. Обычно его оформляют как документ, где фиксируют: 

• зоны ответственности;
• сроки реакции и выполнения;
• правила передачи задач;
• порядок эскалации;
• метрики качества процесса.

Например, компания обещает сотрудникам восстановить доступ к CRM за четыре часа. Чтобы уложиться в этот срок:

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

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

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

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

OLA — один из инструментов, который помогает сократить такие потери.

Чем OLA отличается от SLA

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

SLA (Service Level Agreement) — это договоренность между компанией и клиентом или внутренним заказчиком о качестве услуги: сроках реакции на обращение, времени решения проблемы, доступности сервиса и других показателях.

Например, в SLA может быть указано, что проблему пользователя нужно решить за восемь часов. А OLA распределяет это время между участниками процесса: поддержкой, ИТ и разработкой. 

Таблица: отличие OLA от SLA

Где применяют OLA и примеры взаимодействия

Чаще всего OLA используют в процессах, где важны скорость реакции, понятные зоны ответственности и предсказуемые сроки.

• ИТ-поддержка. Пользователь сообщает о проблеме с сервисом. Первая линия поддержки принимает заявку и проводит базовую диагностику. Если проблема связана с инфраструктурой, задачу передают системным администраторам. Если причина в продукте — подключается разработка.
• HR и найм сотрудников. Рекрутер передает кандидата нанимающему менеджеру, а тот должен дать обратную связь в фиксированный срок. Иначе сильный кандидат может принять оффер другой компании, пока внутри продолжаются согласования.
• Онбординг сотрудников. HR оформляет документы, ИТ готовит учетные записи и доступы, АХО — рабочее место и технику, а руководитель планирует первые задачи. Если один из этапов задерживается, новый сотрудник может несколько дней ждать оборудование или доступ к рабочим системам.
• Согласование документов. Менеджер отправляет договор в бухгалтерию, затем документ проверяют юристы и другие участники процесса. Если сроки и ответственность не определены заранее, согласование может растянуться на недели.

Пример, как фиксировать внутренние сроки для каждого этапа онбординга:

• HR передает данные сотрудника в ИТ за 3 дня до выхода;
• ИТ настраивает доступы в течение 1 рабочего дня;
• АХО должно подготовить ноутбук минимум за сутки до начала работы;

Также в OLA фиксируют, что делать при сбоях. Например, если один из этапов задерживается, руководитель получает уведомление.

Что должно быть в OLA  

Обычно в OLA фиксируют:

• Цель соглашения. Например, сократить время обработки заявок, ускорить онбординг сотрудников или уменьшить количество просрочек.
• Участников процесса. Какие команды участвуют в работе и кто отвечает за каждый этап.
• Процессы, которые покрывает OLA. Это может быть обработка инцидентов, согласование договоров, подключение новых сотрудников или работа с клиентскими обращениями.
• Сроки реакции и выполнения. Сколько времени есть на принятие задачи, обработку и передачу следующей команде.
• Правила передачи задач. Какие данные нужно приложить, в каком статусе передавать работу и кто принимает задачу дальше.
• Порядок эскалации. Кто подключается, если задача выходит за рамки сроков или процесс останавливается.
• Метрики качества. Например, время реакции, количество просрочек, доля возвратов на доработку или среднее время прохождения задачи через процесс.
• Правила пересмотра OLA. Процессы внутри компании меняются, поэтому соглашение важно регулярно обновлять, а не хранить как формальный документ.

Как составить OLA 

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

Шаг 1. Найти процесс, где возникают задержки

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

Шаг 2. Разобрать процесс по этапам

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

Шаг 3. Зафиксировать правила взаимодействия

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

Заркепить это можно в сервисах по управлению проектами, например, в Kaiten.

Кайтен — российский сервис для совместной работы. Все процессы компании в одном месте: проекты, задачи, цели, сотрудники, документы, переписки, отчеты, заявки.

Попробовать бесплатно

Шаг 4. Определить метрики

В OLA лучше сразу закладывать измеримые показатели, иначе оценить эффективность процесса будет сложно. Обычно компании отслеживают:

• время реакции;
• срок выполнения задачи;
• количество просрочек;
• среднее время прохождения задачи через процесс.

Шаг 5. Сделать процесс прозрачным

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

Шаг 6. Регулярно обновлять OLA

Процессы внутри компании меняются: появляются новые команды, инструменты и этапы согласования. Если OLA не пересматривать, со временем он начинает описывать процесс, которого уже не существует.

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

Ошибки при внедрении OLA 

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

Смешивать OLA и SLA

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

Например, в SLA указано, что сервис нужно восстановить за четыре часа. А рядом прописывают внутренние требования: поддержка должна ответить за 15 минут, инфраструктурная команда — проверить серверы за 30 минут, разработка — подключиться в течение часа.

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

Описывать ответственность общими словами 

Формулировки вроде «разработка подключается при необходимости» или «менеджер координирует процесс» обычно работают только до первой нестандартной ситуации.

Например, ночью перестает работать приложение. Поддержка видит инцидент, но не понимает, кого именно подключать: дежурного инженера, владельца продукта или инфраструктурную команду. Пока сотрудники пересылают сообщения друг другу, простой продолжается.

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

Не назначать владельца процесса

Часто за отдельные этапы отвечают разные команды, но за процесс целиком — никто.

Например, HR передал данные нового сотрудника в ИТ. ИТ создали учетную запись, но забыли выдать доступ к CRM. Руководитель уверен, что все готово, потому что «задача уже у айтишников». В итоге сотрудник выходит на работу без доступов, а команды начинают выяснять, кто должен был проверить итоговый результат.

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

Устанавливать сроки, которые невозможно соблюдать

Если требовать реакции за 15 минут при высокой нагрузке и небольшой команде, сотрудники быстро перестанут воспринимать такие правила всерьез. В итоге OLA формально существует, но никто не ориентируется на него в реальной работе.

Передавать задачи вне общего процесса

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

• кто сейчас отвечает за задачу;
• принял ли следующий участник ее в работу;
• когда началась обработка;
• на каком этапе возникла задержка.

Например, поддержка пишет разработчику: «Посмотри, пожалуйста, срочную проблему у клиента». Разработчик отвечает через два часа, потому что не заметил сообщение. Поддержка считает, что задача уже в работе, а разработка — что это был просто вопрос в чате, а не официальный инцидент. 

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

Не прописывать правила эскалации

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

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

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

Не смотреть на метрики

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

Хранить OLA отдельно от реальной работы

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

Не пересматривать OLA после изменений в процессе

Процессы внутри компании постоянно меняются: появляются новые команды, сервисы и этапы согласования. Если соглашение не обновлять, со временем оно начинает описывать процесс, которого уже не существует.

Как встроить OLA в ежедневную работу команды

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

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

OLA можно хранить в разделе «Документы». Это встроенная база знаний, где можно описать все, что входит в OLA: зоны ответственности команд, сроки реакции и выполнения, правила передачи задач, сценарии эскалации и метрики.

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

Также в Кайтене есть модуль «Служба поддержки». Он помогает выстроить работу с обращениями пользователей и внутренними заявками.

В модуле можно настраивать SLA — например, задавать сроки реакции и обработки заявок.

Основа работы в Кайтене — канбан- доски. Они помогают визуализировать процесс: каждая задача отображается в виде карточки и проходит через этапы работы — например: Новая заявка → Проверка → В работе → Согласование → Готово.

Карточки помогают хранить всю информацию в одном месте: сроки, приоритеты, комментарии, чек-листы, файлы и связанные задачи. Благодаря этому командам не приходится искать детали в переписках и разных системах.

Упростить работу помогают автоматизации. В Кайтене можно настроить правила, по которым:

• после создания заявки система автоматически назначает ответственного;
• при переходе карточки в новую колонку задача передается следующей команде;
• если срок начинает срываться, руководитель получает уведомление;
• после выполнения всех подзадач карточка автоматически переходит на следующий этап процесса.

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

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

В статье «1500 заявок вместо 500, но отвечаем в 4 раза быстрее: кейс техподдержки Кайтен» поделились кейсом нашей команды поддержки. Рассказали, как сервисные процессы, SLA и автоматизации используют внутри компании — и как это помогло справиться с ростом нагрузки без увеличения команды.

Что важно запомнить 

1. OLA — это внутреннее соглашение между командами, которое помогает синхронизировать работу разных участников процесса. Оно нужно, чтобы задачи не «застревали» между отделами, а сроки не зависели от случайных договоренностей в чатах и переписках.
2. SLA отвечает за обязательства перед клиентом: например, за скорость реакции поддержки или доступность сервиса. OLA описывает, как внутренние команды должны взаимодействовать, чтобы эти обязательства выполнить.
3. Обычно в OLA фиксируют: зоны ответственности, сроки реакции и выполнения, правила передачи задач, порядок эскалации, метрики качества.
4. Если OLA существует только как документ в папке, сотрудники быстро перестают им пользоваться. Чтобы договоренности действительно соблюдались, они должны быть встроены в ежедневный процесс работы.
5. Системы управления рабочими процессами помогают сделать OLA прозрачным: видеть ответственных, сроки, загрузку команд и этапы, где чаще всего возникают задержки.