另外一个方面我们看看假设有一个审计公司，到你们公司做审计的话，要做哪些事情，有内部审计，外部审计。英文里面有个词语，一个是inspector，带有外部审计，请一个审计公司来帮助审计。还有auditor是内部审计。有三件事情要记住，说你所做的事，一方面是说文档化，要把你做的事记录下来。比如说人家来了，告诉人家你如何做软件开发。第二件事是做你所说的事。有一个企业说过CMMI，我们好像像应付托福考试一样，你的行为要一致的，你写了那么多文档，到具体的落实当中，你可能按照CMMI的0级来做，这个严格审计的话可以审计出来。最后就是要有能够证明两个是一致的。它的目的是看你的业务控制力度，到底和流程是否一致。这个控制的依据在哪里，常用的手段和问题呢，你的流程在哪儿，他需要看你的文档，人家需要备案。第二要衡量你的流程是否成熟，如何证明你的成熟，会拿你的历史数据来看，比方说今天来审计了，昨天才把文档写好了，他会看你这个流程是否成熟，是不是跑了一年两年的流程，一定有历史数据，这是一个稳定不稳定，成熟不成熟的证据。还有流程本身是否遵规，对你本身的流程进行检查。还有产出的流程与工件的关联性，还有提交的时候移交过程、签署过程在哪里，你交一个过程的时候一定要签字，在审计的时候这点很关键。一定要签字，在国外很认签名。在很多情况下需要签字的，把文档交到另外一个部门需要签字的，这是应付审计的。当然这个有好处的，出了事的话好查实。还有支持工具之间是否有链接性，集成性。如果你用的工具五花八门的，之间没有关系的话，那应付审计的话非常麻烦。他需要你有证据来证明。这样的话你很辛苦。还有你的测试结果与需求的关联性。这是审计人员或者审查人员，我们内部叫QA的过程，跟外部的调查公司有异曲同工的地方，他们会从这个方面入手。这些审查人员在什么时间进入你公司的现场，往往在公司出事的时候，美国的很多的公司为什么接受审查呢，是因为这些公司闹出丑闻，2001年安然是一个导火索。首先从三个地方进行审查，告诉你系统设计有缺陷造成这个事故，第二是不是人为的错误，第三是不是有恶意行为。一旦事故发生的时候，这些审查人员怎么样调查你。如果你软件本身出了一个Bug，你需要看一下是不是设计的情况，人为的错误，还有恶意行为呢，不能把恶意行为放在第一位。
所以我们讲遵规既是一个需求，有一些企业必须遵循它，也是一个机会，契机，借助这个大环境，这个推动力，帮助我们优化一个软件的开发过程。这个遵规表现在三个层面的体现上，第一要避免惩罚，要遵循这个规定，避免一些不必要的麻烦。很多企业的出发点从这里开始。然后在做好遵规之后，第二阶段很重要的是自我改进和持续优化。自己慢慢看这个规定生搬硬套的，循规蹈矩的做完了，看看有没有持续性的改进。然后量变达到质变的时候，充分利用遵规可以赢取业务优势。对于国内CMMI的遵循和改进的道路，我们发现很多的公司现在做到一个遵规以后，就不再往前走了。我过了CMMI几级之后，我该怎么做起来怎么做，我们真正没有从CMMI里面，或者ISO9000也好，没有吸取真正的精华的东西，去改进自身。只是考完了托福了，英语还是那样。然后你很难达到这个方面，不客气的讲，我的感觉以及看到一些数据，北京市过CMMI3的企业有多少，可能有上百家，但是真正可以承担的一千万两千万以上外包业务的究竟有多少。就会知道为什么过了CMMI那么多的级别，为什么达不到这个阶段，大概没有脚踏实地地做事情，这也是一个机会，就要靠大家如何抓住这个机会。
下面我们看看IT组织，特别是我们软件交付组织的遵规，有哪些具体的。刚才讲了这么多遵规的内容，到底要归结到IT系统上。现在查你业务的时候，基本上查你IT的应用系统。这是一些大的企业，一些咨询公司说过的话，比如说像KPMG头说的，任何审计都是IT的审计，符合规定已经变成它的需求了，还有可以符合哪些规定，应对哪些审查。这是我做了一些小规模研究，发现在IT上使用的一些标准和框架。很多都是大家很熟悉的，比如说CMM、CMMI，ITIL是符合IT业的标准，还有Six Sigma是项目管理的方面，还有国军标5000是做了CMMI一个汉化的标准。IBM自身有很多的方法和标准，IPD我们做产品研发的，IRUP是我们做软件开发管理的标准。很多成为业界公认的标准。比如说ISO9000的标准，因为9000太多了，现在大家知道ISO 900X里面有很多的内涵。还有COBIT，这边关于IT治理方面的，有一些东西大家不太熟悉。大家注意关注一下这些标准。包括COSO，主要是对内部审计的一个框架，更大的做整个IT治理的一个规范或者一个评价标准。这么多标准，同样IT的规范和标准，跟我们刚才看到的金融、食品、卫生的标准，实际上都是息息相关的，这边的遵规可以直接影响到业务系统的遵规，这个方面我们想看看开发对于遵规的影响。如果我们审计一个公司，具体的IT开发的遵规程度如何，很可能会问到这些问题。大家可以看看，就是说你的企业里面是否有这样的一个环境去记录和审计，来应对这些审计。首先谁批准了把这些东西部署到测试和生产环境，记录在哪里，签字在什么地方，然后签字的这些记录在哪里。然后当前测试环境下、生产环境下，部署的什么版本的构建，又是谁同意，谁做的构建。比如说给客户交付了1.0，然后客户说传输网络坏了，能不能重新传一下，对不起，昨天那个东西组合不出来了，只能给你一个1.1版，还在测试当中。你在构建当中，没有任何记录，还要重新构建一次。然后有哪些工件呢，提交的什么内容，这些东西在哪儿，工件之间的关联性怎么样，还有哪些源代码文件，可执行文件跟源代码的版本有哪些关系，如何编译出来的。我们做的软件开发做得很细致了，要落实到这些地方去，是很实用的。这些规定，这些东西看上去好像挺严格的，但是如果照着去做的话，一定会有好处的。你如果刚刚接触这个方面的话，可以照着去做，慢慢去消化。
|
服 务 CIO 推 进 信 息 化 
