1. MRP到MRP2到ERP到MES為什麼是逐步發展的
轉載，供參考。
軟體開發項目進度控制
一、影響軟體開發項目進度的因素
要有效地進行進度控制，必須對影響進度的因素進行分析，事先或及時採取必要的措施，盡量縮小計劃進度與實際進度的偏差，實現對項目的主動控制。軟體開發項目中影響進度的因素很多，如人為因素、技術因素、資金因素、環境因素等等。在軟體開項目的實施中，人的因素是最重要的因素，技術的因素歸根到底也是人的因素。軟體開發項目進度控制常見問題主要是體現在對一些因素的考慮上。常見的問題有以下幾種情況：
1、80-20原則與過於樂觀的進度控制
80-20原則在軟體開發項目進度控制方面體現在：80％的項目工作可以在20％的時間內完成，而剩餘的20％的項目工作需要80％的時間。這個80％的項目工作不一定是在項目的前期，而可能是分布在項目的各個階段，但是剩餘的20％左右的項目工作大部分是在後期。所以軟體開發在進入編碼階段後會給人一種「進展快速」的感覺，使得項目經理、項目團隊成員、用戶以及高層領導產生了過於樂觀的估計。有些領導看到軟體交付給用戶了，就一塊石頭落地「總算交差了」，同時又可能撤出一些被認為不必要的人力資源。但很多情況下這是為了對付用戶不合理的交付期限要求而採用的不得已的措施。這樣的結果是拖延了後期的工作，同時如果軟體還不成熟的話，會給用戶造成不好的影響。
2、范圍、質量因素對進度的影響
軟體開發項目比其他任何建設項目都會有更經常的變更，大概是因為軟體程序是一種「看不見」又「很容易修改」的東東吧，用戶是想改就改，造成需求的蔓延，項目經理有時還不知如何拒絕，加上要說「我能」的心理因素，一般都會答應修改。這樣集少成多，逐漸影響了項目進度。
如果某項工作在進度上表面上達到目標了，但經檢驗其質量沒有達到要求，則必然要通過返工等手段，增加人力資源的投入，增加時間的投入，實際上是拖延了進度。不管是從橫向或縱向來看，部分任務的質量會影響總體項目的進度，前面的一些任務質量中會影響到後面的一些任務質量。
3、資源、預算變更對進度的影響
資源，最主要的還是人力資源，有時某方面的人員不夠到位，或者在多個項目的情況下某方面的人員中途被抽到其他項目、或身兼多個項目、或在別的項目不能自拔無法投入本項目。還有一個很重要的資源，就是信息資源，如某些國家標准、行業標准，用戶可能提供不了，而是需要去收集或購買，如果不能按時得到，就會影響需求分析、設計或編碼的工作。其他資源，如開發設備或軟體沒有到貨，也會對進度造成影響。
預算其實就是一種資源，它的變更會影響某些資源的變更，從而對進度造成影響。
4、低估了軟體開發項目實現的條件
低估軟體開發項目實現的條件表現在低估技術難度、低估協調復雜度、低估環境因素這樣幾個方面。
首先是低估技術難度。軟體開發項目團隊成員，有時甚至是企業的高級項目主管也經常低估項目技術上的困難。低估技術難度實際上也就是高估人的能力，認為或希望項目會按照已經制定的樂觀項目計劃順利地實施，而實際則不然。軟體開發項目的高技術特點本身說明其實施中會有很多技術的難度，除了需要高水平的技術人員來實施外，還要考慮為解決某些性能問題而進行科研攻關和項目實驗；
其次，低估了協調復雜度，也低估了多個項目團隊參加項目時工作協調上的困難。軟體開發項目團隊成員比較強調個人的智慧、強調個性，這給項目工作協調帶來更多的復雜度。當一個大項目由很多子項目組成時，不僅會增加相互之間充分溝通交流的困難，更會增加項目協調和進度控制上的困難。
另外，企業高級項目主管和項目經理也經常低估環境因素，這些環境因素包括用戶環境、行業環境、組織環境、社會環境、經濟環境。低估這些條件，既有主觀的原因，也會有客觀的原因。對項目環境的了解程度不夠，造成沒有做好充分的准備。
5、項目狀態信息收集的情況
由於項目經理的經驗或素質原因，對項目狀態信息收集的的掌握不足，及時性准確性完整性比較差。另外其它一些原因也會造成這種現象。某些項目團隊成員報喜不報憂，不希望別人知道自己工作的不好的情況，例如軟體程序的編制，可能會先編制一些表面的東西，現有界面，看起來好像完成任務了，實際上只是一個「原型系統」或演示系統。給領導造成比較樂觀的感覺。
如果項目經理或者管理團隊沒有及時地檢查發現這種情況，將對項目的進度造成嚴重的影響。當然，如果出現這種需要時時刻刻都互相提防的氛圍，管理人員就應該從管理的角度，從制度的角度檢討一下，進行改進，讓大家實事求是地進行溝通。溫伯格說:「無論你多麼聰明，離開了信息，對項目進行成功的控制就是無源之水、無本之木。」
6、執行計劃的嚴格程度
沒有把計劃作為項目過程行動的基礎，而是把計劃放在一邊，比較隨意去做。例如對於項目團隊內部溝通或外部溝通，在計劃中要說明清楚人員、周期、方式、方法，不能遺漏，但在實際項目過程中，可能出現溝通沒有按時或沒有完整地達到所有項目干係人的情況。若項目計劃本身有錯誤，執行錯誤的計劃肯定會產生錯誤。如，計劃制訂者在計劃系統框架設計考慮上的錯誤、進度安排上的失誤等。實際的項目實施中，除了這種錯誤之外，還可能因為項目執行上的錯誤，造成項目的麻煩。例如，項目的客戶及其他項目干係人沒有及時為項目中出現的情況採取必要的措施或者所採取的措施的不適合具體的情況、沒有效果或者有副作用等。另外，如果在項目中的某項工作（如某個子系統或模塊、組件）被轉包給第三方開發後，不能進行有效的管理，也會造成進度上的延誤。
7、計劃變更調整的及時性
漸近明細是項目的特點，特別是對於軟體開發項目，並不是一個一成不變的過程。開始時的項目計劃可以先制定得比較粗一些，隨著項目的進展，特別是需求明確以後，項目的計劃就可以進一步的明確，這時候應該對項目計劃進行調整修訂，通過變更手續取得項目干係人的共識。計劃應該隨著項目的進展而逐漸細化、調整、修正。沒有及時調整的計劃或者是隨意的不負責任的計劃的項目是難以控制的。在高技術行業，日新月異是主要特點，因此計劃的制定需要在一定條件的限制和假設之下採用漸近明細的方式，隨著項目的進展進行不斷細化、調整、修正、完善。對於較為大型的軟體開發項目的工作分解結構可採用二次甚至多次 WBS 方法。即根據總體階段劃分的總體 WBS ，需求調研階段結束、概要設計完成後專門針對詳細設計或編碼階段的二次 WBS 。由於需求的功能點和設計的模塊或組件之間並不是一一對應的關系，所以只有在概要設計完成以後才能准確地得到詳細設計或編碼階段的二次 WBS ，根據代碼模塊或組件的合理劃分而得出的二次 WBS 才能在詳細設計、編碼階段乃至測試階段起到有效把握和控制進度的作用。有些項目的需求或設計做得不夠詳細，無法對工作任務的分解、均衡分配和進度管理起參考作用，因此要隨著需求的細化和設計的明確，對項目的分工和進度進行及時的調整，使項目的計劃符合項目的變化，使項目的進度符合項目的計劃。
8、未考慮不可預見事件發生造成的影響
假設、約束、風險等考慮「不周」造成項目進度計劃中未考慮一些不可預見的事件發生。例如軟體開發項目還會因為項目資源特別是人力資源缺乏、人員生病、人員離職、項目團隊成員臨時有其他更緊急的任務造成人員流動等不可預見的事件對項目的進度控製造成影響（即項目按時完成是基於如下假設：人力資源不會缺乏、人員不會生病、人員不會流動）。企業環境、社會環境、天災人禍等事件對項目的進度控製造成影響。對項目的假設條件、約束條件、風險及其對策等對於進度的影響在項目計劃要進行充分的考慮，在項目進展過程中也要不斷地重新考慮有沒有新的情況，新的假設條件、約束條件、潛在風險會影響項目的進度。假設是通過努力可以直接解決的問題，而這些問題是一定要解決才能保證項目按計劃完成；約束一般是難以解決的問題，但可以通過其他途徑迴避或彌補、取捨，如犧牲進度、質量等等；假設與約束是針對比較明確會出現的情況，如果問題的出現具有不確定性，則應該在風險分析中列出，分析其出現的可能性、造成的影響、採取的措施。實際上像沒有考慮人的疾病、人員流動這些情況本身也不是什麼問題，因為任何人都不可能把所有以外的情況都考慮完整，實際上也沒有必要。但有些諸如下班或節假日的加班時間都被安排用於項目工作的情況就會造成更多的項目不確定性。在可能的情況下當然要對所有可能情況都做到有備無患，但是有的時候也要冒一定的風險，同時對於風險的防範也需要考慮如果防範的成本大於風險本身造成的損失和影響，則這種防範是沒有必要的。
9、程序員方面的因素對進度的影響
程序員方面有兩種常見的心態影響了進度的控制：一是技術完美主義、二是自尊心。
技術完美主義的常見現象是，有些程序員由於進度壓力、經驗等方面的原因，會匆忙先做編碼等具體的事情，等做到一定程度後會想到一些更好的構思，或者看到一些更好的技術的介紹，或者是覺得外部構架可以更加美化，或者是覺得內部構架可以更加優化，這樣他們會私下或公開對軟體進行調整，去嘗試一下新的技術。而是否使用這些新的技術對完成項目本身的目標並沒有影響，相反可能帶來不確定的隱患。這種做法不是以用戶的需求為本、或以項目團隊的總體目標為本，可能對軟體開發進度造成較大的影響。
自尊心的常見想像是，有些程序員在遇到一些自己無法解決的問題時，傾向於靠自己摸索，而不願去問周圍那些經驗更為豐富的人。有些人也許會通過聊天室等方式匿名地向別人求教。如果運氣好會很快地解決，否則要花很多實踐摸索。而如果向周圍的人求教，可能摸索幾天的問題別人早就解決了。
10、未考慮軟體開發過程的循環、迭代特性
對軟體開發的各個過程分類過於精細，制定進度計劃時各項工作過於緊湊、沒有彈性，造成的後果是，定期提交項目進度階段報告的制度只有在表面上起到效果，按照計劃的時間表提交階段成果也只是在表面上起到效果。因為「上有政策、下有對策」，強行的規定會使人產生一些錯誤的認識：如在項目計劃中「規定」某個時間只能做某某類別的事情，那麼嚴格執行的後果就是編碼階段就不能修改文檔；另外錯誤的「里程碑」概念可能會使大家輕易地相信上一個階段的工作成果都是「通過評審」最終定稿了，而實際上可能只是因為時間到了該提交的人提交、該評審的人評審了。如果上下階段是不同的人就根本不會去檢查其中是否還有錯誤；如果上下階段是同一個人，就可能非正式地修改上一階段的錯誤，但佔用的時間和精力卻是下一階段的，並且這樣的修改時沒有記錄的。這樣關於階段進度控制的措施實際上只是在表面上有效。最為普遍的情況是，用戶在合同中限定了提交軟體系統的時間，實際上這個時間對完成項目任務來說是遠遠不夠的，但計劃只能按照合同來進行，所以要不用戶讓步，要不只能按照時間的約定提交實際上還未完成的軟體系統，完成系統的安裝，但這時候的「完成階段任務」只是一個表面現象，系統雖然安裝了，但可能是沒有經過嚴格徹底測試的，也可能是只完成了部分的功能，省略了某些功能，有些是整塊功能省略，有的是省略了某些功能的某個過程，如數據錄入裡面隱含的數據錄入前預設值設置、數據錄入檢驗等功能，而是實現了比較粗糙的功能。這樣，系統交付並不意味著項目的完成，而在項目交付之後還要花更多的時間。
11、其他因素
以上這些因素是影響項目進度的幾個主要方面，除此之外還有很多其他的影響因素。其實最主要的因素還是人的因素，這里的人包括所有與項目相關的人。項目經理的素質、管理者的水平、用戶的因素、項目成員的因素等等，都會對項目進度造成影響，這是因為由於軟體開發的特性。因為篇幅有限無法一一列舉，只能在此分析一些常見的因素。
不可否認，軟體開發項目進度可控性還是帶有一定運氣成分的。特別是需要用戶配合的那些軟體開發項目，其可控性與用戶的成熟度、軟體應用領域的成熟程度和行業標准規范的完備程度有很大關系。關於可控性方面會涉及到一些與客戶打交道經驗，雖然我們說，顧客是上帝、以顧客為中心，但並不是說我們要把主導權交給他們，而關鍵是我們如何去主導、引導、把握。因此，項目控制的好壞與相關人員人際關系方面的經驗也有關系。
盡管存在很多不可控的因素，我們的任務是首先分清哪些是可以控制的，哪些是我們不能控制的。項目經理一是要盡量擴大可控的領域，減少不可控的領域，二是不要在「不可控」上花太多時間，而是多花一些時間把可控的工作控制好，做好防範措施，減輕不可控因素對項目進度的影響。
項目進入實施階段後，項目經理的幾乎所有的活動都是圍繞進度展開的。進度控制的目標與成本控制的目標和質量控制的目標是對立統一的關系。項目的進度、質量和成本構成一個相互制約的三角關系，需要項目經理去平衡。
二、項目進度控制的目的
項目進度控制和監督的目的是：增強項目進度的透明度，以便當項目進展與項目計劃出現嚴重偏差時可以採取適當的糾正或預防措施。已經歸檔和發布的項目計劃是項目控制和監督中活動、溝通、採取糾正和預防措施的基礎。
1、根據計劃進行監控
項目控制的第一個目的是根據計劃對項目的各項活動進行監控，即根據已經制定並取得共識的軟體開發項目計劃來監控項目的實際表現和進度。為此應該根據項目計劃來監控項目計劃參數的實際值，這些參數包括進度表、項目成本、工作量、工作產品和任務的屬性、使用的資源、項目成員的知識和技能；根據項目計劃來監控項目團隊所作的承諾是否已經或可能兌現、原來的確定的風險是否可以避免或減少損失，是否有新的風險出現；根據項目計劃來收集、管理、使用項目數據；根據計劃監督項目干係人的參與情況，監控各項任務承擔人的參與活動；定期進行必要的進度評審，確定項目是否存在重大偏差、跟蹤變更請求和問題報告直到變更或問題得到解決；在項目的里程碑對項目的成果進行評審。
2、管理糾正和預防措施
項目控制的另外一個目的是管理糾正和預防措施，即當項目進度或者結果已經或即將與計劃有嚴重偏差時，對需要採取的糾正或預防措施進行管理。為此應當收集並且分析項目進行中可能存在的問題，並以此確定解決這些問題的糾正或預防措施；對已經確定的問題採取糾正和預防措施；監控要實施的糾正和預防措施，分析措施採取以後的結果，判斷這些措施的有效性，確定和記錄糾正與計劃結果存在偏差的問題而採取的必要且合適的措施。
項目執行過程中僅僅靠最初建立的一份「完善」的基準計劃是不夠的，最好的計劃也未必會一直有效。根據項目任務漸進明晰的特點，特別是軟體開發項目的特點，在項目進行過程中，肯定需要在適當和必要的時候對項目進行變更控制，這種控制過程包括定期搜集有關項目進展情況的信息，把實際進展情況與計劃進展情況進行對比；如果實際進展情況比計劃進展情況有差距，或可能會有差距，就應當採取糾正或預防措施。變更控制應當在項目期間定期進行，這里所說的變更控制不一定要進行真正的變更，而是說要定期對變更進行控制。
如果在項目生命周期內的某一時間點，把實際進度與計劃中約定的進度相比對，顯示出項目已經延誤或即將延誤、超出預算目標或不符合質量要求，就必須採取糾正或預防措施使項目回到正軌上來，重新符合計劃的安排要求。在已做出執行糾正或預防措施的決定之前，應評估一下糾正與預防措施的有效性和無副作用性，以確保糾正措施使項目回到項目的工作范圍、時間和預算約束內，並對項目的其他目標不會造成太大的影響。
3、在各種項目目標中進行平衡
如果經過評估確定項目確實已無法控制，就應當下定決心以犧牲軟體功能范圍、工作成果范圍（如某些中間文檔）、成本預算、進度計劃或軟體質量中的某一項目標為代價，來保住項目最重要的那些目標，在各種項目目標中進行平衡，最終確定一個最合適的解決方案。有效的項目控制的關鍵是定期及時測量實際進程，並與計劃進程相比較，如有必要就立即採取糾正或預防措施。指望不採取糾正和干預措施，問題就自行消失的想法是不現實的。問題越早發現就越好改正，造成的影響和損失越小。問題越提前發現就越好採取預防措施，可以用最小的代價避免造成損失。基於項目實際進展情況，就有可能准確預測項目進度計劃和成本預算的實施情況，以便順利完成項目。如果這些項目參數超出項目目標的限制范圍，就必須馬上採取糾正措施；如果發現這些項目參數有超出項目目標的限制范圍的趨勢，就必須馬上採取預防措施。
軟體開發項目實施中進度控制是項目管理的關鍵，若某個分項或階段實施的進度沒有把握好，則會影響整個項目的進度，因此應當盡可能地排除或減少干擾因素對進度的影響，確保項目實施的進度。
三、軟體開發項目常用進度控制措施
1、項目進度控制的前提
項目進度控制的前提是有效地項目計劃和充分掌握第一手實際信息，在此前提下，通過實際值與計劃值進行比較，檢查、分析、評價項目進度。通過溝通、肯定、批評、獎勵、懲罰、經濟等不同手段，對項目進度進行監督、督促、影響、制約。及時發現偏差，及時予以糾正；提前預測偏差，提前予以預防。
在進行項目進度控制時，必須落實項目團隊之內或之外進度控制人員的組成，明確具體的控制任務和管理職責。要制定進度控制的方法，要選擇適用的進度預測分析和進度統計技術或工具。要明確項目進度信息的報告、溝通、反饋、以及信息管理制度。
項目進度控制應該由部門經理和項目監控人員共同進行，之所以需要部門經理參與，是因為部門經理負責項目一般要負責一定人事行政的責任，如成員的考核、升遷、發展等。他們只有通過軟體開發項目才能更好地了解項目成員，項目也只用通過對他們有切身利益的管理者參與管理才會更加有效。
2、項目進度控制主要手段
項目計劃書：作為項目進度控制的基準和依據，項目負責人負責製作項目計劃書。項目進度監控人員根據項目計劃書對項目的階段成果完成情況進行監控，如果由於某些原因階段成果提前或延後完成，項目負責人應提前申請並做好開發計劃的變更。對於項目進度延後的，應當分析產生進度延後的原因、確定糾正偏差的對策、採取糾正偏差的措施，在確定的期限內消除項目進度與項目計劃之間的偏差。項目計劃書應當根據項目的進展情況進行調整，以保證基準和依據的新鮮性、有效性。
項目階段情況匯報與計劃：項目負責人按照預定的每個階段點（根據項目的實際情況可以是每周、每雙周、每月、每雙月、每季、每旬等等）定期在與項目成員和其他相關人員充分溝通後，向相關管理人員和管理部門提交一份書面項目階段工作匯報與計劃，內容包括：
a、對上一階段計劃執行情況的描述
b、下一階段的工作計劃安排
c、已經解決的問題和遺留的問題
d、資源申請、需要協調的事情及其人員
e、其他需要處理的問題
這些匯報將存檔，作為對項目進行考核的重要材料。
在計劃制定時就要確定項目總進度目標與分進度目標；在項目進展的全過程中，進行計劃進度與實際進度的比較，及時發現偏離，及時採取措施糾正或者預防；協調項目參與人員之間的進度關系。
在項目計劃執行中，做好這樣幾個方面的工作：
檢查並掌握項目實際進度信息。對反映實際進度的各種數據進行記載並作為檢查和調整項目計劃的依據，積累資料，總結分析，不斷提高計劃編制、項目管理、進度控制水平。
做好項目計劃執行中的檢查與分析。通過檢查，分析計劃提前或拖後的主要原因。項目計劃的定期檢查是監督計劃執行的最有效的方法。
及時制定實施調整與補救措施。調整的目的是根據實際進度情況，對項目計劃作必要的修正，使之符合變化的實際情況，以保證項目目標其順利實現。由於初期編制項目計劃時考慮不周，或因其他原因需要增加某些工作時就需要重新調整項目計劃中的網路邏輯，計算調整後的各時間參數、關鍵線路和工期。
3、進度控制內容
從內容上看，軟體開發項目進度控制主要表現在組織管理、技術管理和信息管理等這幾個方面。組織管理包括這樣幾個內容：
（1）項目經理監督並控制項目進展情況；
（2）進行項目分解，如按項目結構分，按項目進展階段分，按合同結構分，並建立編碼體系；
（3）制訂進度協調制度，確定協調會議時間，參加人員等；
（4）對影響進度的干擾因素和潛在風險進行分析。
技術管理與人員管理有非常密切的關系。軟體開發項目的技術難度需要引起重視，有些技術問題可能需要特殊的人員，可能需要花時間攻克一些技術問題，技術措施就是預測技術問題並制訂相應的應對措施。控制的好壞直接影響項目實施進度。
在軟體開發項目中，合同措施通常不由項目團隊負責，企業有專門的合同管理部門負責項目的轉包、合同期與進度計劃的協調等。項目經理應該及時掌握這些工作轉包的情況，按計劃通過計劃進度與實際進度的動態比較，定期向客戶提供比較可靠的報告等。
軟體開發項目進度控制的信息管理主要體現在編制、調整項目進度控制計劃時對項目信息的掌握上。這些信息主要是：預測信息，即對分項和分階段工作的技術難度、風險、工作量、邏輯關系等進行預測；決策信息，即對實施中出現的計劃之外的新情況進行應對並做出決策。參與軟體開發項目決策的有項目經理、企業項目主管及客戶的相關負責人；統計信息，軟體開發項目中統計工作主要由參與項目實施的人員自己做，再由項目經理或指定人員檢查核實。通過收集、整理和分析，寫出項目進展分析報告。根據實際情況，可以按日、周、月等時間要求對進度進行統計和審核，這是進度控制所必須的。
4、不同階段的項目進度控制
從項目進度控制的階段上看，軟體開發項目進度控制主要有：項目准備階段進度控制，需求分析和設計階段進度控制，實施階段進度控制等這幾個部分。
准備階段進度控制任務是：向業主提供有關項目信息，協助業主確定工期總目標；編制階段計劃和項目總進度計劃；控制該計劃的執行；
需求分析和設計階段控制的任務是：編制與用戶的溝通計劃、需求分析工作進度計劃、設計工作進度計劃，控制相關計劃的執行等。
實施階段進度控制的任務是：編制實施總進度計劃並控制其執行；編制實施計劃並控制其執行等。由甲乙雙方協調進度計劃的編制、調整並採取措施確保進度目標的實施。
為了及時地發現和處理計劃執行中發生的各種問題，就必須加強項目的項目的協同工作。協同工作是組織項目計劃實現的重要環節。它要為項目計劃順利執行創造各種必要的條件，以適應項目實施情況的變化。
5、關於進度落後時的「趕工」措施
進度落後的情況下，有幾種措施來彌補，如加人、加班、加激勵等等，這些都是增加資源而又未必會見效的方法。根據Brooks原則，在某些項目進度延遲的情況下增加人手，有可能會使項目的進度更加延後。因為對於新加入本項目的員工來說，對項目相關背景、需求、設計的培訓、對項目環境的熟悉和項目團隊成員之間的溝通路徑的增加，可能會使項目的工作效率急劇下跌。而加班造成的疲勞會再次使工作效率降低。增加激勵會造成工作成本卻不斷的向上攀升。這些措施並不是完全不可取，而是項目經理要考慮適度原則。最好是要全面分析項目進度延遲的原因，如果確實是不合理的項目交付時限要求，就應當通過溝通變更為合理的項目時限要求，以免因為這樣一個不合理的時限要求造成對軟體質量或團隊成員心理上的負面影響，最終導致項目最終的失敗。否則應從技術、團隊成員心態、環境等方面查找原因，找到提高效率、加快進度的方法。
2. 怎樣才能成為一名成功的MES實施顧問
辛辛苦苦熬了幾個月的通宵，終於確立了MES需求，規范了工作流程，系統配置也完成了，正准備按部就班MES系統上線時，企業用戶突然改變了需求，不想這么做了，提出了新的需求。
對於MES實施顧問來說，正如晴天驚雷，這也是所有MES顧問最感到恐怖的事情。因為有時候，用戶只是簡單的一句話，但是對於系統的調整來說工作量是非常大的。
1、需求變更：遷就or拒絕?
從MES項目立項開始，需求就是MES實施顧問的心頭之痛。隨著對MES的深入認識、項目環境的變動，企業內外部多種因素都可能使客戶對MES的需求不斷改變。如果不能有效處理這些需求變更，項目實施進度必將一再調整，上線日期也會隨之一再拖延，項目成員的士氣也將越來越低落，嚴重的還會直接導致MES項目失敗。
需求變更，本應是客戶的權力，但也是實施顧問的為難之處。如果確需變更，當然要滿足客戶需要。問題是不能讓變更權力濫用，把一些無關痛癢的變更寵慣養成堂而皇之的變更。例如，我曾經在某MES項目中屬於「謙虛型」，對於客戶提出的變更，無論大小都給予解決，客戶對此非常滿意。然而，項目進度卻拖得很長，項目一再延期。相比之下，在另一個項目上我顯得稍有些「盛氣凌人」，對於客戶提出的需求變更，大多都不予理睬，客戶對此不是很滿意。不過，該項目的進度控製得較好，基本能按期完成項目。
按後一種「盛氣凌人」的做法，對客戶的要求一概不理，自顧自地按照最初的需求和計劃實施，很可能會由於沒有用戶的參與，使得MES系統與用戶的需求相差甚遠，導致驗收通不過，收不回尾款而使公司利益受損。對於客戶來說，達不到需求的滿足也浪費了投資。事實上，客戶不滿意，則項目就不算成功，實施顧問辛勤勞動最後就只能落得個「沒有功勞，只有苦勞」的份。
但按前一種「謙虛型」做法，完全順著客戶的意見走，客戶滿意度就一定會高嗎?其實也不一定。由於需求變更會帶來工作量的大量增加，甚至可能會出現大量的無效勞動。而且，頻繁變動的需求也會導致實施質量下降，留下許多隱患。因此，一味的遷就用戶將會使進度一拖再拖，實施方案一改再改，變更越來越多，士氣越來越疲，公司越來越不滿意，用戶越來越急。到最後，實施顧問會發現這個項目已經成為了一個「不可能完成的任務」。
2、需求變更為什麼總是做不完?
在MES實施過程中，實施顧問所要面對的將是一系列和多方面的考驗。經常發生而又最令人頭疼的恐怕就是需求變更了。客戶變更需求是MES項目與生俱來的特性，也是一個無法避免的事實。需求變更的表現形式是多方面的，如客戶臨時改變想法、項目預算增加或減少、客戶對功能的需求改變等。它會導致MES實施過程中成本增加、進度拖延等風險，而且越往後的變更產生的風險將越大。
以筆者參與的多個MES實施項目的實際經歷來看：需求變更泛濫是非常可怕的事，尤其是到了項目實施後期，客戶不斷對移交的MES系統提出修改意見，甚至有時剛剛重新完成的更改，客戶又要求改回去或改成另一種模式。需求變更越來越多，實施顧問只能疲於應付。「無底洞」是大部分實施顧問進行MES項目的共同感覺。
實施顧問作為項目的承擔者，在規定時間內利用有限資源保質保量的完成項目，讓客戶和公司都滿意是最終目標。但是讓客戶滿意就是不斷滿足客戶無窮無盡的需求嗎? 我們分析一下出現需求變更的根源：
① 合同簽訂馬虎，沒有真正明白客戶需求
簽訂合同時缺乏對客戶需求認真對待，導致需求描述不清，為後期的實施工作帶來困惑。MES銷售顧問為使客戶能夠快速的簽訂合同，往往草率決定和片面同意客戶提出的需求。當客戶提出新的需求時，往往是銷售顧問一看「應該」只是一個小小的修改，沒有太大的影響，所以直接答應能變更。
該問題的關鍵是合同簽署的太爛，沒有把需求明確再簽合同，而且也沒有把需求變更的流程寫入合同。如果在合同時把客戶需求弄清楚，後期就根本不需要頻繁的變更需求。簽訂合同時明確定義項目需求的范圍，可以為以後各項實施工作的開展奠定深厚的基礎。
② 研時沒有深入理解客戶需求
在MES上線前的需求調研分析階段，項目組成員和客戶的深入交流是減少頻繁需求變更的關鍵階段之一。但是由於雙方的誤解通常使需求交流難以進行。更嚴重的是，實施顧問只根據用戶提出的描述性、總結性的短短幾句話去制定實施方案，沒有真正挖掘和按客戶的需求去制定實施計劃。當客戶頭腦一熱或領導一拍腦袋提出新的需求時，實施顧問往往也就不能區分客戶真正需求和鍍金需求。如果項目組對客戶需求的細節了解不充分，雙方對需求的理解就會產生差異，就會導致移交MES系統時才使問題暴露出來，客戶只能頻繁的提出需求變更。
③ 沒有明確的需求變更管理流程
沒有明確的需求變更管理流程，就會使需求變更變得泛濫。並不是所有的變更都要修改，也不是所有變更都要立刻修改，需求變更管理的目的是為了決定什麼類型的變更需要修改和什麼時候修改。
比如MES界面風格問題，就可以先不修改，或者規劃一下修改的時間待到以後進行優化。另外，對於核心模塊的修改沒有嚴格把關流程，有些小需求看起來工作量不大，但是實際上實施顧問和開發顧問要耗費比較長的時間去完成這些銷售顧問或者客戶沒有考慮到的細節問題。
④ 沒有讓客戶知道需求變更的代價
對變更的影響沒有評估是需求變更泛濫的根本原因。變更都是有代價的，應該要評估變更的代價和對項目的影響，要讓客戶了解需求變更的後果。如果客戶不知道需求變更付出的代價，對實施顧問的辛苦就會難以體會。在評估代價過程中，可以請客戶一起做判斷：「我可以修改，但您能接受後果嗎?」。
3、如何有效控制需求變更?
需求變更對項目成敗有重要影響，既不能一概拒絕客戶的變更要求，也不能一味地遷就客戶，所以實施需求變更之前必須做好控制。例如授權、審核、評估和確認，在實施過程還要進行跟蹤和驗證。有句通俗的話說得非常好：「需求變更控制的目的不是控制變更的發生，而是對變更進行管理，確保變更有序進行。」
用戶需求的變更總是不可避免的，所以我們要以積極的心態去接受和控制用戶的需求，而不僅僅是埋怨。對待客戶頻繁的需求變更，應採取有效辦法應對，避免事態蔓延，不讓客戶養成隨意變更的毛病。
① 合同約束
需求變更給MES實施帶來的影響是有目共睹，所以在與用戶簽訂合同時，可以增加一些相關條款，如限定用戶提出需求變更的時間，規定何種情況的變更可以接受、拒絕或部分接受，還可以規定發生需求變更時必須執行變更管理流程。
雖然MES項目合同很難在簽訂之初就能夠精確定義每項需求，單靠合同是幫不上忙的，但也不能忽視合同的約束力。有一個笑話，就是許多銷售顧問都開玩笑說他們都是清政府。為什麼是清政府?清政府的特點之一就是喪權辱國的條約太多。
② 建立需求變更審批流程
要明確需求變更審批環節、審批人員、審批事項、審批流程等。目的有兩個：一是將客戶下達變更的流程盡可能地規范化，減少張嘴就來的非必要、非緊急、非合理、非高層領導意圖的「無效變更」。二是留下書面依據，為今後可能的成本變更和索賠准備好「變更賬」。凡未履行審批程序的「變更」，一律是無效變更不予受理。
有效的需求變更流程應該包括確認變更、評估變更的價值、分析變更對項目的影響，以及提交給雙方高層進行評價以確定是否執行變更。變更請求必須有書面材料，當用戶發現由於業務變化而引起的需求變更，需要提出書面申請。這樣對所有的變更，雙方的項目負責人都能做到心裡有數。而且用戶在遞交書面變更申請時比較慎重，一般都在內部經過討論後進行，這樣減少了因用戶內部看法不同導致的反復變更。
③ 對於零星變更，集中研究、批量處理
每周或每兩周甚至每月召開一次需求變更專題會議，集中研究處理這些零碎變更事項，主動控制好工作節奏，盡量避免由於處理零碎變更而影響項目運行的總體進度。例如向客戶正式提交一份各階段需求變更的完成計劃，註明變更引起的時間、成本、工期的代價和增加的工作量。要求客戶配合需求變更計劃，確定變更時限，控制變更規模，過時變更不候，離譜的變更不做，保大局棄小變。
④ 評估各種需求變更的影響
客戶的需求是永遠不會滿足的，可能一天一個樣,為了達到控制頻繁的需求變更。需要將需求變更後產生的成本進行評估與量化，形成分析報告提交雙方領導。否則，一味的妥協只會讓項目進一步惡化，實施顧問需要掌控客戶及公司的進度成本，把客戶的每一次需求變更進行成本分析。確認哪些需要收費變更，哪些可以免費配合客戶。這樣既可以維護客戶關系，又不致造成公司無謂的損失。
⑤ 確認客戶是否接受變更的代價
要讓客戶認識到變更都是有代價的，要和客戶一起判斷需求變更是否依然進行。例如，變更是沒有問題的，但是要明確客戶能否接受由此引起的如進度延遲、費用增加、效率下降等問題。一般來說，如果客戶認為該變更是必須的(不是其上級領導拍腦袋提出的)就會接受這些後果，通過與客戶的協商，項目組可能會得到回報或者即使沒有回報也不會招致公司和客戶雙方的埋怨。
如果客戶認為該變更雖然有必要但是可以暫緩，雙方簽署備忘錄後留待以後解決。如果客戶認為該變更可有可無，多數情況下會取消變更。這樣即可防止頻繁變更，也讓客戶認識到不是所有的需求都需要變更，更不是所有的需求變更都需要立刻修改。客戶一般對MES不甚了解，他們認為很簡單的事情，但可能解決起來會很復雜。以筆者的經驗來看，一般來說用戶的鍍金需求可以延期解決甚至不考慮。用戶的新增需求如果不是影響到核心業務的實現，也可以安排在現有功能的完善之後。
⑥ 每月變更記錄上報雙方領導
最後，實施顧問要將有關變更措施和記錄隨時抄報雙方最高層留檔備案，可採取簡報、文件、抄報、抄送、會議等多種形式。掌握主動權，逐步讓不合理的隨意頻繁變更，成為客戶不好意思開口的尷尬事件，盡快形成正常的項目執行氛圍和良好的工作習慣，也為可能受到變更所帶來的責任問題留下伏筆。
最後，要特別提醒，要在MES項目開始就對項目組和客戶進行宣傳和培訓，讓所有成員都理解變更控制的重要意義。
3. 用友系統ERP實施完了，為什麼還要做MES
ERP實施顧問是一種綜合技術知識和管理能力的職業，門檻高所以很多人進不來，但是只要能進來，在成長中一般都可以磨練出來，就是說ERP實施顧問的成長需要積累，需要在實踐中不斷完善和提高。 以下是對ERP顧問職業所具備的知識和能力結構的十大建議。 1、一定的計算機、網路技術基礎 身為ERP軟體實施顧問，你不能不了解你的產品，當然你可以了解得粗略，不必象技術工程師那樣精通，你要能夠回答客戶提出的大部分問 題，所以需要你掌握的知識非常綜合、全面——強調的是廣度而不是深度，當然，如果你的深度夠好，那麼會更加有利。如果你的深度不夠，經常回答不上客戶的問 題，沒關系，關鍵是你要留一個緩沖餘地，你要知道，你應該從哪裡獲得幫助和支持。優秀的ERP實施顧問，應該懂得如何調度資源。 以下為我認為ERP實施顧問應該掌握的技術： （1）ERP軟體本身，主流的管理軟體如用友、金蝶、SAP、甲骨文等。 （2）系統管理知識，包括WINDOWS 2003，UNIX。 （3）資料庫知識，包括SQL2005、ORACLE、DB2等等主流資料庫，SQL技能。細分可為查詢分析器的使用，數據表的操作，報表的基本技能等等。 （4）網路知識。網路協議配置、網路拓撲等。 （5）一定的硬體知識，如伺服器、交換機等。 2、ERP行業知識 管理信息化行業知識浩如煙海，沒有人可以掌握全部。把握好你的定位，你要了解全部的產品有什麼，但你要選定一個方向，在這方面成為專家。既要廣博，也要有自己的專精所在。 不要貪多，很多東西知道框架即可，用的時候懂得較快地搜索、查找出來即可。時間精力極為有限，有些東西要懂得放棄。 3、管理知識和項目管理知識 應當具備豐富的管理知識。要與客戶保持好關系，要有良好的服務意識。客戶管理層是項目推 進中最好的資源，一定要取得他們充分的信任和合作。如果你不了解管理知識，你難以讓客戶信服和接受。管理軟體之所以需要ERP實施顧問，就在於實施顧問能 夠通過資源調度使它具備生命力，沒有產品是盡善盡美的，但是一名盡責的、優秀的ERP實施顧問，卻可以彌補產品本身的不足。網路上管理知識應有盡有，只看 個人的吸收能力。另外的一個好的學習途徑就是客戶方管理人員，他們的管理經驗更有實效性。所以，在項目的實施過程中，我們事實上就可以學到很多管理知識。 這也是這項工作的誘惑和魅力之一。 作為ERP實施顧問，項目管理非常重要。要掌握基礎的項目管理知識，掌握項目管理常用的軟體工具。如果你是由技術工程師轉型而來，觀念上的轉變至為重要。 erp實施顧問不是替客戶做事，而是指導客戶做事。所以盡管你眼看著一個簡單的問題卻在客戶手中無法解決，禁不住著急，想要代做，也請你管住自己。牢牢記 住實施顧問的定位，不要混淆。事實證明，這是很多做慣了技術服務的工程師在轉型到實施顧問時的一個瓶頸。身為ERP實施顧問，你的專業化，恰恰是體現在 「項目管理」上面。項目管理的知識，可以充分利用互聯網，用BAIDU、GOOGLE去搜。 另外，一個ERP實施顧問，他是一個客戶和研發的中間人。那麼他就要給客戶設計方案時候，不但要滿足客戶的需要，而且要了解研發的難處實現的可能性。好的方案不但要了解系統還有了解行業。同時要了解研發的技術以及一些資料庫結構的設計以便同時為客戶、研發服務。 更重要的一點就是實施計劃的制定，考慮的客戶的迫切心理，和研發的實際進度。為了遷就客戶，計劃過於緊密，研發就會出現質量問題，反而不好。時常要降低客 戶的期望值，也是一種方式。同樣東西，研發都是3號提交，客戶希望5號，和客戶希望1號。當研發只能3號時候，最好能讓客戶答應5號。然後3號給他們。他 們會有意外驚喜，甚至覺得你為了提前2天做了，很多工作，可能在其他地方給你通融。 4、計算機專業英語水平 國際軟體廠商研發的ERP系 統，是用英文開發的，相關資料，尤其是最新的資料基本都是英文的，如果英語不靈，那真有點被動。就是本土軟體的顧問也應該學好專業英語，了解主要的國外廠 商產品，及時吸收外文最新知識，這對你是很有益的！不過英語不好的同學也不用著急，這里說的是專業英語，掌握計算機和管理領域的常用詞彙就基本可以滿足工 作需要了，當然懂的越多越好。 5、ERP實施顧問應有一個清爽整潔、職業化儀表。 要知道顧問基本上是一個服務性質的工作，必須得到客戶方的認可，必須讓人家喜歡和你相處。不修邊幅的人，不適合擔任ERP實 施顧問。你的氣質與風度，你能否征服你的客戶讓他們接受你，信任你，是項目順利進展的關鍵。曾有客戶講過，如果他們不接受實施顧問本身，也就難以接受實施 顧問帶來的一切。除了相貌，氣質，還有談吐。彬彬有禮、條理清晰、善於表達，是良好溝通的基礎。當然，自信心也很重要。而職業化，不僅僅是實施顧問的要 求，它是身在職場的人們都必須具備的常識。如果想在這方面得到提高，可以去買本公關禮儀方面的書或者查詢網站上的相關知識。另外可以多留心一下那些公認有 修養、善談吐人士的言談舉止，逐漸地養成習慣，固化下來。 6、不斷的學習新知識 上述幾條，不是獨立存在，而是相輔相成，技術、管理、企業業務流程，都需要不斷地學習。知識是日新月異的，必須與時俱進，活到老學到老，你往往需要在知識上走在客戶的前面，有時候你必須要向客戶學習，要學的東西永遠太多，所以想要成為一名優秀的ERP實施顧問，時間管理是必須要掌握的，如何合理的安排時間、有效利用時間是一門大學問，需要自己不斷探索、總結。唯有熱愛這個行業，對它感興趣，甚至到了吃飯、走路、坐車、如廁也常常思考相關的問題。 7、一定的運氣和機遇 機遇也是非常重要的，一定要善於尋找機遇，創造機遇，抓住機遇。 想要成為優秀的ERP顧問，需要一個漫長的過程，要多多用心，潛心體會，自然會有心得。常常要耐得住寂寞清靜。多付出，不要太在意回報。堅韌不拔，終將修成正果。優秀的實施顧問，前途必然是光明的。 8、職業發展路線 現在ERP實施顧問的職業發展前景被業界看好，未來五年管理信息化行業將需要5-6萬名ERP顧問，不僅大學畢業生想進入這個領域，很多職場人也很想轉型做ERP實施顧問。目前，大家共同的問題是這個領域要求綜合素質高，沒有相關經驗的人進入門檻是個問題！不過要是真的想在這個領域發展還是有機會的，用友集團成立了一個交用友管理軟體學院（.cn）的教育機構，專門為想進入ERP領域的人進行系統化訓練，解決門外漢的門檻問題，好的一點是他們是推薦就業的，畢業後大部分留在用友體系，一小部分推薦到用友的客戶單位，再提示重要的一點，入學他們是有面試和考核的，資質不好的是進不去的。 目前的情況看，有工作經驗的人轉型做ERP顧問更有優勢，可迅速升級做售前顧問、項目經理職位。以下是ERP顧問職業常見的職業發展路線。 1、初級實施顧問，中級實施顧問，高級實施顧問，實施總監，研發部總經理； 2、初級實施顧問，中級實施顧問，高級實施顧問，售前顧問，高級售前顧問， 銷售經理，銷售總經理 ； 3、初級實施顧問，中級實施顧問，企業信息化項目主管，信息總監（CIO）。 做ERP實施顧問是要經常出差的，但是在企業方做信息化項目很少出差，但是需要的知識結構和能力基本相同，部分ERP實施顧問（女性偏多一點）轉型到企業里發展，最後做到CIO的位置，也是一個不錯的職業發展路線。
4. 新韶光MES系統項目實施團隊的組建是什麼樣子的
一個完整的MES項目團隊，大體上會包含以下類型的人員：項目經理、業務顧問、系統架構師、開發工程師、實施工程師。
5. 想了解MES實施工程師工作內容，是否需要經常出差，頻率需要具備哪些能力
這是個很有抄前景的職業，需要比較強的綜合能力，
可以看看人家的招聘要求。
職責：
1、負責MES項目的業務調研、流程梳理、需求分析、詳細設計以及現場實施；
2、負責已實施MES項目的運維和技術支持；
3、負責完成項目實施過程中各類文檔、匯報材料的編制。
任職要求：
1、專科及以上學歷，機械、化工、自控、計算機等專業；
2、具有獨立工作和獨立解決問題能力，主動進取心和團隊合作精神；
3、具有良好的表達能力和溝通能力，善於引導客戶提出需求；
4、能適應長期出差；
5、熟悉MES軟體產品，具有3年以上MES項目實施經驗者優先；
6、熟悉工廠DCS控制系統、自控儀表、以及石油石化、煤化工、精細化工等行業生產管理業務者優先。
6. 我以前在化工廠做化工工藝，現在跳槽出來，公司安排去做外協，做MES實施工作。雖然做項目實施有出差補助
其實我倒是蠻喜歡你這MES的工作
7. 如何打造一個成功的MES系統
這個問題可以從兩個角度理解，即甲方和乙方。
從乙方的角度來理解，也就是如何開發出來一套成功的MES系統，這個話題很大，涉及到需求分析、產品設計、技術開發、產品測試以及運營推廣等一系列的事情。
從乙方角度能做到打造成功的MES系統，基本上就可以算是一個成功的創業了。
不過，我覺得這個問題的理解，可能更多是從甲方的角度，就是您可能是一家甲方的公司，你們要上MES系統，你們想要知道如何上一套成功的MES系統。
如果這個理解沒錯的話，根據我們跟很多企業實施MES系統的經驗，企業可以從以下的幾個層面來考量——如何打造一個成功的MES系統。
首先，要考量企業為什麼要上MES？企業是否適合上MES？
可以考慮以下這些個問題：
1 企業是否有上MES的明確的目的？
2 企業是否有上MES要解決的具體問題？
3 衡量MES系統成敗的指標是什麼？
4 企業對MES功能和性能是否有明確的考量？
5 企業是否有上MES配套的業務人員和IT人員？
這些問題的答案，決定了最後如何衡量MES是否成功，以及企業上MES是否具備必須的條件。
其次，企業明確上MES的目標，也確定了適合上MES，接下來就是要做好MES產品和廠商的選型。
MES產品和廠商的選型，也需要考量幾個方面：
1. 對MES系統選型在產品和技術上做衡量，包括：
1.1 產品上的功能滿足度
1.2 產品的易用性和良好用戶體驗
1.3 技術上的成熟性和穩定性
1.4 技術上的定製性和拓展性
1.5 技術上的先進性
2. 對備選MES系統廠商在案例上做考量，包括：
2.1 MES系統廠商是否有足夠多的案例？
2.2 MES系統廠商是否在相同或類似行業里有可參考案例？
3. 對備選MES系統廠商的資質做考量，包括：
3.1 MES系統廠商具備怎樣的資質？
3.2 MES系統廠商的財務運營狀況？
3.3 MES系統廠商受到的其客戶的評價？
3.4 MES系統廠商實施人員的數量、經驗？
3.5 MES系統廠商實施人員在相同或類似領域內的經驗？
選定了MES產品和廠商之後，接下來就是具體MES實施了，這其中更多的是項目管控的事情。
項目管控，一方面涉及到企業內部資源的管控，比如組建項目團隊，需要業務人員、IT人員等都參與到項目當中，並在項目的進展中推進進度、把控質量；另一方面涉及對MES廠商資源的管控，包括對MES廠商提供的項目人員的能力的評估，對於廠商項目進度的推進和管控，對於廠商提供同的產品和服務的把控。
項目管控的具體涉及的細分層面很多，比如進度、任務、費用、變更等等，詳細了解可以參考PMP的內容。
最後，整個項目的實施基本結束前，要對系統做評估和驗收。
根據項目開始時，確定的項目成功的標准，逐項的評估MES廠商提交的項目成果，判定是否滿足當初制定的成功標准；滿足則為合格，不滿足則需要限期整改，直到滿足標准。
所有的過程搞定之後，一個MES項目才算是成功搞定，一套MES系統才算是打造成功。
以上，供參考。