導讀:在CRM應用中，輕松改動、擴展和集成應用程序的功能比任何其他特性都要來得更重要。因為真正最佳的CRM系統(tǒng)是構(gòu)建起來的，而不是購買過來的，平臺優(yōu)勢比特性列表來得更重要。
　　在CRM應用中，輕松改動、擴展和集成應用程序的功能比任何其他特性都要來得更重要。因為真正最佳的CRM系統(tǒng)是構(gòu)建起來的，而不是購買過來的，平臺優(yōu)勢比特性列表來得更重要。所以只要讓平臺變得更好，就可以讓CRM變得更可靠、耐用。話雖如此，如果你有一個完美無瑕的平臺。但用戶極度討厭這一界面，那么CRM系統(tǒng)還是會夭折。在評估平臺時，對于CRM應用，平臺的哪些方面才是真正重要的呢？
　　1.應用編程接口(API)、語言和庫的流行程度
　　一個擁有上百萬開發(fā)人員的平臺比另一個只有一小群忠實開發(fā)人員的平臺重要得多。誰還記得ABAP編程語言？要是你無法圍繞Ruby on Rails建立一支高效的開發(fā)團隊，那么這個平臺再漂亮都無關緊要。正是由于以一種注重實際的態(tài)度關注開發(fā)人員群體，而不是底層技術(shù)，VB.net、Java、PHP、PERL和Python等平臺才備受青睬。
　　2.附件、工具和開發(fā)輔助手段的數(shù)量和用途
　　眾多庫有沒有得到一大群用戶(可能是開源用戶)的審壹，這確實很重要。它們會以適當?shù)姆绞教幚鞺TF-32字符嗎？能夠適當處理這種字符的庫往往不是太多。你還要關注集成開發(fā)環(huán)境(IDE)的插件和擴展件(Eclipse或NetBeans)、測試用具(Test harness)以及構(gòu)建環(huán)境。
　　3.該平臺是一種考慮縝密、表現(xiàn)穩(wěn)定的集成方式？還是一堆唬人的營銷大話？
　　使用云平臺有兩大理由：一是便于開發(fā)，二是便于與其他廣泛應用程序集成。應當關注API的一致性和適用范圍。你能獲得CRM系統(tǒng)里面的所有重要對象嗎？API是散布于17個動態(tài)鏈接庫嗎？還是它們是一組邏輯的Web服務？可以使用任何子系統(tǒng)的所有API嗎？還是說平臺被分隔開來？應用程序能從平臺外面開始執(zhí)行CRM事務或工作流嗎？外部系統(tǒng)能夠完全參與到CRM應用的觸發(fā)器和工作流嗎？
　　4.實際環(huán)境的可擴展性
　　每個月出現(xiàn)的停運時間有幾個小時？在忙碌時段響應時間怎么樣？平臺擁有資源調(diào)控限制嗎？還是僅僅為了方便CRM供應商，強行使用死板的代碼結(jié)構(gòu)？或者有沒有簡單直觀的方法可以一下子處理1萬個或10萬個記錄？你會驚訝地發(fā)現(xiàn)，CRM的API里面在可擴展性方面存在太多的局限性。
　　5.為所有API操作而實施的一種細粒度的安全模型
　　需要考慮安全模型的三個級別：底層數(shù)據(jù)庫的C/R/U/D權(quán)限、應用程序級別的角色、對象和操作、以及Web服務的方法。
　　正如以上顯示的那樣，魔鬼在于細節(jié)中。這是因為，有可能獲得基于一種非常流行的語言的API，但CRM供應商可以增添專有擴展件，結(jié)果擁有再龐大的開發(fā)社區(qū)也沒多大意義;或者有可能擁有完美無瑕的API，但只能適用于存儲在CRM應用的數(shù)據(jù)庫里面的那些數(shù)據(jù)。
　　因此，要真正知道你的CRM平臺對你來說是否足夠可靠、靈活，一個可行的方法就是以某個實際應用為對象，開展試點項目。當然。這么做可能需要高昂成本，但與選錯平臺造成的更大代價相比還是劃算的。

比特網(wǎng)