Мониторинг бизнес-процессов: простые метрики и алерты

Почему важно мониторить процесс, а не только серверы

Мониторинг серверов отвечает на вопрос: «Жива ли система?» Но бизнесу обычно важнее другое: «Делается ли работа вовремя и без лишних кругов?» Сервер может быть зеленым по всем графикам, а заявки при этом неделями лежат в очереди: их никто не берет в работу или они постоянно возвращаются на доработку.

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

Типичные проблемы, которые «невидимы» на уровне железа и сервисов:

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

Мониторинг бизнес-процессов переводит разговор с «у нас все работает» на «у нас проходит через процесс столько-то заявок с таким-то временем и качеством». Узкие места находятся быстрее: видно, на каком этапе копится хвост, где чаще происходят возвраты и как меняется ситуация после правок регламента.

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

С чего начать: выбрать процесс и границы измерений

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

Чтобы мониторинг работал, у процесса должны быть понятные границы: где он начинается и где заканчивается. Без этого «время согласования» каждый будет считать по-своему, а споры съедят весь эффект.

Как выбрать 1-2 процесса на старт

Оцените кандидатов по простым признакам. Хороший процесс для старта:

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

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

Зафиксируйте границы измерений простыми правилами

Запишите две фразы: «Старт = ...» и «Финиш = ...». Стартом может быть момент, когда заявка получила статус «Отправлена» (а не «Создана», если черновики висят неделями). Финишем - «Оплачено» или «Выполнено», в зависимости от того, что вы хотите контролировать.

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

И договоритесь заранее, что вы делаете с метриками. Пример простых правил:

• если 10% заявок «зависают» более чем на 48 часов на одном шаге, руководитель этапа раз в день разбирает очередь;
• если растет доля возвратов, обновляют форму и чек-лист для заявителя.

Данные и события: откуда брать факты для метрик

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

Обычно «следы процесса» можно найти там, где люди и так работают каждый день: в сервис-деске (инциденты и запросы), CRM (сделки и согласования), корпоративной почте (цепочки писем и ответы), таблицах (реестры заявок) и внутренних порталах (формы и маршруты). Даже если система одна, полезно смотреть не только на итоговый статус, но и на историю изменений и комментарии. Комментарии часто содержат причину возврата или уточнение, из-за которого заявка зависла.

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

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

Если есть возвраты, добавьте еще одно поле: причина возврата (список вариантов, а не свободный текст). Тогда доля возвратов будет понятной и сравнимой по подразделениям.

Главная ловушка - заставить людей заполнять лишнее вручную. Лучше забирать данные автоматически: фиксировать смену статуса как событие, подтягивать автора и время из системы, а причины возврата давать выбрать из короткого списка.

Например, при согласовании закупки рабочих станций или серверов (типичный кейс для ИТ и снабжения) возврат часто связан с неполным ТЗ или неверным бюджетом. Если это отмечается одним кликом, метрика становится надежной, а уведомления по зависшим заявкам перестают быть «шумом».

Три базовые метрики: определения без двусмысленностей

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

1) Время согласования

Это длительность пути заявки от понятного старта до понятного финиша. Частая ошибка - считать «как получилось в системе», не договорившись о правилах.

Начало обычно фиксируют в момент, когда заявка стала «готова к согласованию»: отправлена в работу, заполнены обязательные поля, приложены документы. Окончание - когда принято финальное решение (утверждено или отклонено), а не когда кто-то «посмотрел».

Отдельно решите, как считать паузы. Есть два удобных варианта:

• календарное время (как ощущает бизнес);
• активное время (как работает команда).

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

2) Доля возвратов

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

Чтобы метрика была управляемой, причины возврата нужно классифицировать. Не нужно 30 категорий. Хватает 4-5, которые реально ведут к разным действиям. Например: «неполные данные», «ошибка в сумме/номенклатуре», «не тот маршрут согласования», «нет основания/документа», «прочее».

Если 60% возвратов - «неполные данные», это сигнал улучшить форму и подсказки при создании заявки, а не «давить» на согласующих.

3) Зависшие заявки

«Зависшая» - это заявка, которая не меняла статус дольше допустимого времени на одном шаге. Важно измерять именно отсутствие движения, а не просто большой общий срок. Заявка может быть долгой, но живой: каждый день происходят действия.

Определите два параметра: какие статусы считаются «в ожидании действия» и через сколько часов или дней это становится проблемой. Простой пример: «На согласовании у руководителя» без изменений более 48 часов - зависание. Так вы ловите узкие места точечно, а не ругаете весь процесс целиком.

Нормы и пороги: как задать цели, которые работают

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

Для метрики «время согласования» удобнее начинать не со среднего, а с перцентилей. P50 (медиана) показывает типичное время, а P90 показывает, что происходит с «хвостом», где и прячутся задержки. На практике именно P90 чаще всего отражает боль: редкие, но громкие случаи.

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

Еще один источник споров - календарь. «24 часа» по стене и «24 рабочих часа» - разные вещи. Для согласований обычно честнее считать только рабочее время (например, 09:00-18:00 в будни). Тогда заявка, созданная в пятницу вечером, не будет выглядеть как катастрофа к понедельнику утром.

Чтобы выбрать первый целевой уровень и не обещать невозможное, начните с фактов за последние 2-4 недели и поставьте пороги чуть лучше текущей картины:

• снимите базу: текущие P50 и P90 по времени согласования;
• разделите на 2-3 категории (например, срочные и обычные, или по подразделениям);
• решите, считаете ли вы время только в рабочие часы;
• поставьте цель на шаг вперед (например, улучшить P90 на 10-20%, а не в 2 раза);
• зафиксируйте, что считается нарушением: «P90 за день выше порога» или «N заявок старше порога».

Пример: если у обычных заявок P50 сейчас 6 рабочих часов, а P90 - 2 рабочих дня, то разумная первая цель может быть P50 до 5 часов и P90 до 1,5 дня. Для срочных - отдельно: P50 до 1 часа и P90 до 4 часов. Такой подход дает понятные ожидания и создает основу для простых уведомлений без постоянного шума.

Как настроить простые алерты: пошаговая схема

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

Схема из пяти шагов

1. Сформулируйте, какой сигнал полезен и кому. Руководителю группы важно знать про заявки без движения; исполнителю полезнее напоминание о ближайшем дедлайне; владельцу процесса - резкий рост возвратов.

2. Выберите простое условие срабатывания. Начните с одного измерения: время в статусе (например, «На согласовании» более 48 часов), повторяемость события («возврат» больше 2 раз) или накопление очереди («ожидают назначения» больше 20 заявок). Сложные формулы часто дают спорные срабатывания.

3. Добавьте контекст, чтобы алерт можно было закрыть действием, а не перепиской. Минимум: номер заявки, текущий статус, кто ответственный сейчас, сколько времени прошло и что должно быть следующим шагом (например, «нужно назначить исполнителя» или «ожидается подпись руководителя»).

4. Определите канал и правила тишины. Одни уведомления уместны в почте, другие - в рабочем чате, третьи - только в ежедневной сводке. Задайте часы, когда алерты не приходят, и ограничьте частоту: например, не чаще одного сообщения по одной заявке в 4 часа.

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

Как быстро уменьшить «шум»

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

Дашборды и отчеты: кому какие цифры показывать

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

Руководителю: 3-5 цифр, которые показывают здоровье процесса

Руководителю не нужен список заявок. Ему важно понимать, где процесс теряет время и качество. На одном экране обычно достаточно 3-5 показателей: тренд времени согласования (по неделям), доля возвратов, доля просрочек и объем входящего потока. Полезно добавить топ-3 причин возвратов (по выбранным категориям), чтобы разговор быстро переходил от эмоций к действиям.

Показывайте не только среднее время, но и медиану или 75-й процентиль. Среднее легко «портят» редкие случаи, а процентиль честнее отвечает на вопрос: как бывает у большинства.

Исполнителям: что зависло и что делать прямо сейчас

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

Чтобы это работало, добавьте к каждой заявке короткие подсказки: где застряла (этап), сколько часов в статусе, что нужно для движения (комментарий, документ, согласование).

Ежедневный короткий отчет: только то, что требует решения

Ежедневный отчет полезен как утренний «пульс». Он должен отвечать на три вопроса: что уже просрочено, что на грани просрочки и где нужна помощь руководителя. Обычно хватает трех блоков:

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

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

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

Пример из практики: согласование заявок в организации

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

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

Полезный минимум:

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

Алерты лучше держать короткими и однозначными:

• «Заявка зависла»: нет изменения статуса на конкретном шаге дольше X часов (для юристов и ИБ пороги часто разные).
• «Повторный возврат»: заявку вернули на доработку второй раз подряд.
• «Порог по циклу»: общий срок согласования превысил Y дней, даже если на каждом шаге «почти нормально».

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

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

Частые ошибки и ловушки при мониторинге процессов

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

Вот ловушки, которые встречаются чаще всего:

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

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

Несколько правил, которые помогают не наступить на эти грабли:

• начните с 2-3 метрик, которые можно объяснить одной фразой и привязать к действию;
• зафиксируйте определения письменно: от какого события до какого считаем, что исключаем, какие статусы валидны;
• у каждого алерта должен быть владелец и простое действие: «проверить», «эскалировать», «вернуть с комментарием»;
• договоритесь о гигиене данных: обязательные поля, список причин возврата, запрет пустых статусов;
• подавайте метрики как повод улучшить этап, а не как поиск виноватого.

Так вы быстрее получите доверие к цифрам и сможете управлять процессом, а не спорить о том, кто как «правильно» считает время.

Короткий чек-лист и следующие шаги

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

Быстрый чек-лист перед запуском

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

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

План на 30 дней, чтобы не застрять

Сделайте пилот на одном процессе и доведите его до привычки в работе:

• дни 1-7: выбрать процесс, зафиксировать определения, включить сбор событий;
• дни 8-14: настроить 2-3 метрики и простые пороги, прогнать на исторических данных;
• дни 15-21: включить алерты ограниченной группе, убрать шум, добавить контекст;
• дни 22-30: закрепить владельца, ритуал проверки (например, 10 минут в день), устранить первые 3-5 повторяющихся причин задержек.

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

Если нужна интеграция с текущими системами, подготовка инфраструктуры под сбор событий и поддержка 24/7, это можно обсудить с GSE.kz (gse.kz) как с системным интегратором, чтобы мониторинг процессов стал рабочим инструментом управления, а не отчетом «для галочки».