第五章 技術(shù)的設計（二）

5.3 服務請求

。。為了提供請求的服務，目標系統(tǒng)要以企業(yè)CRM方案為基礎，該方案是為委托客戶和客戶服務專業(yè)人員制定的，可以幫助他們輕松地提交、獲取、處理和跟蹤服務情況，并且快速準確地解決問題。

具體說明，運行呼叫中心系統(tǒng)的CRM方案必須：

• 對公司現(xiàn)有產(chǎn)品和服務水平表示不滿
• 標準基礎上--允許應用程序改進（不需要改變"編碼"），適應公司不斷變化的需求和運行策略
• 可延伸--支持公司提供的發(fā)展中的服務"清單"
• 可提高--使公司能夠支持隨時間不斷增加的使用目標系統(tǒng)的委托客戶數(shù)量。

更詳細地說，運行目標系統(tǒng)的企業(yè)CRM方案應含有下列內(nèi)容：

• 應用和登記辦法：能夠收集并處理（綜合后備辦公辦法支持）登記和應用信息，以便公司服務、許可、執(zhí)照和事件的處理。
  。。不過在技術(shù)上二者有很大區(qū)別。例如，遠程過程調(diào)用（RPC）中間件以過程調(diào)用類似概念為基礎，本質(zhì)上會發(fā)生同步化和堵塞。

  因此，RPC基礎的中間件要求：

  • 客戶程序和服務器在服務請求期間同時可用
  • 客戶等候服務器應答后再進行其他工作

  。。顯然，這種程序模式已不適用了。舉例來說，即使不是服務請求時間，公司也可能要收集、儲存、給后臺辦公系統(tǒng)傳達服務請求信息。如果技術(shù)同步化，使用RPC是不能進行這些工作的。同樣地，服務請求系統(tǒng)也可能需要同時查詢各個后臺辦公系統(tǒng)。使用RPC系統(tǒng)也不可能進行工作，因為技術(shù)堵塞，需要客戶等候遞交請求的回復，然后再遞交別的請求。下面的圖表說明了這一過程。

  
  

  。。RPC技術(shù)的一個替換方案是信息發(fā)送中間件。信息發(fā)送和信息排隊技術(shù)利用信息傳送和排隊技術(shù)支持應用程序進程間通信。信息傳送模式可使客戶通過發(fā)送信息給服務器呼叫API并發(fā)送服務請求。許多運行過程中，信息發(fā)送模式通過排隊和保證發(fā)送措施得到提高，可以非常靈活并不同步地儲存，進行聯(lián)絡。這種不同步模式加上綜合傳送橋梁服務系統(tǒng)，可以完美地運用廣域網(wǎng)絡技術(shù)發(fā)送信息--在此范圍內(nèi)不能同步使用分配的資源。下面的圖表描述了信息排隊模型。

  

  。。舉例來說，一些公司的呼叫中心系統(tǒng)運用兩種信息發(fā)送產(chǎn)品結(jié)合了所需的后臺辦公方案。它們是IBM公司的MQ系列以及Mitem 有限公司的MitemView 。更具體地說，MitemView 用于緊密地將呼叫中心系統(tǒng)"結(jié)合"后臺辦公方案包括IBM3270，或類似的終端設備。該方案不要求以任何方式修改現(xiàn)有后臺辦公方案，也不要求在系統(tǒng)上安裝其他軟件。也就是說，MitemView運用提供終端圖像服務的數(shù)據(jù)流建立要求的應用程序界面，這在下圖中有所說明。

  

  。。當后臺辦公方案不能提供3270或類似界面時，就要使用IBM公司的MQ系列。作為呼叫中心系統(tǒng)的一部分，通過持續(xù)排隊和保證發(fā)送服務，MQ系列可以不同時不堵塞地發(fā)送信息。這些服務可以保證正常閱讀排隊中的客戶請求，并在業(yè)務委托和確認之前都能進行--即使排隊運行環(huán)境不穩(wěn)定或在程序中發(fā)生錯誤的情況下也能工作。

  。。在決定中間件研究怎樣結(jié)合特別的后臺辦公方案之前，需要進一步分析公司的歷史數(shù)據(jù)和后臺辦公方案。
  

   

  本文由作者向CTI論壇提供

  回到 李博士專欄——呼叫中心構(gòu)建規(guī)劃指南