最近,我们开发的系统上线投入使用后,遇到了一些问题,其中有两个问题引人深思。
问题1 合同号填写不规范
1.1
问题描述:
合同基本信息登记是合同管理的第一步,所有线上针对合同的管理活动都要指向一个明确的合同对象,合同基本信息是载体,它是所有合同扩展信息的生根之处,合同号是合同最重要的属性,它体现了合同的唯一性,是不可重复的。这个信息本职应该是PU专业输入,因为一些历史原因,MC专业协助PU专业做合同量单的时候也会顺便输入合同基本信息,自从合同支付款项流程与材料管理软件集成之后,MC专业发现合同号出现了不正常的输入,几个合同号连在一起被当做一个合同号输入了(举个例子:合同号A和合同号B是两个合同,系统里面出现了一个叫A/B的合同),还有的合同号就是一个“.”或者“-”。
1.2
产生的原因:
合同支付款项流程自从与材料管理软件集成后,PU部门秘书承担了部分合同基本信息的输入工作。排查发现,这类问题合同信息基本都来自于他们的输入,因为合同在支付款项的时候会出现几个合同一起支付的情况,虽然合同是多个,但是付款凭证只有一张,于是他们就把几个合同登记到一起了,这样凭证上传一次就可以了。“.”或者“-”这种合同号则是因为不明原因随手输入的,事后大部分作废,留在系统里成为了垃圾数据。
1.3
分析和思考:
最初看到这个问题的时候我的感觉是很憋气,即使对于一个不懂软件开发,但是天天做采购业务的人来说,出于职业敏感性,合同号的重要性不言而喻。当初规划整个系统数据流的时候,合同号作为合同的唯一性标识,是最核心的主数据,显然是不能随意组合在一起的,这样就破坏了他原本要表达的含义。举个例子,就像我们的姓名一样,虽然张三、李四都要参加考试,但不会在一张准考证的姓名栏写张三/李四吧。道理似乎很简单,但是要让用户理解却并非易事,一张付款凭证不能撕成两半分开上传,那两个合同使用一张支付凭证的话如何处理呢?
在软件不做任何改动的条件下,合理的做法应该是登记一个A合同,将凭证上传一次,再登记一个B合同,将凭证再上传一次,这样合同号的唯一性没有被破坏,凭证跟合同也实现了对应,漏洞是合同对应的凭证上还有其它合同的支付信息,但是在以文件关联而不是存储结构化数据的情况下,这样的漏洞不会导致数据错误。用户会这样做吗?我觉得不会,做一遍就完事的事情,不会做两遍,人的因素是软件应用中不能忽视的部分。但是我们也要看到信息化规划和设计是一个系统性的工程,总体规划设计者和某个角色的用户在视角上是不同的,为什么我们要强调合同号唯一的重要性,因为合同号是一切合同管理功能的基础,一个规划设计里有一些基本规则,在与其它的需求发生冲突的时候,应该根据规则的重要性来决定谁应该让路。用户只看到自己的界面是输入合同号和上传付款凭证,怎么便捷地输入完合同付款凭证是他们最关心的,合同号唯不唯一跟他们没有关系。这一点并不能完全怪用户,因为软件此时也没有给出最好的解决方案,此时用户做对自己最有利的选择是正常的,那么问题在哪呢?
我觉得问题的根源就是用户对信息化建设的理解不足,这也是传统行业信息化工作中最常见的困境之一,用户不知道整个系统的规划设计方案(以这个事情为例,参加需求调研会的都是部门领导和主工,实际使用系统的PU秘书从未参加过会议),也不理解信息化建设的目的,自己也不是(代表业务部室的)开发组成员,也许自身对信息化也毫无兴趣觉得信息化就是增加工作量(有这种看法的人在传统企业中比例很高)。
比如就这个问题而言,最理想的过程是,用户在一发现这个问题时就反馈给我们,一起讨论一个最优的解决方案,这个最优可能不是操作便利性的最优,但是肯定在保证数据正确性方面做到最优,但是用户没有把这个问题反馈给我们,而是自己想办法处理,结果破坏了数据的规则,直到被其它专业发现,反馈给我们的时候,问题已经很棘手了,因为错误的合同号已经上传了正确的付款凭证,数据产生了关联,如果删掉,已经产生的付款流程的数据就会发生故障。你说用户是不是不知道如何跟我们反馈问题,那也不是,界面输入的时候差数据字段这样的问题就知道联系叫我们增加,我猜测,用户自己能判断出来合同号如果不能连在一起输入的话,新的方案肯定会使输入更麻烦,于是主动避开了反馈这个问题。如果我是用户,我大概也会这样干,所以这个事也不怪他们。但是我们告诉他们不能这样输入合同号,并没有人理我们,A/B/C/D这样的合同号还在继续涌现。
事情进展到这里,我只能说有一点失望,材料管理信息化建设已经十年了,对于软件最核心的数据的设计方案,干系人之间的理解还能出现如此大的偏差,我竟然还在跟用户为这么粗浅的一个技术问题死磕,用户层面依然存在“我想怎么搞就怎么搞,不要跟我说应该怎么搞,你说的都不算”这种十分体制内的思维。是贯宣不够?还是参与开发的人员安排有问题,还是需求调研、开发流程、验收方法有问题,也许都有问题吧,说这是一个困境,一点都不为过。
1.4
更好的方案:
最初设计的时候并不知道会出现一个凭证对应好几个合同,所以设计上传凭证的时候是选一个合同上传一次。应该将这个动作拆解成两个部分,第一部分是登记合同基本信息,按照合同号格式要求填写,一个一个的登记合同基本信息,第二部分是选择合同,此时可以多选,将要上传的凭证对应的合同都选出来,组合成一个合同的集合,然后上传凭证,凭证对应的是这个集合。这样数据结构就符合实际业务场景了。
这也暴露出我们自身的问题,需求调研不够充分,不论怎样,要把用户的需求放在第一位,用户需求的变化倒逼我们做出改进,才能把系统打磨到最好。
问题2 对是否设置供应商信息初审的分歧
2.1
问题描述:
供应商门户网站上线后,供应商开始在供应商门户网站上注册信息,上传相应的资质证明文件,这些信息在供应商提交之后,我们设置了一个操作叫初审,顾名思义初审当然是对信息进行初步的审核,让经过审核的有效数据进入后面的工作流程,结果没有想到这个初审给我们带来了巨大的麻烦。
2.2
产生的原因:
用户觉得不需要这个初审环节,觉得我们为他们增加了工作内容,创造了新的岗位,无法给这个岗位安排人员,而我们觉得这个环节必不可少,没有创造新的工作内容和岗位,冲突就这样产生了。
2.3
分析和思考
为什么我们要设置这个初审的环节?这个操作学名应该叫数据的合规性检查。数据从公共区域采集后,一定要有一个过滤或者校验,这样做的意义有以下几点:
用一个形象的比喻,合规性检查就像一个一座房子的大门,大门都是装在客厅,没有人把大门装在卧室。
是否增加了工作内容和岗位?我觉得并没有,审核供应商的信息本来就是供应商管理工作中的重要内容。即使没有我们的软件,靠excel管理的年代,供应商信息也是有人审核的,这个工作职责在供应商管理工作范围内天然存在,并不是新创造的,而且现在利用信息系统审核,更加方便,所有的信息经过整理可以集中在一个界面上,检索查阅效率更高,数据存储在一个数据库中,实现集中管理,甚至将来还可以集成企查查之类的第三方数据平台,这是后话。至于有没有专职岗位管理供应商信息审核,我觉得如果以前有专人干,现在这个事还是他干,如果以前没有专职人员干,那这个职责肯定是由某个角色来承担,比如采买工程师、采购经理或者部门主工、主管甚至主任,那这个职责依然是对应的角色负责即可,不存在什么新的岗位,虽然我推荐有一个专职人员会更好。
2.4
最后的结果
结果十分尴尬,最后事情被丢回到我们手上,给我的感觉就是:既然这个是你们弄出来的,那就你们搞吧;把软件开发人员的电话往外面群发,球就算踢到我们这里了,我们反对也没用,因为我们说的不算(这句话是不是很眼熟?)。球踢给我们解决不了任何问题,我们的开发人员什么事也不用干了,一天接几十个供应商的电话,几乎都是问为什么还在等待初审,审这个动作只有业务人员能做,不论是初审还是N审我们都没有能力做,没人做,那当然都等着呗。
事情到这里,一起把这件事做好所需要的基础已经没有了,很难再向前推进,原因是多方面的,我反思最大的问题也许是在沟通上,我们没有让对方正确地理解初审这个环节的含义、重要性以及这个环节对整个供应商管理流程的积极影响。让用户精确地理解方案设计的每一个细节也是很重要的。信息化如果想进展到一个实质性的深度的话,决定成败的都是细节,如果没有处理好可能会把项目推入困境,本例是一个典型。
当然可以把数据合规检查这个操作拿掉,大家都省心了,厂家把信息一提交,直接就是初审通过进入潜在供应商名单,开始评审流程吧,至于填的是猫还是狗跟我们有毛线关系?
我们不会这样做的。
反思
3.1
有太多的东西需要反思了
3.2
对信息化规划的疑惑
在与用户沟通这些问题的时候,也暴露出用户对信息化规划的疑惑:
以上。
https://blog.csdn.net/xiangcns/article/details/89492864