最近幾年的顧客關係管理市場顯得有點黯淡， 就連過去曾意氣昂揚的領導廠商Siebel也碰了壁，最終以被甲骨文收購做結。然而在一片負面消息中，On Demand顧客關係管理系統廠商在近幾年的成長卻相當驚人。

Salesforce.com在2001年時的總營收僅有五百多萬美元， 該年虧損三千多萬。然而到2005年時一飛沖天的總營收已經達到整整三十倍之多的一億七千多萬， 且有七百多萬美元的利潤落袋。同為On Demand廠商的RightNow也不遑多讓，2001年時RightNow總營收二千多萬美元，虧損一千五百多萬，到2005年時總營收成長到近九千萬，獲利七百多萬美元。

事實上，這段時間逆勢成長的salesforce.com可謂名利雙收，除了上述的實質收益之外，salesforce.com的名聲也是一天比一天響亮。與此同時，傳統套裝顧客關係管理廠商卻面臨了營收持續下滑的困境，讓我們看看下面的營收趨勢比較圖：

本圖的重點在於消長的趨勢， 其中 Salesforce.com 與 RightNow 是純 On Demand 顧客關係管理廠商，Onyx以傳統套裝軟體模式提供產品，Siebel則是在2003年推出 On Demand 服務後兼有套裝與On Demand 兩條產品線（由於Siebel於2005年被Oracle併購，故無該公司2005年財報資料）。由圖中可以發現當傳統套裝顧客關係管理大廠營收逐漸衰退的同時，On Demand 廠商卻異軍突起。而salesforce.com 更是在營收、利潤與用戶數上屢創新高，成為人們談到顧客關係管理、On Demand 或是軟體即服務（Software as a Service, SaaS)等熱門話題時無法不帶上幾筆的代表廠商。

由Ma r c Be n i o f f 在1 9 9 9 年創立的Salesforce.com 堪稱近兩年來最耀眼的顧客關係管理廠商。事實上，最近用戶與獲利持續成長的salesforce.com 不僅在顧客關係管理市場上嶄露頭角，更成功地站上了這波企業軟體創新的浪頭，這波浪頭有很多名字：可以叫做隨選即用、軟體即服務、Web 即平台（Web as a Platform)，或是 Benioff 所說的全球商務網(Business Web)。

沒有人知道Marc Benioff  究竟是個深謀遠慮的諸葛亮（ 早在1999年成立salesforce.com 時就已預見今日的趨勢而定下隆中策）或者只是一路走來奮鬥掙扎的軌跡碰巧對上了目前看來前程似錦的道路。但不論如何，單以 salesforce.com 過去七年來的發展來看，Benioff 似乎是有計畫地逐步實現Business Web的理想。在這七年之中，salesforce.com 依序推出了Sforce、customforce、multiforce與 AppExchange 等創新概念，不斷提升自身的On Demand實踐層次。Salesforce.com近年來的發展歷程如下表所示：

時間	創新概念	特色說明
2003	Sforce	提供了程式開發的工具與技術支，讓開發人員可以在salesforce.com上修改與撰寫程式，也強化了salesforce.com與企業現有系統整合的彈性，是salesforce.com邁向真正On Demand的開始。
2004	customforce	提供了一套簡單的客製化修改機制，讓企業內的非技術人員能透過視覺化介面快速地對表單與流程進行客製化，甚至建立全新的程式以滿足其業務需求。
2005	Multiforce	提供了On Demand網路作業系統的概念，讓開發人員能在共通的底層資料模型(data model)、安全機制(security model)以及使用者介面上開發程式，salesforce.com由 CRM業者轉向企業應用平台經營的意圖昭然若揭。
2006	AppExchange	提供「企業軟體的eBay與iTunes」，讓開發商擁有一個能接觸到全球企業用戶的虛擬市場，也讓salesforce.com的企業用戶能夠以低成本且快速的方式尋找與評估來自世界各地的企業軟體元件。

隨著各種創新概念的實作與發表，salesforce.com由最初的顧客關係管理代管服務廠商（Hosted CRM）蛻變為On Demand企業應用平台的營運者，在企業應用領域活用了現今所謂的Web 2.0概念，將網路當成了開放的平台來經營並獲得成功。為了持續成長，salesforce.com除了投入創意與腦力之外，背後更需要資金的支持。在圖二中我們可以看到近年來salesforce.com各項重要創新概念的推出以及逐年營收與重要支出費用的趨勢圖，其中有三個值得我們注意的現象：

1. Salesforce.com在2001~2005年總計投入了約三千萬美金（約台幣十億）的研發費用來實踐各種創新概念。
2. 同時期該公司累計投入了約兩億三千五百萬美金（約台幣七十六億）的行銷與業務支出來打造品牌與擴大顧客基礎。
3. 2003年以來，隨著營收的快速成長，投入行銷與業務的費用也一飛沖天，但研發費用則僅緩慢成長，到2005年時的研發行銷業務經費比為一比十。

就前兩個現象而言，顯然創新的實踐是必須付出研發經費作為代價的，而為了建構出營運良好的On Demand企業應用平台，則必須投入大量的業務與行銷費用，以期用戶數量與平台上的流通元件數能早日達到關鍵多數（Critical Mass）。一旦達到關鍵多數後，大量的用戶會吸引開發商的投入，而充沛的可用元件則確保用戶的需求能被滿足，產生平台體系正循環的動能。

而第三點現象我們將放到文章的後段再行分析探討。相較於salesforce.com在研發與行銷業務上的資金投入，國內廠商由於公司規模較小，在研發與行銷上的投入也顯得不足，若要自行建構平台可能會因受限於資金而遭遇困境。面對這樣的市場發展趨勢，互相結盟建構聯合營運平台，或是轉型為元件開發者加入既有平台是另外兩個可能的方向。

Salesforce.com的核心經營模式不外乎「On Demand」一詞。但On Demand其實有好幾重意義，許多人談到O nDemand時往往將數種定義互相混淆用，造成討論與理解上的困擾。事實上企業應用的On Demand可分為三個層次：照錶收費、按需調整、隨選即用。

以下我們將針對要達到這三個層次必須提供的功能、服務，以及相關的技術進行說明。所謂「照錶收費」就是不再一次賣斷整個套裝軟體給用戶，而是讓用戶依據使用量來付費，一般都是以提供代管服務（hosted）以及訂閱收費（subscription model）的方式來經營。在多年前曾興盛一時隨即泡沫化的系統服務提供廠商（application service provider, ASP）所做的On Demand大抵上就只達到這個層次。

此模式對用戶而言主要的優點為初期投入成本低，相較於傳統顧客關係管理系統的導入經常在建置期即付出大量成本，訂閱模式讓用戶能夠以近於「先試試看」、「步步為營」的方式嘗試導入顧客關係管理，風險相對較低。對於付不起傳統套裝顧客關係管理導入專案龐大支出的中小型企業用戶尤其有吸引力。

而更上一層的「按需調整」就是要滿足用戶的客製化以及整合需求，畢竟一樣米養百樣人，由人組成的企業自然也個個不同，因此On Demand企業應用系統必須要有足夠的客製化彈性來滿足用戶需求，而非要求用戶改變自己的業務流程來配合系統。為了達到按需調整目的，一般必須滿足三個條件：

1.客製化能力

對於以資料庫和商業流程為中心的企業應用軟體來說，所謂客製化能力主要包含了：（1）自訂資料表與欄位與（2）自訂工作流程兩大部分。salesforce.com以「meta data/declarative development」風格的開發工具來提供客製化能力。由於On Demand架構中會有許多使用者共用同一個實體資料庫，為了系統的安全與穩定，不可能讓使用者直接對實體資料庫進行修改。因此salesforce.com便透過新增邏輯中介層的方式將開發者與實體資料庫隔開，讓開發者透過salesforce.com提供的AppExchangeBuilder開發介面自由增刪自訂物件（Custom Object），也就是一個邏輯上的資料表，藉著操作自訂物件的方式在不直接碰觸實體資料庫的前提下滿足用戶對資料庫的客製化需求。

2.外部系統整合能力

外部系統的整合則可依照整合的方向分為兩大類：（1）以salesforce.com為企業內運作流程主體，將外部系統的資料整合進來；（2）以既有外部系統為運作主體，將salesforce.com中的資料整合至外部系統流程中。在第一類的整合需求上salesforce.com 提供了一種彈性擴充機制，開發者可以上傳自行開發的ActiveX、JavaApplet或其他物件，並以撰寫HTML及JavaScript的方式來調用控制這些物件。因此開發者可以透過此項機制配合AJAX、JavaApplet、ActiveX以及Web Service等技術開發出無縫整合外部資料來源的元件：現有外部系統以Web Service提供資料整合介面，AJAX、JavaApplet與ActiveX則扮演與外部資料來源互動，並決定資料呈現邏輯與方式的角色。而在第二類的整合中salesforce.com則是提供了一組以Web Service為基礎的應用程式開發介面（API）供外部系統叫用，讓外部系統能夠取用salesforce.com系統中的資料，主要使用的技術為Web Service。同時salesforce.com也提供了各種開發工具使用的工具包（toolkit），提升開發者的工作效率。

3.提供大量第三方元件
除了自行開發核心顧客關係管理元件之外，透過開放開發工具與平台介面，salesforce.com也吸引了許多開發人員在AppExchange平台上進行開發，提供了用戶更多可以選擇的元件。

最上層的「隨選即用」則是更嚴苛的要求，要讓用戶在最短的時間內完成客製化的調整。最理想的狀況便是能直接在線上挑選安裝新元件，讓元件的新增如同在iTunes上買一首歌一樣簡單—直接在線上搜尋自己需要的功能元件，線上付款→馬上安裝→即刻使用。為了達到這樣的層次，必須達到：

1.預先整合式（pre-integrated）的元件開發
為了讓使用者找到理想的元件後能夠迅速地安裝並上線工作，所有的元件與應用程式都必須是與平台「預先整合」的，salesforce.com提供了統一的開發與運行平台以及平台API，使得在其上所開發的新軟體與元件能與salesforce.com上的其他程式有良好相容性，讓使用者在添加新元件時不需要為整合問題傷太多腦筋。知名網路電話廠商Skype所開發的網路電話會議程式就是個典型的例子，Skype透過AppExchange上的開發工具開發程式，並透過其平台API存取salesforce.com內建的核心CRM系統資料庫，使用者只需要點幾下滑鼠，便能將此程式安裝至其salesforce.com系統內，且能即時整合資料庫中的資訊，依據該使用者CRM系統中的商機（Opportunity）資料提供網路電話會議功能。

2.簡化元件的搜尋、評估與交易機制

電子商務技術的進步， 簡化了許多商品搜尋、評估與交易的機制， 也成就了Amazon.com、eBay與iTunes等服務的成功。如今salesforce.com將這一套作法轉移到企業應用元件上頭，以「企業應用軟體的eBay」概念提供了AppExchangeDi rector y這個元件的集散與交易中心， 大幅簡化元件的搜尋、評估與交易機制。讓用戶不用上窮碧落下黃泉地苦苦尋覓， 只要到AppExchangeDirectory就能找到市面上大多數的salesforce.com元件，直接在線上瀏覽與搜尋各種企業應用元件，閱讀相關說明、評論與用戶評分，且在線上快速地訂購安裝至自己的企業應用平台中。

3.強化開發者與用戶間的連結，降低第三方元件與用戶需求間的落差

透過 AppExchangeDirectory元件交易平台，開發商與用戶間得到一個能夠互動溝通的管道，讓元件開發商能更清楚知道什麼樣的元件有較大的需求，而企業用戶也更容易找到自己所需要的元件。從而避免過去應用服務提供商（ASP）經常無法滿足客戶實際需求的狀況。

在前面我們分析了salesforce.com透過哪些技術來支持On Demand經營模式，現在我們來談談salesforce.com的經營發展策略。我們可以透過圖五來解釋其策略方針：salesforce.com遵循了80-20法則，首先自行開發了最核心的，屬於80%多數企業共通需求的20% 顧客關係管理功能元件，以此建立基本的用戶規模。

接著構築AppExchange平台吸引其他廠商進來開發另外80%的各種利基市場元件，藉此滿足更多用戶的需求並擴大用戶規模，而用戶規模的擴大則吸引更多元件廠商投入，理想上這將形成正循環，並帶來salesforce.com、企業用戶、元件開發商之間的三贏局面，讓salesforce.com、用戶、開發者結合成一個互相依存的生態體系（Ecosystem）。

事實上，建立生態體系的策略並不是新觀念，即便是「傳統」大廠的企業應用產品也都有各種合作夥伴計畫與第三方元件廠商的參與。但AppExchange的概念顯然更為開放，它的自我定位不僅只是一個企業應用系統，而是運用Web 2.0觀念的開放式平台，將網路當成商業平台（Business Web）來經營。

Benioff的終極理想是透過這個平台讓軟體開發進入所謂「社會生產」（social production）的階段，將開發的資源與權力賦予給任何有意願參與的人，讓軟體開發像寫blog一樣容易，任何有興趣的人都能透過輔助工具在標準化的開放平台創造與交流自己的智慧結晶，藉此塑造出一個開放且充滿生產力的社群。與此同時，鼓勵開放程式介面的Web 2.0式開發風格也造就了Benioff所謂的「企業級混搭程式」（enterprisemashup），讓開發者透過結合現有資料來源與服務便能快速地組合出新的應用程式。

當然，由平台API開放扯到「讓軟體開發像寫blog一樣」或「社會生產」云云是有點陳義過高甚至打高空了。不過換個角度來看，salesforce.com開放平台的經營方式也隱然揭露出一種「一把大傘大家撐」的體系合作策略輪廓。Salesforce.com的品牌與平台就像一把大傘一樣，把所有的元件開發商覆於其下。讓長於技術，但苦於公司能見度低，所能接觸之客戶規模太小的小型元件開發商能夠專注於優勢領域的元件研發，而通路、行銷、拓展顧客規模等議題則交給salesforce.com負責。

由於AppExchange實際運作的歷史還不長，這樣的合作策略是否可行還需要一段時間的觀察，不過這個品牌大傘的概念其實相當有趣。在過去我們認為軟體廠商必須投注相當的研發經費方能維持產品創新的活力，也才能維繫顧客的忠誠，然而salesforce.com在2005會計年度卻呈現出完全相反的現象：行銷與業務費用佔了總營收的55%，而研發費用則僅佔5%。相較於其他廠商通常在10%以上的研發費用Siebel則超過20%），salesforce.com的研發/行銷業務支出比例難免令人懷疑這家公司近年的榮景是不是靠行銷與廣告堆積出來的假象。不過如果這種由salesforce.com負責品牌與平台研發，其他合作廠商則專注於利基元件研發的品牌大傘策略可行的話，行銷與業務遠高於研發費用的狀況倒是相當合理。