简介
在瞬息变幻的商业环境中，作出反应的速度往往决定着企业的成败。由业务流程管理（business process management，BPM）、业务规则系统再加上对最近的商业智能的访问所构成的解决方案使得这种快速响应成为可能。本文是一个系列中的首篇文章，该系列将通过几个场景来探讨通过集成 BPM、业务规则和商业智能来创建灵活、动态和快速响应的解决方案。
成为一个随需应变的企业
当今的企业正面临着许多的压力 —— 既有在节奏很快、瞬息变幻的环境中参与竞争的压力，也有不断降低成本以保持竞争力的压力。成为随需应变（On Demand）的企业意味着为您的企业在这种困难的环境下取得成功作好准备。
下面是成为随需应变的企业所涉暗募父龇矫妗?
● 首先，需要创建一个快速响应的环境，以便对市场上的任何变化作出快速反应，而不管这种变化是内部的还是外部的，是计划内的还是未能预料的，是威胁还是机遇。
● 其次，企业应该采用灵活多变的成本结构来管理成本，以跟上企业的发展或需求的增长。
● 再次，企业需要将注意力放在有利可图的、对企业的成功有着核心作用的事务上。
● 最后，企业需要一个有弹性的、健壮的基础设施，并且是全球 24 小时可用的。
但问题是，如何创建快速响应环境呢？为了回答这个问题，让我们看看 International Foods Market (IFM) 这家虚构的公司以及该公司所面临的挑战。作为一家典型的大型零售商，他们要出售来自数百个供应商的数千种产品。为了获得成功，他们必须小心翼翼地管理存货、价格控制（markup）、劳务支出以及其他方面。他们需要对竞争对手所带来的任何挑战快速地作出响应，需要提高客户服务质量，快速地将新产品送到商店，以及快速地采用新的政府及行业标准。
Christina White 是这家公司的 CIO，她正面临着一个很大的挑战。她如何创建一个能够更好地对这些挑战作出响应的 IT 系统？让我们看看她的公司在过去通常是怎样处理变化的。首先从公司传达下来一个需求，Christina 将这一需求分派给某个项目小组，后者将评估该需求的大小并安排开发进程，这里所谓的开发实际上就是对遗留系统的更改。这些遗留系统都是很大的单块程序，因此一旦出现新的需求，通常需要花费数月甚至数年的时间来实现。图1（单块应用程序）对此作了解释。
在最近的一次 CIO 会议上，Christina 听说了业务流程管理技术的诸多好处，并了解到将业务流程从应用程序逻辑中分离出来可以创建出非常灵活的快速响应结构，当公司的业务流程发生变化时，这种结构非常容易修改或扩展。她决定让她的一个架构师 Greg Thomas 来研究这项技术。Greg 经过深入研究发现，将业务流程从应用程序逻辑中移出到一个 BPM 引擎中可以带来巨大的利益，而且，业务规则引擎还提供了将公司的策略移入到一个易于控制的组件中的能力。Christina 希望能够轻松地访问公司策略以及关键业务流程，这样他们就可以很容易地修改这些策略和业务流程，以响应新的需求。
Greg 还提到，在业务流程和规则环境的上下文环境中，最近完成的作为公司 CRM 计划的一部分的数据仓库部署是商业智能（BI）极好的数据源。在过去，他们就已经看到了对能获得更多提升空间以及更灵活的定价解决方案的需求，这些都可以从对 BI 数据的访问中获益。他们决定将数据仓库整合到这些新环境中。
从图2（灵活的 BPM 应用程序架构）可以看出，不管是新应用程序还是已有的应用程序，都有业务逻辑的身影出现，但是通过使用像 WebSphere® Business Integration 这样的业务流程管理工具（Business Process Manager）来实现业务流程时，为新的应用程序引入了灵活性。同样，业务策略是在一个业务规则引擎（Business Rules Engine）中实现的。这种新的架构为 IT 环境带来了一些好处。
● 首先，通过有意识地将策略与流程从逻辑中分离出来，迫使企业清楚地思考他们的流程和策略到底是什么，这些流程和策略应该是怎样的。
● 其次，这些技术所提供的丰富的工具使得企业可以很容易地快速而又有建设性地更改流程或策略（记住随需应变目标中的“灵活多变”）。
业务流程管理
电子表格（spreadsheet）是用于更改数据的工具。当第一种电子表格Microsoft Excel、Lotus 123 问世之前，大多数人还是通过计算器手工地分析数据的。还记得反波兰（reverse polish）逻辑吗？使用计算器只能做那么多的分析，而当出现了电子表格的时候，突然间每个人都再也不会为各种各样的计算而睡不好觉了。这一变化彻底改变了我们看待数据的方式。
业务流程管理也一样。它不仅仅是用来运行业务流程的一种技术，它还是应付改变的工具，是改进流程的工具。BPM 技术允许企业系统地理解、分析、改进和实现他们的业务流程。BPM 是通过信息技术改善企业运作的一种革命性的方法。
| BPM 有很多好处： |
●
● 它允许人们组织他们的业务流程并可见地观察这些流程。
● 它促进了业务流程的形式化，而在此之前业务流程并没有被编制文档，有时候也只是有一些特殊文档。
● 在一致性对公司有好处的情况下，它可以提供建立行为一致性的工具，而对于不需要一致性的情况，它也提供了相应的灵活性。
● 它允许人们建模、模拟和分析业务流程，这样他们就可以创建出最能体现他们目标的业务流程。
● 它可以作为加快实现流程更改的一种方式。正如 Fingar 和 Smith 在他们编写的 BPM the Third Wave 一书中所提到的 “BPM 并没有加快应用程序的开发，只是消除了对应用程序的需求。 ” 注 1
● 它允许企业将注意力放在 “ 核心 ” 流程上，甚至以服务的形式将这些流程提供给贸易伙伴。
什么是业务流程？
业务流程是指企业中的某种活动，这种活动具有有限的开始，一组中间活动，并且有最终的结果。流程有其利益相关的几方，叫做风险承担者（stakeholder），他们将从流程中获益，或者参与到流程中。并不是所有的企业运作都是业务流程。例如，雇用一个新雇员属于一个业务流程，而该雇员打卡上班就不算是业务流程了。
所有业务流程通常都有一些共同的特征。业务流程比较大、复杂、动态、分布在企业的多个不同部分、持续运行时间很长，并且要么是人机交互的，要么是自动的。业务流程用于充当 IT 与业务环境之间的桥梁和纽带，要求工具和技术不管对于业务人员还是技术人员来说都是有用的。
什么是 WebSphere Business Integration？
WebSphere Business Integration（WBI）提供了一套功能组件，这些功能组件为企业提供了集成的消息发送机制、集成代理程序（integration broker）以及业务流程管理解决方案。在 WBI 中有两种可用的业务流程管理技术。WebSphere InterChange Server（前身是 CrossWorlds）提供了流程自动化功能，可以将多个离散的业务应用程序当作一个应用程序来管理。而 WebSphere MQ Workflow 支持长时间运行的业务流程工作流，运行期间这些业务流程可以与系统和人进行交互。
Complimenting WebSphere InterChange Server 和 WebSphere MQ Workflow 是一套用于建模和监控业务流程的工具。WebSphere Business Integration Modeler 提供了设计、测试复杂业务流程以及在复杂业务流程间通信的工具。WebSphere Business Integration Monitor 可以显示来自各种不同环境的实时信息，以允许对决定性的流程性能进行管理和优化。
IFM 里的 BPM
让我们回到 International Foods Market 公司。作为他们第一个 BPM 项目的一部分，一个小组的技术人员和业务人员开始使用 WBI/Modeler 工具记录他们公司当前的一些业务流程。这种工具帮助他们捕捉“AS IS”流程的每一步细节。他们发现一些有趣的事情，以前他们并没有想到这些事情会在他们公司发生：
● 他们的一个遗留系统的功能性实际上并不完全符合这些雇员用于完成工作的实际方式，因此这些雇员在流程中要手动地完成一些步骤。
● 用于决定产品价格的那些步骤是嵌入在他们很久以前购买的一个打包的应用程序中的，没有人真正知道该如何更改这些用于决定标价提高的规则。最初开发这个系统规范说明的人早已退休了。
Christina 认为定价问题非常适合作为他们第一次实施这种技术时所处理的问题。定价问题在 IFM 的业
务中实在太重要了，不应该任其留在一个没有人能够掌握的应用程序中。
业务规则引擎
在传统的应用程序结构中，业务规则是包含在应用程序内的业务逻辑中的。每当需要更改规则的时候，这种嵌入了规则的应用程序都需要修改应用程序代码。这就加大了定制和扩展的难度。而通过将业务规则从应用程序中移出可以使分析员能够描述独立于应用程序逻辑的处理规则。
这样就使企业具有对以下方面的变化作出响应的适应性：
● 公司策略
● 政府法规
● 客户状态
● 合同条款 & 条件
● 新的业务模型
业务规则必须将易变化的业务逻辑成块地封装起来。要使用规则引擎获得成功的关键之一是小心地标识出那些“高度易变”的逻辑块。可以将这些逻辑块暴露成规则，以便通过业务规则引擎工具方便地进行修改。规则引擎为以后的绑定提供了方便，因为在以后的绑定中，从业务逻辑到业务规则的特定联接（linkage）不是在实现时定义的，也不是在部署时定义的，而是在运行的时候临时决定的。这样就带来了最大的灵活性。
业务规则将公司策略从应用程序中分离出来，同样，业务流程管理工具为将公司的业务流程从应用程序逻辑分离出来提供了方便。通过使用一种基于组件的应用程序构造模型，加上业务流程管理工具和规则引擎，可以提供最大的灵活性和适应性。
一些处于领先地位的独立软件供应商，包括 Ultimus、Versata、ilog 和 Blaze 都提供了规则引擎系统，在 WebSphere 的 BRBeans 技术中也提供了规则引擎系统。虽然他们提供的规则引擎系统在功能和函数上各不相同，但是都提供了一些相同的功能上的好处：
● 在可变性情况下业务策略或规则的客观化，这种情况下要将业务规则标注（call-outs）插入应用程序代码或业务流程流中。
● 用于以一种直观的方式表达规则的语言。
● 用于运行规则的执行环境。
● 允许用户创建和修改业务规则的工具。
值得注意的是，存在不同类型的规则引擎，在决定如何应用一种工具之前理解这种工具的用途是极其重要的。当您跨业务规则领域进行调查研究时，您将注意到这些工具可以分为以下几类：
● 简单业务规则（simple business rule） —— 通过一张简化的、直观的词汇表来表达并且是在应用程序或业务流程的可变性情况下调用的一种业务规则。这种规则引擎的一个很好的例子就是 ilog、Blaze 和 IBM 的 BRBeans。
● 人工智能规则（artificial intelligence rule） —— 管理 AI 和数据挖掘（Data Mining）产品中算法行为的规则。这种类型的规则引擎的一个例子就是 DB2® Intelligent Miner™ 产品。
● 事件相关规则（event correlation rule） —— 在事件相关性中用到的规则，用于将一套各自独立的事件聚合成一种聚合的（aggregated）有意义的形态。这种类型的规则的一个很好的例子就是 Tivoli® Event Console 系统管理产品。
● 数据为中心的规则（data-centric rule) —— 这些是约束对数据的检索和更新的规则。这些约束控制着如何转换数据以及谁可以访问数据，并通过加强语法、语义和上下文保留了数据的完整性。这种规则引擎的一个很好的例子就是 Versata。
● 转换和验证规则（transformation & validation rules） —— 这些是应用集成或信息集成场景中定义对数据的修改的规则。这些规则定义数据是如何修改、净化或验证的。提供了这种规则的产品包括 WebSphere Business Integration 和 DB2 Warehouse Manager。
商业智能
顾名思义，商业智能描述的是用于从混乱的公司信息中创建出智能知识的一套技术。一家中型企业在一个较短时期内累积下来的信息量可以达到 1000 GB（terabyte）这样的级数。如果不能深入理解这些数据所传达的信息，企业就不能在市场中获胜。这一点可以从引用一本最近出版的书的一段话中看出：
| “知识驱动着企业的竞争。要在市场中获胜，就需要企业知识 —— 即关于客户、产品和流程的知识。只有这样，才能调整好您的企业，使之在市场中表现出色。”注2 |
在深入研究商业智能如何与业务流程管理发生联系之前，让我们先花少量时间讨论一下商业智能系统是怎样的。商业智能解决方案的基石是数据仓库，数据仓库是一个储存库，存储着每一件有意义事件的历史记录以及过去所发生过的事件的记录。围绕在数据仓库周围的是一些组件，这些组件有助于发现、分析和报告仓库中的数据。让我们看看这些组件：
数据源（data source） —— 数据仓库生态系统（ecosystem）始于使企业运转的操作性系统（operational system）和操作性数据库（operational database）。来自各种不同系统的数据提供了许多的信息片断，我们必须将这些信息片断拼在一起，创建出关于企业运作的完整历史记录。这些数据源可以包括遗留系统、打包的软件应用程序、ERP 系统，以及关系数据库甚至是非关系数据库。
抽取（extract）、转换（transformation）和装载（load）（ETL） —— 所有公司都有多种不同的企业应用程序，这些应用程序在数据的语法和语义上大相径庭。当将来自这些数据源的数据集中起来装载到数据仓库中的时候，需解决这些数据的不一致问题。这种将来自完全不同的系统的数据装入到数据仓库中的过程就叫做 ETL 过程。在这个过程中，要按照某种计划好的时间间隔将数据从各个不同的数据源中抽取出来，转换成一种经过协商的模式，最后装载到数据仓库中。对于那些已经被用户输入或应用程序错误破坏了的数据，常常还需要一个净化过程。
Staging 表 —— 这些表被用作操作性环境和数据仓库之间的中间表。由于这些表允许 ETL 过程与对数据仓库中完全历史记录的协调更新在时间上各自独立，因而允许对数据仓库中的数据采取适当的更新次序。
数据仓库 —— 业务数据仓库（business data warehouse，BDW）是历史信息的中央仓库。它是关于企业运作的完整历史记录。如果某个事件或数据值没有被捕捉到这个仓库中，那么它将永远丢失，从而妨碍了将来某些分析活动中对数据片断的整合。这正是设计数据仓库来存放企业运作的完整历史记录如此重要的原因。虽然大多数数据仓库是建立在 RDBMS 之上的，但是它们的结构还是稍微有别于传统的企业运作关系数据库。数据仓库具有一种星型模式（star schema），目的是启用分析历史数据时使用的特定的“what if” 查询。星型模式由一个中央事实表（central fact table）及其周围的一些维组成，中央事实表包含一些业务度量（business measure），而这些维则提供了灵活性。典型的维包括产品、客户、地区、公司或组织，当然还有时间。
商业智能与 BPM
那么，商业智能为业务流程管理带来了什么用处呢？显然，好处非常多。我们在前面就已提到，在业务流程中实现的企业决策需要建立在对关于公司运作、竞争对手和客户方面的智能的最佳洞察力的基础之上。商业智能并不只是用于创建报告的，它还应该是能付诸实施的，能够促进业务流程的改进。
增加 IT 中“I”的分量
IT 中的“I”是否仅仅意味着这种技术向用户开放了数据的消防站，又或者它还有意提供一些更高程度的智能呢？Fingar 和 Smith 在 BPM the Third Wave 一书中认为，信息应该加强流程的变化：
| “现实是，至今计算机还只是用户保存记录的机器，而不是用于管理的机器。计算机可以吞进和吐出数百万兆字节的数据，但是在实时的各个层次的自动化的或者人为的决策制定过程中，管理洞察力、在上下文环境中所需的能付诸实施的信息又在哪里呢？”注3 |
一个企业中的信息生态系统应该从企业运作流经数据仓库，转换成能付诸实施的知识，这些知识再流回到操作性环境中，以实现改进的业务流程。这通常被称为闭环（closed-loop）的商业智能，因为整个流程改进周期是通过将分析的结果集成回到企业运作来完成的。
IFM 中闭环的商业智能
回到 International Foods Market 公司，记住动态定价正是他们要处理的一个场景。Christina 和 Greg 与一些最能理解定价问题的关键业务人员碰了头。他们开始一起来定义用于设置和更改价格的业务流程以及用于判断价格应该怎样的业务规则。在创建业务规则的过程中，他们注意到需要将 利润（profit） 包括进来，作为定价公式中的一个元素。
当他们开始思考这个问题时,事情并没有他们开始想像的那么简单。任何一种产品的利润都波动很大，因为从供应商购买产品的成本（所卖商品的成本）、运输费用、用于存放这些产品的仓库或货架，以及将产品存放到商店里的劳务支出都是不定的。Greg 确定了用于解决这个问题的一些备选方案：
● 他们可以对所有产品的利润采用一个固定的值。
● 他们可以创建一个静态的利润表，表中存有每种产品的利润，这些利润是以当前的商业智能报告为基础的。
● 他们可以通过某种从 BPM 环境到数据仓库的联接获得对数据仓库中利润值的实时访问。
Christina 和 Greg 一致认为实时访问数据仓库中最近计算出的利润这种方案比较理想。这正是成为一个随需应变的企业的好例子，使得 IFM 对销售额、存货和供应链的变化具有极好的响应能力。在本系列以后的一些文章中，我们还将回过头来讨论这种集成是如何完成的。
业务活动监控
关于 BI+BPM 的技术还有一个最热门的领域，如果没有述及这一领域，我们就还不算完成了对商业智能与业务流程管理的集成的讨论。这一领域就是业务活动监控。
业务活动监控（business activity monitoring，BAM）这个术语是在两年前由 Gartner Group 提出的，用于描述一些新兴的能力，这些能力将一些关键技术集中起来，从根本上改变业务系统的状况。BAM 强调业务改进中的一些关键概念，这些概念足以捕获到整个业内的 CxOs 的实质：
● 业务流程管理革命性地改变了管理企业运作的方式。
● 业务流程是由能付诸实施的智能驱使的。
● 业务流程可以通过分析在业务流程执行期间捕捉到的一些关键度量来得到改进。
● 企业并不希望简单地不断吐出数千页的商业智能报告。他们希望商业智能系统对一些关键绩效指标（key performance indicator，KPI）作出报告，这些关键绩效指标能够揭示出运作成功的几个决定性方面。这导致了一门名为企业绩效管理（enterprise performance management）的新学科的诞生，该学科将焦点放在根据这些 KPI 计算、报告、分析和控制业务上。
● 应该存在一个零延迟环境（zero latency environment），这种环境可以在实际情况下将业务事件转换成业务流程和企业运作能够利用的能付诸实施的知识。
BAM 可以用业务活动监控的“五个 R” 来解释。这五个“R”是：
● 识别（Recognition）
● 响应（Response）
● 解析（Resolution）
● 审核（Review）函数
● 交付 ROI
为了与能付诸实施的商业智能这一思想合拍，BAM 解决方案应该能够识别在该环境中正在发生的事情，解释这种信息的意义，并决定对此做些什么。事件每时每刻都可能发生。人们常说，大多数人最多可以同时处理 7 件事。对于这个瞬息变幻的世界中的很多经理来说，每天早上 8:15 这一限制便已触底了。这就是为什么自动检测重大业务事件如此至关重要的原因了。
要识别重大事件需采用一些高级的分析方法和业务规则系统，这些分析方法和业务规则系统应该能够在其他事件和过去的企业运作历史的上下文环境中解释事件。偶尔被蜜蜂刺一下或许很恼人，但是未必有害，除非你过敏。然而，当您接二连三地被蜜蜂刺到时，问题就突出了。同样，任何业务事件本身来说并不是十分重大，但是当它与其他事件混在一起时，便会显得重大起来。
BAM 是商业智能和业务流程管理的一个会合点（convergence），下面这段引自 IntelligentEnterprise 杂志中一篇最新文章的话对此作了阐述：？”注4[/QUOTE]
| “BAM 是关于流程自动化和工作流管理的呢，还是关于商业智能和绩效管理的呢？您可以说 BAM 是业务流程管理中的后面的一层，或者是任何公司绩效管理系统中的一个关键组件。实际上，两者都是。它可以帮助优化业务流程，并最终提高您对操作性（operational）和策略性（strategic）绩效的理解。” |
IFM 业务场景
现在让我们简单介绍一下 IFM 公司中的三个场景，在后面的文章中我们将对这些场景加以讨论。这些场景演示了将业务流程管理、业务规则以及商业智能集成到一起以创建一个快速响应的、动态的随需应变环境的价值所在。
场景一：动态定价
Christina 需要用一个新的灵活定价模型替代 IFM 的遗留定价应用程序，这种新的定价模型考虑了关键的供应链、销售额以及客户信息。业务人员希望具有根据市场行情更改定价规则的能力。他们需要根据产品类型、客户反馈和竞争压力的特征来采用不同的定价模型。他们不能判断在定价活动或定价规则中所需使用的所有因子是哪些，但是他们希望能够添加新的因子或轻松地更改定价规则。
在以下条件下，业务人员希望能够作出反应：
● 在运输费用或所卖商品的成本方面发生了变化
● 在存货方面有了重大变化
● 来自竞争对手的压力减弱
● 对产品需求的季节性影响
Greg 认识到，要创造出业务人员希望拥有的这种灵活性，业务流程管理是理想的解决方案。当对定价流程有了新的需求时，他们可以通过使用 WBI 流程设计工具快速地更改流程流。应用不同定价方程式的需求可以通过开发一种业务规则引擎来得到满足，这种业务规则引擎将被集成到定价业务流程中。
这个场景是前瞻式（proactive）业务模型的一个例子，在这个场景中，IFM 将注意力放在根据市场行情对他们的产品进行定价这一问题上，而不管随后会出现什么问题。这一场景允许 IFM 预测价格上的波动并据此相应地设置价格。
在本系列的下一篇文章中，我们将看看关于如何将 WBI Interchange Server 中的业务流程与业务规则引擎相集成的细节，以支持这第一个场景。
场景二：将商业智能集成到 BPM 中
在场景一中，对定价业务流程的一个需求是允许访问历史信息和业务流程中的分析结果，以提供一个当前的利润值，这个利润值表明了数据仓库中当前报告的 IFM 的实际利润。这样就为业务流程带来了实时性，从而使得 IFM 能够对某个特定产品或产品类在利润上的波动快速地作出反应。
将商业智能集成到业务流程中有些困难。首先，要得到利润值，需要考虑很多方面。他们希望使用上个月按地区计算出来的产品平均利润，还是上个季度全公司按类别计算的产品平均利润，又或者是上个月某商店的产品平均利润呢？这种集成解决方案需要解决这种对灵活性的需求。
第二个问题是对多维立方体中计算出的值的处理，这也是需求中的一部分。在 WBI Interchange Server 中通过 RDBMS 连接器可以轻松地访问到普通（flat）关系表，但是对于驻留在数据仓库中的多维数据，是否能够访问得到呢？在本系列的第三篇文章中，我们将讨论用于提供对操作性业务流程环境中的数据仓库信息的访问的技术。
场景三：感知（sense） & 响应（respond）
管理层对新的前瞻式定价业务流程的反馈使 Christina 欣喜不已。最近，她应邀参加了高级管理层会议，由于新的业务流程对公司的销售额和利润产生了积极的影响，会上她受到了表扬。然而，大家对于这种新解决方案的热情也更凸现了 IT 小组所面临的更多挑战。管理小组已经注意到，在商店和供应链中还存在一些未能检测到的情况。如果能够检测到这些情况，那么就可以启动这个定价业务流程来对问题作出反应了。
这个反应流程将监控各种不同的业务度量，这些度量可以表明在某种特定产品的销售上是否存在问题。由于有上千家商店，每家商店又销售 10,000 多种不同类型的产品，因此 IFM 公司单方面很难监控某种特定的产品在销售和存货方面所有可能出现的偏差。以下情况可以作为出现了问题的症状：
● 可能将销售额拱手让给竞争对手
● 供应链可能有问题（产品未能运输到位或运输了太多的产品）
● 对于某种特定产品的需求可能有所缩减
IFM 将开始监控数据仓库中的信息，以检测这些情况，然后要么通知某个特定的雇员采取行动，要么在供应链上启动一个能够更改价格、发起促销活动或者订立订单的业务流程。在本系列的第四篇文章中，我们将谈到如何在数据仓库之上创建监控器，以便检测在产品销售和存货上的偏差。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
