袁先生具有較強的數(shù)據(jù)庫操作能力，豐富的BW模塊和ABAP模塊實施經(jīng)驗。其深刻理解SAP技術本質，以客戶需求為核心高效制定解決方案，并全程參于實施數(shù)據(jù)倉庫、數(shù)據(jù)模型的建立及增強、Query及WAD設計、程序性能調優(yōu)、數(shù)據(jù)傳輸、周邊系統(tǒng)集成接口、系統(tǒng)增強等專案。

 

        在此項目后的評價系統(tǒng)中，為了保證將來系統(tǒng)的可擴展性，我們將在系統(tǒng)中將需要的所有數(shù)據(jù)都抽取到BW數(shù)據(jù)中心，以此作為項目后評價的中心數(shù)據(jù)源，當專家對一個項目或者項目包進行評價的時候，其評價的依據(jù)都從BW中產(chǎn)生，并展示到項目評分界面。這樣設計的優(yōu)點是，即使將來評價依據(jù)的數(shù)據(jù)來源發(fā)生變更，對項目后評價系統(tǒng)沒有致命的影響，只需要對BW的數(shù)據(jù)源和抽取規(guī)則進行變更后即可，便于將來系統(tǒng)的擴展。

       該項目評價體系數(shù)據(jù)庫采用ORACLE進行設計，界面采用Web Dynpro進行開發(fā)，展示和評價指標由BW進行設計，評價指標大部分都來自PS或者ORCLE數(shù)據(jù)源。對于這種開發(fā)和BW并存的項目，和我們平常在純BW項目中碰到問題有點區(qū)別，這些問題能更好地觸動我們在面對項目時所采用的思維方式及問題解決的能力。

 

關于流程

       對于已實施過BW的公司，在進行后期深化的時候，流程是非常重要的，每個過程都必須有嚴格的流程把關，不然很可能后續(xù)InfoObject的增強和相應的轉換或者數(shù)據(jù)源的改動而影響到前期的模型和報表。

       這一點對于養(yǎng)成從頭開始慣性思維的BW顧問來說，一開始可能會有點不習慣，因為從頭開始的BW系統(tǒng)像一張白紙一樣，任由顧問揮灑，但對于其后續(xù)功能增強來說顧忌就較多。我們一開始從賬號、權限、對象名、對象存放的位置、數(shù)據(jù)庫的連接、權限改動、報表發(fā)布、報表掛接目錄等等，幾乎每一個過程都需要提交一個工作聯(lián)系單，由上級部門和維護組同事審核過了之后才能開始工作。其實，一開始對于這一塊我是很抵觸的，而且這一點也影響到了我們的項目進度，后來維護組的同事對我說：流程化的東西確實很麻煩，但這對系統(tǒng)規(guī)范操作和后續(xù)維護來講都是非常必要的過程。

       的確，我們做項目不是以完成此項目就萬事大吉；其次，要從項目整體來考慮，包括后續(xù)維護的簡易性和方便性，所以這里還是希望我們的顧問在進行項目規(guī)劃的時候可以從整體考慮，完善項目流程和文檔。

 

關于項目

       對于開發(fā)和BW并存的項目，有時候如果項目經(jīng)理在某方面經(jīng)驗豐富，他可能會偏重于那方面。同樣，此項目的項目經(jīng)理偏重在后臺數(shù)據(jù)庫和開發(fā)，所以項目一開始項目經(jīng)理會明顯對開發(fā)的工作提更多的建議，但對BW來說，這就處于一個配合的角色，這點對于項目吻合性來說不是非常有利。自從BW組的工作由我負責后，我們BW組的討論結果都會以郵件或者共同交流的方式提交給項目經(jīng)理，然后一起頭腦風暴，確定項目的方向。這樣做的目的是，為了防止項目出現(xiàn)數(shù)據(jù)庫這樣設計，模型按照另外一套思路走的危險；或者數(shù)據(jù)的勾稽關系無法進行溝通，數(shù)據(jù)庫視圖錯誤的等問題。為了保證模型和ORACLE數(shù)據(jù)庫邏輯的吻合性，最后數(shù)據(jù)庫視圖由我這邊根據(jù)ORACLE表的邏輯進行開發(fā)，然后提交開發(fā)組同事確認邏輯，這樣就保證了BW抽取的外圍數(shù)據(jù)庫字段的準確性。

 

關于與客戶溝通

       從以往的一些項目經(jīng)驗來看，做技術出生的顧問很多時候都是用技術上可是實現(xiàn)就是“是”，反之就是“否”的思維方式，因為計算機語言本身就是“1”和“0”的組合。這樣就會導致客戶在提出一個需求的時候，我們有些顧問一看技術上不可行，直接就說“這個是無法實現(xiàn)的”。而站在客戶的角度來說，若得不到詳細的解釋，還是不知道為什么不行。他們可能會產(chǎn)生以下的想法，是不是顧問偷懶，不愿意給他們實現(xiàn)某個功能；或者顧問能力不行，推搪系統(tǒng)無法解決。久而久之，當客戶有需求的時候，就不再會向我們的顧問咨詢了，二是直接報告他們的領導，然后領導找PMO，這樣對項目的進度和我們項目組的形象都會產(chǎn)生負面的影響。

這時候就要求我們所有的顧問，在面對客戶某個需求的時候，即使技術上實現(xiàn)不了，也要耐心地給客戶解釋不能實現(xiàn)的原因，對此我們有哪些可替代的方法。雖然，這樣可能會在前期解釋中較煩瑣，但當你為客戶詳細講解很幾次后，客戶就會對你產(chǎn)生信任感，這會為你以后的工作打開方便之門。

 

關于問題的解決

        我們就評價依據(jù)是否由BW提供來進行頭腦風暴時，BW報表能否可帶URL進行靈活的傳值就關系到此項目的大體方向。由于項目的構架方向要在一周之后提交客戶方進行審核，留給我們BW組去解決URL帶參數(shù)傳值的時間只有兩三天，當時我接到此任務的時候在網(wǎng)上苦尋無果，最后通過查看英文的Library進行相關嘗試，最終在晚上9點左右拿下了這個問題。由于太累，當時反而沒有什么特別興奮感，只是覺得如釋重負，因為項目組明天可以確定放下，并以此方向繼續(xù)做下去了。

       后來，我們BW組在共同的努力下，解決了很多技術問題，包括如何通過ORACLE數(shù)據(jù)庫自動生成BW Hierarchy、如何完成自動算分、ICP等等。

 

關于跳出思維怪圈

        在ORACLE自動生成Hierarchy的技術方案中，需要使用到“Open Hub Destination”，在處理鏈中用信息輪輻（InfoSpoken）將ORACLE的數(shù)據(jù)源開放到BW服務器上的某個目錄中，然后通過平面文件生成Hierarchy，實現(xiàn)Hierarchy的自動更新。然而，該方案在進行對象傳輸?shù)臅r候會記錄BW服務器的系統(tǒng)標示，對于開發(fā)機、測試機、生產(chǎn)機來說，三者的系統(tǒng)標示都是不一樣的，但是手工改動處理鏈中的系統(tǒng)標示從權限上來講是不允許的。當時，我們在解決如何自動改變服務器系統(tǒng)標示上花了很多時間，同時也咨詢了SAP的一些專家，幾乎都于事無補，最后靈光一現(xiàn)，問題迎刃而解，我們?yōu)楹尾煌ㄟ^ABAP程序直接將數(shù)據(jù)寫到服務器中的某個地方呢？這樣便于理解，也便于維護。

關于加班

        這也許是作為SAP從業(yè)者最基本的職業(yè)道德，也是這一行永遠都無法逃避的話題。作為SAP顧問，很多似乎已經(jīng)把加班當成了一種習慣。這次項目要在6月中旬上線，可由于客戶方流程方面的問題，系統(tǒng)賬號在4月底才申請下來，所以留給我們的工作時間短，任務大。幸好前期模型和藍圖已經(jīng)設計完成，但是這也無法挽救我們的五一假期。當時我的身體也不爭氣，五一假期后就開始感冒發(fā)燒，而恰巧趕上“豬流”大流行，于是我不得不去醫(yī)院做詳細檢查。還好最后安然歸隊，有驚無險，而我們項目組成員“期盼”因我而全體隔離，好好休息休息的夢想也隨之破滅。當然，在8小時工作時間內(nèi)完成當天工作，保證項目進度。是我們所有顧問的夢想。

 

關于BO

        最后要提一點的是通過BO進行界面展示的一些體會，Business Objects將其三大主流產(chǎn)品（Web Intelligence、Crystal Report、Xcelsius）在多維分析報表、格式化報表、績效圖表方面做了明確的定位和區(qū)分。我們很多習慣使用BW Business Explorer套件的顧問會覺得WAD用起來更方便，而BO的報表發(fā)布必須采用BOE的平臺可能較前者麻煩。其實在界面展示方面，BO有其特有的優(yōu)點和價值，很多時候對于工具的使用都有個習慣的過程，但我們清楚的知道，BO和BW的整合方向肯定不可能被WAD去取代Crystal Report，所以對新的工具，我們更多的的時候應該懷著接受的態(tài)度去促使其人性化地運用。

 

本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/bxy5511/archive/2010/08/23/5832991.aspx