ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 用于产品生命周期管理的 SOA 方法,第 3 部分: 业务流程管理

用于产品生命周期管理的 SOA 方法,第 3 部分: 业务流程管理

原创 Linux操作系统 作者:isoa 时间:2009-04-03 13:39:15 0 删除 编辑
本文在虚构的 Trucks Inc.的业务问题上下文中讨论业务流程管理(Business Process Management,BPM),并对其做出定位。

BPM 是公司需要处理的一项战略业务决策。Trucks Inc. 对端到端 BPM 并不熟悉。虽然存在一些针对特定过程的文档,但是这些文档基于纸张,没有关于流程执行时间或成本的可见性。此外,它们从未进行更新,组织中没有人正式负责确保流程质量和完整性。

应用程序之间的点对点数据流实际上是没有受到 IT 组件控制的较大业务流程的孤岛。Trucks Inc. 曾接受过有关 BPM 优点的教育,并作为其战略重组活动的一部分对 BPM 工具和方法进行了投资。

与 Trucks Inc. 展开讨论的第一个主题是确保他们拥有清楚的流程定义。流程用于桥接业务交付产品、服务或最终可交付件的需求与用于支持该交付的技术之间的差距。可以将流程描述为一组链接在一起的活动,它们接受一个输入,并对其进行转换以创建输出。在理想的情况下,流程中发生的转换必须为输入增添价值,并创建对上游或下游接收者更有意义或有效的输出。可以将 BPM 模型看作是某个时间点捕获的事实的多维表示形式。该模型具有目的、远景、受众、内容、详细级别以及阶段。它用于总结信息和传达信息。流程模型包括流程中所有活动的详细规范以及关键性能指标。

此定义还强调了活动与流程中发生的转换之间的联系。流程的特征如下:

  • 可定义性

它必须具有清楚定义的输入和输出边界。

  • 顺序

它必须由按照各自的时间和空间位置排序的活动组成。

  • 客户

流程的结果必须有接收者。

  • 增值

流程中发生的转换必须为上游或下游的接收者增添价值。

  • 嵌入性

流程不能独立存在。必须将其嵌入到某个组织结构中。

  • 跨功能

流程通常可以跨越多个功能。但不是必须要如此。

  • 流程所有权

流程必须有所有者。必须有某个人员负责流程的性能和持续改进。

此外,可以在多个级别定义流程以区分战略方向、业务执行和技术管理。BPM 社区中有关应该存在多少个级别的流程(以及每个级别的名称和意图)的意见各异,但是下面给出了一个示例:

  • 第 1 级:企业视图

从其主要功能或活动类别方面进行描述的业务。

通常根据人员、资源和责任性的使用来划定边界。

  • 第 2 级:业务功能视图

第 1 级视图的一个组件,从其主要功能或活动类别方面进行描述。

  • 第 3 级:流程

主要业务功能或活动类别,是第 2 级视图的组件。

  • 第 4 级:子流程

完成第 3 级流程所需要的操作。第 4 级定义完成子流程的概念性方法,并定义用于完成该子流程的最佳实践。

  • 第 5 级:活动

描述构成子流程中包括的一个或多个操作的活动组、活动或工作步骤。这是最详细级别的流程模型,并包括服务和集成的捕获结果。

  • 第 6 级:工作步骤

描述构成每个工作步骤的工作步骤详细信息。工作步骤的定义应该足够详细,以允许对照系统需求进行验证。

  • 第 7 级:步骤脚本

与工作步骤相关的详细决策表、测试脚本、配置设置以及详细的工作步骤叙述。最终用户材料、帮助窗口、帮助台材料以及其他支持教育和培训的文档。

业务流程管理

BPM 是将软件功能和业务专业知识相结合来加速流程改进和促进业务创新的学科。由面向服务的体系架构(service oriented architecture,SOA)支持的 BPM 提供了灵活的体系架构样式,以支持高效的流程更改和快速的流程部署。要让 BPM 项目取得成功,使用支持 SOA 的软件和拥有交付及履行 BPM 承诺的专业知识都是非常关键的。BPM 已发展到处理现代业务的挑战,并认识到需要业务方法、组织效率和软件来处理当今业务的流程需求。


图 1 BPM 通过利用世界领先的 BPM 应用程序、方法、标准和高度熟练的专业人员,从而处理与业务流程的捕获、分析采用和执行相关的挑战

最终,采用 BPM 对 Trucks Inc. 的好处如下:

  • 流程洞察和优化

许多合作项目中的第一步是监视正在发生的情况。

了解业务中正在发生的情况可以促进相关能力,以增强组织的最重要和最有影响力的部分。

  • 加速流程改进

此步骤不只是涉及到改进和优化。它还涉及到您能多快地确定驱动更改的业务部分,以及能多快地实现和部署那些更改以实施改进。

  • 适应将来更改的灵活设计

不仅现在做出更改非常重要,而且为每个组织都必须面对的将来更改做好准备也非常重要。

在讨论 Trucks Inc. 的 BPM 采用之前,让我们首先检查一下他们的业务基础结构的条件。第一个观察结果在于,该基础结构是异构的,并且非常复杂。由于 Trucks Inc. 是通过公司合并形成的,这种复杂性进一步增加。其特征表现为一系列针对点问题的业务应用程序、多种技术和保持业务正常运行所需要的专门技能集。另一个观察结果在于,很难获得驻留在不同 IT 系统中的上下文相关的业务信息。给定此业务基础结构,公司 IT 要跟上不断变化的业务条件几乎是不可能的。

事实上,IT 很难跟上形势的发展。更糟糕的是,就 IT 在这些条件下创建或更改应用程序的能力而言,业务部门与 IT 之间已经形成了鸿沟。由于 Trucks Inc. 是通过组织创建而成的,此问题进一步复杂化。作为外部经济因素,客户转移能力、法律法规压力以及产品和服务开发混杂在一起,推动了对更强的流程灵活性的需要。IT 经常陷入操作和现有应用程序维护之中,而无法及时做出响应。组织推迟进度以等待开发人员更改核心应用程序中嵌入的业务流程是不合理的。话虽如此,对于核心应用程序和基础结构元素的可用性和可审核性,IT 必须维持可理解程度的所有权。因此,IT 和业务部门必须采用某种手段有效地协作以完成业务目标。每个实体还必须有某种方法在不影响其他实体的情况下管理和更改其环境。这种多作用和多方面的功能集,以及让业务用户能够创建或更改流程并维护流程可见性的能力,在 BPM 中处于核心地位。

采用流程标准

为了帮助 BPM 方法的采用,Trucks Inc. 检查了行业标准流程的结构和内容。存在许多可能对 Trucks Inc. 有用的标准流程来源。对于技术级别的工程更改流程的执行,他们可以依赖 Verband der Automobilindustrie (VDA) 组织。VDA 为 ECM 流程提供了有关客户与供应商之间使用标准进行更改数据交流的支持,例如 ISO10303-214 (STEP AP214) 和 OMG 推出的 PLM 服务。从业务流程的角度看,Trucks Inc. 可以考虑价值链操作参考(Value Chain Operations Reference,VCOR)、供应链操作参考(Supply Chain Operation Reference,SCOR)或设计链操作参考(Design Chain Operations Reference,DCOR)模型,尽管这些模型通常以核心产品开发领域为中心。但是为了扩展 BPM 采用的范围,建议 Trucks Inc. 使用某个特定于行业的流程分类框架(process classification framework,PCF)。最初的通用 PCF 由美国生产力与质量委员会(American Productivity and Quality Council,APQC)组织所创建。有关 APQC 的详细信息,请参见以下网站:

http://www.APQC.org

此通用 PCF 是 APQC 在包括 IBM 在内的合作伙伴的支持下创建的。APQC 合作伙伴随后创建了特定于行业的模型(包括汽车业),并作为开放源代码标准可用。

这些 PCF 提供了流程的层次结构,任务、决策和角色的术语共性,以及等效于本文前面提到的第 5 级定义的详细流程模型。

在许多情况下,流程的定义中使用了模式。这些模式是可重复的流程任务或决策分组,在整个端到端流程框架中重用了许多次。流程模式的示例是审查周期。审查在整个产品开发周期中进行,从某人确定新卡车的市场机会开始,到回收有害材料时结束。审查的参与者、数据和位置可能各不相同,但核心步骤是相同的。

  1. 确定对审查的需要
  2. 收集将要审查的数据并将其分发给审查团队
  3. 审查团队对后续步骤做出评估(包括他们是能够自己定义后续步骤还是需要外部势力)
  4. 实施后续步骤。

图 2 显示了此审查模式的示例。


图 2 审查模式示例

除了流程本身以外,PCF 还包括全套关键性能指标(key performance indicator,KPI)。通过采用这些 KPI,如果 Trucks Inc. 利用 PCF 并向 APQC 订阅,则与该标准组织的其他成员相比,他们将能高效地对其业务有效性进行基准测试。作为 BPM 采用的一部分,Trucks Inc. 在法律上必须证明某些流程中的功能,以实现认证和规章遵从性。通过使用为适应 Trucks Inc. 的特定流程需要而定制的行业 PCF,阐明遵从性的挑战得到了极大的简化。

有控制的流程灵活性和创新需求

值得注意的是,即使同属相同垂直市场,也没有任何两个组织是完全相同的。虽然他们可能拥有在某些市场的宏观级别相当一致的业务流程(例如管理客户帐单),但是每个公司或组织都会增添自己的细微差别,并定制那些流程版本以反映各自的业务需求。对于受管制的市场,业务流程还必须是可审核的,并且同样有不同程度的管制在影响着整个市场的各个组织。

但与此同时,组织还必须在各自的业务实践中实现创新,无论这意味着寻找改进服务的方法还是缩短产品开发周期以使用高质量的产品和服务更快速地响应市场来实现流程中的这种灵活性。

要处理的广泛需求

来自合并前的两家公司的单独业务最佳实践、行业标准流程(例如源自 APQC 的标准流程)、针对安全和环境注意事项的法律法规需求以及创新的动力混合在一起,因此 BPM 解决方案必须处理广泛的流程类型、构成、参与者和性能需求。需求涵盖以下情况:

  • 需要将多个应用程序绑定在一起的流程,以便能够在应用程序间具有适当控制的情况下对数据进行处理。
  • 需要与业务操作(或作为其结果)紧密一致地保留文档并将其声明为记录的应用程序。
  • 处理异常以及从结构化的流程中解决异常的能力
  • 集成共享领域的能力,团队成员可以在这些领域就项目和相关材料进行合作

处理复杂性:流程和参与者

Trucks Inc. 中存在所有这些需求,必须将它们联系起来以处理更加复杂的操作。还必须基于行业和业务法律法规对它们进行监视和审核。BPM 解决方案必须使组织能够捕获和轻松更改关键流程元素:

  • 信息在人员和系统之间必须经历的路线
  • 参与流程的角色
  • 控制这些相互关系的规则和策略

还必须处理参与这些流程的各种各样的角色。

这包括业务部门流程所有者、提供集成和定制功能的 IT 专业人员、仅查看跨流程的性能仪表板表示形式的经理和主管,以及可能对流程进行建模和模拟的业务分析人员。BPM 必须提供支持所有上述情况和参与者的定制体验。

保持以业务用户为中心

尽管具有可能的复杂性,BPM 必须交付适当的信息,据以通过直接了当的方式作出决策。

这从对流程进行建模、模拟和修改的能力开始。对于需要人员做出决策的流程,或者对于可能需要人员参与自动化流程的情况,在业务用途的上下文中交付信息是极为重要的。对于 BPM 解决方案,这意味着处理适当的业务角色、获得驱动决策所需的有效信息,以及使用户能够在继续之前与信息交互。在某些情况下,动态地(例如,在流程预先不知道要调用哪一个特定应用程序或服务的情况下)向业务用户提供正确的应用程序或信息的能力是一项需求。此外,当需要流程内部或外部的各种信息来做出决策时,将采用门户(并最终采用 Web 2.0 技术)向业务用户交付统一和上下文相关的视图。

BPM:战术与战略方法

在 Trucks Inc. 中开始 BPM 活动时,董事会已决定他们将实现 BPM 以处理新合并的公司中单个业务领域中的特定难点。但是,即使在那些情况下,BPM 解决方案也不会是独立的孤岛。它必须与其他应用程序集成,它必须足够灵活以允许频繁地更改流程,它还必须为使用它的人员提供正确的上下文。但与此同时,BPM 也不能牺牲流程灵活性,并且它必须容易与信息管理工具集成,无论那些工具是用于分析还是与内容相关,以确保为用户提供他们在适当的上下文中做出决策所需要的内容。

在 Trucks Inc. 处理完整 BPM 实现这个更大战略目标的时候,上述所有需求都适用,但是所选的 BPM 解决方案集合或组合还必须提供其组成部分之间的互操作性,从而为用户、经理、开发人员和其他参与者提供有效支持。

供应商还必须提供广泛的功能以处理组织中的广泛流程,无论那些流程是协作的还是事务性的,是结构化的还是动态的。同时从流程的范围内(通过业务活动监视或有关流程性能及基础结构性能的分析)和流程外的相关应用程序或事件方面优化流程的能力正日益成为一项需求。

动态流程、BPM 和 SOA

必须利用 BPM 与 SOA 的关系,以增强流程中的动态需求,以及反映通过更改组织、市场和业务需求来轻松修改基础结构和集成应用程序的能力。设想创建一个金融帐户开立流程,该流程足够灵活,在新客户提供有关其状态的信息和外部系统帮助确定他的信贷价值时,能够实时确定若干帐户选项中哪一个选项是适当的;其中只需对流程重新建模以利用新的服务和遵循更改后的业务规则,即可对客户的信贷价值做出更改。而且随着流程变得更加复杂以及集成的动态性,那些流程对信息和内容更改做出反应或轻松获得信息以实现自动化或人工决策的能力变得前所未有的重要。

BPM 与企业体系架构(Enterprise Architecture,EA)

在 Trucks Inc. 的 BPM 采用过程中,必须从体系架构的角度考虑 BPM,给定该组织对转向 SOA 的日益增加的需要以及支持信息基础结构的相关需求,情况尤其是如此。EA 规程认为存在单独但相关的业务、信息和技术体系架构组件。因此,BPM 解决方案必须遵守技术基础结构和平台需求,同时还要提供业务灵活性和与信息管理标准的联系。

因此,组织必须考虑提供以下特性的功能和供应商:

  • 多个 BPM 入口点

具备如下特征的一组广泛的 BPM 功能是至关重要的:它们可互操作但是可分离,并且足够开放以适应当前和将来的体系架构平台、应用程序、流程和信息需求。可分离性非常关键,因为并非每种情况都需要 BPM 技术的每个方面。例如,有些组织在对流程监视一段时间之后确定了哪些流程需要优化(以及如何优化)。其他组织面对不断变化的业务需求,确定了要需要创新的流程。

  • 处理多个业务场景的能力

能够处理从协作到事务的广泛流程,同时向流程的任何阶段中涉及的每类用户(业务、IT、管理等等)交付适当的上下文重点,这样的 BPM 技术非常重要。流程起初可以按照主要特征(例如,在线帐户开立)进行指定,但是可能需要不同的 BPM 功能以满足次要需求(例如,需要捕获文档以满足规章遵从性的客户例外情况)。供应商必须提供此系列功能,并在其中提供适当的可互操作性。

  • 灵活性和更改流程策略及规则的能力

灵活性是 BPM 技术的一个主要优点,解决方案必须在所有平台中反映此优点。这意味着流程建模与开发工具和标准集成,同时提供用于流程模拟和优化的信息并对信息做出反应。它还需要动态链接和编排外部服务及其他流程以处理更复杂业务情况的能力。必须解决包括及规定协作和面向团队的功能以解决例外情况或处理较偶然流程问题的能力。

使用 BPM 处理特定业务需求

为了将采用 BPM 的战术优点作为某些关键业务挑战的实用解决方案来加以推动,Trucks Inc. 必须确保他们的 BPM 解决方案提供从建模直至监视的全套集成功能,同时确保处理组织确定要实现优化(或者甚至是要实现简单自动化)的关键流程。在优化时,利用直接从流程中得出的分析结果以及与流程相关的外部分析结果(例如,可能影响供应链流程的区域销售数据)的能力正在变得更加关键,持续地建立和测量流程 KPI 的能力也是如此。能够纠正流程,或者推动可以处理通过分析指定的动态业务需求的策略,这将成为下一代 BPM 的标志。战术 BPM 方法还必须取得微妙的平衡,既要处理为之做出优化的流程,同时又要提供足够的回旋余地和互操作性以拓宽流程范围或处理例外。

专业知识

通过行业专业知识快速着手进行流程优化是非常关键的,无论那些专业知识是预先建立的基于标准的角色和 KPI、行业基准,还是面向垂直行业的服务。能够利用反映适当角色、安全性和功能的预定义数据模型或模板,这不仅可以提高实现速度,而且还可以提高可用性并确保普遍性和轻松地顺应行业预期。

给定通过 BPM 加强组织中业务用户能力的要求,通过交付熟悉和可接受的用户环境来方便快捷地处理业务需求的能力极为重要。

使用 SOA 支持的 BPM 加强 LOB 和 IT 的协作能力

虽然配备 IT 的目的是解决复杂技术问题,但是 IT 并不知道如何最佳地优化某个流程,或者必须跟踪哪些关键性能指标才能跟踪和优化业务性能。直到最近为止,业务部门虽然清楚关键业务流程,但是还不具备在条件更改或预期要更改时更改业务流程的能力。

但是,除非 Trucks Inc. 采用某种经过证明的方法,通过该方法创建和部署其 BPM 内容以推动业务导向的更改,否则他们对创新 BPM 软件的使用将毫无意义。

实现业务流程管理

实现 BPM 的挑战之一是需要在处理业务级挑战的自顶向下方法与开发服务的自底向上方法之间取得平衡。为了解决此挑战,需要在 PLM 领域中的技术和业务架构师达成一致意见的情况下将 Trucks Inc. 流程分离为各个构成组件,应用程序也需要类似的分离。

组件业务建模(Component Business Modelling,CBM)是一种经过证明的方法,可以让组织通过将活动重新分组到数量可管理的离散、模块化和可重用的组件中,从而确定改进和创新机会。可以使用 CBM 推动自顶向下的开发活动。这可以实现灵活性,并清楚地将重点放在运行业务和推动战略所需要的核心功能上。

CBM 的主要方面如下:

  • 业务组件是企业中具备独立操作潜力的部分(例如,它具备已定义和已声明输入和输出集,并且可以在有限附加外部影响的情况下运行)。业务组件是企业一部分的逻辑视图,该部分包括交付价值所必需的资源、人员、技术和专门技能。它具有高度的自主性,单独进行管理,并通过业务服务和集成信息系统与组织的其他部分联系在一起。
  • 业务组件映射是业务组件的表格式视图。该映射提供有关业务的自顶向下视图。
  • 业务组件模型是用于描述某个企业或行业的业务竞争力、业务组件、业务服务及其关系的术语。

用于重型卡车行业的标准组件业务模型模板已经创建,并形成了 Trucks Inc. 的 CBM 评估的基础。使用这些模板作为与客户讨论的起点,然后可以根据客户的工作方式对模板进行专门定制。由于该 CBM 进一步划分为一套行业流程和子流程(请参见图 3)以及一套 KPI,因此可以使用此模型来确定业务流程中有待改进的部分。


图 3 行业流程和子流程的组件业务模型套件

实现 BPM 远不只是确定流程改进机会那么简单。与任何新的战略方向的实现一样,不仅必须考虑流程或新技术,而且还必须考虑将执行流程的人员。在采用 BPM 时,Trucks Inc. 必须考虑他们打算做的工作的组织更改管理影响,这其中包括以下影响:

  • 组织构造

新流程或技术的采用可能影响当前组织的构造方式。作为 BPM 的一部分,将对组织当前状态下的效率和所需条件下的预测效率进行评估,并提出有关重大组织重组的建议。

  • 教育和培训

BPM 采用给组织带来了对附加培训和教育的需要:教育是关于为什么给定的角色正在执行某个任务的说明,培训是确切地说明如何执行某个任务。

在从原有 BPM 状态转向将来状态时,大多数公司都要经历包括四个阶段的实现方法:

  • 概念验证

捕获新流程的意图,并短期测试新流程和新技术以捕获有关新流程有多好、有多廉价或有多快速的指示。此 PoC 阶段通常采用测试数据在独立环境中实施。

  • 试验

进一步测试新工具和流程,通过大量数据和更频繁的执行为工具和流程施加显著的负载。通常使用实时数据库的副本在预生产 IT 环境中执行。

  • 实现

将新工具和流程全规模地部署到实时数据之上的用户社区。

  • 支持

提供用户支持以确保新工具和流程的无缝采用,以及从更广泛的用户社区收集反馈。

为了采用 SOA 术语来表达这四个步骤,我们将 BPM 的实现考虑为以下阶段

  • 建模阶段

捕获当前状态的静态流程模型。此原有模型提供了有关当前流程成本和执行时间长度的视图。

基于 APQC 流程分类框架行业流程创建特定于客户的动态将来流程,并同样应用代表性时间和成本数据。原有与将来模拟结果的比较提供了投资回报和业务案例以论证客户的 BPM 开支的合理性。

除了简化和有效的业务流程以外,在将来模型中还将捕获 KPI,用来在该周期中的以后监视流程的运行状况。在建模阶段结束时移交给 IT 架构师的业务成果是业务流程执行语言(Business Process Execution Language,BPEL)模型。

  • 组装阶段

IT 架构师实现建模阶段中的 BPEL 输出。

然后开发人员能够优化流程的执行,基于集成平台实现策略和规则,并在部署到生产环境之前彻底测试该实现。

  • 部署阶段

包括人工任务管理在内的流程执行和自动化(工作流和编排)是业务流程的重要元素。

执行是通过流程引擎(最好运行在 ESB 和安全应用程序服务器上)上部署的组装活动结果来进行的,并且可以包括与内容管理的集成。在所有业务流程中,随着工作的推进,都会创建或使用信息。

内容是要在业务流程中操作的主要对象。

因此,流程参与者需要能够创建新内容,同时还需要能够访问和利用现有内容。正确的时间手边有正确的信息可用,对于流程成功至关重要。

  • 监视阶段

业务活动监视是监视流程性能和检测可能影响性能的事件的能力。要分析流程效率和有效性并让流程改进与企业目的和目标保持一致,这涉及到使用诸如 WebSphere Business Monitor 等软件来侦听关键业务事件、关联事件数据,以及更新建模阶段中捕获的 KPI。

BPM 工具

在 BPM 内容的创建和部署中,我们向 Trucks Inc. 推荐了以下 WebSphere 产品套件:

  • IBM WebSphere Business Modeler

此产品提供流程建模、模拟和分析功能,以帮助业务用户可视化、了解和记录业务流程以实现持续改进。除了对资源、角色、组织、信息和业务度量建模以外,它还使业务用户能够对至关重要的业务流程进行设计、建模并做文档记录。

  • IBM WebSphere Integration Developer

在生产环境中进行部署之前,业务流程优化所产生的应用程序和集成的开发、组装和测试中将使用本产品。它是用于构建跨 WebSphere Process Server、WebSphere ESB 和 WebSphere Adapters 的基于 SOA 的解决方案的公共工具。

  • IBM WebSphere Process Server

此产品通过自动化任务和人工任务来管理 WID 中定义的流程、集成和应用程序的执行。

  • IBM WebSphere Business Monitor

此产品通过以下功能提供业务性能的端到端可见性:

    • 可自定义的仪表板
    • 针对新出现的业务情况的早期检测和警报
    • 用于实现流程改进的完整 WebSphere Business Modeler 反馈机制
    • 显示在仪表板上的近实时信息

这些功能提供了做出及时更改和执行高级分析以基于历史记录和趋势数据制定决策的能力。除了处理从事件源接收的事件以外,WebSphere Business Monitor 还可以将其他业务参考信息引入 Business Monitor Server。与 WebSphere Integration Developer 和 WebSphere Process Server 集成以后,WebSphere Business Monitor 可以全程跟踪 WebSphere Enterprise Service Bus 和 WebSphere Process Server 中运行的所有组件的活动。

  • IBM WebSphere Business Services Fabric

此产品使业务用户能够根据不断变化的环境动态地更改和适应(例如,在开发周期中的不同部分使用替代供应商,或者能够根据一组业务规则做出更改)。请参见图 4。


图4 用于 SOA 实现的 BPM 的四个主要阶段之间的联系的图形表示形式以及关联工具


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14780828/viewspace-584504/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-07-07

  • 博文量
    251
  • 访问量
    299050