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

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

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

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