法规遵循已经成为我们生活中的一部分。几乎所有的业务都会直接或间接的被标准与规定所影响。例如,在美国,所有业务必须符合 Occupational Safety & Health Administration (OSHA) 规定。
在 Sarbanes-Oxley、BASEL II,以及其它强制管理美国和国际商业的时代,执行遵从管理战略的理由日趋明显。首先,不能忽略关于法规、标准和政策的遵从,因为这是经营业务所必需的。 如不遵守,依据第三方审核,企业的业务将会受到严厉惩罚。公司坚持通过审核的能力将最终确保遵从要求。为通过审核,企业不但需要提供遵从的证据,而且这些证据必须容易获得和理解。我们将这个称为"可审核的。"
为了创建并维护可审核的遵从证据,企业需要适当的控制过程。因此企业的职责就是研究那些管理它们业务的规定、标准、和政策,以有效管理他们的投入。
最后,IBM Rational Compliance Management 策略能够帮助企业实现以下目标:
•软件周期中的强制性业务和技术的控制
•促进尽可能少的干扰性控制,以此作为非常好的使用方式
•利用控制作为IT治理的基础
•提供业务优势机会
使用Rational Unifed Process®,或 RUP® ,以及特别为支持法规遵循管理的RUP环境所设计的插件(RUP for Compliance Management),可将这种策略传递至企业。
什么是法规遵循?
一般说来,法规遵循需要完全理解规定、政策,并完全理解满足性能、遵守程序性要求的意义。
规定、标准和政策
开展业务经常需要遵循许多规定。如图 1中所示的规定和标准。规定往往具有以下共同特征:
强制性: 监管当局可能要求资质和/或某种特定标准,并明确规定针对不符合要求的惩罚。
非指示性: 监管部门往往会定义要做什么,而不会指明如何做。
持续性变化:公司政策的规定可以在不同的时期经常性发生改变。
不断增加的IT影响: 少部分规定与IT直接相关,但正不断影响着IT系统。
非担保性: 代理商一般不赞成、推荐,或确认某种方案。
相关危害性: 监管机构推荐一种基于完全评估风险的方法,这种方法可以预先确认所有的风险。
这些特点提醒我们达到领域内的要求是复杂的,且需要不断进行管理。过程标准企图将当前良好系统实践与质量设计的基本体系作为业务操作的一部分。这种体系的集成从本质上说就是审核员和检查员在审核或视察过程中要做的。
图 1: 规定与标准的实例
为确定规定和管理遵从要求,执行官经常需要定义IT应用与过程中所执行的业务控制。在这一过程中,他们寻找那些可以为企业提供过程体系的标准,诸如集成的能力成熟度模型(Capability Maturity Model Integrated ,CMMI) 或 ISO 900x。通过执行这种体系结构,业务就可以执行这种过程,变更控制和测量可创建满足法律与规定(例如那些与FDA,SOX,HIPAA有关的)的控制类型的机制。实际上,大企业会执行各种体系的复合体,例如IT Infrastructure Library (ITIL) 和 Control Objectives for Information 和相关的技术(COBIT)。
法规遵循意味着什么?
在较高的层面上,法规遵循需求可分为两类:
•执行要求 证明了支持某种特殊政策的交付功能或执行任务的能力。例如,特殊的审核日志数据,或金融记录和相关政策的格式化命令。
•程序性要求 证明了坚持文档化的操作过程--例如, "老板有责任适时确认职员的身份。"
企业依靠他们自己的法律顾问和风险官员理解规定,并将这种理解代入企业政策中,这就决定了在开展业务中对于控制的定义。
这种遵循是如何建立起的?
本质上说,在商业中建立法规遵循包括执行法规遵循的方式,获取实际法规遵循确认。让我们仔细想想这些。
审核员、审核和可审核性
审核员的职责就是评估法规遵循。他们一般是法规遵循体系的中立者,这表示只要选择理由是具有证明文件的且公平的,他们将不会偏向任何一种标准。对于建立满足需求的执行和过程要求的企业来说,它必须为审核员提供实现的证据。最后,法规遵循在很大程度上由企业通过审核的能力决定。
审核员往往追寻同种类型的信息:
•具有证明文件的针对业务工件所创建的过程
•由工件创建者定义的过程
•有效的过程自动化
•由工具指导所支持的过程之间的链接
•配合业务过程步骤的工件之间的链接
•针对交付链中重要点的工件可追踪性
•报告的透明性
•交付链中的可说明性
•系统中工件的认可
根据法规遵循域的复杂性,如果不能容易地获取需求证据或是不能保证其真实性,一家企业是不可能成功通过审核的。如果过程满足这些标准,它就具有了"可审核"的资格。 审核过后并不意味着企业是合格的,它必须使审核易于管理,并且比较容易解决差距。相反,再没有比当一家公司实际满足监管要求却不能让审核员相信,从而失去鉴定资格更让人丧气了。
企业的法规遵循
当审核对于实现大部分规定、标准和政策来说十分重要的时候,审核本身恰恰是不充分的;任何要求可能都会包含某个企业所没有实现的要求。企业化的法规遵循指出了获得某种标准、规定或政策(例如ISO 9001-2000, SOX)的法规遵循认证。
法规遵循管理: 一个旅程
承诺遵从的企业往往可以获利,但半推半就的承诺或是过度的遵守规则是弊大于利的。
收益
企业早期的收益是获得了透明性与授权。建立法规遵循管理的实践与控制将有助于明确角色及其责任,且有助于帮助员工理解如何非常好的化的增加项目附加值。他们还可以作为一种提高员工效率、转换企业运作方式的方法。
除此之外,支持即时更新记录、使用适当工具还提供了针对项目状态与性能的管理,并赋予管理团队在项目与过程中增加控制的职能。自动化的法规遵循管理过程增强了透明性。
当今天人们已广泛接受搞笑过程是重要的这一观点的时候,旧有习惯依然难以改变。许多企业规模很小,以至于结构化的业务过程被认为是弊大于利的。当这些企业经历了成功并快速发展时,严重的过程与质量问题(例如,缺乏质量)就会暴露出来。此时,经常会难以重新考虑过程模型,难以获取关键员工的支持以改变目前工作良好的过程。外部强加的法规遵循可能有机会推动一个年轻的企业的优势,使之逐步完善,启动其重组进程。
一些反模式
但明确有一些企业应避免的法规遵循方法。
首先要避免购买交钥匙遵守管理办法。因为达到并管理法规遵循将会是复杂且代价高贵的过程,其中的诱惑就是去找现成的答案。从长远来看,这样很少有效果。法规遵循过程首先要编纂现有过程,将其放入必须的机制中使得它们满足标准、规定和政策的需要。
法规遵循往往是复杂的,代价高昂的,没有重大贡献的底线-- 仅仅是多做的工作。因此可以试图"造假" -- 就是说,可以在审核时期利用某个特殊项目将企业内部和外部装扮得满足法规遵循。虽然这种方式也许短期有效,但这是不可持续的,原因如下:
•这种策略代价高昂,每个审核准备就要从零开始。
•除了表面上的东西,该企业将不会从法规遵循中获得重大利益。
•企业不能建立起一套连续的追踪记录。
•这种策略对于企业文化会产生负面影响,因为企业员工会将其大量的时间投入到他们并不能理解与接受的规定及行动中。
最后,企业必须避免以法规遵循的名义进行过度的控制。由于法规遵循管理往往会增加现有过程的控制,任何努力的成功(例如,通过审核)都可能被理解为对于控制IT所有方面大开绿灯。不幸的是,这种策略将很快达到报酬拐点。当企业管理法规遵循时,企业必须注意到它对于企业的影响。考虑以下不良结果:
•增加更多控制可能会增加对于灵活性的影响与实现代价。
•当员工发现自己花费越来越多的时间以遵从相关事物时(至少短期内他们不能照常工作),员工的效率与士气就会受到极大影响。有效的法规遵循管理必须时刻关注其对于IT的影响。
法规遵循管理的基础
有效的法规遵循管理涉及健全的法规遵循治理,与针对IT企业的基本过程控制。
法规遵循治理
企业往往发现他们自身处于这样一种状态,他们必须要满足多个标准、规定或政策。 对于客户定义的控制来说既不实际也没有成本效益。相反的,企业必须从企业高度建立起一套治理体系以从全局角度定位问题。图 2展示了一种可能的法规遵循治理体系的例子。
图 2:主动的法规遵循治理
法规遵循治理体系结构为以下内容提供了实现方法:
•分析标准和规定,源于对一系列政策的全面定位。
•明确要符合这些政策的法规遵循需求。
•组织法规遵循需求并按照次序排列。
•批准和计划法规遵循增强项目。这些项目主要分为三大类:
•开发IT过程控制的项目 增强IT过程。这些控制直接应用于IT企业以改进软件开发过程本身的精确度 -- 例如,足够的项目跟踪、记录,整个软件生命周期都已具备的审批手续。
•开发应用控制的项目:这些控制用以构建企业IT系统,他们已成为监管的或是基于标准意义上的软件需求。例如,一种应用于人力资源(HR) 企业的普通控制用以"限制访问分类员工数据。" 这种控制利用使其成为所有HR系统的软件需求实现了自动化。
•IT 过程控制自动化项目: 这些项目处于开发IT 过程控制与开发应用控制的交合点。他们包括了使用(经常是商业)工具以实现自动化的工作流,并管理IT过程的产品。 这些项目要实现"工具指导行为" ,部分过程被强制加入工具本身。
IT 过程控制的基本原则
我们这里所介绍的控制对于IT过程的可审核性来说是极为关键的,因此是法规遵循领域的基本原则。他们是:
•正式列入并附有文档的过程。在审核员可选的各种任务中,他们往往首先选择熟悉企业的软件开发过程。因此,详细的法规遵循资产清单应包括现有过程的文档。
•工作产品控制。这是一种依据特定过程生产的工作产品所指定的工作流控制。这种工作流描述了修订的概况及最终满意的工作产品。
•记录控制。 记录是种只写一次,只读的文档,它提供了正式的所实现内容的依据。记录控制指出了哪些记录是必须有的,如何产生的,哪些人有权利创建它们。
•可追踪性。 工作产品并不是独立开发或凭空产生的:他们具有依赖性与关联性。 追踪的目的就是确保相关工作产品的连续性。
•法规遵循管理相关信息的分离 。 这由定义面向法规遵循的工作产品实现。这有利于审核且将控制集中于面向法规遵循信息。
•基于角色的责任分离。 这是高级控制环境的基本原则。它的基础是工件的开发、复查和使用不能由同一人执行,且可以质疑流程的公平性。
•正式的把关过程(定义控制点)。 随着项目与产品变得越来越复杂,单独的计划已不能保证实现全部项目目标。可以定义控制点以管理以下行为:
o确保满足重要标准
o评估为实现目标所做的决定及改变
o审核与目标(风险、质量、内容,等等)关联的度量
o由(与责任分开)接收者全面评价目标内容
o通过电子标签批准实现的控制环节。
应用于RUP的法规遵循管理规程
法规遵循管理的整体范围是一个长期的目标,已超过了单个项目的范围。 为支持软件开发项目,IBM Rational 公司首先倡议开发 Rational Method Composer (RMC) 插件以增强RUP过程体系的可审核性 -- RUP for Compliance Management Plug-in。 这种插件支持之前我们所介绍了过程控制实现。这将适应安全与控制都必须增强的高可信度条件下RUP的应用。图 3提供了为企业创建过程体系时的一些高级标准。
图 3: 为企业创建正确的过程级别
插件支持本部分所描述的法规遵循管理IT过程控制。
正式的过程
RUP 指出对于全面正式的特定软件开发过程来说,使用统一方法体系架构(Unified Method Architecture,UMA) 是一种产业旗舰和标准。它与其他Rational 工具(诸如IBM Rational Portfolio Manager) 的集成性使得它能够为其他过程管理工具导出相应的内容,从而支持过程自动化与工具导向的行为。
法规遵循管理工作产品
如下所列的工作产品已包含在本插件中。虽然他们中的大部分可被定义为现有RUP工件的一部分,但他们还是相互独立以支持可审核的过程控制。
•企业政策(Corporate Policy ) 反映出了一家企业对于规定的理解。它不是由过程开发出的,而是所必需的针对法规遵循需求开发的输入。
•法规遵循增强愿景附录(Compliance Enhancement Vision addendum ) 识别出核心的法规遵循需求,并由目标项目激发IT 法规遵循管理控制,总结确认过程满足控制对象的方法。
•过程验证计划(Process Validation Plan) 定义了一系列用来确认自动化软件开发过程实现了控制对象的测试。其中的一个例子就是工具定向行为正确的自动操作了过程。
•控制点说明(Control Point Specification) 提供了控制、大部分工作产品批准与移交环节的定义。
•变更流程说明(Change Workflow Specification) 提供了项目将遵循的变更工作流的细节。
•分发策略(Distribution Policy) 定义了为 QA 或部署分配可交付使用的政策。它描述了退出标准与程序以满足官方发行版本。
•项目归档(Project Archive) 提供了对于审核目标和未来使用的所有项目工件的基线。
法规遵循管理角色
法规遵循管理扩展并精选了RUP角色,不仅因为引入了新工作产品,而且在法规遵循敏感区域确定了责任分离。
•策略分析(Policy Analyst)。 在目录化并理解了规定、标准和政策以识别内部政策后,抓住了法规遵循需求的重点。
•过程工程师(Process Engineer)。 用于文档化并定义与应用过程标准,体系和规定一致的IT治理过程。
•技术带头人(Technical Lead)。 用于批准编码改变并最终确定变化要求。这个角色用以引导、监督应用软件组件的开发。
•部署经理(Deployment Manager)。 用于交付评估生产阶段的软件发行。这一角色存在于经典RUP内,但其扩展职责和职责分离原则要求并激发了附加的发布经理(Release Manager)补充角色。
•发布(Release Manager)。 用于从多种项目中比较发行的工作产品,以生产可交付使用的发行版本。发布经理(Release Manager) 控制发布管理过程。
工作产品控制
这种插件以两种方式定位工作产品。首先,它提供了工作产品控制方针以帮助建立工作产品控制。其次,它将识别出的必须批准的最小工作产品集用于工作产品控制。我们对于RUP的改进包括了如下批准:
•过程确认批准(Process Validation Approval) 正式化的指出该项目处于"审核就绪。"
•交付变更批准(Deliver Change Approval) 控制一系列改变的集成。
•基线批准(Baseline Approval) 控制长期发展任务或QA、产品化发布版的基线。
•变更请求批准(Change Request Approval) 提供了针对开发过程中改变要求的接受记录。
•测试结果批准(Test Results Approval) 指出项目已成功测试法规遵循需求。
•分发批准(Distribution Approval) 提供了针对QA和产品环境的一系列构建对象交付的控制。
记录控制
这一插件支持记录控制,通过:
•提供记录控制方针。
•定义一种总结了记录控制的新的控制工件。
•正式确定了批准,测试结果,和所记录的项目文件。
可追踪性
大部分复杂情况下,追踪性都能包含由过程产生的大量工作产品。本插件中,我们已将它包含入维持变更要求(包括需求)和关联测试间最小可接受的水平,并且改变了要求、测试和由工作产品所控制的测试日志。
工具导向的行为
要应对今天的规定、标准和政策的混合过程使得人工操作十分昂贵,更重要的是给员工代来极大负担。使用良好的工具以实现部分流程的自动化被称为 "工具导向的行为," 或(TDB)--将法规遵循变为现实的主要因素。 IBM 提供了全面的工具套件实现工具导向的行为。
•IBM Rational Method Composer (RMC) 具有这样一种能力,它既能裁减 Rational Unified Process 以适应客户需求,并且/或者将非常好的实践作为构建团队过程的一部分。
•IBM Rational RequisitePro® (ReqPro) 支持需求,并可以通过适当水平的追踪性与控制改变管理。
•IBM Rational ClearQuest® 提供了交付可审核改变的的能力,它是通过支持应用自动化的工作流管理、审核追踪、电子签名、报告的软件资产的管理与控制实现的。
•IBM Rational ClearCase® 提供了交付可审核变更的能力,它是通过支持应用版本控制、审核追踪、用户验证、基线,报告的软件资产的管理与控制实现的。
•IBM Tivoli Configuration Manager® (TCM) 将软件构建与配置联系起来。
•IBM Rational Portfolio Manager® (RPM) 帮助企业控制项目,通过即时准确的信息最优化配置资源,它还为中层与行政管理提供了项目组合管理的视图。
正式的把关过程(控制点)
定义控制点是一项非常依赖于实际情况的工作。一般来说它们被定义为执行工作流的一部分。执行工作流的目的往往是确保参与执行的部分符合各个步骤的要求,以生产出相同质量的产品。用以确保产品质量责任及控制程序的附加机制可加入至工作流中。这些控制程序一般都需要一个检查的步骤,因此需要复查者指出输出产品中满意及不满意的地方。 这些控制点是开发工作流中的重要事件,同时批准动作用来允许过程继续运行。当建立自动化工作流的方案同时,需要仔细研究部分条目。要考虑的内容包括参与到工作流中的角色的建立,每个角色将被授予的决定权,和在工作流中具有足够数据一决定输出质量的关键环节。
我们建议创建全部关键目标的控制点。在插件中,我们主要关注于在构建管理及最有效避免代价高昂错误的发行时创建控制点。例如, 本插件中的控制点可以帮助避免高昂代价的领域问题,如Ariane-5火箭的悲剧,这次灾难的根源是错误的安装了推力控制软件的版本。
提高RUP审核的好处
Business-Driven Development for Compliance Modular Service Offering 和 RUP for Compliance Management plug-in (以服务所提供的内容作为基础)形式化的定义了一些法规遵循的非常好的实践,并将它们作为独立IT过程控制。 RUP for Compliance Management 插件提供了如下好处:
•利用从高度可信的环境中扩展的应用性在法规遵循管理中使用RUP的坚实基础。所引入的控制由RMC正式定义,包括:
o法规遵循管理特定工作产品
o法规遵循管理角色实施责任分离
o正式的把关过程(控制点)
o工作产品控制
o记录控制
o通过工具导向的行为进行过程自动化
•针对 IBM Rational 法规遵循管理方法的强大支持总结如下:
o"说企业所做的"
建立法规遵循开发过程
业务控制与工作流
技术控制与工作流
批准、授权、质量把关,责任分离
o"做企业所说的"
自动化强制执行法规遵循过程
过程指南、自动化工作流、工具导向的行为
o"能够证实"
自动化产生审核文档
针对软件开发企业的审核报告,审核追踪
o"平衡业务优势的法规遵循"
分析项目度量和过程度量
迭代改进
•平衡形式性与实用性。 当某些项目不需要所有控制时,经验告诉我们重新考虑工程项目的核心过程并不实用,就因为其高昂的代价和复杂度。仅仅少部分案例中,由于使用更多的控制,重大的调整保证了过程的执行。