刘欣的优快云博客

从2014年潍柴汽车，整车计划员给我提需求开始，我一直在这一个细分领域尝试突破。昨天超级工厂生管计划员告诉我，我的程序帮助他们把每天的排产时间缩短了2个小时后，我觉得我在这个领域终于有所建树，并且取得了巨大的成功。

【摘要】本文回顾了作者作为项目经理在2023-2024年主导APS整车高级计划排程系统项目的关键突破：1）攻克超级BOM解析难题，开发7个程序实现3000零件精准校验；2）创造性提出Plan B方案，确保主计划功能按时交付；3）为物流团队开发高效齐套检查工具，至今支撑三大车间物料管理；4）打造"丝滑"混线排产系统，实现分钟级千辆整车排序。这些创新解决方案不仅保障了项目成功，更成为企业持续使用的核心工具，展现了作者在汽车IT领域的深厚技术功底和问题解决能力。

一旦我们有计划订单一车一单模型，计划部门的各种业务无外乎就是对计划订单数据做全生命周期管理，有了这样的颗粒度，我们可以轻松应对。APS系统覆盖销、供、产业务，提供的承接销售需求，编制生产计划，输出生产订单的功能。在IT系统中，应该建立相应对应数据模型，销售需求－销售订单模型，生产计划－计划订单模型，执行生产－生产订单模型。这些模型的颗粒度，应该要细化到一车一单，才能支撑销售模型，计划模型，生产模型数据之间的联动。如果我们对主计划数据建一车一单的“计划订单”模型，这样就可以应对计划部门随时调整计划的场景。

程序实现前的准备，收集网上的资料放这里，这样就不用每次到处去找了。

四、AI算法的运用与严谨程序逻辑不同，学习期长，只有时间段内最优解没有最终解。三、数据体量大（包含产品BOM），对数据质量要求极高、配置BOM技术壁垒高。二、服务器架构基本全自研，试错过程长，但生产环境对架构要求高。五、计划排产数据受制于业务现场，限制条件多，导致结果不如意。一、成功案例少，从业人员少，顾问经验少。

但其实他的诉求一直就在，是没有改变的，只不过他没有完全告诉我，而且在第四次，我如果不去找他更进一步深入了解，可能还是不能最终关闭，达成满足他的诉求。我在想，应该去全面了解他用这些数据是怎么工作的，然后我仔细问了志勇，他给我展示了他的物料推移表，在那个表中，有5个工作簿，BOM数据是在第二个工作簿，从第一到第四个工作簿，都是作为第五个工作簿“推移表”的数据源。第一次，年前的一次APS培训，刘志勇出现在会上，会后他一直没走，问我们他要查询BOM数据在哪儿有这个报表，当时我告诉他，XXX系统中是有的。

比如第一组7000KM进入了下一轮，我们随机改变它一点，从1，2，3，4，5，6，7，8，9改变为。第一步，我们自己定义计算规模，也叫种群大小（为什么叫这个，因为遗传算法是真正模拟生物遗传的元素），我们定义了100，就是假设100条线路，这些线路里面的数字数据，是初始化时让程序随机生成的，当然我们也可以定义20，就是假设30条线路，然后把数据初始上去，这些都是自己定的。这样的情况下，比如第一组从1到2到3到4到5到6到7到8到9，的总距离是7000KM。

2023年接到潍柴汽车信息领导的电话，聊到2015年在潍柴汽车工作时的系统，才发现当年的建设的系统已经没有剩下几个，感悟什么才是企业的核心数据和系统，首当其冲的应该是研发数据；而这一块在APS项目前，我理解得还不够，每次看到一鸣去处理接口BOM数据都属于观众，没有真正去参与，终于机会来了，一个新生的系统等我去处理BOM数据，我相信只要让我看到详细的数据，我就能够理解吃掉他。，就像雷布斯在发布会说的，其实你想的问题，很多都已经有了答案，只要你去问到那个人。三、整车订单下达接口的理解。二、整车调序程序的开发。

在APS中，我一开始也没有管这2两块，都交给你们在设计落地，直到上次你们内部被罚款了，虽然最终没有找到原因，陈帆也是鸭子死了嘴壳子硬说不是我怀疑的“订单BOM重读”与组件干预同时操作BOM数据冲突的问题；“订单BOM重读”在SAP中是标准提供的功能，SAP标准模块的东西都是很多年沉积下来的功能，这里面牵涉的东西很多，但还好它非常稳定，几乎没有需求要去动这块，其实也没几个高级顾问可以有完整的FS敢去动它。组件干预，在SAP中只是我们公司特定的自开发程序功能，它的程序逻辑可能只有“订单BOM重读”的百分之一；

几位一线的战友，包括乃文，你们的人品我觉得还是很好，因为不管什么问题，你们都能够如实相告。比如昨晚我吃饭回来，你们告诉我重读bom有bug，今天万福也如实相告有bug，我觉得我们建立了信任。这么重要的功能，处理海量数据，出错很可能是人工无法短时间挽救的。我也不要求完全不能发生bug，因为代码是人做的，人会犯错，而且我也不能把开发吃了。但是在生产环境，出现bug不能描述为“小”问题，我不也不知道领导会不会听你我们是第一次bug的借口。我希望你们以后告诉我，欣哥，大事不好了，我在测试环境误删了一条数据。

博主开发了一个程序，把两边的BOM数据拉到一起来比对，从最初的一个车型，增加到5个车型，最后成型是30个车型，几乎覆盖了F1、F2的全部车型。并且程序还实现了消息提醒功能，如果检查到有异常发生，会放到钉钉的内部群里，博主可以看到。SAP从CU50中解析了BOM。

当系统中有100个订单时，每个订单下BOM是几千个组件，这样的内存占用会一直增加，我们发现如果订单量很小，使用内存来存放还是很快的，但是如果订单很多，对内存的查询是会越来越慢的（我估计这个架构并没有用LINQ或并行遍历），而且内存资源也是很有限的。供应商的小伙伴带来了一个全新的架构，在服务器提供的服务中，有一个对象模型服务，就是数据内存对象；我对这个重度使用内存的服务架构做了安全测试，当接口传入系统一条数据后，数据会很快建立内存对象，然后持久化到磁盘文件中，所以数据放内存对象丢失的情况是没有发生的。

在SAP测试系统中，我们造了一条A的相同测试数据，又在接口程序中下了一个断点，跟踪程序，终于我发现程序并没有完全按FS写的逻辑操作数据，原来程序检查到系统中有特征后，并不是报错不做了，而且进入后面修改的BAPI程序段去修改了原有的特征。APS按这个逻辑来就出现了2个完全一样的特征，但我们发现SAP中却只有一个，SAP是我们想要的正确结果，但是和FS逻辑又不符合。今天，陈帆来找我，告诉APS系统中出现了2个相同的特征，因为PLM下发的2次特征设变，都是用的A标识。