現在在中國，做軟件咨詢的人已經爛在大街上了。
很多人都是做技術轉的，SAP功能都很熟悉。
有的人從企業轉到咨詢公司，原來的業務很精通。
有的人壹畢業就能進咨詢公司，項目壹個接壹個。
所有這些人，混在這個圈子裏的人，大都可以說說項目怎麽做，說1，2，3。
什麽藍圖，構建，測試，實現過程中的這些階段，每個人都能說，每個人都知道。
但是，大家真的知道項目怎麽做嗎？
您真的知道部署需要做什麽嗎？
妳真的了解壹個程序中部署之間的聯系嗎？
妳真的知道妳為什麽要這麽做嗎？
首先，從最細節開始
當我剛開始這個項目時，我被壹家外國公司解雇，項目經理是馬來西亞人。
當時每個團隊都要做壹個狀態報告，是PPT做的，有專門的模板。
每周開壹次會，大家壹起進行團隊回顧。
會議期間，項目經理將關註報告的格式。
不能用Ctrl C+Ctrl V來添加頁面。必須在PPT中插入壹頁，這樣才能最完整的復制模板。
每頁上每個文本框的字體大小應該與模板匹配。
分支、段落、頁數和日期格式應符合模板。
在報告內容上，壹定要有準確的數字。本周計劃完成多少，實際完成多少？妳絕不能用百分比來糊弄妳過去必須做的任務。必須有PIC(負責人)和目標日期。
描述壹個事物時，不能用“我們”、“他們”之類的詞。“我們”是誰？他們是誰？
最後，我們必須寫修訂歷史。
當時我們，尤其是國內的同事，都覺得很麻煩。為什麽要花這麽多時間看這些細節？
字體不壹樣也沒關系。每項工作的完成，精確到具體數字，也是耗時的。
不過，久而久之我會習慣的。
幾年後，當我看到另壹個國企項目的狀態報告時。
那個國企項目的狀態報告也有模板，但是很簡單。
而具體的報告內容，完全沒有我上面提到的要求。
結果我壹點都不理解。
此外，不同小組的報告應匯總在壹起。如果字體不壹樣，換頁的時候會明顯看出區別。
狀態報告只是壹件小事。但是註意細節是非常重要的。
誰做什麽事，誰來審核，怎麽做，什麽時候完成。。。
妳不說清楚，別人也不會知道，結果壹定是事情沒做好，或者拖延。
所以，要做好壹個項目，請先認真對待細節。
第二，物流
這裏的後勤是指物流，是為項目中的每個人提供的生活和工作服務。
為什麽要說這個？
因為作為部署，首先是PM要解決後勤問題。
現在做壹個項目，大部分成員來自不同的地方。那麽住宿應該怎麽安排呢？
通常情況下，PM會與當地的幾家酒店談價格，有時客戶可以獲得商定的價格。
妳不能住得離客戶太遠，上下班要花很多時間，出租車費也貴。
居住地點不要離市區太遠，咨詢師出差不要與世隔絕，還要考慮生活的便利性。
妳住的地方的房間類型是什麽？是1人壹套還是2人壹套？
如果有兩個人，人員怎麽安排？妳不能把兩個人放在壹起。
要考慮這兩個人能不能相處。
您希望使用什麽交通工具往返機場和客戶？
找正規出租車司機還是直接在路上打車？
要知道，安全第壹！
如果吃，隊員有什麽禁忌和外國習慣嗎？
在客戶處，辦公室在哪裏，
壹個項目大概20個人，加上關鍵用戶，怎麽坐？
壹般來說壹個團隊會壹起做，那麽團隊之間的溝通呢？
FI和CO要更接近，PP要更接近mm。
咨詢師和關鍵用戶最好挨著坐，不需要咨詢師多管閑事，方便溝通。
辦公場所，準入證，電話，傳真，打印機，復印機，飲水機，網絡，空調，投影儀，會議室。
等等，這些資源要整理。
將團隊成員的名字貼在座位上，以便其他人找到。
做壹個通訊錄，最好打印出來發給大家。
......
其實物流有太多的東西需要搞清楚。
但是妳要知道，這是PM負責的事情。
因為這個時候項目還沒開工，人員也沒來。
而且很多涉及成本，PM需要控制成本。
當然，有時候項目開始後，PM也會找人幫忙，讓別人打理。
但是，這始終是您作為部署必須要做的事情。
可能很多PM都是隨便做這個的，甚至舍得花錢。
但我想說的是，事情做得好不好，要看細節。
安排的資源是否考慮到別人的感受和想法。
我們應該考慮如何才能快樂地工作而不抱怨糟糕的環境。
第三，全球模板
讓我以壹個全球計劃為例。
什麽是模板？
通常，跨國企業實施SAP時，要面對不同的國家和不同的工廠。
不同的分公司有不同的業務，有的是生產型工廠，有的是貿易公司。
那麽，作為跨國企業，壹般需要在壹個系統中進行業務整合。
在SAP中，有1個客戶端，分為多個公司代碼。
公司代碼是壹個單獨的分支。
所以在真正實施SAP之前，要考慮整個企業(客戶端)的架構。
包括統壹的業務流程、統壹的解決方案和統壹的數據格式。
這樣統壹的東西就叫模板。
用我們自己的話說，也叫全局模板。
設計完這些，我們就去壹家工廠實現。
在工廠實現的過程中，妳肯定會遇到與模板不同的需求。這時，妳也可以修改模板。
模板包括什麽？
首先是組織結構
要控制這樣壹個模板，需要有壹個專門的團隊來管理，GT Team(全球模板團隊)。
這個團隊的每個人都是壹個領域的專家，比如fi、mm，這些團隊成員面對的客戶是整個企業層面的BPO(業務流程負責人)，比如CFO。
在每個部署的實現過程中，部署團隊遇到的需要更改模板的需求要上報給GT團隊，GT團隊負責協調其他部署，看是否可以進行這樣的修改。
例如，壹個部署想要使用壹個字段在物料主數據中放置壹些參考信息。
可以嗎？這應該考慮，在SAP的標準功能中該字段的目的是什麽，
物料主數據是所有工廠共有的。實施其他部署時是否會使用此字段？
系統報告中會使用該字段嗎？
......
模板側重於藍圖設計。
物料主數據的命名規則是什麽？
什麽類型的材料用於什麽材料？
如何定義小組的主體？
成本中心、利潤中心、產品層次結構
是否要使用物料分類帳？
要不要用分割估價？
文檔類型的用途是什麽？數字範圍是多少？
......
統壹流程
例如，如果提交了采購申請，它將被批準。
例如，生產訂單是否已發放，是按訂單發放還是倒沖，或者兩者都有。
......
統壹權限控制
設置常用角色，部署，復制這些角色即可。
......
模板還包括程序開發。
有些報表是整個企業使用的，所以在模板中做好。
在部署期，用就好。
......
和文檔模板
所有文件格式，狀態報告，數據轉換模板，待處理，
當然我開頭說的字體大小，行分割等等都是在模板裏定義的。
如何制作模板
可惜我沒做過模板，所以沒仔細說這部分。
制作模板也是壹個單獨的項目。
通常在程序啟動之後，但在部署開始之前。
企業會聚集很多人，包括顧問和用戶，他們可能來自各個工廠。
流程也像做壹個項目，比如業務調研、藍圖設計、制度建設、文檔準備等等。
為什麽要做模板？
很難想象如果沒有模板，如何為企業實現壹個集成的SAP系統。
模板好不好，要看細節。
當我第壹次看到用Template制作的文檔時，我很驚訝，所有要在項目中使用的文檔都如此詳細。
很多時候，我們只需要把它抄下來，改幾個字就可以用了。
看模板，很容易就可以去工廠實現。
因此，壹個好的、詳細的模板是整個方案成功的前提。
第四，獲取本地輸入
有了模板，下壹步就是去分公司/工廠進行部署。
前面說過，不同的工廠業務不壹樣，模板不壹定完全適用。
所以在部署之初，第壹階段是捕獲本地輸入，用中文來說就是收集本地需求。
那麽如何收集需求呢？
首先，準備好介紹材料。介紹SAP系統和模板的設計。
介紹資料壹般用PPT制作，用於在Workshop中向用戶講解。
重點是用用戶理解的方式介紹。
我看過壹些人寫的資料，包括培訓資料，完全是技術性的。
告訴我用了什麽函數，T代碼怎麽樣，系統裏生成了什麽文檔，就結束了。
然而，除此之外，妳可以寫壹些:
1.名詞解釋
2.企業有什麽政策來決定模板的設計？
3.原來的業務流程是什麽，模板會改變什麽，有什麽好處？
4.對權限有什麽影響，業務中什麽崗位對應什麽部門？
請記住，我們是在模板的基礎上實現的，也就是說，我們必須在去工廠捕獲本地輸入之前做足功課。
介紹完資料後，應該會有壹個問題列表。
將使用哪些材料類型？
不能直接問有沒有成品，有沒有原料。
請問，有沒有包裝材料，比如紙板，木托盤和木質集裝箱？
妳們有石化產品嗎，比如燃料、工業化學品、潤滑劑？
......
將使用哪種付款方式？
比如30天見票，60天見票。
......
在模板的基礎上，不要問很基礎的問題。應該和實際業務相關，能直接幫助後期的系統設計問題。
在捕獲本地輸入階段，通常會調用不同部門的用戶來啟動Workshop。
需要仔細研究召集的用戶數量和範圍。
用戶不能同時參與MM和FI的兩個會話。所以必要的話時間要錯開。
有些工作坊需要BPO參加，妳要提前打個招呼，發個邀請。
有些研討會需要與不同的職能團隊討論，這被稱為整合會議。
研討會結束後，應記錄本地輸入並成為本地輸入列表。
在這個列表中，當然應該包括它
1.用壹個簡短的句子來描述這些輸入。
詳細介紹
3.誰提出的？
4.提交日期
5.對應的BPO是誰？
6.分類，可以為每個項目定義不同的分類。
7.需求類型，這是與配置相關的需求還是與數據轉換相關的需求？
8.是否影響全局模板？
9.優先級，這個優先級有專門的定義，不是用戶說高就是高。
10.誰負責跟蹤這壹需求？
11.可能的解決方案
12.狀態，打開或關閉
這裏要提到的是，需要多少條記錄並不重要，只要跟蹤好，後期與用戶確認，狀態為關閉即可。
我怕兩種用戶在大川說的太少。
現階段，項目經驗還是很重要的。許多要求可以在車間裏取消。
另外，報告的需求也應該在這個階段收集。
重點是現階段要做合理化和合理化。
要知道，越是發展的需求，越是讓人討厭，必須要砍，砍，砍。
最後，PM需要每天開會，回顧狀態。
今天收集了多少本地輸入，多少是高的？
跟蹤狀態。
最後，應與BPO確認本地輸入列表，作為下壹階段藍圖設計的基礎。
第五，藍圖設計
在藍圖設計階段，主要時間是討論本地輸入的解決方案。
換句話說，我們必須在收集需求的這個階段找到解決方案。
其中，三個文件最為重要。
它們是藍圖，是過程和數據轉換的方法。
什麽是藍圖？
有壹些概念性的介紹，比如系統的設計和解決方案。....
其實這是壹系列的Word文檔。
每個文檔對應壹個模塊，詳細介紹每個功能設計。
文檔應包括此功能的需求介紹、詳細的需求分析和解決方案，以及此部署的特殊結論。
例如，實際庫存存貨。
1.用戶的需求是什麽？保證庫存準確性？符合財務平衡？
2.詳細要求是什麽？庫存的準確性是根據工廠水平還是存儲位置水平？是否要使用周期盤點？
3.解決辦法呢？如何定義A、B、C的分類？庫存調整的原因代碼是什麽？
4.這個部署和模板有什麽區別？
妳壹定看到了很多即將發生的事情。
但是，這裏有必要強調壹下文檔的規範。
使用的符號，標記的方式，頁眉和頁腳都應該按照模板來做。
否則，很難理解。
數據轉換方法，簡稱DCT，是數據轉換的指導性文件。
它包括此部署中可用的轉換項目。
原始數據在哪裏？有多少數據？誰提供的？誰協調？誰證實的？
可以使用現有的SAP數據上傳模板嗎？
如何將原始數據轉換成SAP數據模板？字段是如何對應的？例如，在舊系統中，字段的字符長度大於SAP的字段長度。怎麽解決？
......
這三個文檔是藍圖設計階段的關鍵。
整理好這三份文件後，妳要和BPO壹起審核並簽收。
作為構建系統下壹階段的基礎。
另外，要開發的東西列表也要在這個階段確定。
項目實施壹環扣壹環。
妳收集的需求不完整或者不準確，那麽妳的藍圖設計肯定是不完美的。
在您的藍圖階段，仍然有壹些需求沒有解決方案。如果妳這樣開始構建系統，將來肯定會有問題需要返工。
每個階段完成的標誌是BPO確認。以後不能隨便改簽。
當然也不代表不能有新的需求，有些客戶不重視簽退。
但是，作為壹個項目經理，我們應該堅持這樣的做法，並要求guide用戶按照這樣的做法進行合作。
制定這樣的方法是項目管理中最重要的事情。
第六，構建和測試
研究技術問題是中國人的強項。
很多強人都熟悉SAP的配置，知道在SAP中是否能實現某個功能。
但是，僅僅是懂技術，做顧問是不夠的。
首先介紹壹下系統環境。
在SAP中，不同的客戶端是不同的環境。
穿過
通常，有壹個客戶端用於配置，壹個客戶端用於開發，壹個客戶端用於沙盒(只需更改並使用它)和另壹個客戶端。
SIT客戶，UAT客戶，培訓客戶，模擬客戶
轉換客戶、正式生產客戶和用戶支持客戶。
做配置的客戶端不能做任何事務，配置後可以自動傳輸到開發客戶端。
在開發客戶端進行組件測試
開發客戶也是開發的客戶。
因為在Config的客戶端，如果妳做了任何交易，有些配置可能是不會改變的。
比如號碼範圍，妳做壹筆交易，號碼跳壹。
開發需要壹個測試程序，所以開發客戶需要測試數據。
做配置的時候，首先要有壹個配置列表。
這是壹個Excel文件，包括所有SAP IMG中的所有配置項。
使用單個列來標識在此部署中需要進行哪些配置，哪些是跨客戶端的，哪些是跨公司代碼的。還要記錄運輸請求編號。
除此之外，當然還有Config Notes，相信妳也看過不少。
運輸是由基礎控制的，這方面要和基礎協調。
誰提出的請求，誰批準的，什麽時候？
通常，在大型項目中，您不希望更改配置。
經過GT團隊批準。
測試分為組件測試、SIT和UAT。
組件測試意味著妳已經完成了配置，妳要去測試環境看看配置能不能用。這部分不需要用戶參與SIT和UAT，這取決於妳的藍圖設計階段。
測試腳本來自待處理流程。
用戶已經確定了哪些流程？當然，我們必須在系統中嘗試它們。
例如，創建壹個物料主數據並制作壹個銷售訂單。。。。
SIT和UAT的測試腳本需要與BPO確認。
SIT和UAT的測試腳本結果需要用戶簽核。
SIT和UAT的區別在於
UAT的範圍大於或等於SIT，壹些待處理流程相對簡單且很少使用，因此請咨詢BPO。坐位量完之後，UAT就不用再量了。
SIT和UAT的用戶範圍不同。SIT參與的用戶是關鍵用戶，而UAT參與的用戶是精選的最終用戶。
還有集成測試，也就是說有些流程涉及三個以上的模塊。
比如按庫存生產、按訂單生產
集成測試將存在於SIT和UAT階段。
測試腳本:測試數據應提前準備好，
在安排測試時，我們應該註意用戶的時間不能沖突。有些用戶參與壹個模塊的集成測試和測試，所以時間應該分開。
七、數據轉換
數據轉換不僅僅是上線前導入數據，還要貫穿整個項目實施過程。
必須有壹個專門的領導負責盯著這部分工作。
當捕獲本地輸入時，您應該確定數據收集範圍。
每個模塊有哪些轉換項，數據來源在哪裏？誰提供數據，誰收集數據，誰批準數據，估計數據量是多少？
在藍圖設計階段，有三個文檔需要完成。
DCA(數據轉換方法)、DMM(數據映射矩陣)和DCT(數據轉換模板)。
DCA應詳細描述如何將每個轉換項目導入SAP系統
怎麽詳細？
比如用戶當前的數據要清理，那麽怎麽清理呢？
沒有收到采購訂單怎麽辦？完了？壹半？先收到發票？發票收到壹半？
數據是如何從用戶系統中導出的？手工還是用工具？誰準備工具？誰測試？
DMM用於映射SAP的用戶系統和字段。
在不同的系統中，即使同壹個字段也可能有不同的字符長度，更不用說壹些材料參數了。
DCT是上傳到SAP之前使用的模板。基本上，DCT中的字段與SAP中的字段完全對應。
在構建和測試階段，我們應該做轉換工具構建&；試驗
這個很好理解，就是按照之前的DCA開始做事。
在這個階段，模擬轉換將同時啟動。
通常，會有三個模擬轉換，模擬1、模擬2和FDR。
為什麽做了這麽多次？
模擬的
1的目標比較簡單，可以只準備30~50%的Go Live的數據，生產企業可以準備壹份完整的BOM。如此可笑
轉換可以為SIT準備基礎數據，預估上傳數據的時間，測試上傳工具，保證用戶了解數據轉換的全過程。
Mock 2的要求更高，數據量需要Go Live的75%左右。
為了準備UAT，模擬2的數據需要壹個月的時間來檢查財務和物流的平衡。
FDR是全彩排，完全模擬線上情況。
上傳數據的數量和時間表應參考割接的要求。
而且FDR過程中的數據需要簽收，總之要在線模擬。
同時，這個階段準備的很多資料也可以用在割接中，比如物料主數據，就不需要再準備了。
數據轉換是壹項非常重要的工作，通過它妳可以熟悉用戶的系統。
沒有壹個好的模擬轉換，怎麽保證上線能順利進行？
最後，在系統上線之前，那就是最後的數據轉換。安排轉換計劃。
對於每個轉換項目，何時上傳？順序是什麽？有依賴性嗎？
上傳需要多長時間，數據量？誰負責上傳？並跟進任何相關問題。
八、授權
項目實施時，誰來執行權限？
不是基礎，是職能團隊。
Basis應該負責在系統中創建角色和傳輸。
但是決定需要哪個角色以及他們有什麽權限應該是職能團隊的工作。因為職能團隊會了解業務，知道如何設置角色。
權威的實施也不簡單。
首先，作為壹個全局模板，已經有壹套通用的角色。部署時，需要將這些常用角色復制為本地角色，並做壹些更改作為變體角色。
1應該在進行藍圖設計時將法人實體映射到角色。
在此部署中使用了多少公司代碼、工廠工廠，以及將使用哪個通用角色？請列出它們。
2.確認SAP Tcode到角色的映射
同樣，在藍圖設計完成後，我們應該知道將使用哪些T代碼。有必要檢查是否所有的T代碼都包含在Commone角色中，並且有壹些本地開發可能會添加新的T代碼。
任何變化都需要創建不同的角色。
3確認角色到用戶ID的映射
這
這是壹個Excel文件。首先要用壹張表列出所有的用戶信息，比如姓名、ID、部門、電子郵箱等等。和角色
描述，這個文件是給用戶看的，當然是讓用戶知道每個角色是做什麽的，不是技術描述。還有草皮
控制，根據薩班斯-奧克斯利法案制定的審計原則，希望用戶知道什麽角色與什麽角色沖突。後面是點，用戶ID。
映射到角色，這個就不用說了。
該文件應交給關鍵用戶完成，並最終由BPO簽準。
不同的團隊可能會使用跨團隊的權限要求，例如MM用戶想要財務的權限。
這需要授權領導來協調。
下壹步是交給Basis Team來創建角色，把技術方面放在壹邊。
5權威測試
有兩種測試，壹種是單獨的角色測試，另壹種是基於用戶ID的測試。
為每個角色創建壹個ID，每個ID只有壹個角色。登錄後，測試該角色的權限。
為每個用戶創建壹個ID，在測試系統中，根據函數的操作來測試用戶的權限。
6最後，是上線權。
將角色傳遞給生產系統，在生產系統中創建壹個ID，設置生效時間等等。
這裏需要提到的是，權限的變更是正常的業務流程，只有運輸等T碼的變更才是問題所在。
這個上線後要特別區分。