CRM軟件中，軟件選型很大程度上是決定其成敗與否的關鍵因素。如果選擇了合適的軟件，那么，就意味著CRM軟件項目已經成功一半了。而在軟件選型中，軟件測試是最重要的。企業項目管理員要根據企業自身的實際業務情況，對于CRM軟件進行測試。
在一般況下，別的企業適用的CRM軟件，拿到自己的企業中來用的時候，會發現很多不適應的地方。而不能夠看其他同行某款CRM軟件用的很好，就也選擇這一款。在企業中推進CRM項目的時候，筆者發現企業很多信息化負責人對于如何測試CRM軟件感到非常陌生。在CRM軟件測試的時候，只憑著自己的感覺走。致使在測試中留下了很多盲點，最后還給CRM軟件在企業中順利部署設置了障礙。
對此，為了幫助大家提高CRM軟件選型的水平，筆者特地在此給大家推薦一種簡單易行的CRM軟件測試模型，此軟件測試可分五大組件：
組件一：測試團隊
很多企業在CRM軟件測試中，最容易犯的一個錯誤就是這個測試團隊的問題。他們在測試CRM軟件的時候，幾乎都是企業IT部門負責人或者CIO的事情。其他業務部門都很少參與進來。眾所周知，IT部門負責人或者企業CIO，即使他們水平最高，也是技術出身，不太了解客戶關系管理的實務工作。如果讓他們來對CRM軟件進行測試，那此不不是對牛彈琴嗎？即使他們可以從業務人員那邊去取經，在短時間內想學到全面的客戶關系管理實務也不容易。因此，他們對于CRM軟件的測試也是不全面的，或者說，可能更多的關注技術層面，而忽視業務層面的需要。
為此，筆者建議，企業信息化項目負責人在組建CRM軟件測試團隊的時候，最好能夠讓相關業務部門的負責人參加，至少要讓一些關鍵用戶參加。而項目負責人在其中，只是起到一個聯系與記錄的作用。換言之，在CRM軟件測試中，企業IT部門負責人或者CIO只是起到一個輔助作用。具體軟件業務功能的測試，還是要依靠各個業務部門的關鍵用戶。因為只有他們最清楚自己到底需要什么；軟件能否提供他們滿意的解決方案。
組件二：測試實驗室
測試實驗室可分兩個部分：一是需要組建一個跟實際應用差不多的網絡環境；二是需要有一個日志關系系統記錄相關的測試過程。
通常情況下，企業在實際CRM軟件測試中，往往會忽略這方面的內容。如有些企業在CRM軟件測試中，主要是單機測試；而忽略員工之間的互動。如此的話，一個用戶把業務從頭做到尾，沒有發現什么問題。可是等到軟件實際使用的時候，一個業務流程往往需要有多個員工才能夠完成。此時，就會遇到問題了。這主要是因為系統在不同業務之間銜接是缺乏相關的提示所造成的。這也就是我們通常所說的，業務邏輯上沒有問題，但是在界面設計上缺乏人性化，缺乏相關的提示。如此的話，后面的業務人員接著做剩下的工作時，就會無從下手。這也是很多剛誕生的CRM軟件的最常見的不足之處。
同樣，測試日志也很重要。一方面企業選型的時候不可能只看一個CRM軟件。假如是這樣，選型就毫無意義了。企業肯定會像相親一樣，多看幾個，才能選擇一個合適的。為此，若在第一個軟件測試的時候，不做好相關的紀錄，那么后續軟件測試就必須得從頭再來。那回憑空增加很多的工作量。而另一方面，在測試的過程中可能會發現一些現有軟件中沒有的功能，但是這些功能卻是企業所必需的。為此，就需要在后續的二次開發中對其進行定制。如果在軟件測試的過程中，沒有進行相關的記錄，那是否在后續的項目推進中，又要重新整理一次。
組件三：需求
我們在軟件測試的時候，是不能夠漫無目的的進行測試。這就好比醫生給病人看病，總是需要先問清病人的癥狀，然后再確定是否要進行深一步的檢測。而在CRM軟件測試中，也應該是這樣。企業項目負責人首先要集合各個部門的業務人員，讓他們列舉出自己部門的關鍵業務與業務流程。收集到這些需求之后，在軟件測試過程中，才能夠拿這些需求去對CRM軟件進行比對，看看CRM軟件中是否有類似的解決方案。
但是，在需求收集的時候，筆者認為要注意一個問題，就是主次問題。雖然CRM軟件沒有ERP軟件那么復雜，但是，其涉及到的業務流程也有數百條。如果對這些流程都一一進行測試的話，那么花在測試上的時間會比較多。同時，由于企業自身的特殊性，若要全部滿足這數百條業務流程的CRM軟件，恐怕現在還沒于出世。因此企業在根據需求測試CRM軟件功能的時候，需要分清主次。而一些次要流程與業務，若能夠滿足最好；若實在不行，也不能夠強求。或許可以通過其它方式來解決。
組件四：二次開發。
對于類似的問題，筆者以前在企業中作CRM軟件內部實施的時候也曾碰到過，因為企業有時候，需要把某個客戶狀態設置為異常。如此的話，這個客戶將不能夠在系統中處理新的業務；而對于系統中已經啟動的業務流程，則不受影響。筆者提出這個需求后，軟件公司也比較認真，大概一個星期左右就完成了這個二次開發的需求。在測試的時候，也順利通過了。可是在后續使用的過程中，則發現了新的問題。就是當客戶狀態為異常時，不能夠直接把這個客戶狀態改為終止交易。而必需要先把這個狀態改為正常，然后才能夠改為終止交易。
CRM軟件測試不僅在軟件選型的時候要進行，而且在系統二次開發完成之后，也需要進行測試。從某種程度上來說，二次開發結果測試其更加的困難。因為二次開發過后，企業項目管理人員并不知道其內部進行了那些修改。或許其表面上看來某個功能實現了。但是，實現這個功能是否對其他作業有不利影響呢？這企業項目管理人員也無從考證，只能夠通過測試來實現。
從這個筆者親身經歷的例子表明，在二次開發過后，會出現比較多的小BUG。畢竟二次開發就好像是對人進行部分的美容。其或多或少會有一些副作用。因此，后續的測試對于二次開發來說是非常重要的。
組件五：基礎架構。
CRM軟件雖然主要是一個業務管理的工具，可是其基礎架構測試也非常重要。因為其直接關系到CRM軟件在企業的網絡環境中運行的是否順暢。在基礎架構測試中，企業項目管理人員主要注意以下幾個問題：
首先是要注意軟件的性能。CRM軟件利用不同的開發平臺，其性能會有很大的差異。若CRM軟件使用JAVA語言平臺開發的話，那么在系統登陸的時候，會占用比較多的內存與CPU資源。如果企業內部網絡組建的比較早，主機配置比較低的話，則從系統打開倒出現登陸界面，可能需要近一分鐘的時間，這對用戶來說是無法接受的。因此，企業要根據自己的網絡環境，在軟件功能、兼容性與性能方面取得一個均衡。
其次是要注意企業的網絡環境。在多數企業的網絡環境中，操作系統都不會很存。如有些企業中，除了現在最流行的XP操作系統外，出于某些特殊的需要(如開票系統的需要)，還有比較早的98操作系統。另外有些企業，除了微軟的Windows操作系統之外，還存在Linux等開源操作系統或者蘋果操作系統等等。
在這種如此復雜的網絡環境中，企業必須充分考慮到應用軟件的兼容性問題。另據筆者所知，有些CRM軟件對于操作系統的依賴性還是很高的。如無法在98等早期的操作系統中使用；或者無法不支持跨平臺使用，即無法在Linux操作系統中使用。因此，在CRM軟件基礎架構測試時，要考慮CRM軟件與企業網絡環境的兼容性問題。
最后是需要測試軟件的并發訪問問題。如果有些CRM軟件設計的不好的話，并發性訪問會產生比較大的問題。如一兩個用戶在使用CRM軟件的時候，訪問速度不會有什么影響；不過，如果有八九個員工同時訪問CRM軟件時，訪問速度就會急速下降。這不僅跟應用程序的開發有關，而且還跟后臺數據庫的設計有關。如后臺數據庫設計不好的話，則當多個用戶同時訪問某張數據表的話，就會導致鎖沖突，甚至產生死鎖，從而降低應用程序的反應速度。
因此，在基礎架構測試中，并發性訪問測試也是非常重要的一個環節。在實際測試時，項目負責人可以讓多個用戶同時訪問某些關鍵的窗口，如客戶投訴處理窗口，看看系統響應速度有沒有明顯降低。
上一篇：
助你提高客戶滿意度的Exact crm下一篇：
實施CRM失敗率因素縱多不會影響其發展