常年玩控制，最终还是摔死在控制的道路上。侥幸心理在控制的道路上是致命，控制缺陷给了控制失效滋生的天然土壤。
事件回顾
周二，如同往常一般到办公室，开着电脑查收邮件，一切都是那么平静，没有新任务也没有问题邮件，窃喜中。。。突然间钉钉消息在闪烁，点开一看是采购同事老振给的消息，问银行回单不同的付款记录是不是回单号必然不同？果断回答“是的”。
隐约有种不好的感觉，立马追问怎么突然问这个呀。随即收到了他转发出纳给他的银行回单截图，仔细看了下为同一收款方、金额相同、回单号不同。立刻意识到出事儿了，马上到他办公室问清楚状况，有没有可能是巧合？
然想法是美好的，现实是骨感。经过核查，发现五笔货款重复支付。经过初步分析与查证，系重复打印付款申请单所致。
事情已然发生，快速分析了产生原因背后的控制缺陷及预防方案后，随即向自己老板汇报了此事。给出补救措施为采购部门负责协调供应商退回重复支付的货款；预防措施为控制ERP系统付款申请单打印次数与调整财务内部付款流程与单据流转流程。
事件处理方案得到首肯后，随即完成了系统控制设置与流程调整。
控制缺陷反思
表象为重复打印付款申请单所致，其实质是未能按ERP系统标准流程执行付款申请与付款支付业务记录。
采购付款业务现有的系统逻辑是：应付管理模块中先行参照采购订单或者采购发票填制付款申请单，而后付款申请单经过授权审批后，由出纳参照付款申请单生成付款单后执行银行指令提交付款，会计审核后填制记账凭证。
系统上线时也是如此规划这个子流程，然后因为出纳未能熟练掌握系统操作，把该由出纳先行在ERP系统操作付款单后，执行银行付款的作业不仅调换了顺序，还由会计代替出纳填制付款单并审核记账，就是因为一个作业节点的顺序颠倒，导致ERP系统控制重复付款的控制失效。
事后反思，就算重复打印付款申请单，如果是出纳或者会计收到付款申请单后，逐笔生成ERP系统付款单保存，重复打印的付款申请单也会因为无法再次生成付款单，而被系统识别。把重复支付的风险扼杀的摇篮之中。
失效的本质是控制链条断层了！
改进的控制措施及流程
付款申请单打印次数控制
事后迅速与采购部门碰头协商，付款申请单严格控制重复打印，每张付款申请单被获准只能打印一次。同时考虑到可能因为打印机故障，确需要重复打印时，设置了非首次打印密码验证控制，并由专人保管密码负责二次打印。
调整财务付款流程
事后严格系统规则执行采购付款作业操作，采购部门填制付款申请单，经过授权审批后打印单据传递财务部门付款。应付会计收到单据后，在ERP系统中逐笔参照付款申请单生成付款单，由出纳提交银行付款指令后审核付款单并在付款申请单加盖付款印戳。会计根据审核的付款单触发记账凭证生成。
总结
控制道路无侥幸，意识到风险存在时，切不该因为某个岗位人员技能的不足，在未采取其他替代方案时纵容风险存在。特别是在控制链条明显断层时，更应该反复进行控制成本与收益的效益评估。
记录此案例，以不断鞭策自己，防微杜渐。
共有条评论 网友评论