erp項目實施寶典(更新版)

　　

【正文】 案編制者手上有大量可公用的素材庫。　　所以一個人要想寫好一個方案，首先要把自己產品的來龍去脈，功能模塊，適應領域，典型客戶實施情況有一個全面的了解，這樣才能建立一個完整的知識體系，然后逐步補充競爭對手知識和一些技術性知識，不斷深化自己的知識體系。　　有結構就有思路，有思路就有方案。3. 如何寫解決方案？　　第二是按照調研先后順序組織，和業務流順序盡量一致。握手方式即明確如何讓對方系統得到要進行更改的信息(也可能是依靠人員來進行手工操作)，這樣對方系統對接口文件進行處理。　　依據所提供樣例最終得到的接口中間文件將以完整實例作為驗證標準依據。例如當產品結構發布，相關工藝數據也發布后才能啟動接口，如果有明確接口時機要求，接口程序應適當做校驗性判斷，防止提供不正確的數據給下游系統。這種方式的重點是要掌握同什么數據對比，得出增減記錄。　　如果是中間文件的還需要確定是全量式接口還是增量式接口。通過COM的底層機制，可以訪問運行中的應用程序對象，實現與運行中程序交換數據。　　4)COM組件方式。　　3)鏈接庫方式。這類語言的缺點是沒有通用性，功能有限，由于解釋執行，速度受到很大限制，并且應用軟件開發商實現專用編程語言及調試環境有較大難度。由對方軟件直接讀取數據。　　這種情況下要提供這些工具的詳細使用說明。這種情況要求對對方數據有詳細認識。　　調研備忘錄和一般的備忘錄一樣，主要是說明本次現場工作進行了哪些工作內容，達到了怎樣的目的，和企業約定的下一步工作安排是什么，并得到企業負責人簽字認可。　　售前調研一般要協助拿項目，所以不要輕易發表對問題傾向性看法，要了解事實，用比較文飾的語言表達對問題的認識，通過對事物認識深度獲取支持。輸出數據又起什么作用，是指導下游還是反饋上游。在用戶現場上網工作時順便聊天看和工作無關的內容；　　但是各種文檔本質上是被動、靜止的通信工具，通過它們來理解一個動態系統是困難的。　　為什么不能通過一次調研鎖定需求呢？　　正確的需求是系統成功的關鍵。　　很多人很多需求都是一時靈感，沒有經過認真思考，所以口舌之快，過了也就過了，不形成文字記錄，他自己也不記得自己說過什么了。 常見錯誤九：關鍵業務只詢問了個別人意見　　一些業務在整個調研工作中是占據很重要分量，而且涉及多個業務部門，這個時候調研就要記住“兼聽則明，偏聽則暗”，一定要把業務涉及不同部門意見都聽到，也要把不同人對同一業務描述進行對比調研，從中能發現很多錯誤。指出不受控的地方，而不是失控的地方，指出實現不方便的地方，而不是指出無業務管理覆蓋的地方。但對于企業領導又如何知道我們了解企業業務呢？　　有人說這些將在解決方案中完整體現，不過說實話，有幾個人相信我們這些管理供應商寫的多達百頁的文檔企業里會有三個以上的人看一遍？　　都是在浪費紙張而已！　　所以在調研完成之前，在調研計劃中調研者應主動安排或者創造這么一次匯報的機會，專門陳述我們對企業業務和要解決關鍵問題的認識，這個認識陳述好了，企業自然對供應商刮目相看，就算有一些偏差，也可以立即得到糾偏的機會。　　沒有經過精心準備的演示可以有幾個亮點，但很難形成整體打動別人決定性力量，反而浪費了調研的時間，影響了為有價值解決方案制作的調研時間。　　第二寫記錄的過程就很容易發現一些自己感覺清楚但實際上并不清楚的內容，這些內容馬上可以形成第二天的問題進一步確認，把調研逐步推向深入。不要讓用戶以為我們每天沒有調研的時間沒有在工作，實際上為了整理四個小時的調研內容往往要用掉八個小時。　　比如有的企業更改非常多，很多調研人員就寫上一句，更改管理業務很重要。一個滔滔不絕的用戶應該是一個成功調研的特征。　　所以好的調研者要充分的讓用戶講話，自己只是在提話題，讓用戶有興趣有心情把自己知道的事情完整有序地講明白。　　做完這些工作才不是匆忙展開調研工作。 常見錯誤二：匆忙地進入調研狀態　　計劃一旦得到領導確認很多人就立即著手調研，這個時候容易犯的錯誤就是匆忙地進入調研狀態。　　多和領導見面，多用肯定語氣溝通，就會讓領導不斷強化對我們積極的印象，逐步將感情的天平傾斜到對我們有利的方面。此時就有可能需要調整計劃內容和時間。　　記住給領導溝通最有效方式之一就是“多請示，多匯報”。如果有政策，一定不要浪費。有時候很有用。計劃一定要用心，用心才能做好。　　有的時候用戶在調研過程中提出要我們做一個培訓和軟件演示的要求，一般情況下我們應該避免在售前調研階段做這個工作，因為這些要經過精心調研仔細準備后再進行質量更高。　　熟悉公司已實施的相近項目的情況。　　從應付各種用戶刁專古怪的問題的角度而言，調研準備永無止境。　　我們至少要做到80分！　　計劃發給用戶后用戶一般是不會認真看和落實的，這是中國人做事的習慣，特別是一些地位不高的聯系人，可能連為這個事找領導這個協調的膽都沒有。　　第二個調研者再進行調研時用戶就會清楚很多事情，回答問題質量就比較高，同時我們也可以有機會了解對手的牌，進行針對性準備，后發制人。調研者作為一個職業人員，我們至少要盡到提醒客戶經理去申請資源提前準備的責任。　　但是前面已經強調過，調研工作不是一個單獨的業務行為，調研是承上啟下的一個工作。還有什么比這更劃算的呢？我們只需要做一份合理的模板，每次多寫幾個字，就可以換來一個好的印象。　　用戶領導或者有時候是用戶協調人也一定希望我們在現場的工作緊湊合理，不浪費彼此的時間。一般對手在壓力下出錯的機會就越多，我們了解充分準備也容易充分，這樣我們項目成功的概率就越大。　　如果用戶都認為調研者非常或者有能力了解他們的業務，調研者說服或者高質量幫助公司的同事進行后續工作自然不在話下。　　根據我的觀察，在調研準備階段大家常常存在這么幾個錯誤。　　第一個階段叫調研準備階段，這個階段要完成調研計劃的確認，調研背景資料的準備兩方面的工作。調研工作如何組織？ 　　很多人認為調研工作極難，水平最高的人才能做好一次調研，軟件工程中也強調需求獲取是最難的事情。　　因為一個具有豐富實戰經驗的人對企業最有價值的場合不是深入實施某個具體的項目，而是進入售前。 54 第五是演示人員能力不足。 38 第五個容易犯的錯誤：沒有認真檢查，存在大量硬傷。解決方案難寫在哪里？ 31 第一種是沒有體系 31 第二種是沒有思路 32 第三種是沒有素材 32 第四種是沒有層次 32 壞的解決方案有哪些特征？(上) 33 第一個容易犯的錯誤：只有論點，沒有論證 33 第二個容易犯的錯誤：業務解決方案成為功能列表 34 壞的解決方案有哪些特征？(中) 34 第三個容易犯的錯誤：結構不清晰 34 壞的解決方案有哪些特征？(下) 38 第四個容易犯的錯誤：口語書面語混雜，遣詞造句不嚴謹。 53 第四是演示時機不好。　　根據我個人的經驗，這樣的項目經理是很少的，更多的項目經理是擁有崗位并非擁有崗位技能，但可笑的是，往往是一個人剛剛被發現具備這樣的潛質就會沒有多少機會實施項目，而是陷入另一種疲于奔命的狀態。2 如何做業務調研？　　在一個有調研經驗的業務人員眼里，調研決不是現場調研這么簡單，無論是售前還是售后調研工作本身都可以分為三個階段。 調研準備階段容易犯哪些錯誤？(上)一般接到一個調研工作任務后，大家都會去編制一個調研工作現場工作計劃，同時進行一些調研準備工作。　　如果用戶都認為調研者非常或者有能力了解他們的業務，他們自然也比較相信這個調研者的后續的解決方案或產品演示。　　我們調研工作質量越高，認同程度越高，對手壓力就越大。　　實際上我們寫一個計劃寫給誰看？計劃是我們給用戶分管領導確認的，用戶領導對你的工作內容了解越清楚，他幫助你安排工作就越方便。　　而且一份詳細的計劃做為開始，正是恰到好處的體現了我們的專業背景和職業素養。 調研準備階段容易犯哪些錯誤？(中) 第三個容易犯的錯誤：計劃沒有在內部溝通　　很多人接到調研任務，將計劃寫好，立即就開始和用戶溝通，工作精神很好，是不折不扣的行動派。　　如果很明確要進行這類工作，但又沒有安排演示準備人員。　　很多用戶往往并不清楚他們要購買的軟件到底是什么東西，所以第一批調研者很多精力要花費在灌輸概念的工作上，如果基本概念不清楚，用戶往往不能提出有價值的需求，調研時往往沒有邊際。　　有的人還會準備一些前期調研文卷和資料準備清單，讓客戶經理配合落實后再去調研，這樣的人100分。　　沒有經過認真準備的調研，到了現場很可能對各種突發情況措手不及。　　聽取他們的建議，使自己調研更有針對性。　　準備同用戶交流時的軟件原型或交流PPT。　　設計業務調研計劃。　　1WINDOWS2000/SQL SERVER/ORACLE安裝盤等常用工具軟件安裝盤。　　調研完成后送給調研對象一個小禮品是很容易給對方留下好印象的機會。和高管見面要做好三件非常重要的事情：　　一、匯報我們的計劃，請其再次確認，并請其協調資源安排人員配合。　　此外領導可能提出一些要求，例如進行培訓或者其它要求，我們可以根據實際情況確定是否要進行或者不進行。　　調研如果有一段時期，不可能天天找領導匯報，也不能不匯報，那么這個時候就可以請示領導每幾天安排一次當面匯報還是書面匯報。　　企業大了，高管并非只有一位，有的匯報必要時該重復就重復，不要給別人不尊重的感覺。　　這個鋪陳包括三個方面，第一是自我介紹，有時候還包括公司介紹，調研者也是公司的活名片，第二是了解被調研者的背景，對其配合調研表示感謝，順便奉承一下，例如說能得到您這樣有經驗人員配合是我們非常高興的事情，讓其有一個好心情開始配合調研工作，第三是對調研總體內容和時間有一個說明，說明我們想通過調研能為其業務設計好的信息化支持手段，讓其配合時做到心中有數，樂于協助。所以調研的方式應該是站在用戶的角度了解業務，有了一個對業務的總體認識，再了解細節也就更深入和細致。所以調研不是調研人員的獨角戲，而是用戶為主介紹，我們只要起到引出話題，復述內容的作用即可。　　為什么會產生這個事實？原因是什么？這個原因到底是什么產生的？一層一層了解下去，就象撥筍一樣，最后把事情分析得很透徹和明白了，問題的解決思路也就出來了。　　其實每天調研的時間一般不要超過四個小時！　　對每個個體一次訪問的時間也不要超過兩個小時！　　四個小時的調研內容是需要用同等長度甚至更長時間整理才能成型成體系的，所以在每天的調研計劃中，必須要和企業溝通好我們自己的工作方法，保障我們整理調研內容的時間。這樣做有很多好處：　　第一避免遺忘，好記性不如爛筆頭，調研過程中不停把信息記錄在本子上，但可能還是有一些遺漏，必須用一些時間趁著大腦有印象，趕緊補記下來。　　其實在調研過程不是做解決方案的過程，調研就是為解決方案奠定基礎的，過早在調研過程中提供問題的答案有如下壞處。　　單個用戶是否建立這種認識我們是通過復述技巧實現的。　　業務分析會一個鐵的原則就是不要輕易說自己用戶的不足，即使要說，也應用一種委婉的方式表達；指出可進步的地方，而不是指出落后的地方。　　所以好的調研者不僅僅是一個專業人員，在非正式場合也是一個可以讓別人說話的人，這樣的調研行為才是完整的。　　至于不想將用戶一些天馬行空問題，或者的確不想引發他們高度興趣的問題回避的方法，不是不通過調研，而是認真記錄，但不提供在正式文檔的方式規避。　　事實上這些調研信息要隨時記錄確認并最終完善到項目解決方案中，可以這樣說，信息化項目中始終要有隨時開始調研的意識，如果我們承認信息化需求是無止境的話，那么調研也是無止境的。　　大型軟件的開發需要系統分析員、軟件工程師、程序員、實施經理、用戶領導、用戶負責人、具體用戶等眾多各類不同層次不同技術水平人員的一致協調努力，因此良好的通信和相互理解對于保證工程成功至關重要，傳統的需求鎖定方法假設使用適當的文檔可以做到項目參加者之間清晰、準確、有效的溝通。調研過程中電話短消息不斷；　　　　輸入數據其什么作用，有哪些信息傳遞到輸出數據中。在啟動大會上對調研方法和需要取得支持告訴企業配合人員后進行。 如何寫調研備忘錄　　調研備忘錄一般情況下并不是把自己調研日志的內容匯總重新羅列，因為調研日志和業務調研報告就是做這個工作的。主動式基本有兩種方式：　　1)DATA方式，通過數據庫語言對數據庫進行直接讀寫。例如現在神州數碼易飛ERP就全部采用控件方式接口。即開方我們的文件或數據庫格式給對方。而只需用戶懂一點程序設計知識即可。例如CAPP和國外PDM的接口就屬于這種開放方式。目前國內很多AutoCAD二次開發軟件，就是使用ObjectARX開發的，可以完全的嵌入AutoCAD。組件是完全與語言無關的,任何過程性語言夠可以用來開發組件，根據不同的需求，可以輕易的用不同語言開發應用程序的不同部分，用戶可以選擇任何過程性語言做二次開發。是目前采用較多的接口方式。對方軟件根據數據提供方提供的文件直接更新數據庫。也就是約定當數據達到怎樣的規定后才可以啟動接口輸出，此時也可以約定接口輸出負責人員。此時可能還需要針對接口樣例提供數據規范性錄入操作說明。　　動態一致性：如設計更改信息，在一個系統內的數據更新后，要求另一個系統內的數據也要進行相應的處理。　　凡是不設計業務流和數據流，但必須要描述的內容，例如企業的一些基礎數據情況，我們把其作為企業的基本情況介紹，例如企業概況，企業設計數據統計情況，企業工藝數據統計情況，企業標準化編碼規定等等，做基本情況介紹時要把握兩個原則：　　第一是結構化，不要散亂，將相關性強的一組基本情況設計成表格填寫，這樣既方便填寫，又不容易遺漏。　　這也就是調研最大樂趣所在。關于寫方案我只總結一點，結構化地去組織你的思想。只有當一個人對一個產品思路有體系以后，才能夠寫出完整的方案，否則就是一個單元也要費盡腦汁。　　這些內容基本上是通用的，但如果沒有足夠積累每次編制方案就需要花費大量時間去準備，造成方案完成周期過長。　　方案想要寫得好，一定要用心，用心就一定要耗時間，指望用幾個小時寫出一個高質量的方案是不