说个制造业里特别常见但又特别让人窝火的事。某电子制造企业的品质部质检判定标准是按客户来的。A客户的允收标准是一个样B客户是另一个样而且每个客户隔三差五就会更新标准。这些判定逻辑被开发人员写进了质检系统的代码里。结果就是——每次客户更新标准品质部就得提需求给ITIT排期开发、测试、上线。一个简单的判定条件修改快的话一周慢的话一个月。品质部的同事经常吐槽客户今天改的标准我们下个月才能用上。中间这段时间全靠人工记忆和Excel表格兜着。这不是个案。几乎所有制造业企业的系统里都藏着大量写死在代码里的业务规则。而这些规则恰恰是制造业日常运营中最需要灵活调整的部分。一、制造业的业务规则远比想象中复杂先盘点一下工厂里到底有多少业务规则在裸奔。1. 质检判定规则不同产品、不同客户、不同缺陷类型对应的判定标准完全不同。有些是简单的超差即不合格有些是多维度的综合判定——比如外观缺陷在A级产品中是致命缺陷在C级产品中可能只是轻微缺陷。再加上客户经常更新标准这套规则的变化频率远超想象。2. 报价与定价规则原材料价格波动、客户等级、订单量阶梯、交期要求、运输距离……报价涉及的因素太多了。这些因素的交叉组合形成了一套复杂的计算规则而且随着市场行情变化规则本身也在不断调整。3. 工艺参数校验规则不同产品规格对应不同的工艺参数范围。温度上限多少、压力区间多少、转速范围多少——这些参数组合起来构成了一个庞大的校验矩阵。产品型号一多规则量就是指数级增长。4. 预警与升级规则设备温度超过某个阈值触发一级预警超过另一个阈值触发二级预警甚至停线。不同设备、不同工序的预警规则不同。而且随着设备老化或工艺优化这些阈值需要动态调整。5. 排产约束规则哪些产品不能在同一台设备上连续生产换模成本太高、哪些订单必须优先排客户等级或交期约束、哪些工序之间有先后依赖关系……这些约束条件构成了排产的核心规则体系。这些规则有一个共同特点数量多、变化快、逻辑复杂、且业务人员最清楚规则该怎么定。但当它们被写死在代码里的时候业务人员就成了看客——明知道规则该怎么改却没有能力自己动手只能等IT排期。二、写死在代码里的代价规则被硬编码在系统里表面上看也能用但代价是隐性的、长期积累的。1. 响应速度跟不上业务变化前面说了一个简单的质检标准修改走开发流程可能需要一两周。但在竞争激烈的制造业客户给你一两周的响应窗口很多时候系统还没改好业务已经用别的办法手工表格、人工记忆顶上去了。系统里的规则跟实际执行的规则脱节数据准确性就出了问题。2. 维护成本不断膨胀代码里的规则越堆越多时间一长连开发人员自己都搞不清楚某条规则为什么存在、对应什么业务场景。老开发人员离职了新来的人更不敢动——这段代码不知道谁写的但一直在跑别碰它。这就是所谓的代码腐化。规则越堆越复杂维护成本越来越高但谁也说不清到底哪些规则还在生效、哪些已经是僵尸代码。3. 业务人员和IT之间反复扯皮业务说这个规则早就该改了IT说你提需求了啊我在排期。业务说这个逻辑很简单改一下不就行了IT说没那么简单涉及好几个模块的联动。这种沟通消耗每天都在发生。根源在于业务规则的变更不应该走系统开发的流程而应该走规则配置的流程。但规则写在代码里就没有配置这个选项。4. 规则的执行无法审计追溯代码里的规则执行结果可以查到但为什么这样判定往往没有清晰的解释。出了问题要回溯的时候需要开发人员去翻代码、查逻辑效率极低。在制造业的质量合规场景中这一点尤其致命。客户来审核问你这批产品的判定依据是什么你总不能回答请给我们开发人员三天时间查代码。三、规则引擎解决的核心问题说白了就一句话把业务规则从代码里抽出来变成可以独立配置、独立管理、独立生效的规则。业务人员在可视化界面上配置规则配置完直接生效不需要走开发流程。听起来简单但要做到好用需要解决几个关键问题。1. 可视化配置——让不懂代码的人也能配规则规则引擎的配置界面必须足够直观。业务人员不需要理解什么是代码、什么是编译他们只需要在界面上做选择、填数字、设条件。常见的配置方式包括决策表类似Excel表格行是条件组合列是输出结果。业务人员一看就懂。决策树树状结构从根节点到叶节点每一步是一个判断条件。适合层级化的判定逻辑。评分卡每个因素赋予一定分值总分决定最终结果。适合风险评估、客户分级等场景。这些方式都应该是拖拽填表式的操作而不是写代码。2. 规则版本管理——改错了能回滚业务规则会频繁调整这就需要一个版本管理机制。谁在什么时候改了什么规则、改之前是什么版本、如果改错了怎么回滚——这些都需要清晰记录。就像代码有Git一样规则也需要有自己的版本控制。3. 规则测试——配置完能先验证再上线规则配好了不能直接上生产。需要有个测试环境拿历史数据跑一遍看看新规则的输出跟预期是否一致。尤其是质检判定这种影响大的规则新规则上线前必须用历史数据做充分验证确保不会出现误判或漏判。4. 规则与系统的解耦——改规则不用动系统规则引擎作为独立的组件跟业务系统质检系统、ERP、MES等通过接口对接。系统负责数据采集和结果展示规则引擎负责逻辑判断。两边各司其职。这样一来换一套规则不影响系统运行升级系统也不影响规则逻辑。耦合度降下来灵活性才能上去。5. 执行记录可追溯——每条判定都有据可查规则引擎执行每条规则时应该完整记录输入了什么数据、命中了哪条规则、为什么得出这个结果。在质量审核、客户验厂、合规检查等场景中这种可追溯性不是锦上添花而是必须有。四、制造业上规则引擎从哪个场景开始1. 先挑变化最频繁的规则比如质检判定标准——客户经常改IT疲于应对业务人员苦不堪言。把这类规则迁移到规则引擎上效果立竿见影。2. 再挑逻辑最复杂的规则比如报价计算——涉及十几个变量的交叉组合用代码写出来又长又难维护。用决策表的方式呈现业务人员一目了然修改起来也方便。3. 最后做跨系统的统一规则中心当多个系统都需要用到同一套规则时比如质检和售后都可能用到同一套缺陷判定标准用规则引擎做统一管理避免不同系统里的规则各自为政。五、结语制造业的系统里到底有多少业务规则被写死在代码里可能比大多数人想象的要多得多。而每一条被写死的规则都意味着一次潜在的响应延迟、一次沟通损耗、一次业务和IT之间的拉扯。规则引擎的价值不在于它有多高级而在于它解决了一个很朴素的问题让业务规则回归业务人员手中。该改就改改完就生效不用等排期、不用改代码、不用走流程。在制造业这个变化越来越快的时代灵活本身就是一种竞争力。