Rational Edge: 可运作的 IT 治理

本文介绍了对于 IT 治理的可运作方法,将治理描述为具有其自己的生命周期和工件的有意图的活动。随后作者介绍了对于 IT 治理过程的基于价值的方法,以及一组 IT 组织可以遵照的原则,从而用它们的商业设置来实现治理的益处。

Murray Cantor, 杰出工程师, IBM

Murray Cantor作为 IBM Rational 领域服务团队的领导,Murray Cantor 促进并扩展了 Rational 最佳实践,包括 Rational Unified Process for Systems Engineering®(RUP-SE®)。由于 Murray 对 RUP-SE 的贡献,以及在客户企业转型上的成功,他获得了杰出工程师的称号。他曾经发表了两本书和许多文章,并且在与 UML 和 RUP 相关的标准委员会中担任重要角色。1973 年他在伯克利加利福尼亚大学获得数学博士学位。



John D. Sanders, 执行 IT 架构师, IBM

author photoJohn D. Sanders 是 IBM WW SOA 技术销售团队的高级认证执行架构师。他拥有 20 年以上的进行沟通、系统整合、系统设计和应用程序设计的经验,并且已经设计并实现了各种 SOA 计划,目前他正在开发一个围绕 SOA 的软件适用产品。在为 IBM Global Services 工作时,他得到了一些他最大的 SOA 合约。他还担任 IBM 的软件开发实验室的首席架构师,为电视广播公司设计商业广告现场插播解决方案。他从 LaSalle 大学获得 MBA 和信息系统管理科学的学士学位。



2007 年 7 月 16 日

大梁的插图在本文中,我们着重于 IT 治理的两个应用:

  • IT 过程的治理,例如那些在 Information Technology Infrastructure Library(ITIL)或 Control Objectives for Information and related Technology(CobiT)标准中找到的
  • IT 支持的商业过程的治理

从本质上说,治理是关于决策制定和沟通的。对良好治理的需求源于对组织制定好的决策并有效进行沟通的需求。当面临糟糕的成果时,组织经常需要审查决策是如何制定的,并且采用能够更好地支持决策进行下去的结构。这些决策可以是大型的,例如,是否向新计划投资,或者批准年度报告,或者决策可以是常规的,例如是否允许访问敏感数据或包含发布版本中的软件代码。

随着 IT 的成熟,服务定向和面向服务体系结构(Service Oriented Architecture,SOA)的出现提出了一组新的治理难题。服务定向所导致的模块性和效率提供了更快地产生好处和坏处的方法。SOA 的敏捷性要求组织更慎重地制定决策,这是有效治理的真正好处。采用 SOA 的组织不仅需要向服务工件的生命周期过程应用治理,还需要考虑 SOA 对所有 IT 治理子规程的影响,例如项目组合治理或数据治理。对采用 SOA 的 IT 组织重新安排 IT 治理称为 SOA 治理。

IT 范围内治理的浮现

IBM 的客户出于两个重要的原因不断地关注 IT 治理:

  • 满足并编制对从外部被利用的商业实践的法规遵循的需求,包括:
    • 公司和行业规章,以及相关的法规遵循需求,例如 Sarbanes-Oxley、Health Insurance Portability and Accountability(HIPPA)、Payment Card Industy Data Security Standard(PCI DSS)、Basel-II,及其它
    • 公司政策,例如财务管理和人力资源
    • 参与更大范围的组织商业过程
  • 希望对企业交付来自 IT 运作和投资的更多价值。举例来说:
    • 当企业或消费者需要时,有以业务为关键的系统可用
    • 保证 IT 运作支持并且不会阻碍商业策略的演进
    • 在交付所需服务时将成本最小化
    • 期望从 SOA 的采用中获得价值,并且减少 SOA 的采用所带来的风险
  • 期望提高开发组织的敏捷性、价值和革新能力,举例来说,新产品的开发、软件开发,新的服务生成

在本文中,我将介绍对于 IT 治理的可运作方法,它提供了处理图 1 中显示的 IT 治理的过程(Avi Yaeli 和 Clay Williams 的研究结果,IBM Research)。IT 治理过程拥有其自己的工件集和循环的生命周期。治理过程生命周期包括,获取组织的治理需求,在主动的平衡价值和风险的同时,创建、部署,并演进满足那些需求的治理解决方案。

显示治理和商业要素之间关系的图表。

图 1:治理、管理和商业关注的关系

采用可运作的治理为组织提供了实际的方法来提供它们试图交付的基本价值,不论那是组织的效率、客户紧密度,或是产品创新。

我们在文章结尾给出了一组有效应用 IT 治理的原则。

定义治理

存在各种各样一般的治理定义和特别地 IT 定义。一些定义认为治理是增强对组织的外部需求的方法,而其他的定义将 IT 治理看作获得上述益处的方法。还有第三类将治理本身作为过程的定义。这些运作型定义通常着重于决策权的分配。1 决策权的概念常常扩充为决策机制。2 使用这些定义的组织一般着重于推动更大的效率(举例来说,Lean Manufacturing)。

当然,也有将这些概念合并起来的混合定义。而且还存在着重于治理的政治根源的其他定义。

虽然这些定义中的每一种都包含对治理的重要观点,但是没有一个是充分的。因此,没有对哪个单个简明的定义的一致认同。在本文中,我们采用并构建在可运作的观点上。

有关定义治理工作中的困难的最后一点是:术语“治理”在自然语言中的使用会产生阻碍。有时候我们说治理组织,其他时间说治理过程。有时候,我们明确地说设置政策并分配决策权的管理者执行治理,其他时候我们又说规章或一些外部过程对决策进行治理。有时,我们将治理作为控制个人和团队行为的方式。在下文中,我们将讨论对治理的这些观点,同时着重于令治理可运作的成功必要条件。为了进行此讨论,我们提出一个治理的可运作定义,以及一些支持的重要定义。基于领域经验的这些定义不仅为治理的讨论提供了明确性,而且还提供了对可以推动技术和服务资产的设计的模型和场景的输入。

首先,我们需要对“过程”的定义:

过程是一系列产生结束或结果的行为、变更,或方法。3

过程的特征在于随着过程的执行,工件/工作产品(对象)的状态在进行变更。很关键的是要注意,过程可能是分层的,或者以其他方式进行关联。举例来说,全面的开发过程涉及整个产品的生命周期。它包含跟踪测试覆盖及测试缺陷度量的质量或发布管理过程,而质量或发布管理过程包含涉及缺陷生命周期的缺陷管理过程。

现在,我们可以继续进行“治理”的可运作定义了:

治理是这样的过程:
  • 建立职责、权限和沟通链(决策权)
  • 建立度量方针、标准,和控制机制,从而使人们执行他们的角色和职责

注意这个定义将治理描述为过程。在治理控制之下的对象是决策权和度量、政策,和控制机制。每个组织必须按照定义中指定的建立治理要素,这些要素能够使组织的业务单元履行其角色,并且向更广泛的企业提供价值。该规范称为治理解决方案。如下面所讨论的,此治理解决方案是通过治理生命周期来进行建立和维护的,并且有与之结合的管理解决方案进行支持。

治理定义的第一个部分是公共的4 决策权。这可能被认为是治理的静态的一面,即组织是如何构造和工作的。指定决策权确定了社会网,这使组织的成员清楚地了解了谁应该制定决策。一些决策权实例包括开销和雇佣权限。对于 IT 组织来说,决策权可能包括项目投资、项目内容管理、架构内容和质量管理。注意我们没有包含项目优先化,这是一个可能由一些行业或更高的跨组织的权力机构所掌握的决策实例。

第二个部分是建立治理的动态的一面。通过设立政策、标准度量,和控制,建立可以在组织的过程中施行的治理决策是可能的。还要注意的是对度量的强调,反馈循环是任何需要改进的运作中的关键,并且/或者要经受变更的环境。

通过考虑在治理之下应该设置什么过程来指定决策权和度量,决策是在过程的执行过程中制定的。事实上,如下所述,选择那些过程来应用治理是有用的,由于它可以向企业证明什么在工作,而什么没在工作,以及如何变更那些过程来创造对企业更大的好处。简要的说,governance process(治理过程)应用为governed processes(受治理的过程)

治理解决方案

如果治理是一个过程,那么执行该过程的结果必须是一组有形资产(有时候称为工件)。我们称这组治理工件为治理解决方案。典型的治理解决方案包括以下一些内容:

  • Responsible Accountable Consulted Informed (RACI) 矩阵,用于获取决策权和权限的链。
  • 治理有效性度量在业务层获取良好治理的组织向更广泛的企业交付价值的方式,例如,事务的平均成本。对于开发功能,有效性度量可以交付的时间。
  • 运作度量规范将日常的度量定义为对商业过程实施控制的基础。一个实例是日平均响应时间。对于开发组织来说,代码搅动 —— 程序员代码中变更的频率 —— 是可运作的度量。
  • 方针 库是指导和对受批准的决策的控制的文档说明。
  • 法规遵循规范指定那些决策必须编制为支持决策的可闻性,

治理和管理

由于经理制定决策,所以很容易认为管理和治理是一样的。然而,管理和治理的视点不同。治理一般从外部看组织,将组织视为需要拥有适当的运作结构和模式,以提供价值的系统。管理位于组织的内部,确保那些运作结构和模式的执行。

治理用于决定“谁,什么时候,为什么,及如何”制定“什么”决策。组织的治理特别地包括:

  • 组织所需要的决策(“什么“)
  • 组织中负责哪些决策的角色(“谁”)
  • 指导应该如何制定决策的方针(“为什么”)
  • 决策制定方法(“如何”)
  • 在治理过程中的什么位置适当地制定决策?(“什么时候”)

相反,管理是确保所选择的治理方法能日常地执行的活动。一般来说,经理:

  • 分配并监督职员执行任务
  • 监控运作的度量并执行治理解决方案中指定的控制
  • 收集并报告治理有效性
  • 进行预算及资源的计划和监控

治理生命周期

治理生命周期有四个阶段,如图 2 所示。

  1. 计划
    • 获取组织的治理需求的需要,例如满足法规遵循的需要、政策的符合、提供更好的商业价值,或达到服务水平
    • 确定对于基于商业需求的解决方案的执行和测试的财务和组织的职责
    • 确定在治理下运行的过程
    • 确定治理解决方案的有效性的度量和目标
  2. 实现
    • 指定要应用于治理下面的那些过程的决策权、度量,和政策
    • 指定自动化和工具支持
    • 分阶段地大量生成对于组织的治理解决方案
    • 监控及度量
    • 确定治理解决方案是否达到了其有效性目标,并且做出调整
  3. 管理
    • 令组织执行治理解决方案以获得基本经验
  4. 评估
    • 收集治理的有效性度量
    • 确定治理解决方案是否达到了其有效性目标,并且做出调整
    • 分析不足,从而向下一轮生命周期的计划阶段提供输入
详细描述治理生命周期的图表。

图 2:治理生命周期

治理因素

作为一个过程,可运作的治理必须由一个或多个人来执行。即使将治理看作组织的日常运作(管理)之外的东西是有用的,那些治理过程的执行也可能属于或不属于受治理的组织。即使这样,那些执行治理过程的人必须考虑对组织的外部力量,如图 3 所示,例如:

  • 由较大组织执行的过程。例如,大多数软件开发组织都是执行投资过程的比开发组织本身涉及的更多的企业的一部分。更广泛的组织从事投资,而开发组织从事于用给定的内容在特定的进度安排下交付产品。
  • 外部政策。实例包括影响受治理组织的公司政策(举例来说,关于影响人力资源组织的平等就业机会的法令)或为了遵从外部标准的组织的决策。
  • 外部标准。例如各种 ISO 规范或不太正式的标准,例如 CobiT、 ITIL,或 Capability Maturity Model Integration (CMMI)。
  • 政府法规。包括 Sarbanes-Oxley,或各种行业具体的规章。
显示四个影响治理的力量的图表。

图 3:影响受治理过程的力量

在每个实例中,非正式的说,组织的过程受治于这些外部的过程、政策,或标准。较正式的说,要执行治理过程,就必须在治理解决方案的设计中考虑这些力量,并且那些执行治理解决方案的经理和职员必须知道这些力量。

这种嵌套的治理的一个重要实例源于组织包含于其他组织之中的事实。举例来说,企业中包含部门,而包含其他组织的组织可能拥有需要根据被包含的组织制定特定决策的过程或政策。由于治理过程是这样的,那些对被包含的组织执行正式这里的组织就受到约束。在缺少更高层可运作治理的情况下,政策可能会冲突。举例来说,IBM® Rational® 软件团队品牌包含于 IBM Software Group(SWG)中。名为“Integrated Product Development(IPD)”的 SWG 过程是一组品牌(Rational、Tivoli®,等等)用来设置优先级及管理投资的。因此我们说“IPD 治理着 Rational 过程”。要执行 IPD,必须生成特定的工件。这些工件拥有带有决策点的生命周期,并因此需要治理。这个开发治理的实例在确保一致的投资决策制定的同时向管理层提供个别的品牌。

被包含的组织将拥有能使其参与在进行治理的过程,也许还做其他事情的过程。这些过程可能不是正在治理的过程明确所需要的。这些内部的过程将需要一个很好的治理解决方案来提高被包含的组织的整体性能。

为了得到这一点,治理过程向被包含的组织的治理解决方案加上约束条件。注意,这个定义与许多文献中对治理的定义一致,并且它包含了将治理应用于一系列过程,以及执行那些过程的组织的内容。

商业价值

如 Michael Treacy 和 Fred Wiersema 所指出的,5 企业可以通过三种方式向市场提供价值:

  • 产品革新:一贯地尽早向市场交付新的产品或特性
  • 运作效率:一贯地以低成本可靠地交付商品产品或服务
  • 客户满意度:快速地响应客户的演进需求

Treacy 和 Wiersema 指出,每个公司必须提供一些混合,上述三者之一应该支配文化和商业价值手段,如图 4 所示(示例企业显示,受到运作效率的支配比客户满意度多)。因为 IT 是提供这一价值交付的关键,所以了解价值问题的混合使 IT 治理复杂化是很重要的。一些 IT 项目支持一种价值,比方说交付效率,而其他可能提供创新。对于组织的治理有效性度量总的来说应该反应这种混合,而对于不同项目的治理解决方案是不同的 6。这一混合应该在 IT 治理生命周期的计划阶段过程中予以考虑。

显示结合三个价值之一的已知企业的图表

图 4:商业价值空间

风险管理

风险是识别出的受治理组织交付价值并满足风险承担者需求的不确定性。一般,有三种 IT 治理解决方案应该处理的被采用的风险:

  • 运作的:在日常经商过程中采取的风险
  • 投资:开发或收购新能力时采取的风险
  • 法律:被罚款或控告,或者由于没有满足法律需求而进监狱的风险

当生成治理解决方案时,我们不仅必须确定组织的目标,还要确定 IT 系统要减少的风险。一般,对这些风险的处理由明确的过程进行:运作风险可以通过安全管理、商业弹性管理,和数据完整性管理过程进行处理。投资风险通过开发、交付和整合过程进行处理。因此,治理解决方案应该将这些过程放在治理之下。治理有效性度量应该反应这些风险的消除。

法律风险由下面介绍的法规遵循实践处理。

法规遵循

法规遵循是对决策的正确执行的文档化。许多组织引入治理的概念,因为它们开始商业法规,例如 Sarbanes-Oxley 或 Basel II,的遵从过程。这些法规由确定商业决策是否由恰当的人员根据恰当的政策制定出来,的审计强制执行。要通过这些审计,组织必须编制其决策权、政策,和编制每个决策实际上都是由恰当的人根据法规制定出来的法规遵循记录。

在建立治理时,组织必须考虑其法规遵循需求并且设置过程和工具来有效地获取法规遵循记录,从而令组织记录并传达各种过程遵循商业或法规政策的程度。

政策

政策是指导或约束获得决策权的人的行为的规则或原则。政策指导决策权,这一般是有条件的。举例来说,一线经理可能被允许,可用在未得到进一步批准的情况下花费规定数量之下的钱,而对于该量之上的支出,就需要进一步批准。雇佣经理可以补缺,但不能雇佣亲戚。政策为决策提供指导,为指导的遵从设定硬性指标,并且可能提供除外条款。举例来说,联邦法官被授予对那些有罪犯人的判刑决策权,但他们经常受到判刑指导原则的约束。

政策可能参考治理度量。举例来说,在 IT 组织中,政策可能要求运作经理在没有达到服务质量水平的时候减少行动。

注意政策不仅约束决策,而且还可能要求要制定的决策。举例来说,可能需要经理来建立并实行平等的就业机会实践。

政策提供指导,有时候设置限制,并且有时候允许行为。这类似于特定政治系统中的概念,除了那些国家明确禁止的,公民拥有每项权力(也就是,这些政策设置了限制)。在其他系统中,公民只拥有国家允许的那些权力(也就是,这些政策允许行为)。

可运作治理的原则

在此我们将介绍七个针对在实施的治理的原则:

  • 过程原则:治理是一个自身被应用于将被治理的过程的过程。
  • 工件生命周期原则:受治理的过程工件生命周期指导治理解决方案。
  • 风险原则:必须根据风险级别调整度量和控制。
  • 适合性原则:组织的需求确定了如何特制治理的级别和风格。
  • 行为原则:治理解决方案推动组织的行为。
  • 部署原则:治理解决方案必须增量地实现。
  • 自动化原则:技术令治理解决方案可授权并且不冒昧。

过程原则

过程原则声明“治理是一个自身被应用于将被治理的过程的过程。”

弄清治理是如何应用于组织是很重要的。当您在思考与治理相关的所有不同的概念时很容易混淆。下面是用于理解的很重要的分解了的简化:

  • 我们向过程应用政策。
  • 我们向过程应用标准。
  • 我们在过程中执行决策权。
  • 我们权衡并控制过程。

由此得出结论,要很好地治理,治理就必须是具有一序列运作(一个生命周期)和一组通过其执行而创建并演进的对象(工件)的过程。上面图 2::治理生命周期中描述了治理生命周期。

治理工件的实例是

  • RACI7 矩阵追踪
    • R负责的(他们为完成任务而工作,在功能和财务方面有多个负责的资源)
    • A有责任的(最终对决策负有责任的资源)
    • C顾问的(为了确认而寻求那些人的意见)
    • I消息灵通的(那些人实时关注提供监督的决策)
    人的给定决策
  • 存储库授权规范
  • 度量规范及模板
  • 法规遵循记录

在治理生命周期执行的过程中生成并演进了这些工件和可能的其他的工件。治理解决方案被定义为治理工件及其相关性的总的集合。

注意,在此生命周期中,设定了治理目标,并且定义了度量来确定目标是否达到。这是周期性的生命周期,它要求周期性的访问治理解决方案以查看目标是否达到,并且调整治理解决方案。

在治理过程的执行中,在最初的阶段,您必须确定受治理的过程 —— 也就是,决策权和度量分配到的组织的过程。

过程规范的来源可能包括:

  • IT 能力框架,例如 CobiT 和 ITIL,它们定义了一组由 IT 组织执行的过程
  • 开发成熟度模型,例如 CMMI,它们定义了由软件和系统开发组织执行的过程
  • IBM SOA Foundation,它列出了 SOA 生命周期(建模、组装、部署、管理)中具体到 SOA 的过程
  • 任何无数的其他具体领域的和商业的过程

事实上,通过指定在治理之下设置那些过程来定义各类治理(IT 治理、开发治理等等)是有用的。举例来说,将治理应用于 IT 过程是 IT 治理,等等。

一些过程,例如服务复用,常常叫做“治理过程”,因为在没有有效的治理的情况下很难完成,或者因为它们增进了治理目标。然而,严格地说,这样的过程不是治理过程,它们是被治理的过程。

许多称为治理过程的东西实际上是受到治理解决方案的执行的影响,或者是治理解决方案的执行所需要的过程。举例来说,要满足公司的安全需求,IT 组织要创建并实现密码政策。这个要求需要 IT 组织设置一组创建,并维护、监控,和实施密码的过程。在进行期间,IT 组织的领导采用了一组决策权(举例来说,负责批准访问、发出密码,及变更密码的人)、内部政策、控制机制,和文档化程序。对该要求建立的这样的响应就是治理。换句话说,日常的密码政策的执行不是治理,而仅仅是密码管理。该 IT 组织进一步确定利用自动化并实施决策权的密码管理软件来实现该治理解决方案。该软件的实现和配置由治理解决方案决定,尽管那些密码政策的执行和相关软件的使用不是在进行治理,那些政策和支持的技术对治理解决方案的执行是必要的。

区别被治理的过程和治理过程可以帮助阐明角色,过程本身的模型,和所需的治理水平。它还帮助阐明对运行时和工具支持怎样及在哪里辅助治理的讨论。

工件生命周期原则

工件生命周期原则声明“受治理的过程工件生命周期指导治理解决方案。”此原则构建于早先的两个概念之上:(1) 治理包括决策权的分配,以及 (2) 治理应用于受治理的过程。回忆定义,过程的执行需要过程工件的创建或变更。

治理的特点可能在于一些需要在过程中特定控制点制定的决策。控制点提供度量过程的机会,并且决定过程的执行是否需要调整。一些这样的决策可能需要在过程中任意控制点由监控工具收集的一组度量。 知道过程中的什么决策是关键的,以及什么时候制定它们,并且了解需要将什么度量作为那些决策的输入,这些是治理的全部。

过程中某些活动可能与控制点相关。举例来说,工件的“审查步骤”可能与控制点相关联。以类似的方式,过程本身中某些事件,例如生命周期里程碑也可能是控制点。在 IBM® Rational Unified Process®(RUP®)中,有四个阶段:Inception(初始)、Elaboration(精化)、Construction(构建)和 Transition(产品化)。在每个阶段末尾,都有一个阶段转换校对,计划管理人员可以在此决定计划是否准备到下一个阶段(产品化的末尾是产品的发布)。这些里程碑都是控制点。

从本质上讲,工件生命周期提供了确定控制点的方法,以及推出定义治理解决方案的方法:

  • 确定治理将应用于的过程
  • 对于那些过程,确定过程所生成或影响的那些工件
  • 对于那些工件,确定它们什么时候变更情况或状态(这些是控制点)
  • 在每个控制点,确定
    • 决策的 RACI 角色
    • 可应用的政策
    • 应该应用和收集的度量
    • 要生成的法规遵循记录

这个直接的方法生成了将要实现和自动化的治理解决方案的要素。

在应用此工作流的过程中,要进行一些额外的考虑:

  • 一些过程,例如软件开发,可能包含一组子过程。在这种情况下,全过程以及每个子过程拥有决策点(例如生命周期阶段转换)。对于全部和子过程的决策点也许是对齐的或者也许是不对齐的。
  • 不是所有的工件都需要加入治理解决方案中。治理决策来确定那些工件需要正式的生命周期过程建模和治理,那些将受到非正式的或“特别”的管理。
  • 在进行过程工程时,过程本身就是工件,并且存在与其生命周期相关的控制点,从 proposed(提议的)adopted(采用的)retired(退休的)
  • 考虑工件的“集合”如何以协作的方式共同地转换其生命周期也是重要的。

虽然现在已经存在许多用于为单个工件的生命周期建模,并且在单个工件的生命周期中的各个位置执行政策和决策权的工具,但是为了了解同时协调多个工件的更复杂的过程,并且因而了解那些过程中的那些控制点需要决策权的应用、度量,和政策的施行,还要做进一步的工作。

受控工件的分析,以及那些工件的生命周期模型为治理提供了丰富的过程。许多现有的治理工具,特别是基于注册的治理,包含关键工件的生命周期的模型,并且为政策和决策权的施行提供控制点。

风险原则

风险原则声明“必须根据风险级别调整度量和控制。”

行为原则(参见下个部分)说明一些过程风险与执行变量的统计不确定性相关。风险的等级决定了您该如何度量:

  • 当确定性和过程可预测性的等级很高时,您可以着重于活动的度量。
  • 当确定性等级低时,您需要着重于度量确定性等级中的变更,而不是个别的活动。

注意到,当确定性等级低时,您不能创建从头至尾的计划。相反,您必须利用所完成的结果和所获得的见识来创建一系列迭代,来设置活动及资源来促使计划成功。成功的关键是每个迭代的有效度量,以及在对下一个迭代反馈时对度量的使用。

我们经常不能区分高确定性和低确定性的情况。虽然说您处于低确定性的情况中可能会痛苦,因为风险和成本更高。许多组织浪费了大量事件来处理延迟的决策,这大大地提高了商业成本。通过忽略确定性的缺乏,您可以暂时避免一些痛苦,但是这并没改变项目的本质,而之后将产生更大的痛苦。

适合性原则

适合性原则声明“组织的需求确定了如何特制治理的级别和风格。”

不同的组织拥有不同的治理需求。一些组织处理受到严格规定的拥有关系任务或关系生命的产品的过程,例如,航空电子学或医药学。这些组织需要更正式、可审查的治理。其他组织,例如开源团体,作为带有新兴行为的精英得到治理。

对更严格的治理的需求由决策点处更紧密的政策,以及正在进行的政策执行和法规遵循度量来满足。

甚至在一个组织中,不同的过程可能需要不同的治理风格。一些过程,例如代码发布,比其他过程,例如软件编码,需要更严格的治理。

一些治理风格需要考虑组织及其子组织之间的关系。不同的组织文化需要决策制定过程中不同级别的独立性。例如,行业中的 IT 组织和跨行业的(也就是,公司)IT 组织之间的决策权在不同的企业之间都不同。

为了更加敏捷和有效,许多组织正采用治理方法。许多厂商创建的方法是满足最大可能的需求集合的最大峰值的框架方法。组织需要适合性原则,并且必须重视这些治理方法,对其进行适当裁减。目标是在不丢失已知方法带来的结构的价值的情况下,创建适合组织的方法。

行为原则

行为原则声明“治理解决方案推动组织的行为。”

从前,经理放弃可以将工作人员看作可编程序的机器的想法。现今,执行者的难题是创建导致组织以目标能实现的方式执行的环境。治理是可以用于推动组织行为的工具。

治理推动行为的应用性从这四种现象得来:

  1. 人们自发地创建他们自己的社会网来完成工作。
  2. 跨组织边界的沟通没有在边界之内的那些有效。
  3. 规模不经济 —— 沟通随着扩大的组织的大小成非线形增长。8
  4. 人们将对自己如何受到度量,以及组织如何受到度量做出响应。

通过适当地设置决策权和度量,您可以使用这些现象来完成良好的组织行为。类似的,如果决策权和度量没有设置好,或者根本没设置,那么这些现象可以导致糟糕的组织行为。

前三个现象与决策权相关。设置清楚的决策权令职员了解其职责所在,以及谁需要与谁讨论什么。此外,在开发中处理现象 2 和 3 的久经考验的方法将组织边界与系统架构结合起来。有时候叫做“您在装运组织”。企业和企业架构中用到的逻辑分解方法促进有效的沟通。设置权限和决策权增强了这些管理技术。

经验还表明需要谨慎地选择度量,因为它们可能对系统的行为有很大影响。确实,管理的格言是,“您获得您所测量的”。举例来说,如果您度量软件开发人员的代码行数,那么团队将生成拥有许多不必要代码行的程序。

部署原则

部署原则声明“治理解决方案必须增量地实现。”

治理,由于其对组织的特殊性,需要一种为了组织调整的增量方法。该原则强调定义和精练组织中使用的治理过程和能力的迭代方法。治理能力包括将与各种治理规程相关的过程和最佳实践形式化,以及建立跨规程的能力和服务,使治理过程更加有效和节省成本。

IBM 推荐组织使用治理生命周期来增量地确定治理需求,将治理能力就位,并且建立度量机制来确保对治理的改进可以引起组织行为中的预期变更。

要在治理生命周期中迭代有三个理由:

  • 增量地增加新的治理能力
  • 增量地提高现有治理能力
  • 增量地转换负责治理的组织能力

如果您在第一次试图升级您的能力时遇到一个太大的问题,那么您增加了失败的可能性。不要一次咬下整个治理问题,在计划阶段将您的治理需求排列优先级,并且依靠多次执行本文的“治理生命周期”中介绍的步骤。获得治理权是迭代的过程,治理的文化和行为方面使其成为非确定的活动。

组织对“治理能力”的倾向将成为其采用治理策略的主要因素。拥有传统结构和责任的那些公司将更适合治理,而那些已经采用“胆小的方式”的那些公司将更加挣扎。该原则的一些实例是像 IBM 和 GE 的公司的长久性。这些公司都拥有结构化治理的长期历史,这给予它们经受不同时期的能力。

自动化原则

自动化原则声明“技术令治理解决方案可授权并且不冒昧。”

由于治理一般来自组织的外面,或者看起来满足外部需求,所以工作人员可能将治理看作不可避免的灾祸,并且新的需求确实可以增加开销并阻碍生产力。通过将决策的编排自动化,获取法规遵循记录,收集并集成度量,也许通过执行将治理解决方案作为组织的结构一部分部分的政策,技术可以满足此关注点。

良好的治理解决方案可以令组织能力加强。指定好的决策权提供角色明确性,并且简化促进沟通。每个人都清楚地知道需要什么沟通来完成任务。良好的度量加强适当的行为。用自动化来增强治理决策提供了方法来减少开销,并确保治理解决方案的连续的执行,增加员工对解决方案是真实的,且可以参照的自信心。最后,治理解决方案应该隐藏起来,令工作人员专注于他们的实际工作。

最后的思考

人们经常认为他们在“治理”和“不治理”之间进行选择,而事实上,这是“好的治理”和“坏的治理”之间的选择。每个组织都拥有一个决策制定框架,以及一些常常未阐明的度量。商业的需求和 IT 的角色在演进,而这些无意识的治理解决方案没有演进。好的治理是有意图的,并且它做出努力并关注。本文中所介绍的可运作的观点为治理的良好运行提供了方法。

注释

1 参见 Peter Weill 和 Jeanne Ross 的文章,IT Governance: How Top Performers Manage IT Decision Rights for Superior Results,Harvard Business School Press:2004 年)。

2 参考 IT 服务管理论坛(IT Service Management Forum,itSMF)。要了解更多的信息,请参见 http://www.itsmf.org/

3 出自 American Heritage Dictionary,Houghton Mifflin Co.:1991 年。

4 参看实例,Weil 和 Ross,Op. cit。

5 Michael Treacy 和 Fred Wiersma,The Discipline of Market Leaders,Basic Books:1997 年。

6 Murray Cantor,“估算偏差及管理”来自 The Rational Edge,2006 年 3 月。

7 如果您不熟悉 RACI 图,那么 Wikipedia 对其进行了很好的概述 http://en.wikipedia.org/wiki/RACI_diagram

8参见 Ronald H. Coase,“The Nature of the Firm”,4 Economica 186,1937 年,或 Frederick P. Brooks,The Mythical Man Month,Addison-Wesley,1995 年。

参考资料

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=240466
ArticleTitle=Rational Edge: 可运作的 IT 治理
publish-date=07162007