信息化建设在管理上的“代价”.doc

[原创]信息化建设在管理上的“代价”(入选推荐日志,加10币)

笔者近日与在世界500强高科技制造型企业供职的一位Finance Analyst聊天,她主要负责Disbursement这块。出于我和她工作中的共同点,我饶有兴趣地跟她探讨一些关于支付的问题,当然她focus on业务处理,我focus on电子流程。其间,我向她假设了一种情形:

“假设出差在外的你应当地分公司一位销售的请求,给他协助一些事宜,由此你发生了本不该属于你的部分差旅费(如Taxi等),而你回来报销的时候,连同这部分费用一同填进了差旅费报销申请单,而实际上这笔费用在成本核算的时候应当列帐至那位分公司销售所在的部门。”

她的回答很精简:

“首先这种事情发生的概率很小,我们全球2万职员的公司,每年也不会发生超过5次;其次,只要是公司内部的账务,因为核算对象不同,会计自然会做处理。给会计便可。”

我想这么简单的一个问答来回是否能够给我们搞信息化建设的同仁一些启示呢?至少我在那晚想了许久而不能入眠。笔者做企业信息化应用也已经有10年了,对企业信息化咨询、设计、实施过程可谓深入根基,从中目睹了甲方客户那呼天不应叫地不灵的痛苦,更切身感受了乙方开发实施人员那种“对牛弹琴”似的绝望。这种信息不对称(Asymmetric Information)导致了信息化建设在管理上的“代价”。以下我就来细述一下这种“代价”的根源以及偿付方式。

“代价”的根源:信息化对传统流程的变革力被用户过高估量和期望。对于一些偶发事件或特殊事件,信息化系统不具备完全操控效力,而用户却认为只要有存在可能,系统就要有相应的解决机制。如此一来,系统的规范性受到了某些特定管理要求的限制,使得系统业务逻辑变得不再清晰一致。其实,纵观大小系统,一旦由于某些特殊管理要求而引起的二次开发或改造,造成的结果其实未必是系统功能的完整性,而是系统逻辑的模糊进而引起的后台数据规范性的影响以及业务逻辑冗余;另一方面,在用户实际使用过程中,也未必带来较好的体验,因为我们的用户在不同的职位仅仅是business operator,puter operator,为了某一个偶发事件而去多了解一个控件乃至一个模块的使用,对信息化的应用未尝是件好事。

“代价”的偿付方式:尊重普遍性。这五个字看起来很简单,其实在