最后，一個集中的業務邏輯模塊有助于在整個企業范圍內的多個業務系統中使用和管理業務規則。還是上面所講的客戶服務的例子: 市場和銷售部門都需要客戶服務滿意度的KPI，其中包括客戶共撥打了多少次電話、有多少次得到了及時處理等數據。這里非常重要的一點是，市場部和銷售部必須對客戶服務過程中的“及時處理”的含義理解一致。這就是說，市場部和銷售部在為客戶服務生成報表時必須使用同一個業務邏輯。這一點可以通過在企業中設一個集中的業務規則存儲庫來辦到，這樣每個部門都可以查看、理解和在生成自己的報表時使用。
與最后一點有關的是人們對主數據管理（Master Data Management，MDM）的興趣正在增加?，F在為了保證各個部門對數據的理解一致，認為有必要建立一個集中的MDM的企業越來越多。人們已經認識到主數據（Master Data）對于理解不同IT系統中的數據有非常重要的作用，而在一個企業中對這些數據的理解原本應該是一致的。由于MDM中含有業務邏輯，因此，MDM可以看成是一個簡單的或者是一種特殊版本的業務規則。
業務規則引擎
那么，一個獨立的業務邏輯構件到底應該是什么樣子？總體上說，它應該是除了IT人員以外，業務人員也應該能使用它來定義業務規則、與其他業務部門和IT系統共享這些定義。通過設計，這種構件能為IT和業務人員提供一個接口。其實際含義就是通過報表或者操作型BI為業務人員提供一個操作的界面，程序代碼由業務邏輯構件自動生成，盡量避免要程序員進行編碼。
專家們通常把這種構件稱為“業務規則引擎”（Business Rules Engine）。不幸的是，對這個詞的兩種不同理解常常導致一些混亂。對一部分人而言，業務規則引擎是一種應用軟件，它能捕獲商業活動或者業務流程中的一些重要的知識，并能把這些知識應用到實際業務中; 而另一些人把它認為是“專家系統”，這個詞來自于人工智能領域——它使用一組業務規則引擎來分析一個數據集，從中得出某個（些）論斷。這兩種應用都對業務規則引擎進行編碼，但是它們使用在兩種不同領域。
讓業務人員能管理業務規則引擎或者至少能查看其中被編碼的規則很重要。因此，業務規則必須以一種容易被業務人員理解的形式進行封裝。這就是為什么業務規則專家經常要求業務規則以自然語言的方式進行聲明和表達的原因。業務規則引擎中一個普遍關注的問題是，隨著時間的流逝，原來用來對業務邏輯進行編碼的語言不再使用了怎么辦。而規則的聲明有助于解決這個問題。
在一個BI應用特別是操作型BI應用中，業務人員習慣于把業務規則用一種程序化的方式來表達，讓業務人員以上這種方式來描述流程和子流程是非常有好處的，這種描述可以非常簡單地用流程圖的方式來表達。盡管在許多業務流程專家認為這恰恰是業務流程最不應該的方式，但是在一個操作型的BI中，這卻是業務人員表達完成某些操作的業務邏輯的最自然的方式。因為不管是IT人員還是業務人員都可以理解流程圖，而且流程圖可以采用最典型的“if/then”語句來描述。業務規則引擎可以通過這些流程圖生成可執行的程序代碼，然后在有請求或者以批處理的方式應用到數據處理中。
總之，集中管理業務規則讓BI能幫助企業總結出業務中蘊含的知識，同時讓企業以一種一致的方式使用這些業務邏輯——正是這些業務邏輯讓BI越來越聰明。

（c112）