问题说明
一个项目做请购单遇到两个问题，虽然问题不大，但很有代表性，这种细节问题在软件应用到一定的深度才会暴露出来，在这里分享一下：
（1） 有部分阀门材料名称带后缀（例如.LO）和不带后缀的材料编码相同，但是它们不能混用；
（2） 地管先期已经请购，但（地管的）MTO并没有进入系统，但是地管请购单里有部分材料标注了材料编码，后期对主装置MTO材料池进行抽料的时候，会将地管中已经有编码的材料减掉，导致主装置材料少买。
问题分析和解决
问题1
材料编码的一个主要作用是表达材料的唯一性，也就是说不同的材料编码不能一样，那么我们所说的这个不同是否有一个标准来衡量，什么叫不同，一般性原则认为两个材料有任何一个规格不同，即可认为他们不同，这个规格包括了名称、尺寸、技术参数等。这个原则在之前的数个项目中都顺利执行，但是这次意外，两个阀门一个叫VALUE GATE，一个叫VALUE GATE.LO，但是编码却是一样的，材控在做请购单时发现材料名称只有VALUE GATE而没有VALUE GATE.LO，这是因为我们的编码系统采用了编码库的模块设计，当一个编码被登记进编码库以后，再次导入时就不会重复登记了，所以第一次材料登记名称为VALUE GATE后，就不会再登记一个名称叫VALUE GATE.LO且材料编码一样的材料，请购单在引用编码库描述时全部读取的都是VALUE GATE，看不到VALUE GATE.LO的描述。
事后了解到这两个阀门其实是一模一样的，这个后缀大概代表阀门的操作状态之类，出厂时设置好，目的大概是为了满足某些方面的技术要求，但重要的是，不同的状态之间是不能混用的。
所以我理解这个后缀并不是一个用于制造阀门的技术参数。做编码的人员估计也是第一次遇到这种情况，所以编码做成了一样的。这个案例暴露出了一个关于材料编码规则的细节问题：我们该如何设计材料编码规则，是不是所有的技术参数对材料编码都有影响，如果两个阀门的所有制造用规格参数都一样，理论上着两个阀门就是完全一样的，但是非制造用规格参数导致这两个阀门不能混用，这时如果两个阀门编码完全一样，那么材料编码就没有起到表达材料唯一性的作用。
虽然我们采用了一些土办法解决了问题，但标准的解决方案应该是为这两个阀门做两个不同的编码，这个案例提醒我们，材料完全一样（使用相同的编码）的定义至少有两条：
- 规格完全一样
- 可以交换使用
问题2
材料编码的另一个主要作用给系统提供自动批处理的数据操作对象，例如自动生成请购单就是一个对材料编码十分精巧的应用场景，以后我会再介绍这个自动生成的原理，今天我们先介绍这个生成领料单时暴露出的问题。
对于工程项目，地管先期施工是常见情况，往往地管施工时期，详细设计还没有做完，PDMS模型还没有建好，不可能抽出带有编码的材料表，于是我们的材控人员会先拿着一个数出来的Excel材料表做地管的材料请购，这个数出来的Excel原始数据可能来自设计专业，由于种种原因（从PDMS里导出的半成品）带上了几个材料编码，于是请购单中就有了这几个材料编码。到这里似乎都没什么问题。后来主装置的MTO完成了，导入成为材料池，从材料池抽取材料做主装置的请购单。做请购单的时候我们有一个精巧的设计就是自动汇料的时候系统会减去已经买的量，自动计算出还没买的量，列在新的请购单里。问题来了，例如（随便编个编码）叫PE0022366的弯头在主装置中设计了5个，结果正好有一个地管弯头写了编码，编码也是PE0022366，系统做出了它认为正确的操作，用最新版本的设计量5减去已经请购过的材料量1等于4个，主装置的请购单就买了4个该规格的弯头，结果主装置少买了1个。
上面这一大段啰嗦总结成一句话：系统把别处已经买了材料当成了己处已买材料导致本该买的材料量遗漏。
这个问题上系统似乎并没有错，它按照我们给定的计算方法计算出了数学上正确、逻辑上错误的结果。那么这个问题的错误在哪呢，我给它起了一个名字：数据污染。地管材料中的有编码的材料污染了主装置的材料表，导致主装置汇料操作时，遍历已请购材料的范围出现了非期望的部分（地管），计算的结果当然就错了。
地管的材料和主装置的材料就像两杯水，要想他们不互相污染，最好的办法就是把他们分别装在两个杯子里，形成隔离，解决思路：
- 最简单的方法就是地管材料不要带编码，和有编码的主装置材料区别开，这样汇料的时候系统自动处理有编码的材料，所有无编码的材料都略过，地管和主装置就自然分开了。
- 标准的做法的把地管的MTO导入进系统，这样量都在自己的池子里扣减，不要减到别人的池子里而且MTO的存在还可以为以后反向查询材料的偏差原因提供便利。
总结
这两个问题可以总结出以下几点：
- 数据结构的合理设计在信息化系统中的重要性，我们在设计数据结构的时候不但要从IT的角度出发，更要从业务层面去理解数据的关系、粒度，认识到不同类（对象）之间的边界，很多功能的实现离不开数据结构的正确设计，当然这是一个很困难的事，我们对数据的认识是循序渐进的，不可能一步到位，所以数据结构的设计会随着软件的迭代而不断改进优化，这其中会付出很大的成本；人员的经验也很重要，需要两栖开发人员，但是培养困难，如果公司不能加大投入和鼓励，就只能全靠情怀了。
- 业务部室参与深度的重要性，这些问题都是由业务部室的工程师发现并提交给我的，我感触到软件的成功离不开用户的深度参与，很多在软件测试阶段发现不了的业务层面问题只有在真实的项目数据检验中才能被发现，如果遇到一个支持软件应用并且喜欢琢磨思考的用户，使用过程中思考和发现问题，并与开发团队一起解决，软件就是这样不断完善进步的。有的项目业务部室用软件都是一副你欠他钱的表情，这个工作就很难做，因为他只会身体参与，心不会参与，身体参与都很勉强，更不会思考软件怎么用，怎么改进，发现不了问题，因为根本就不想多看一眼，可能发现问题了也当没看见，终于发现一个过不去的问题，马上扣上不好用、不可用、影响项目进度、耽误进度你负责？等帽子。这个问题根本原因是公司对信息化的认识没有统一，信息化的认识需要从公司层面培养，落地到基层，不能只是每次开个信息化会，上层领导或是某委员会之类在会上讨论讨论，做个规划设计，一线员工都不知道信息化是干嘛的，有啥用。提升信息化认识水平需要公司从各个层面宣传和引导，加强业务部室在系统开发和应用过程中的参与深度，让大家站在全局看信息化工作为整个公司带来的收益，而不是只看自己专业增加了多少工作量，设计协同、数字化交付这些新兴概念是工程公司前进必然要面对的事物，迟早有一天我们要将工作全部放在线上，那一天来临之前，所有人都要做好准备。