在部署CRM系統的時候，開發人員通常會根據企業的共性，設置一些默認值，以減少后續配置的工作量。如將雙休日作為節假日、以自然月份作為會計期間等等。但是這些默認設置卻是一把雙刃劍。用的好，既能提高系統的靈活性，又能實現企業的個性化需求。相反，如果用的不好的話，就會破壞系統的穩定性，并失去優化企業業務流程的機會。 因此，筆者認為，在使用默認設置的時候，企業CRM項目管理員必須要緊握這把雙刃劍。這樣才能最大限度提高CRM的靈活性。

    使用默認設置時這個設置是否真的適合自己？

    一般情況下，實施顧問通常都是建議用戶采用系統的默認設置。除非用戶自己提出來，否則，不會對默認設置進行更改。這主要是出于系統穩定性的考慮。但是由于各個企業的特點都有所不同。如以結帳日期為例。許多企業都是按自然月來進行結賬的。也就是每個月的最后一日為結帳日期。然而，仍然有部分企業，不是按自然月來結賬。如他們可能是每個月的25日作為結賬日期。這么做主要出于兩個方面的原因。一是他們的客戶可能就是25日結帳的。為了跟客戶保持一致，企業也就這么規定了。二是為了給財務做帳留下足夠的時間。為此將25日以后的業務都算到下個月去。這就導致了不同的企業，對于結賬日期會有不同的要求。

   如果在CRM項目實施過程中遇到這種情況，則企業項目管理員就有兩個選擇：一個是更改企業現有的操作模式，服從于系統的默認配置；另一個是更改系統的默認配置，來符合企業自己的個性需求。 要做出這個選擇雖然比較容易。但要了解其背后的深層次內容的話，則較為復雜。如從改善企業管理的角度講，系統的默認配置當然是首選，不過，若是從提高企業管理的靈活性角度來說，也需要支持企業合理的個性化需求。因此，如果企業在使用系統的默認設置時，需要捫心自問：這個默認設置適合企業的實際情況嗎?要回答這個問題，就需要在靈活性與標準化作業之間進行抉擇。 如果企業的需求是合理的，不存在其他的安全隱患，則應該積極的更改系統的配置，來滿足企業業務的需求。但是，如果更改這個默認設置的話，則會引起連鎖反應。或者說需要通過二次開發來更改相關的配置，此時企業就應該慎重。因為我們使用套裝的CRM軟件的主要原因無非就是為了改善企業的管理模式，以標準化流程來武裝自己。

    更改默認設置時更改后會有什么影響？

    當企業決定更改系統的默認設置(如通過系統配置來更改或者通過二次開發來更改)，在決定更改之前，必須要向實施顧問確認清楚，如果真的這么改，那么對系統的其它作業會有什么影響?換言之，企業項目管理員在這里需要搞清楚一個基本的原則，即蝴蝶效應。大家知道，CRM項目各個作業是環環相扣的，所以，如果一個參數的更改，則會對企業的多個作業造成不同程度的影響。如上面這個結賬日期的更改，不僅會影響到各個單據的輸入，而且還會影響到各個報表的數據。

    當確實需要更改默認設置時，需要對更改后可能造成的變化進行確認。 筆者總結了如下幾個建議，以供大家參考：

    1、需要對更改前后的內容進行測試，并進行對比。例如，可先利用系統的默認設置進行操作，然后再按更改后的參數進行測試。最后就是比較兩次更改，所造成的差異。這種方法不僅能夠幫助我們了解相關配置參數對系統作業的影響，而且也有利于幫助用戶確定，到底是使用默認配置，還是需要更改默認配置。

    2、需要對上面這一步的動作，有書面的紀錄。包括更改前后的參數、測試出來的差異的地方。其實，實施顧問并不是實際的開發人員。他也不能夠窮舉所有有差異的地方。或者說，有個差異可能比較細小，對于大多企業都沒有影響。不過，由于各個企業實際情況的不同，可能正好打中你們企業的要害。因此，為了便于后續的維護與系統的優化，企業最好能夠做好相關的書面記錄。 

    3、需要對這相關的內容最好后續的跟蹤與培訓。 比如在系統剛上線時，系統管理員需要隔三差五的去觀測一些這些節點，有沒有什么意外的情況發生。在后續對員工進行培訓的時候，也需要強調這方面的內容。 系統升級時參數是否需要更改？如果確實需要更改系統的默認配置的話，則系統管理員還需要考慮以后軟件升級的事情。事實上，與其他的操作系統一樣，CRM系統也需要通過不斷的升級，來增加軟件的功能，優化軟件的性能。在這種情況下，項目管理員需要考慮的是，用戶的自定義設置在升級之后是否會保存下來?比如微軟的操作系統，可以將用戶的自定義配置分為兩類：一類是用戶通過操作系統的界面進行的個性化配置，如通過組策略來配置桌面等等。這類個性化配置一般會在系統升級后自動保留下來。另一類是通過二次開發完成的個性化需求，如與其它應用程序的接口等等。這些個性化需求在系統升級后是否可以兼容呢?這不能夠保證。

    另外，在CRM系統升級的時候，也同樣存在這種情況。通常情況下，一些比較成熟的CRM系統，其實與微軟操作系統的情況相差甚微。通過系統自定義平臺更改的默認設置，在軟件升級后一般都是支持的，就不需要重新配置。而對于二次開發完成的個性化定義，則往往還需要進行二次開發來完成。這是一個比較頭疼的問題。由于二次開發的風險與成本相對較大，而且如果企業有比較多的二次開發，所以，軟件公司在系統升級時，一般都不會優先考慮你。因為在軟件升級過程中，軟件公司的工作量本來就比較大，需要處理升級過程中出現的各種各樣的問題。如果系統的二次開發量比較大，軟件公司就會將升級工作往后壓。等到其他公司的升級工作完成了，再來處理你們公司軟件的升級問題。這是需要考慮的一個問題。

    一些比較小型的CRM軟件，在這方面可能設計的并不十分理想。就算是通過系統的自定義平臺的個性化設置，在系統升級之后，也不會保留下來，需要系統管理員進行重新配置。這可能有兩方面的原因。一是系統在開發設計時，沒有將相關的配置參數存放在一個獨立的配置文件中。從開發的角度講，就是沒有通過變量來保存參數，而是通過常量。這個時候，如果軟件升級，新舊系統就不能夠兼容。另外一個是系統的核心代碼發生了比較大的變更，這導致了新舊功能的不兼容。此時新舊配置參數更加不兼容了。

    總結：

    正如前文所說的，系統的默認設置是一把雙刃劍，如果利用的好，確實能減少后續配置的工作量。但是如果一不小心，這些默認設置反而會將企業用戶引入誤區。因此，出于安全的考慮，在實際工作中， 需要對系統的更改做好相關的紀錄。如果在升級時，發現不兼容的情況，也可以通過原始記錄進行重新配置。