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

Что такое операционные узкие места и зачем их отслеживать

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

Что считать «узким местом» на практике

Узкие места обычно проявляются в четырёх формах:

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

Важно: узкое место — не «плохой сотрудник» и не разовая авария. Это повторяющийся паттерн, который можно измерить, локализовать и улучшить.

Какие ответы должно дать приложение

Веб‑приложение для поиска узких мест ценно тем, что превращает ощущения в конкретику:

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

Результат — решения опираются на данные о потоке работ, а не на самые громкие инциденты.

Для каких процессов это подходит

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

• обработка заявок (продажи, кредитование, закупки, HR);
• производство и контроль качества;
• склад (приёмка, комплектация, отгрузка);
• поддержка и сервисные обращения;
• доставки и логистика.

Главное условие: можно зафиксировать события (переходы статусов, время начала/окончания шагов) и причины остановок.

Ключевой результат проекта

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

Цели, роли и границы процесса: с чего начать

Приложение для поиска узких мест не начинается с дашборда — оно начинается с согласованных целей. Если команда по‑разному понимает «что считаем задержкой» и «как считаем время», метрики будут спорными, а выводы — недоверенными.

Определите пользователей и их решения

Сначала перечислите роли и то, какие решения они должны принимать с помощью продукта:

• Руководители: увидеть, где теряется время и деньги, и какие изменения дадут эффект.
• Аналитики: проверить гипотезы (например, влияние смен, типов заявок, поставщиков), подготовить отчёт.
• Исполнители: понимать приоритеты, устранять повторяющиеся «затыки», корректно фиксировать причины задержек.
• Диспетчеры/координаторы: управлять очередями, перераспределять нагрузку, предотвращать просрочки.

Для каждой роли зафиксируйте решения, которые человек принимает ежедневно. Это удерживает продукт от превращения в «витрину KPI» без действий.

Сформулируйте 5–10 ключевых вопросов

Соберите короткий список вопросов, на которые продукт обязан отвечать без ручных выгрузок, например:

• На каком этапе заявки чаще всего застревают и сколько времени теряем?
• Какие причины задержек встречаются чаще всего?
• Какие типы работ/каналы поступления создают пики нагрузки?
• Кто перегружен, а кто недозагружен по сменам?
• Как изменились узкие места после правок регламента или распределения?

Эти вопросы станут «проверкой» для всех дальнейших решений — от модели данных до визуализаций.

Задайте границы процесса (и смело «отрезайте лишнее»)

Опишите процесс как маршрут:

• Старт/финиш: что считается началом (создание заявки, поступление звонка, оплата) и что считается завершением (закрытие, отгрузка, подтверждение качества).
• Этапы и статусы: какие переходы фиксируем, какие статусы считаем «в работе», а какие — «ожидание».
• Роли и ответственные: кто принимает, кто исполняет, кто согласует.
• Каналы поступления: почта, телефония, чат, интеграция из другой системы — всё это влияет на поток работ.

Согласуйте время и правила расчёта

Узкие места часто «появляются» из‑за разных трактовок времени. Сразу договоритесь:

• считаем ли рабочие часы или календарные;
• как учитываем смены, праздники, выходные;
• что делаем с паузами «ожидание клиента/поставщика»;
• какие SLA и пороги считаем просрочкой.

После этого у команды появляется общий язык — и только тогда имеет смысл строить мониторинг процессов и дашборды KPI.

Метрики, которые действительно выявляют узкие места

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

Время цикла vs. ожидание vs. обработка

Время цикла (cycle time) — сколько проходит от «взяли в работу» до «готово». Оно хорошо отражает клиентскую скорость, но само по себе не объясняет причину.

Разложите его на две части:

• Время ожидания (waiting time): задача стоит в очереди, ждёт согласования, данных или слота у специалиста.
• Время обработки (processing time): фактическая активная работа.

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

WIP и очереди: ранний сигнал перегруза

WIP (work in progress) — сколько элементов одновременно «в процессе». Высокий WIP почти всегда означает переключение контекста и рост ожидания.

Отслеживайте не только WIP по всему потоку работ, но и размер очереди перед конкретным этапом (сколько задач ждут конкретную роль/команду). Резкий рост очереди — прямой признак формирующегося узкого места.

Пропускная способность по этапам и по командам

Throughput показывает, сколько единиц работы реально завершается за период.

Смотрите в разрезе:

• по этапам (где «выпуск» минимальный),
• по командам/ролям,
• по типам задач (инциденты, запросы, изменения).

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

SLA и распределение задержек

Один процент просрочки не раскрывает картину. Добавьте:

• долю просрочки (сколько задач нарушили срок),
• распределение задержек (насколько именно опаздывают: на 1 день или на 2 недели).

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

Качество и нагрузка ресурсов

Чтобы не «ускоряться» ценой брака, фиксируйте:

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

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

Сбор данных: события, статусы и причины задержек

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

Событийная модель: что логировать

Ориентируйтесь на небольшое, но стабильное ядро событий. Обычно достаточно четырёх типов:

• Статус изменился (например, «в работе» → «на согласовании»).
• Работа назначена (изменился исполнитель/команда).
• Этап завершён (веха процесса, влияющая на SLA).
• Комментарий/причина задержки зафиксированы (см. ниже).

Событие должно быть неизменяемым (append-only). Если что-то исправили — пишите новое событие «коррекция», а не переписывайте старое.

Минимальный набор полей

Даже если источников несколько, для аналитики узких мест нужен общий «скелет» записи:

• id объекта (заказ/тикет/заявка) и, при необходимости, id события;
• этап/статус (как было и как стало) или тип вехи;
• актор (кто сделал действие: пользователь, роль или системный процесс);
• время события (timestamp) и часовой пояс/смещение;
• источник (какая система прислала событие, версия интеграции).

Этого достаточно, чтобы считать длительности по этапам, очереди, передачу между ролями и отклонения по времени.

Причины задержек: справочник + комментарии

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

Хорошее правило: требуйте причину только при нарушении SLA или при переводе в статус «Ожидание», иначе пользователи начнут выбирать случайные варианты.

Как жить с «грязными» данными

Реальные события приходят с проблемами: пропуски, задвоения, неверные таймзоны.

• Пропуски: помечайте как unknown и показывайте долю таких записей на дашборде качества данных.
• Задвоения: вводите ключ идемпотентности (например, source_event_id) и делайте дедупликацию по окну времени.
• Таймзоны: храните время в UTC, отдельно — исходную зону/смещение, и нормализуйте при импорте.

Чем раньше вы формализуете эти правила, тем меньше «ложных узких мест» появится в отчётах.

Интеграции и импорт: как подключить реальные системы

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

Какие источники подключать в первую очередь

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

• Таск‑трекер: статусы задач, исполнитель, срок, комментарии, теги.
• CRM/ERP: заказы, этапы сделки, счета, отгрузки, статусы согласования.
• Почта/чат: входящие запросы, время ответа, эскалации (часто через экспорт или журналы).
• Формы (заявки, рекламации): структура полей, время подачи, маршрут обработки.
• Датчики/сканеры: штрих‑коды, проходы по точкам, события на оборудовании.

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

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

• API — лучший вариант для точности и контроля: можно забирать изменения, справочники и детали объектов.
• Вебхуки — удобны, когда нужна скорость: система сама отправляет событие при изменении статуса.
• Выгрузки (CSV/Excel) — быстрый старт для MVP и исторических данных.
• Чтение логов — подходит для внутренних систем и оборудования, где API нет, но есть журналы событий.

Часто используют гибрид: история — через выгрузку, новые изменения — через API/вебхуки.

Стратегия обновления: near‑real‑time или пакетно

Near‑real‑time полезен для алертов и диспетчеризации (минуты). Пакетная загрузка проще и дешевле для управленческой аналитики (час/день). Критерий выбора — насколько быстро вы должны реагировать на задержку и сколько стоит «устаревший» дашборд.

Как связать объекты между системами

Самая частая причина «битой» аналитики — неверная идентификация.

• Используйте единый ключ (номер заказа/заявки) там, где возможно.
• Введите маппинг (таблица соответствий) для случаев «ID разные, смысл один».
• Поддерживайте справочники (контрагенты, склады, команды) с правилами нормализации названий.

Зафиксируйте эти правила в одном месте — и подключение новых источников станет предсказуемым, а метрики — сопоставимыми.

Модель данных и хранение: база для аналитики и скорости

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

Выбор хранилища: транзакции vs аналитика

На практике удобно разделить два слоя:

• Реляционная БД (для веб‑приложения и API): хранит «истину» по объектам процесса (заказы, заявки, обращения), их текущие статусы, справочники, права доступа. Здесь важны целостность и быстрые точечные запросы.
• Аналитическое хранилище (или витрины): хранит события и агрегаты для отчётов. Здесь важны дешёвые сканы больших объёмов и быстрые группировки.

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

Схема: объекты, события и версии

Минимальный набор сущностей обычно выглядит так:

• Объект процесса (например, ticket): идентификатор, тип, приоритет, клиент/подразделение.
• Этап/статус: нормализованный справочник статусов, а не произвольный текст.
• Событие: смена статуса, назначение исполнителя, комментарий, пауза/возобновление. Событие — главный источник расчёта длительностей.
• Причина задержки: справочник + связь с событием/интервалом (важно для аналитики «почему»).
• Версионирование: храните версии справочников и правил (например, изменились SLA или названия статусов), чтобы исторические отчёты не «ломались».

Агрегации и витрины для дашбордов

Чтобы дашборды открывались быстро, используйте предрасчёты:

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

Так вы не будете каждый раз пересчитывать большие объёмы событий при открытии /dashboard.

Политика хранения: срок, архив, удаление

Заранее определите:

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

Чёткая политика хранения снижает риски и держит стоимость инфраструктуры под контролем.

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

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

Главный экран: здоровье процесса

Главный экран удобно строить как сводку состояния потока работ за выбранный период (например, сегодня/7 дней/30 дней): текущие очереди, просрочки и тренды. Полезная структура:

• Индикатор здоровья процесса: доля заявок в SLA, медианное время цикла и изменение к прошлому периоду.
• Текущие очереди: где копится WIP и на каких этапах растёт ожидание.
• Просрочки: количество и «вес» (например, стоимость простоя или приоритет).
• Тренды: как меняется throughput (выпуск) и время прохождения по неделям.

Выделяйте цветом только отклонения от нормы, а «норму» объясняйте прямо на экране (подписью или подсказкой).

Разрезы: чтобы увидеть, где именно узко

Узкие места часто видны только в разрезе. Сделайте переключатели и фильтры:

• по этапам процесса (где время ожидания максимальное),
• по командам (перегруз, дисбаланс нагрузки),
• по продуктам/типам работ (разные профили сложности),
• по регионам и каналам (разные правила и сезонность).

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

Визуализации: что выбирать под задачу

• Контрольные графики (control charts): показывают стабильность времени цикла и помогают отличать «шум» от реальной проблемы.
• Распределения (гистограмма/box plot): полезны, когда среднее «врёт» из‑за длинного хвоста задержек.
• Воронки: где теряются заявки или где они «застревают» между шагами.
• Канбан‑поток (cumulative flow): наглядно показывает рост очередей и перекосы между этапами.

Дрилл‑даун: от графика к конкретной заявке

Любая тревожная точка на графике должна вести к списку объектов (заявка/партия/заказ), а дальше — к карточке с историей событий: смена статусов, ответственные, комментарии, причины задержек.

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

Алерты и реакции: когда система должна поднимать тревогу

Алерты нужны не для «проверки пульса» системы, а чтобы вовремя остановить рост очередей и просрочек. Хороший алерт отвечает на два вопроса: что именно стало плохо и что делать прямо сейчас.

Правила алертов: пороги по очереди, времени ожидания и доле просрочки

Начните с 3–5 самых понятных сигналов, которые напрямую связаны с узкими местами:

• Очередь в статусе/этапе: например, «в обработке» > 120 задач или рост очереди > 20% за час.
• Время ожидания (age): 95-й перцентиль ожидания на этапе > 6 часов, либо медиана выросла в 2 раза относительно последней недели.
• Доля просрочки: > 8% задач в этапе превысили SLA/дедлайн.

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

Дедупликация и «тишина»: чтобы уведомления не превращались в шум

Если алерт начинает срабатывать десятками раз, команда перестаёт реагировать. Рабочие практики:

• Дедупликация по ключу: (процесс + этап + тип сигнала). Пока инцидент «открыт», новые события не создают новые уведомления, а обновляют текущее.
• Окна тишины (cooldown): повторная отправка не чаще, чем раз в 15–30 минут, если проблема не решилась.
• Эскалация вместо спама: если алерт активен 60 минут, повышайте уровень критичности и подключайте следующую роль.
• Снижение ложных срабатываний: требуйте, чтобы условие держалось 2–3 интервала подряд (например, 10–15 минут), особенно для метрик с шумом.

Каналы доставки: почта, мессенджеры и веб‑уведомления

Обычно достаточно трёх каналов:

• Почта — для предупреждений и ежедневных/еженедельных дайджестов.
• Мессенджеры — для критичных алертов с быстрым подтверждением («взято в работу»).
• Веб‑уведомления внутри приложения — для оператора/тимлида, который уже работает в системе.

Держите принцип: один алерт — одно короткое сообщение с ссылкой на конкретный разрез в интерфейсе (например, /alerts/123 и /queues?stage=review).

Плейбуки: что делать при срабатывании

Каждый алерт должен иметь плейбук (2–6 шагов), иначе он не ускоряет реакцию. Минимальный шаблон:

1. Проверить контекст: какой этап, какая очередь, сколько задач и сколько «просрочено».
2. Диагностика: топ‑3 причины задержек (если вы их собираете), список «самых старых» задач.
3. Действие: перераспределить нагрузку, временно изменить приоритеты, подключить дежурного.
4. Ответственный и SLA реакции: кто подтверждает алерт и за сколько минут.

Так система превращается из «табло с метриками» в инструмент управления узкими местами в реальном времени.

Права доступа, безопасность и соответствие требованиям

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

Ролевой доступ: минимум прав по умолчанию

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

Практичный подход:

• Операторы/исполнители: видят только свои задачи и необходимый контекст.
• Руководители: видят KPI и узкие места по команде без лишних персональных полей.
• Аналитики: доступ к событиям и причинам задержек, но с ограничениями по персональным данным.
• Администраторы: управление справочниками и интеграциями, но с обязательным аудитом.

Аудит действий: кто и что изменил

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

Логируйте как минимум: изменения прав и ролей, правки справочников (этапы, причины), ручные правки событий/статусов, импорт/выгрузки, входы в систему и ошибки авторизации. В аудите храните идентификатор пользователя, время, объект изменения и значения «до/после».

Обезличивание и минимизация данных

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

Безопасность интеграций: токены и контроль прав

Интеграции — частый источник утечек. Используйте короткоживущие токены, ротацию ключей и отдельные учётные записи с минимальными правами (read-only там, где возможно). Ограничьте IP, включите rate limiting, шифруйте секреты в хранилище секретов и регулярно проверяйте права доступа интеграций.

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

Архитектура и качество: чтобы приложение работало стабильно

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

Производительность: где обычно теряется время

Основные задержки в таких системах возникают не в интерфейсе, а в запросах к хранилищу и пересчётах.

• Индексы и партиционирование: индексируйте поля фильтрации (дата события, процесс/очередь, статус, исполнитель, объект «заказ/тикет»). Для больших объёмов полезны партиции по времени.
• Кэш: кэшируйте тяжёлые агрегаты (например, «время в статусе по неделе») и результаты популярных фильтров. Важно задать понятную стратегию инвалидирования.
• Предрасчёт витрин: для дашбордов лучше готовить агрегированные таблицы/витрины (день/неделя/месяц, по процессу и типу работы), чем каждый раз пересчитывать «сырые» события.
• Очереди задач: вынесите импорт, нормализацию и пересчёты в фоновые задачи, чтобы UI оставался отзывчивым.

Надёжность: данные должны грузиться повторяемо

Импорт и ETL почти всегда дают сбои: сеть, лимиты API, дубляж, «переигранные» статусы. Критично заложить:

• Идемпотентность: повторная загрузка того же диапазона не должна удваивать события. Используйте стабильные ключи (source_id + timestamp + type) и upsert.
• Повторяемые загрузки: ретраи с экспоненциальной паузой, сохранение чекпоинтов (до какого момента дочитали), dead-letter очередь для проблемных сообщений.
• Контроль качества данных: проверки на пропуски статусов, отрицательные длительности, некорректные временные зоны, «висящие» объекты без закрытия.

Наблюдаемость: чтобы понимать, что сломалось

Добавьте метрики сервиса (время ответа, очередь задач, скорость импорта), логи с корреляционными ID и трассировки для длинных цепочек (импорт → обработка → витрина → отчёт).

Определите SLO для отчётов: например, «95% запросов дашборда до 2 секунд» и «витрина обновляется не реже, чем раз в 15 минут».

Тестирование: особенно для расчётов

Помимо юнит‑тестов на парсинг и маппинг, нужны:

• Интеграционные тесты для импорта/очередей/БД.
• Тесты корректности метрик: заранее подготовленные наборы событий и ожидаемые значения (lead time, время в статусах, WIP). Это защищает от незаметных ошибок в бизнес‑логике при изменениях схемы или правил.

Внедрение и развитие: от MVP до масштабирования

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

MVP: один процесс и один понятный дашборд

Для MVP выберите один наиболее заметный процесс (например, обработка заявок) и опишите его как цепочку из 3–5 этапов. Важно, чтобы этапы были понятны исполнителям и отражали реальные переходы.

В MVP достаточно базовых метрик и одного дашборда:

• время цикла (от старта до завершения);
• WIP (сколько объектов «в работе» одновременно);
• доля просрочки по SLA/дедлайну;
• время ожидания между этапами.

Дашборд должен отвечать на один вопрос: «Где сейчас тормозит поток и на каком этапе это началось?» — без перегруженных графиков.

Практический способ ускорить первый релиз — собрать прототип в TakProsto.AI: описать процесс и метрики в чате, получить каркас веб‑приложения (React), API на Go и базу PostgreSQL, а затем итеративно добавить импорт событий, витрины и роли доступа. Это удобно, когда нужно быстро проверить гипотезы на реальных данных, а позже — экспортировать исходники и развивать решение внутри команды.

Пилот: обучение и настройка метрик под реальность

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

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

Карта улучшений: что развивать дальше

После пилота сформируйте понятный бэклог развития:

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

Как измерить эффект: сравнение до/после

Эффект подтверждайте измерениями: сравните «до/после» по времени цикла, доле просрочки и WIP. Закрепите период сравнения (например, 4 недели) и не меняйте определения метрик в середине — иначе выводы будут спорными.