五年前讀過的一篇史于的《消失的中間件》，至今記憶猶新，主要內容是2002年7月25日，BEA公司在中國宣布其主要業務從原來的做中間件轉變為提供基礎件（application infrastructure應用基礎架構軟件）。由此，中間件這個概念似乎從市場宣傳輿論中“消失”了，被基礎件取而代之。其實，基礎件就是由中間件延伸而來的整合版本的軟件產品，然而它符合了最新的應用趨勢。所以，雖然國內這一市場尚未起步，可是新一輪角逐的序幕已經拉開了。

　　五年過去了，驚嘆于歷史的重演，回顧2007呼叫中心的市場，呼叫中心中間件同樣面臨著風光不再的境地。由于企業市場的井噴，中間件四面楚歌，中間件廠商需要突圍，尋找新的發展之路。

　　中間件風光不再

　　呼叫中心發展的歷史中，呼叫中心中間件起到了重要的作用，呼叫中心中間件將通信廠商和業務軟件開發商整合在一起，讓兩個不同領域的技術和業務無縫連接，形成了呼叫中心整體產業迅猛發展的局面。試想沒有呼叫中心中間件，提供BOSS、金融業務、電子商務、政府業務等等的廠商需要潛心研究復雜的呼叫中心的交換機、板卡、錄音、協議、接口，一個呼叫中心的建設周期至少延長幾倍；提供通信交換機、語音板卡和錄音板卡的廠商，需要針對不同行業了解業務，完成一個呼叫中心建設幾乎是不可能的。

　　于是，10年來，呼叫中心中間件市場逐步啟動，形成了一批很有影響力的廠商，成為整個產業鏈重要的一環。而呼叫中心中間件的概念也在不斷擴展。最早的呼叫中心中間件用于屏蔽交換機的差異，對上提供CTI開發的統一接口，代表公司是當時的Dialogic的CT Connect；之后，中間件的概念為屏蔽交換機、語音板卡、傳真板卡、錄音板卡的差異，對上提供統一的接口；到現在，呼叫中心中間件對于運營管理的支撐要求越來越高，需要報表、監控、實時統計、錄音調聽等等。

　　未來的呼叫中心建設要求與目前的建設方式有很大的差異。主要表現在三個方面：

　　第一，隨著呼叫中心在企業地位的不斷提升，呼叫中心的基礎信息將成為除了包括運營管理以外，幾乎所有的企業信息系統需要的重要的數據，這樣，廣泛而深入的集成是必不可少的，整合的層面不能只停留在座席軟電話和數據庫共享的整合上；

　　第二，接入渠道的整合方面是呼叫中心歷來的難點，包括音頻交互、視頻交互、文本交談、護航瀏覽、表單共享、應用共享、電子白板和桌面共享等接入渠道，而且不是簡單的接入，而是一個完整的運營管理和信息共享；

　　第三，產品化和個性化之間的矛盾越來越難以調和，產品廠商做交付，交付廠商想做產品，強勢產品廠商將基礎功能需求（如在IVR之前的黑名單功能）強加給集成商，強勢的集成商將非常個性化的功能需求強加給產品廠商（如讓產品廠商提供大量的界面）。

　　因此，中間件的定位越來越模糊，最直接的體現就是2007年以前，大型呼叫中心的招標經常將中間件進行單獨招標，而2007年以來，單獨招標的情況越來越少，中間件的各種功能在軟件部分體現，并且和業務的耦合度越來越高。

　　進一步分析總結，長期以來，一方面，中間件提供的屏蔽差異的作用一直沒有變化，沒有為用戶或集成商提供更多的價值；另一方面，而呼叫中心的需求一直在增長，價格一直在降低，建設周期一直在縮短，集成商所做的工作一直在增加，因此，作為產品形式出現呼叫中心中間件的地位就越來越低，風光不再了。

　　中間件在企業市場的四面楚歌

　　回顧2007年呼叫中心市場，最典型的特征是企業呼叫中心市場達到了井噴，從座席數到建設投入已經超過電信和金融呼叫中心。

　　企業市場包括電視購物、DM、電子商務、家電、商旅服務、商業、煙草等等。

　　企業呼叫中心的特點是盈利型呼叫中心，由于呼叫中心的收益可以量化，呼叫中心的建設周期短，初期投資小，但是隨著業務的增長，座席規模相對發展較快，資金投入也相對增加較快。

　　企業呼叫中心在建設方面與電信和金融呼叫中心有很大差異：

　　第一、企業呼叫中心建設投資規模比較小，建設周期比較短，前期設計比較粗糙；

　　第二、集成商水平參差不齊，呼叫中心的細節了解過少；

　　第三、企業呼叫中心管理者對呼叫中心認識差別很大，一類是沒有接觸過呼叫中心的管理者，對呼叫中心規范了解甚少，一類是電信或金融培養出來的座席或班長，對大型呼叫中心了解很多，因此，對呼叫中心的功能需求差別很大；

　　第四、呼叫中心隨業務調整變化很大，缺乏業務規范；

　　第五、建設咨詢沒有形成規范，建設廠商非常分散。

　　基于以下原因，呼叫中心中間件在企業市場上可謂四面楚歌。

　　第一方面、交換機廠商的擠壓

　　交換機廠商紛紛重拳出擊，力推自己的中間件，無論是AVAYA、Alctel和Nortel，都在市場上大力推廣自己的品牌。交換機廠商的中間件雖然未必是原廠的產品，在功能、開放性和技術支持方面，未必可以與獨立的中間件媲美，但是畢竟在市場宣傳上有很好的品牌效應，在銷售上有很好的捆綁降價力度。因此，交換機廠商對呼叫中心中間件廠商擠壓的力度是很大的。

　　第二方面、集成商的擠壓

　　由于用戶資金投入少、建設周期短、管理者認識水平低、沒有明確的規范，集成商經常選用低成本的中間件、或者只采購中間件的很少的模塊，其他的部分，根據用戶的需求定制。筆者接觸了若干集成商，他們熟悉TSAPI、CTCAPI，了解報表各項指標的形成機制，可以大量取代中間件的工作，進一步擠壓中間件的市場份額。

　　第三方面、用戶需求急速提升帶來的壓力

　　很多用戶的管理者來自電信和金融的呼叫中心，他們在投資50萬元軟硬件建設一個50座席的呼叫中心的時候，要求系統具備5000萬元呼叫中心需要的智能ACD、實時統計、預測外撥和Internet呼叫中心的所有功能。同時，要求中間件具備隨著業務需求發展不斷變化調整的能力，他們會在三個方面去要求中間件廠商，第一，產品的開放性達到可以適應這種變化的要求；第二，要求中間件廠商按照交付的方式提供新的功能；第三，最為甚者，要求中間件廠商提供駐場服務，隨時修改。

　　第四方面、集成商數量的迅速增加帶來的壓力

　　幾年前，呼叫中心的集成項目被為數不多的行業集成商壟斷著，中間件廠商只需要和他們的軟件進行對接即可，算起來，一個中間件廠商只要能和10個左右的集成商系統對接就可以“旱澇保豐收”了。而現在，數量隨著企業市場的“井噴”，集成商數量迅速增加，10個遠遠不夠，包括潛在合作伙伴在內，至少需要四五十個。這四五十個集成商開發工具不同、軟件架構不同、應用領域不同。于是，中間件的日子更難過了。

　　四面楚歌的中間件亟待尋找突圍之路。

　　突圍

　　筆者認為，中間件廠商的突圍不是指業務轉型，比如轉型做電信增值業務、做外包運營、做系統集成等等，而是尋找中間件新的發展道路。

　　再次感嘆歷史的重演，從BEA的基礎件（application infrastructure應用基礎架構軟件）戰略中我們能夠感悟很多。

　　中間件向基礎件的發展，似乎成為必然，然而，過程會非常曲折，需要大量的資金投入，并且充滿風險。

　　筆者建議，中間件廠商的突圍應從以下幾個方面入手，才能減少投入、增加收益、規避風險，最終贏得勝利。

　　第一、縝密的成本構成分析

　　中間件向基礎件發展，首先需要分析我們將哪些部分作為基礎件的組成部分。這就回到了中間件產業產生的原因，降低總體建設成本。

　　多說幾句，例如，一個功能，中間件提供，需要研發、內測和多個項目的測試，功能豐富穩定，總體研發成本是30萬，實際應用在30個項目中，那么單套成本1萬；集成商提供，針對項目定制，針對一個項目測試，只在一個項目中應用，功能滿足要求，但是穩定性稍差，也滿足要求，研發成本為3萬。用戶和集成商的選擇很明確，應該選用中間件提供的方案。

　　深入一步，如果中間件提供的功能，只能在10個項目中應用，單套成本為3萬，集成商很有理由選擇自己來做。

　　再深入一步，如果中間件提供的功能，單套成本為1萬，集成商的集成或二次開發工作是2萬，那么集成商也有理由選擇自己來做。

　　縝密分析是絕對必要的，既要計算功能研發的成本、攤薄成本，也要計算集成商集成或二次開發的成本，而以下的所有的突圍都是基于這些分析。

　　第二、可視化開發工具的豐富

　　可視化開發工具是有效降低集成商二次開發成本的手段。如IVR圖形化開發工具，被業界廣泛認可，這與行業標準如Voice XML的產生有直接的關系。

　　然而，ACD圖形化開發工具、報表圖形化開發工具和監控圖形化開發工具在中間件產品中頗為罕見，原因只有一條，對“成本構成分析不夠縝密”。

　　圖形化開發工具本身的技術門檻是非常高的，首先，規范制定難度大，如果不能很好的定義需求、規則、開發方式，很容易被項目的需求左右甚至摧垮；其次，解釋執行不是件容易的事，就像IVR解析執行服務器一樣，需要長期的測試；最后，圖形化開發工具開發本身也是需要耗費大量人力物力的。

　　可是，投入是值得的，我們只需要簡單計算一下如果沒有IVR可視化開發工具，中間件廠商需要額外投入多少成本在項目實施中，就可以大致計算出有了ACD圖形化開發工具、報表圖形化開發工具和監控圖形化開發工具帶來的收益了。

　　第三、B/S架構

　　提B/S架構我自己都覺得很吃驚，但是確實很多老牌中間件廠商是不支持的。筆者在這里并不是說C/S沒有競爭力、落后、沒有價值，只是針對“縝密的成本構成分析”而言，C/S太吃虧了。

　　試想，JAVA和.net的B/S多么流行，C/S整合起來成本高多了。主管的網頁上要點擊一個鏈接看一下報表、監控和實時統計或者調聽一兩個錄音，對于B/S架構太簡單了，在權限允許的情況下，傳送一個html請求即可，而對于C/S架構的中間件就難了，中間件廠商有三個解決方案，方案一，你重新打開我的軟件，重新登錄，再使用，“我可不管主管的感受”；方案二，我給你開發一個OCX接口或WebService接口，你的B/S的軟件來調用吧，“你累我也累”；方案三，你訪問我的數據庫吧，“反正密碼大家都知道”。

　　B/S架構已經是突圍所必須的，當然，WebService方式的分層也是必備的，保證B/S和C/S的通用。

　　反過來思考，對于中間件廠商來說，B/S是的研發是有難度的，因為中間件的底層更多的是C++，而且實時監控也用到了大量的比較新的技術如AJAX。然而，“縝密的成本構成分析”之后，你會覺得值得投入。

　　第四、數據共享形式規范化和多樣化

　　數據共享是企業呼叫中心近年來凸現的需求，特點是一點數據個點都要體現。為了理解深刻一點，我們看看以下幾個用戶要求的實例吧：

　　1、報表匯總指標中有每一個小時的每個座席組中每座席的呼入量、平均呼入通話時長、平均應答時長、呼出量、平均呼出通話時長、咨詢次數、平均咨詢時長、會議次數、平均會議時長、保持次數、平均保持時長、登錄時長、就緒時長、后處理時長、平均后處理時長、未就緒時長、置忙率、使用率、空閑率；既然可以，那么我在班長使用的實時監控統計部分每1分鐘我要看到每小時開始到現在這分鐘的這些指標，中間件廠商說“可以”；如果這也可以，那么，我需要在每個座席軟件上也要實時顯示出來，中間件廠商說“那可以吧”；如果這也可以，那么，我需要整合在我的OA系統中，保證老板在任何時候，上網即可看到所有的數據，當然是實時的，中間件廠商說“那我們定制開發一下，可以吧”；如果這也可以，那么，我需要把這些數據整合在你們的錄音系統中，錄音系統既然可以實時看到每條線路的狀態，我要保證質檢人員能同步看到這些數據，當然也是實時的，中間件廠商說“那我們定制開發一下，可以吧，需要加錢了”，而回答往往是沒有預算了；

　　2、信息當然應當是共享的，我們需要您的ACD、IVR、軟電話、報表、監控、實時統計、錄音系統實時的關聯我們的業務數據，如電話叫車客戶的性別、區域、歷史叫車次數、等級和被叫的駕駛員的車號、駕駛員號要同步顯示在軟電話上、報表記錄中、監控指標里，按照類別要實時統計（如按一分鐘），錄音系統里面這些資料也要全的；

　　3、你們的軟電話功能非常全，我一定用你們的軟電話，但是我只是想增加一個按鈕，叫做開會培訓狀態，以便在監控、報表中做工作量統計，還有，我認為你們填寫的呼叫號碼的對話框布局不好，調整一下，你總不能不給我改動吧；我覺得你們的報表很好，我只是想加入我們的一些統計分析指標，當然需要填寫一些輸入參數，表格的樣式還是有比較大的區別，我們用您的報表，我們沒有源代碼，您們幫我們做一下，應該不需要付費吧；實時統計很好，只是改動一點點，我們需要的是按照客戶的五種特性分類做顏色顯示，改動很小吧；

　　以上的數據共享困擾著無數中間件廠商。滿足客戶的要求，意味著軟件版本的混亂，交給集成商來做，集成商難以完成，而大量工作是對以前的基礎工作的拋棄。

　　“縝密的成本構成分析”是解決的方式，首先要有足夠的規范，界定工作范圍，超過范圍的應由項目經理控制；其次，開放性在多個層次保證，不能修改一個功能，所有功能全部拋棄；最后，也是最難的地方，作為基礎架構，應該有足夠的開放性，保證以上需求的低成本實現。

　　第五、標準功能的基礎化

　　五年前，聽中間件廠商說:“呼損報表指標，那是業務，集成商做吧”；

　　四年前，聽中間件廠商說:“錄音，那是第三方的產品，集成商做吧”；

　　三年前，聽中間件廠商說:“實時統計，那是第三方的工作，集成商做吧”；

　　兩年前，聽中間件廠商說:“黑名單，那是業務，集成商做吧”；

　　現在都不敢這么說了，標準功能必須基礎化。

　　重點說幾個方面經常用到的功能，應該通過簡單配置即可使用的標準功能：黑名單、紅名單、座席通過IVR對通話錄音的調聽、自動報工號、報排隊數、會議錄音、客戶掛機前進行滿意度調查、座席轉IVR進行密碼輸入或收聽公告、分布式呼叫中心的數據集中和語音智能勸阻機制等等。

　　通過“縝密的成本構成分析”，中間件廠商應該對自己所處的領域的需求分類，逐步加深。

　　第六、Internet接入

　　Internet接入是將來利潤比較豐厚的部分，請參考筆者在其他“第五代呼叫中心”方面的文章。

　　機遇與挑戰

　　新的機遇，新的挑戰，2007年即將過去，2008即將開始，再次感嘆歷史的重演。但愿中間件廠商能夠不讓中間件真的“消失”，而是通過縝密的成本構成分析，發揮我們的智慧、付出我們的勞動，讓這個行業更快更好的發展。秉承“合作共贏、誠信為本”的商業理念，商路通期待與廣大合作伙伴共同打造一條市場共享、知識共享、技術共享、健康發展的呼叫中心產業鏈。

作者為北京商路通信息技術有限公司副總經理、技術總監。