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