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