現狀
采用數據中心數據集中處理之后,運營商基本實現了采集、計費、賬務處理、銷賬、欠費管理的全程數據自動交換;在賬務處理、銷賬、欠費環(huán)節(jié)實現了數據共享;消除了通過手工進行HLR操作的現象;大大提高了數據處理的準確度和時效性;在結算和對外服務渠道上提供了統一的外部接口;核心系統采用了封閉的內部網絡和比較穩(wěn)健的系統架構。
結合當時市場的發(fā)育程度和同業(yè)競爭形勢來看,整個運營系統在功能、性能和安全性方面有較好的表現,基本滿足了市場需求和業(yè)務需求,在一定程度上滿足了運營管理需求,并與通信網技術達到了較好的契合度。
下面以遼寧聯通省公司數據中心為例對計費系統現狀進行剖析。
其計費系統架構如圖一所示:
通過對以上特點的分析可以看出,該套運營系統的設計把滿足公司基本的業(yè)務需求作為基點;在實現信息系統自動處理、消除人工干預的基礎上,去提高數據處理的準確性。
存在的問題
任何技術都是一柄“雙刃劍”。隨著信息技術的飛速發(fā)展、市場發(fā)育的日益完善和同業(yè)競爭的日趨激烈,計費系統在功能、性能、成本及風險控制、更多的信息、改進的服務等方面有了更高的標準和要求。
除了因為業(yè)務量的增加,在對海量數據的存儲和處理時導致的硬件資源的緊張之外,在系統架構設計、關鍵技術使用、風險防范、經營決策和客戶服務等方面還存在以下缺欠:
系統架構設計方面的缺欠
1.由于計費子系統和營業(yè)子系統、賬務子系統主機物理分離,兩臺主機數據庫之間需頻繁的數據交換,隨著數據量的增大,對主機性能的影響日益明顯;
2.由于營業(yè)子系統和賬務子系統的應用(AP)和數據庫(DB)集中于一臺主機,導致賬務子系統在執(zhí)行批處理作業(yè)時影響營業(yè)子系統的性能;
3.系統的應用和數據庫未進行整體的規(guī)劃、分層,阻礙了系統擴展能力的提高。
關鍵技術使用方面的缺欠
1.在采集機和計費主機之間的文件傳輸采用ftp實現,由于ftp僅僅實現了文件傳輸的基本功能,對傳輸的完整性和時效性不具備保證機制;
2.在計費主機、HLR前置機和交換機之間使用網絡編程的方式完成三方之間的交易,無法實現交易的一致性。
在風險防范方面的缺欠
為了增強企業(yè)核心競爭力,應有效防范來自公司內、外部的風險。風險主要體現在業(yè)務人員操作風險、客戶信用風險和經營過程缺乏可控性的風險。計費系統能夠很好地支持事后監(jiān)督功能,但還無法實現事前預測和事中控制機制。
在經營決策方面的缺欠
該計費系統對經營決策的支持是一個空白。由于數據庫的分散,致使在數據庫中無法直接提取出客戶或賬戶信息的一個完整單元,因此,在該計費系統中,目前只能通過手工方式將數據導出,通過二次加工進行數據過濾和抽取工作,這種處理方式的缺點是顯而易見的:效率低下、準確性缺乏認證、耗費較多的人力成本。
在客戶服務方面的缺欠
在此計費系統中,為客戶提供服務的手段、方式和方法比較單一,對客戶的服務只體現在對現有信息的直接提取和對客戶的維系服務層面,還不能直接通過計費系統本身對數據的加工生成對開發(fā)客戶有所幫助的信息,只能依靠手工的方式處理。
優(yōu)化策略
采用三層C/S架構,將應用功能分成表示層、功能層和數據層三部分,對這三層進行明確劃分,并在邏輯上使其獨立,從而使系統具有硬件系統的擴展性較好、軟件的功能界定清晰、程序的可維護性較強、安全控制嚴謹、系統管理簡單、可支持分布式數據庫等特點。
采集機和HLR前置機分別在省中心設置一臺主機,采取數據集中處理模式。
優(yōu)化后的系統架構如圖二所示。
計費系統的業(yè)務流程集中體現為賬單流、定單流、服務保障流和決策流。
在賬單流的設計中,引入為賬戶建賬本的概念,使計費系統具備了初步的財務功能,即賬戶有總賬-分類賬-明細賬的模式,提高賬務的明晰性和準確性;注意系統設計的開放性,以適應各類客戶群體對層出不窮的新業(yè)務的要求、適應復雜的運營環(huán)境;注意系統設計的先進性和前瞻性,保證對特色業(yè)務計費方式的支持。
在定單流的設計中,重點是業(yè)務系統對網元設備進行操作的方式、方法和途徑。
在服務保障流的設計中,重點是針對CRM系統的建設,緊緊圍繞客戶的滿意度指標,去細分市場,發(fā)掘客戶。
決策流著重對于經營決策系統進行描述,體現在決策支持系統(DSS)和商業(yè)智能(BI)等領域,核心數據庫是其數據源,通過構建數據倉庫形成其數據平臺。
與此同時,通過對業(yè)務量的合理估測,選用高性能的主機、通訊和存儲設備,通過群集技術,為應用系統的高可用性提供穩(wěn)健的硬件平臺,并用交易中間件實現交易的一致性和原則性,用消息中間件實現采集數據的可靠傳輸。
通訊產業(yè)報