盧偉開,周英耀
(南方電網數字電網研究院有限公司平臺安全分公司,廣東廣州 510000)
傳統的呼叫平臺主要以交換機和語音板卡為核心,隨著計算機、互聯網、電信等技術的飛速發展,以呼叫中心平臺軟件和互聯網平臺為核心的完全開放的呼叫平臺已逐步取代了傳統的呼叫平臺[1]。當前,對于這類標準呼叫平臺的成熟度評估還缺乏統一的評價標準和評價機制,無法準確地評價其運營能力水平[2]。目前基于Android 平臺的評價系統可對呼叫平臺進行成熟度定位,但由于缺乏修正與驗證,評價結果不可靠[3]。分布式Agent 等級評價系統雖然對評分方法進行了大量的改進,但是由于數據量大,其方法缺乏代表性[4]。為此,針對目前存在的問題,提出了呼叫平臺能力成熟度等級評價系統多模塊設計。
呼叫平臺能力成熟度等級評價系統多模塊結構設計需要實現三方面需求:數據收集,在各個呼叫項目中收集所有評估子項目的響應數據,即數據輸入和存儲;數據處理,對存儲的原始數據進行處理、過濾、計算和分析;成熟度信息顯示,成熟度信息由數據處理產生,并由此得到呼叫平臺成熟度評估報告。
在MVC 模型-視圖-控制器架構中實現了業務邏輯、界面顯示和數據分離,因此,可將評價系統多模塊結構分為業務邏輯層、展示層和數據存儲層三個層次[5]。評價系統多模塊結構如圖1 所示。

圖1 評價系統多模塊結構
由圖1 可知,業務邏輯層包括移動APP 終端、虛擬驅動器和座席模塊,是用于實現呼叫平臺成熟度評估的業務邏輯結構層;展示層是呼叫平臺能力成熟度等級評定的布局實現部分,包括顯示能力成熟度評定界面和顯示評定結果輸出[6-7];數據存儲層負責對平臺能力成熟度級別評估項目的數據資源文件的存儲和調用,以及存儲能力評估問題和重要級別數據。
在安裝了移動APP 終端之后,系統將提供虛擬機調試功能。使用這種虛擬裝置,移動終端可以模擬其運行環境,從而方便地評估呼叫平臺的功能成熟度[8-9]。移動APP 端結構如圖2 所示。

圖2 移動APP端結構
根據圖2 可知,該移動APP 終端避免了系統被瀏覽器劫持,減少了對搜索引擎的依賴,使用方便快捷,界面一致,確保用戶不受第三方的干擾。
1.2.1 業務邏輯層與數據存儲層的接口設計
此接口設計用于通過共享存儲器實現業務邏輯層與數據存儲層之間的通信。該存儲器被劃分為4個區域:參數傳遞區,主要負責存儲系統級別的變量,外設程序可以直接修改一個變量來改變運行參數;請求處理區,主要負責與外部進程對話的請求處理[10];系統輸出區,主要負責將部分信息輸出到系統外;數據交換區,該區域主要負責在消息服務層和業務邏輯層之間進行通信。
1.2.2 業務邏輯層與展示層的接口設計
此接口設計用于業務邏輯層與展示層之間的通信,展示層通過共用存儲器將大部分共享內存消息發送給業務邏輯層,然后業務邏輯層將小部分共享內存消息發送給虛擬驅動器[11]。其余剩下部分內存用于存儲以下各種參數:1)呼叫者在接聽電話時所撥號碼的長度;2)掛線、忙音、鈴音和撥號音的定義;3)模擬通道關閉之前的振鈴次數;4)系統語言信息(業務邏輯層負責從系統讀取數據,以供驅動使用);5)語音字典(業務邏輯層負責從系統讀取數據以供驅動使用)。
1.2.3 通用查詢構件接口設計
通用查詢構件接口如圖3 所示。

圖3 通用查詢構件接口
如圖3 所示,現有的組件模型是在深入分析評估系統的基礎上,通過提取穩定和通用的需求而抽象構造的。因為查詢功能是所有模塊必需的,小組將其細化為一個通用查詢構件[12]。在軟件復用過程中,查詢被提取出來作為分析、設計和實現的組件,每個模塊都有一般查詢的需求,為查詢對象提供統一接口,便于其他模塊調用。
在計算機RAM 區域中,虛擬驅動器是物理磁盤區域,其結構如圖4 所示。
從圖4 中可以看出,硬件虛擬化是實現業務系統與信息技術分離,使虛擬業務系統與虛擬資源建立映射關系的重要手段[13]。將虛擬資源與實際物理資源進行映射,從而在邏輯層次上形成標準化的虛擬數據庫,通過虛擬化實現數據中心資源的整合。將虛擬資源與實際物理資源映射,在邏輯層次上形成標準化的虛擬數據庫,通過虛擬化實現數據中心的資源整合。

圖4 虛擬驅動器結構
根據該平臺的實際運行情況和目標需求,建立了呼叫平臺能力成熟度等級評價系統多模塊的標準模型,如圖5 所示。

圖5 成熟度模型
依據圖5 所示的成熟度模型,定義成熟度內容,如表1 所示。
由于各個平臺能力等級建設水平不同,在復雜的平臺環境和呼叫服務量大的情況下,如果采用一個級別對每個領域和指標進行評估,則無法準確反映每個平臺的實際情況[14]。而單獨進行評估,則難以反映總體能力,因此設計了E1-E5 級別的能力評估覆蓋百分比,并通過相應領域的加權平均對其進行評分,成熟度級別分值為0~100,呼叫平臺能力評分等級劃分如表2 所示。
在獲取評估數據之后,程序從平臺輸入的評估系統中直接讀取評估數據,調用評估程序配置信息,并評估模型數據。
為清晰地顯示計算過程,在式(1)中設置永久映射Pl:

n個子流程的成熟度等級加權平均,其計算結果為總百分比,默認未劃分的n個子流程成熟度的權值為1[15]。對呼叫平臺能力進行性能成熟度評估,以獲得整個調用平臺的性能成熟度,計算公式為:

采用雷達圖分析方法可以總結并顯示評估在調用平臺不同方面的結果,雷達圖可以靜態地顯示相應流程的成熟度[16],可以更好地比較流程的成熟度,從而使決策者能夠在評估后構建下一階段。
在第一期工程完成后,重新獲得了新評估的雷達圖數據。相對于以往評估結果展示方式,新的雷達圖分析法能夠動態顯示呼叫平臺能力的發展變化,明確其發展趨勢和關鍵點,使呼叫平臺的服務水平得到了進一步提升。采用雷達圖分析法,可以統一顯示評價范圍內的流程成熟度,能夠更加直觀地顯示各流程的成熟度階段。
以某電力客服服務中心為例,驗證呼叫平臺能力成熟度等級評價系統多模塊設計合理性。
呼叫平臺系統結構如圖6 所示。

圖6 電力客服服務中心呼叫平臺系統
由圖6 可知,系統是將電力營銷、電力調度等全部集中到同一平臺上,以此處理客戶撥入的通話,并將電話合理分配給座席人員。
以評價周期分數和成熟度雷達圖為對象,分別使用基于Android 平臺(Q1)、分布式Agent 等級評價系統(Q2)和該文的等級評價系統多模塊結構(Q3)進行對比分析。
3.2.1 評價分數分析
評價分數對比結果如表3 所示。

表3 評價分數對比結果/分
根據表3 可知,使用基于Android 平臺在E2、E4兩個等級中,評價分數在實際分數值范圍內;使用分布式Agent 等級評價系統在E2、E3、E4、E5 四個等級中,評價分數在實際分數值范圍內;使用該文的等級評價系統多模塊結構所有等級均在實際分數值范圍內。由此可知,使用該文的等級評價系統多模塊結構評價分數分析結果更加精準。
3.2.2 成熟度雷達圖分析
成熟度雷達圖對比結果如圖7 所示。
根據圖7 可知,基于Android 平臺(系統A)在停電預告、電話調查、語音信箱方面成熟級別較低,在Web 大廳、欠費催繳、郵件和傳真處理方面成熟度較高,短信服務處于中等水平;分布式Agent 等級評價系統(系統B)在短信服務、欠費催繳、停電預告、語音信箱、郵件方面成熟度較高,Web 大廳成熟度中等。而使用該文的等級評價系統多模塊結構(結構C)在Web 大廳、欠費催繳、停電預告、電話調查、語音信箱、傳真處理、短信服務、郵件方面成熟度均較高。

圖7 成熟度雷達圖對比結果
在分析智能、自動化呼叫平臺運行能力的基礎上,結合智能呼叫平臺運行狀態,構建成熟度等級評價模型。經過成熟度級別評定,提高了平臺運行能力,促進呼叫平臺運行維護水平的快速提高。目前雖然已經實施了呼叫平臺能力成熟度的評估,但是還需要改進。因此,在下一階段應在已有的基礎上增加成熟度研究內容的深度,擴大評估項目的范圍,使評估更加準確,并考慮實施更全面的呼叫流程,以獲得更全面的呼叫平臺支持能力。