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

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

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

Сводный дашборд помогает выбрать процесс, который требует разбора

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

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

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

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

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

Поэтапный дашборд разделяет время работы и ожидания

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

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

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

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

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

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

Дашборд очереди показывает, где работа накапливается быстрее, чем завершается

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

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

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

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

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

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

Разрезы по типам заказов помогают объяснить причину задержки

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

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

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

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

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

Дашборд возвратов показывает, где процесс заставляет выполнять работу повторно

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

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

Допустим, из 120 заказов за сопоставимый период 36 хотя бы раз вернулись на доработку. Доля таких заказов составляет 30%, но самих возвратов может быть больше, если некоторые документы возвращались неоднократно. Поэтому на дашборде стоит отдельно показывать количество затронутых заказов и количество повторных операций.

После выбора причины «Не хватает исходных данных» станет видно, какое поле или документ чаще отсутствует при передаче. Если расчёт возвращают из-за изменения требований клиента, полезно открыть момент изменения и проверить, когда эта информация стала доступна сотрудникам. Место, где документ остановился, и место, где возникла причина остановки, могут находиться на разных этапах.

Сам повтор ещё не означает лишнюю работу: для части заказов повторная проверка предусмотрена процессом. В дашборде я бы разделял обязательные повторные действия и исправления, чтобы сокращение числа возвратов не достигалось за счёт пропущенного контроля. Анализ длительности, ожидания и повторных действий также используется в обзоре процесса Microsoft Process Mining.

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

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

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

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

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

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

История событий определяет, что дашборд сможет объяснить

Чтобы раскрыть задержку до конкретных действий, дашборду нужна история процесса. Для каждого заказа сохраняются его идентификатор, события, даты и ответственные; для анализа работы и ожидания дополнительно требуются соответствующие временные отметки. Идентификатор экземпляра процесса, название действия и время события входят и в базовые требования к данным для анализа процессов в Microsoft Power Automate.

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

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

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

После изменения процесса дашборд должен показать результат по всему пути

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

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

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

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

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

Пишу о BI, данных и управлении в телеграм-канале: https://t.me/smart3asy

Наш сайт https://smarteasybi.com