Обзор и аналитика

Назначение

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

Группа меню Аналитика — раздел «Аналитика» (/analytics) — сводная аналитика производства за произвольный период: план/факт выпуска, незавершённое производство, брак, а также блок «Эффективность и качество» (вкладки OEE, TPM, SPC) и вкладка WIP-лимитов. Если дашборд отвечает на вопрос «что нужно сделать прямо сейчас», то «Аналитика» отвечает на вопрос «как участок или производство в целом работали за период».

Кто использует (роли)

• Обзор (/) виден любому авторизованному оператору — прав на сам раздел не требуется. Но у дашборда нет собственных данных: каждый виджет — отдельный запрос к API того раздела, который он отображает, и подчиняется его правам. Если у оператора нет права на какой-то виджет (например, «Брак за 7 дней» требует qc.write), этот виджет просто не появляется в списке «Добавить виджет» — весь дашборд при этом не ломается и не показывает ошибку.
• Аналитика (/analytics) требует право production-board.view — Мастер участка и Диспетчер (см. таблицу ролей в Начало работы). Это право проверяется один раз на уровне роутера /api/analytics/*; внутри раздела дополнительных проверок по вкладкам нет, кроме одной: управлять WIP-лимитами (менять число, открывать/закрывать интервалы состояния участка) может только тот, у кого есть scheduler.manage — без него вкладки WIP и TPM показывают данные только для чтения, без формы редактирования.

Основные понятия

Обзор — настраиваемый дашборд (/)

Что видно

Заголовок «Обзор» и кнопка «Добавить виджет» справа. Ниже — свободная сетка (react-grid-layout, 12 колонок) с карточками-виджетами. У каждой карточки в заголовке — «ручка» для перетаскивания (иконка GripVertical, весь заголовок целиком — зона захвата) и крестик «Убрать виджет» справа; сама карточка тянется за правый нижний угол для изменения размера. Клик по кнопке «Добавить виджет» открывает выпадающий список виджетов, которых ещё нет на дашборде и на которые у оператора есть право («Все доступные виджеты уже добавлены», если добавлять больше нечего).

Каталог виджетов (widgetRegistry.ts) — три типа карточек:

• Плитки (число + подпись, часто с подстрокой и цветовой пометкой тревоги) — кликабельны целиком, ведут в соответствующий раздел:
  • «Заказы в производстве» (orders.view) — заказы не в статусах draft/done/canceled; красным — сколько из них просрочено.
  • «К сдаче на участках» (work-records.view) — количество позиций в списке работ, ожидающих сдачи.
  • «Приход, не оприходовано» (arrivals.view) — необработанные приходные документы.
  • «Лимитные карты на исходе» (limit-cards.view) — открытые лимитные карты, у которых срок действия истекает в течение 7 дней.
  • «Заказы клиентов: риск срока» (customer-orders.view) — строки заказов клиентов под риском срыва срока; отдельно выделены уже просроченные.
  • «Брак за 7 дней» (qc.write) — отклонённые ОТК-записи за последние 7 дней из общего числа проверок за тот же период.
  • «Дефицит материалов» (scheduler.view) — число позиций с дефицитом обеспеченности (из сводки Управления потоком).
  • «Просроченные операции» (work-assignments.view) — сменные задания прошлых дат, ещё не выполненные и не отменённые; отдельно — сколько из них уже «в работе».
  • «Узкое место» (scheduler.view) — участок-кандидат в ограничение потока (наибольшая очередь), часы в очереди и загрузка в процентах.
  • «Простои оборудования сегодня» (scheduler.view) — суммарное время простоя+ремонта по всем участкам за сегодня и число ремонтов.
  • «Незакрытые несоответствия» (qc.write) — открытые записи несоответствий и суммарное количество, ожидающее решения.
  • «Закупки требуют внимания» (provision.view) — заявки на закупку в статусах «черновик»/«согласована» + просроченные поставки по открытым заказам поставщикам.
  • «План / факт выпуска сегодня» (production-board.view) — фактический выпуск за сегодня, % выполнения плана и плановое количество.
  • «Мои задачи» (work-records.view) — задания из списка работ, назначенные лично на сотрудника, привязанного к текущему оператору (если оператор не привязан к сотруднику — виджет покажет 0 с соответствующей подсказкой).
• Графики (recharts, столбчатые):
  • «Заказы по статусам» (orders.view) — число заказов по каждому статусу, те же цвета, что и в канбан/диаграмме Ганта.
  • «ОТК за 7 дней» (qc.write) — принято/брак за последние 7 дней.
  • «Загрузка участков» (scheduler.view) — топ-8 участков по загрузке (load_ratio), перегруженные (≥100%) выделены красным.
• Список: «Последние события» (parts.view) — 8 последних записей журнала действий (дата/время, действие, детали, кто сделал); клик по списку открывает полный журнал.

Первый вход (нет сохранённой раскладки) показывает фиксированный набор из 6 плиток — «Заказы в производстве», «К сдаче на участках», «Приход, не оприходовано», «Лимитные карты на исходе», «Заказы клиентов: риск срока», «Брак за 7 дней» — это тот же набор, что показывал более ранний нередактируемый дашборд; остальные виджеты — опциональны, через «Добавить виджет».

Типовые сценарии

1. Ежедневный обзор. Оператор открывает «Обзор» — видит 6 плиток по умолчанию, кликает на плитку с тревожным цветом (например, «Просрочено: N» под «Заказы в производстве»), попадает в раздел «Заказы» уже с представлением, куда нужно.
2. Настроить дашборд под свою роль. Диспетчер добавляет «Узкое место», «Загрузка участков», «Дефицит материалов», убирает неактуальные для себя плитки («Лимитные карты на исходе»), перетаскивает график «Заказы по статусам» наверх — раскладка сохраняется автоматически (с задержкой ~300 мс после последнего изменения) и восстанавливается при следующем входе под тем же логином.
3. Общий терминал, разные операторы. На разделяемом ПК Мастер участка и Диспетчер входят по очереди под своими логинами — у каждого своя раскладка (ключ в localStorage включает operator.id), они не перезаписывают друг друга.

Особенности и ограничения

• Раскладка хранится только в браузере (localStorage), не на сервере — переход на другой компьютер или очистка данных браузера обнуляет настройку дашборда до значений по умолчанию.
• Если сохранённая раскладка ссылается на виджет, которого больше нет в каталоге (убрали при разработке), или на виджет, на который у оператора больше нет права (сменилась роль), такая запись молча отбрасывается при загрузке — карточка не показывается пустой/сломанной.
• У каждого виджета — собственный независимый запрос к API; сбой одного виджета (сеть, 403 и т.п.) показывает «—» только в этой плитке, остальной дашборд продолжает работать.
• Часть виджетов делает несколько последовательных запросов (например, «Простои оборудования сегодня» запрашивает показатели по каждому участку отдельно) — при большом числе участков это соответственно медленнее простой плитки.

Аналитика — вкладка «Производство» (/analytics)

Что видно

Фильтры сверху: период «С» / «По» (по умолчанию — последние 14 дней) и выбор участка (или «Все участки»). Ниже:

• 4 KPI-карточки: Фактический выпуск (с плановым числом под ним), Выполнение плана (%), Просрочено заказов (среди активных), Уровень брака (% от проверенного ОТК за период) — просроченные заказы и брак >0 подсвечены цветом тревоги.
• План / факт выпуска — столбчатый график по дням периода (плановое и фактическое количество друг на друге).
• НЗП по этапам — горизонтальные полосы: сколько шагов маршрута сейчас «Ожидает запуска» / «В работе» / «Выполнено» (только по активным заказам — не done/canceled/draft).
• Pareto брака — виды брака по убыванию количества за период.
• Требует внимания — таблица заказов с проблемой срока: колонки Заказ, Изделие, Срок, Готовность (%), Причина («Срок просрочен» — красным, «Срок в выбранном периоде» — жёлтым, если готовность <100%). Клик по номеру заказа открывает карточку заказа. Список ограничен 50 строками, отсортирован — сначала просроченные, затем по возрастанию срока.

Типовые сценарии

1. Отчёт за смену/неделю мастеру участка. Выбрать свой участок и нужный период → посмотреть % выполнения плана и список «Требует внимания», чтобы понять, какие заказы нужно подтолкнуть в первую очередь.
2. Диспетчер ищет причину срыва плана. Смотрит «План / факт» — где именно просел факт, переключается на «НЗП по этапам», чтобы увидеть, не скопилось ли НЗП на конкретном статусе (например, много «Ожидает запуска» — узкое место на входе в участок).
3. Отслеживание качества. Pareto брака за месяц показывает доминирующий вид брака — повод завести разговор с участком или пересмотреть техпроцесс.

Особенности и ограничения

• Период ограничен 366 днями за один запрос — бэкенд отклонит более широкий диапазон ошибкой 422.
• «Требует внимания» и «Просрочено заказов» считаются только по активным заказам (не draft, не done, не canceled); черновики (ещё не запущенные в производство) в аналитику производства не попадают — по смыслу они не в производстве, см. Производство и планирование про жизненный цикл заказа.
• При выборе конкретного участка все счётчики (НЗП, «Требует внимания», список участков в фильтре) пересчитываются относительно шагов маршрута именно на этом участке — сводка меняет смысл, а не просто фильтрует таблицу.
• «Уровень брака» считается по количеству, проверенному ОТК за период (quantity в QcRecord), а не по количеству, сданному на участке — если ОТК отстаёт от сдачи, показатель за текущие дни будет занижен.

Аналитика — вкладки OEE / TPM / SPC («Эффективность и качество»)

Общий блок фильтров: выбор участка (обязателен — без него вкладки OEE и TPM показывают подсказку выбрать участок) и период «С»/«По» (по умолчанию — 30 дней), кнопка «Обновить». SPC использует тот же период, но участка не требует — у неё свой фильтр (параметр контроля).

OEE — что видно

• Круговой индикатор (OeeGauge) с итоговым % OEE — цвет зависит от значения (зелёный ≥85%, жёлтый ≥60%, красный ниже); подпись рядом расшифровывает формулу: «OEE = доступность × производительность × качество».
• KPI-карточки: Доступность (%, с подстрокой «X из Y мин учтено»), Производительность (%, «норма-время / время в работе»), Качество (%), MTBF / MTTR (часы, число ремонтов) — карточка MTBF/MTTR подсвечивается предупреждением, если за период были ремонты.
• Учтённое время — горизонтальная полоса, поделённая на сегменты «В работе» / «Простой» / «Переналадка» / «Ремонт» с легендой (минуты и %).
• Потери (Парето) — те же не-«в работе» интервалы, отсортированные по длительности, с отметкой «80% потерь выше черты» (классический ABC-срез потерь).
• Если OEE не удалось посчитать (нет интервалов состояния или рабочих записей за период) — вместо чисел подсказка, что именно нужно донабрать (интервалы на вкладке TPM и рабочие записи за период).

TPM — что видно

• KPI-карточки: MTBF, MTTR (с числом ремонтов), Простои (минуты за период), Переналадки (минуты за период), Активные проблемы — сколько интервалов состояния сейчас не «в работе» (подсвечено красным, если больше 0).
• Текущее состояние участка (ResourceStatePanel) — список открытых сейчас интервалов (состояние, комментарий, время начала); у каждого — при наличии права scheduler.manage — кнопка «Закрыть». Ниже — форма открытия нового интервала: выбор состояния (В работе / Простой / Переналадка / Ремонт) + текстовый комментарий + кнопка «Открыть интервал». Без права scheduler.manage форма и кнопки «Закрыть» не показываются — только просмотр списка.
• История интервалов (IntervalTimeline) — построчно по дням периода: цветные сегменты на суточной шкале, показывающие, в каком состоянии участок находился в какое время (наведение — всплывающая подпись с состоянием/комментарием).

SPC — что видно

• Поле выбора параметра контроля — автодополняющийся комбобокс по названиям QualityMeasurement.parameter_name, введённым в ОТК.
• После выбора параметра — KPI-карточки: Среднее, UCL / LCL (верхняя/нижняя контрольная граница), Cp / Cpk (индексы воспроизводимости процесса — считаются только если у параметра заданы допуски tolerance_min/tolerance_max), Вне контроля — число точек за пределами UCL/LCL из общего числа точек (подсвечено красным при ненулевом значении).
• Два графика: Индивидуальные значения (I) — линия значений с пунктирными линиями среднего/UCL/LCL, точки вне границ увеличены и подсвечены; Скользящий размах (MR) — линия |разницы соседних значений| с пунктиром среднего MR.
• Разворачиваемая таблица всех точек: дата, ID записи ОТК, значение, скользящий размах — строки вне контрольных границ подсвечены.

Типовые сценарии

1. Ежемесячный разбор эффективности участка. Мастер выбирает участок и месяц на вкладке OEE, смотрит итоговый % и разбивку по трём компонентам, чтобы понять, что тянет показатель вниз — простои (доступность), медленная работа (производительность) или брак (качество); переходит в «Потери (Парето)», чтобы увидеть главную причину простоев.
2. Ведение журнала простоев в реальном времени. Диспетчер/мастер с правом scheduler.manage на вкладке TPM открывает интервал «Ремонт» с комментарием причины, когда оборудование встало, и закрывает его, когда работа возобновилась — это и есть первичные данные, на которых считается OEE/TPM.
3. Контроль стабильности процесса. Технолог/ОТК выбирает числовой параметр измерения (например, диаметр детали) на вкладке SPC за интересующий период, смотрит на точки вне UCL/LCL и Cpk — сигнал, что процесс разъехался и пора разбираться с причиной, не дожидаясь массового брака.

Особенности и ограничения

• OEE/TPM целиком зависят от дисциплины ручного ведения интервалов состояния участка (ResourceStateEvent) — если мастер не открывает и не закрывает интервалы, «Доступность» и производные от неё показатели будут недостоверны.
• «Производительность» может быть выше 100% — это не ошибка: она считается как отношение нормативного времени (Тман сданных работ) к фактическому времени в состоянии «В работе», и если участок работал быстрее нормы, показатель превышает 100% (виджет OeeGauge для дашборда рассчитан на такой случай отдельно, но на вкладке OEE значение просто показывается как есть).
• MTBF/MTTR не считаются (остаются пустыми), если за период не было ни одного интервала «Ремонт» — это ожидаемое поведение, а не ошибка данных.
• SPC использует упрощённую I-MR карту для индивидуальных значений (не X̄-R для подгрупп) — контрольные границы считаются по скользящему размаху с постоянными коэффициентами (d2=1.128, множитель 3σ=2.66 для n=2), а не по подгруппам произвольного размера. Cp/Cpk считаются, только если хотя бы одна запись измерения содержит tolerance_min и tolerance_max.
• Права разделены только по одной операции внутри блока OEE/TPM/SPC — scheduler.manage на открытие/закрытие интервалов состояния и редактирование WIP-лимитов; сам просмотр вкладок закрыт одним общим правом на раздел (production-board.view), отдельного права на просмотр конкретно OEE/SPC/TPM нет.

Аналитика — вкладка «WIP» (/analytics, вкладка WIP)

Что видно

Список участков, для каждого — текущее НЗП / установленный лимит (current_wip / limit) и полоса заполнения (красная, если лимит достигнут или превышен); если лимит не задан — пометка «не задан». При наличии права scheduler.manage — кнопка «Изменить» рядом с каждым участком, открывающая поле ввода нового значения лимита и кнопки «Сохранить»/«Отмена».

Типовые сценарии

1. Диспетчер, настраивающий буферное планирование потока (см. Производство и планирование, «Управление потоком»/«Диспетчеризация»), заходит на вкладку WIP, чтобы свериться, на каких участках лимит уже установлен, а на каких ещё нет значения (значит, ограничение по факту не действует).
2. Мастер видит, что участок «упёрся» в лимит (полоса красная, current_wip == limit) — это подсказка, почему диспетчер не пускает на участок новую работу, пока текущая не сдвинется.

Особенности и ограничения

• Эта вкладка — только витрина существующих WIP-лимитов; сам механизм, как лимит влияет на планирование и дальнейшую диспетчеризацию потока, — предмет Производство и планирование («Управление потоком», «Диспетчеризация»/POLCA). Здесь же описано только то, что видно и редактируется именно со страницы «Аналитика».

Связанные разделы

• Начало работы — роли и права, окна и навигация; здесь используются без повторного объяснения.
• Производство и планирование — «Управление потоком» и «Диспетчеризация» — источник данных для виджетов «Узкое место», «Дефицит материалов», «Загрузка участков» и вкладки WIP (WIP-лимиты, POLCA, узкое место потока изучаются там подробно); «График производства» — источник статусов заказов, которые отображает «Обзор» и вкладка «Производство».
• Работы и качество — «Приём работ», ОТК и брак — первичные данные, на которых считаются виджет «Брак за 7 дней», KPI «Уровень брака», Pareto брака и вкладка SPC.
• Склад и снабжение — приход материалов, лимитные карты, обеспеченность — источник виджетов «Приход, не оприходовано», «Лимитные карты на исходе», «Закупки требуют внимания».