如何在erp實施上儘快入門？
本人現在在一家ERP公司實習，但是目前在這個行業是一張白紙，希望能夠系統地學習ERP實施方面的知識，請問要在哪些方面入手？
這是我在6年前寫的，現在看感覺有點半桶水晃蕩的感覺。
貼出來希望這點文字可以拋磚引玉，有經驗的人一起探討一下。我下面的方法是針對SAP的項目，所以關於其他軟體，或者是特別的軟體開發項目，可能有不一樣的地方。
序
現在的中國，做軟體諮詢這行業的人已經爛大街了。
很多人從做技術轉過來，SAP功能玩得很熟。有的人從企業轉去諮詢公司，原先的業務很精通。也有些人一畢業就能進諮詢公司，一個項目接一個項目。所有這些人，在這個圈子裡混的人，對於怎麼做項目，大多都能侃兩句，說個1，2，3什麼Blueprint啦，Build啦，Testing啦，這些實施過程中的階段，大家都說得出，都知道。可是，大家真的都了解怎麼做項目嗎？
真的知道一個Deployment需要做的事有哪些嗎？真的知道一個Program中各個Deployment之間的聯繫嗎？
真的知道為什麼要這樣做嗎？一，從最細節做起
我剛做項目的時候，是一個外企的Roll Out，PM是馬來西亞人。
當時每個Team要做Status Report，Status Report是用PPT做的，有專門的模板每周開會，大家在一起一個一個Team ReviewPM在開會的時候，會盯住Report的格式。增加一個頁面不能用Ctrl C + Ctrl V，一定要在PPT里insert一個頁面，這樣才能最完整地Copy模板每個頁面的每個文本框的字體大小要符合模板分行，分段，頁數，日期格式，要符合模板Report的內容里，一定要有準確的數字，本周計劃完成幾個，實際完成幾個，絕對不能用百分比來糊弄過去要做的任務，要有PIC（Person in Charge），Target Day。
在描述一個事的時候，不能用「我們」「他們」之類的詞。「我們」是誰？「他們」又是誰？最後，還要寫好revision history。當時我們，特別是中國的同事，覺得好麻煩啊。花那麼多時間看這些細節做什麼。
字體不一樣又不會有事。每個工作的完成情況，要精確到具體數字，統計起來也很花時間不過，久而久之也就習慣了。若干年以後，當我看到另一個國企項目的Status Report。那個國企項目的Status Report，也有模板，但是很簡單而具體的報表內容，完全沒有上面我提到的要求結果就是，我完全看不懂。另外，不同的Team的report要匯總在一起，如果字體不一樣，換頁的時候你會很明顯看到差別。
Status Report只是一個小東西。但是對於細節的認真卻是非常重要的。
任何一件事，誰去做，誰來review，怎麼做，什麼時候完成。。。你如果不講清楚，別人也不會知道，結果肯定是事情做不好，要不就Delay。所以，要做好一個項目，首先請認真對待細節。二，Logistics
這裡的Logistic是指後勤，是項目中為大家提供的生活工作服務。
為什麼要說這個呢？因為作為一個Deployment，最開始的事情，是PM要解決Logistic方面的問題。現在做一個項目，成員大多是從不同地方來的。那麼住宿應該怎麼安排？通常的，PM要找幾家當地的賓館談談價格，有時客戶那裡也拿得到協議價。
住的地方不能離客戶太遠，上下班會花很多時間，打車費用也貴
住的地方不能離市區太遠，顧問出差不能與世隔絕，也要考慮生活便利住的地方的房型怎麼樣，是1個人一套還是2個人一套2個人的話，人員怎麼安排？不是隨便2個男人就可以安排在一起的。要考慮這2個人是否能相處。往返機場，往返客戶那裡，找什麼樣的交通方式？
找固定的計程車司機還是隨便在馬路上打車？要知道，安全是第一位的！吃飯的話，Team Member有沒有忌口，有沒有國外的習慣
在客戶那裡，辦公在什麼地方，
一個項目20個人左右，加上Key User，怎麼坐？一般會說一個Team做一起，那麼Team和Team之間的交流呢？FI和CO要近一些，PP最好和MM近一些顧問和Key User最好隔著坐，不要顧問只管自己，這樣方便溝通辦公的地方，出入證明，電話，傳真，印表機，複印機，飲水機，網路，空調，投影機，會議室
等等這些資源都要安排好。把Team Member的名字貼在位子上方便別人找到做一個通訊錄，最好列印出來發給每個人......
其實要說清楚Logistic的事情，實在是太多了。
可是你知道嗎，這是PM要負責的事情因為這時候項目還沒有開始，人員還沒來。而且很多牽涉到費用，PM需要控制成本。當然有的時候PM會找人幫忙，等項目開始以後讓某個人來管。但是，這始終是作為一個Deployment開始所要做的事也許很多PM做這個比較隨便，甚至很捨得花錢。
但我想說的是，事情做得好不好，關鍵還是在細節。安排的資源有沒有考慮別人的感受想法。要考慮如何才能大家不用抱怨環境差，開心地工作。三，Global Template
讓我以一個Global的Program為例子吧。
什麼是Template
通常的，在一個跨國企業實施SAP的時候，要面對的是不同國家，不同工廠
不同分公司業務也不一樣，有些是生產型的工廠，有些是貿易公司那麼作為跨國企業，一般都是要把業務整合在一個系統里。在SAP里就是1個Client，裡面分多個Company CodeCompany Code就是單獨的分公司所以在開始真正實施SAP之前，就要考慮整個企業（Client）的架構
包括統一的業務流程，統一的解決方案，統一的數據格式這樣一些統一的東西，就叫Template
我們自己的說法，也叫Global Template等設計完了這些之後，再去一個一個工廠實施
在工廠實施過程中，肯定會碰到和Template不一樣的需求，這時候也可以再修改Template.Template包括哪些內容
首先是組織結構
要控制這樣一個Template，就要有一個專門的Team來管理，GT Team (Global Template Team)這個Team里每個人是一方面的專家，比如FI，MM。這些Team Member面對的客戶的人，是整個企業這一級別的BPO（Business Process Owner），比如CFO。在每個Deployment實施過程中，Deployment Team碰到的需要更改Template的需求，都要報告給GT Team，由GT Team負責協調其他Deployment，看是否能做這樣一個修改比如說某個Deployment想在物料主數據里用某個欄位來放一些參考信息。
可不可以呢？這就要考慮，這個欄位在SAP的標準功能的用途是什麼，物料主數據是被所有工廠都通用的，其他Deployment實施的時候會否用這個欄位這個欄位在系統的報表裡會不會被用到......Template的重點是Blueprint Design
物料主數據的命名規則是什麼？
什麼物料用什麼物料類型？集團的科目怎麼定義？Cost Center，Profit Center，Product Hierarchy要不要用Material Ledger要不要用Split ValuationDocument Type用哪些？Number Range是多少？......統一的Process
比如採購申請，誰提申請，誰批准比如生產訂單發料，是Issue to Order，還是Backflush，還是都可以......統一的許可權控制
設置Common Roles，Deployment只要Copy 這些 Roles就可以了......Template也包括程序開發
有些report是整個企業都會用到的，那麼就在Template里做好到Deployment時期只要用就可以了......還有Document Template
所有的文檔的格式，Status Report，Data Conversion Template，To Be Process，當然包括我一開始提到的字體大小，分行分段等等，都是在Template里定義怎麼做一個Template
很遺憾，我沒有做過Template，所以這部分我說得不仔細
做Template也是個單獨的項目一般在Program開始後，在Deployment開始前企業會召集很多人，有顧問有用戶，用戶可能來自各個工廠過程也象做項目一樣，業務調研，藍圖設計，系統搭建，文檔準備等等為什麼要做Template
很難想像，如果沒有Template，怎麼為企業實施一個整合的SAP系統
Template的好不好，還是取決於細節當我一開始看到Template所做的文檔，我很驚訝，居然把項目中要用的文檔都做得那麼詳細很多時候，我們只要Copy過來，改幾個字就可以用了看著Template，就可以很輕鬆地去工廠實施。所以，一個好的，詳細的Template，是整個Program成功的前提四，Capture Local Input
有了Template，接下來就是去分公司/工廠做Deployment了
前面提到，不同的工廠業務不一樣，Template不一定完全適用所以在開始Deployment的第一個階段就是Capture Local Input，中文來說就是收集當地的需求那麼怎麼來收集需求呢？
首先要準備介紹資料。介紹SAP系統，介紹Template的設計介紹資料一般用PPT做，用於在Workshop上跟用戶講解其中的重點是，要用用戶看的懂得方式去介紹。我看到過一些人寫的資料，包括培訓材料，完全是走技術路線
說說用到哪些功能，T-code怎麼樣，在系統中產生什麼Document，就結束了可是，另外的，可以寫一些：1.名詞解釋2.企業有什麼Policy，來讓我們決定Template的設計3.原來的業務流程是什麼，Template會改變什麼，有什麼Benefit4.對於許可權有什麼影響，對應於業務上的什麼部門的什麼崗位要記住我們在Template的基礎上做實施，就是要做好功課，才去工廠Capture Local Input介紹資料之後，還要有一個Question List
哪些物料類型會用到？
不能直接問有沒有產成品，原材料。可以問，有沒有Packaging Material，比如Chip Board，Wood Pallets，Wood Containers有沒有Petrochemicals，比如Fuels，Industrial Chemicals，Lubricant......哪些Payment Term會用到？
比如見票30天付款，見票60天付款......在Template的基礎上，就不要問很基礎的問題了，要跟實際業務相關，能直接幫助之後系統設計的問題
在Capture Local Input階段，通常會召集不同部門用戶來開Workshop
召集的用戶人員，範圍，需要仔細研究一個用戶不能同時參加MM和FI的2個Session。所以有必要的話時間要錯開有的Workshop，需要BPO參加，要事先打好招呼發invitation有的Workshop需要不同Function Team一起討論，稱為Integration Session經過Workshop，要把Local Inputs記錄下來，成為Local Inputs List
在這個List里，當然的，要包括1.簡短的一句話來描述這個Inputs2.詳細介紹3.誰提出來的4.提出的日期5.對應的BPO是誰6.分類，這個每個項目可能不同定義7.需求類型，這是個Config相關的需求，還是Data Conversin相關的需求8.是否影響Global Template9.Priority，這個Priority有專門的定義，不是用戶說High就是High的10.誰負責跟蹤這個需求11.可能的解決方案12.狀態，Open還是Closed這裡要提到的是，記錄的需求多沒關係，只要跟蹤好，稍後跟用戶確認，狀態Closed掉就可以了
就怕2種用戶，說話太多和說話太少這階段嘛，項目經驗還是很重要的。很多需求在Workshop時就可以砍掉了另外，報表的需求也要在這階段收集
重點是在這階段就要做rationalization，合理化。要知道，開發的需求搞得越多越煩，一定要砍掉，砍掉，砍掉。最後，PM需要每天開會，Review Status
今天收集了多少local inputs, High的多少不斷地跟蹤狀態。結束的時候，Local input list要跟BPO確認，作為下一階段Blueprint Design的依據五，Blueprint Design
Blueprint Design階段，主要的時間在針對Local Input來討論Solution
也就是說，收集到需求，都要在這一階段找到解決方案其中，有3個文檔是最重要的它們是Blueprint，To Be Process和Data Conversion Approach。什麼是Blueprint？
有一些比較概念性的介紹，比如這是系統的設計，解決方案....實際的，這是一系列Word文檔每個文檔對應一個模塊，裡面詳細介紹各個功能設計
文檔里要包括對於這一功能的需求介紹，詳細的需求分析和解決方案，對於這一個Deployment的特別的結論比如說，Physical Inventory 庫存檔點
1.用戶的需求是什麼？保證庫存準確率？和財務的Balance一致？2.詳細的需求呢？庫存準確率是按Plant level還是Storage Location level？要不要用Cycle Count？3.解決方案呢？A, B, C分類怎麼定義？庫存調整的Reason Code用哪些？4.關於這一個Deployment，和Template有什麼不一樣的地方？關於To Be Process，大家肯定看過到很多了
只是，這裡要強調一下文檔的規範使用的符號，標註的方式，頁眉頁腳，都要根據Template來做不然人家也很難看懂啊Data Conversion Approach，簡稱DCT，是對於Data Conversion指導性的文檔
裡面包括，在這一個Deployment有哪些Conversion Items。原始數據是哪裡？數據量有多大？誰提供？誰協調？誰確認？現有的SAP數據上傳模板可不可以用？原始數據怎麼轉成SAP的數據模板？欄位怎麼對應？比如在老系統里某欄位的字元長度大於SAP的欄位長度，怎麼解決？......這3個文檔，是Blueprint Design階段的關鍵
整理好這3個文檔以後，要跟BPO review，並且sign-off作為下一階段Build 系統的依據除此之外，要開發的東西的列表也要在這一階段確定下來。
項目實施，是一環接一環的，
你收集的需求不完全或者不準，那麼你的Blueprint Design肯定也不完善你Blueprint 階段還留下一些需求沒有解決方案，如果這樣開始Build系統的話，以後肯定有問題要返工每一階段完成的標誌是BPO Confirm。Sign-off以後不能隨便改。當然不是說不能有新的需求，也有的客戶不重視sign-off但是作為PM，要堅持這樣的approach，要guide用戶按這樣的approach來合作制訂這樣的approach，是項目管理中最重要的事。六，Build and Testing
研究技術問題是中國人的強項。
很多強人對SAP的配置很熟悉，知道能不能在SAP里能實現某個功能但是，光了解技術，要做Consultant是不夠首先介紹一下系統環境
在SAP里，不同的Client就是不同的環境通常的，有一個做Config的Client，一個做Development的Client，一個Sandbox的Client（隨便改隨便用）還有一個SIT的Client，一個UAT的Client，Training的Client，Mock Conversion的Client，Production的正式Client，User Support的Client做Config的Client不能做任何Transaction，做好配置以後能自動傳到Development Client
在Development Client里做Component TestDevelopment Client同時也是做開發的Client因為在Config的Client里，如果做任何Transaction，有可能有的配置改不了比如Number Range，你做了一個transaction，號碼就跳了一個了而Development需要測試程序，所以Development Client需要測試的數據在做配置的時候，首先，要有一個Config List
這是一個Excel 文件，包括所有SAP IMG裡面所有的配置項單獨用一列來標識，哪些Config 需要在這一個Deployment里做，哪些是Cross Client的，哪些是Corss Company Code。還要記錄Transport Request號碼另外，當然是Config Notes了，相信大家看到過很多
Transport是Basis控制的，這方面要跟Basis協調好
誰提request，誰approve，什麼時候傳一般在大的項目里，不是你想改就改配置的要經過GT Team ApproveTesting分Component Test，SIT和UAT
Component Test就是你做好了配置，要去測試環境里試一下配置可不可以用，這部分不需要用戶參與SIT和UAT都取決於你的Blueprint Design階段Testing Script來源於To Be Process跟用戶確定過哪些流程，當然就要在系統里都試一下比如創建個物料主數據，做個銷售訂單。。。。SIT和UAT的Testing Script都需要跟BPO確認SIT和UAT的Testing Script結果都需要User Sign-offSIT和UAT的區別在於
UAT的範圍大於等於SIT，有些To Be Process比較簡單，很少用到，那麼跟BPO確認一下，SIT測了以後，UAT就不用再測了SIT和UAT的用戶範圍不一樣，SIT參與的用戶是Key User，UAT參與的用戶是Selected End User還有Integration Test，是指有些流程是牽涉到3個以上模塊的
比如Make to Stock，Make to OrderIntegration Test在SIT和UAT階段都會存在Testing Script，Testing Data要事先準備好，
安排測試的時候，要注意用戶的時間不能衝突，有的用戶參加Integration Test和某個模塊的Tesing，那麼時間上要分開七，Data Conversion
Data Conversion不只是上線前把數據導進去而已，而是貫穿整個項目實施過程所要做的事
一定要有一個專門的Leader，來負責盯這部分工作。在Capture Local Input的時候，要確定Data Gathering Scope
對於每個模塊，有哪些Conversion Items，數據源是哪裡？誰提供數據，誰負責收集，誰Approve，數據量估計多少在Blueprint Design階段，要完成3個文檔
DCA（Data Conversion Approach），DMM（Data Mapping Matrix）還有DCT（Data Conversion Template）DCA裡面要詳細描述每一個Conversion Item怎麼樣導入SAP系統中要怎麼詳細呢？比如說，用戶現在的數據要清理吧，那麼怎麼清理呢？採購訂單沒有收貨的怎麼處理？收完的？收了一半的？發票先收了的？發票收了一半的？數據怎麼從用戶的系統導出來？手工還是有工具？工具誰準備？誰測試？DMM是用於Mapping用戶系統和SAP的欄位的
不同系統中，即使同樣的欄位，字元長度也可能不一樣，更不用說一些物料參數了DCT是用於上傳到SAP之前的模板，基本上DCT里的欄位完全對應SAP里的欄位了在Build and Testing階段，要做Conversion Tools Build Test
這個好理解，就是開始按照之前的DCA來做事在這一階段，同時要展開的是Mock Conversion
通常的，Mock Conversion會有3次，Mock 1，Mock 2和FDR為什麼搞這麼多次呢？Mock 1的目標比較簡單，可以只準備Go Live的30~50%的數據，生產型的企業可以準備一個完整的BOM。這樣的Mock Conversion，可以為SIT準備基本的數據，可以估計上傳數據的時間，可以測試上傳工具，可以保證用戶了解Data Conversion全過程Mock 2的要求就比較高一點，數據量要求Go Live的75%左右。Mock 2的數據要為UAT做準備，需要取一個月底的時間，可以核對財務和物流的餘額FDR就是Full Dress Rehearsal，完全模擬上線的情況上傳數據的量和時間安排都要參考Cut Over的要求來做而且FDR過程中的數據需要Sign-off，總之要模擬上線。同時，很多這一階段準備的數據也可以用在Cut Over的時候，比如Material Master，不用重複準備了。Data Conversion是很重要的工作，可以通過它來熟悉用戶的系統
沒有經過好的Mock Conversion，怎麼能保證上線能順利進行呢？最後，在系統上線前，那就是最終的Data Conversion。要安排好Conversion Plan
每一個Conversion Item，哪一天Upload，順序是什麼，有沒有dependency估計需要多少時間上傳，數據量？誰負責上傳？以及任何相關問題的跟蹤。八，Authorization
在實施項目的時候，許可權是誰來實施的呢？
不是Basis，是Function Team。Basis應該負責具體在系統中創建Role以及transport之類的工作。但是關於決定需要哪些role，分別有什麼許可權，應該是Function Team的工作。因為Function Team會了解業務，知道Role應該怎麼設置許可權的實施也不簡單
首先，作為Global Template，已經有一套Common Role，在做Deployment的時候，就是要把這些Common Role copy as Local Role，有一些更改的作為Variant Roles1 在做Blueprint Design的時候，要做Legal Entity Map onto Role
在這一個Deployment用到幾個Company Code, Plant，哪些Common Role會用到，要列出來2.Confirm SAP Tcode to Role Mapping同樣的，經過Blueprint Design，哪些T Code會被用到也應該知道了，要檢查Commone Role裡面是否都包括還有一些本地的開發會有新的T-code可能要加進去。任何改變都需要創建Variant Role3 Confirm Roles to User ID Mapping這是一個Excel文件，首先要用一個Sheet列出所有的用戶信息，名字，ID，Department，E-mail之類。還有Role Description，這個文件給用戶看，當然要讓用戶知道每個role是做什麼事，不要技術性的描述。還有SOD Control，根據Sarbanes-Oxley所制訂的審核原則，要用戶知道什麼role和什麼role衝突。後面是重點，User ID Mapping to Roles，這個不用多說了這個文件應該交給Key User去完成，最後要BPO sign-off不同的Team可能用Corss Team的許可權要求，比如MM User想要財務的許可權，這就需要Authorization Leader去協調4 接下來就是交給Basis Team去創建Roles了，技術方面的東西就不說了5 許可權測試分2種測試，單獨的Role測試和基於User ID的測試為每一個Role創建一個ID，一個ID只有一個role，登錄以後測這個Role的許可權為每一個User創建一個ID，在測試系統里，按照Function的操作測試用戶的許可權6 最後，就是上線的許可權準備了，把Role傳到生產系統里，在生產系統里創建ID，設置有效時間等等這裡要提到的是，許可權的更改是正常的業務流程，只有要改T-code之類要transport的才是Issue
這在上線以後要特別區分開。九，Training and Change Management
Training，通常的我們會想到Key User Training和End User Training
可是想得仔細些，仍然有很多事情需要注意1 有哪些課程？
通常和To Be Process是聯繫在一起的。創建銷售訂單是一個培訓，審批採購訂單是另一個培訓當然也可以根據需要，有一些Integration的培訓課程2.有哪些課程需要在這個Deployment做？這個Deployment需要哪些To Be Process，就需要哪些Training3.怎麼確定參加誰來參加什麼培訓？根據許可權的安排。有創建採購訂單的許可權，就參加維護採購訂單的培訓不可以按用戶的喜好，什麼想多學一點，搞到後來就是安排不過來4.Traing Agenda怎麼安排？首先，估計每個課程需要多少時間，再看參加的人員是否重複，還要考慮教室的安排5.培訓材料怎麼準備？當然要用用戶看得懂的話，這個誰都想得到，關鍵是怎麼寫有的人習慣的技術工作，是寫不出「用戶看得懂的話」的可以寫什麼呢？比如這個課程的業務背景，Blueprint Design，誰來做，根據客戶的什麼Policy，原來怎麼樣現在怎麼樣，有什麼Benefit......6.關於反饋認真點做培訓，當然要收集反饋意見，不只是用戶對講師的意見，還有用戶自己的Evaluation7.其他要注意的誰發邀請給用戶來參加培訓？什麼時候發？教室大小，有沒有足夠的位子？有沒有計算機？網路？投影儀？白板？水？培訓材料的列印？簽到？ 演示用什麼Client？用什麼ID？用什麼數據？誰準備？什麼是Change Management？
Change Management做些什麼事？我還是直接點，說說Change Management要做的事，你就知道什麼是Change Management了1. Focus Gp Workshop
要協調一開始的收集Local Input工作，安排會議，教室，安排人員等等2. Localize Training Material培訓材料不可能每個Deployment都準備，Global Template應該已經有了要把這些培訓材料改成符合local design的，Change Management是協調者3. Train The Trainer這個大家經常聽到，就是要教培訓的人, Function Team的人講課要注意什麼4. Change Readiness Survey準備各種各樣的Survey，包括對培訓的Feedback5. Pre Go live BriefingGo Live之前要通知大家吧，要告訴所有人，即使沒有參與這個項目的人發生了什麼6. Go Live booklet小冊子，要包括一些上線後的注意事項比如新的流程開始了，有誰是聯繫人7. Go Live Event這個比較輕鬆，準備一些活動8. Regular communication to the employees定期讓用戶知道項目情況，比如用黑板報9. External communication上線前要跟供應商，客戶溝通好，告訴對方我們上系統了，新的採購訂單，銷售訂單的格式有沒有變10. Go Live Communication Letter正式上線要Announce一下，發個郵件。十，RICEF
RICEF就是Report, Interface, Conversion, Enhancement, Form，SAP中開發的幾個內容。
本節和技術無關，只是說在項目中怎麼來實施RICEF首先，在Capture Local Input階段要收集RICEF Requirement
用戶需要什麼報表，什麼介面，Priority是什麼，Complexity是什麼，Frequency是什麼，每天用還是每月用一次對於這些Requirement要進行分析SAP的Standard報表可不可以用？GT Template里的報表可不可以用？這個Requirement是完全新的開發，還是在已經有的開發上的修改這個開發隻影響這一個Deployment，還是影響整個Program這個需求是一個Business Requirement還是Legal Requirement誰提的需求，對應的BPO是誰？估計的開發Man/Day是多少？上面這些考慮的因素都要都固定的標準，比如Complexity，怎麼樣算容易？怎麼樣算困難?
報表用到1個table算容易？用到4~5個table算困難？這都要development team先做好相關文檔收集Requirement的同時，就要做rationalization，砍掉不必要的需求
千萬記住，越多開發，到後期就越麻煩。有的人覺得給客戶多做開發，到以後客戶就離不開這家諮詢公司了可是，做項目不應該是這樣的，掙錢不是靠大量的開發的。等到rationalization之後，Blueprint階段就要跟BPO確認RICEF List
定下來具體會做哪些開發。是Go Live前需要還是上線後1個月需要。確定RICEF List以後，也是為了確定Go Live之前不要變出其他需求而影響Go Live雖然通常用戶會有新的需求出來，但是實施的時候可以說那些新的需求我們另外再處理如果不確定這個RICEF List，那麼怎麼樣才算做完呢？永遠做不完了。確定RICEF List之後，就要聯繫Development Team，安排開發計劃
一般Development Team和Deployment Team是分開的2個Team對於開發人員的安排，要計算的是Man/Day比如總共3個ABAPer，100個Man/Day，怎麼安排？雖然報表說是Go Live的時候需要，但是不能Go Live前才做好，因為還要測試之類的事。應該設定的目標是UAT之前做好開發。Function Design什麼時候可以做完？什麼時候Sign-off？FD Sign-off之後才能開發。每個RICEF估計要多少時間開發？即使所有報表做完，也要留一個人做bug fix，這也要算在Man/Day里做好計劃以後，要跟Function Team溝通，安排相關的人員寫Function Design
控制跟蹤進度。Function Design有沒有寫完？有沒有Sign-off？Coding in Progress？Coding Completed？Unit Test in Progress？Unit Test Completed？UAT什麼時候開始？UAT Sign-off什麼時候？Deployment Team需要一個RICEF Leader去協調，組織相關的事情，跟蹤進度。
有的時候，報表需求影響整個Program，還要去Global Template審批比如PO form，各個工廠都用同一個程序，你改這個程序可能會影響其他工廠的。最後，要把這些RICEF全部開發完，要handover給support team.
給他們文檔，解釋function design.十一，Cut Over
做完一個項目，印象最深的通常是Cut Over
一方面Cut Over比較接近項目的尾聲，另一方面Cut Over會很忙，加班比較多Cut Over不只是Data Conversion，還包括很多很多其他事項Cut Over有4個階段：Plan，Prepare，Execute和Deploy
Plan很好理解，Prepare就是協調準備Cut Over的內容，比如準備上線的小冊子Execute就是正式上線切換所做的事，比如數據導入的操作Deploy就是啟用新的業務流程主要的Activity有6個方面
1.Process System Readiness這當然是說項目實施方面的Delivery。Business Issue要解決，系統配置要傳到生產系統里，報表要開發好，許可權要分配好2.Data Readiness對於數據切換的工作數據傳到系統里，BPO sign-off3.People Readiness用戶培訓做好，用戶調研做好告訴用戶上線後的支持流程4.Technical Infrastructure Readiness客戶端要裝好，生產環境，測試環境要準備好用戶ID，系統備份準備好5.Physical Environment Readiness用戶的工作環境準備好，上線後支持人員的環境準備好一些手工填寫的申請單的格式有沒有更新好6.External Parties Readiness供應商，客戶是否準備好了？政府機關，審計公司有沒有準備好？然後，我們需要有一個Check List和一個Detail Schedule
Check List中，對於上面提到的6個方面，把具體的Avtivity列出來對應的Timeline，PIC，StatusDetail Schedule一般是指Go Live前1個月的每一天要做的事情和Data Upload那幾天要做的事情，精確到分鐘為了完成Cut Over，我們還需要有很好的組織結構
首先要有一個Cut Over Leader來協調所有事情然後6個方面的Activity每一個方面都要有人負責負責人要同時有Deployment Team的人，和用戶的人讓每個人知道自己應該在什麼時間做什麼事情Cut Over的時間安排，可以從Go Live往前推
什麼時候系統可以準備好？接著數據上傳。數據上傳後要做Shakedown Test，就是在生產系統測試一下之後就是Go No Go Meeting，評估Cut Over Avtivity是不是都做好了之後，可能還有一些Data Catch up, Month End Close什麼時候Go Love？什麼時候老系統Shut Down？Cut Over有很多事，通常會加班。
但是加班並不是必須的，我就經歷過沒有加班，周末也休息的Cut Over重點在於計劃要做得好，大家配合。十二，Support
Go Live之後，項目組通常會有一段時間的On Site Support
可是這Support也是有講究的，不只是解決問題而已首先是組織結構，通常做項目的人想得到的，是End User的問題先找Key User，Key User找顧問。
那麼這樣就要分清楚每個部門對應的人員。以及聯繫方式。除此之外，還需要有一個Support Leader來協調和統計Support的問題有問題總是要記錄下來，但是怎麼記錄呢？記錄在哪裡？什麼樣的問題要記錄呢？
我以前的項目是用SAP Solution Manager在Solution Manager裡面，用戶可以自己創建Support Message，選好模塊以後，系統就會關聯上對應的顧問同時還有很多選項，比如Priority和Type。這樣的方式很有用因為，讓用戶去寫Support Message，而且要求用戶寫得詳細，這樣，用戶有的小問題，可能只是操作不知道，就懶得記在Solution Manager里了用戶自己也會知道，只有正式的Issue才需要記錄下來。記錄下來的Issue才會跟蹤處理。關於Priority，需要事先確定什麼是High，什麼是Low，不能用戶自己感覺自己說了算關於Type更有用了，怎麼分清一個Issue和一個Change Request呢？比如報表問題，有的用戶發現報表有錯誤，這是Issue，有的用戶說報表要增加1個欄位，這是Change Request怎麼分清一個Issue和一個正常的業務呢？比如用戶許可權問題，有的只要給用戶加一個Role就可以了，這是正常的業務流程；有的是要改Role的設置，要Tranasport的，這是Issue這些都要在Type裡面區分開來。還有比如創建一個物料主數據這樣的事，就更不能當做Issue了。對於Support來說，首要目標是減少Issue，不能有High的Issue，其他的么Change Request之類存在是很正常的。對於Support的統計，也不能只限於解決多少Issue方面。還有對系統的Stabilization 分析
每一天，創建了多少物料主數據？創建了多少Vendor？創建了多少PO？這些都要進行統計，要綜合起來看想想如果用戶這一天，沒有一個Issue，但是一個PO也沒做過，這算有沒有問題呢？Support最後的工作，就是要Handover給長期的Support Team
你不想一直在這家客戶做下去吧。在Handover的時候，當然要準備好Handover Check List列出項目過程中做過的文檔，然後開Handover Session，給長期的Support Team解釋Solution一般Handover的時候要求所有High的Issue都要Closed十三，Evaluation
通常的，項目會上線的，通常的，上線後，人走了。
可是，怎麼知道這項目做得好不好呢？這項目帶給客戶的是什麼呢？實施ERP項目的意義是什麼呢？對於正規的項目實施來說，Go Live，人走了，並不是結束。
3個月後，應該會有Senior的人來做Implementation Review，看看項目實施的情況。怎麼來Review？
因為去Review的人不多，而且是Senior Manager，我本人並沒有這方面的經驗。所以只能根據看到的一些文檔做解釋我印象最深的是RICEF。
之前我們提到，RICEF是開發的東西的總稱。通常用戶提出需求，顧問給用戶開發。Review的時候，就可以看每一個報表的使用率有多少，系統里可以記錄每個T-code運行的次數。想想，一個客戶化的報表，一個月只使用2～3次，說明什麼？說明這報表是不重要的，這個開發是多餘的，需求分析是錯誤的除此之外，還可以
看看上線之後3個月有多少Issue上線之後系統的使用情況，具體做了多少訂單，多少憑證是不是所有的業務都做到系統里去了。能不能及時關帳Project Cost方面，這個項目的花費和之前的計劃差多少？客戶化開發花了多少錢？項目的交付的文檔全不全。在評價一個項目做得好不好的時候，其實在任何工作時，要盡量用具體的數字來說明問題，
這樣才有說服力，別人才能清楚地了解情況任何好，比較滿意，80%之類的詞都是模稜兩可的，那只是在搗漿糊後記
謝謝你看完這個帖子，這只是我的一點工作體會。
對我來說，把這些寫出來也是個整理的過程。發在這樣的論壇，比較輕鬆，不用去追究理論上的項目管理是怎麼樣的其實我想說的，是一種做事的態度。我遇到過很多顧問，即使是在一流的公司里，也有很多人不知道怎麼做項目
做事沒有計劃，不知道怎麼handle客戶，文檔做不來，細節不考慮我寫的這些東西，我所說的做事方法，如果周圍多一點人按這樣的方式去做事，我也會輕鬆很多可惜的是，即使你看完這個文章，你只能了解個大概，仍然不會去做項目。
比如我說High/Medium/low要有定義，那麼怎麼定義呢？因為那些細節，只有你真正去做，才會理解，最終成為你自己的東西可是沒關係，我只是希望能多一點人，理解我所說的態度，
在自己的工作崗位上，認真仔細，做好自己
謝謝
我也是涉足這個領域沒多久，簡單談下個人的幾點體會，如有不對，歡迎交流指導！1. 首先我只涉足過財務和HR以及一點供應鏈的，所以其他生產製造，PLM等等就有待其他童鞋分享2. 如果你是計算機等相關專業出身，那麼建議你去網上找點基本的會計和財務知識，比如起碼了解下會計三大表吧，知道借貸平衡吧，會計準則吧，可以拿本大學本科的基礎會計書看看；如果你是金融啊，會計，管理或者其他非計算機專業，那麼就了解下計算機的基本知識，起碼知道資料庫是什麼吧，對於常見的計算機軟體安裝啊，系統重裝什麼的盡量懂點吧，一些術業要明白，看得懂流程圖吧，可以的話自己學下簡單的SQL語句；要是實在是對以上提到的都不懂沒接觸過，那就花多點時間，將以上兩點都自己找資料學習；3.有基礎當然好，沒基礎的話，也不用怎麼擔心，實施的話，把你扔到一個項目組上，不管在這之前你懂多少，遇到問題了自然會想辦法解決，而且一般同組都會有前輩帶你，4.你說的系統學習ERP實施方面，其實最好的途徑我認為是去了解基礎財務會計知識，懂點基本計算機知識，然後找找SAP啊等公司的培訓資料，逐個了解各個模塊（財務，HR，供應鏈，生產製造，CRM等等）的業務模式/流程，當然，你可以在網上找下ERP這個概念的資料，比如相關歷史，ERPII，MRP是什麼等等，有個大概的了解，然後跟著項目成長，才是最好的途徑，別空想先學多少多少理論知識再上戰場做實施，那是不實際的，當年和我一起進來的同事，還是實習呢，一進來沒一周就被扔到項目組，一去就是大半年！
這種沒有速成班。一口吃不成大胖子。
唯一的建議找個不水的、要求比較嚴格的PM，跟著他後面做事，哪怕打雜。被罵著罵著，差不多就能開竅了。你個實習生，能寫好會議記錄，PM認為你還是個人，就算不錯了。等你做了三五個項目，再轉過頭來想想，什麼地方對，什麼地方不對，項目的實施方法論有沒有用好，你才能恍然大悟，原來如此。
你現在第一是學產品，第二是學寫會議記錄，第三是手腳勤快，少說多做。
你做得到這三點，自然有人教你，做不到，求人學也是假樣子。第一步：把目標客戶業務流程弄熟（可以通過公司內部培訓）第二步：按業務流程把軟體流程跑通（數據正確流轉）第三步：到客戶那裡實施（一開始可跟老手一起去，看幾遍再獨立實施）記住用戶永遠是你最好的老師
假如你的專業是計算機方面，建議你補充企業管理方面的理論知識；假如你的專業是企管方面，建議你補充一些SQL相關知識。無論你的專業是什麼，熟悉你的ERP軟體本身，以及知道企業的基本運轉模式都是必須的。你必須知道ERP能為企業做些什麼，才談得上如何將ERP導入企業與實際工作結合併創造價值。必須儘可能多地參與項目實施。多向前輩請教，根據項目的實施藍圖，對照項目實際進度，多看、多思考。完整地參與一個項目從調研規划到上線的全過程後，如果你適合從事這個工作，那麼你應該能基本上手了。
先弄懂手上的系統的各個業務流程，實施時學習各種流程的組合配置及更改，逐漸弄懂自家產品的長處和短處。再進一步，知道你所面對的客戶所處行業的通常會遇到的問題，他們需要解決的問題，如何解決。就實施本身來說，盡量參與完整的項目實施，經歷項目各階段和環節，有全面的項目體驗，知道每一階段會遇到什麼樣的問題。同時學習與客戶和項目團隊內的溝通。
所有的erp系統都是基於業務產生的，所以第一步永遠是學習業務，否則你的學習進展會非常的不順利。然而業務是分散的，而erp系統是聚焦的，所以要結合系統來學習業務，所以去學習系統中每個模塊和功能的業務背景。當你把這個搞明白了，你就入門了。然後找個項目印證和實踐你學習的東西你就可以成為一個合格的實施顧問了。再後面就是需要懂企業管理和項目管理的東西了。
ERP的主要的功能就是提高公司管理程度，可以更加準備高效的對業務的狀態和業績進行反饋。
我也用過不少類似的軟體，有興趣的話可以試試魔方網表，有EXCEL模板的功能，可以直接導入表單。
入門erp的實施工作，首先得明白，企業在實施ERP之前要做哪些準備工作。
首先企業各業務部門
必須收集整理分析自身的信息化需求。
其次公司將各部門的業務需求匯總後
進行優化和調整
因為很多部門問題放在公司層面考慮時
有些問題是重複的、
或者是交叉的甚至有些需求是錯誤的。
一般企業在沒有實施ERP之前，
各部門處於信息孤島狀態，
有些部門處於"數據壟斷地位"，
有了系統之後，
很多數據可以通過系統直接查詢到，
根本不需要四處打聽。
打個比方，企業在沒有信息化之前，
很多中層幹部還屬於"體力勞動者"，
因為每天的工作時間有一半在手工制單、
手動傳簽、打電話要數、傳真各種單據 等；
有了系統就不一樣了，
單據可以通過系統快速錄入，
很多單據可以從系統中直接調出，
稍加修改即可，
類似"客戶信息"、"產品信息"、
"價格信息"等只要從系統調出即可
不用重複錄入
在實施ERP之前，
還有一個很重要的工作就是初步進行流程的梳理，
內部人員在一起討論討論，
將涉及"人財物、產供銷"等相關流程簡單梳理即可，
沒有必要外請諮詢公司或者高校老師來輔導，
畢竟還是企業的各級負責人最了解企業。收起全文d
新人菜鳥，也是偶然機會接觸這一行，新S4HANA的發行對於我們這種新菜鳥能好入門嗎？求各位大咖給點意見~~~
供應鏈 財務 會計 資料庫 懂一點 能看懂業務流程圖 其他什麼的直接去項目練習
入行4年，有幾個項目經驗，可以收徒弟，帶剛零基礎的菜鳥沒問題。
找家erp公司當顧問，最簡單。
沒必要看額外的書。項目會教你一切，吃虧多了，就成熟了。實踐是檢驗真理的唯一標準
過來人告訴你，乘早換個行業吧，erp現在顧問不吃香了，要麼去大型製造企業做個技術支持，但是要知道製造企業本來待遇就不高，待久了，學會了又咋樣呢。
還不如追點熱門的，去找找互聯網公司，跟金融搭上邊的。
erp已經是個紅海領域，個人沒啥可以再多發展了這個行業 ~~實踐才是真理~~有空在這裡問 不如去做幾個測試~~討論幾個方案~你看了這些 有點感悟 但你還是不會~
我也想找一家工廠做ERP顧問，介紹一下吧，
推薦閱讀：
※SAP顧問這個職業會消失嗎？
※如何自學SAP？
※德國的經濟信息學（Wirtschaftsinformatik）是怎樣的一個專業？
※CRM能解決什麼問題？
TAG:思愛普SAP |