MES：制造執(zhí)行系統(tǒng)，所謂制造執(zhí)行系統(tǒng)就是跟生產(chǎn)現(xiàn)場的管理密切相關，生產(chǎn)現(xiàn)場需求本身也存在很大的不固定性，為了優(yōu)化各方面的管理或者為了簡化現(xiàn)場的操作等一系列的原因都會導致需求變更的結果。需求變更是MES項目與生俱來的特性，在MES項目實施過程中，項目管理所要面對的經(jīng)常發(fā)生而又最令人頭疼的恐怕就是需求變更了。從個人理解角度闡述一下發(fā)生需求變更的原因和如何管理發(fā)生的需求變更。
導致需求變更的根源之一：合同簽訂時的需求范圍不明確
這個要從銷售身上說起，在銷售階段簽訂合同時缺乏對客戶需求認真對待，導致需求描述不清，為后期的實施工作帶來困惑。為了盡早的讓客戶簽訂合同，往往草率決定和片面同意客戶提出的需求。 該問題的關鍵是合同簽署的太爛，沒有把需求明確再簽合同，而且也沒有把需求變更的流程寫入合同。如果在合同時把客戶需求弄清楚，后期就根本不需要頻繁的變更需求。簽訂合同時明確定義項目需求的范圍，同時明確的定義需求變更的流程，這樣可以為以后各項實施工作的開展奠定深厚的基礎。
根源之二：需求調研階段沒有詳細理解客戶需求
在項目的需求調研階段，實施顧問和客戶的深入溝通，了解客戶的詳細需求是減少需求變更的主要動能。在需求調研階段常常會有實施顧問僅僅根據(jù)用戶提出的描述性、總結性的只言片語去制定方案，這樣得到的方案和Function Spec簡直會讓人崩潰。當需求會議一天幾個接著開的時候，可能當時客戶或者領導的思路也會偶爾發(fā)生混亂提出新的需求時，實施顧問往往不去區(qū)分客戶真正需求和非真正需求。在需求分析階段項目組對需求的細節(jié)了解的不夠充分，雙發(fā)對需求的理解就會產(chǎn)生很大的差異，而很多項目實施的過程中如果不存在一個Function Spec再次確認的過程(很多項目為了進度可能僅僅確認一下分析文檔結果的方案架構)，就會導致在上線階段很多問題暴露出來，沒有辦法客戶只能貧乏的提出需求變更。
根源之三：需求變更管理流程不夠明確
沒有明確的需求變更管理流程，就會使需求變更變得更加泛濫，客戶更會毫無顧忌的提出各種各樣的需求變更，甚至有很多時候僅僅是某個人的操作習慣就知道幾個需求變更的產(chǎn)生。所有的需求變更都要有一個變更流程，有一個優(yōu)先級。并不是所有的變更都要修改，也不是所有變更都要立刻修改，需求變更管理流程的目的是為了決定什么類型的變更需求修改和在什么時候修改，以及由此需求變更所產(chǎn)生的人力和時間耗費對項目進度的影響。對于一些界面上的優(yōu)化問題，或者一些個人操作習慣上的問題，完全可以作為上線后的優(yōu)化項目進行處理。需求變更的管理流程中針對核心模塊的變更處理要把重要程度提到一個很高的級別，因為對于核心模塊的變更，某個小需求看起來工作量不大，實際修改起來不僅僅對于實施人員的時間和人力浪費很大，而且往往極大可能產(chǎn)生一些附屬的問題。同時需求變更管理流程中要將最后的需求變更結果報告給雙方的領導層，讓雙方領導明確的清楚在項目實施的過程中由于多少的需求變更產(chǎn)生了多少的人力和時間的付出。
針對如此多的導致需求變更的原因，該如何解決呢?建議從以下幾點進行需求變更的管控：
1、合同效力的約束，在簽訂合同的時候就需要針對需求變更有明確的變更流程要求。
2、建立需求變更的審核流程，執(zhí)行審核的流程的目的是將客戶下達變更的流程盡可能地規(guī)范化，減少張嘴就來的非必要、非緊急、非合理、非高層領導意圖的“無效變更”。同時可以留下書面依據(jù)，為今后可能的成本變更和索賠準備好“變更賬”。凡未履
行審批程序的“變更”，一律是無效變更不予受理。定期召開需求變更專題會議，集中研究處理零碎的變更事項，主動控制花工作節(jié)奏。
3、定期向雙方領導匯報變更結果，這樣可以避免一些客戶個人需求一些的非必要變更。
當然做到這幾點也不可能完全避免所有的需求變更，如何合理的減少需求變更，以及當發(fā)生了需求變更時如何合理的解決，是項目管理過程中重要的一個環(huán)節(jié)，期待能聽到更多更好的觀點。
用戶需求的變更總是不可避免的，所以我們要以積極的心態(tài)去接受和控制用戶的需求，而不僅僅是埋怨。對待客戶頻繁的需求變更，應采取有效辦法應對，避免事態(tài)蔓延，不讓客戶養(yǎng)成隨意變更的毛病。由于需求變更對項目最終的成敗會產(chǎn)生極大的影響，所以不能一律的拒絕所有的客戶需求，也不能一味地接受客戶所有的需求變更，所以實施需求變更之前必須做好控制。