數(shù)據(jù)倉庫和OLAP技術在CRM投訴分析中的應用研究

岳鵬，劉淑娟

（1 重慶郵電大學通信學院 重慶 400065； 2 西南大學計算機學院 重慶 400715）

0 引言

目前的網絡業(yè)務運行監(jiān)控還存在一些問題，精細化程度不夠，難以發(fā)現(xiàn)具體網元的運行隱患；后分析方式的被動監(jiān)控多，主動監(jiān)管少。出現(xiàn)上述問題的一個重要原因就是在日常網絡業(yè)務運行監(jiān)控中，忽略了大量、多種網絡業(yè)務信息（例如非緊急/重要投訴信息）和沒有更可靠的支持主動監(jiān)控技術。

因此，充分利用各種網絡業(yè)務運行信息，通過科學的主動監(jiān)控技術發(fā)現(xiàn)網絡業(yè)務運行中的潛在問題，實現(xiàn)有效的主動監(jiān)控預警分析，才可以及時預警改進，并進一步推進集中監(jiān)控的精細化，提高網絡業(yè)務運行的安全性、穩(wěn)定性。

其次，當前的網絡管理是基于各網元管理系統(tǒng)實現(xiàn)的，在功能上主要實現(xiàn)了網元管理層和各自網絡設備管理層的功能，沒有面向業(yè)務的管理功能。因此故障信息都是基于設備而無法與投訴等業(yè)務和客戶相關聯(lián)。在故障監(jiān)控方面很難做到主動監(jiān)控，目前主要還是接受申告的被動維護。

1 BI解決方案結構設計

鑒于上訴背景, 利用某運營商客服投訴系統(tǒng)近年來長期積累的某運營商客戶投訴數(shù)據(jù)，進行原始數(shù)據(jù)的分析，建立相應的數(shù)據(jù)倉庫, 根據(jù)投訴主題建立多維數(shù)據(jù)集，在此基礎上利用OLAP技術從多角度、多側面、多層次對某運營商CRM投訴數(shù)據(jù)進行分析，對某運營商客戶投訴進行了科學系統(tǒng)的分析評估。進而做針對性的改進，提高某運營商對廣大客戶的服務質量。CRM投訴主題監(jiān)控的BI解決方案整體結構如圖1所示。

圖1 XX運營商CRM投訴主題監(jiān)控的BI解決方案結構

2 CRM投訴原始數(shù)據(jù)分析

原始數(shù)據(jù)分析結果的可行性、有效性、透徹度等，將直接關系最終的多維分析的角度，直接影響某運營商網絡服務質量的真實反映的準度和深度，對最后服務質量的改進起著決定性的作用。

開始至今，積累了相當數(shù)量的客戶投訴數(shù)據(jù)，這些投訴數(shù)據(jù)包含了大量與某運營商服務質量相關的有用信息。通過對大量客戶投訴數(shù)據(jù)的研究，得到與某運營商網絡服務質量相關的主要觀察數(shù)據(jù)主題：(a)網絡投訴量；(b)各公司投訴量；(c)業(yè)務投訴類型統(tǒng)計； (d)不同用戶類型投訴統(tǒng)計分析。

3 數(shù)據(jù)倉庫模型設計

3.1 設計方法

數(shù)據(jù)倉庫(Data Warehouse)是支持管理決策過程的、面向主題的、集成的、隨時間變化持久的數(shù)據(jù)集合[1]。其設計方法有兩種：自下而上和自上而下。自上而下的設計方法強調應用決定數(shù)據(jù)，有什么應用就獲取什么數(shù)據(jù)，設計維度和多維數(shù)據(jù)集是項目的開始；自下而上的設計方法首先要依據(jù)系統(tǒng)文檔與需求分析來創(chuàng)建數(shù)據(jù)倉庫,然后根據(jù)不同的分析主題建立多維數(shù)據(jù)集[2]。

本文采用自下而上的設計方法,圍繞CRM投訴數(shù)據(jù)分析為主題來建立數(shù)據(jù)倉庫。

3.2 數(shù)據(jù)結構

目前最流行的數(shù)據(jù)倉庫多維數(shù)據(jù)結構有3種:星型結構、雪花型結構和混雜型結構[2]。

星型結構是一種典型的數(shù)據(jù)結構，它以事實表為中心，一組維度表在星型結構的頂尖，事實表和每個維度表通過主鍵連接在一起,組成一個星型結構。雪花型結構是用一組或多組數(shù)據(jù)表與某些維度表相互鏈接，進而有效地描述維度表的復雜程度和層次。混雜型結構是綜合了星型結構和雪花型結構的優(yōu)點。

本文綜合考慮，介于某運營商CRM投訴綜合查詢對效率和準確度的追求，最終決定采用星型結構。

星型結構是非范式的、以查詢?yōu)橹行牡哪Ｐ停@種模型的最大優(yōu)點是能夠提供所謂的星連接，即通過一步連接就可以獲取大部分所需要的信息，并很快得到輸出結果，這在常規(guī)的事務處理數(shù)據(jù)庫結構中是很難做到的。在這種模型中信息分為兩大類：事實表和維度表。星型結構對本文主題數(shù)據(jù)查詢十分適合。

數(shù)據(jù)倉庫的模型設計是數(shù)據(jù)倉庫設計的一個重要方面。本文以某運營商客戶投訴分析主題來組織數(shù)據(jù),以CRM投訴作為事實表,以用戶品牌，用戶級別，投訴區(qū)域，故障描述，時間為維度表。

3.3 事實表的粒度

數(shù)據(jù)越詳細,粒度就越小,數(shù)據(jù)級別也就越小;數(shù)據(jù)綜合度越高,粒度也就越大,級別也就越高。而事實粒度需求的不同,一方面將直接導致數(shù)據(jù)倉庫模型設計的差異,另一方面將直接影響存儲容量與分析效果,因此粒度的設計極其重要。

由于本文需求分析中,不僅需要對細節(jié)性數(shù)據(jù)進行分析,而且需要對綜合數(shù)據(jù)進行分析,因此采用了多重數(shù)據(jù)粒度的設計方法。這也是針對業(yè)務量大、分析要求比較高的情況采用的最理想的解決方法[2]。

4 數(shù)據(jù)整合

4.1 數(shù)據(jù)源

業(yè)務數(shù)據(jù)是數(shù)據(jù)倉庫的數(shù)據(jù)源，而對業(yè)務數(shù)據(jù)的了解是設計數(shù)據(jù)倉庫的基礎。只有通過對業(yè)務數(shù)據(jù)的分析，才可以清楚地知道原有數(shù)據(jù)系統(tǒng)中已有什么指標，再結合用戶的需求，才能明確當前數(shù)據(jù)倉庫的設計能提供需求中的哪些指標，還缺少哪些指標。總之，通過對歷史數(shù)據(jù)和需求的分析，可以明確用戶正在使用的數(shù)據(jù)現(xiàn)狀、他們如何使用這些數(shù)據(jù)以及將來利用這些數(shù)據(jù)干什么。

本數(shù)據(jù)倉庫的數(shù)據(jù)來源于某運營商客服服務系統(tǒng)所統(tǒng)計積累的客戶投訴的歷史數(shù)據(jù)，涉及到的數(shù)據(jù)主要有投訴工單號，投訴受理時間，投訴業(yè)務類型，投訴故障描述，投訴區(qū)域，投訴用戶品牌，投訴用戶級別，分公司等。

4.2 數(shù)據(jù)的抽取、轉換與裝載（ETL）

設計好數(shù)據(jù)倉庫的模型之后，就需要把歷史數(shù)據(jù)裝載到數(shù)據(jù)倉庫去。歷史數(shù)據(jù)中存在大量的錯誤的、不一致等問題，數(shù)據(jù)質量是分析結果可靠性的基礎，而ETL(數(shù)據(jù)抽取、轉換、清洗和加載)是數(shù)據(jù)質量的重要保障[3]。ETL包含以下3個過程:

(a)抽取：從多個異構的不同結構或者不同格式的文件中抽取數(shù)據(jù)到目標數(shù)據(jù)庫臨時表中。

(b)轉換：抽取出的數(shù)據(jù)可能存在異常值或者缺失值等情況，為了保證數(shù)據(jù)的完整性和一致性，需要對不同的原始數(shù)據(jù)進行清洗和加工，并最終轉換成目標數(shù)據(jù)所要求的格式。

(c)加載：將以上步驟處理后的數(shù)據(jù)裝載到目標數(shù)據(jù)倉庫的事實表，維度表和視圖表中去。

為了確保數(shù)據(jù)倉庫中的數(shù)據(jù)更加準確，首先對某運營商公司近半年的歷史客戶投訴數(shù)據(jù)進行分析，先將數(shù)據(jù)從數(shù)據(jù)源抽取到臨時數(shù)據(jù)表，并形成一套標準的CRM投訴的業(yè)務代碼對應表，然后建立CRM投訴業(yè)務代碼表清洗規(guī)范，最后采用SSIS(Microsoft SQL Server 2008 Integration Services)逐日對某運營商提供的客戶投訴原始數(shù)據(jù)進行抽取、轉換和清洗,并裝載到目標數(shù)據(jù)倉庫中。最終所完成的ETL流程如圖2所示。

圖2 ETL流程圖

ETL在整個數(shù)據(jù)倉庫系統(tǒng)中的位置處于數(shù)據(jù)源與目的數(shù)據(jù)倉庫之間，貫穿于整個解決方案的全過程，管理數(shù)據(jù)的質量，并且對整個系統(tǒng)的數(shù)據(jù)進行處理與調度。ETL涉及到大量的業(yè)務邏輯和異構環(huán)境，在一般的數(shù)據(jù)轉換項目中ETL部分成為了牽扯精力最多的部分，故而ETL規(guī)則設計和實施約占在整個項目中工作量的60%～80%，這是從眾多實踐中得到的普遍共識[4]。

5 建立OLAP多維數(shù)據(jù)集

在上文中，設計好數(shù)據(jù)倉庫,并且將業(yè)務數(shù)據(jù)經過ETL數(shù)據(jù)整合之后,需要進一步根據(jù)CRM投訴這一分析主題建立相應的多維數(shù)據(jù)集。OLAP多維分析以多維數(shù)據(jù)集為基礎。多維數(shù)據(jù)集是數(shù)據(jù)分析時用戶的數(shù)據(jù)視圖，是面向分析的數(shù)據(jù)型,可以給分析人員提供多種觀察的視角和面向分析的操作,即將數(shù)據(jù)看作多維的數(shù)據(jù)立方體[5]。利用SSAS(Microsoft SQL Server 2008 Analysis Services)建立多維數(shù)據(jù)集。設計出的CRM投訴分析多維數(shù)據(jù)集的數(shù)據(jù)星型模型如圖3所示。

圖3 CRM投訴分析多維數(shù)據(jù)集數(shù)據(jù)模型

圖3模型中,表頭顏色較暗的是維度表，有CRM用戶品牌維度表、CRM用戶級別維度表、CRM故障描述維度表、CRM投訴區(qū)域維度表、時間維度表；表頭顏色較亮的是CRM客戶投訴事實表。多維數(shù)據(jù)集的度量值是CRM投訴量。

多維數(shù)據(jù)集的存儲方式有3種： ROLAP、MOLAP和HOLAP[6]。本文采用MOLAP方式存儲 ,它將細節(jié)數(shù)值和合計數(shù)值都存放在立方體中,可將多維視圖直接映射到數(shù)據(jù)立方體數(shù)組結構。這種存儲方式的優(yōu)點是可以對數(shù)據(jù)立方體的數(shù)據(jù)快速索引[7]。通過對多維數(shù)據(jù)集的切片、切塊、鉆取等多種操作，可以從多個角度分析CRM投訴數(shù)據(jù)，來分析網絡投訴量、各公司投訴量、業(yè)務投訴類型統(tǒng)計、不同用戶類型投訴統(tǒng)計、同地市VIP用戶投訴統(tǒng)計等投訴情況。

6 CRM投訴分析前端展現(xiàn)與結果實例分析

商業(yè)智能的前端產品負責直接面向用戶,將用戶的請求轉發(fā)給服務器層、數(shù)據(jù)層,同時也向用戶展現(xiàn)所需信息。商業(yè)智能前端產品極光商智（ABIS），以圖形等直觀形式，聯(lián)動的調整和展現(xiàn)分析結果。

首先，將CRM投訴分析多維數(shù)據(jù)集，添加到ABIS的數(shù)據(jù)源管理器中。利用ABIS的超級分析器，部署所關注的CRM投訴分析角度和層面，然后保存為共享報表，最后以圖形和圖表形式展現(xiàn)分析結果。

6.1 實例1：網絡投訴量分析

網絡投訴量統(tǒng)計結果如圖4，時間切片選取粒度“月”，圖表中所選為某年某月數(shù)據(jù)，切片還可選擇周為粒度。圖形還可以選擇疊加柱形、曲線、折線等多種圖形形式來展示。

圖4 網絡投訴量柱形圖數(shù)據(jù)表

由圖表所展示的統(tǒng)計信息可看出，該公司的各大片區(qū)的網絡投訴量中，主城區(qū)的投訴量明顯高出各片區(qū)公司近9～10倍，而各片區(qū)之間投訴量相差不遠。這種結果可能由幾種情況導致：(a)主城區(qū)用戶數(shù)量高于各片區(qū)用戶數(shù)量; (b)主城區(qū)用戶密集程度高于各片區(qū)地區(qū)，對設備的使用頻率較高，導致設備出現(xiàn)故障幾率增大；(c)主城區(qū)用戶所用網絡業(yè)務較于各片區(qū)種類繁多，類型復雜，導致軟硬件服務設備更容易產生故障；(d)主城區(qū)用戶對網絡質量要求指數(shù)較高，對網絡狀況出現(xiàn)的問題較為敏感。以上分析中，(b)、(c)點應該是主要因素，運營商可據(jù)此統(tǒng)計，對主城區(qū)的軟硬件設備做更頻繁的安全檢修。以保障為廣大用戶提供更完善的服務。

6.2 實例二： 各公司投訴量分析

如圖5所示，各公司投訴量統(tǒng)計結果中，時間切片選取粒度“周”，圖表中顯示的是某年第某周的數(shù)據(jù)，及切片還可選擇“月”為粒度。度量值除了投訴量，還增加了計算列：投訴量占比，可醒目的顯示，各片區(qū)公司投訴量的所占比重。圖形還可以選擇疊加柱形、曲線，折線等多種圖形形式來展示。

圖5 各公司投訴量柱形圖數(shù)據(jù)表

因主城區(qū)公司的投訴量明顯高于各片區(qū)公司，故將主城區(qū)展開到下一層（行政區(qū)層）。有圖可得知，主城區(qū)各行政區(qū)中，南岸區(qū)、九龍坡區(qū)和沙坪壩區(qū)的投訴量居高，這3個區(qū)均屬老城區(qū)，所以這3個區(qū)的通信設備可能使用年限較久，應注意安全檢查，設備維修，必要時要更換新設備。

6.3 實例三業(yè)務投訴類型統(tǒng)計分析

如圖6所示，業(yè)務投訴類型統(tǒng)計結果中，時間切片選取粒度“周”，及切片還可選擇“月”為粒度。圖形還可以選擇疊加柱形，曲線，折線等多種圖形形式來展示。不同的業(yè)務類型以不同的色彩標志，各業(yè)務類型還可以往下層鉆取。

圖6 業(yè)務投訴類型統(tǒng)計柱形圖數(shù)據(jù)表

圖6將投訴總量最大的話音基本業(yè)務下鉆到次層，再將次層的網絡覆蓋類型下鉆至第三層。可透徹詳細地看到每個投訴的具體問題是什么。由圖可知，話音基本業(yè)務中的室內覆蓋問題是投訴的主要問題。室內是用戶每天所停留時間最長的場所，所以，此方面的投訴要格外重視。運營商可想辦法把用戶密集的地區(qū)的居民住宅的語音信號覆蓋率進一步加大，來給用戶提供更為優(yōu)質的服務。

7 總結與展望

本文利用某運營商客戶服務中心積累的豐富的客戶投訴信息資源，經過數(shù)據(jù)的ETL預處理到聯(lián)機分析的數(shù)據(jù)倉庫中，并建立CRM投訴分析多維數(shù)據(jù)集，最后對這些數(shù)據(jù)進行多維分析并將結果用工具“極光商智”以圖形、報表的形式進行展現(xiàn)。本文的分析結果，對某運營商客戶服務質量的提升具有一定的指導意義。下一步的工作重點是借助數(shù)據(jù)挖掘技術，利用已經建立好的數(shù)據(jù)倉庫和多維數(shù)據(jù)集，進一步揭示出隱含在投訴數(shù)據(jù)中的規(guī)律和信息，從而為投訴問題的預測分析進行科學導向。

[1]Inmon W H.數(shù)據(jù)倉庫[M].3版.王志海,林友芳 譯.北京:機械工業(yè)出版社,2003.

[2]朱德利.SQL Server 2005 數(shù)據(jù)挖掘與商業(yè)智能完全解決方案[M].北京:電子工業(yè)出版社,2007:189-191.

[3]Brian K, Erik V.SQL Server 2005 Integration Services 專家教程[M].馮飛 譯.北京:清華大學出版社,2008:20-29.

[4]Vassiliadis Panos,Simitsis Alkis,Skiadopoulos Spiros.Conceptual Modeling for ETL Processes[M]. Virginia USA.14-21.

[5]Andreas S. Maniatis,Panos Vassiliadis.Advanced Visualization for OLAP//Proceedings of the 6th ACM International Workshop on Data Warehousing and OLAP. New Orleans: Louisiana, 2003: 9-16.

[6]Melome E,et al.SQL Server 2005 Analysis Services 標準指南[M].武桂香 譯.北京:電子工業(yè)出版社出版社,2008:56-61.

[7]柳進,胡政,唐降龍.OLAP數(shù)據(jù)倉庫在電網調度決策中的研究與應用[J].計算機工程與設計,2005,26(2):296-311.

[8]鐘建強.IP核心網的BGP增量規(guī)劃[J].電子測試,2011(07):54-57.

[9]愈大國.綠色通信網的設計分析[J].電子測試,2010 (12):87-93.