——由软件开发实践中遇到的两个问题看传统行业信息化的困境和对信息化建设规划的理解
最近，我们开发的系统上线投入使用后，遇到了一些问题，其中有两个问题引人深思。
问题1 合同号填写不规范
问题描述：
合同基本信息登记是合同管理的第一步，所有线上针对合同的管理活动都要指向一个明确的合同对象，合同基本信息是载体，它是所有合同扩展信息的生根之处，合同号是合同最重要的属性，它体现了合同的唯一性，是不可重复的。这个信息本职应该是PU专业输入，因为一些历史原因，MC专业协助PU专业做合同量单的时候也会顺便输入合同基本信息，自从合同支付款项流程与材料管理软件集成之后，MC专业发现合同号出现了不正常的输入，几个合同号连在一起被当做一个合同号输入了（举个例子：合同号A和合同号B是两个合同，系统里面出现了一个叫A/B的合同），还有的合同号就是一个“.”或者“-”。
产生的原因：
合同支付款项流程自从与材料管理软件集成后，PU部门秘书承担了部分合同基本信息的输入工作。排查发现，这类问题合同信息基本都来自于他们的输入，因为合同在支付款项的时候会出现几个合同一起支付的情况，虽然合同是多个，但是付款凭证只有一张，于是他们就把几个合同登记到一起了，这样凭证上传一次就可以了。“.”或者“-”这种合同号则是因为不明原因随手输入的，事后大部分作废，留在系统里成为了垃圾数据。
分析和思考：
最初看到这个问题的时候我的感觉是很憋气，即使对于一个不懂软件开发，但是天天做采购业务的人来说，出于职业敏感性，合同号的重要性不言而喻。当初规划整个系统数据流的时候，合同号作为合同的唯一性标识，是最核心的主数据，显然是不能随意组合在一起的，这样就破坏了他原本要表达的含义。举个例子，就像我们的姓名一样，虽然张三、李四都要参加考试，但不会在一张准考证的姓名栏写张三/李四吧。道理似乎很简单，但是要让用户理解却并非易事，一张付款凭证不能撕成两半分开上传，那两个合同使用一张支付凭证的话如何处理呢？
在软件不做任何改动的条件下，合理的做法应该是登记一个A合同，将凭证上传一次，再登记一个B合同，将凭证再上传一次，这样合同号的唯一性没有被破坏，凭证跟合同也实现了对应，漏洞是合同对应的凭证上还有其它合同的支付信息，但是在以文件关联而不是存储结构化数据的情况下，这样的漏洞不会导致数据错误。用户会这样做吗？我觉得不会，做一遍就完事的事情，不会做两遍，人的因素是软件应用中不能忽视的部分。但是我们也要看到信息化规划和设计是一个系统性的工程，总体规划设计者和某个角色的用户在视角上是不同的，为什么我们要强调合同号唯一的重要性，因为合同号是一切合同管理功能的基础，一个规划设计里有一些基本规则，在与其它的需求发生冲突的时候，应该根据规则的重要性来决定谁应该让路。用户只看到自己的界面是输入合同号和上传付款凭证，怎么便捷地输入完合同付款凭证是他们最关心的，合同号唯不唯一跟他们没有关系。这一点并不能完全怪用户，因为软件此时也没有给出最好的解决方案，此时用户做对自己最有利的选择是正常的，那么问题在哪呢？
问题的根源就是用户对信息化建设的理解不足，这也是传统行业信息化工作中最常见的困境之一，用户不知道整个系统的规划设计方案（以这个事情为例，参加需求调研会的都是部门领导和主工，实际使用系统的PU秘书从未参加过会议），也不理解信息化建设的目的，自己也不是（代表业务部室的）开发组成员，也许自身对信息化也毫无兴趣觉得信息化就是增加工作量（有这种看法的人在传统企业中比例很高）。
比如就这个问题而言，最理想的过程是，用户在一发现这个问题时就反馈给我们，一起讨论一个最优的解决方案，这个最优可能不是操作便利性的最优，但是肯定在保证数据正确性方面做到最优，但是用户没有把这个问题反馈给我们，而是自己想办法处理，结果破坏了数据的规则，直到被其它专业发现，反馈给我们的时候，问题已经很棘手了，因为错误的合同号已经上传了正确的付款凭证，数据产生了关联，如果删掉，已经产生的付款流程的数据就会发生故障。你说用户是不是不知道如何跟我们反馈问题，那也不是，界面输入的时候差数据字段这样的问题就知道联系叫我们增加，我做了一个大胆的猜测，用户自己能判断出来合同号如果不能连在一起输入的话，新的方案肯定会使输入更麻烦，于是主动避开了反馈这个问题。为了防止自己站在道德制高点上，我喜欢换位思考，如果我是用户，我大概也会这样干，所以这个事也不怪他们。但是我们说不能这样输入合同号，并没有人理我们，A/B/C/D这样的合同号还在继续涌现。
事情进展到这里，我只能说有一点失望，材料管理信息化建设已经十年了，对于软件最核心的数据的设计方案，干系人之间的理解还能出现如此大的偏差，跟准确的说法应该是也不屑于理解，用户层面依然存在“我想怎么搞就怎么搞，不要跟我说应该怎么搞，你说的都不算”这种十分体制内的思维。是贯宣不够？还是参与开发的人员安排有问题，还是需求调研、开发流程、验收方法有问题，也许都有问题吧，说这是一个困境，一点都不为过。
更好的方案：
最初设计的时候并不知道会出现一个凭证对应好几个合同，所以设计上传凭证的时候是选一个合同上传一次。应该将这个动作拆解成两个部分，第一部分是登记合同基本信息，按照合同号格式要求填写，一个一个的登记合同基本信息，第二部分是选择合同，此时可以多选，将要上传的凭证对应的合同都选出来，组合成一个合同的集合，然后上传凭证，凭证对应的是这个集合。这样数据结构就符合实际业务场景了。这也暴露出我们自身的问题，需求调研不够充分，不论怎样，要把用户的需求放在第一位，用户需求的变化倒逼我们做出改进，才能把系统打磨到最好。
问题2 对是否设置供应商信息初审的分歧
问题描述：
供应商门户网站上线后，供应商开始在供应商门户网站上注册信息，上传相应的资质证明文件，这些信息在供应商提交之后，我们设置了一个操作叫初审，顾名思义初审当然是对信息进行初步的审核，让经过审核的有效数据进入后面的工作流程，结果没有想到这个初审给我们带来了巨大的麻烦。
产生的原因：
用户觉得不需要这个初审环节，觉得我们为他们增加了工作内容，创造了新的岗位，无法给这个岗位安排人员，而我们觉得这个环节必不可少，没有创造新的工作内容和岗位，冲突就这样产生了。
分析和思考：
为什么我们要设置这个初审的环节？这个操作学名应该叫数据的合规性检查。数据从公共区域采集后，一定要有一个过滤或者校验，这样做的意义有以下几点：
- 减少垃圾数据，比如有人输入一个厂商名字叫“哈哈哈”，这是一条毫无意义的数据，数据会占据数据库的存储空间，一条垃圾数据并不会怎么样，但是供应商信息采集的内容很多，比如供应商简介、财务信息、供货范围、各类资质文件证明等信息，如果继续输入的话，所有挂在“哈哈哈”这个厂商下的附加信息都属于垃圾数据，这些垃圾数据增多之后对系统的性能有影响，占据了宝贵的存储空间，增加了检索有效数据花费的时间，而且后期查找和清理的代价很大。对数据进行合规性检查相当于直接将垃圾数据拒之门外或者打上了标记，后期集中清理的时候效率会高很多，策略做得好的话甚至还可以自动清理。
- 提高系统效率，最常见的工作流程可能就是审批，以供应商数据为例，供应商信息进入潜在供应商目录后就要开始进行评审和资格认定。一般能对厂家进行评审和资格认定的人，我们叫评委，评委多数来自有资历的员工或者是专业的技术骨干，很多已经是中层领导干部，可以称为工时成本高的用户。如果数据不经过合规性检查直接进入生产环境，会出现什么样的场景呢：某个专家打开待评审的厂家一看，第一家叫“哈哈哈”，第二家叫“嘻嘻嘻”，第三家叫“呵呵呵”，你说还评个什么东西？，纯属浪费时间，用好听的话说叫降低了工作效率，花费了专家查看数据的时间，却没有办法做出有效的评审，专家心里大概暗骂一句：什么狗屁玩意，估计这辈子再也不会打开这个软件。
- 建立互动界面，数据的合规性检查也是一个与厂家互动的一个界面，这个界面可以理解为一个交互的接口，不是单纯指一个网页，检查发现的问题可以通过这个界面反馈给用户，与用户之间形成一种信息的传递，并不是每一条不合规的数据都是垃圾数据，有时候数据不规范只是因为厂家没有准确理解数据填写的要求，例如：要求厂家填写近三年的财务指标，有的厂家理解为本年也算在内，其实本年是不算在内的，一般遇到这种情况，就可以通过互动把建议反馈给厂商，这个互动就可以借助数据的合规性检查这个动作来承载。
用一个形象的比喻，合规性检查就像一个一座房子的大门，大门都是装在客厅，没有人把大门装在卧室。
是否增加了工作内容和岗位？我觉得不存在，审核供应商的信息本来就是供应商管理工作中的重要内容。即使没有我们的软件，靠excel管理的年代，供应商信息也是有人审核的，这个工作职责在供应商管理工作范围内天然存在，并不是新创造的，而且现在利用信息系统审核，更加方便，所有的信息经过整理可以集中在一个界面上，检索查阅效率更高，数据存储在一个数据库中，实现集中管理，甚至将来还可以集成企查查之类的第三方数据平台，这是后话。至于有没有专职岗位管理供应商信息审核，我觉得如果以前有专人干，现在这个事还是他干，如果以前没有专职人员干，那这个职责肯定是由某个角色来承担，比如采买工程师、采购经理或者部门主工、主管甚至主任，那这个职责依然是对应的角色负责即可，不存在什么新的岗位，虽然我推荐有一个专职人员会更好。
最后的结果：
这个事情的结果十分尴尬，最后事情被丢回到我们手上，给我的感觉就是：既然这个是你们弄出来的，那就你们搞吧；把软件开发人员的电话往外面群发，球就算踢到我们这里了，我们反对也没用，因为我们说的不算（咦，这句话怎么这么眼熟？）。球踢给我们解决不了任何问题，我们的开发人员什么事也不用干了，一天接几十个供应商的电话，几乎都是问为什么还在等待初审，审这个动作只有业务人员能做，不论是初审还是N审我们都没有能力做，没人做，那当然都等着呗。
事情到这里，一起把这件事做好所需要的基础已经没有了，很难再向前推进，原因是多方面的，我反思最大的问题也许是在沟通上，我们没有让对方正确地理解初审这个环节的含义、重要性以及这个环节对整个供应商管理流程的积极影响。让用户精确地理解方案设计的每一个细节也是很重要的。信息化如果想进展到一个实质性的深度的话，决定成败的都是细节，如果没有处理好可能会把项目推入困境，本例是一个典型。
当然可以把数据合规检查这个操作拿掉，大家都省心了，厂家把信息一提交，直接就是初审通过进入潜在供应商名单，开始评审流程吧，至于填的是猫还是狗跟我们有毛线关系？
我们不会这样做的。
反思：
有太多的东西需要反思了。
- 用户的需求并不一定都是合理的，这句话要辨证的看，有时是用户的需求真的不合理，有时是我们没有领悟用户的真正意图，不论是哪种情况，双方都有一起把这个事情做好的诚意是最重要的，技术层面的问题从来都不是问题。
- 信息化规划不可能所有人都参与，但是要让所有人明白是很有必要的，这就是统一思想的重要性，我们该如何让大家统一和提高对信息化的认识和理解，这是一个严肃的课题。目前只能加强贯宣，要覆盖到每一个干系人，让他明白自己在系统中的权限、职责，明白做的每一件事的意义。
- 光统一思想是不够的，还需要强大执行力，虽然我们规划了数据的格式，但是输入的时候就是不按照约定来，那这个规划也就只是一纸空文。
- 沟通太重要了，但是加强沟通不是增加联络次数，而是要找到更好的沟通方案，用户在发现问题的时候应该如何反馈给我们而不是自己想办法对付过去，我想还是要靠加强用户对整个信息系统的理解。
在与用户沟通这些问题的时候，也暴露出用户对信息化规划的疑惑：
- 为什么我们用户总是觉得我们没有清晰的信息化总体规划，没有总体架构。首先我必须澄清，总体的规划和架构都是有的，但是深度确实没有达到用户的期望，比如有些规划只是停留在word或者excel里的一些条目式的提纲，或者是简单的系统功能模块图。我觉得这可能与我们的信息化建设方法有关，我们总是自下而上地进行信息化建设，这是最适合传统行业企业做信息化建设的方法，是由易到难的方法，因为最下端的业务场景最清晰，能在最短的时间内完成功能性建设；能不能自上而下的建设呢，理论上可以，先做信息化顶层设计，然后向下展开，这样的规划能做出来吗？如果要做到花拳绣腿的程度，可以，如果要做到像施工图的深度，做不出来的，因为业务场景不清晰，数据流不清晰。反观今天的知名企业，即使是IT行业，当初他们做信息化建设的时候十有八九跟我们一样，也是自下而上，先开发功能模块，然后经历信息孤岛、系统集成，平台建设这几个阶段，这是信息化建设的规律，我们得按规律办事。
- 有一些对信息化的认识需要纠正，信息化建设在管理范畴内最大的贡献是规范性而不是自动化，指望通过信息化实现工作内容全部自动化的那是生产线，规范性的前提是首先你的工作流程在业务层面要有效运作（注意这里不是仅仅指打通），这是一个定律，叫：“先有制度，后有信息化”。用户总想用信息化手段解决业务流程上的梗阻，结果往往事与愿违，上了系统之后原来的流程做一遍，系统里再做一遍，工作量翻一倍，这可能就是“信息化等于增加工作量”这个认知的出处。信息化是不是等于增加工作量呢？正常的情况下，应该是在短期内增加了工作量，这是系统和传统业务流程磨合的一个时期，是信息化必然带来的阵痛，最终流程越来越顺利之后，计算机归纳总结人的工作模式，逐渐提高自动化的程度，最终取代人的部分工作量，人的负担才会减轻，工作效率、正确性都会提升，这是一个长期和循序渐进的过程，不是一蹴而就的。
以上。
