В статье Владимира Репина обсуждаются ключевые временные характеристики бизнес-процесса: что и как измерять? Как разработать и использовать SLA и OLA для кросс-функциональных бизнес-процессов? Как сократить время выполнения бизнес-процесса используя OLA и KPI для его участников?

Важна ли длительность выполнения бизнес-процесса?

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

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

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

Рассмотрим пример – процесс «Заключение договора с клиентом». Важно ли для клиента заключить договор как можно быстрее? Как правило, да. А для организации? О да, каждая компания заинтересована как можно быстрее заключить договор и получить деньги. В теории – это так, но на практике я наблюдал картину, когда средняя длительность согласования постоплатного договора по форме клиента составляла у торговой компании более 20 календарных дней, при этом никого из менеджеров этот факт особенно не волновал. Очевидно, всё определяется потребностями ключевых заинтересованных сторон в компании, в первую очередь, — собственника. В большинстве случаев, сокращение времени выполнения кросс-функциональных бизнес-процессов считается необходимым.

Если нет очереди (клиентов, заявок, товаров, изменений и т.п.), то сокращать время выполнения бизнес-процессов, казалось бы, бессмысленно. Но это не так. Во-первых, очередь из клиентов может возникнуть внезапно (после удачной рекламной компании нового продукта/услуги и т.д.) – нужно быть готовым к увеличению нагрузки. Во-вторых, сокращение времени выполнения задач/процессов означает, в том числе, повышение производительности работы сотрудников. Если процессы выполняются быстрее, то высвобождается рабочее время, что позволяет его использовать для других важных задач.

Показатели времени выполнения задач и бизнес-процесса в целом

Какие показатели можно использовать для измерения времени выполнения задач и бизнес-процесса в целом?

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

Нормативная длительность (трудоемкость) выполнения бизнес-процесса – это сумма нормативного времени всех задач внутри одного экземпляра бизнес-процесса в случае выполнения его по кратчайшему пути (Happy Path), то есть без ошибок, задержек и возвратов. Пример: нормативная трудоемкость выполнения кросс-функционального бизнес-процесса согласования договора с клиентом в некоторой компании составляет 4 часа 26 минут.

Фактическая трудоемкость выполнения задачи – реальное время, которое потратил сотрудник на выполнение задачи определенного уровня сложности. Например, бухгалтер потратил 22 минуты на вычитку и согласование договора.

Фактическая трудоемкость выполнения бизнес-процесса — это сумма фактической трудоемкости выполнения всех задач бизнес-процесса, включая те, которые выполнялись повторно. Практический интерес представляет средняя фактическая трудоемкость. Для ее расчета нужно сложить фактическую трудоемкость всех задач, выполненных в каждом экземпляре бизнес-процесса, и поделить эту сумму на количество экземпляров процесса, которые были реализованы за определенный период (месяц, квартал). Пример: фактическая трудоемкость выполнения кросс-функционального бизнес-процесса согласования договора с клиентом составила 12 часов 38 минут.

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

Средняя календарная длительность выполнения бизнес-процесса. Каждый экземпляр бизнес-процесса имеет дату и время своего начала и завершения. Например, согласование конкретного проекта договора было инициировано в 9-32 2 декабря, а завершено 15 декабря в 17-21. Если сложить календарную длительность всех экземпляров процесса, выполненных за месяц, и поделить на их общее количество, то мы получим среднюю календарную длительность выполнения. Например, для процесса согласования договора с клиентом она составила 4 недели 2 дня и 6 часов.

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

1. процесс «стоит» в ожидании доступности ресурсов (исполнителей, оборудования и других ресурсов);
2. при выполнении процесса возникают возвраты на предыдущие этапы.

Почему ресурсы для выполнения бизнес-процесса оказываются недоступными? Дело в том, что:

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

SLA и OLA на время

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

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

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

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

Рис. 1. Владелец процесса указывает сотруднице на превышение предельного времени выполнения задачи в рамках кросс-функционального бизнес-процесса.

А что в западной практике? Там определены понятия SLA и OLA:

• «SLA (Service Level Agreement) — это внешний документ, который подписывают обе стороны и имеет юридическую значимость. Он определяет, какие услуги, в каком количестве и в какой срок будет предоставлять поставщик».
• «OLA (Operational Level Agreement) — это аналогичный, но внутренний документ. Он составляется для внутренних подразделений и сотрудников компании, которые несут ответственность за соблюдение сроков и условий SLA».

Понятие SLA прошло эволюцию от технического регулирования до стандарта бизнес-отношений:

• 1970-е (Телекоммуникации): зарождение термина в США. Использовался операторами связи под давлением регуляторов (FCC) для гарантии доступности телефонных линий. Метрики были сугубо техническими.
• Конец 1980-х (ITIL v1): с появлением библиотеки ITIL в Великобритании, SLA стало стандартом для IT-услуг. Фокус сместился с «работы оборудования» на «ценность для пользователя».
• 1990-е (Аутсорсинг и ASP): бум доткомов превратил SLA в юридический инструмент финансовых гарантий в договорах хостинга.
• Современность (ESM — Enterprise Service Management): SLA вышло за пределы IT. Сегодня применяется в HR, закупках, юридическом обеспечении и проч.

Если рассматривать SLA с точки зрения времени выполнения, можно привести примеры, когда компания гарантирует клиенту, что:

• время с момента получения заявки до момента выставления счета на оплату составит не более 1 рабочего дня (SLA для внешних клиентов);
• время согласования постоплатного договора по форме клиента составит не более 1 рабочей недели (SLA для внешних клиентов);
• время предоставления коммерческого предложения составит не более 3-х рабочих дней (SLA для внешних клиентов);
• время подбора сотрудника по заявке составит не более 3 недель (SLA для внутренних клиентов);
• время ремонта оборудования заданного типа составит не более 6 часов (SLA для внутренних клиентов).

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

Для того, чтобы OLA можно было контролировать, необходимо, как минимум:

1. организовать учет фактической календарной длительности выполнения задач исполнителями;
2. разработать информационную панель, с использованием которой руководитель (владелец процесса) будет выполнять оперативный мониторинг исполнения OLA сотрудниками.

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

Рассмотрим, как такая задача может быть решена с использованием программного продукта Business Studio 7. На рис. 2 показан фрагмент бизнес-процесса согласования договора на закупку. Это типичный кросс-функциональный административный бизнес-процесс, который представляется собой «микс» каскадного и параллельного согласования (как впрочем и многие другие процессы, которые выполняются в офисе наших компаний).

Рис. 2. Атрибуты в свойствах задачи бизнес-процесса.

В свойствах задачи бизнес-процесса создано несколько новых атрибутов: «Нормативная трудоемкость, минут», «SLA, нормативная длительность, минут» (предельный нормативный срок выполнения задачи), «SLA, средняя фактическая длительность, минут» (фактический средний календарный срок выполнения задачи). (Правильнее было бы назвать атрибуты OLA, но что сделано, то сделано).

Нормативная трудоемкость выполнения задач и OLA по их предельной длительности могут быть введены в Business Studio вручную или импортированы из различных источников.

Значения средней фактической календарной длительности выполнения задач сотрудниками могут быть импортированы в Business Studio, например, из 1С-ДО или других систем.

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

Результат показан на рис. 3. Например, видно, что отклонение среднего фактического значения OLA для задачи «Согласовать договор» (которую выполняет Руководитель департамента закупок) от нормативного, составляет 250% в сторону превышения (красная заливка).

Рис. 3. Вывод информации о времени выполнения задач на схему бизнес-процесса.

Общая схема бизнес-процесса согласования договора на закупку с индикаций нормативных и фактических значений (отклонение в %) показана на рис. 4. Руководители могут использовать Business Studio 7 (Portal Viewer) для мониторинга исполнения OLA для всех ключевых кросс-функциональных бизнес-процессов компании (в случае, если в Business Studio создана архитектура процессов и соответствующие модели процессов на операционном уровне).

Рис. 4. Схема бизнес-процесса с индикаций показателей OLA.

Как использовать OLA для мониторинга и контроля бизнес-процесса?

Владелец процесса может использовать OLA следующим образом:

• выполнять оперативный (ежедневный, еженедельный) мониторинг исполнения OLA участниками бизнес-процесса с использованием BPM-системы (СЭД), чат-ботов и проч.;
• выполнять ежемесячный контроль исполнения OLA участниками бизнес-процесса-(ов) с использованием Business Studio 7 Portal Viewer;
• выполнять анализ отклонений от OLA по итогам месяца/квартала с использованием технологий OLAP и BI и соответствующих панелей управления;
• принимать решения по исполнителям бизнес-процесса, в том числе мотивационного характера на основе KPI – сокращать или увеличивать премии и проч.;
• инициировать и выполнять быстро-реализуемые инициативы (БРИ) и/или проекты по оптимизации бизнес-процесса.

Удобным инструментом мониторинга OLA являются системы класса BPM. На рис. 5 и 6 показаны примеры панелей управления, разработанные в Elma-365.

Рис. 5. Пример мониторинга бизнес-процесса в Elma-365.

Рис. 6. Пример мониторинга бизнес-процесса в Elma-365.

Рис. 7. Пример мониторинга бизнес-процесса в Comindware.

Рис. 8. Пример мониторинга бизнес-процесса в Comindware.

Кейс 1 . «Мгновенная доставка» глобального маркетплейса.
Крупный e-commerce ритейлер строит свое конкурентное преимущество на жестком SLA для клиентов уровня Prime: «Доставка на следующий день». Внешнее обязательство (SLA) звучит просто: товар должен быть вручен клиенту до 19:00 следующего дня. Однако, чтобы выдержать этот срок, весь сквозной процесс «от клика до двери» декомпозирован на строжайшие OLA для внутренних подразделений и IT-систем:

• OLA 1 (IT-система): Обработка транзакции и передача заказа в WMS (систему управления складом) — не более 2 минут.
• OLA 2 (Склад / Комплектация): Подбор товара роботом или сотрудником («Pick & Pack») — не более 45 минут с момента поступления заказа.
• OLA 3 (Внутренняя логистика): Перемещение со склада в зону отгрузки — не более 15 минут.
• OLA 4 (Транспортный цех): Погрузка в трак (грузовик) — строго до 23:00 текущего дня.

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

Кейс 2: «Ипотека за 24 часа»
В условиях жесткой конкуренции за качественного заемщика, один из российских банков поставил цель сократить время принятия решения по ипотечной сделке. SLA (Для клиента): Получение финального одобрения по кредиту и объекту недвижимости — 24 часа (1 рабочий день). Для обеспечения такого результата процесс, в котором участвуют рисковики, юристы и служба безопасности, был «прошит» следующими OLA:

• OLA 1 (Андеррайтинг): Скоринговая оценка заемщика (автоматически + верификация) — не более 1 часа.
• OLA 2 (Оценщики/Залоги): Проверка отчета об оценке квартиры — не более 3 рабочих часов.
• OLA 3 (Юристы): Правовая экспертиза чистоты сделки — не более 4 рабочих часов.

Ранее юристы могли рассматривать документы до 2-х дней, ссылаясь на высокую загрузку. Введение жесткого OLA в 4 часа потребовало изменения самой технологии работы: типовые объекты теперь проверяются по чек-листу (Fast Track), а сложным случаям присваивается особый статус. Это наглядно показывает, что OLA часто выступает драйвером оптимизации самого процесса.

Если рассматривать SLA с точки зрения времени выполнения, можно привести примеры, когда компания гарантирует клиенту, что:

• время с момента получения заявки до момента выставления счета на оплату составит не более 1 рабочего дня (SLA для внешних клиентов);
• время согласования постоплатного договора по форме клиента составит не более 1 рабочей недели (SLA для внешних клиентов);
• время предоставления коммерческого предложения составит не более 3-х рабочих дней (SLA для внешних клиентов);
• время подбора сотрудника по заявке составит не более 3 недель (SLA для внутренних клиентов);
• время ремонта оборудования заданного типа составит не более 6 часов (SLA для внутренних клиентов).

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

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

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

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

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

OLA и KPI

Что будет мотивировать исполнителя выполнять установленные для него OLA? Совесть? Профессионализм? Жесткий контроль вышестоящим руководителем? Возможно, все это. Но целесообразно разработать соответствующие KPI.

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

1. фиксированный оклад – 100 тыс. рублей;
2. ежемесячная премия – до 50% от оклада.

Премия, в свою очередь, состоит из следующих частей (пример):

1. премия от общего результата работы компании за месяц (выполнение плана продаж) – 25%;
2. оценка вышестоящим руководителем работы бухгалтера (в том числе выполнения поручений) – 25%;
3. премия за выполнение OLA в кросс-функциональных бизнес-процессах – 50%.

Премия за выполнение OLA может быть рассчитана следующим образом:

№	Наименование бизнес-процесса	Вес	Нормативное значение OLA	Среднее значение OLA	Отклонение в %	Доля в премии, %
1	Согласование договора с клиентом	0,4	240 минут	378 минут	57,50%	0%
2	Согласование договора на закупку	0,3	360 минут	574 минуты	59,44%	0%
3	Согласование заявки на оплату	0,3	360 минут	243 минуты	-32,50%	30%
	% от премии за OLA					15%

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

Таким образом, при фиксированном окладе 100 тыс. рублей, бухгалтер получит за месяц 128 750 рублей, вместо максимальных 150 тыс. рублей, что достаточно чувствительно.

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

Рис. 9. Бухгалтер в офисе пытается выполнять OLA в кросс-функциональных бизнес-процессах.

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

В чем разница между SLA и OLA?
Соглашение об уровне сервиса (SLA) упрощает взаимодействие между поставщиком и заказчиком за счет обещаний (гарантий) определенного уровня качества обслуживания (сроки, стоимость, дефекты и проч.) OLA, в свою очередь, определяет, как исполнители будут работать вместе для выполнения этого SLA.

Почему ОЛА так важны?
Руководители отделов четко понимают, кто из сотрудников за что отвечает. Они следят за тем, чтобы каждый сотрудник и каждая внутренняя команда эффективно работали над достижением конечного результата.

Кто должен создавать ОЛА?
В процесс разработки должны быть вовлечены: владелец процесса, руководители отделов, ключевые исполнители и все, кто отвечает за скорость и качество обслуживания. Внутренние заинтересованные стороны, участвующие в заключении соглашений об уровне сервиса (SLA), должны согласовать свои роли и вклад в SLA, в том числе с использованием OLA.

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

Что произойдёт в случае нарушения OLA?
Нарушение OLA может привести к задержке предоставления услуг и сбоям с SLA. Эти сбои часто приводят к недовольству клиентов (внешних и внутренних), поэтому отслеживание OLA имеет решающее значение.

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

Как часто следует обновлять OLA?
Желательно обновлять OLA при каждом изменении бизнес-процессов, организационной и ролевой структуры (обязанностей исполнителей), программных продуктов, оптимизации бизнес-процессов или изменении SLA.

Владимир Репин,
к.т.н., доцент, консультант по управлению, процессный архитектор и методолог, член ABPMP Russian Chapter, автор 10 книг по бизнес-процессам.

Декабрь 2025 г.

www.bpm3.ru