第 1 篇文章中，我们介绍了随需应变业务、业务流程管理（BPM）、业务规则引擎和商业智能的总体概念。第 2 篇文章中，我们演示了业务规则引擎如何服务于具体化业务流程管理器的策略。第 3 篇文章中，我们详细讨论了如何使智能数据对业务流程可见。而在这本系列的最后一篇文章中，我们将讨论如何将分析方法与 BPM 相配合，从而创建动态的、灵活的感知和响应环境。

数据仓库中的新趋势
商业智能领域中一些令人激动的新进展增加了它给商业所带来的价值。作为该系列的最后一篇文章，本文关注数据仓库的一些新兴能力，以及这些能力如何利用商业智能解决方案的灵活性和响应能力。

检测异常
检测偏差是一项极具挑战且令人畏缩的业务工作。业务执行中的偏差往往隐藏于亿万字节的企业数据之中，因此，只有业务分析员恰好切取该分析报告的某个视图才能发现其偏差。传统的方式是，业务分析员根据自己的专业知识和直觉形成业务假设。通过利用 OLAP 工具，分析员可以首先获得高级别的聚合报告，检查可视化条目，检测有问题的区域，最后钻取更低的原子层以查找原因。只要数据是可管理的，该方法似乎是适用且可行的。但请考虑若企业具有下列特点将会怎样：

• 有来自于不同数据源的大量数据。
• 拥有许多商店、产品和客户。
• 这些数据中隐藏了异常。

这种程度的复杂性对于大多数企业来说都是典型问题。有些业务领域的表现不佳，但管理层却无法立即识别该问题。早期的问题检测就是为了最小化表现不佳所带来的影响。为了完成该目标，您必须能够有计划地进行多维偏差检测，以判断哪些领域与其对等领域相比“情况不佳”。

那又如何解决呢？虽然 OLAP 工具可以帮助您回答 what if（如果……那么……）问题，但是您还必须回答 why（为什么）问题。挖掘技术已被引入到多维数据库中，给传统的“假设驱动”能力又增加了“发现驱动”的功能。已经设计了多维数据库的挖掘器（如 DB2 OLAP Miner）来进行超出正常人类能力的异常和偏差检测。DB2 OLAP Miner 以多种方式补充了 DB2 OLAP 的功能：

• 解除了手工检测的过程：DB2 OLAP Miner 免除了分析员手工钻取原子层数据以检测异常或者为某种趋势寻求解释的工作。当数据集变得极其庞大时，手工驱动的方式对于分析员也会变得冗长且易出错。由于过分依赖于直觉和目测，分析员很可能会忽略掉某些重要方面。
  
  
• 能够在多维中检测模式：与普遍误解刚好相反，模式不仅存在于原子数据层中，而且还存在于维中。此外，不同的维有不同的模式，这一事实也需要在 OLAP 中进行挖掘。OLAP Miner 引擎帮助检测存在于粒状数据以及汇总数据中的模式。OLAP 挖掘系统进行多维挖掘，并按这些维识别模式，比较或者合并它们，以及以十分智能的方式与用户交互。例如，OLAP 可能会告诉您“Blues 品牌的产品 8 月份在北卡罗来纳州盈利了”，而 OLAP Miner 却会告诉您“Blues 品牌的产品 8 月份在北卡罗来纳州盈利了，但大部分利润来源于大商场在周末免税促销时夹克衫的销售”。

概括地说，OLAP 解释您的企业发生了 什么事，而 OLAP Miner 则进一步告诉您 为什么会发生。OLAP Miner 通过使 OLAP 系统可提供与访问服务同样多的 发现服务而补充了 OLAP。

发现隐藏模式
OLAP 是假设驱动和人为驱动的，而数据挖掘却是数据驱动和发现驱动的。OLAP 需要分析员提出指定问题，如“在 2003 年第三季度纽约的销售人员在推销产品 A 时的成绩如何？”相比之下，您不必为数据挖掘提出指定问题。配有高级统计算法的数据挖掘却可以发现或者揭露人力所无法检测到的隐藏模式。

数据挖掘允许业务为前瞻式（proactive）。通过数据挖掘技术，可以发现您所不知道的新问题或者机会。考察杂货店里快速结帐台前排队的人们的购物篮总是很有趣的。他们不得不急于跑出来买的东西的各种组合令人惊讶。人类行为的多样性恰好就是导致一个组织中商业运作的细微差别的因素之一。

使用挖掘工作台（mining workbench）的旧的传统方法大量依赖专家以获得挖掘模型。比较起来，最新的方法已经开始转向在数据库本身中集成数据挖掘技术的范例。这就使得挖掘模型可以通过预测模型标记语言（Predictive Model Markup Language，PMML）交换信息。

此外，可视化工具不仅仅限于工作台。各层次的决策者们随时随地都可通过 Web 在线看到挖掘模型。挖掘模型的部署也经改善易于与操作性系统集成，以及可应用于各种销售渠道上每个客户的单独数据。而集成过程可简单到调用一个 SQL 语句，以对存储在 DB2 数据库中的挖掘模型应用新数据。 图 1描绘了新的集成架构。

图 1. 集成的挖掘环境

让我们看看新的集成挖掘范例中的三个核心组件。

使用 IBM Intelligent Miner Modeling 进行挖掘
虽然传统的工作台挖掘工具一直统治着市场，但要在应用程序中集成挖掘工具仍然存在诸多障碍。例如，操作性应用程序就很难能够动态触发动作以调整挖掘参数、代替输入数据以及重新构建挖掘模型。IBM Intelligent Miner (IM) Modeling 通过提供 DB2 UDF 挖掘函数以及允许用户在关系表中存储挖掘结果来解决该问题。这些表可包含于标准报表解决方案中并且易于被终端用户所理解。

IM Modeling 给数据挖掘函数提供了 SQL 编程接口。作为 DB2 数据挖掘函数而构建，IM Modeling 直接将数据挖掘技术集成到了 DB2 UDB 中。这就带来了应用程序的更快执行以及更好的集成。

公司可极大地受益于将模型和记分存储为数据库对象。这些好处是：

• 易于自动化与集成：由于挖掘函数通过 SQL 与数据库紧密集成，所以可以构建可重复的挖掘过程和任务来避免手工部署或者安装。此自动过程能以触发器、批文件或者应用程序的实时调用的形式进行。该自动化和集成包括构建挖掘模型以及部署记分结果。由于挖掘模型是存储在记分函数可直接访问的关系表中的，所以无须为记分而定时更新挖掘模型。因而，减少了许多同步步骤。
  
  
• 高效且有效：其中一个好处就是销售自动化和模拟。例如，公司可在指定的销售活动中搭配不同的挖掘模型，创建多个销售活动，选择部分客户模拟不同的销售活动所带来的影响，并随之存储和比较结果。整个过程都在一个环境中进行，因为模型和记分都是数据库对象。另一个好处就是管理的高效性。DBA 可容易地备份和恢复交易数据和挖掘模型，以及常规数据库管理步骤中的记分结果。
  
  
• 提高性能：通过为挖掘函数内置 SQL 接口，其性能可得到相当大的提高，因为由于在存储数据的地方就可以执行挖掘函数，您就少了传输或移动数据所带来的开销。
  
  
• 可利用现有的 IT 技术：用 SQL 编程语言进行挖掘使常规 IT 人员也可执行挖掘任务，而这些任务在一般情况下都需要数据挖掘专家的专门知识。由于挖掘专家的人数保持不变而挖掘需求却持续增加，所以挖掘专家的流动比率一直很高。SQL 挖掘编程语言允许公司在极大程度上自动化挖掘过程，并因此减少技术缺乏所带来的威胁。同时，还增加了挖掘的部署。

使用 Intelligent Miner Visualizer 进行可视化呈现。挖掘模型的可视化提供了交互和图形化呈现挖掘结果的能力。它允许分析员研究通过数据获取的规则、数据分布以及有关于每个挖掘算法的详细统计信息。Visualizer 使公司能够分析模型结果，以洞察新业务和发现新的市场定向。

挖掘模型的可视化不再限于工作台挖掘工具。Intelligent Miner Visualizer 允许您查看来自于许多可能渠道（包括 Web 应用程序、portal 和 PDA）的遵循 PMML 的挖掘模型。应用程序可以调用这些 Visualizer 来呈现模型结果，或者为就绪传播将 Visualizer 部署为 Web 浏览器中的 applet。若将应用程序部署为 Web 浏览器中的 applet，您将获得下列好处：有一个安装中心点，可减少管理时间，并且还能够集成其他现有的 Web 应用程序和 portal 应用程序。

使用 Intelligent Miner Scoring 进行前瞻式记分。虽然挖掘技术可发现隐藏的或非直觉的模式，但其可用价值仍依赖于部署模型。实时部署允许公司可基于数据挖掘模型所表达的一组预定规则对记录进行记分（分段、分类或排序）。

举一个 Web 商店中客户分段的例子。零售商可以分析客户的网上购物行为并从中获取模式、模型和统计信息，接着又可通过这些信息来确定他们可以预计销售什么以及销售给谁。根据客户的历史消费模式，公司可以将客户分为几个类别，如 platinum、diamond、gold、silver，等等。当一个客户（Joe Smith）再次登录 Web，他的有关数据将被聚集起来并对模型加以应用。模型可将 Joe Smith 归为 Platinum 类，并给他呈现定制的折扣、上行销售或交叉销售信息。这就使得公司可以通过不同的销售点抓住商业机遇。

实时分析的当前趋势是支持在更完美的数据准备上及时部署分析模型。换句话说，目标就是要在几天而不是几周之内进行实时部署，以抓住商业机遇，即使挖掘模型还不那么完美。在实现闭环的、实时的 CRM 应用程序中，记分（Scoring）技术变得十分重要。

既然易于集成是成功的关键，那么让我们来密切关注一下 IM Scoring。在 IM Scoring 中，挖掘函数被分为几组不同的挖掘类型： 群集（Clustering）、分类（Classification）和 回归（Regression）。记分（Scoring）函数可以使用其中每一种类型。每个记分函数包含了不同的算法，用以处理该类型中包括的不同挖掘函数。例如，群集（Clustering）类型包含人口群集（Demographic Clustering）和神经群集（Neural Clustering），因此，群集的记分函数就会包含用于人口群集和神经群集的算法。

IM Scoring 挖掘函数的典型用法将包括下列 4 个步骤：

1. 将挖掘模型导入 DB2 表，作为大型对象进行存储。
2. 对 DB2 表中存储的数据应用模型。
3. 在 DB2 表中存储记分结果。
4. 提取关于结果的信息，例如，群集 ID 和记分。

最后，IM Scoring 提供了一个使用方便的基于 SQL UDF 和 UDM 的 API。它还通过促进 PMML 中指定的挖掘模型上的记分提供了供应商互用性。

感知和响应
使企业能在业务事件发生时立即做出响应的新技术正变得可用。不是在问题发生后寻找需要解决的问题，而是可以通过感知（sense）和响应（response）技术立即做出响应，因为可以把业务事件本身变成可付诸实施的。

在传统的商业智能环境中，从发生业务事件到呈现显示了该事件对人的商业影响的分析报告，在时间上存在相当大的延迟。然而，加快该过程将帮助企业更及时地作出反应。有些人已经给这个新设计的实时分析法起了个时髦的名字：零延迟企业（Zero Latency Enterprise），因而暗指了该方法将给商业智能带来速度。

实时商业智能的另一方面就是 可付诸实施的部分。系统不仅提供情形检测，而且还提供响应该情形的适当操作的初始化。诸如 闭环的商业智能（closed-loop business intelligence）和 业务活动监控（business activity monitoring）的术语描述了朝着这些能力发展的行动。能更加快速响应的组织也能赢得更多的控制能力。它可以对发生的问题作出反应，并且在其业务还未受到影响之前快速行动以解决这些问题。它还可以成为前瞻式的，从而使业务事件导致公司迅速抓住机遇。通过商业智能，组织可预测何时将会出现问题或机遇，并且采取适当的行动。

这种主动智能带来了一些业务处理的新模式。第一个模式就是 感知（sense）和报警（alert），其中将检测情形并通知适当的人。乍一看，这也许听起来不像是非常革命性的东西。然而，当您在大量的信息和事件中进行耗费人力的信息采集时，如果有一个系统过滤器可以过滤掉不重要的信息并刚好获得需要引起关注的信息，那是一件多么美妙的事情。

主动智能的另一模式就是 感知（sense）和 响应（respond）。它通过使系统自动启动响应操作，扩展了感知和报警模式。自动化对于 IT 系统来说并非新东西。自定义自动系统已为业务运作服务多年。然而，自动化与商业智能和业务流程管理的结合却是具有重要意义的。

主动智能的一个例子就是一组称为主动技术（Active Technology）的 IBM 研究技术（请参阅 http://www.haifa.il.ibm.com/projects/software/amt.html）。这些技术演示了可以如何创建用于管理和响应业务事件的智能架构。主动技术由 3 个元素组成：

• Active Middleware Technology
• Active Dependency Integration
• Active Real-time Automated Decision Making

Active Middleware Technology（AMIT）是一个规则引擎，用于监控事件以及判断事件何时变成情形。规则关联长时间以来的不同事件，以发现需要操作的条件趋势或模式。这是很重要的，因为任何一个事件单独是没有意义的，但是处于以前发生的事件的上下文中，它就会具有重要意义。用一个简单例子说明了该观点：蜜蜂蜇一下对于大多数不过敏的人来说只是件引起了疼痛的小事。然而，蜜蜂蜇两三下却可能引起严重得多的健康忧虑。这种升级的忧虑模式正是感知和响应处理的重要组成部分。

Active Dependency Integration（ADI）为事件、业务实体及其相互依赖性之间的交互构造模型。它给 AMIT 事件监控规则引擎提供了一个依赖性上下文环境。无论是计算机系统实体还是人类实体与其他实体间都存在关系和依赖性。这些关系是为给业务事件提供正确意义必须要理解的重要部分。

第三个主动技术， Active Real-time Automated Decision Making（ARAD），可以优化为在情形的多个备选操作中选择一个最好的而启动的操作。

现在让我们看一个业务场景，它展示了感知和响应是如何有益于业务的。我们将以一个虚构的公司 IFM 为例，而在本系列的前三篇文章中，我们已经讨论了该公司的业务智能需求。

场景解决方案架构概述（感知和响应）
Christina 和管理小组已经注意到，在商店和供应链中还存在一些未能及时检测到的情况。如果能够检测到这些情况，那么就可以启动定价业务流程来对问题作出反应了。第一个反应流程就是监控各种不同的业务度量，这些度量可以表明在某种特定产品的销售上是否存在问题。而存货问题就作为最具挑战性的问题出现。由于 IFM 拥有上千家商店，每家商店又销售 10,000 多种不同类型的产品，因此，IFM 公司单方面很难监控某种特定的产品在销售和存货方面所有可能出现的偏差。他们决定实现一个监控流程，用以在某个特定产品的存货过多时，触发打折活动来促进销售。

在该场景中，通过 OLAP Miner 检测到了一个存货过量的情形。挖掘结果将触发促销业务流程。这些产品加上前几篇文章中讨论过的 OLAP 报告引擎和规则引擎组件联合实现了感知和响应行为。感知和响应流程的步骤相对比较简单：

1. 感知
   1. DB2 OLAP Miner 寻找偏差。
2. 响应
   1. WebSphere Business Integration Server（WBI）启动新的业务流程。
   2. 流程通过 OLAP 报告引擎连接获得附加分析数据。
   3. 流程调用合适的业务规则。
   4. 流程广播新的折扣价格。

OLAP Miner 挖掘结果包含维信息、当前存货的价值和期望值，以及偏差大小。这些结果将发送给 WebSphere Business Integration 所查询的展开文件。无论何时更新该文件，都将启动一个新的业务流程实例。净化和过滤了不需要的候选挖掘结果之后，WebSphere Business Integration 就向 Web 商店查询定价信息。此外，它还通过 OLAP 报告引擎（本例中是指 Alphablox）的 URL 检索产品利润率信息。然后查询规则引擎，以确定基于特定产品的过多存货数量、价格和利润率的折扣。然后会在门户服务器（portal server）中展示折扣信息的最终结果。 图 2描绘了上述过程。

图 2. 感知和响应流程示例

OLAP Miner（感知组件）

• 支持 OLAP 偏差检测。

IFM 数据仓库小组一旦创建了多维数据库，就会使用 OLAP Miner 以帮助检测异常和立方体中的偏差值。OLAP Miner 客户机将自动展示 IFM 当前拥有的应用程序以及他们能检测偏差的可用立方体。接下来的段落将展示 IFM 如何定义偏差检测以及如何运行偏差检测。

• 定义偏差检测

IFM 通过初次选择需要检查的立方体来创建偏差检测的定义。他们选择菜单中的“Create Deviation Detection Definition”。

• 选择每一维的成员

接下来，他们定义需要 OLAP Miner 检查并检测偏差的立方体的面积。在此业务场景中，他们希望检测 2003 年 7 月份中跨不同市场分段产品的非典型存货状况。他们对更高的聚合级别不感兴趣，因为它对存货计划没有直接影响。因此，他们的 OLAP 偏差定义包括将存货设置为度量，选择 2003 年 7 月为时间维的切片者（slicer），以及选择所有的产品家族和市场分段进行检测。OLAP Miner 演示在偏差检测定义中所作的选项。IFM 还指定 OLAP Miner 返回前 30 个偏差，以使他们可以进行更有效的促销活动。 图 3展示了 OLAP Miner 偏差检测向导。

图 3. OLAP Miner 偏差检测向导

• 运行并解释 OLAP Miner 的结果

IFM 数据仓库小组运行偏差检测并选择结果文件之后，将在主窗口的右边窗格中显示偏差列表。在结果页上，将显示不同的列：Scenario、Year、Caffeinated、Market、Product、Inventory、Expected 和 Magnitude。前五列表示 IFM 在偏差检测定义中所选择的维。Inventory 表明被检测立方体的单元格的当前值。Expected 列描述计算出的期望值是否高于或低于单元格的实际值。OLAP Miner 计算期望值和实际值之间的差异，从而导出量级（magnitude）。量级数目越大，偏差越多，且期望值与实际值之间相差越大。

以 IFM 前面结果的第四行为例进行说明。它显示处于 West 地区具有 Caffeinated 特点的产品 200-30 的当前存货为 4,229，该值要比期望值大得多。这表明 West 地区有产品 200-30 的过量存货，并且可执行一些促销活动来清空存货。

图 4演示了由 IFM 的偏差检测算法所得的偏离了正常模式的单元格。

图 4. OLAP Miner 的结果

WebSphere Business Integration（响应组件）
WebSphere InterConnection Server（WICS）驱动处理解决方案中“响应”部分的业务流程。它链接用于分析数据的 OLAP 报告引擎以及用于实施定价策略的规则引擎。下面的小节将讨论 WBI 用于集成这些组件以及实现业务流程的功能。

WBI 适配器（Adapter）
WBI 适配器（也被称为“连接器”）将不同的系统连接到业务流程逻辑中。自定义的 OLAP Miner 适配器检索 OLAP Miner 偏差检测输出，将之转变为其他 WBI 组件可用的形式并传递出去。该适配器被配置为使用自定义数据处理程序（data-handler），而数据处理程序是专门为将 OLAP Miner 输出处理为 WBI 业务对象而编写的。该数据处理程序被指派了 mime 类型的文本/偏差。在将 OLAP Miner 文本输出转变为 WBI Server 业务对象的过程中，数据处理程序将过滤掉无关重要的数据，如聚合的月份和年份信息。下面的 清单 1显示了 OLAP Miner 的输出格式。

            1: "OLAP Miner Version 7.1"
            
 2: "Scenario" ,"Year" ,"Caffeinated" ,"Market" ,"Product" ,"Inventory" ,"@Expected" ,"@Magnitude" ,"@Bitmap"
            
 3: "Scenario" ,"Jul" ,"Caffeinated" ,"Massachusetts" ,"100" ,-1493 ,2.27693 ,7 ,00011
            
 4: "Scenario" ,"Jul" ,"False" ,"Massachusetts" ,"200" ,1304 ,7558.66 ,6 ,00111
            
 5: "Scenario" ,"Jul" ,"True"
            

由于 OLAP Miner 输出数据是基于文本的，所以理论上可以使用 JText 连接器（配置为使用自定义数据处理程序）来替代自定义适配器（adapter）。然而，JText 连接器在进行处理时总是要移动输入文件，这就会产生问题，因为 OLAP Miner 输出文件还需要用于其他分析。因此，将使用自定义的 OLAP Miner 连接器而不是 JText 连接器。 图 5显示了 OLAP Miner 连接器的配置属性，包括了为自定义数据处理程序指派的 mime 类型。请注意，连接器将在 OLAP Miner 输出文件夹中查询新文件。

图 5. OLAP Miner 的自定义 WBI 适配器

自定义规则引擎适配器向规则引擎传递信息并且获取基于规则的折扣结果。该系列的 第 2 篇文章中讨论了自定义规则引擎适配器的细节。

JText 连接器是一个专门用于处理不同格式文本输入文件的 WBI 适配器，它通过映射将业务流程结果转变为在 WebSphere Portal Server 中显示的 XML。

WBI Server 业务对象
OLAP Miner 连接器和偏差数据处理程序将 OLAP Miner 偏差检测输出文件中的每一行转变为 DeviationDetectionBO 业务对象中的一个行项（METAOUTLINEBO）业务对象。 图 6中所示的映射是用于将 METAOUTLINEBO 行项转变为规则引擎业务对象。

图 6. 为 OLAP Miner 设计的 WBI Server 映射

最后，输出的 JText 连接器通过映射将 DeviationDetectionBO 转变为基于 XML 的业务对象，该业务对象将产生输出的 XML。

WebSphere Business Integration 协作
WBI Server 协作定义了业务流程的整个过程。本场景中协作的首要目的就是通过 OLAP Miner 偏差检测的输出以及产品利润和价格信息来计算存货过多产品的折扣。协作还将偏差信息以 XML 格式发送给 WebSphere Portal Server。如 图 7中的范例所示，业务流程协作由 OLAP Miner 偏差检测流程（OLAPMinerConnector）触发，然后使用偏差信息以及规则引擎信息（VersataConnector）并产生文本 XML 输出（JTextOLAPConnector）。

图 7. 展示业务对象和连接器的 WBI Server 协同

图 8显示了带标注的协作业务流程的 WBI 流程设计器。

图 8. WBI Server 流程设计器

由于输入的偏差信息包括存货过多和脱销情况的条目，协作折扣计算在确定每个存货过多条目的折扣之前，首先排除脱销条目（“净化”）。要确定折扣的多少，包含了利润和偏差信息的规则业务对象将通过一个端口传递给自定义规则引擎适配器，而该适配器将启动规则引擎中的规则评估并将已更新的规则业务对象返回给协作。最后，协作将用折扣信息更新每个存货过多的偏差条目，并且将已更新的偏差信息传递给输出 JText 连接器。

规则引擎
在规则引擎中计算存货过多产品的折扣百分比值。为存货过多产品选择折扣的规则要考虑 OLAP Miner 所检测到的现有供应与期望值的偏差变化，以及产品价格和利润率。如果变化相当大，那么就要基于利润是否为高、中或低来选择折扣，而衡量“高”、“中”和“低”的值是基于公司策略定义的。如果变化较小，那么折扣的计算就随动态定价规则变化，而在 第 2 篇文章中动态定价规则用于计算涨价。如 第 2 篇文章所述，WBI 适配器技术使得可从一个规则引擎切换至另一个选择合适的自定义规则引擎适配器的简单问题。

正如第 3 篇文章所述，在操作性系统中，利润率不是什么随意可获得的东西。它需要计算历史结果。利润将在整个企业中随时间波动。由于这个原因，分析信息必须从数据仓库环境中提取。

偏差检测的示例应用程序
图 9演示了三个不同的产品如何被检测具有偏差行为，要么是存货过多，要么是备货不足。根据其相应的利润，要针对每个产品提供不同的折扣。

图 9. 感知和响应流程的示例结果

结束语
本系列文章中，我们向您展示了行业中的一些令人激动的新技术是如何支持更加动态的、快速响应的业务环境的。通过 IFM 公司的例子，我们说明了业务流程管理如何给予组织更多的对流程再造的控制，业务规则的客观化如何允许策略从流程中分离出来，商业智能如何加强业务流程，以及在这最后一篇文章中说明感知和响应技术如何可以使业务在管理其运作时反应更加快速且更具前瞻性。