谈谈亲历的WMS、MES与ERP的集成之路(第一篇:初尝)

某夏 2020-10-12 09:10:25

上篇困惑每逢回想起至今尤寒，虽前路不明，也定要披荆斩棘，谁让你担当这现代化建设者，谁让你履行“消防员”的责任。

自然，我们抛弃了供方提供的方案3.人工处理的方式，理由也非常充分：数据量、单据量大，操作完一个系统需配备一定素质的人继续另外系统的操作，效率低下，出错率最高，且并非所愿，虽然大企业大批量可以这样玩，即便你玩得很开心，不乏人力，但是不low吗？很low，妥妥的，且以后的自动化述求何时能实现？不积跬步,无以至千里.不积小流,无以成江海。

方案1，我们将把需求的实现转嫁给ERP或WMS、MES厂家或者第三方，需评估以下方面:
1> 需求制定、开发、测试周期；
2> 没有接口的ERP的开发模式决定了难度，比如单据插件开发模式需要考虑单据量(功能考虑不周将导致周期与预算大大超出)，又比如按钮事件开发模式需要评估和制定操作功能标准(在世的众多ERP都面临单据有按钮操作，列表有操作，其他单据也能后端操作等等)；
3> 二次开发带来的升级、迁移弊端(如果开发带来严重影响升级或者升级包执行后二开失效请谨慎再谨慎，”消防员”宁赴死却承担不了灵魂的拷问啊。)。
4> 当然就是成本与维护的考虑了，初次预算下来起码需交付几十万，虽风险已转嫁，但维护、优化却受制于人，且重用性基本为零，更谈不上管理，IT决策者请试想怎么有效的管理及运维它，付出与得到差距甚远。

方案2，在此基础上，我们第一次最终无奈选择了它，确实无奈、请恕在下无能。此次集成部分全部由内部团队对ERP各个数据表以及关联表附写定时调度查询功能，以时间戳记录为筛选依据，进行了浩浩荡荡的数据转移到中间表。回写部分梳理了业务关联性，从少量数据传回前提下，去抓取上下游关系数据，回写ERP业务数据表。为时一月有余，战战兢兢地上阵。

此处谈谈为什么建议慎用触发器：主要原因是合理的触发器编写对设计者和编写者的要求很高，必须比较全面的分析相关业务，同时全面了解触发器工作原理。也就是说写出的触发器要求在业务上考虑全面，在技术上作到最好，才能不影响业务和性能。触发器也确实不容易被注意，给后期维护带来困难。同时业务往往需要考虑触发器的挂载，例如单据存在子表、孙表的时候需要验证业务系统事务处理的机制以及是否在事务中，否则数据不完整，逻辑不完善都会带来严重的后果，同时对性能和开销都要有一定的考虑，更有系统厂商鉴于触发器造成的数据混乱会告诫不在维护之列。

当后来我们还沉浸在完工的喜悦时，自觉得会不断的修复bug来完善此方案，现实的打击接憧而至：
1> 业务从开始1小时定时调度不满逐步转成30分钟定时、5分钟定时、1分钟定时甚至更甚，因为理由确实充分，生产在等数据才能操作。此时发现了越来越多的数据紊乱，天生的时序已经出现了各种问题，虽不断修复，但我们已经痛苦不迭，每日埋没在修改数据的事务之中，业务抱怨纷繁踏至；
2> 数据虽然在传输，但是业务之间始终没有相互制约，举个例子ERP采购订单下发后，A料采购数量100PCS，WMS供应商已经释放条码，包装，甚至送货途中，ERP因特殊原因变更了采购数量为80PCS，WMS何其无辜的说了声，你叫我修改的，好，那么修改后多余的20PCS后续会出现怎么对待的问题，此时WMS弥补性的再发声，我加一个校验返回到中间表不能修改，ERP再定时去抓取禁止ERP修改，长此以往，数据穿插交互犹如蛛网，IT每日都在头晕之中，谁来为这现实埋单？是制定标准用管理来约束？还是配备人员在不断的查证纠错修改工作中辛勤耕作？答案往往都很难具备说服力，限制功能往往带来更复杂的操作才能撤销和弥补，大量的维护也将得不偿失，效率低下。
可想而知在这一年多里，心有所绊，却非念想，何其无奈。IT外出团建都带着电脑，产线加班都有IT默默在陪伴。如果幸运的你在几班倒的企业，是决定做你的男人24小时不睡觉待命还是翻牌伺寝，当然也不乏乐在其中的人儿，想想兴许还有点其他福利，或者自觉得不可或缺。
就像夹在和田籽料里面的水石，虽外表一样光滑亮丽，但它终不是来自昆仑经山流水千万年岁月的沉淀，结果可想而知。

...全文