BPM实施：成功的 BPM 需要真正的团队解决方案

“聚集在一起是开始，维持在一起是一种进步，一起做事才算是成功。” —— 美国实业家和生产线生产方式先驱亨瑞·福特（1863-1947）

面向团队的 BPM 解决方法

最近美国队和日本队之间的女子足球世界杯决赛使我们有机会看到团队作战是如何带来成功的。赛前很少有人会认为日本队有希望战胜美国队。但是，正如我们所看到的，日本队不甘失败，她们赢得了胜利，这要归功于整个团队的目标统一、步调一致和精诚合作。与此相似，业务流程管理的成功也需要类似的团队协作。当业务线 (Line of Business, LOB) 和信息技术 (IT) 有关各方在流程开发和优化方面协调一致时，BPM 的成功几率最大。

过去，传统 BPM 主要关注面向 IT 的 BPM 解决方案。由于只关注技术，没有业务有关各方的参与，BPM 工具开发困难重重。结果，业务流程设计和开发被定义为传统的应用程序开发项目并按照传统项目执行。遗憾的是，典型的 IT 项目成功率并不是最佳的。根据 The Standish Group 的 CHAOS Summary 2009 报告（请参阅 参考资料），400
个组织接受了调查，几乎有 1/4（24%）的 IT 项目被认为是失败的。更重要的是，还有 44% 的项目被认为是不顺利的；例如，它们或者延期完成，或者超出预算，或者没有完全满足需求。因此，可以得出这样一个结论：应用这些传统的 BPM 解决方案会遭遇类似的难题。

最近，我参与了一个客户 BPM 项目。该客户花费了近 12 个月时间，英勇无畏地试图构建一个相对简单的 BPM 解决方案；遗憾的是，他们使用的工具过于偏向技术开发人员。该客户试图应用一种面向业务的设计解决方案，但开发出的业务流程不能完全理解业务需求和适应业务用户。一年以后，由于没有可以展示的成果，该项目被取消了。

混淆技术设计和业务设计是一个常见挑战。BPM 的成功需要业务和 IT 部门相互合作，打造一个能够实现其共同目标的设计，但这也正是挑战所在：组织如何一起定义和开发 BPM 解决方案的业务和 IT 部门之间的目标呢？基于业务的 BPM 解决方案要求业务和 IT 角色在 BPM 开发流程的各个阶段作为积极的参与者相互配合。尽管管理协作式 BPM 设计中的组织工作令人望而生畏，但 IBM 发现，传统的 BPM 开发途径往往是获得成功的主要障碍。如果没有一种同时考虑到业务和技术相关人员的开发和操作方案，BPM 会继续遭遇各种实现挑战，无法达到最佳效果。相反，如果某种解决方案能够促使业务和
IT 相关人员在 BPM 实现中密切配合，就可以实现更快的开发速度、更高的业务需求满意度和更好的解决方案质量。

传统 BPM 实现方式面临的挑战

在传统的 “老派” BPM 开发中，业务需求是从文档、电子表格、Visio 和 PowerPoint® 幻灯片中的业务线收集的。这些材料通常会接受 IT 人员的审查，生成一些经过更新的设计文档。这些文档看似更加完善，但它们的实际价值却令人质疑（尽管不能抗拒来自关键资源的 “必需” 审批签名）。根据这些经过更新的
“需求” 文档，IT 将生成后续交付物，并据此制作高级解决方案设计文档；业务用户将审查、批准并签署它们。随后，IT 部门会开始进行开发，开发期间仅仅通过定期检查一些检查点来更新业务需求。根据解决方案的复杂性，可能会创建一个原型，供用户评审。解决方案将根据用户反馈进行更新：更改通常源自一些沟通和记录不良的初始需求。基于这个流程，传统开发的失败率几乎是 1/4 一点也不奇怪，您在投币式弹球机上的成功几率可能都比这个高。

但是，当我们检查 BPM 设计方案时，还有其他一些因素在发挥作用。Economist Intelligence Unit 最近进行的一项调查（请参阅 参考资料）表明，实施
BPM 计划的组织有 80% 遭遇了员工抵制，取得的成功有限。抵制原因涉及两个因素：

员工在确定新流程的过程中的发言权很少甚至没有（31%）

新流程没有体现员工认为适当的作业方式（28%）

由于前面提到的业务和 IT 之间的鸿沟，使用传统的 IT 瀑布式 BPM 解决方案会导致不太成功的结果。更糟的是，业务用户通常会抵制变化；他们宁愿 “以同样的老方法” 工作，也不愿采用新方法。要获得 BPM 成功，则需要在这种业务流程开发解决方案中关注这些方面。通常，这个问题独立于在一个统一的设计和实现中捕获和定义业务需求方面的失败。

还记得本文开头引用的亨瑞·福特的名言吗？我们可以将福特的三个要点映射到一个 BPM 设计方案：

聚集在一起关注流程发现，让业务和技术团队共同定义需求并制作高级解决方案设计文档。

维持在一起定义一个迭代式开发解决方案，要求业务用户参与解决方案实现。另外，“维持在一起” 还强制实现工具开发和纪律严明的 BPM 治理解决方案，以确保将解决方案工件作为一个部署单元进行管理，并在一个 BPM 存储库中进行版本控制。

一起做事要求采用一个协调一致的解决方案，以支持一些生命周期操作/运行时间特性，比如 BPM 监控、管理和流程优化。

除需要一种更专注的 BPM 需求采集解决方案外，BPM 开发还需要一种灵活的、协作式 BPM 设计和优化解决方案。但仅仅采用一种灵活的解决方案还不够。关键是还要为 BPM 项目定义一些关键角色（包括流程所有者、业务分析师、业务流程架构师、流程设计师和集成开发人员），并确认适用于这些角色的技术资源。强烈建议
BPM 项目定义一个面向项目的工作分解结构，以便识别流程发现、流程设计和开发、实现和后实现活动等阶段，明确具体业务和 IT 相关人员的关键责任。还建议组织定义一些最终目标并制定一个策略，以便从试验计划发展成为基于项目的 BPM 计划，并最终成为企业 BPM 战略/计划。

协作式 BPM 业务流程管理需要一种经过改良的 BPM 解决方案实现方法。鉴于我们讨论的是一种协作式 BPM 解决方案的租户，所以我们主要关注的是 IBM® Business Process Manager，并会讨论和查看一些关键技术功能。尽管其他一些新兴工具也支持部分功能，但对 IBM Business Process Manager 技术和客户用例的概览将有助于我们探索全面的 BPM 解决方法所需的功能。

聚集在一起：支持流程发现和设计

首先，我们需要定义 IBM Business Process Manager 术语中的 “流程” 的含义。流程为流程的定义提供了容器，包括服务、活动和网关、计时器、消息、异常事件、规则和变量。流程在 Process Designer 中被实现为可重用的业务流程定义 (Business
Process Definition, BPD)。了解流程定义后，我们来看看支持协作式 BPM 开发这个概念的解决方案。

流程发现代表 BPM 开发中的一个关键活动，但是，如果业务用户在 Word 或 Visio 中采集他们的需求，然后将这个文档交给 IT 进行分析和设计，那么流程发现通常会受到限制。对于设计一个面向业务的解决方案而言，这不是一种良好实践。成功的
BPM 设计不仅需要一种方法，还需要提供一些工具，以便支持业务用户采集需求，与其他有关人员（包括 IT）积极配合，提炼这些需求。举个例子，IBM 的 Blueworks Live™ 解决方案提供了一个面向业务的、基于 Web 的解决方案，以便进行流程建模、需求采集以及关键流程文档制作。可以将 Blueworks Live 作为一个可控的 “软件即服务” 解决方案为其提供支持，大型和小型流程设计团队都可以轻松管理它。

最近，我的一个客户正在设计一个开户解决方案。业务相关人员与一位系统集成人员合作，定义高级解决方案设计。使用 IBM 的 Blueworks Live，业务用户能够快速确定端到端流程的里程碑和活动，开发一些初始流程模型。这个功能允许业务用户设计并原型化他们想象的开户流程，将来自公司信息技术团队的协助降至最低。图
1 展示这个客户的 on-boarding（开户）流程在 Blueworks Live 中的发现映射。褐色方框表示流程中的高级里程碑，蓝色方框表示特定里程碑对应的任务和活动。


图 1. Blueworks Live 发现映射



然后，这个发现映射用于创建一个初始流程图，其中包含泳道（swimlane）定义、决策步骤和高级流程逻辑，如图 2 所示。

图 2. Blueworks Live 初始流程图



可以对流程设计进行分析，洞察流程流特征、循环时间、资源需求以及潜在的系统影响。更重要的是，业务和技术用户可以直接共享这个设计，以便优化设计并确保 BPM 需求统一。

使用一种协作式流程发现方法，这种类型的计划为开户实现的开发提供了初始工件。IT 可以使用 IBM 流程开发工具直接连接到 Blueworks Live 中的这些资源。另外，流程工件可以以多种格式导出（包括 BPMN 2.0 和 XPDL 2.1），并支持其他流程工程解决方案

维持在一起：管理流程开发

完成流程发现之后，业务和技术相关人员需要一种协作式或迭代式的开发方法来确保流程的成功实现。BPMN 的发展已经成为面向业务的解决方案设计中的一个关键支持因素，它提供了很适合业务用户审查和编写的可视化/图形化建模。但 BPMN 的使用仅仅是支持协作式 BPM 设计的一个方面；业务流程和定义的快速原型化和技术集成组件的实现还需要
BPM 工具开发。

已购买的 Lombardi 解决方案和 IBM 行业领先的 IBM WebSphere® Process Server 的结合提供了一个直接支持这种方法的代表开发基金示例。图 3 显示了这个高级 IBM Business Process Manager 解决方案架构。


图 3. IBM Business Process Manager



Process Designer（右上角）支持流程建模、原型化和测试，将其作为 BPM 开发的一部分。开发环境是基于 Eclipse 的，使用图形工具和属性表单来支持组件实现。通过拖放设计和填充关联属性表单，业务和技术用户可以快速创作流程工件。这些工件包括：

业务流程应用程序包含解决方案的流程和服务。

业务流程定义定义 BPMN 流程流。

工具包提供一个可重用、可共享、可跨解决方案使用的组件集。

代表业务流程应用程序或工具包的可部署版本的快照（snapshots）。

支持多个团队在同一个流程的多个版本上平行工作的跟踪（tracks）。

Process Designer 支持拥有基于 IBM 的 ILOG® JRules 的规则创作经验的开发人员进行业务规则创作。另外，规则内容可以导出到 ILOG JRule，以支持企业业务规则管理。

作为这种开发方法的一部分，Process Designer 支持 BPM 解决方案的直接回放，从而支持需求验证和与业务用户之间的交互式原型会话。

技术集成工件的开发通过 Advanced Integration Services (AIS) 支持完成。AIS 组件提供一些实现资产，这些资产允许从其他 Process Design 服务调用。AIS 接口对应 WSDL 定义的单个操作，通过实现模块的 SCA 导出公开。通过基于 BPEL 的微观/宏观流、基于 ESB 的中介流、与 IBM 的基于 JCA 的连接器的集成、接口和数据映射、关系、以及其他高级流程设计功能，这些组件能充分利用 SOA 的威力。

图 4 展示了这些组件之间的交互；“蓝色云彩” 代表一个业务流程，该流程通过对一个服务接口（通过 “I” 指定）的绑定调用一个 AIS。这个模块额外调用了一个中介模块，然后将控制权返回给调用流程（右下角的蓝色云彩）。

图 4. AIS 组件



这种方法支持面向业务的流程设计和作为可共享服务的技术集成组件，促进业务和技术问题之间的松散耦合和分离。AIS 组件的开发通过 Integration Designer 实现。IT 开发人员使用 Integration Designer 来实现在特定业务流程内部调用的技术集成组件（AIS）。这些资产在 IBM Process Center 中作为可重用组件管理。Integration Designer 提供组件实现，包括数据转换工件、Business Process Execution Language (BPEL)
业务流程、以及应用程序和后端系统接口。Integration Designer 组件在模块中组装，利用导入和导出来提供模块间集成。另外，有一些库提供了一些可在集成模块之间共享的组件集合。

Integration Designer 提供跨多个传输/协议标准支持组件绑定的能力，这些标准包括 SCA (Service Component Architecture)、基于 SOAP 的 Web 服务（HTTP 或 JMS）、JMS、IBM WebSphere MQ、HTTP/REST、EJB/Java™ EE、EIS（Enterprise Information Systems，包括 SAP、PeopleSoft、Seibel 和其他关键企业应用程序）。Integration Designer 支持在包含的本地
Unit Test Environment 上测试模块和组件。集成服务与 Process Center 同步。另外，IBM BPM 开发工具能直接与 Service Registries（比如 IBM WebSphere Service Registry and Repository）集成，提供 SOA 治理。

协作式 BPM 开发的关键方面聚焦于提供一个健壮的 BPM 存储库。在 IBM BPM 产品中，Process Center 提供这种功能，通过锁定管理对流程应用程序的并发访问。Process Center 提供资产管理和跨流程应用程序的资产的版本控制。通过 Process Center 控制台，开发人员可以管理流程应用程序、工具包以及关联流程工件的创建和管理。图 5 展示了 Process Center 的主要关注领域。

要在协作式 BPM 开发中取得成功，则必须提供一个共享开发平台，还要拥有控制和管理应用程序到运行时环境的部署的能力。例如，Process Center 支持流程资产和关联依赖项的治理和管理。流程应用程序包含对一个或多个工具包的引用，以支持可共享/可重用的组件集合，比如规则、服务和接口。当开发人员实现解决方案时，会将这些更改保存到 Process Center 存储库中。另外，流程应用程序快照是一些部署单元，可以将它们部署到远程 Process Center 或远程运行时服务器，将它们用于测试、暂存 (staging)
和生产。

BPM 工程中的另一个关键功能是支持并发流程编辑的能力。IBM BPM 解决方案通过平行工作空间支持这个功能。Process Center 负责管理业务流程定义和工具包的版本。这种独特的版本控制方法提供了支持 “时间逆转” 版本管理的功能，允许开发人员和管理员根据需要回滚到以前的版本。

通过 IBM 与客户共同实现 BPM 解决方案的经验，我们看到有一系列完整的 BPM 需求。我们的许多客户拥有高级需求，而其他客户只是刚刚开始接触 BPM。IBM BPM 支持多个配置，以匹配某个公司的 BPM 发展过程中所需的典型入口点或阶段。下表列示了这些配置。

表 1. IBM BPM 配置

配置	阶段
高级	变革 完整的业务流程管理功能集 扩展的大容量流程自动化支持。 广泛的企业级服务集成和业务流程的内置 SOA 组件。
标准	计划 典型的业务流程管理项目配置 针对多项目改进计划，涉及较多的业务参与。 基本系统集成支持。 快速实现价值和提高用户生产力。
快速	项目 首个业务流程管理项目配置 快速实现价值和提高用户生产力。 低入门价格。 轻松安装和配置。

企业级集成需求通常要求 “高级” 配置，该配置包含 Integration Designer 来支持企业级流程和服务集成。（关于 IBM BPM 配置之间的区别的深入讨论超出了本文范围。有关配置的详细信息，请参阅 参考资料。）

总之，在 BPM 解决方案开发领域，同时支持业务和技术相关人员的能力对于实现面向团队的 BPM 解决方案至关重要。在 IBM BPM 解决方案中，Process Designer 和 Integration Designer 为 BPM 开发提供了一个创新的协作式平台。Process Designer 为业务和 IT 相关人员开发 BPM 流程解决方案提供了 Integration Designer 工具，支持 IT 将集成组件开发为可重用资产。这些功能如图 5 所示。

图 5. Process Designer 和 Integration Designer



因此，业务和 IT 用户使用 Process Designer 来编辑流程定义和相关资产。这个集成的视角提供了一个面向业务的流程解决方案视图，不需要业务用户理解或设计技术实现内容。类似地，技术开发人员使用 Integration Designer 提供相关业务项目和流程的可视性，以支持组件开发。

一起做事：提供流程管理和优化

当内外部因素（比如经济形势和法规要求）发生变化时，正在进行的 BPM 计划能否成功取决于是否具有随时间变化而优化流程的能力。因此，需要在开发和设计期间细化流程的优化，后续流程实现应该作为流程生命周期的一部分。这个要求意味着 BPM 方法和相关工具开发需要直接支持流程的管理、监控和正在进行的增强。例如，IBM 的 Process Center 解决方案支持在一个给定业务流程的生命周期内持续进行协作式设计和流程优化。BPM 工具中的内置治理和版本控制功能，结合 BPM 监控功能，提供 BPM 解决方案生命周期管理和优化。这种解决方案允许业务和
IT 相关人员通过一个共享流程模型不断改进流程定义，支持流程改进。

“一起做事” 代表流程生命周期管理的闭合循环特征。简言之，改进流程的最佳方法就是先进行测量，然后采取适当的步骤来优化发现的瓶颈。通过丰富的监控工具，流程所有者和相关人员能随时间变化积极优化业务流程。在 IBM BPM 解决方案内部，Process Portal 提供一个重要任务视图，以及总体资源和流程性能的可视化。在流程执行过程中，IBM BPM 解决方案通过 Performance Data Warehouse 中积累的指标收集并关联性能事件和业务数据。

另外，Process Portal 中的管理功能允许终端用户基于与他们的特定角色关联的特权初始化并更改流程。Process Portal 向管理员提供管理运行时服务器的能力。在 IBM BPM Advanced 版本中，可以通过 IBM Business Space 功能扩大这些功能，提供基于角色的自定义用户界面，可以在独立模式下支持这些功能，也可以在 IBM WebSphere Portal 环境中支持它们。下图展示了通过 Process Portal 环境支持的界面类型的样例，其中包括仪表板、记分卡和 BPM
诊断器。

图 6. 通过 Process Portal 支持的界面



“一起做事” 的概念可以通过流程模型图中的性能瓶颈的可视化来实现。这个功能允许流程所有者快速识别潜在 “热点”，向他们提供推荐流程增强。IBM BPM 解决方案还提供了一些管理和监控功能，包括：

IBM Business Process Manager for Microsoft® Office，允许用户通过一个 Outlook® 插件直接从他们的 Office 桌面查看和运行 IBM BPM 任务。

IBM Business Process Manager for Microsoft SharePoint®，允许 SharePoint 用户从 SharePoint 门户页面查看和运行 IBM BPM。

通过使用 IBM Business Monitor，IBM BPM 解决方案可用作综合业务活动监控解决方案架构的一部分。

IBM Business Monitor 解决方案支持汇总并显示了来自 IBM BPM 解决方案和其他内外部源的信息，这些内外部源包括 B2B 解决方案、第三方应用程序以及其他中间件组件。IBM Business Monitor 中的扩展功能提供实时可视性，支持可视化和管理跨多个应用程序和组织边界的扩展解决方案架构。IBM Business Monitor 包含 IBM 的 Cognos® Business Intelligence 10.1 平台的一个有限许可，支持对这些扩展解决方案进行报告和预测性分析。IBM
Business Monitor 支持许多 IBM 技术，其中包括 IBM BPM、IBM Decision Server、Integration Designer、IBM Industry Packs、WebSphere Business Events、IBM FileNet®技术、IBM Case Manager、IBM CICS®、WebSphere Adapters、WebSphere Enterprise Service Bus 以及其他关键 IBM 技术。

对实时 BPM 流程提供实时控制和快速识别 BPM 执行中的关键瓶颈的能力对于流程管理很重要。至少，流程所有者需要内置的管理功能来快速响应流程性能变化。更重要的是，BPM 解决方案必须允许相关人员通过记分卡和仪表板理解和预测流程性能。通过这些功能，相关人员才能够更好地理解流程行为，相互协作，支持持续流程优化。

回页首

亨瑞·福特和 BPM：成功需要团队解决方案

就通过生产线概念标准化汽车制造而言，亨瑞·福特对基于团队的协作的远见是革命性的。通过采用一种团队解决方案来制造汽车，福特将一些关键 BPM 原则应用于制造业，为未来指明了方向。他根本不会知道那些概念会在将近 100 年之后应用于协作式 BPM 中。福特的 “聚集在一起、维持在一起、一起做事” 的理念可以直接映射用于 BPM 发现、设计和开发、执行和完善的协作式解决方案。

如前所述，传统 BPM 实现方法自身提供的 BPM 解决方案往往不够全面。传统实现方法不能满足大多数 BPM 项目的需求，因为它过分关注技术，限制了业务用户在流程设计和开发中的参与程度。另一方面，BPM 在促进业务变革方面是成功的，这通常需要业务用户积极参与 BPM 生命周期活动。协作式 BPM 管理解决方案建立在业务和技术相关人员共同参与解决方案的设计、开发和优化之上。

通过采用这些总体原则，将其作为 BPM 计划的一部分，一些组织会发现，BPM 项目将会更加成功，BPM 解决方案将会给企业提供更高的商业价值。

引用：http://www.ibm.com/developerworks/cn/websphere/techjournal/1108_col_simmons/1108_col_simmons.html