第一篇：項目總結會議經驗談

項目總結會議經驗談（轉）

項目總結會議經驗談

序：筆者主持過大小四十多個項目，參加過無數次的項目會議，對此可說是游刃有余，而且筆者主持過的項目總結會議中，有幾個就是在同事們意料之外的表情中，和客戶簽署了項目驗收文檔的。然而，年前的一次項目總結會議卻是鎩羽而歸，雖然原因很多，并非筆者的失誤，但結果是全面失敗。這次的老馬失蹄使得筆者靜下心來，對所參加過的項目總結會議進行總結，在此提出兩個觀點，三個準備和四個步驟，以希望更多的人獲益。

兩個觀點

一、項目驗收的標準的不同將決定項目驗收的進度和難度，盡快地讓項目驗收是項目經理首要的職責

越是大項目，驗收的標準和細節就越多，同樣也因為金額大，所以涉及驗收的人員也多，在誰簽字誰負責的壓力下，大家都不愿意先簽字，就使得項目驗收的標準變得比較不可捉摸。

在大項目中查找不適合驗收標準的問題，就相當于打靶的目標是我們所站的地球，隨便怎么打，都能中。因為客戶內部都會有一套連賣硬件都難過關的驗收標準文檔和流程，更何況是軟件驗收。如果真的按客戶的要求和標準執行，團

隊再進行兩年的開發，還不能保證能通過驗收。

所以，大項目的驗收，往往都包含著三分人情。項目經理平時就要搞好和客戶的關系，雙方在驗收的標準上能有個雙方都可以接受的方案，共同把事情做好，如果做不好，雖然客戶他也有責任，但你的公司卻要為此多付出很多的人力

物力時間和資源。

二、項目總結會議是決定項目能否順利通過驗收關鍵與跳板，要把握好這機會，不要打無準備之仗

項目總結會議，顧名思義，就是對項目的工作進行總結，哪些做到了，哪些還沒有完全滿足客戶的需求，哪些是還沒有完成的工作。因為軟件的運行有個周期，其需求會隨著用戶使用的程度，而提出更多更完善的需求，同樣，也會使

得項目的周期會比商務談判時所想像的要更長一些。

因為有商務合同和項目組工作的匯報，如果能獲得客戶的認可，同時，軟件功能，在客戶目前所提的范圍內，有了一定的實現，則項目總結會議很有可能會變成項目驗收的跳板，至少對項目驗收會有非常好的心理預期，讓雙方的中下層人員在接下來的工作中，都以項目驗收為中心的工作，會讓項目工作順利地轉入驗收期做最好的鋪墊。

三個準備

一、全面了解項目情況

很難想像一個對項目進程和工作不了解的項目經理，能主持好一個項目工作總結會議。項目驗收的流程就象是鏈環，一個套一個，其中的任何一個環出了問題，整個鏈就斷掉了。因為其中涉及的細節太多，客戶所問的任何一個問題，你沒有做出讓客戶滿意的回答，就很難保證客戶會讓會議結果朝著你所想像的目標進行。

所以，項目經理在會議開始之前，心里就應當要非常清楚，這個項目中哪些是客戶關注的，項目組完成的情況，以及客戶的滿意度，特別是客戶領導所提的需求的滿足度。以及項目進行到什么程度，在項目進行過程中，客戶的想法和

態度等等。

在此基礎上設想，客戶對我們的滿意度，如果滿意度達到一定的程度，就要明白在正式會議開始的時候，哪些會是客戶重點關注的業務，客戶在這些關注點上的態度和底限，預先知道客戶會出什么的牌，會讓你在會議上有著出人意表的收獲。

二、知曉參會人員特點

在項目實施過程中，要注意收集客戶基本的為人處世的信息，比如某人對要他簽字非常感冒，非常怕擔責任，某人比較好說話，某人實事求是，某人對細節問題非常關注，某人有整體的項目觀念，等等，平常注意這些信息的收集，總

會在某些特定的場合讓你的項目更加順利地進行。

在知曉客戶的這些信息后，要盡可能地了解客戶在參加會議那幾天的工作安排，盡可能地讓對項目有利的人員參加你的項目總結會議。千萬不要碰到能幫你說話而且權重比較大的人物，在你預約的時間出差，把你的計劃全部打亂。

同時，更要多考慮對項目滿意度不高的人，特別是對項目抱有敵意的關鍵人物，越早了解這樣的人可能出的牌，對你的項目就會越有利。因為即使客戶中有人幫你說話，但只要有人執反對的聲音，作為同公司的同事，客戶還是幫他的同事，而不是你。

三、確定切實可行的目標

不參加沒有議題的項目會議，每次項目會議都一定要有一個明確的會議主題，即使是項目例會。沒有目標的會議大家過過場，其實那是浪費雙方的時間，也是項目經理的失責。

同時在了解項目過程與現狀的基礎上，針對參會人員的特點，制定切實可行的目標與你所要實現的最低目標，并抱著最低目標進會議室，在此基礎上和客戶商談。過高的目標與期望只能在客戶都非常認可你們的工作，對你們所在的公

司也非常認可的情況才會實現。

同樣，以較低的可實現的目標向你的領導匯報時，在實際會議結束后，如果爭取到了好的成績，領導當然更高興了。相反，如果預期目標過高，而實際卻沒有實現，很難想像你要如何向領導交差。

四個步驟

項目總結正式會議

一、實事求是地對項目過程進行總結

這是一個開場白，根據習慣和現場情況，也可以將第二點放在首先開始的位置。

在對項目過程總結的時候，還是要注意盡可能談大的方面，對項目有利的要多談一些，項目過程中發生的不愉快則不要談及，同時避免將會議的主題往細節方面偏。對客戶在項目過程中的幫助不要忘記提一提，特別是他們領導在場時。

實事求是但不忘方法。

在項目總結過程，要強調的是關鍵的里程碑，雙方的付出，客戶方人員的變更，過程的辛苦，這是感情牌，有可能對會議過程會有不小的收益。軟件的運行狀況一定要報告的，談的要是總體的情況，因為細節問題和讓他們不滿意的可

以談三天的。

二、明確項目已完成和未完成的工作

任何一個項目，總是做不完，就算全部做完了，也不可能做到盡善盡美，而且更不可能做到客戶的百分百認可。所以，已完成的工作一定要重點強調，未完成的工作還是要提，因為總結會議上提到了未完成的工作，大家的心里也會開始逐漸不設防，容易流露出他們真實的想法，同樣，也不會讓他們有著驗收的壓力，雖然我們的目的是為了驗收。

同樣，已完成的工作中獲得哪些客戶的認可，最好能表示一下，避免大家為了擔責任又相互踢足球，同樣，其他人都認可了，會讓會議更順利一點，為我們的預期目標實現鋪好路。

三、探聽對方的虛實和態度

項目總結會議的最高目標就是為項目驗收做鋪墊和引信，所以在項目總結會議上看客戶對項目過程的總結和未完成工作的報告時，就能明白客戶的態度了。

此時客戶不可避免會根據項目過程中的某些問題談自己的看法，此時，要避免和客戶發生爭執，要用較委婉的方式提出讓客戶覺得我們努力了，而且結果總體上也還是不錯的，能說得過去的，記住在客戶的同事們面前要保留住客戶的面子。

如果客戶此時沒有異議，表示可以接受，就說明客戶對項目整體上還是可以接受的。如果客戶對此還是有一定的不能接受，這時一定要再對客戶的此問題進行解釋，以達到他所提的是有道理但卻超出項目的范圍。如果客戶對此異議較大，則需在不傷客戶面子的基礎上，據理力爭，最好是由下層人員發表意見，以便為項目經理或更高層的副總和總經理

留有更廣的回旋空間。

如果某些客戶提出近乎耍無賴或苛刻的要求，此時，現場最高職位的人一定要站出來，發表對其的批評和意見，因為此時不制止，就算客戶的同事明白這情況，但也不會發表相左的聲音幫你說話的，相反，要是高職位的人員出面說話，客戶的同事特別是職位比他高的人反而會幫忙制止他的要求，如果提這樣無理要求的客戶是項目經理或更高職位，那現場上，中下層人員包括項目經理都要做好和客戶吵翻天的準備了，此時，鬧得越大，只要有理，雖然人員會更換，但項目的驗收一定會比所有的預期中更快的時間完成，甚至本周就會完成。

四、結合現有情況逐步實現目標

項目總結會議并不是項目驗收會議，所以特別忌諱項目驗收簽字付款這類的詞匯，更不能在會議剛開始時，就表露出這樣的心態，除非雙方公司有非常鐵的關系，對方也非常愿意近期將這項目驗收才成，不然項目總結會議會使得雙方變得有敵意，而且客戶會因為你所說的這些話開始對你設防，處處抵制你所說的項目情況，會議就會陷入細節辯論，使

得會議勞而無功，所有的預期目標都難實現了。

所以，一開始你要隱藏目標，在了解了客戶對項目的態度和底線后，再根據現場你所主導的氣氛和客戶對項目的認可度，再決定你所能達到的目標，如果覺得目標客戶不可能答應，就不要提。所以在現場，只能根據實際情況順勢利導，提出對方可以接受的要求，以保證會議會有收獲。

結合現場情況，在實現初步目標的基礎上，逐步提出更高的目標，會讓客戶在不知不覺中逐漸認同你的觀點，項目過程中的某些不足客戶也會覺得情有可原，大家心里都了解都明白，只要不陷入細節的商談，會議的預期目標會在非常自然的情況下被客戶認同的，因為只要我們項目做到位，客戶是不會去非常刻意地為難我們的，他們也希望項目能驗收，特別是元旦和春節之前。

第二篇：IT項目收尾管理經驗談

IT項目收尾管理經驗談

2013年12月20日 09:24 來源：中國項目管理資源網 作者： 字號

打印 糾錯 分享 推薦 瀏覽量 267

所謂驗收就是對整個軟件開發、建設項目的結果的綜合評價，是軟件系統交付使用前對項目進行評估、認定和總結的過程，包括費用、質量、服務等多個方面，包括對整個系統的運行情況、業務流程重組的有效性、生產運作的效率等方面的一個評估，也是對IT項目范圍的再確認。IT項目的實施，一般包括6個階段，即項目的選型、培訓、業務流程重組、基礎數據整理、會議室試點、切換等，在系統切換后，緊接著的還有一項關鍵性的工作，就是項目的驗收。

IT項目驗收主要是通過對項目全面測試性檢驗，找出項目中可能存在的問題和不足，并進行最后的修正、完善，以使項目保質保量最終交付到用戶單位每個使用人員手中。可以說，驗收是IT項目最后關鍵的環節，它是對項目的實施質量和軟件的可交付性起到“一錘定音”的作用，也關系到IT項目能否平滑順利步入運營期、為企業創造效益，軟件開發服務商能否實現收益標志之一。因此CIO必須高度重視，萬莫輕視。

比如ERP項目，由于其軟件的復雜性、規模性，CIO們可能更多地關注它多變的需求定義、選型、個性化解決方案，卻輕視了項目的驗收工作，而驗收需要大量數據測試、自定義擴展、長時間運行等后才能明辨優劣、成效，但是由于供需雙方受種種原因的影響急需“結賬”，從而使項目驗收從時間、內容、范圍、數量、人員等投入均顯不足，而且由于多數信息化項目的驗收評估標準難以具體量化，常使驗收常流于形式，最終使實施結果不佳。

為何不少IT項目成了“雞肋工程”甚至變成“爛尾工程”?一個重要原因就是最后一個關--“驗收”疏忽大意，沒有把關好，前功盡棄，敗走麥城。對此，作為企業信息官的CIO，負有重要責任。還有，一些用戶單位CIO以為項目實施工作做好了，系統跑起來了，文檔移交了，開發商確認了，還有什么必要大動干戈做驗收？這些想法、做法，源于對驗收的目的、流程、方法和意義缺乏認識，造成一個個延期工程、半生不熟項目或爛尾工程。

一、把握項目驗收的重點內容

可以說，驗收事關項目能否善始善終，悠關全局的成敗，那么CIO如何做好項目驗收？從哪里重點把握？結合理論與實際操作，一般而言，IT項目驗收主要應包括驗收準備、數據移植、系統測試、系統評估4個主要過程。

1、著手驗收階段的準備工作

當單位始要進入驗收時，CIO應著手進行相應驗收的準備工作--向軟件開發商收取軟件開發過程中各階段性文檔，包括需求分析說明書、概要設計說明書、詳細設計說明書、數據庫設計說明書、源程序代碼、可供安裝使用的系統安裝程序、系統管理員手冊、用戶使用手冊、測試計劃、測試報告、用戶報告、數據移植計劃及報告、系統上線計劃及報告、用戶意見書、驗收申請等；然后對這些各類約定的技術文檔和合同中的相關內容進行自查，要徹底了解系統目前完成的情況如何，是否已完成了與開發商達成的各項書面約定以及口頭約定，沒有完成的，如果是書面約定，準備采取什么策略去進一步完成等。

當然，此時CIO做一個詳細的驗收計劃是非常必要的，可以用來作為驗收階段的工作指導，并組織管理層領導、業務管理人員和信息技術專家成立項目驗收委員會，負責對IT項目進行正式驗收。

2、數據移植

如今不少企業都上了OA、CRM等系統，或淘汰老系統，在進行新系統(如ERP或PLM)建設并最終上線時，一般需要將舊系統的原始數據移植到新系統或調用企業原有的OA、CRM等系統內的數據時，則常需數據移植，此時CIO正好可籍此機會檢驗新系統的優劣、匹配性如何。這些應完成以下主要工作內容：

1)制訂數據移植：除了要定義數據收集的格式、范圍、進度外，還要考慮系統接口的影響，并建立數據移植完整性和準確性測試方法以及意外事件處理程序;

2)數據收集：項目實施常涉及到數據收集，應由數據收集小組根據數據收集格式，準確對數據進行收集，以確保數據提供人員了解和掌握對數據收集的各項規定和要求;

3)數據導入并核查結果：項目組成員將數據導入系統，并在導入后按照事先制定的數據移植完整性和準確性的測試方法，對系統中的數據做進一步的核查，確保導入數據的質量;

4)數據移植后要進行適當時間的試運行，檢測、確認數據移植的真實性、準確性和完整性。

3、系統測試

系統測試是項目驗收的關鍵環節，也是CIO最需花心思把關之處。以ERP軟件為例，系統測試具體包括以下5大測試內容：安裝測試、功能測試、界面測試、性能測試、文檔測試等。而其中，功能測試是重點，必須高度重視。

下面結合ERP，重點闡述如何有效進行功能測試，其功能測試的用例設計，主要應注意以下幾點：

1)測試項目的輸入域要全面。要有合法數據的輸入，也要有非法數據的輸入，CIO可以此檢驗系統的抗干擾性如何;

2)要適時利用邊界值進行測試。如“訂單預排”中一般要求預排的數量大于0，那么測試數據可以分別為0，-1，1，100000(一個非常大的正數)，查看單據流轉和控制情況，系統在執行MRP分解、工單下達、車間任務調度等操作是否正確;

3)CIO可不按照常規的順序執行功能操作，查看系統計算的準確性，如倉庫歷史庫存、當前庫存、貨位庫存是否準確;

4)驗證實體關系，實體間的關系有三種：一對一，一對多，多對多。如一個MPS對應多個MRP，一個MRP對應多個車間任務，CIO對此檢驗，看能否對應;

5)執行正常操作，觀察輸出結果的異常性。如CIO刪除某條記錄對排序的影響，或執行審批后，單據的狀態是否改變，報表的打印輸出效果如何;

6)劃分等價類，提高測試效率。要劃分等價類，選擇有代表意義的少數用例進行測試，提高測試效率等等。

4、其它系統測試

除上述的系統測試外，CIO還有必要對系統的其他特性和需求加以測試，這些系統測試也很重要，主要有以下幾種：

1)負載壓力測試，主要包括并發性能測試、疲勞強度測試、大數據量測試和速度測試，一般采用自動化技術分別在客戶端、服務器端和網絡上進行測試;

2)恢復測試，通過模擬硬件故障或故意造成軟件出錯，檢測系統對數據的破壞程度和可恢復的程度;

3)安全性測試。通過非法登陸、漏洞掃描、模擬攻擊等方式檢測系統的認證機制、加密機制、防病毒功能等安全防護策略的健壯性;

4)兼容性測試。通過硬件兼容性測試、軟件兼容性測試和數據兼容性

測試來考察軟件的跨平臺、可移植的特性;

5)性能測試，性能測試主要是測試軟件的運行速度和對資源的消耗。

5、評估整個系統運行效益

作為信息部門的一把手，聰明的CIO應在項目合同上寫明系統試運行2-3月后再來驗收、付款的規定，以爭取主動。CIO的做法主要是錄入1-3月的企業相關經營數據進行核查，目的是利用此段時間來判斷系統上線運行后能給企業帶來哪些積極變化和成效--看它有無促使企業在管理思想、管理模式、管理方法、管理機制、管理基礎、業務流程、組織結構、規章制度、全員素質、企業競爭力、企業形象、科學決策和信息的集成與處理等方面發生一些明顯的改進、提高和創新;企業是否運用ERP系統對整個供應鏈管理中的各相關環節和企業資源實行有效的規劃和控制;通過財務模塊分析，企業在客戶關系管理、市場預測分析、加強財務管理、合理組織生產、資源優化配置、壓縮生產周期、降低物料庫存、減少資金占用、降低產品成本、提高產品質量、擴大市場銷售和實行電子商務等方面有無產生相應的經濟效益等。如果在這些方面，用戶感覺良好，表明系統運行成功，那CIO就可放心正式驗收、簽單付款了。

二、項目驗收的幾大注意事項

CIO把握、核檢了項目驗收4個主要過程了，并不表示萬事大吉，尚需對以下幾大事項高度重視，加以解決，以保證項目和驗收全面順利完成。

1、依據行業標準制定驗收規則。驗收是目前或許是一個比較模糊的概念，業內一直都沒有一個統一的標準，隨意性大。而這種“驗收的隨意性”對于用戶單位來說將是一個致命性的錯誤，產生此類問題的根源就在于CIO常不知道或根本就沒有制定合理的驗收標準，從而導致IT項目在驗收過程中，主次顛倒，忽視了對關鍵業務流程的驗收。因此，只有明確了相關系統項目的驗收標準，才會做到有備而來，從而達到驗收的目的。CIO一定要重新明確、制定每個階段驗收標準和項目總體驗收標準，時刻維護驗收的嚴謹性、權威性和準確性，必要時可請第三方咨詢顧問機構來幫忙把脈把關。

2、把握驗收的時間火候。一般而言，要根據軟件模塊的多少、系統涉及部門人員、投入費用的多少，CIO要在驗收時間上進行更多考量、把控，別急于收尾驗收。大型的ERP項目通常是邊實施邊驗收，一步一步地向前推進，以便一邊發現問題一邊解決問題，但中小型的ERP項目最好是成功切換后，錄入了一個月以上的數據，運行一個月時間，再來驗收。畢竟一個月才是一個小的系統周期，如果小的周期都沒有跑順，就更別說一年這樣的大周期了。如ERP系統能做到平穩運行兩個月以上，能夠準確導出各類月度報表的時候，系統應用和各項業務操作基本正常、順暢，通常而言，可認為系統已達到的效果或者是達到了先前預定的目標，系統項目上線成功了，驗收可算通過了。

3、建立有效的解決沖突機制。用戶、開發商在實施、驗收IT項目過程中難免會發生沖突，造成IT建設偏離軌道。關鍵是事先是否有明確的項目目標和項目要求，是否建立起有效的沖突解決機制。CIO主要是要明確今后雙方責權利關系，可對將來可能發生重大事件或不可抗拒事件所引發可能的實施超期、費用超支、產品價格調整以及服務收費超標等事項、行為及其權責做出預測，并有效約定，從而使信息化項目從一開始就按預定的規道行駛，避免再發意外。因此CIO要快速查找以前問題所在，既然上次合約沒有明確細節，也就意味著可以增加驗收內容，明確細節和進度，從合同中挑出對方的問題，與對方補簽合約，保證項目有效進行。建立解決沖突機制，是為了使驗收更好地執行。

第三篇：房地產項目周總結會議

唐霸華府2014年12月21日周日總結會議

唐霸華府的家人們下晚上好，大家辛苦了我代表公司、個人感謝大家。經過大家風雨無阻，不怕苦不怕累的戰斗精神，團結一心奮戰的精神，我們取得了初期的成績，好的宣傳效果，讓我們售房部來訪不斷。說明一份付出一份收獲。離我們認籌排號時間不多了。大戰在即讓我們拿出我們唐霸華府超人一般工作方法和能力去沖刺我們的任務和目標，俗話說得好，是好鋼你用在刀刃上，到了我們展現的時候了，我相信我們唐霸華府的每一個人都是好鋼，大家說是嗎？下面我們開會，一：先匯報一下本周任務完成情況，個人匯報，案場第一名獎勵紅包一個（50元）少完成一個任務樂捐20元。劉媛媛：任務

實際完成董

敏：任務

實際完成 楊

娜：任務

實際完成趙苗苗：任務

實際完成薛舒靜：任務

實際完成0

高

賽：任務

實際完成拓展部：任務

實際完成

二：定下一周任務，注：置業顧問或拓展部經理不許比上周任務少只許多。

劉媛媛：任務6

實際完成 董

敏：任務5

實際完成 楊

娜：任務3

實際完成 趙苗苗：任務3

實際完成 薛舒靜：任務1

實際完成 高

賽：任務1

實際完成 拓展部：任務17

實際完成三：置業顧問；拓展部經理發言總結本周工作。四：工作紀律確定，擺位接待紀律，執行劉媛媛。

五：暴風雨般的掌聲有請李經理和劉主管進行施行樂捐和發獎儀式，五：本周總結會結束，祝唐霸華府全體家人周末愉快，明天節氣冬至大家都記得吃餃子不然耳朵會凍呀。掌聲

2014年12月21日

第四篇：經驗談

2012，很特別的一年，世界末日并沒有打破所有考研學子的夢想，我也一樣，堅持到了最后一刻。我是2013年考華中師范英語學科教學的，考研這一年當中我最喜歡瀏覽的網頁就是考研論壇了，從這里了解到歷年華中師范的題型，還經常關注其他研友的備考心態。瀏覽考研論壇確實挺另人興奮的，每次都會有不一樣的收獲。很感謝考研論壇為所有的學子提供這樣一個平臺。以前在論壇了解了挺多東西的，經歷了一次考研，也了解到了一些華中師范英語學科教學的一些新動態，僅供給2014的學弟學妹參考。

英語學科教學是專業碩士，主要要考四門，政治，英語二，333教育綜合，833專業英語。政治大家都要考，所以比我有經驗的很多，所以不說了，英語二今年考得挺簡單的，也是國家統考，所以這些信息都比較好掌握。發這個帖主要是要說一下華中師范今年的333教育綜合及833專業英語。

333教育綜合，因為我剛開始什么都不懂，所以報了一個凱程酷考的全程班，花了1600多，可能確實有點多，但那時以為特別難，又不知道怎么動手復習，所以就急急忙忙地報了一個班，有沒有這個必要能，我覺得還是看個人吧，現在覺得教育綜合確實不難，如果自己能踏踏實實看書，真的問題不大。凱程酷考對我最大的幫助是它每個時間寄資料過來，分批寄過很多次，這不僅讓我復習有指導性，還讓我堅持到最后，當我每次收到資料時我都會特別有感覺，我知道我下一步該怎么做了，就是這種感覺讓我穩步前進。還有就是他們的資料確實很全，以前有學姐有前幾年的，但酷考今年跟凱程聯辦，所以2013年的資料增加了不少，擁有他們這些資料，自己踏踏實實看書基本上問題不大，雖然有大綱，有參考書目，但是我覺得凱程酷考的資料確實是最好的，今年333教育綜合感覺自己答得比較順利，其實這一年自己確實花了很多時間在這么功課上，但到考前我最怕考教育綜合，我總怕自己到了考場上什么都忘了，答不出來。如果真踏踏實實復習過來，真不用擔心，到了考場上以前背的全記起來了。教育學從大三下學期我就開始準備了，那時都在看那六本厚厚的書，還有大綱，還一邊聽凱程的基礎課程，看了挺久的，這是第一輪復習教育綜合。接下來就是暑期凱程強化班了，資料有大綱詳細解析和題庫了，十月份有個真題和專題，十一月份就是沖刺班，有沖刺資料考前必會題，掌中寶，還有模擬題7套。所以我說333教育綜合我資料最多，花的時間和錢也是最多的一門，不過還是挺有收獲的，不管結果如何，這一年都過得特別充實，考場上也還比較順利，也沒有追求太多，經歷也是一次不錯的選擇，選擇考研一點都不后悔。接下來說下今年333的題型吧，今年題型有點變，15題選擇題，挺簡單，4個名詞解釋，4個簡答，3個論述題。名詞解釋：體育，白版說，形成性評價，還有一個忘了。簡答：教育的文化功能，人格發展規律，朱子讀書法，教師教育素養。論述題：舉例說明啟發誘導原則的基本要求，陳鶴琴的活教育論，加德納多元智力理論。就是這些題型了。

今年感覺最難的就是833專業英語了，題型有點變動，而且感覺比前兩年的更難點，以前的單選蠻簡單的，今年有點難。今年備考當中確實用在專業英語上的時間比較少，因為沒有指定的書目，不好準備，也不知道怎么準備，所以感覺有點難。先說下題型吧，單選20個，以前的是老六級單選，今年基本上不存在了；然后是改錯，兩篇閱讀理解；接下來是完型填空，自己填單詞，沒選項，有點難；下一個題型是true or false,基本上語言學的，這個題型經常變，以前考縮約詞，歧義句，名詞解釋，之前我都是準備這些的，所以真不好準備，真不知道明年老師又出什么題目。接下來就是有關教學法的翻譯了，不怎么難。最后一題是作文，沒怎么變，關于杜威的教學理論，總結評述一下，就是這些了，說怎么準備吧，每個人都有不一樣的方法，知道題型就自己找適合自己的方法，英語確實不好復習，不像教育綜合，怎么都不會超出這個界限。

第五篇：SAP實施Roll out項目經驗談（精選）

SAP實施Roll out項目經驗談

本系列文章主要討論在SAP實施Roll out項目中需要注意的事項，包括思路與項目管理，技術細節與數據兩個部分。

本文討論項目實施實施的思路與項目管理方面。

Roll out項目，本身在很多方面不同于全新的實施項目。它在很多方面受制于Global的實施思路和系統配置的影響。這種影響主要體現在以下幾個方面。第一，業務流程限制

與全新項目不同，Roll out項目的業務流程都是已經定好了的。實施的過程是一個把已有的業務流程復制到另一個子公司的過程。這就從根本上規定，業務流程實現方式必須以母公司為模板。尤其是跨公司交易的業務，公司間采購，跨公司銷售等，更是必須遵從母公司的流程。

第二，數據分類限制

全新的項目可以根據公司的需要去定制統計分析模板，關鍵數據，特征字段等，都可以自行設計；但在Roll out項目中，不可避免地要受到母公司統計分析要求的制約。比如物料類型定義，涉及統計分析的字段內容定義如客戶組，物料組等。CO模塊更是有很多定義好的結構，是必須要嚴格遵從不能更改的。第三，實施過程限制

全新的項目可以按照ASAP的方法論進行項目實施。但在Roll out項目里則不一定。根據簽訂合同內容的不同，實施的過程有可能會不同于全新項目。比如某個項目的Roll out合同規定，該Roll out項目必須完全拷貝母公司的流程，不允許有子公司個性化設置。在這種前提下，業務流程調研這一步的工作就幾乎被忽略了，實施重點只是業務實現和培訓。實施團隊的任務不是根據子公司的實際業務制定流程，而是主要負責把母公司的流程介紹給子公司，子公司嚴格按既定的業務流程操作。第四，法律法規限制

這一點在跨國公司roll out項目中尤其明顯。各個國家法律法規不盡相同，從而導致公司業務流程不完全相同，這是顯而易見的。比如稅種不同，海關規定不同，甚至業務操作模式不同。這些都要在Roll out項目中予以充分的考慮。第五，實施時間限制 一般來說，Roll out項目的實施時間都會比全新項目的實施時間短。常規的Roll out實施一般是三到四個月，而全新項目一般至少要六個月以上。

由于諸多類似限制的存在，我們在做Roll out項目時，要從項目實施思路的層次確立指導思想，在項目管理的層次嚴格落實。指導思想的正確是項目成功的前提。不要認為這是空話套話，象天朝官員講話一樣。事實上，指導思想絕對是項目實施中至關重要的一個環節。平時注意不到它，是因為它不大會出錯。一旦指導思想出了偏差，項目離失敗就不遠了。這一點適用于全新的項目和Roll out項目。第一，在母子公司之間確定主次。

各個企業結構不同，母公司對子公司的控制力度也不同。有些公司母公司控制力非常強，大權獨攬，相對于子公司來說，是我叫你干啥你干啥，沒叫你干的你就別干；另一些公司，相對松散，子公司相對擁有較大的自由度，除了關鍵問題，子公司具有“我說了算”的權力。在做Roll out項目的時候，確定公司間的這種主次關系是首要的任務。就本次實施任務來說，是子公司說了算，還是母公司說了算？這一點要在參與實施的各方之間達成共識。

在項目組織的架構上，如果以母公司為主，則項目經理應該是母公司的派出人員；在實施過程中，項目經理對子公司與項目相關的部分應該有相對較大的決定權。子公司項目參與人員更多的是被動的接受，而不是在某些需要做決定的有爭議的部分，指手劃腳。如果以子公司為主，則項目經理應該是子公司的人員，或者母公司派出人員。項目實施過程中更多地考慮子公司自身的業務，母公司已經設置好的流程等只是作為參照。曾經有一個項目，母子公司之間在這一點上沒有達成共識。母公司認為子公司應該以復制母公司現有流程為主，基本不考慮額外的需求。如果有困難要從流程改變上去解決；但母公司又沒有派出項目經理，甚至沒有人全程參與，僅僅依靠實施顧問方進行知識轉移，阻力之大可想而知。子公司參與人員沒有理性的期望值，對項目要求過高。這種項目注定是不成功的。可能不是失敗的，但最終效果一定是不理想的。第二，注重與母公司的溝通。

對于roll out項目來講，不僅僅要在項目內部進行溝通管理，而且要在項目與母公司之間進行順暢的溝通管理。項目組必須要建立項目與母公司順暢的溝通渠道。實施過程中，不可避免地會需要與母公司進行各方面的溝通。特別是有CR提出來時，如果遲遲得不到解決，會大大地拖延項目進行，也會嚴重影響到項目人員的積極性。

值得一提的是，不論是母公司為主，還是子公司為主，母公司一定要有熟悉項目的人參與到子公司的實施過程中來。一個熟悉原始項目的參與者帶來的效益，好過一堆文檔。相信大家對這一點是認同的。囿于時間，資金等限制，幾乎沒有什么項目能夠在文檔上做到與項目實際進程齊頭并進，保證文檔是最新最準確的。除非是一個專門以交付文檔為目的的項目。在這個前提下，原始項目參與者帶來的知識就顯得異常重要。而且，很多東西是無法寫在文檔中的，它只存在于人的大腦里。沒有原始項目人員的參與，roll out項目實施過程中，就只能不斷地通過電話郵件等方式與母公司聯系。這對項目進行的效率影響是相當大的。尤其是跨國公司，加上時差原因，溝通效果就更大打折扣。第三，適當降低期望值。

無論是在全新實施項目中，還是在roll out項目中，這一點都是相當重要的。如果客戶對項目的期望值過高，實施起來就會難度重重。優秀的咨詢顧問，應該知道如何幫助客戶建立適當的期望值。迫于簽單的壓力，銷售人員往往會有意無意地夸大系統的功能，給后來的實施埋下隱患。顧問進場后，很重要的一個任務就是要管理客戶的期望值。

尤其是在roll out項目中，要先給客戶定下調子，這個項目不可能有很多的自由度，或許有很多實際的業務流程無法在系統中滿足，只能通過更改現有的操作習慣的方式來解決實際問題。在數據分類，跨公司業務等涉及到全球模板的方面，要想更改是很不容易的，除非有特別的理由。

當客戶對系統能夠實現的功能有了較為合理的定位時，項目推進過程中就會避免很多抱怨。客戶的主要精力才會由壓迫顧問做事，轉向自我改良去適應全球模板要求。

這并不是敷衍客戶。全球模板之所以能被推廣，一般來說不會有什么根本性的缺陷。某個子公司的特殊需求，經過認真分析，大部分可以在全球模板中找到解決的方案。第四，給予培訓工作更多的重視。

對于全新的項目來講，事前的流程討論，業務藍圖的設置，需要用去很多的時間。這部分的工作做得越仔細，越認真，后續的系統實現和測試等就會越順利。而在這整個過程中，關鍵用戶都是全程參與的，無形之中他們已經學習了很多系統知識。同時，由于項目時間久，關鍵用戶對系統的了解是由淺入深逐步進行的，會有時間去消化所學到的內容，后來的操作培訓就會相對容易一些。

但對于roll out項目來講，流程討論部分其實是全球模板的介紹，僅對不符合實際業務的部分進行討論和定義。由于時間短，關鍵用戶沒有太多的時間去理解系統的邏輯，對他們不可避免地要實行填鴨式培訓，效果也相對差一些。常常是學了前面忘了后面。另一方面，由于系統功能已經經過原始項目的完整測試，一般來說在測試過程中出現的問題也少一些，關鍵用戶通過測試發現問題，了解問題出現的原因的過程中，學到的知識也會相對較少。由此，培訓工作在roll out項目中就要占據更大的比重。第五，整理數據時注意全局性。一般來說，roll out項目整理數據時，母公司的系統已經運行了一段時間。在數據的分類上，數據標準上，都已經有了現成的標準。更有許多物料供應商客戶等數據，是母公司系統中已經存在的。因此在數據搜集和整理的過程中，要特別注意這一點。要過濾母公司已經存在的數據，新的數據定義，分類要與母公司保持一致。

從項目管理角度來說，要想避免冗余數據或者錯誤定義，應當由母公司對數據進行檢查。但往往這是一個不可能的任務。因此，顧問應該對數據搜集投入一定的精力。這里又有一個矛盾。一般來說，數據搜集是客戶的任務，顧問只提供模板，不參與實際的搜集整理過程。我認為，這是一個很不好的現象。數據是SAP系統運行的基礎，如果數據做不好，系統的運行就不會令人滿意。顧問作為系統專家，應該參與到數據搜集當中去。最好是在項目合同中就明確，顧問應該參與數據搜集整理，當然，咨詢公司因此要得到一定的報酬。還要界定責任，顧問應當主動檢查用戶數據，并提出專業的意見。事實上，客戶在搜集數據的過程中，也經常會向顧問請教。但是主動的參與和被動的指導，其效果肯定是大不一樣的。這一點，不論是全新項目還是roll out項目都適用。第六，上線切換注意關聯交易。上線時的切換工作方面，roll out項目和全新項目有一些不同。主要體現在跨公司業務方面。在子公司上線時，母公司往往已經運行了一段時間，且與子公司有業務往來。未清的跨公司交易業務如何處理？這是在roll out項目中要考慮的。在全新的項目中則不必考慮這一點，只需考慮到對客戶，對供應商的未清業務即可。而公司間交易與外部客戶和供應商顯然有不同之處。

總之，roll out項目不同于全新項目，在項目管理的指導思想上，項目經理要區別對待，針對性地加強對相關環節的控制。

上一篇談到roll out項目的實施主體思路及項目管理方面要注意的事項，本篇著重談技術與數據方面的問題。

技術方面，由于上篇所講到的諸多限制，與全新的項目也有所不同。本人只在后勤方面有所了解，因此只能簡單談一下后勤方面配置的注意事項。總的來說，就是要注意在做系統配置的時候，不要忽視了已經存在的東西。有些配置或許在原始項目中已經做了，而且不是使用的標準設置，在做roll out項目的時候就要特別引起注意，不要因為roll out把母公司的業務給攪亂了。

技術方面的問題不能分門別類地談，比較零亂，只能說一點是一點了。1.語言問題。

尤其是在跨國roll out項目中，一定要注意語言的問題。比如，在國家設置中，如果選定了語言，則在發往別國的采購單上，國家代碼是以本國語言顯示的。如果實際業務中不能做成這樣，國家代碼里就不要去選這個語言，讓系統根據登錄的語言自動確定即可。

再如，采購單的form，是有多種語言的。如果要拷貝出來更改的話，一定要注意拷貝多種語言。只在一種語言下拷貝，有可能導致其他語言下的采購單出問題。2.數據分類

著重談一下物料類型。在roll out項目中，很多都會涉及到公司間交易。不論是跨公司銷售，還是公司間采購，如果這種公司間交易是采用系統標準的模式來做，都會涉及到同一個物料編碼在多個工廠之間應用的問題。這時，一個物料是什么物料類型就成為一個很重要的問題。物料類型里有獲取類型的限制。比如ROH的物料一般是只允許外部采購，不允許自制的。而在公司間交易時，往往在這個工廠是原材料的東西，在另一個工廠應該是成品。這時候，如果把它設置為原材料物料類型，在另一個工廠就無法做生產了。物料類型里也有視圖控制。HAWA里是沒有工作計劃的視圖的。如果某個工廠向另一工廠采購物料后直接銷售，往往會把它設置為HAWA類型。但是在另一個工廠，它就是自制品，需要生產的。

諸如此類的問題往往會導致物料類型分類方面的麻煩，需要特別加以注意。3.采購批準策略

如果原始項目中沒有使用批準策略，而在roll out的時候，子公司需要使用的話，要注意特性設置上用公司代碼或者采購組織等區分開來，而不能簡單地使用一個單據類型實現這個功能。

4.物料特殊獲取類型

在MRP2視圖里有一個字段叫作special procurement type。這里可以定義物料在另一工廠生產。象這種涉及到公司間交易的字段要著重加以確認。5.輸出條件記錄

要記得用MN*去維護各種輸出的條件記錄。尤其在跨國公司中，要注意維護出口稅條件類型。

6.在基礎數據的設置中注意國家的正確維護

比如shipping piont的國家設置，有時候直接從原始項目中的某個拷過來了，改的時候只注意地址細節之類，沒有注意到國家是不同的。這個是很容易忽略的。因為國家這個概念太大了，一般不會去理會它。在跨國公司roll out時尤其要注意。7.EDI配置

在roll out項目中，有時會用到公司間交易。公司間交易的發票自動入賬可以通過EDI實現，所以要注意EDI的相關配置。8.稅碼設置

SAP有個專門的notes來說這個事情。跨公司銷售時，在F2類型的發票上，稅碼是如何確定的呢？可以由出貨工廠和客戶所在國家來確定，也可以由銷售組織和客戶所在國家來確定。默認是前一種。如果要用后一種，要手工把notes打上。9.ERS的使用

在原始項目中，一般只有外部供應商，不會啟用ERS功能。但在roll out項目中，有可能會使用ERS，因為內部供應商一般來說是可信任的。10.GR-Based IV 原始項目中一般都要啟用基于收貨的發票校驗。但在公司間交易中，有可能會使用基于PO的發票校驗。尤其是在使用公司間采購流程同時使用EDI傳送發票時，最好使用基于PO的發票校驗。這樣在發貨方發貨做Billing之后，對方可以立即入賬。如果啟用基于收貨的發票校驗，則因為還沒有做收貨，會出現無法過賬的IDOC。11.MRP的運行范圍

多個工廠聯合運行MRP，在roll out項目中可能是經常遇到的。要注意修改相關的配置。12.Client層級的字段選擇

比如物料主數據，供應商主數據，inforecord等，都有client層級的或者事務代碼層級的字段選擇設置。在改動這一類設置的時候，一定要小心。本人曾經改動過一個物料主數據的設置，為了針對某個工廠設置某個字段，把原始項目的相關字段組全部改為工廠級，還原為原來的設置，只把需要的工廠下的該字段屬性做了改動。最后卻發現考慮不周，影響了其他已經上線的公司，造成了很不好的影響。技術方面和數據方面，需要注意的地方很多。本文只是列出一些本人所了解到的一小部分而已，希望能夠起到拋磚引玉的作用。