Прозрачность начинается с одинаково фиксируемых событий
Если один отдел считает заказ принятым после оплаты, второй - после подтверждения менеджера, а третий - после создания карточки, их отчёты будут рассказывать о разных событиях. Сначала договоритесь, какие переходы действительно меняют состояние процесса: создано, принято владельцем, начато, отправлено на согласование, возвращено, завершено. Для первого разбора можно выделить 5-10 ключевых событий, но число определяется маршрутом, а не нормативом
Пять блоков панели собственника
Поток
сколько вошло, сколько вышло, как меняется выпуск
Очередь и возраст
сколько незавершённого и сколько времени лежат самые старые элементы
Качество
возвраты, переделки, ошибки, доля первого прохода
Деньги
стоимость обработки, потери, маржа или ценность потока
Исключения
что вышло за порог и требует решения, а не просто наблюдения
Эти пять блоков - рабочая структура для обсуждения, а не обязательный набор для любого бизнеса. В рекомендациях APQC выбор показателей связан с целью и границами процесса, надёжностью данных и решениями, которые по ним принимают. Начните с этого, а не с заданного количества метрик [1]
Пример страницы собственника
Пример ниже не содержит клиентских данных. Частота просмотра зависит от скорости процесса и цены ошибки: критичное отклонение не должно ждать еженедельного отчёта только потому, что относится к качеству
| Блок | Основная метрика | Поддерживающие | Когда смотреть |
|---|---|---|---|
| поток | выход в день/неделю | вход, остаток, доля завершения одной группы задач | по ритму бизнеса |
| очередь | возраст старейшей работы | объём очереди, распределение по возрасту | ежедневно при быстрых процессах |
| качество | доля первого прохода | типы возвратов | еженедельно |
| деньги | стоимость единицы | затраты на исключения | месяц/неделя |
| исключения | число за порогом | владелец, срок, ущерб | по событию |
На узком экране таблицу можно прокручивать по горизонтали
Самопроверка: насколько процесс вообще наблюдаем
Авторская самооценка, не аудит качества данных. «Нет» = 0, «частично» = 1, «да» = 2. Сумма используется только как краткое резюме ответов: хороший ответ по одному пункту не закрывает пробел в другом. «Не проверено» не получает балл. Для ответа «да» должна быть проверка на реальных задачах, а не только наличие нужного поля в системе
Чего собственнику не нужно видеть постоянно
Собственнику нужен обзор работы и понятный путь к деталям при отклонении, а не постоянный список действий каждого сотрудника. Например, документация Microsoft показывает визуализацию записей действий и времени работы в приложениях. Это один способ исследования задачи, но такой отчёт сам по себе не становится картиной всей компании [2]
- не выводите показатель, если непонятно, какое решение он меняет
- не смешивайте показатели разных периодов и определений
- не заставляйте руководителя искать отклонение в таблице из сотен строк
- не ограничивайтесь средним: добавьте распределение возраста, самые старые незавершённые задачи и отдельно объясните известные исключения
Как связать прозрачность с данными и ранними сигналами
Если руководители спорят, какой отчёт правильный, сначала нужен единый источник правды и понятное происхождение показателей. Если данные уже прозрачны, следующий уровень - ранние сигналы, которые предупреждают о проблеме до финансового ущерба
Источники и границы выводов
Пять блоков панели, таблица и шкала самооценки - рабочие инструменты статьи. Они не являются нормативом APQC или Microsoft и не подтверждают наблюдаемость по одной сумме баллов
- APQC: выбор показателей процесса. Открытая рекомендация о целях, границах, надёжности и полезности показателей. Не задаёт норматив для пятиблочной панели и пороги этой самооценки
- Microsoft Learn: визуализация записей действий в Power Automate. Документация по анализу записей задач и использованию приложений. Это более узкий материал, чем сквозной анализ событий всех корпоративных систем
