本文将介绍如何使用 BPM 实现企业现代化｡还将介绍确保 BPM 取得成功的技术和最佳实践,包括业务流程查询､业务流程分解､业务流程所有权､服务识别和代码模块化｡与其他旧有的现代化方法相比,BPM 能够有效地确定范围;无需大海捞针,便可查看执行具体的业务流程和该流程所需的要素,以及只有现代化该流程才需要的 IT 功能｡随着要实现的流程越来越多,您可重用那些为以前的流程开发的服务,逐步现代化旧有应用程序中的必要要素,使它们与企业的未来密切相关且不可或缺｡BPM 方法能够快速实现价值并吸引业务用户｡

企业运行和维护着大量的遗留代码,比如大型机上的 COBOL 或 System i (iSeries) 上的 Report Program Generator (RPG)｡业务人员需要一种更易使用的环境､更高的性能可视性､更少的手动工作,以及处理异常的更好方式｡与此同时,IT 面临着有关如何处理这些遗留应用程序的艰难决策,这些应用程序通常已存在许多年并支持着关键的核心业务功能｡成套应用程序或者甚至自行组装的应用程序等都在迫使公司离开这些遗留平台｡业务流程管理 (BPM) 是一种可供公司在企业现代化上下文中使用的策略,使他们能够利用遗留应用程序并使遗留应用程序对未来更有用｡本文将介绍如何在企业现代化上下文中使用 BPM｡本文描述了您可用于使旧有投资对您长期的企业架构和策略更有用的技术｡

为什么选择 BPM ?

本节介绍 BPM 是一种实现企业现代化的可行方法的原因｡

遗留应用程序评估

现代化并不容易!我们合作过的许多客户(在 CEO､CFO､CIO 或其他高管的要求下)都要求过外部咨询公司对他们的一个或多个核心业务应用程序进行评估｡出于许多原因,公司通常在一个应用程序产品组合评估中以合理化应用程序产品组合为目标而执行遗留应用程序评估,这些原因包括但不限于:

在新的地区实现增长｡

将业务网络扩展到新的业务合作伙伴｡

不满意的客户｡

操作效率低下｡

缺乏使用技术实现核心应用程序的熟练员工｡

这种详细的评估可能是由一个更加全局性的应用程序产品组合管理方法引起的,旨在突出具有高业务价值和但功能或操作性能低下的应用程序｡评估的核心应用程序的示例可能包括自有的订单管理系统､一个高度自定义的客户关系管理 (CRM) 系统或一个成员管理系统｡在参与这样的研究时,可能会要求公司回答以下一些问题:

核心应用程序是否会满足业务计划的需求?

我们是否应该以核心应用程序为基础?

我们是否会找到一些熟练的开发人员和 IT 操作人员来应用那些用于实现核心应用程序的技术?

这类应用程序评估研究通常包含与关键利益相关者(包括业务和 IT)的访谈､技术审核､针对特定条件进行评估､归档结果和建议､列出关键活动,以及实施建议的路线图和总体估算结果｡评估的输出是一个与公司的核心业务目标一致的建议和总体行动计划｡

然后,公司会基于评估的结果为如何处理核心业务应用程序(比如现代化､退役或扩展)制定决策,并认真考虑行业趋势､避免供应商锁定､解决方案的性能和灵活性等因素｡

使用 BPM 作为构建或购买决策的替代方案

在处理应用程序评估建议时,公司需要就构建还是购买而制定应用程序管理决策｡这些决策受通常由 CIO 设定的 IT 原则推动｡例如,一家公司的应用程序管理原则可能是购买优先,仅在无法购买时才构建｡构建方法提供了最高的灵活性,使应用程序可高度自定义和满足企业的特定需求｡但是,构建需要投入大量时间和金钱｡另一方面,购买通常提供了更快的价值实现速度,需要更低的初始成本,但它不满足业务的所有独特需求｡BPM 缓解这些难题,提供了一种灵活且高效的解决方案｡BPM 利用现有的投资,添加了所需的可视性和灵活性层,为解决方案提供了快速的价值实现速度和更高的总体拥有成本｡

业务和 IT 协作

我们与许多既拥有强大的流程改进团队(有时称为业务流程重组或 BPR),又拥有专注于实现高价值企业服务的 IT 团队的公司打过交道｡流程改进团队偏向于业务,致力于提高核心业务流程的操作效率,通常不会关注 IT 实现｡IT 部门通常拥有一种旨在识别､实现和维护可重用的企业服务的面向服务的架构 (SOA) 策略｡不幸的是,两个群体之间的协作和互动常常不够充分｡这导致出现无法实现的业务流程和未派上用场的昂贵的 IT 职能｡BPM 可缓解这些难题｡BPM 使业务与 IT 之间的协作变得很方便,支持以可执行的业务流程或业务规则的形式实现和实施业务策略,支持开发支持这些业务流程的高价值企业服务｡用户一定要认识到的是,BPM 不是应用程序中的现有业务逻辑的替代品,它提供了一种放大和扩展应用程序应用范围的方法｡

BPM 层

图 1 演示了流程层,它位于业务用户和后端系统之间｡底部的一个后端系统可用作评估主体的核心应用程序(比如 CRM 或 Billing)｡BPM 解决方案使用了这些核心业务应用程序和遗留系统,在这些系统与业务用户之间提供了一个额外的增值层｡

添加流程 (BPM) 层可缓解本文开头描述的许多难题:

自动化业务策略､工作流和决策制定｡

减少错误和提高一致性｡

跨地域或市场标准化过程｡

为团队领导､经理和员工提供可视化和可控化｡

提醒关键事件和发起操作｡

业务流程所有权

尽管 BPM 带来了所有这些承诺,但我们仍然看到如今的许多 BPM 项目都失败了｡研究表明,许多关键问题是本质上的而不是技术性上的,而域组织变更､治理和技能关系更紧密｡具体来讲,业务流程所有权是 BPM 计划最关键的成功因素之一｡多个业务所有者或组织竞争一个共享业务流程中的规则或逻辑,或者协作各方之间缺乏合同约定,这些都可能导致 BPM 失败｡出于这种原因,在深入分析将 BPM 用于企业现代化的细节之前,我们希望回头看看一种缓解业务流程所有权问题的具体技术｡

业务流程分类:隐式和显式业务流程

为了预防域流程所有权相关的问题,有必要将考虑使用的应用程序的功能映射到一个分类框架｡MIT 流程手册 是这类流程分类框架(比如 APQC､SCOR､LEAN 和 EFQM)的一个不错来源｡IBM 的组件业务建模 (Component Business Modeling, CBM) 是这类分类框架的另一个示例｡根据 APQC 网站上的描述,APQC 的 Process Classification Framework “组织为 12 个不同的类别,包括 5 个操作区域类别和 7 个支持区域类别｡每个类别包含一组流程和活动,这些流程和活动从整体上表示一个组织的操作｡这些框架可跨行业使用,可选择特定于行业的格式｡”

Process Classification Framework 允许将一个业务分解为第 1 层:类别,第 2 层:流程组,第 3 层:流程,第 4 层:活动｡图 2 是一种端到端销售的 APQC Process Classification Framework 分解图｡例如:

8(类别):管理财务资源

8.2(流程组):执行收入核算

8.2.2(流程):向客户开具发票

在架构级别上,用户可能会混淆业务流程希望管理和监视的 隐式 端到端业务流程(比如 Order to Cash)和 显式 的细粒度模块化业务流程(比如 Service Provisioning 和 Billing)｡隐式端到端业务流程是业务流程监视模型的基础｡它们提供了域业务流程使用者相关的视图,例如,作为客户,您可能希望了解您的订单状态｡但是,因为它们贯穿于多个业务领域,所以为这些隐式流程分配一个业务所有者是不切实际的｡但是,显式业务流程通常可归入单个业务领域内,该领域自然就成为了它们的业务所有者(比如 Billing)｡基于现场经验,作者提供一种方法,在这种方法中,仅有显式业务流程会成为流程自动化和执行的目标｡作者将隐式流程映射到 BPMN 的公共流程,将显式业务流程映射到 BPMN 的私有流程｡您需要为每个私有流程确定业务所有者｡请注意,在上面的流程分类框架中,私有(显式)流程位于分解图的第 3 层,例如 Invoice Customer｡

灵活的企业会将他们的流程或流程组的操作委托给管理这些流程的业务所有者｡出于这种原因,业务敏捷性需要区分一个业务所有者控制的领域与作为不同所有者之间的服务合同的总体企业流｡图 3 描绘了位于一个客户销售端到端公共流程中第 3 层的 APQC 流程｡根据组织决策,分解图的第 2 层的 3.5 Develop and Manage Sales Plans 只有一个所有者,或者 3.5.2 Manage Customers and Accounts 和 3.5.3 Manage Customer Sales 具有不同的所有者｡在第一种情况下,可在该组中所有流程之间执行由一个 BPM 引擎驱动的正式 BPM 自动化,而第二种情况暗示着第 3 层的流程可以自动化,但与服务或事件交互｡

如图 3 所示,此最佳实践会导致流程层被分为两层:

显式流程层 是现有的遗留应用程序的一个扩展｡

在显式流程层之上有一个 隐式流程层,它仅用于监视用途｡

尽管显式流程层会从其自动化模型自动监视,但隐式流程层需要一个监视模型,以及将反映显式流程和应用程序链的总体视图的探测器和事件的定义｡

BPM 实现

本节将介绍 BPM 实现的最佳实践｡

业务流程查询

与其他旧有的现代化方法相比,BPM 允许有效地设定范围;无需大海捞针,便可一次查看执行一个业务流程和该业务流程所需的要素｡业务流程查询关乎理解目标业务(所选的核心应用程序)当前的运营情况(“现状” 状态),更重要的是,理解业务在未来应如何运营(“目标” 状态)｡考虑因素包括:

每个任务为流程增加了(或未增加)多少价值｡

完成每个任务花了多长时间｡

花了多少成本｡

往返传输了哪些信息(包括纸张文档和传真等)｡

谁参与了业务流程(角色)｡

参与者使用了哪些信息渠道(例如电子邮件､电话呼叫和 Web 门户等)｡

哪些后端系统(应用程序)支持该业务流程｡注意:依赖于业务流程,除目标核心业务应用程序外,可能有必要访问其他信息｡例如,可能有必要访问结算系统和客户投诉管理系统｡

为了理解现状流程,作者会要求业务用户(例如呼叫中心团队领导､客户服务代表)描述他们执行每日任务的方式,包括他们如何与被现代化的核心应用程序进行交互｡可以使用建模来理解和记录业务流程(同时包括现状和目标状态)｡建模工具应是用户友好的产品(资源占用少､配置需求极低,并针对非 IT 的业务用户而设计),同时还提供了所需的建模功能｡IBM Blueworks Live(如图 4 所示)或 IBM Business Process Manager 的 Process Designer 是功能全面的建模工具,提供了行业标准的结构,比如业务流程建模表示法 (BPMN)｡此功能对于支持成熟的模型驱动开发 (MDD) 方法至关重要｡这些工具使业务和技术用户均可设计和构建流程模型,这些模型可分析､优化和直接转换为实现代码｡

BPM 的一个云交付模型(比如 Blueworks Live)是最理想的｡利用公共云可消除对评估组织的 IT 部门的依赖性,该部门对软件的采购或部署有发言权;惟一需要的最终用户软件是 Web 浏览器,它通常已安装在用户的个人计算机或笔记本电脑上｡

实现显式和隐式业务流程

用于实现在 BPM 系统(比如 IBM Business Process Manager)上执行的显式业务流程的技术不属于本文的介绍范畴｡目前的最佳实践包括快速实现价值､业务用户参与和迭代式开发｡在本文中,我们的目标是将这些 BPM 技术与企业现代化相关联｡有关 BPM 方法的更多信息,请参阅 参考资料｡在企业现代化上下文中,BPM 的另一个成功因素是数据建模｡BPM(和业务规则)使用的数据模型称为业务对象模型或 BOM｡一定要理解 BOM 与其他数据模型之间的关系,不过这是另一篇文章的主题｡在未来的文章中,我们将介绍一种从显式业务流程执行中监视隐式业务流程的技术｡

探查事件的遗留性

您也可将数据事件与业务流程和数据同步解决方案相链接｡经典的事件发布为以下场景提供了有效的更改数据发布环境:

提供应用程序到应用程序集成,这使将操作性客户数据推送到一个套装的客户关系管理 (CRM) 应用程序成为可能｡

启动业务流程,例如增加一个客户记录会启动一封欢迎电子邮件､一次信用验证和对 CRM 系统的更新｡

监视关键数据事件,比如促使一个业务流程重新进货的低库存水平｡

例如,IBM InfoSphere Classic Data Event Publisher for z/OS 捕获非关系数据库中的数据更改,将更改封装为一种一致的关系格式,并将更改作为自述性消息发布到 WebSphere MQ 消息队列或平面文件,包括从 VSAM 和 CICS® VSAM 文件､IMS､ADABAS 或 CA-IDMS 发布事件｡此外,WebSphere Operational Decision Management 提供了一个完整的业务事件处理 (BEP) 平台,它与 IBM 的 Business Process Manager 进行了紧密集成｡

然后,消费应用程序(在我们的示例中为 BPM 系统)可通过显式流程或隐式监视来使用数据事件,促进后续处理以及与流程层的集成｡这种松散的集成有助于确保每个应用程序可独立于其他应用程序进行更改｡

服务识别

业务流程查询 (BPD) 和业务流程分类是一种自上而下的方法,首先从总体上理解业务流程,然后逐渐下钻到业务流程细节｡显式(自动化)业务流程通常位于业务流程分解图的第 3 层｡如面向服务的建模和架构 (SOMA) 中所述,我们通常在下一层(第 4 层)以恰当的粒度识别可重用的业务功能(也就是服务操作)｡示例服务操作包括:getPastDueOrders､validateAddress 或 upateCustomerInfo｡请注意,拥有这些服务和它们的操作的正确粒度对重用非常重要｡粗粒度的服务提供了高业务价值,但重用的机会很少;细粒度的服务提供了较少的业务价值,但重用的机会更多｡请注意,因为这些服务是从业务流程分解图中识别的,所以它们会自动与业务保持一致(它们提供了业务价值)｡识别这些服务后,您需要查看被现代化的核心应用程序如何提供服务的必要功能或实现｡这是由下而上的方面｡

代码现代化

现在回到 RPG 或 COBOL 代码,您需要确保遗留代码可在现代 BPM 解决方案中使用｡这一需求的最常见挑战是缺乏模块化或 “意大利面条式代码” 效果,其中相同的代码片段(比如一个子例程)包含业务､流程､数据和表示 (UI) 逻辑｡在现代解决方案中,我们希望流程逻辑位于业务流程层中并由 BPM 系统管理,该系统不在遗留应用程序中｡另外,流程逻辑常常包含人机交互步骤,用户必须按照特定顺序填写表格｡在这种情况下,流程层可包含屏幕流逻辑(屏幕的顺序和实际屏幕)｡我们真正需要的是这样一个代码片段,它仅执行流程或业务逻辑需要的操作,例如 validateAddress｡

为了实现此目的,我们需要模块化遗留代码(COBOL 或 RPG)｡这通常在过去的开发人员习惯使用的工具(比如 Rational® Developer for z､IBM U2 for Universe)中完成｡它需要全面的回归测试,以确保对代码的模块化不会破坏应用程序｡这需要投入时间和资源,但是,一旦将代码模块化之后,它就会推动未来的成功｡同一个遗留代码片段然后可供 BPM 和其他企业计划使用,比如 SOA 和主数据管理｡另外,我们还发现,识别的服务可供其他针对实现而优化的流程快速使用｡拥有模块化的代码后,您就有多种选项将它添加到现代 BPM 解决方案中｡3 个最常见的选项是 Web 服务支持､使用 ESB 和适配器或业务规则提取｡

Web 服务支持

Web 服务支持包括获取遗留的 COBOL 或 RPG 代码业务逻辑函数(比如 validateAddress),将它封装为 Web 服务｡此操作可以使用一个向导来完成｡在幕后,该向导围绕 COBOL 或 RPG 创建一个 Java™ 包装器,然后围绕该 Java 包装器创建一个 Web 服务包装器｡例如,使用 Rational Developer for i,您可使用一个向导从 ILE RPG 或 COBOL 源代码或从 Program Call Markup Language (PCML) 文件创建 Web 服务｡使用此方法,业务逻辑代码仍在遗留平台上运行,业务流程逻辑以及一些用户界面逻辑(屏幕流)现在位于 BPM 系统上｡

企业服务总线和适配器

一种用于将 BPM 层连接到后端遗留系统的常见架构模式是,使用一个企业服务总线 (ESB),可能还使用一个特定于平台的适配器｡例如,WebSphere Adapter for IBM i 基于 Java Connector Architecture (JCA),支持在现代应用程序与遗留系统之间执行入站和出站集成｡适配器使用了 Java 调用,可发现 IBM i 服务器上的对象｡当数据转换或路由需求占主导地位时,这种模式很有用｡它为连接策略提供了牢固的基础｡但是,它不需要使用新技能在 ESB 工具中编写仲裁,例如,在使用 WebSphere ESB 时,要使用 WebSphere Integration Developer 来开发仲裁｡

业务规则提取

业务规则提取包含挖掘业务逻辑(规则和策略)的遗留代码,从遗留的 COBOL 或 RPG 提取这些逻辑,在一个业务规则管理系统 (BRMS) 中创作和管理它们｡这么做的常见优势包括:

业务用户可以理解业务规则｡(注意: 这适用于 IBM WebSphere Operational Decision Management(新的 ILOG jRules),但业务用户可能很难理解非 IBM 平台上的规则｡)规则不再在 RPG 或 COBOL 中编码,而是以一种伪英语(或法语)语言或决策表的形式编写｡

业务用户能够更快更轻松地在传统软件开发生命周期 (SDLC) 周期外更改业务规则的一些参数(比如驾驶员的年龄)｡

更容易在其他应用程序的上下文中重用业务规则｡

遗留现代化上下文中的业务规则的一种常见架构模式包含支持业务规则的 Web 服务,因此使业务规则成为了企业决策服务｡在使用此方法时,业务逻辑不再在遗留平台运行｡相反,它在 BRMS(比如 WebSphere Operational Decision Management､IBM 的 BRMS)上运行和管理｡

遗留应用程序与业务流程层之间的集成

在将来自遗留应用程序的业务逻辑实现为服务(启用了 Web 服务的 COBOL 代码或决策服务)并且实现了业务流程或业务规则之后,最后要解决的问题是如何将核心应用程序与 BPM 系统集成｡(本文未涵盖用于实现业务流程或规则的技术｡请参阅 参考资料 一节获取此主题的链接｡)换句话说,遗留应用程序如何与显式或流程层进行通信?这需要核心应用程序触发一个业务规则或启动一个流程实例(比如启动一次欺诈审核)｡遗留应用程序与流程交互的两种常见的技术是 Web 服务调用(同步)或消息队列(异步)｡例如,使用库或工具包,可以生成用于 RPG 或 COBOL 应用程序中的 Web 服务客户端存根,进而允许遗留应用程序调用业务规则或启动流程实例｡(IBM Business Process Manager 提供了一个 Web 服务来启动流程实例)｡另一项技术可供遗留应用程序用于将消息发布到推列上｡然后 BPM 系统会处理这些消息,启动流程实例｡(IBM Business Process Manager 通过 JMS 或 WebSphere MQ 完成此任务｡)

现在业务流程层可通过调用 Web 服务(针对启用了 Web 服务的函数或决策服务)与核心应用程序进行交互｡例如,作为订单管理流程的一部分,该流程会调用 verifyAddress 服务｡

结束语

在本文中,作者介绍了 BPM 如何实现遗留应用程序评估和企业现代化｡BPM 允许 IT 部门解决各种业务需求,比如为最终用户提供一个更容易使用的环境､可视化过程和性能､更多地控制业务成果､减少手动工作或更快地响应异常｡作者探讨了确保 BPM 取得成功的技术和最佳实践,其中包括业务流程查询､业务流程分解､业务流程所有权､服务识别或代码模块化｡与其他遗留现代化方法相比,BPM 能够实现有效的范围划分;无需大海捞针,便可查看执行一个具体的业务流程和该流程所需的要素,以及只有现代化该流程才需要的 IT 功能｡随着您要实现的流程越来越多,您可以重用那些为以前的流程开发的服务,逐步现代化遗留应用程序中所有必需的要素,使与对企业的未来密切相关且不可或缺｡BPM 方法提供了快速的价值实现速度并吸引着业务用户｡这是对以 IT 为中心的遗留现代化工作的一项广受欢迎的革新!