几乎每一个绩效管理系统或者商业智能系统都会用到业务规则(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在声明中所说: “业务规则应该以一种非常容易转换到一个新的软件平台或者硬件平台的方式组织和部署。”
几乎每一个绩效管理系统或者商业智能系统都会用到业务规则(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在声明中所说: “业务规则应该以一种非常容易转换到一个新的软件平台或者硬件平台的方式组织和部署。” (x227)
