谢邀。不过说来惭愧，虽然我也算是会计科班出身，但多年来主要是在计算机领域工作。唯一能跟审计沾上边的，就是从2004年开始的讲授高校信息系统审计(IT审计)课程、给银行做IT审计咨询，以及后来曾经短期在TD银行做Senior IT Auditor的经历。所以我就单纯从IT审计的视角介绍一下自己的感受，算是对前各位的精彩回答的补充。

一般说来，审计过程主要包括 审计规划、风险评估、控制测试、实质性测试、审计意见与报告几项。如果按照工作内容和处理方式分类，我们可以把这几项工作大致分为文档类和数据类工作，然后看一下对于不同类型的工作，VBA可能会有哪些作用：

(1)数据类工作：控制测试、实质性测试。先说具体一点的业务，也就是各种测试。无论控制测试还是实质性测试，还是我们经常遇到的搞不清楚算是这二者中哪一种的测试，归根到底都是信息或数据的比对、复核。如果碰巧这些信息数据被存放到Excel中，那么VBA就有可能发挥出独特的优势。

比如我在银行做IT内审时有一个例行工作，就是每个月都要把当月最新的雇员信息表，与上个月的雇员信息表进行比对，排查出所有离职员工(存在于上个月但不存在于本月)和所有新进员工(存在于本月但不存在于上月)的名单，再将这些名单与各个信息系统的活跃账号比对，以便发现已离职但未销号等异常情况。这种比较应该算是Excel最基本的功能，用VlookUP、PivotTable等都可以实现，我的同事之前就是使用VLookUp来做的。但问题在于，我们的要求并不是简单的对工号进行比对，有时还涉及到其他多个字段，比如员工并未离职，只是更换了部门，也需要把他找出来检查系统权限。所以我看到他们之前的公式都写的比较复杂。不过最可怕的地方在于，我们的员工名单平均都在9万人左右，因此将两个员工逐条比较时，最坏情况可能需要比较几十亿次，运行时间无法忍受。所以我当时看到的情景就是：同事复制好公式，然后把电脑锁定、贴一张便签提醒自己不要碰它，接下来就去做外勤，第二天早上再来检查结果。

我接手后，第一个思路就是把这个工作转移到Access中，用数据库来提高效率。所以我把这些数据存到Access表中，并且给关键字段加了索引，然后做SQL语句来解决。测试结果，性能虽然比VLookUP提高很多，但仍然让我无法接受。并且经常需要根据项目要求去修改SQL，非常繁琐。所以我最后还是决定用VBA做一个通用的工作簿比较工具。(这类工具网络上也有，但是银行内控很严，不太可能批准购买使用)。

于是我做了下面这个VBA程序：每次运行时都会弹出一个窗体，提示选择待比较的两个Excel文件或一个Excel文件中的不同工作表。可以在窗体中指定要比较的工作表名称、用于比较的一个或多个列的名称、以及每个列在比较时，是否忽略空格、是否忽略大小写等选项。最下面还提供了一个利用了Excel内嵌排序功能的算法优化选项，如果选中，那么就会启动优化算法，时间复杂度可以从O(n2)降低到O(n)。也就是说，对于9万员工的数据，大概只需要几十万次比较而不是之前的几十亿次比较。

这样，选好关键字、设置好比较选项，只要按下按钮，很快就会得到一个新的工作簿，里面用多个表格，分别存放了“只存在于表1”、“只存在于表2”、“同时存在于表1表2”等所需数据：

写好并测试通过后，我们Team后来各种涉及到比对的工作，都是使用这个工具完成的，不需要再费劲脑筋编写和测试公式、也不需要再等待令人发指的运行时间了。

当然，我相信对公式或Pivot等进行优化后，应该也能大幅提高性能。但VBA的优势在于你可以按照自己的业务逻辑编写“通用性”的程序，而且可以根据自己的需要把任何独特的工作需求编成代码，所谓“一次编写、多次运行”(具体关于VBA和公式的比较，请见我的另一个知乎文章：公式 vs VBA，到底该选谁？ - 知乎专栏)。我觉得这对从事具体业务的审计人员还是很有意义的，毕竟审计充满了大量枯燥的重复劳作，长期搞下去很容易让人发疯。

控制测试中还有另一种情况也会用到VBA，就是基于Check List的控制评估模型。2002年我刚接触IT审计的时候，就看到过一个普华的IT基础设施控制测试工具。其实就是一个Word版的Checklist，不过使用VBA做成了类似网上常见的心理测试题的形式，每次只显示一个Checkpoint，然后根据你对这个点的评估结果，自动筛选并跳转到下一个check point，直到最终得到评估结果。

此外，尽管Excel或其他审计软件中已经提供了大量功能和公式，用来处理各种常见运算比如折旧、年金等，但在控制测试或实质性测试中总会遇到一些特殊计算。比如我的一个审计署的朋友曾经在审一家城市银行时，感觉他们的企业利息计算模块有可能与财政部文件不符。但因为无法直接查看相关系统的源代码，而企业利息计算模型的分类又很复杂，所以他最后只能自己参照相关文件编写一个小程序，实现了最核心的企业利息模型，然后用这个程序把所有企业客户信息跑了一遍，成功定位出银行计算错误的企业信息，最后倒推出银行系统设计出错的点， 使银行不得不承认并且接受了代码审计。

(2) 文档类工作：审计计划、风险评估、审计报告。编制报告、划分风险点、出具审计报告等都可看做以编写文档为主的工作(当然，风险评估中可能会用到一些简单的计算)。对于全面采用计算机审计系统的企业/事务所，这些工作流往往已经固化，我们只要在公司的系统里面用鼠标点选各个适配的风险点，它就会自动替我们生成全套的审计方案。在这种环境下，VBA一般没有什么发挥空间。

不过凡事都有例外。在我接触过的范围里，能够将内部审计流程全部自动化的企业基本都是大型银行和成熟的国企，因为他们的业务流程已经十分稳定，同时又有严格的内控要求和足够的资金实力来支持这种系统的开发。但我想可能现在还有很多其他类型的企业仍然需要自己动手、为每一个审计项目针对性的开发审计计划和风险模型。另一方面，即使已经实施了自动化系统的企业，也会面临系统中未曾涵盖的新业务、新模型的审计。这种时候，VBA就可能成为审计经理的有力工具。

再举一个自己的例子。我在银行做IT内审的最后一个月，刚刚结束了上一财年的SOX，各个Team都开始规划下一年度的审计计划。按照公司的战略，下一年度将在多个Team中全面采用COBIT的审计模型。如果大家不是做IT审计的，只要知道Cobit就是一套PDF文档，里面很宽泛的概述了企业中各种常见的IT风险点、评估指标等等。大概就是下面的样子：

问题在于，Cobit文档中列出的控制点有210个，对应测试指标近千。而我们需要把银行中被审计单位的每一个风险点，都分别与这200多个控制点逐个匹配，最终做出下面这样的Excel表格(保密关系，里面所有数据都是自己瞎填的，与银行无关)

由于公司使用的审计系统完全没有考虑过Cobit模型，所以上面所有这些工作都必须人工完成。同事的一个Team试了一下，3个人用了2个星期，才勉强规划好一个审计项目的风险点表格。而他们大部分时间，都浪费在反复的比对文档、填写单元格、表格排版等琐碎操作上。我不止一次看到那个意大利哥们在小会议室里面，郁闷地对着投影拼命揪自己头发的样子。

于是我主动跟Senior聊了一下，然后用业余时间，开发了一个VBA程序，将所有操作全部电子化，大家只要对着屏幕一边讨论一边点按钮就可以了：

首先，将银行自己的风险点逐个填入：

然后，直接双击某一个银行风险点的所在单元格(比如双击D5单元格)，就会弹出一个GUI窗体界面。里面列出了Cobit中所有控制点和描述。如果觉得某些控制点与这个银行风险点匹配，直接用鼠标挑中，最后按一下“Add Selected ” 按钮就可以了。

按下按钮后，窗体消失，而我们选中的各个风险点则已经全部被自动导入到表格中，并且VBA会自动完成单元格插入、合并、拆分等排版操作。

如果想查看某个Cobit控制点的更多内容，也可以在刚才的GUI窗体中按下中间的“See Details In PDF” 按钮，VBA会打开Cobit的PDF文档， 并直接跳转到指定页面：

这样，Team members只要对着投影，一边讨论一边按按钮，就可以确定最终的风险计划。讨论结束后，只要按一下“Export Map Reports”按钮，VBA就会自动生成三份最终报告并保存到一个新的Excel文件中。这些报告的本质是相同的，但是视角完全不同，因此报告格式也各不相同。

经过我们Team的试验，与同事Team同样规模的项目，我们2个人只用了4天就全部完成。而且可能因为不用为排版等琐事闹心，我们的讨论效率更高，匹配出来的计划也更加合理。所以在我离职前的一周，Senior安排我们做了几次报告，把这个工具推广到了各个Team。前几天与老同事聊天得知，随着银行间的人员流动，貌似这个工具已经流传到了好几个公司里。

最后发几句感慨。其实如果大家会任何一种工具，比如Java、Python、C#，都可以做的更好更快。不过之所以大家都强调VBA，是因为一方面它比上面的工具更加简单易学、并且与Office结合紧密、就是为Office而生；另一方面，在大多数内控严格的企业里，恐怕VBA是极少数没有被禁止的、可以做些自动化工作的Windows工具(其他的还有VBScript、PowerShell等)。当我在银行报到并领取了电脑时，被告知不能安装Java/C/C++/Python等各种工具时，我几乎当时就想辞职。所以等坐下来打开电脑，发现Office里面的VBA编辑器居然还在时，眼泪都要下来了。

最后，也是我觉得最讽刺的一点是：尽管我们在做审计时非常愿意使用VBA来提高效率，但是在IT审计理论中，VBA这种东西被称作“End User Computing”，是IT审计师必须提高警惕并要求用户尽量避免采用的技术。因为非专业的程序员编写出来的程序，总会被认为存在漏洞、可能导致计算错误和安全风险。所以我当时一边自己享受着VBA，一边还要时刻提醒客户不要使用VBA，最后终于熬不下去，辞职开课专门讲解VBA去了。