在CRM項目部署過程中，我們首先需要遵循標準業務規則。但在這個過程中，由于各個企業業務、文化背景等不同，也會在一定程度上存在著一些個性化的內容。無論是作為企業的項目管理員，還是項目的咨詢實施顧問，都必須正確面對這一點。如果一味的抹殺企業的個性化需求，那么，CRM項目離失敗也就不遠了。所以，企業必須關注如何才能夠快速的構建適合企業“廠情”的個性化CRM系統。

    首先，通過工作流控制為首選 在項目需求調研、實施的過程中，若發現企業的個性需求是合理的，那么實施顧問就有義務幫助他們實現。但問題是，到底應以哪種手段來實現這些需求呢?當然，選擇合適的個性化需求實現方式，確實能取得事半功倍的效果。但是如果實現的手段不合適的話，那么就會影響到系統的穩定性與項目的實施成本。

    這里有一點是尤其值得注意的，就是有一些心黑的軟件提供商，他們不是根據需求來選擇實現方式，而是根據利潤。簡單而言，即答應給企業免費開發的一些需求，他們可能會采用工作流控制、后者平臺來實現，因為這可以大大的降低軟件開發公司的開發成本。 反之，對那些收費的二次開發需求，就算是可以通過工作流控制或者平臺等功能來簡單的實現，但是軟件公司仍然可以采取通過修改源代碼的方式來實現。因為這可以為軟件公司爭取更多的利潤。

    因此， 在構建個性化的CRM系統之前，企業項目管理員需要了解個性化需求實現的相關手段，并了解他們在對系統運行的穩定性、項目的實施周期、成本等方面的不同影響。

    另外，當遇到個性需求時，企業首先要想到的是通過工作流的手段來實現。因為目前大多數的CRM系統都已經集成了工作流模塊。一些個性化需求完全可以通過配置工作流系統來實現。如新客戶的審核流程中，可能需要信用額度、付款方式、付款條件、客戶基本信息(如營業執照)等等信息的審核。其中涉及到不同的部門。這對這個個性化需求，就可以通過工作流系統，將不同的不同虛擬到同一個流程之中，加以實現。

    那么，為什么筆者將“通過工作流方式來實現個性化需求”定位為首選的方式呢？這是因為主其有如下三個優點：

    1、成本低廉、實施的周期短。通過流程控制來實現，無需涉及到源代碼的開發，測試的工作量也少。所以，其實現成本不僅較低廉，而且周期也比較短，更不會影響到項目的整個實施計劃。

    2、企業用戶的靈活性高。由于流程控制不會涉及到源代碼成面，所以，不少軟件公司都會將這個功能開發給用戶。一旦用戶掌握了相關的配置技巧，就可以根據自己企業的實際情況來進行配置，從而主動權是掌握在用戶手中的。

    3、對系統的穩定性基本不會有影響。通過流程來實現個性化需求就好像房屋裝修過程中的改變室內布局一樣，只要不涉及到承重墻(源代碼)，就不會對整幢房屋的安全性產生影響。

    綜上， 企業對于那些必須要實現的個性化需求，首先考慮的是通過系統提供的工作流模塊來完成(如果系統提供這個功能)。而只有在這個無法實現的情況下，才考慮其他的手段。

    其次，通過平臺實現功能的再定義 

    當某些功能工作流模塊無法完成，如需要定義一張客戶評價的報表或者在客戶信息中增加一項內容，這個時候，通過工作流就無法實現。因此，在這種情況下，也不一定需要修改原程序。企業還可以考慮選擇平臺來對功能進行再定義。目前許多軟件公司為了提高市場競爭力，都會開發一些平臺，方便對一些功能進行二次調整。如金蝶的ERP與CRM軟件中，就提供了K/3BOS平臺。這是一個面向業務的、開放的集成與應用平臺，具有比較強大的業務配置和開發能力。 通過平臺來實現二次需求，有這樣一個共同點：很多情況下，用戶不需要修改源代碼即可實現。這不但能保證系統的穩定性，而且又提高二次開發的效率。

    但通過平臺來實現功能，其有一個限制，即不會改變系統的主流程。這就好像一棵樹。通過平臺之能夠改變樹的枝葉，如添加或者刪除，而不能夠改變樹的主干。與其說這是一個限制，還不如說這是這個手段的優點。因為有了這個限制，就可以保證用戶的修改不會影響到系統整體運行的穩定性。

    通過平臺來實現二次需求相比于第一個方式 ，往往需要在軟件公司的協助下才能夠完成。一方面通過平臺來實現一些功能，有可能需要編寫一些簡單的代碼，如定義報表時需要sql查詢語句等等;另一方面在后續CRM軟件版本升級時，也必須考慮這方面的內容。所以，這往往需要企業與軟件公司兩方面相互配合才能夠完成。還有一點需要注意的是，就是通過平臺來實現的新功能，在使用之前需要做好相關的測試，不管是后臺數據庫中增加表或者字段，還是在前臺增加一個窗口，都可能會對其他的功能有關聯。在投入使用之前，需要確保這些關聯不會產生負面的影響。因此，從測試量來說，要比第一個方式多的多。

    鑒于以上原因，通過平臺來實現二次需求是一個中性的方式。從總體成本來說，要比通過工作流方式要高，但是比二次開發卻要低。

    最后，二次開發不得已而為之 因為其不管是通過哪一種來實現，其有一個共同點，即基本上不會涉及到后臺的源代碼。所以其實現的功能也是有限的。如客戶信息的審核動作就無法通過前面兩種方式來實現。換言之，雖然這兩種手段都具有一定的優勢，但是可能仍然無法實現企業全部的個性需求。在一定的情況下，企業仍然需要通過二次開發來完成一些比較復雜的需求。

    盡管如此，但企業仍然要最大限度的降低二次開發的數量。因為二次開發的成本都是比較可觀的，如有些軟件公司都是按500元/小時/人的價格來收取。另一方面，由于二次開發會修改系統后臺的源代碼，不利于后續的維護。如需要進行軟件版本的升級，那么就會遇到麻煩。軟件公司可能需要針對這個個案專門設計升級的方案，無論是成本還是周期上都會帶來負面的影響。此外，由于二次開發的內容軟件公司不會投入大量的精力去測試，所以，在穩定性上就會大打折扣。修改源代碼，已經是傷筋動骨了。沒有一定時間的磨合，是無法發現隱藏在其中的風險。

    為此，筆者建議，一般只有在不得已的情況下才通過修改源代碼的方式來實現二次需求。同時，企業還需要充分認識到，如果采取二次開發的方式來實現需求可能會遇到的風險。但不管是采取怎樣的方式來構建個性化的需求，有一項基礎性的工作都是要做的，就是需要保留相關的原始分檔。包括用戶的需求分析、需求實現的具體細節、功能測試報告等。因為這些資料在后續的維護中是非常重要的。能在很大程度上降低維護、系統升級的工作量，尤其是當更換項目負責人時，這些資料的價值就更大了。