二、CRM分析功能會產生大量的網絡流量

CRM軟件從功能上可以分為分析性的CRM軟件與記賬型的CRM系統。筆者認為，如果企業采用的是記賬型的CRM系統，那么可以跟現在的SaaS模式很好的兼容。因為記賬型的CRM系統，只是記入平時跟客戶的聯系、交易情況，其涉及到的數據庫一般都不是很大。但是如果企業采用的是分析型的CRM系統，那么就有可能出現問題了。

因為分析型的CRM系統，在對歷史數據進行分析的時候，會產生大量的數據流。如筆者的一家客戶，在根據以前三年的交易數據預測未來一年的訂單數量的時候，其需要用到過去三年的交易數據。而且需要對這些數據進行統計、分析。那時，將這個服務器系統與客戶端都部署在企業的局域網內(這個網絡的性能與吞吐量要比互聯網好的多)，也大概需要花費半個小時的時間。而如果采取SaaS模式來部署 CRM系統，由于服務器是部署在互聯網上的。現在用戶需要運行這個預測功能的話，需要從服務器上下載相關的數據然后進行分析統計，由于受到網絡速度的限制 (國內的網絡速度是比較慢的，跟局域網的速度沒有可比性)，其需要花費更長的時間，如可能是兩個小時，甚至更長的時間。

有些SaaS服務器上可能已經預見到了這種情況，他們在軟件設計的時候對此做了一定程度的改善。如對于這些可能產生大量數據流量的作業，會將其放在服務器上運行。即企業用戶將需要完成的需求通過代碼的形式反映到服務器。在服務器端直接從數據庫中查詢數據并進行統計分析以及相關的運算，而不會將這些數據下載到客戶端在進行分析。最后將得到的結果再返回給用戶。這種設計雖然可以在很大程度上提高由此產生的網絡流量，提高應用程序的性能。但是由此也會造成一個新的問題。如在一些CRM軟件的分析、統計作業中，有可能用戶不僅需要最終的結果，而且還需要中間的運算過程。因為當用戶對最終的結果感到懷疑時，他們需要查看中間的數據以進行核對。如現在需要統計客戶過去三年的應收帳款情況，以確定最新的折扣政策。這也需要用到大量的基礎數據。此時軟件設計者是可以將這個運算放在服務上運行，然后將最終的結果返回給用戶。此時在網絡上傳輸的數據量不會很多。但是，如果用戶對最后產生的結果有懷疑，他們需要產看某一年度的應收帳款統計情況。其實這個在上面的過程中已經統計過，此時服務器沒有把相關的中間結果返回給用戶。此時用戶就不得不重新提交一個請求。顯然這又會浪費不少的時間。

為此筆者認為，現在SaaS應用模式與CRM軟件結合的比較好的，基本上都是那些記賬型的CRM軟件。或者雖然有分析功能，但是企業用的比較少。要利用CRM軟件進行統計、分析、預測，必然需要用到大量的基礎數據。而要跟互聯網上的數據傳遞這些數據，到目前為止的企業聯網速度，用戶可能需要等待比較長的時間。即使設計者改變數據處理的位置，那么也是用戶犧牲中間運算結果為代價的。而在某些情況下，這些中間的運算結果對于用戶來說有很大的實用價值。故從這個角度講，筆者認為分析型的CRM軟件現在還很難跟SaaS軟件即服務模式很好的集成。如果硬要將他們綁在一起的話，可能會產生比較大的沖突。