Rational Edge: 建立采用 Rational 解决方案的收益案例

文档选项 未显示需要 JavaScript 的文档选项

级别： 初级

Zoe Eason, 技术顾问, IBM

2006 年 12 月 14 日

本文来自于 Rational Edge：了解如何在组织中创建采用 IBM Rational 工具和方法的引人注目的、按部就班的收益案例，并且此案例可以作为一个更大业务案例的一部分。

在过去的一些年，软件开发公司的负责人已经开始认识到将通用流程、技能和工具标准化的益处。而这种承诺对一个组织来说是一项十分重要的投资。

最近几年的潮流是，如果没有一个权威的业务案例很少有 IT 主管能够签署重大的 IT 开支。这种决策通常要提交给由多种涉众组成的预算批准委员会，包括首席信息官、财务主管和开发主管。为了达成一致，需要一个引人注目并且目标明确的业务案例和收益实现计划，来使得这些决策制定者支持这样一个投资。

作为 IT 顾问，我们通常相信技术上的解决方案，但是在表达这一解决方案对组织来说如何转化为商业价值方面还需要一点帮助。在这篇文章里，通过从采用 IBM Rational 产品套件中的一个或更多解决方案组件，我将回顾可以用来定义“收益案例”的技术。这篇文章对那些熟悉业务案例开发的读者们来说可以当作一次复习，对那些还没有从事基于这类标准的项目的读者们来说可以提供一个整体的认识。本文的主要目的是为建立一组有说服性的收益集合方面提供一些指导，而它们能够被用作您组织的业务案例过程的输入。

定义：什么是业务案例？

Donald Reifer ¹ 在他的一本关于业务案例开发的书中，是这样定义业务案例的：

是为那些决策制定者们准备的材料，用来表明其正在考虑的观点是好的，并且在经济方面是合理的。

简而言之，一个业务案例是为了改进业务而提出的有组织的建议。它充分证明了投资的收益，同样也证明了已经考虑并分析过的各种可能性。

一个业务案例包括：

• 业务关系和状况的分析
• 解决方案将如何支持技术和业务的驱动力
• 解决方案将如何应对当前的挑战
• 解决方案的描述
• 包括假设条件、约束条件、风险和可选方案
• 解决方案的成本收益分析

一个完整的业务案例包括详细的检验投资评估的金融投资分析和内在回报率（IRR），并考虑整个投资期间的净现值（NPV）。在这篇文章里，我将重点放在已提出的解决方案、它与业务目标的结合以及组织目前面临的挑战和成本收益分析上。我将引用这些元素作为我们的“收益案例”，这些元素将是一个完整的业务案例的主要输入。

创建收益案例：全景

如下面图1所示，这篇文章中所提出的步骤会产生“全景”。一个自上而下的方法将考虑组织所必需的业务结果以及支持这些目标的合适的计划。一个自下而上的方法将从开发的角度来考虑目前什么正良好的运行，以及存在哪些地方需要改进。构成解决方案的软件开发能力被挑选出来以应对自上而下的驱动力和自下而上的挑战。这些能力是过程、工具、技能传递、基础结构需求和组织需要的结合。

图1：产生“全景”的步骤，可以自下而上或自上而下进行。

在开发团队需要克服挑战的地方，评估效果以提供一个基线度量是有用的。通过使用最佳实践和工具而在改进方面达成一致，评估采用 Rational 方法的成本收益是可能的。这也可以用来推动执行计划。

我将说明图1中展示的图片的每一部分。

开发团队：角色和职责

Joshua Barnes 在他的关于创建 ROI ² 评估的论文中，为此任务识别出了“梦之队”。下面的列表概括了将承担或支持必需的活动以帮助创建收益案例的角色。

• 执行发起人 -- 一个或多个被授权的执行层面的管理人员，他们对计划提供强有力的支持，同时支持预算和资源的分配。
• 领导者 -- 在识别业务和技术驱动力以及组织必须解决的主要挑战方面，并将这些挑战映射到 Rational 解决方案中以客观的评估潜在的收益方面拥具有以往的经验是十分重要的。
• 财务人员 -- 拥有组织项目和程序预算、业务案例过程以及资源利用率的标准等方面知识的人员。
• ROI 人员 -- 这是具有准备 IT ROI 评估经验的人和精通 ROI 计算的人。他们应该具备在成功的业务案例中使用这些 ROI 计算的经验，并且能够提供失败的业务案例的例子。
• 运作主管 -- “了解每一个人”的人。在大多数公司，有一些雇员在公司中工作了很长时间，他们很清楚要跟谁谈、影响在什么地方以及要想项目继续进行下去谁能够消除这些影响。
• 沟通人员 -- 那些精通以一种引人注目的形式呈现收益案例的 IT 沟通的人员。

对于以上这些是角色，一个人可能拥有多种技能，并可以担任多个角色。另外，这些角色中的许多可能不是正式的，是由那些具有这方面专长的指导人士担任的。在这些角色里有两个是主要的。没有合适的执行发起人，您将得不到合适的支持；没有合适的经验丰富的领导者，您可能要为创建一个引人注目的案例费尽心思。

活动

图2提供了创建一个大概三个星期的业务案例所需活动的整体框架。带颜色的编码强调了他们涉及的角色和活动的关联。

作者注：如果您在创建一个收益案例的技能方面有经验，您可能只想简单的浏览一下这部分，然后直接进入到“生成的工作产品”部分。

图2：创建一个三个星期的业务案例所需活动的整体框架

组织活动以确保一开始就有紧迫感并有任务要做。此外，在初期就对恰当的环境和范围进行详细说明。时间线看上去可能很有挑战性，但是即便在一个更大的组织里，引入恰当的重点和合适的人员也是有可能的。

活动的细节在下面的部分详细列出。

完成任务

在着手这项工作之前，需要确定一个执行发起人。在组织里可能是一个或者更多的高级人员。执行发起人应该认同变更需求、了解变更的紧迫性并且在适当时候使得收益案例通过预算批准并执行。如果一开始没有这样一个明确的任务，那么工作将不可能顺利的开展下去。

谁是为组织采用过程、工具和新的技能的合适的执行发起人呢？首席技术官是担任执行发起人这一角色的最具代表性的侯选人。开发方面的负责人可能更加合适，或者可能有一个关注过程和工具标准的特定开发团队，他们的代表可以作为一个执行发起人。选择谁来担任这一角色取决于在使任何一种收益案例在组织中成为现实的过程中哪些地方受到了影响。

划定成本收益研究的范围

发起人参加的初始会议将划定成本收益研究的范围。这一活动着眼于理解解决方案、它所覆盖的方面以及范围。帮助识别范围的典型问题包括：

• 需要使谁信服这一提议？
• 涉众是谁？
• 收益研究在 2006 年及未来所需要的记分卡/目标度量标准的设置是什么？
• 在这个成本收益分析的研究里谁将“拥有”并与开发团队共事？重要的是这一职责应该是属于您的组织组织的，而不属于 IBM Rational 或其他任何您请来的帮助你的外部第三方顾问。
• 开发团队和组织结构的哪些方面被覆盖？
• 将致力于哪些角色？
• 软件开发的什么方面将被覆盖到？比如，全部生命周期？
• 一旦做了成本收益分析的研究，在 Rational 解决方案中批准投资的决策过程将是什么？

经过讨论，您需要为收益案例设定清晰的目标和范围，并详细说明一旦完成这一点将如何推动决策过程。

计划后续活动并制定时间安排

一旦获得了支持并划定了工作范围，下一步就是确定开发团队里的某些人来协助完成剩下活动的计划和时间安排。对这一任务来说关键是要有办法获得资源——人员、场所、时间表等等。

在收益分析的过程中，获得支持是最关键的方面。

理解您的业务案例开发方法

在这一方法中，首先要考虑产生一个收益案例，这个收益案例最终将成为业务案例的基础。每一个组织都有一个略微不同的业务案例开发方法，理解您所在组织最惯用的方法是十分重要的。这需要与团队中对在组织环境中生成业务案例颇有经验的那些人紧密合作。业务案例将评审的方面如下：

• 启动一个项目要遵循的步骤是什么？
• 一个成功的业务案例意味着收支平衡还是 ROI/IRR 时期/数量 —— 例如，是一年内的收支平衡还是两年内每投资1美元收回2美元呢？
• 回顾一到两个客户业务案例－－无论成功与失败，目的是了解组织里什么在工作

与正确的人进行集中的两到三小时的会谈将提供一些有用的背景以确保研究的侧重点是正确的。保证这些人参与到整个研究过程，不论是以一个公正评审员的身份还是作为团队的成员，也是十分重要的。

获取收益计算必需的数据

为了计算收益，需要一些围绕成本、项目和人员的基本信息。这包括：

• 一年工作多少天？（典型是220-240天）
• 一天有多少小时是计费的？（典型是7小时）
• 一年里要管理多少项目？
• 组织里将需要多少人？将需要执行哪些任务？
• 员工的计费标准是什么？
• 标准的年薪是多少？（包括养老金和其他一些福利）
• 在软件开发周期的分布式软件上排名前十位的花费是什么？如何分配到产品中？（目的是通过供应商 可能减少的量来寻求成本收益率。）

这一信息需要通过和适当员工进行讨论来了解（特别是项目管理人员）。如果能够得到正确的信息，只需两到三个小时的讨论就能解决。

理解业务关系

需要从两个方面来理解更广泛的业务关系。自上而下的方式能够帮您理组织的驱动力和方向。自下而上的方式能够帮助您了解那些直接参与到开发软件相关的日常活动中的人所面临的挑战。让我们了解一下这两个方面。

理解组织方向

研究需要结合组织的目标，这意味着您需要了解各类信息：

• IT 策略 — 组织在未来一年、两年以及五年要努力的方向是什么？
• 在支持策略实施过程中主要的战略计划是什么？（例如 CMMI/Off-shore、SOA 等等）？您需要对这些计划及它们的所有者进行高层次的描述。
• 除了这些计划，还有其他一些进一步表现组织方向特征的重要应用程序开发项目/计划吗？也就是说，还有被关键策略业务所推动的项目吗？

这种信息通常已经被组织记录在案。与一些计划的所有者进行后继讨论也许是合适的。

理解开发方法

这一活动的目的是很好地理解当前的开发能力、检验主要的过程和工具。这可以通过与组织中以下角色的代表进行访谈来完成：

• CTO/CIO/开发的领导者
• 业务代表
• 项目经理
• 架构师
• 分析师、设计师/开发人员
• 测试人员
• 配置/变更管理经理
• 项目管理办公室
• 服务交付/运作（管理生产系统）
• 维护

这些访谈应当查明什么运行得很好以及什么需要再提高。它们可能包含评估一些背景工件：例如，需求或设计文档。

检查的发现结果将帮您分析：

• 当前开发过程中哪些方面是成功的。
• 当前开发过程中哪些方面可以提高。
• 发现任何问题的征兆。
• 了解根本原因。
• 在哪里 IBM Rational 方法在可以增加工具和过程的价值。

在许多组织里，这类评估或评定由外部的顾问组来承担。可能已经执行了这样一次评估，您可以适当地重用发现的结果。

定义解决方案

一旦您了解了策略和挑战，您可以为满足这些需求的解决方案生成一个明确的定义。解决方案试图详细说明根据过程、工具、技能传递、基础结构和组织定义被引入的开发能力。

修订收益分析

对发现的结果进行分析后，您通常需要修订收益分析中的痛点来对影响进行定量分析。

此外，一旦您设计了这些度量方法，很重要的是与受影响方一起修订这些度量数据以确保他们是合理的，并在所有数字上都达到一致。这些讨论趋向于以四或五个主要痛点为目标。

生成重点的收益分析

从上面的活动中收集的信息作为完成成本收益分析研究的输入。这一研究将检测收益及它们与组织目标的结合。它将集中在一些主要的痛点以检测当前的情况和应用 Rational 解决方案的效果。

覆盖的典型区域类型包括：

• 什么活动花费大量的时间？我们能否缩短这一时间吗？
• 例如，如今创建一个构建版本要花多长时间？我们能否缩短这一时间，并确保更多频繁的构建版本？
• 可以简化多少手工活动（例如，建立报告）？
• 什么都不做的成本是什么？
• 您可能碰到的问题是什么以及他们的相关成本是什么？
• 有一些对业务自身产生影响的问题吗？
• 例如，不能做的一些事情是否有潜在收入？

被捕获的收益将充实到业务案例中。

生成收益/业务案例

正如我之前所提到的，详细说明一个正式的业务案例所需要的每一个元素超出了这篇文章的范围。在我们看来，阐明这一点就足够了，那就是最终的业务案例将概括分析业务关系和业务情况并对解决方案（包括假定、约束条件、风险和可选择性）和解决方案的成本收益分析进行描述。

其他有助于支持业务案例的材料包括来自其他客户或分析师（Gartner、 IDC 等）的外部参考，还有来试验导项目或概念证明阶段的其他发现。

在这篇文章的后面部分，我将描述如何认别潜在的成本和相关的收益。

向发起人展示成本收益分析研究

应该在一个两到三小时的会议上将收益/业务案例的发现结果展示给发起人。讨论的结果将是达成一致的收益案例（在这次会议中经过一致同意做了较小的调整）。这次会议也应该讨论推动收益案例最终达成一致以及下一步应该做的事情。

生成工作产品

通过这些活动，您正在构建作为全面业务案例输入的收益案例，Rational 的工具和过程将为你提供软件开发方面的最佳实践。正式的收益案例将包括：

• 业务关系
• 解决方案的描述
• 财务预测

业务关系

在“理解驱动力和方向”的活动中，我们了解了业务驱动力、每一个主要的策略计划和他们的关键成功因素（也被认为是“技术成果”）。图3显示的是一个您可以如何定义业务关系的例子。将这些计划进行优先级划分，并检验每一项投资将如何帮助计划取得成功是有用的实践。

图3：如何定义业务关系的例子

在“了解开发方法和痛点”的活动中，除了自上而下的策略方法外，我们需要识别这些计划背后的开发团队和他们的关系所面对的挑战。图4显示的是计划背后的一些挑战以及我们可以如何使他们发生联系的例子。

图4：计划与某些挑战可以如何发生联系

这一方法提供了业务关系的概貌：为什么我们正在重点介绍新的能力，以及他们将如何以自上而下和自下而上的方式同组织结合起来？

提示：那些熟悉 Rational 工具套件的人可能会认识到 Rational RequisitePro 对于表现这种可追溯性是一种十分有用的工具。

这一实践应该首先强调帮助组织提高的主要软件开发能力。例如，上面的图首先表明的是需求、变更管理和简化的架构实践都是主要改进的地方。

解决方案描述

解决方案描述详细说明根据过程、工具、技能传递、基础结构和组织定义引入的开发能力。他们被打包成为一系列“解决方案”组件。

被建议的解决方案的主要组件包括：

• 描述 －－ 描述要改进的软件开发能力。建立这些能力与他们将解决的挑战/痛点和他们将投入的技术驱动的跟踪性。
• 范围 －－ 将会影响组织的哪一部分？将会影响什么能力、技术、任务等等？（经过和我们的发起人讨论会获得这一信息。）
• 持续时间 －－ 解决方案需要多长时间才能显现效果？解决方案将以递增的方式呈现吗？
• 解决方案组件 －－ 每一个组件包含什么－－流程、工具、指导、培训等等？
• 假定和约束条件
• 风险 －－ 识别风险十分重要，因此他们应该被清楚地表达。后续的执行计划应该包括风险规避策略。例如，大规模实施的主要风险之一是组织驱动一个成功的变更程序的能力。
• 可选的解决方案 -- 有一些可供选择的其他方案吗？不要忘记什么都不做也是一个潜在的选项。这样做的影响会是什么呢？

获取解决方案所有权的总成本是十分重要的。这应该包括：

• 许可证成本和第一年的维护费。
• 未来几年的维护费。
• 培训、顾问和指导成本。
• 核心执行团队成本。
• 管理和支持/协助的办公成本。
• 硬件和基础设施成本。
• 学习曲线成本。
• 应该考虑的其他一些成本 — 例如，组织人员参加培训的时间成本。

计算必须切合实际；不要低估解决方案的总成本。具有代表性的是，您更可能低估成本而不是高估成本。尽管如此，如果您的成本恰巧超过了最高值，您可能想要考虑分阶段的办法，对每一个阶段进行单独投资。在每一个阶段，您将计划如何证明价值，帮助推动下一阶段的投资。关键是如果估计得过高，您不可能得到必需的资金。

下面图5中显示的图能够帮助您分析 Rational 解决方案中必需的许可证数量和各自的成本（当包含定价的时候）。许可证是浮动型的，因此他们可以被许多协作的使用者共享。比例应该根据组织的任务和需要来调整。目的是考察跨越您所考虑的区域的每一个角色的许可证需要。

图5：分析 Rational 解决方案中必需的许可证数量，以及包含定价时相应成本

记住单独的工具不是答案。解决方案应该表示软件开发能力改进的所有方面：

• 管理
• 流程
• 工具
• 团队需要的技能
• 根据基础结构的部署需要

为了达到良好的效果，解决方案应结合指导和技能传递 — 也就是说，他们应该包含战略计划、技术成果和组织所面临的挑战。重要的是要始终关注能够为组织提价值的区域。

财务预测

“从根本上说，ROI 评估不是科学；它们应当是勤奋的实践以建立一个指导方向，并为组织转变的方面提供支持。在我们的行业里几乎所有的 ROI 数据都是基于一些推测。”— Walker Royce, IBM 软件服务部 — Rational (ISSR) 的副总裁这样说。

正如 Walker Royce 所说，财务预测不是一个精确的科学。但是当我们为一组潜在的 ROI 数字设定一个基线后，那么我们就可以对相关方面进行讨论并相应进行调整以确保数字是合理的。有许多技术可以用来从财务角度观察软件开发投资。让我们来看一下收支平衡分析，以及如何分析帮助推动必需的生产力改进的益处。

收支平衡分析

南加州大学的软件工程中心的 Barry Boehm 博士有一个十分简单的运算法则（图6），可以确定项目实现生产力增长的收支平衡点：

图6：Boehm 的用于确定项目实现生产力增长的收支平衡点的运算法则

图6和图7中显示的收支平衡分析的详细说明为财务预测提供了一个好的开端，也提供了一个检查解决方案的绝佳方案。典型的收支平衡计算需要生产力的增长率在2%到7%之间。

图7：图6中所描述的 Boehm 的运算法则的例证

这一信息为证明投资本身与所必需改进的数量是合理提供了保证。通常，这只是财务讨论的开始，还需要更多的关于生产力提高将来自何处的说明。这一点将在下一部分进行描述。

关于提高生产力的收益

通常情况下，很难对改进进行量化，这就是为什么我趋向将重点放在时间和相关的成本上 — 也就是我能够度量的事物上。很具有代表性的是，这会引发对节约成本的分析或者用较少的资源做更多事情的能力，也就是提高生产力。

典型地，在能力改进方面的投资显示了成本提高了15% 到30% 但是让我们以一种保守的观点来看：设想组织将能力提高 5%。那将意味着什么呢？

设想一个 IT 组织有1000名员工受到影响。仅仅5%的生产提高率将使得每人平均多出11个额外的工作日用于其他项目（每年5%*220个工作日）。这相当于11,000个额外的工作日用于其他的 IT 项目（11*1,000名员工，每天计费600美元）。注意：这里我们将使用之前围绕日薪、每年的工作天数等获取的数字。

结果：每年节约大概六百六十万美元或者得到 11,000个工作日

这些改进来自何处？

通常当看到生产力提高 n% 时，人们会问，这来自什么地方？表1和表2提供了某些特定活动的一些初步分析，在那些活动里 IT 可以产生特定的生产力提高。这一分析将会在业务案例的开发过程中得到加强，但是在这一阶段，它很好的展示了潜在的改进。

表2提供了一些 IT 将如何了解基于已知实践的成本收益分析的例子。有许多关于 Rational 工具如何提高生产力和当前实践的例子；这里有一个样例来说明潜在的改进。

为了证明我们对改进后的解决方案创造价值的假设，关于每一个挑战，从内部发起人获得输入是有用的。当您的发起人问“那么 x% 的生产力提高来自什么地方？”时，这种方法的确有帮助。

其他方法

近来 Rational 已经开始利用方法论来帮助成本收益分析领域，称作“Rational 业务价值分析（Business Value Analyst for Rational）”。利用 TCO 或 ROI 分析，该工具帮助分析所有权总成本(TCO)节省、业务和战略收益以及成本所需的潜在投资。该工具由 Alinean, Inc 开发，该公司是由 IT 价值评估专家 Thomas Pisello 创立的，他是 1993年 以来 ROI 和 TCO 分析工具的倡导者。如果您想看一下这一工具并了解它如何提供帮助，请联系您当地的 Rational 代表。

我发现将这些方法结合起来在帮助组织建立一个令人信服的收益案例时十分有用。

结束语

在这篇文章里，我回顾了用于帮助详细说明采用 Rational 解决方案之后的收益案例的方法和技术趋势。我的目标是引导您建立一组有说服性的收益集合，可以作为组织的业务案例过程的输入。

经过几年在这一过程对组织的帮助中，我的开发团队有一些经验跟大家分享：

• 每一个团队有他自己的业务案例开发方法和决策过程。理解这一点至关重要，因为它将影响收益提议。采用在您的收益案例文档中的方法以适应您的组织。
• 确保您的业务案例背后有合适的赞助人和领导者。
• 保持收益案例的简单性、可信性和稳定性。使用您提供的原始数字作为讨论的出发点，并对数字进行调整，直到所有涉中都认为数字是合理的。
• 找到几个友好的支持者 —— 特别是在组织里拥有业务案例开发经验的那些人 —— 通过他们的有用信息来帮助您。

为了获得批准，需要一个引人注目、目标明确的业务案例和收益实现计划来使得这些决策制定者支持这样一项投资。我希望这篇文章已经为读者提供了一些有用的观点，使得他们在通过采用 Rational 过程、工具和技能来开始构建收益案例。

参考资料

¹ Donald Reifer，Making the Software Business Case: Improvement by the Numbers。Addison-Wesley Professional 2001。

² Joshua Barnes， "建立实施IBM Rational解决方案的投资回报评估" Rational Edge，2005 一月。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
  
  
• 您可以参阅 Rational Edge 电子月刊中文版 的其他文章。

关于作者

		在过去的七年里，Zoë Eason 在IBM Rational 产品和服务方面提出了许多技术方面的专家意见，为许多金融服务组织提供了过程和工具方面的培训。今天她对高水平的开发团队进行指导，提高组织的软件开发能力，她的专注领域包括建立业务案例、为变更开发前景和路标、项目评估、基于结果的计划执行和指导等方面。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首