對于大部分企業來說，利潤分析是比較有特色的一項內容。可以這么說，100家企業，有99家企業利潤分析的模型是不同的。要么其側重點不同，要么其包含的要素不同。不過其有一點是值得肯定的，即其相關數據都可以在ERP系統中得到。在這里，筆者就結合ERP系統，談談如何在B1系統中建立利潤分析的模型。

一、利潤分析模型核心流程

ERP數據在BI中對利潤進行分析" src="/files/uploadimg/20110523/0855020.jpg" width=500 height=433>

▲SAP BI中建立利潤分析模型的核心流程

如上圖所示，是在SAP BI中建立利潤分析模型的核心流程。上面一部分主要是在ECC中操作，即ERP中操作。下面部分則是在BI系統中進行設計的。在ERP中，需要建立數據源。然后再BI中，將數據源復制過去，并激活與上傳數據。筆者認為，在這個流程中，核心的作業只有三個：初始化、復制和信息包。初始化是在ERP中建立數據源，而復制是將數據源從ERP系統中復制到BI中去。然后通過信息包將數據從ERP系統中提取到BI中。在后續的內容分析中，筆者也將圍繞著三個核心作業做出一些解析。其他的一些內容由于篇幅的限制，暫時就不做說明了。

二、初始化模型

筆者上面一開始就說過，雖然各個企業的利潤分析模型是不同的。但是可以肯定的是，其相關的數據都是來自于ERP系統。為此在建立數據源時，其實就是一個選擇的過程。系統會將跟利潤分析相關的字段全部列出來，然后項目管理員根據企業的實際需要，選擇對應的字段即可。

從操作上來說，其實非常簡單，就是鼠標點點而已。但是從實際項目上來看，又比較難。因為項目管理員必須對相關的字段非常的熟悉。需要將這些字段與利潤分析模型中的各個因素關聯起來。畢竟在后臺的數據表中，只是一些簡單的字段。最后需要通過數據模型，整合成一張具有實際含義的數據分析表。

在這步操作中，具體來說需要注意如下幾個問題。

一是數據源的命名規則。雖然說在BI系統中，對于命名的規則沒有很嚴格的要求。但是BI系統畢竟是一個相互協作的系統。如有可能有人專門建立數據源，而其他人專門設計分析模型。為此對數據源的命名需要遵守一些業內的規則。說實話，有時候通過觀察數據源的命名規則，就可以知道這個顧問是否專業。通常情況下，數據源的命名包括四個部分。

前面的1_CO_PA是前綴。在實際工作中，一般不建議對此進行更改。第二部分是%CL，它是一個變量，表示當前系統集團的編號。在保存是系統會自動獲取相關細心。

第三部分是%ERK，其也是一個變量，表示運行范圍。這兩個變量其實就代表了企業利潤分析中的組織層次。一般情況下，對這前面三部分內容，不建議用戶對此進行更改。保留系統的默認設置。用戶在命名時，在這后面直接加入一個下劃線，然后帶上一個具有業務意義的名字即可。由于大部分BI的實施顧問都遵守著一個約定俗成的規則，所以具有很好的通用性。

二是數據檢查。在實際項目中，一般不是建立一個數據源，就馬上復制到BI系統中去。這樣做比較浪費時間。通常的做法是，先在ERP系統中建立好多個數據源。然后一次性復制到BI中去。這可以提高工作效率，同時也是多個實施顧問之間相互協作的需要。

不過這里筆者需要強調的一點是，在實際工作中，往往在這里需要加入一個檢查的步驟。也就是說，不能夠將問題傳遞到下一個環節。在ERP系統層面，用戶就需要判斷其所創建的數據源是否準確。其實這個步驟實現起來也比較簡單。在系統中，可以使用RSA3事務代碼來驗證。

通過這個事務代碼，可以查詢對應的數據源中的數據。如果數據源中可以提取到數據，并且數據的內容也沒有問題，那么就說明這個數據源建立的是比較準確的。每建立一個數據源，最好都通過RSA3事務代碼檢驗一下。確保復制到BI系統中的數據源都是沒有問題的。

三、復制與激活

在ERP系統中創建好數據源之后，并不會自動復制到B1系統中去。畢竟這是兩個不同的系統。在實際項目中，需要項目顧問采取手工復制的方式，將數據源從ERP系統中復制到BI系統中。在復制操作時，也有相關的技巧。

一是可以集中復制。如果每建立一個數據源，就復制一次，這工作效率會非常的低。因為在復制的過程中，系統會將BI系統與ERP系統中所有相關的數據源進行對比。

如果發現數據源有更新(包括對原數據源的更改或者有新建的數據源)，就進行復制。可見，如果分開來復制的話，每次都要這么比對一次，顯然工作效率會比較低。如果集中復制的話，那么只需要一次比對過程即可。為此筆者建議最好建立好數據源之后，進行一次性的復制。這是比較合理的。

二是需要注意，后臺運行與前臺運行的不同。在復制的過程中，系統會讓實施顧問選擇，是在前臺運行還是在后臺運行。在前臺運行的話，優先級比較高，會搶占服務器的資源。相反，如果在后臺運行的話，優先級比較低，運行的時間相對來說也比較長。不過系統為了減少復制過程對服務器造成的不利影響，對于前臺運行的進程設置了一個限制條件。如果前臺運行的時間超過了15分鐘，那么系統會自動終止這個進程。此時復制作業就不能夠成功。顯然，如果需要復制的數據源比較多，那么最好還是采取后臺進程比較保險。如果只是測試，可能只有兩到三個數據源需要復制，此時采用前臺進程是可行的。在實際項目中，一般都建議采取后臺進程。

四、通過信息包傳輸數據

通過復制作業，將數據源從ERP系統復制到BI系統中去。注意在這個過程中，其只是復制了一個視圖的結構，或者說只是將字段的結構復制過去。但是具體的業務數據并沒有到BI系統中去。

此時在BI中，數據還是空的。此時就需要通過信息包，將相關的數據從底層的ERP系統中傳輸到上層的BI系統中去。在這里需要說明的是，無論是什么數據源，在BI中將數據從底層傳輸到BI系統中去，都是通過信息包這架馬車來實現的。在信息包中，確定了數據傳輸的相關規則。不過需要注意的是，這個傳輸的過程，其實是一個簡單的復制過程，并不會對原數據做出任何的更改。

五、項目經驗總結

針對利潤分析數據源的創建，筆者總結了如下幾個經驗，供大家參考。

一是這個操縱即簡單也復制。簡單是因為項目顧問只需要鼠標點點即可。而復雜在于需要掌握其后臺相關字段所對應的含義，以及對利潤分析所造成的影響。這不僅要求實施顧問有實際項目的經驗，而且還要對利潤分析這個業務有一定的了解。

二是對數據源的命名上，要遵守約定的規則。一般前面三部分都不要去做更改，而只是在后面加個下劃線和后綴。后綴要能夠反映實際業務的含義。

三是不要建立一個數據源，就到BI中去復制一次。一般是建議先建好數據源，然后再在BI系統中去進行批量的復制。當然，建好數據源之后最好使用RSA3事務代碼檢查一下。

四是在BI中復制數據源時，最好采取后臺的方式。因為采用前臺方式，會搶占服務器資源，會給服務器的正常運行造成不利影響。而且前臺進程會有15分鐘的時間限制。在實際項目中，這個復制往往會超過15分鐘。