大部分企業應用的系統或許與
CRM系統不一樣。雖然有些需求是沒有商量余地，但以逐步的方式來重新定義需求及部署功能仍然大有余地。這就意味著，CRM系統可使用“按杯數計費”的投資模式(by-the-drinkmodel)，而不是像傳統企業軟件特有的“賭上全部家當”的投資模式(bet-the-farmmodel)。
基于SaaS模式的CRM系統所具有的靈活性更大，因為它沒有任何硬件或嚴重的操作問題要處理，只需打個電話，便能增加容量和增加模塊。Web服務應用編程接口(API)穩定可靠的CRM系統(比如Salesforce.com的CRM系統)在開發和部署周期方面的靈活性更大。
鑒于此，本文特地介紹了幾個克服范圍的辦法，供大家參考。
為業務部門不斷帶來細小價值
逐步進行工作開展是現代CRM系統的一大特點，而不是錯誤。但由于Web服務具有松散耦合性，因此，完全有理由確保交付的功能細小、簡單、可分離。有時候，迫切需要的功能只需要幾個工時就能開發及測試完成，那樣每個季度就可以部署兩次，甚至更頻繁。
在這基礎上更進一步：最好只部署一部分功能，把部分功能留到以后去開發可以簡化學習難度，讓企業適應比較小、這樣可以頻繁的交付成果，并且可以為IT部門提供了下一個部署周期所需的“現金儲備”。
嚴格控制需求
由于避免虛假需求是防止范圍漸變的第一道防線，因此，要運用“敏捷”項目概念。用戶也許不知道自已的真正需求有多重要。即便用戶堅決要求的某項功能，也很少能量化該功能所具有的商業價值。所以致力于核心系統——如果明確需要“下一項功能”，必要的功能只會迅速增加，不斷添加到核心系統上。
當你用新CRM
客戶管理系統替換現有系統時，往往會遇到很多麻煩。用戶的預期目標會被之前的系統所框定，如何來保證出現的范圍漸變。這可能需要在會上據理力爭，但你必須弄清楚以下幾個問題：
1 你果真想要新系統就具有舊系統的數據質量和功能嗎?
由于用戶和客戶都已熟悉舊系統的使用習慣，因此切換需要盡量平穩。從一個系統“直接切換”到另一個系統可能會帶來遷移問題，進行分階段、分步驟的切換會相對比較穩妥。
此外，系統中的數據(交易事務和不斷變化的客戶關系)是絕對不能面臨風險的。新系統中的核心數據和功能只有穩定下來，這樣才可以成為更高級系統功能的基礎。有一段時期出現“并行運行”或者功能減少是不可避免的，則應當考慮到計劃當中。
CRM系統的影響與客戶方面的合作情況。如果缺少用戶，即使你添加再多的功能于事無補，也不會給業務帶來更大的影響。此外，為系統增添更多的復雜功能實際上不利于易用性和用戶采用。注重用戶采用的這種觀點也許能成為控制范圍漸變的一個限制因素(gatingfactor)。
逼對方攤牌
其實，用戶請求的有些功能實施起來既簡單也直接。而其他“簡單的要求”會涉及到成本高昂的數據改寫和外部系統集成。但是，如果對功能清單上某項“可有可無”的功能產生懷疑，就要用預算逼請求方攤牌。并估算一下開發這部分功能需要多少成本，告訴請求方：一旦有關方提供預算，就會開始開發這部分功能。只有搞清楚具體的費用數字或在部門之間調撥預算，才會開始開發。
每隔六個月就重新確定
CRM軟件需求的優先級
在某些行業，銷售或營銷副總裁的任職期只有短短18個月。CRM項目開始階段確定的優先級可能因企業內部政策或業務規則出現變化而不適用。此外，競爭對手、合作伙伴和客戶不斷變化，可能意味著CRM和相關系統方面的重點會出現變化。參加這類優先級討論會時，要根據實際成本和商業價值來比較功能。避免不再必要的需求是控制范圍漸變的最有效方法之一
上一篇：
移動CRM為企業帶來何種價值下一篇：
如何利用在線CRM來開拓金融風暴中的內貿市場