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