2021-07-19

Alice 漫谈制造业数字化

一、引子： 物料的齐套计算（PART1)

前些时间同事跟我谈论到一个话题，在制造业中，物流的同事经常需要根据当前物料的库存、供应商的物料交货计划，并结合产品的BOM，从而从物料齐套的角度对客户在中短期的订单需求的可完成度做出一个及时的滚动式的评估。

同事介绍， 市面上的MRP系统一般都内置有齐套逻辑计算，但通常逻辑比较单一，一般只有针对当前库存的齐套逻辑计算，而对供应商交货预测在内的齐套逻辑计算，特别是对供应商交货预期的不同场景，如： 根据系统设定的交货周期而自动生成的交货预期场景，或供应商收到订单后的初步反馈的交货预期场景， 再有与供应商进一步沟通后的确认交货预期的场景等等，MRP系统就没有这样的逻辑计算了， 所以物流的同事通常不得不在MRP系统之外做一些手工的计算， 而这些手工的计算，即使是对Excel各种高级功能都用得心应手的物流同事都是个难题， 所以最后依赖的是物流同事对物料管理的经验和物料短缺情况的熟悉程度，对一些个别的物料做一些针对性的分析，所以做不到完整，及时而又高效的分析。

同事问我有没有好的工具或方法来解决这个难题， 我觉得齐套计算本身逻辑清楚，也不复杂，用数据处理的ETL工具应该是一种解决途径，所以在对物料齐套知识做了一些了解后，我先有了下面的解决思路：

1. 识别出所需数据源

齐套计算逻辑除了涉及到订单需求，订单优先级规则，物料库存，物料交货预期，产品BOM 之外，另添加了非关键物料数据和物料替代料数据。

非关键物料是指那些基本上构不成交货瓶颈的物料，也指那些交货计划并不借助于MRP系统，而是通过类似于JIT(Just In Time）等的可视化补货方式来管理交货的物料，这两类物料的合集（当然往往后者是前者的一个子集）就构成了物流管理中的非关键物料， 因为这些物料或者不需要或者不适合参与物料齐套计算，所以要把它们排除在外。

物料的替代料是指在两个不同的物料号的替代关系 （注意物料的替代不是alternative source的意思，而是discontinue 或follow up 的关系)， 具有替代关系的两个物料，会有替代的系统预估时间和实际时间，替代时间和替代关系在MRB系统中对物料采购，消耗， 工单BOM加载和生产过程的切换管控都是有影响的， 我对其中的部分影响曾经总结过一篇短文，有机会，我会再结合产品物料替代的缘由等，给大家普及一下物料替代关系的知识。 而这里为了模拟的简单化， 仅仅会将有替代关系的物料认同为在库存上是可以互享的， 所以在计算中会将他们合并成同一组。

由此， 列出所需的数据源如下：

1. 客户产品订单需求数据
2. 客户产品订单优先级规则
3. 物料库存数据
4. 物料交货预期数据
5. 产品BOM数据
6. 非关键物料数据
7. 物料替代料数据

2. 对数据源的预处理

对数据源的预处理包括两部分： 第一部分是指对数据格式和内容的预处理，第二部分是对齐套计算逻辑和计算量相关的预处理， 第一部分预处理的原因主要是以上的数据源一般都来自于MRP的输出报表，其中有很多非相关字段，或格式（特别是时间格式，由于MRP的输出报表的非专用性，时间格式在各个报表中可能各各不同）原因需要做一些清理和转换，这一部分的预处理在ETL工具中容易实现，在此就不多做展开。所以这里指的预处理是指跟齐套计算逻辑和计算量相关的预处理部分， 其中包括：

1. 物料替代预处理： 其中包括：
。将具有替代关系的物料归并到一组
。将物料库存数据，物料交货预期数据，产品BOM数据，非关键物料数据，物料替代料数据中具有替代关系的物料号以归并组名代替原物料号。

2. 非关键物料数据预处理：
将物料库存数据，物料交货预期数据，产品BOM数据中属于非关键物料的相关料号移除，以排除在计算之外，通常一个工厂的关键物料占总物料总和的10%以下，所以此预处理对计算量大有帮助

3. 物料库存数据和物料交货预期数据预处理
。将物料库存数据和物料交货预期数据以时间轴进行各料号和数量的合并

4. 产品BOM数据预处理
。产品BOM常见的一个细节上的问题是同一成品下挂有的同一原材料分多行，预处理时就需要要将这些行合并，当然BOM结构由于各种原因可能还会有其它的一些差异或问题需要进行预处理。

5. 客户产品订单需求数据
。虽然每个客户的订单需求和预测实际上不会有要1.2345个这样的非整数个产品的需求，而起不会每个客户每天都有订单需求， 但众多客户的需求数据进入MRP系统后，系统会将这些数据做平滑或平均处理，所以通常从MRP系统输出的客户订单需求数据带有小数点，这些带有小数点的客户订单需求，在和BOM 用量，库存数据在做齐套计算模拟时会陷入一些不想出现的结果，所以如要避免一些计算的逻辑陷阱，可以提前对订单数据进行一些预处理，比如说订单需求量取整，并在计算中以配齐整数套来做模拟。

3. 齐套计算核心算法设计_被否定的算法设计

物料齐套计算模拟的业务需求场景多种多样，我所设计的业务场景是根据物料库存和交货预期，获得对已定义优先级的订单需求得出每日最大的齐套数， 对于其它的业务场景，特别是更复杂的业务场景需求， 有时间有机会会做更多的探讨。

在没有拿到一些实际数据之前时，我一开始设计的算法设计非常简单，步骤如下：

1. 在第一天的所有产品订单齐套计算时，依据当天产品订单优先级，从第一个订单开始，根据它的BOM获得它需求的物料数量，并根据第一个定单的需求日期，从物料库存合并表中获取需求日期前这些物料的可用库存，随后将这些可用库存与定单所需要的物料数量做比较，查看是否有短缺物料，如果没有，这个订单就可全部完成，如果有一个或多个短缺物料，则比较各个短缺物料各自能齐套的数量，找出其最小数量，即获得最大能齐套的数量，然后根据这个齐套数量获取在各个物料上的消耗数量，然后在以扣除了此数量之后的物料的库存和交货数量为基础，移到下一个产品需求定单做同样的分析。。直到第一天产品订单都一一计算结束

2. 结束了第一天订单的齐套计算，就接着对第二天的齐套进行计算，同样也是从优先级最高的产品定单开始算齐套，但不同的是，最高优先级的订单并不是第二天订单需求优先级的订单，而是要从第一天的未完成工单排在前面，并按照其原有优先级来排序，齐套计算方法仍与之前一样。。。这样一一算下去，直到第二天的最后一个订单齐套计算结束

3. 第三天，第四天。。。。到最后一天订单齐套计算与第二天类似，所需要考虑的订单是之前累计未完成的所有订单加上当天的订单并按既定的优先级排序来计算每个定单可在那天的齐套数量。。。一直算到最后一天的最后一个订单。

在算法上不难计算并意味着可实现性，上述计算中需要有双重循环，内循环是对一天内的每个订单的循环计算，外循环是对各天的循环，所以对计算所需要的时间长度，我心里并没有底，当然，那时我还没建立起计算可能也会面临空间长度限制的概念，那是我在调试时遇到了这个问题后才发现这个问题可以更为棘手。

很快同事就给我提供了一个工厂的参考数据，产品订单需求跨了5月到8月3个月，近期的是以天为单位的订单数量，后面以周为单位的订单数量，从源数据的量级(行数）如下：

1. 客户产品订单需求数据 ：10K+
2. 物料库存数据和交货预期数据： 20K+
3. 产品BOM数据 : 140K+
4. 非关键物料数据： 5K+
5. 物料替代料数据: 300+, 替代层数 1-7层不等
6. 产品BOM中不同物料数量(unique part)： 5K+

经过数据预处理后， 数据量级（行数）减为：

1. 客户产品订单需求数据 ：10K+
2. 物料库存数据和交货预期数据： 800+
3. 产品BOM数据 : 7K+
4. 产品BOM中不同物料数量（unique part)：350

预处理后库存和BOM数据量级大大减少，但决定内外循环的每日订单行数和订单跨越的日期数恒定，由此得出的循环次数并不会变。 而单次循环的时间，由于这些数据的全处理只会在有限几个步骤中的，大部分步骤是符合了某些条件后的部分数据的处理，所以主要是步骤数量，及最长时长的步骤才是决定因素，比如说排序，合并，读写操作等，在没有将循环功能用ETL工具搭建起来，我想我还是要先预估下计算执行时间，如果时间执行时间太长，我得调整方案，以免走弯路浪费时间。

执行循环次数的量级推算其实很简单，第一天的循环次数是第一天的订单数量，第二天的循数量是第一第二天两天的总订单数量，这个好理解，因为可能第一天的工单一个都没有完成，需要滚动到第二天继续参与计算，以此类推，每天的循环数量就是到这天为止累计的订单数量，至算到最后一天时，将这每天的数量累加起来，就得到了最worse情况下的总循环数量，看到这个数据我就不淡定了，因为总循环数量实在是有点高，如果以此循环数量，并与我简单测试的单循环时间在5s左右的时间，计算出的总运算时长为163小时，约6.8天，这个时长结果，一方面对运算的稳定性有很大的挑战，更多方面，即使能让一台电脑不间断地进行运算，6.8天才能出结果对业务也是毫无意义了。
下面是循环次数的推演：

4. 齐套计算核心算法设计_可执行的算法设计

上面简单粗暴的算法设计因运算时长的关系，我只能毫不犹豫地放弃了，那么要怎么算呢？很快我想到了如果库存足够足够多，多到大于当天要生产的产品工单中BOM带出的物料需求总量，不就不需要对当天的工单一一去做齐套分析了吗？同样，如果库存相当想到少，比如说像0库存的情况下，用到这颗物料的可齐套率就只能是0了，而在相当相当少的库存和足够足够多的库存之间，怎么找到一种逻辑，建立起其足够多和相当少的定量计算方式，就是此齐套计算的核心了，经过了多轮的推演，数据模拟，测试和逻辑检查，我建立了以下可执行的物料齐套的核心算法：

1. 刷新一天内的订单需求，并根据优先级排列： 这里一天内的需求订单既包括历史遗留的未完成的订单，也包括当天收到的新订单

2. 刷新这天内物料的库存状况： 这里当天内物料的库存状况指的是物料在某个起始点的库存状况，加上起始点到当前的物料交货预期，减去起始点到当前齐套需要的物料消耗后最新的库存状况。

3. 齐套核心分析之__无库存瓶颈的订单定位：
3.1 将根据优先级排列的订单需求依其BOM逐行炸出其物料需求
3.2. 根据物料逐行统计其累计的物料需求量
3.3. 逐行将累计需求量与当前库存做比较，标识出当前库存是否能满足到该行的需求。如当前库存》累计需求量，则标识为yes, 否则为no.
3.4. 统计每个订单中标识为yes的行数，作为订单yes行数。
3.5. 统计每个订单中物料的行数，作为订单物料行数。
3.6 将订单yes行数和订单物料行数一致的订单一次性选出，这些订单就是无库存瓶颈行，订单数量可悉数齐套，并做相应的库存扣减。

4. 齐套核心分析之__有库存瓶颈的优先级最高订单的定位和最大齐套数计算：
4.1 在 第3步分析的3.3中，第一个标识了有一个或多个no行的订单就是有库存瓶颈的优先级最高的订单，后续有库存瓶颈订单的齐套应以它最大化齐套之后的剩余库存来做齐套分析。
4.2 定位了此订单后，对其订单中所有的no行的物料库存可配套的订单数量做一个从低到高的排列， 将排列最低的物料库存可配套的数量作为该订单的最大可齐套数，并做相应的库存扣减。

5. 齐套核心分析之__0库存订单的定位：
在 第3步分析的3.3中，对于订单炸出的行中的当前库存量，一次性选出那些一行或多行当前库存为0的订单，这些订单的最大可齐套数量就只能是0, 当然也不用扣减库存。

6. 齐套核心内循环： 重复1到5步， 直至这天内所有订单的最大可齐套数量都被输出，结束重复

7. 齐套核心外循环： 根据订单的日期，重复 1到6步，结束所有订单的齐套计算。

以上的齐套核心计算的外循环次数恒定，就是订单所有的日期数，而内循环次数则是动态的，取决于有多少颗物料有库存瓶颈，也取决于有库存瓶颈的物料在各订单BOM中的状况。但最worse的循环次数容易估计，就是有库存瓶颈的物料的数量, 而如果我们回眸一下预处理后的数据，这个数据已经跃然而出了， 而在这里，我们可以看到数据预处理可以发挥的价值了

预处理前: 产品BOM中不同物料数量（unique part)：5K+
预处理后： 产品BOM中不同物料数量（unique part)：350

也就是说，内循环的次数不会超过350次, 那么我们再来推演下这个算法下的总循环次数和时长吧。


现在最worse 的情况是11个小时能完成运算，如果内缩短内循环的时间，同时不是BOM中的每个物料都面临短缺的情况下，运算时间是有望达控制在9小时，7小时，5小时，甚至在2小时或更短的时间内的。

5. ETL 流程及设计

这里的ETL工具用的是开源的KETTLE, KETTLE 是一个基本上无门槛的ETL 工具，简单摸索摸索就能上手，关键是我上面所提的解决问题的思路要清晰，才能在调试时比较顺利，并达成自己想要的输出。

6. ETL 运行时遇到的问题及解决

当我信心满满地运行ETL 时，新的没有意想到的问题出现了， 这就是我上面有所提及的，我对计算的设计一直从时间长度的优化在进行考虑，并没有空间长度限制的概念。 而实际上，至少对于KETTLE 的作业，在作业开始到结束的时间内，内存是不会被释放的， 而且不知道是幸运还是不幸， 在运行过程中我遇到了多种OOM问题：
堆内存溢出：Java heap space
栈内存溢出： StackOverflowError
GC溢出： GC overhead limit exceeded
由于自己在这方面还是小白，于是就请教了公司的全栈工程师，和外部的学习资源， 化了一个周末的时间对JVM的几个内存参数调了又调， 终于把所有的订单都跑完了， 同时得出总循环次数是3008次，总耗时约90分钟。

7. 运算设计的改进 （PART2 待续）

ETL 的运行虽然通过调JVM的内存参数顺利跑完了，但这并不是一个根本的解决方法，因为随着工厂订单数量或瓶颈物料数量量级的提高，就会有更高量级的JVM堆内存和栈内存的需求， 这样会带来硬件成本的增加，或因硬件的限制而无法完成运算。

鉴于此，我会做两个方向的改进尝试：

1. 继续用ETL工具作为运算工具，但尝试将循环分批次来执行， 这样，只需要通过设定批次的颗粒度，使得不同硬件配置的电脑都能有合适的JVM堆内存和栈内存来完成整个的运算。

2. 在理解JVM工作原理的基础上，理解齐套计算核心运算对JVM张堆内存和栈内存的影响， 找出时间长度和空间长度都相对优化的方式，直接写java 代码来完成运算。

第一种方式基本不需要额外的IT 或编程知识，只要有时间，应该很快能实现。

第二种方式需要很长的学习周期， 非短时间内能实现。

8. 结语

物料齐套运算的场景需求多种多样，有的场景需求远比我文中所说的要复杂，此文仅是抛砖引玉， 如果有对复杂场景齐套计算做个思考和有过成熟方案的同仁， 可以一起交流讨论。

对于我来说，物料齐套计算仅是我对制造业数字化思考过程中，遇到的一个小插曲，只是近期花了几个周末探索了一下，所以就把它作为一个引子，慢慢带出制造业数字化的众多话题，这是一个非IT，编程或算法的话题，但这是一个IT, 编程，算法能够发挥巨大作用的蓝海，所以就借助CSDN 这个平台，来慢慢发布我对制造业数字化的思想和实践吧。

二、我的数字化之路

在推出后面的章节前，我先介绍一下我是怎么走上数字化之路的， 我是于2013年走上工厂的技术经理管理岗位的，工厂的技术部在工厂的一大职责是作为工厂和产品事业部的桥梁，负责将产品的设计规范传递或解释给工厂的各工程部门，包括工艺，测试，质量等，使产品的制造工艺，软硬件测试，以及来料和出货检验等与设计规范保持符合性； 技术部门的另一大职责是负责产品变更的导入，保证导入时的质量，成本，进展达成项目目标， 具体就是作为变更项目的负责人，制定项目规划， 指派任务给工厂的其它职能部门， 并对各职能部门的工作进行跟踪和推动。
在以上的第一大职责中，难点首先在于我任职的公司是一家多产品线的集团公司，产品的设计管理平台众多， 就我们工厂生产的产品就有10多个管理平台，而且产品设计的图纸，文档管理和制造过程中的信息和数据管理需求其实是有很大的差异的，举个例子来说， 对于一个产品是不是带电池，由于产品的各个零件或组合件在多个供应商处生产， 工厂的ERP 系统一般只有最后组装部分的BOM 维护， 所以通常你需要通过这个产品的设计管理平台，去获取其完整的PBOM查看是否带有电池， 所以对工厂营运管理来说， 所以如何将众多设计平台上浩瀚的设计图纸、文档中embedded 的信息转换成生产营运随时想获取的信息并保持及时更新，一直是一个非常让人挠头的难题， 一个信息的错误可能会引起交货的延误，库存的差异，成本核算的错误， 甚至可能导致重大的质量，安全事故。 但是只要信息是经由人来传递，解释或管控的，就难免会有疏漏有失误，在七年多的经理岗位中，我很大一部分角色是救火员， 同事们也经常作为救火员在工作，而起火的原因往往是之前某个部门某个同事的小失误， 虽然在绝大多数救火之后我们也会组织lesson learn, 但前人挖坑埋雷，后人填坑救火, 同时后人又在日常的工作中继续挖坑埋雷的场景永远在上演， 生生不息。。。如何实现对数据的卓越管理？是我一直在思考的问题，也在我走上数字化道路后愈加成熟，对于数据管理我总结出的道法术器以及具体的产品主数据的管理实战案例，在实战章节有详细介绍。

在第二大职责上，我作为一个技术经理，在担任这个岗位的前半程，从一个对工厂业务和项目管理的小白，到逐渐熟悉了工厂和集团的组织和业务架构， 并在项目和部门的管理中， 提升了自己的沟通能力，资源整合能力和人才培养能力。 然而，在这个岗位的后半程，随着各种工作方式的建立，业务流程的成熟和固化，能改变的和优化的已改变和优化，而那些啃不动的骨头和阻碍组织进一步高效运作的障碍，阻碍同事从工作中获得幸福感的障碍， 却依然因组织结构， KPI 考核，企业文化等的诸多限制，顽固地存在，在项目管理过程中，看着我和同事们每天都挣扎在该kiss one’s ass 还是 kick ones’ ass的方式去推动项目，我开始对进一步激发提升团队的项目管理效率， 让团队和自己获取更多的价值感上遇到了天花板，这种无力突破的感觉直接导致了我长达三年多的日益强烈的职业倦怠， 以至于不堪承受其重而在2020年年初决定不再担任这个技术经理这个岗位， 转而划出相当多的时间去思索新的管理方式方法，也就愈发催生了我从数字化的方向上去寻找解决方案。
为了将自己的数字化构想和宏图能实现，本着自给自足的想法, 我在两位我心目中的大神的指点和引导下，学了javaweb 前后端编程， 并且随着数字化思想的架构不断升级，编程实现能力的提高 （不认为自己是个码农，而且自己也没码农那样精通编程的底层架构，我的编程学习完全是亦步亦趋于实现我的数字化想法为原动力和目的的）， 诞生了数字化合作平台。 平台本着通用，开放的理念，以及以解决组织内部的普遍问题为目标，已经经过了多次迭代。 到今天，我的数字化思维和数字化平台已呈相互融合，相互促进之势，并相信终将会带来企业营运带来全方位的质的转变。

顺便也介绍和感谢两大男神：其一是公司同事，资深全栈工程师，他介绍了我众多数字化工具学习的资源和开源软件， 提供了我很多编程学习的书籍，帮我在电脑上搭建了编程的环境，指导了我项目运行、提交和部署上线的方法，开放了他写的数字化项目的源码让我学习和应用。 其二是一位网友，我是在一个前端学习群问问题时拜他为师的，很幸运发现他也是一个奉行闭眼了才会不学习的全栈工程师，所以于我简直是志同道合，虽然未曾谋面，但早已认作是良师益友，学习中遇到一些度娘解决不了的问题或一些概念性的疑惑，都是向他来请教解答。

当我选择离开技术经理这个岗位时，我看得清楚的是， 技术部门没有我，技术部门是照样会运转的，会有其他人可以来接任技术经理的岗位，而实际上，我的继任者也无缝地接替了我的工作，她早于我进技术部门，资历和能力都不比我差， 同时她的亲和力也比我强，所以在她的带领下，我看到团队在同样的工作环境里的业绩和幸福感更好。

而我同样看得清楚的是，我的数字化思想是唯我所拥有的，我技术经理的后半程无疑是一直处于挫败感中的，但挫败感带来的思考成果以及由此的践行是我最大的资产也是我能给组织带来的最大的价值，没有人会像我那样把数字化当成是我的使命。是的，没有我，没有我构想和践行的数字化，工厂照样会运转，但也就是运转照样， 1 年，2 年，5年，8年， 10年，工厂的运转方式不会本质变化, 工厂是会发展，但发展的代价是更多的人力需求，以及每个人力不断递进地出卖工作时间，八小时以外的时间，以及节假日的时间，用于救火，用于填坑，用于kiss one’s ass or kick ones’ ass, 而有了数字化，一个组织真真正正地发展了数字化 ，组织的运转会从此不一样， 1 年有1年的变化， 2年有两倍加的变化， 3年会是个大变样，5年会是一个完全全新的运转方式，一个新的时代，一个每个岗位都能各尽其才去做有价值的工作的时代才会来临。