最后，一个集中的业务逻辑模块有助于在整个企业范围内的多个业务系统中使用和管理业务规则。还是上面所讲的客户服务的例子: 市场和销售部门都需要客户服务满意度的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越来越聪明。

（c112）