目录
从订单接收到交付的全业务流程建模需以端到端价值流为核心,覆盖计划层、执行层、监控层三大层级,并通过数据模型实现业务实体、事件、状态的全链路映射。以下是分阶段的业务全流程建模设计
一、业务全流程拆解与关键节点
1. 核心流程阶段与业务实体
流程阶段 | 关键业务实体 | 核心数据对象 |
---|---|---|
1. 订单接收与承诺 | 客户订单、销售合同、交期承诺 | 订单编号、产品规格、需求数量、承诺交期 |
2. 生产计划排程 | 主生产计划(MPS)、产能分配、工单拆分 | 工单编号、计划开始时间、资源约束条件 |
3. 物料齐套检查 | BOM、库存批次、供应商交期 | 物料编码、库存可用量、齐套状态标记 |
4. 设备与人员调度 | 设备状态、维护计划、班次安排 | 设备ID、操作员ID、调度时间窗 |
5. 晶圆加工 | 工艺路线、WIP(在制品)批次、工序参数 | 工艺步骤、加工数量、良率记录 |
6. 封装与测试 | 封装类型、测试方案、缺陷分类 | 测试结果代码、缺陷分布、返工标记 |
7. 质量检验与放行 | 检验标准、抽样规则、放行单 | 检验批次号、缺陷数量、放行状态 |
8. 完工入库与交付 | 入库批次、物流跟踪、交付签收 | 物流单号、实际交付时间、客户签收反馈 |
2. 关键业务规则与约束
-
交期承诺规则:基于当前产能、物料库存、设备可用性的动态交期计算。
-
齐套检查逻辑:BOM多级展开 + 替代料匹配策略。
-
设备调度优先级:紧急订单插单、设备维护窗口冲突处理。
-
质量放行条件:AQL(Acceptable Quality Level)阈值判定与特采审批流程。
二、全流程数据模型设计
1. 业务过程建模(流程图→数据流图)
-
Level 1(顶层视图):
-
Level 2(子过程细化):
-
计划排程子流程:
-
2. 实体关系模型(ER Diagram)
-
实体间关系:
-
一个客户订单可拆分为多个工单(1:N )
-
一个工单对应多个工序执行记录(1:N )
-
每个工序依赖特定设备和工艺路线(N:1)
-
3. 数据状态机建模(关键对象状态变迁)
-
工单状态机:
已创建 → 已排程 → 物料就绪 → 加工中 → 完成 → 已关闭 ↓ ↑ 异常挂起 → 恢复
-
质量检验状态机:
待检验 → 检验中 → 合格放行 ↓ 不合格 → 返工/报废
三、业务规则与数据模型映射
1. 规则驱动的事实表设计
业务规则 | 模型实现方式 | 示例字段 |
---|---|---|
交期延迟计算 | fact_order_fulfillment.delay_days | actual_delivery_date - committed_delivery_date |
设备OEE(综合效率) | fact_production_order 中的工时、良率、停机时间 | availability = (实际运行时间 / 计划运行时间) |
齐套率统计 | 物料维度表关联库存事务事实表 | dim_material.stock_available |
2. 约束条件的数据校验逻辑
-
物料齐套检查:
-- 检查工单所需物料是否全部可用 SELECT work_order_id, CASE WHEN SUM(missing_qty) = 0 THEN '齐套' ELSE '缺料' END AS kit_status FROM ( SELECT wo.work_order_id, bom.material_id, GREATEST(bom.required_qty - inv.stock_qty, 0) AS missing_qty FROM dim_bom bom JOIN fact_work_order wo ON bom.product_sk = wo.product_sk LEFT JOIN fact_inventory inv ON bom.material_id = inv.material_sk WHERE wo.work_order_id = 'WO-20231001-001' ) t GROUP BY work_order_id;
四、模型落地与验证
1. 数据血缘追踪
-
使用工具(如Apache Atlas)标记关键字段来源:
-
fact_order_fulfillment.actual_delivery_date
← 物流系统(TMS)的签收事件表 -
fact_production_order.defect_qty
← MES系统的工序报工接口
-
2. 业务场景验证用例
-
用例1:紧急订单插单影响分析
-- 检查插单后原有工单的延迟风险 SELECT affected_work_order_id, new_priority, planned_start_time, CASE WHEN planned_start_time < CURRENT_TIMESTAMP THEN '需重排程' ELSE '可保持' END AS reschedule_flag FROM reschedule_simulation('EMG-ORDER-001'); -- 模拟插单函数
-
用例2:质量根因分析
-- 统计同一设备、同一工序的缺陷聚类 SELECT equipment_id, process_step, defect_code, COUNT(*) AS defect_count FROM fact_quality_inspection WHERE defect_code IS NOT NULL GROUP BY equipment_id, process_step, defect_code HAVING COUNT(*) > 10 -- 设定阈值 ORDER BY defect_count DESC;
五、扩展性与治理
1. 动态扩展设计
-
工艺路线版本化:在
dim_product_process
中增加effective_date
和expiry_date
,支持新旧工艺并行分析。 -
设备参数快照:为
fact_production_order
添加设备参数JSON字段,记录加工时的实时参数(如温度、压力)。
2. 数据治理要点
-
一致性:定义跨系统ID映射表(如工单号在ERP/MES中的对应关系)。
-
时效性:关键事实表(如工单执行)采用近实时(NRT)数据更新(延迟<5分钟)。
-
稽核规则:定期检查工单状态与WIP位置的逻辑一致性(如“已关闭”工单不应有在制品)。
通过以上设计,可实现从业务需求到数据模型的完整闭环,支撑生产计划部门的实时监控、根因分析、预测性决策(如设备维护预警、交期承诺优化),最终驱动半导体制造效率提升与成本降低。
往期精彩
3分钟学会SQL中的断点去重技术,轻松搞定连续相同状态数据去重问题?
颠覆认知!COUNT(DISTINCT) OVER(ORDER BY) 原生写法 VS 替代方案,谁才是王者?
3分钟学会SQL中的断点分组技术,轻松搞定连续相同状态数据分组问题?
HyperLogLog 近似累计去重技术解析:大数据场景下的高效基数统计
宽表爆炸?动态Schema + 增量更新,轻松化解千字段扩展难题
如果您觉得本文还不错,对你有帮助,那么不妨可以关注一下我的数字化建设实践之路专栏,这里的内容会更精彩。
专栏 原价99,现在活动价59.9,按照阶梯式增长,即将恢复到原价。
专栏优势:
(1)一次收费持续更新。
(2)实战中总结的SQL技巧,帮助SQLBOY 在SQL语言上有质的飞越,无论你应对业务难题及面试都会游刃有余【全网唯一讲SQL实战技巧,方法独特】
(3)实战中数仓建模技巧总结,让你认识不一样的数仓。【数据建模+业务建模,不一样的认知体系】(如果只懂数据建模而不懂业务建模,数仓体系认知是不全面的)
(4)数字化建设当中遇到难题解决思路及问题思考。