前阵子考那个《企业信息系统管理》，这身为管理学的教材，通篇讲的都是IT系统的事，真可谓交叉融合，好在科目要求不高，大概懂一点就行了，在这讨论一下自家公司系统的问题也算是学以致用吧。
首先说一下背景，现在公司用的系统是2011年以后上线的2.0版本，一直运行至今也应该成熟了，之前吐槽都是各种故障、缓慢、卡顿。这次居然扯到系统基本架构了。我都不曾想过自己居然会跟IT部的争论如此深层次的问题。毕竟我是一个只懂业务需求的外行人，基础设计跟我是没关系的。在我将问题暴露出来说清楚之后，IT部承认那是设计上的缺陷，话说这漏洞居然藏了这么多年，也算不可思议。
这是个怎样的缺陷呢？简明了说就是物流行业的一份单子，上面有如收货人信息、件数、重量、以及各种费用等项目。其中有一项跟合作代理结算的“送货费”，是我部负责审核的，往常遇到系统显示的“送货费”跟代理那边不一致的时候，我们都能从变更、或则外发商申请修改记录等地方找到不一致的原因。可就在前一阵，我发现有一单的“送货费”，系统显示的钱比代理那边多，我查了所有变更的记录都没法解释究竟为何。于是将问题截图给了IT部，让他们查后台日志。
IT部从后台日志找到了原因，说是因为变更过程冲突了，话说这个解释很可笑，系统上线又不是三两个月，都这么多年过去了，居然没人察觉这个问题。跟钱有关的呀，好像财务每月对账的差异都被手工处理掉了一样。若非这次偶然发觉，天知道这个漏洞要何年何月才曝光。
IT说这问题根源是我们在审核费用，将费用减下来的同时，部门正好起草了一个变更流程，我们费用审完了，那单的流程还没走完。等流程结束之后新数据覆盖旧数据，我们减过的费用就这样被还原了。
I还说这问题很难解决，要根源上搞的话得推倒系统重新设计，工程浩大。简单避免冲突的办法是，只要那些单子正在走变更流程，即有特权不受我部审核。我作为部门经理，当即拒绝这种解决方案。缩减部门权力本身对我来说就很不爽，重要的是我不理解那个修改包装的变更流程，居然扯上了“送货费”，这两项有毛关系。所谓变更运单的同时禁止费用审核，在我眼中就是正确的业务需求为错误的系统设计让步，不可理喻！
后来IT部的另一个领导出面跟我解释，项目关联是有它的合理性，如地址修改，必然会导致送货费变化，最后总金额也会发生变化，为保证数据一致性，所以当初系统设计就是项目关联，每做一次变更系统就要重算一次数据，同一时间只允许一个变更是合理的。
若是一般人，被IT部那领导这么一说估计也就退下了，但我对IT部本就一股怨气，自己又有点底子，立马就看出了这番解释的破绽，他们根本就是在逃避当初错误设计的责任。我后来回了一段话在大伙的群里。
最后我提醒一点，如果系统真那么智能的话，改了地址它就会自动计算送货费，同时自动生成变更送货费的流程，这样的变更才算跟我送货费审核相冲突。而不是说，凭空变更地址，傻傻的不改送货费，也不允许人工干预审核！
退一步说，自动化想法是美好的，但业务处理应该是灵活的，改地址同时费用也可以不变，这看人怎么处理的。系统不够聪明的时候，应该允许人介入。担心冲突，就应该将冲突的项目单独列出来另外处理，而不是绑在一块，既不显示，又不让人介入。改了地址我都没见改费用，为啥不能审核费用？这明摆着就是坑人的。
话都说到了这份上，我相信聪明的领导应该懂得哪一方才是有理。考虑到修改系统底层架构工程浩大，而IT部那帮无能庸才又如此多，我就不奢求他们从根源上解决问题，吐槽这些只当是争口气罢了。
(暂无人赞)
Loading...