如何才能把這個損失減少到最小

可見，CRM項目需求變更，對CRM項目來說，是非常不利的。那我們如何才能把這個損失減少到最小，甚至是消除在項目實施過程中需求變更情況的產生呢?

一、需求變更要盡早，越到后面其成本、風險等影響越嚴重。

當需求變更情況發生后，我跟一些用戶溝通，問他們為什么以前沒有提出來呢?很大一部分用戶說，他們之前也發覺了這個問題，只是那時候認為這個需求不是很重要，可有可無，就沒有說了；但是，沒想到，現在系統余越來越熟悉、越用越好，這個問題也慢慢變大了，覺得非要實現不可，否則的話，工作就進行不下去了。

其實，這個問題很多企業都存在。確實，手工作業跟系統自動作業存在比較大的差異，有些手工業下，可能不是什么大問題;但是，一到利用管理系統進行自動化作業的時候，就發現這個問題成為了信息化作業的大障礙了。這種情況不僅一個企業存在。

但是，從信息化項目角度來講，這是一個很危險的信號。為什么呢?我們造房子，若在房子快造好時，發現原先設計不對，需要重新推翻重造，那成本與時間的浪費，是不可估量的了。對于CRM項目來說，也是類似的道理。若你項目快要完工時，才發現原先的需求有錯誤，需要變更，那損失就會很大。所以，項目越接近尾聲，再進行需求變更的話，則給企業的損失會越大。

所以，我們要充分做好前期的需求調研、系統演示、系統培訓工作，爭取通過這些工作，最大程度的挖掘用戶的潛在需求，發現可能要需求變更的地方，讓用戶盡快做出是否要進行需求變更。我在實施項目的過程中，一般把需求變更或者新需求的確認時間最遲定在系統培訓階段。也就是說，在系統培訓完成后、開始準備雙線并行前，企業用戶還可以提出需求變更的申請;但是，當系統開始雙線運行時，就不允許用戶再提出需求變更等類似的請求了。這以后任何的新需求、需求變更等，都要放在項目上先后再進行。當然，這靠顧問一個人的力量是不夠的，我一般在項目實施中，就會跟企業負責人協商，告訴他們需求變更可能帶來的風險。讓他來下這個死命令，這比我在臺上上幾百幾千句要有效的多。

總之，需求變更越早發現越好。越遲發現的話，無論是項目的時間、成本還是項目風險，都會增加很多。

二、需求變更若無法在短時間內解決，要采取比較折中的方案。

當我們遇到有些需求無法在短時間內解決，需要花個把月才能解決的時候，那我們就不要占牛角尖，不要在一棵樹上吊死，而要想一下，有否臨時的折中方案可以先“應付”一下;一邊使用系統一邊進行二次開發。

這么做，主要是為了減少需求變更對于項目周期的影響，為了保證CRM系統可以按時上線。有時候，為了保證這個大目標的實現，我們，無論是實施顧問還是企業，做出這一點妥協都是值得的。

如很早以前我有一次遇到一個客戶。在項目快培訓完的時候，客戶企業的銷售總監問我我們的系統中有沒有客戶漏斗管理模型。客戶漏斗管理工具在現在的CRM 系統中是比較普遍的，但是，在幾年之前的CRM系統中，還是鳳毛麟角的。因為客戶漏斗管理模型的設計，不僅僅是功能上的區別，而且，對于后臺的技術也有比較高的要求。以前多采用C/S(客戶端/服務器)模式的CRM軟件，無法實現這個功能。而我們雖然剛剛開始采用B/S(瀏覽器/服務器)模式，還沒有考慮這個功能。

該怎么辦呢?用戶有兩個選擇，一是進行二次開發，實現漏斗管理模型，但是，這無疑會增加很多的實施成本，而且，這么復雜一個管理模型，也不是一兩天可以做的出來的，沒有個幾個月的時間，很難實現。第二個選擇就是先不用漏斗的圖形化管理，而只提供一些報表數據，銷售漏斗管理等我們下次系統升級時，優先幫企業升級實現這個功能。如此，這個升級因為屬于版本的升級，企業不用花費一分錢。

該如何抉擇呢?我給銷售總監展示了模擬銷售漏斗管理的相關報表、表單。他發現，雖然利用報標、表單沒有像圖形工具這么方便，但是，從時間、成本等多個因素考慮，這個“不方便”還是可以接受的。所以，接受了我們的第二種處理方案，先遷就一點用著，等到我們系統升級后，再利用銷售漏斗來管理。

需求的變更，對于項目的影響是非常大的。但是，就如同天要下雨一樣，我們無法從根本上加以消除。我們所能夠做的，就是采取一些行之有效的工作，把這個幾率降至到最低;或者采取一些補救措施，把需求變更給CRM項目帶來的損失減到最小。