自上世纪九十年代开始实施商业银行计算机审计，至今已十年有余。从实践情况看，计算机审计在提高工作效率、发现大案要案线索、节约人力等方面都卓有成效，但这些与最初设想的计算机审计目标还有较大的距离，尚未实现计算机审计的模式化、程序化、系统化。主要表现在审计过程中，数据导入、结构分析、计算机模块编写依旧繁琐复杂，且需要大量时间。这已成为制约商业银行计算机审计发展的突出瓶颈，本文试就造成这一局面的根源作以剖析，并结合计算机审计实践提出解决思路。
一、商业银行计算机审计发展瓶颈所在
后台数据库的不统一造成数据导入工作的繁重。目前，各商业银行计算机系统主要采用DB2、Oracal和SQLServer作为后台数据库，而审计署计算机培训的主要是SQLServer数据库，且OA及通审这两种主要审计软件更多支持SQLServer数据库。因此，在计算机审计过程中，审计人员通常要将DB2和Oracal数据库中的数据导入到SQLServer数据库中，才能利用审计软件进行分析和检索。这就需要先从银行数据库中导出文本格式的原始数据和建表脚本，再将这些建表脚本在SQLServer数据库中运行，尔后才能将这些文本格式的原始数据导入。在不同的数据库中，由于同一数据类型的名称各不相同，往往需要审计人员对导出的建表脚本一一进行修改。更为繁琐的是，由于数据库之间固有差异，在数据导入过程中，还经常遇到诸如少列分隔符、数据格式不正确之类的问题。以上问题使得这看似简单的一进一出，操作起来却需要耗费大量的时间和精力，导致审计人员难以有充足的时间和精力去研究计算机审计更深层次的问题。
数据结构的不一致导致结构分析工作的繁琐。为了保证各自商业数据的安全，商业银行均在严格保密的前提下设计自己的数据结构。这些数据结构各不相同，并且，随着银行自身计算机系统的更新升级，数据结构也在产生巨大的变化。因此，在对每个商业银行实施计算机审计时，都需要重新分析该行数据结构，寻找系统中主要的表和字段等。例如，在某银行数据结构中存在“业务代码”字段，作为区分具体业务种类的主要字段，而另一家银行可能根本就不存在这一字段，而是通过“交易码”字段进行业务种类的区分。这样的情况下，以往编写的审计模块就无法直接运行，以往的审计经验也仅剩下审计思路。实现这一审计思路的方法就只有对数据结构进行重新分析，找出主要字段，重新编写审计模块。从而导致金融计算机审计案例的总结往往仅突出审计模块的编写，而在审计思路上则难以有较大的突破。
数据定义的不同限制计算机模块的推广。除了数据结构不一致会制约审计模块的推广使用之外，数据定义的不同给金融计算机模块的推广造成了更大的困难。笔者在审计过程中常常发现，各商业银行的数据系统中存在着一些名称相同的数据字段，表面看来其含义也相同，但实际上，其数据定义大相径庭。如上例中“业务代码”字段，某银行可能是有一个固定的代码划分现金提取这一种业务，另一银行则可能用一个代码对应包括现金提取在内的多种业务。这样的定义差异在审计模块开始运行时往往很难察觉，通常在结束后，审计人员根据审计线索进行进一步调查时，才发现运行结果中存在数据缺失或冗余。这就迫使审计人员必须推翻已经获得的运行结果，根据实际情况，重新分析数据、整理思路，查找关键字段，造成了大量重复劳动。
从上述分析可以看出，审计对象的不同，从根本上制约了审计模块这一计算机审计核心成果难以大规模推广的作用，导致金融计算机审计长期滞留在编写审计模块的阶段，难以抽出时间和精力理顺计算机审计的思路和流程，无法达到预想的运用效果。解决这一瓶颈问题，必须针对问题、抓住要害、另辟蹊径，探寻一条具有可操作性的计算机审计发展道路。
二、商业银行计算机审计发展思路
13888888888
点击咨询 