Модуль 14. Бизнес-аналитика в производстве (Manufacturing)
Картина домена: ERP ↔ MES ↔ SCADA/PLC
Кто есть кто:
- SCADA/PLC/датчики (OT-уровень): события и счётчики из цеха (start/stop, счёт изделий, причины простоев, скорость, температура/давление).
- MES (execution): наряды/операции, маршруты, смены, операторы, качество (OK/неОК), скрап/передел, партионность, генеалогия (какие входные партии во что превратились).
- ERP (back office): MPS/MRP/APS, заказы, BOM/рецептуры, маршруты (routing), мастер-данные (номенклатура, рабочие центры), себестоимости, партии, справочники причин.
Поток данных (типовой):
PLC/SCADA → (источник OT) → шина/стрим (микробатчи 1–5 мин) → MES (нормализация событий) → DWH (RAW→CORE→MART) → семантика KPI → дашборды/алерты.
Важное: единое время события (event time), синхронизация часов (NTP), политика store&forward при обрывах сети.
Модель данных для производственной аналитики
Факты (минимум):
- fact_production_count — счёт готовых/негодных изделий (grain: рабочий центр × заказ/операция × интервал/смена). Поля: good_count, scrap_count, rework_count, ideal_cycle_time.
- fact_downtime_event — простои (grain: событие start–end). Поля: start_ts, end_ts, duration_s, cause_code, planned_flag, microstop_flag.
- fact_quality_sample — инспекции/контрольные замеры (X̄/R, p-charts). Поля: sample_id, subgroup_id, measure_value, characteristic.
- fact_genealogy — потребление материалов: входная партия → выходная партия/серийник. Поля: input_batch_id, output_batch_id, qty_in, qty_out.
- fact_wo_operation — выполнение операций по наряду (start/finish, оператор, qty).
- fact_energy (если актуально) — потребление энергии/пара/воды.
Измерения:
- dim_work_center, dim_equipment, dim_shift, dim_product (SCD2), dim_batch (S/N), dim_route_operation, dim_scrap_reason, dim_downtime_cause, dim_operator, dim_calendar.
Агрегаты/витрины:
- mart_oee_shift_workcenter, mart_losses_pareto, mart_spc_characteristic_day, mart_traceability_edges.
Важные решения:
- Событийная модель: что хранить как интервалы (простой), что как счётчики (pieces), что как снапшоты (параметры процесса).
- Микропростои: порог, ниже которого считаем performance loss (например, ≤60 сек) vs availability (downtime).
- Единицы измерения: секунды/шт/партии; таймзона цеха; сменность.
OEE без магии: формулы, допуски, ловушки
Определения (за смену/смено-рабочий центр):
- Planned Time = календарное время смены − плановые остановы (перерывы, плановая наладка).
- Run Time = Planned Time − Unplanned Downtime.
- Availability = Run Time / Planned Time.
- Performance = (Ideal Cycle Time × Total Count) / Run Time.
- Quality = Good Count / Total Count (Total = Good + Scrap + Rework*, решите как учитывать rework).
- OEE = Avail × Perf × Qual.
Ловушки и решения BA:
- Считать microstops (≤N сек) в performance — задайте порог.
- Ideal Cycle Time — из маршрута/паспорта; при мультиноменклатуре осредняйте взвешенно.
- Planned downtime (переналадка) — либо исключаем из Planned Time, либо показываем как отдельную потерю (SMED-инициативы).
- Rework: как «плохо→хорошо» — в quality отражаем через first pass yield (FPY) и rolled throughput yield (RTY).
Пример SQL (упрощённо, ANSI-like):
WITH s AS (
SELECT wc_id, shift_id,
SUM(good_count + scrap_count + rework_count) AS total_count,
SUM(good_count) AS good_count,
SUM(ideal_cycle_time * (good_count + scrap_count + rework_count)) AS ideal_time_s
FROM fact_production_count
WHERE prod_date = DATE '2025-05-15'
GROUP BY wc_id, shift_id
),
t AS (
SELECT wc_id, shift_id,
SUM(duration_s) FILTER (WHERE planned_flag=FALSE) AS unplanned_dt_s,
SUM(duration_s) FILTER (WHERE planned_flag=TRUE) AS planned_dt_s
FROM fact_downtime_event
WHERE prod_date = DATE '2025-05-15'
GROUP BY wc_id, shift_id
),
cal AS (
SELECT shift_id, wc_id,
planned_time_s -- календарь смен+перерывы
FROM dim_shift_calendar
WHERE prod_date = DATE '2025-05-15'
)
SELECT s.wc_id, s.shift_id,
(cal.planned_time_s - t.unplanned_dt_s) / NULLIF(cal.planned_time_s,0) AS availability,
s.ideal_time_s / NULLIF((cal.planned_time_s - t.unplanned_dt_s),0) AS performance,
s.good_count / NULLIF(s.total_count,0) AS quality,
( (cal.planned_time_s - t.unplanned_dt_s) / NULLIF(cal.planned_time_s,0) )
* ( s.ideal_time_s / NULLIF((cal.planned_time_s - t.unplanned_dt_s),0) )
* ( s.good_count / NULLIF(s.total_count,0) ) AS oee
FROM s JOIN t USING (wc_id, shift_id)
JOIN cal USING (wc_id, shift_id);
TAKT, цикл, Lead Time и WIP
- TAKT time = Доступное время на спрос / Спрос (шт/смену). Это требование рынка.
- Cycle time = фактическое время между выходами изделий.
- Lead time = время от входа заказа до выхода (включая ожидание).
-
Little’s Law: WIP ≈ Throughput × Lead Time.
BA-решение: фиксируем, где измеряем (станок/линия), и на каком горизонте (смена/день), и пороговые сигналы (если Cycle > TAKT → алерт).
Scrap/Rework и Cost of Poor Quality (COPQ)
Определения:
- Scrap — безвозвратный брак.
- Rework — передел, после которого может стать годным.
- FPY = Good first pass / Total input. RTY — произведение FPY по шагам.
Экономика:
- Прямые: материалы, время, энергия.
- Косвенные: простои, логистика, недопоставки, штрафы.
BA фиксирует:
- Категории причин (dim_scrap_reason), кто вводит, где обязательный ввод (MES UI).
- Поле responsibility (процесс/инструмент/сырьё/оператор/поставщик) — для Pareto.
SPC-контроль (минимум, но правильно)
Когда нужен: стабильные процессы с частыми измерениями (толщина, масса, момент, температура).
Диаграммы:
- X̄/R (среднее/размах) для количественных характеристик с подвыборками.
-
p-chart для доли дефектных (бином).
Построение X̄/R (subgroup size = n): -
Контрольные границы:
- UCL_X̄ = X̄̄ + A2 * R̄, LCL_X̄ = X̄̄ − A2 * R̄ (A2 зависит от n)
- UCL_R = D4 * R̄, LCL_R = D3 * R̄
- Правила Вестерна (пороговые сигналы) — документируем, чтобы не реагировать на common cause.
BA-задачи:
- Где считаем подвыборки (по времени/операции), размер n.
- Где храним параметры карт (референс-период, коэффициенты).
- Политика реакции: кто, за сколько, что делает при сигнале.
Партионность и трассируемость (genealogy)
Зачем: отзыв, рекламации, аудит.
Модель:
- dim_batch: batch_id, lot, expiry, supplier.
- fact_genealogy: input_batch_id → output_batch_id (qty_in → qty_out).
- fact_wo_operation: какая партия по какой операции прошла.
Запрос «найди, во что попала входная партия»:
WITH RECURSIVE g AS ( SELECT input_batch_id, output_batch_id, qty_in, qty_out, 1 AS level FROM fact_genealogy WHERE input_batch_id = :defective UNION ALL SELECT g.output_batch_id AS input_batch_id, fg.output_batch_id, fg.qty_in, fg.qty_out, g.level+1 FROM g JOIN fact_genealogy fg ON g.output_batch_id = fg.input_batch_id ) SELECT * FROM g;
BA фиксирует: минимальный набор связей обязателен к вводу; процесс «как восстанавливаем цепочку», SLA ответа на запрос trace.
MRP vs APS: что требовать BA
- MRP (материалы): «без ограничения мощности», расчёт потребностей по BOM и запасам, выдаёт план заказов/пополнений.
-
APS (планирование расписаний): «с учётом мощности», finite capacity, переналадки, очередность, приоритеты, окна.
Требования BA: - Полнота и корректность BOM/маршрутов/номиналов времени, календарей мощностей.
- Обратная связь из MES: фактические времена/скорости → апдейт параметров APS.
- Политики при конфликте (заказ фиксДата vs минимизация переналадок).
Дашборды и NFR: что увидит цех и менеджмент
Линия/цех (операционный):
- KPI-плашки за смену: OEE, Avail/Perf/Qual, Good/Scrap/Rework, Top-3 причин простоев (Pareto), TAKT vs Cycle.
- SPC-виджеты по критическим характеристикам.
- Алерты: TAKT breach, UCL/LCL breach, длительный простой.
Менеджмент (день/неделя):
- Тренды OEE по линиям/сменам, Pareto потерь (availability/performance/quality).
- Скрап по причинам/ответственным, COPQ.
- Выполнение плана (MPS) vs факта, WIP и Lead Time.
NFR (пример):
- Свежесть событий: ≤ 5 мин до витрины смены; агрегаты дня — до 07:00 D+1.
- p95 загрузки рабочих страниц ≤ 3 сек (12 месяцев истории, фильтры: цех/линия/смена).
- RLS: мастер/инженер видит свой цех; HQ — все.
Риски и анти-паттерны
|
Риск |
Симптом |
Что делать |
|---|---|---|
|
Несинхронные часы |
«Негативное» время простоев, «скачущие» смены |
NTP для PLC/MES, хранить event time + ingestion time, политика DST |
|
Счётчик PLC сбрасывается |
Резкие «нули» счётчиков |
Модель «разности» (deltas), защита от переполнения, heartbeats |
|
Плохо размеченные простои |
60% unknown |
Справочник причин + обязательный ввод, таймауты автоклассификации |
|
Микропростои «съедают» Availability |
Avail «ниже плинтуса» |
Порог microstop → в Performance, документировать |
|
Разночтение OEE между цехом и фин. отчётом |
«Не совпадает» |
Единая методика/владелец метрики, версия методики в шапке |
|
Генерация партий вручную |
Потерянная трассируемость |
Штрихкоды/скан, обязательные связи в MES |
|
SPC «фонит» |
Ложные сигналы, «гоняют» настройки |
Обучение common vs special cause, референс-период, ревизия пределов |
|
MRP «в вакууме» |
План не исполним |
Замкнуть петлю MES→APS (фактические такты/наладки) |
|
KPI-косметика |
«OEE растёт», но выпуск нет |
Баланс Avail/Perf/Qual, guardrails (выпуск/OTIF/склад) |
Вопрос–ответ (FAQ)
Q: Почему у нас OEE ниже мировых бенчмарков?
A: Часто из-за методики (микропростои как downtime, включили плановые наладки в Planned Time) или плохой разметки причин. Проверьте пороги, методику и качество данных.
Q: Как учитывать переналадку — planned или unplanned?
A: Плановые наладки исключайте из Planned Time (или показывайте отдельно как SMED-потерю). Важна последовательность и согласование.
Q: Реально ли SPC без лаборатории данных?
A: Да, начните с 1–2 критических характеристик, подвыборок n=5, X̄/R-карты; храните параметры карт, не пересчитывайте каждую неделю без причины.
Q: Что делать с rework в качестве?
A: Отдельно показывать FPY/RTY. В OEE-quality лучше считать Good / Total и держать rework виджетом рядом.
Q: Как быстро внедрить гибкую трассируемость?
A: Минимум — скан партий на вход/выход операции, fact_genealogy; SLA на закрытие «дырок»; отчёт «незамкнутые связи».
Q: Почему TAKT ≠ Cycle даже у «нормальной» линии?
A: TAKT — требование спроса; Cycle — физический выпуск. Балансируйте линии/переналадки или снижайте вариабельность.
Практика (что сдать по итогу модуля)
A. AS-IS/TO-BE процесса участка (1–2 ключевые операции)
- AS-IS (BPMN L2): события start/stop, точки ввода партий, где теряются данные/причины.
- TO-BE: добавлены сканы партий, автозахват простоев, порог microstop, обязательные причины, синхронизация времени.
- Список изменений: быстрые победы (быстрыe коды причин, автозачёт microstops, NTP).
B. Калькулятор OEE для пилота (смена × линия)
- Входы: Planned Time, Unplanned Downtime, Total Count, Good Count, Ideal Cycle Time.
- Выходы: Availability, Performance, Quality, OEE; Pareto потерь (top-5 причин).
- Эталонная сверка: 2 смены × 2 линии; допустимые отклонения ±0,2 п.п.
C. SPC-мини-проект
- Характеристика: толщина/момент. Подвыборки n=5 каждые 30 минут.
- Рассчитать X̄̄, R̄, UCL/LCL; определить 0/1 сигналы; описать политику реакции.
D. Traceability-демо
- Импорт 3-уровневой цепочки (сырьё→полуфабрикат→готовая продукция).
- Запрос «что затронет отзыв партии X» (рекурсивный CTE) и «какие входные партии в продукт Y».
Чек-листы готовности
Данные и методика
- Определён порог microstop и политика planned/unplanned.
- Ideal Cycle Time по продуктам/операциям — актуален.
- Единое время события, NTP, таймзона зафиксированы.
- Определение OEE/FPY/RTY/TAKT — утверждено, версия методики.
Витрины/NFR
- mart_oee_shift_workcenter и mart_losses_pareto собраны.
- Свежесть ≤ 5 мин (операции), отчёт дня — 07:00 D+1.
- p95 страниц ≤ 3 сек; RLS: цех/линия/смена.
SPC/качество
- Карты X̄/R или p-charts на 1–2 характеристики.
- Хранилище параметров карт и политика реакции.
Traceability
- fact_genealogy наполняется; доля незамкнутых связей < 2%.
- SLA ответа на 2 запроса: «вниз по цепи» и «вверх по цепи».
Вы связываете операции цеха и бизнес-метрики: формализуете OEE/TAKT/FPY, строите витрины и дашборды, задаёте политику микропростоев и причин, включаете SPC по критическим параметрам, обеспечиваете трассируемость партий и подаете корректные требования к MRP/APS. С таким пакетом команда не просто «смотрит цифры», а управляет потерями и качеством.
