让BI更聪明

    几乎每一个绩效管理系统或者商业智能系统都会用到业务规则（Business Rules）。这些规则被报表应用程序用来自动解释数据的含义、定义关键性能指标（KPI）或者提出一些问题的整改建议。

    业务规则的含义

    实际上，BI（Business Intelligence）项目并不一定一开始都有业务规则，有的根本就没有，有的只有一个简单的业务规则，然后逐步补充和完善的。例如，在一个为客户服务的呼叫中心的BI项目，客户服务部负责人最初的报表也许只是要列出每个服务中心每天接到的电话有多少。如果每个电话都有记录，这种报表实现起来非常容易，标准的BI工具都可以完成。通常只要对原始数据进行汇总，然后累加一下电话的数量就可以了。

    但是，如果还想知道某一个服务中心有多少个电话没有及时处理，标准配置的BI工具就不够用了，这里涉及到比较复杂的业务逻辑。首先，要区分服务请求是何时提出的、何时完成的; 其次要跟踪这个服务请求是否被安排给了其他的服务中心; 第三，要计算起始之间的时间差，把这个时间差与规定的完成时间进行比较，这里还要考虑节假日。换句话说，这种报表不是直接把原始数据列出来就可行，而是需要理解数据的含义，并进行一定的运算。

    BI专家们谈到“业务规则”时有很多含义。要确定这个词汇的确切含义取决于你是从业务人员的角度还是IT人员的角度出发。罗纳德·G罗斯（Ronald G. Ross）分别从这两个角度给出这个名词的含义。从业务人员的角度，他认为业务规则是用编码来表达的业务活动; 从IT人员的角度，他认为业务规则是可重用的业务逻辑的最小单元。

    业务规则之所以在绩效管理系统和BI项目中占有如此重要的地位，是因为它赋予了数据以含义，可以帮助我们理解数据原始含义，进而产生一些更有意义的报表以指导我们决策。它们是根本原因分析和操作性报表不可或缺的要素。随着BI越来越面向流程，业务规则的重要性也在增加。今天即使在最传统的BI系统（如战略型BI和战术型BI）中也少不了数十个业务规则，还不算那些隐藏在BI系统中数百个业务规则。

    何种业务规则实现方式好

    从IT的角度，业务规则要么被编码在数据仓库的ETL（抽取、转换、加载）流程中，要么在设计一些特定的报表时被编码在BI工具里了。实际上这两种都不是最佳的方式，一种比较好的方式是在一个独立的模块中单独说明这些业务规则，这种软件构件专门用来实现业务逻辑。这种结构有以下四个好处:

    首先，如果设计得好，这种业务逻辑模块对用户是透明的。如果业务规则嵌在ETL或者BI工具中，业务人员将无法对这些实现进行审查，他只能相信程序员正确地实现了文档中所描述的业务规则，相信这些业务规则能正确地发挥作用。一旦出现了问题，也许还要最初的编程人员来帮助查找原因。例如，如果一个客户服务的请求被判定为处理迟了，这里所说的“迟”的标准是指超过3天还是含3天？相反，如果采用单独的业务逻辑模块，可以在这个模块集中完成业务规则的定义、实现或文档化等工作。这样做的好处是业务人员在一个地方就可以看到他关心的内容，比如每一个具体的业务规则是如何实现的，以及它是如何影响报表结果的。

    其次，在BI或者绩效管理项目中业务规则经常需要修改。这主要是由于以下两个原因: 第一，业务处理过程有了变化。比如，根据绩效管理系统提供的报表对业务处理采取了针对性的改进; 第二，根据这些报表以及对业务流程的改进又制定出新的业务规则。上述两种情形都需要对业务规则进行调整，如果采用单独的软件模块，修改起来将会容易得多，也不涉及到系统中其他的部分。

    第三，把业务逻辑模块从其他的IT基础设施中独立出来，有助于减少重复建设。如果IT部门决定换一个ETL工具或者BI工具，在新的工具中那些已经实现了的业务逻辑就无需再来一次。正如Business Rules Group在声明中所说: “业务规则应该以一种非常容易转换到一个新的软件平台或者硬件平台的方式组织和部署。”

    最后，一个集中的业务逻辑模块有助于在整个企业范围内的多个业务系统中使用和管理业务规则。还是上面所讲的客户服务的例子: 市场和销售部门都需要客户服务满意度的KPI，其中包括客户共拨打了多少次电话、有多少次得到了及时处理等数据。这里非常重要的一点是，市场部和销售部必须对客户服务过程中的“及时处理”的含义理解一致。这就是说，市场部和销售部在为客户服务生成报表时必须使用同一个业务逻辑。这一点可以通过在企业中设一个集中的业务规则存储库来办到，这样每个部门都可以查看、理解和在生成自己的报表时使用。

    与最后一点有关的是人们对主数据管理（Master Data Management，MDM）的兴趣正在增加。现在为了保证各个部门对数据的理解一致，认为有必要建立一个集中的MDM的企业越来越多。人们已经认识到主数据（Master Data）对于理解不同IT系统中的数据有非常重要的作用，而在一个企业中对这些数据的理解原本应该是一致的。由于MDM中含有业务逻辑，因此，MDM可以看成是一个简单的或者是一种特殊版本的业务规则。

    业务规则引擎

    那么，一个独立的业务逻辑构件到底应该是什么样子？总体上说，它应该是除了IT人员以外，业务人员也应该能使用它来定义业务规则、与其他业务部门和IT系统共享这些定义。通过设计，这种构件能为IT和业务人员提供一个接口。其实际含义就是通过报表或者操作型BI为业务人员提供一个操作的界面，程序代码由业务逻辑构件自动生成，尽量避免要程序员进行编码。

    专家们通常把这种构件称为“业务规则引擎”（Business Rules Engine）。不幸的是，对这个词的两种不同理解常常导致一些混乱。对一部分人而言，业务规则引擎是一种应用软件，它能捕获商业活动或者业务流程中的一些重要的知识，并能把这些知识应用到实际业务中; 而另一些人把它认为是“专家系统”，这个词来自于人工智能领域——它使用一组业务规则引擎来分析一个数据集，从中得出某个（些）论断。这两种应用都对业务规则引擎进行编码，但是它们使用在两种不同领域。

    让业务人员能管理业务规则引擎或者至少能查看其中被编码的规则很重要。因此，业务规则必须以一种容易被业务人员理解的形式进行封装。这就是为什么业务规则专家经常要求业务规则以自然语言的方式进行声明和表达的原因。业务规则引擎中一个普遍关注的问题是，随着时间的流逝，原来用来对业务逻辑进行编码的语言不再使用了怎么办。而规则的声明有助于解决这个问题。

    在一个BI应用特别是操作型BI应用中，业务人员习惯于把业务规则用一种程序化的方式来表达，让业务人员以上这种方式来描述流程和子流程是非常有好处的，这种描述可以非常简单地用流程图的方式来表达。尽管在许多业务流程专家认为这恰恰是业务流程最不应该的方式，但是在一个操作型的BI中，这却是业务人员表达完成某些操作的业务逻辑的最自然的方式。因为不管是IT人员还是业务人员都可以理解流程图，而且流程图可以采用最典型的“if/then”语句来描述。业务规则引擎可以通过这些流程图生成可执行的程序代码，然后在有请求或者以批处理的方式应用到数据处理中。

    总之，集中管理业务规则让BI能帮助企业总结出业务中蕴含的知识，同时让企业以一种一致的方式使用这些业务逻辑——正是这些业务逻辑让BI越来越聪明。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友