sap 專案總結

SAP專案實施總結 (轉)
專案還沒結束，但很多經驗已經可以開始總結了。對於這個專案，不完善的地方有很多，有我們自己的問題，也有使用者的問題。從顧問自己的角度去看――我們可以做的更好。
我們的SAP的專案包括以下的部分：
專案前期調研
SAP產品入門培訓
企業需求確定（藍圖）
系統配置
顧問內部測試
使用者操作培訓
使用者單元測試
使用者整合測試
專案最終培訓
系統交付與支援
從我參與的情況來看，有幾個部分是需要所有SAP實施顧問尤其是初級顧問應該注意的：
1、完整的培訓文件
從我們的流程來看，培訓至少是包括三個部分的：SAP產品模組的標準培訓（一般採用LEVEL 2的標準培訓資料）、產品配置以後的操作培訓、系統交付前的最終培訓。
其中SAP產品模組的培訓很多顧問採用的是SAP LEVEL2的標準培訓文件，這類文件能很清楚的把SAP的功能模組描述清楚，同時由於顧問反覆對這類文件進行講解也容易掌握培訓的時間（一般是每個模組5天），配合IDES或其他的培訓環境，使用者也能快速的掌握SAP的基本操作
2、產品配置好以後的培訓
這部分培訓基本上是指導使用者在系統上進行操作。在我們這個階段的實施過程中是指導使用者根據已配好的模擬環境進行操作。當然使用者的操作培訓的具體資料也是結合他們實際的業務資料來進行的。
3、專案最終培訓
專案交付前的培訓大多是KEY USER對END USER的培訓。只是在國內的企業中很少有明確的KEY USER跟END USER之分。各部門經理因工作繁忙往往只能參加業務藍圖的討論，更多的所謂KEY USER實際上還是最終的操作使用者。當然也有很多企業抽調了部分業務人員，組成了內部的顧問團隊。很多時候客戶也會要求顧問對KEY USER進行培訓，這無疑加重了顧問的負擔，也降低了客戶在上線後自我完善的能力。
對於一個有一定經驗的SAP顧問來說，大體上文件並不算什麼問題，一個兩個專案，甚至透過個人的渠道都能弄到。但問題是：如何將文件精細化，更貼近這個專案的USER。
SAP專案實施的難點分析
在SAP實施的過程中作為顧問很厭煩幾種USER。
1、刨根問底的人
有好學的心是好的，但對於SAP這樣龐大的系統沒有哪個顧問對所有的業務形態、所有的欄位、所有的模組都能一一講清楚。所以顧問特別厭煩這樣的USER――甚至比那些有些愚鈍的使用者更厭煩。因為他們的好奇心往往會在系統中（尤其是測試系統中）錄入大量的垃圾資料，有可能會影響到專案（培訓）的進度，因為這些不確定的資料會影響到其他人的操作，耽誤實施的程式――而他們往往會振振有辭的說：你怎麼能這樣糊弄我？
2、愚鈍的使用者
反覆培訓仍不能理解系統操作的人。相信每個專案都會有個別這樣的人。比如我們這次的整合測試中某位使用者就讓我們大傷腦筋。由於系統文件上說明的遺漏，有些簡單的操作她/他都無法進行下去――而這些操作在上一個步驟中已經執行過的，這僅僅是重複執行同樣的操作而已。
3、繁忙的使用者
和上述兩種人相比繁忙的使用者大概更多。因為實際的工作繁忙，他們沒有時間參加培訓，只能利用晚上或者其他加班時間參加。而這時就需要顧問們加班加點的培訓了，而培訓的效果也遠澀於正常的培訓，加重了顧問的負擔。
下面我將就如何與上述三種人進行溝通的經驗與大家分享：
對於繁忙的使用者需要顧問投入更多的時間與精力――這是沒有辦法的事情，我相信絕大多數的顧問即使有怨言也會忠實的履行自己的職責。而我認為最好的方法卻是：在使用者群中挖掘可以充當教練的使用者，來協助自己完成工作。說到這點，我最大的感慨是：當產品交付以後仍有很多問題需要解決，而你沒有一個很好的可以協調的視窗將會給自己的工作帶來很大的麻煩。對某個有潛質的使用者進行深入挖掘是個利人利己的好事。當然這也要求顧問本身有良好的心態，不要怕人家搶自己的飯碗。
對於愚鈍的使用者則更要費心的指導。當然也並非沒有技巧可講，這技巧就是：將培訓標準化。對此我的體會就是：顧問在做內部測試的時候留意同時製作相關的培訓文件。並將操作規範化――我比較喜歡在做測試的同時製作相應的培訓錄影。這樣在做後續的培訓指導時可以讓使用者按我的操作錄影一步一步的操作，省去了個別指導的麻煩。由於顧問本身對SAP的操作駕輕就熟，該點哪個欄位，該如何操作都可以很快速輕鬆的進行――省卻了使用者亂點產生錯誤的問題。
對於喜歡刨根問底的使用者，則必須注意處理的藝術。如果處理不當，這類使用者很可能會成為刺頭。我覺得應該從以下幾個方面進行處理：
首先應該確認操作的基本步驟：何時該做什麼，建立操作的標準。當有了操作的標準以後顧問可以“你的操作不規範”為由推脫。
其次應該在使用者最初幾次發問中說明培訓的順序：第一步是瞭解SAP的操作，然後才是理解SAP系統，最後去研究系統中的具體欄位和流程。沒有打好基礎很難有本質上的提高，凡事要一步一步來。
最後應告知使用者：何時會做深入的培訓。我並不認為顧問可以糊弄使用者，但同時也不認為：顧問應傾囊相授。在保證專案順利進行的前提下顧問只是教授應該教的東西，至於其他額外的知識就看使用者跟顧問之間的關係以及顧問的心情了。打工並非賣身。所以深入的培訓，尤其是某些配置方面的高階培訓，顧問可以在專案進行的最後安排時間單獨處理。然而在專案的初期和中期為了保障專案的順利進行絕不能呼叫戶的胃口，做太多的講解。使用者根基沒有打牢靠之前過多的好奇心只會對專案造成傷害。
說到這點，我相信有很多使用者會不滿意了：我用業餘時間學習不可以嗎？這點我個人的感受是：培訓首先會耽誤顧問的時間，打亂顧問的整體計劃跟安排。其次使用者在瞭解到某些“高深的操作以後”對於那些日常性操作的興趣自然就散失了――而這對ERP專案的損害是最大的。正如自學SAP的過程中很多學員期望從配置開始入手，而往往在學習了很長的時間後卻依然不得其門而入。在我看來，學習SAP的後臺配置是需要對SAP產品和實際業務有深入的瞭解的前提下才能進行的。如果僅僅是瞭解某個地方有什麼TCODE，而不能將一連串的功能穿起來，只能是事倍功半。
關於文件
SAP實施的過程中顧問除了培訓外做的最多的工作就是寫文件了。對於文件我有以下的一些感慨：
作為一個成熟的顧問應該擁有一套比較完整而規範的文件――除了自己所掌握的模組以外同時應包括有其他主要/常用模組的全套文件。
在這裡為什麼會強調“全套”二字？因為沒有哪個顧問能真正擁有“全套”的東西，即使是有也不過是內容相對全面一點罷了。在實施的過程中顧問必須交付一套相對成熟的文件給客戶。如果某位顧問的文件比較切合該客戶的需求，那麼大家可以參照同一種格式的文件來修改――修改文件的速度是遠快於重新寫的。尤其是格式統一的前提下，省卻了調整、調整、再調整的麻煩。顧問之間相互共享資料對於加快專案的程式減少自己工作的強度也是有幫助的。
其次交付的文件也必須注意這樣一個問題：沒有哪個文件能把系統所有的配置都講清楚。對於某些標準或常用配置，很多文件上是不會進行描述的。但一旦你對某個操作或者配置進行了描述煩請一定要描述清楚，否則會被使用者揪出小辮子，麻煩的事就多了。而對於使用者我同樣的也要提醒這樣一點：沒有哪個顧問手頭的檔案能把整個SAP系統講清楚的，即使是上千頁的PA培訓教材。如果你真想找這樣的檔案，麻煩你先把HELP看清楚，每個欄位每個欄位的看吧――如果你覺得自己比較閒的話。當然最好是看原版德文版的。
其三，在內部測試的過程中一定要記錄自己測試的過程並形成錄影。做錄影是本人的一大愛好。我一直覺得在交付文件的過程中能同時交付該企業SAP具體操作的錄影本身也是顧問敬業的一種表現。操作的錄影首先制定了使用者操作的標準，這比任何文字性的東西都來的更直觀更全面。如果能再配上些描述或者說明的文字就太完美了。同時做錄影也方便顧問自己――總不可能一次就把所有的功能都配好吧，在錄影的過程中你也同時記錄了自己曾在哪些地方出現過差錯，方便對問題對問題的追溯。
一個專案做下來生成數十個培訓操作錄影，對於顧問自己也是種財富。未來實施SAP的過程中或許還能用上。這也是顧問自身積累的過程。
有人說：SAP的專案做到兩三個或者三五個顧問就成熟了。然而我並不這樣認為。除了那些該配的配置以外顧問更應該深入的研究SAP的產品，測試可能出現的業務場景，並一一記錄。浮躁的中國erp諮詢行業是需要更多的知識沉澱來提升的。