掌上綜合運(yùn)維的支撐研究

■

在移動(dòng)互聯(lián)網(wǎng)的大潮中，電信運(yùn)營商的OSS支撐體系中的各類業(yè)務(wù)系統(tǒng)紛紛推出了適用于智能手機(jī)的客戶端，廣泛運(yùn)用在一線運(yùn)維人員的智能手機(jī)中。但正是由于OSS支撐系統(tǒng)眾多，而各個(gè)業(yè)務(wù)系統(tǒng)的App沒有統(tǒng)一的標(biāo)準(zhǔn)，用戶不得不安裝大量的移動(dòng)應(yīng)用程序，而各個(gè)應(yīng)用之間沒有任何關(guān)系，這樣既增加了智能終端的硬件負(fù)擔(dān)，也不利于一線運(yùn)維人員開展工作，從而給系統(tǒng)建設(shè)和推廣使用都帶來了一定的困難。

一、需求與技術(shù)分析

我們分別從移動(dòng)應(yīng)用的系統(tǒng)和移動(dòng)應(yīng)用的形態(tài)演進(jìn)兩個(gè)角度來看看企業(yè)移動(dòng)信息化的發(fā)展趨勢。

對于制造業(yè)而言，其核心的系統(tǒng)主要為“進(jìn)銷存+研發(fā)管理”等系統(tǒng)，其移動(dòng)化的路線圖為銷→存→進(jìn)，此外針對高層用戶的決策類信息也會(huì)逐步移動(dòng)化；對于服務(wù)業(yè)而言，在線服務(wù)訂購類和在線客服類系統(tǒng)（即所謂的O2O應(yīng)用）應(yīng)用大量出現(xiàn)，如各類酒店預(yù)訂、打車App、團(tuán)購應(yīng)用等；對于電信運(yùn)營商而言，CRM中的營銷和客服類模塊目前已經(jīng)在逐步移動(dòng)化。除了上述的各類業(yè)務(wù)系統(tǒng)，在各類企業(yè)應(yīng)用中被大量使用的辦公類系統(tǒng)（OA和郵件等）和協(xié)作類系統(tǒng)（即時(shí)通信等）對移動(dòng)信息化的需求也是最迫切的。此外，我們也注意到，目前企業(yè)移動(dòng)信息化還處于比較初級的階段，大部分企業(yè)的移動(dòng)應(yīng)用都是各自獨(dú)立，很少有從整體上統(tǒng)一考慮的。

從企業(yè)移動(dòng)應(yīng)用的形態(tài)上看，基于平臺(tái)原生語言的App應(yīng)用大行其道，在iOS平臺(tái)上這類應(yīng)用主要基于蘋果的AppStore進(jìn)行分發(fā)，在Android平臺(tái)上大量應(yīng)用如雨后春筍般出現(xiàn)也催生了很多類AppStore的應(yīng)用分發(fā)類工具，如91助手、豌豆莢等。微信及其第三方公共平臺(tái)的出現(xiàn)使O2O類應(yīng)用和企業(yè)營銷類應(yīng)用的形態(tài)發(fā)生了巨大變化，人們忽然發(fā)現(xiàn)，千姿百態(tài)需要不斷學(xué)習(xí)的各類原生APP其實(shí)還是敵不過最自然的人與人的溝通以及隱藏在這種溝通形態(tài)之后不斷強(qiáng)大的人工智能。與此同時(shí)，越來越多的互聯(lián)網(wǎng)公司開始采用WebApp技術(shù)，原因是伴隨著智能終端處理能力的增強(qiáng)，基于Html5的WebApp技術(shù)將會(huì)占據(jù)主流。融合通信和WebApp的技術(shù)發(fā)展，讓我們看到傳統(tǒng)的AppStore雖然還占有一定的市場，但會(huì)逐步衰落，而基于融合通訊（電話、即時(shí)消息）技術(shù)和WebApp技術(shù)的企業(yè)應(yīng)用的結(jié)合將成為企業(yè)移動(dòng)信息化的主流。

圖1 綜合掌上運(yùn)維整體的業(yè)務(wù)架構(gòu)

從另一方面，維護(hù)人員跨組織、部門，相互交流、溝通較少，容易形成業(yè)務(wù)壁壘，造成知識(shí)共享不夠，維護(hù)人員業(yè)務(wù)水平成長緩慢。為此，維護(hù)人員有強(qiáng)烈的意愿打破溝通壁壘，形成扁平化的交流、溝通業(yè)務(wù)線條，便于彼此共享專業(yè)知識(shí)。在互聯(lián)網(wǎng)浪潮中，融合通信越來越多的承擔(dān)起人與人遠(yuǎn)程溝通、分享的責(zé)任，而企業(yè)應(yīng)用很少顧及融合通信的需求，往往依賴于外部媒體通信工具，這些通信軟件在企業(yè)應(yīng)用方面支撐甚少，不支持企業(yè)內(nèi)部的業(yè)務(wù)系統(tǒng)接入、不支持話費(fèi)落地、不支持企業(yè)加密的消息傳輸沒有安全性可言等等，因此，構(gòu)建融合通訊的掌上運(yùn)維系統(tǒng)，實(shí)現(xiàn)維護(hù)人員的扁平化溝通迫在眉睫。

二、技術(shù)方案

該方案的主要目標(biāo)是建設(shè)綜合化的掌上運(yùn)維系統(tǒng)，其中包括四大網(wǎng)絡(luò)運(yùn)維維度：掌上數(shù)據(jù)中心、掌上維護(hù)中心、掌上知識(shí)中心和掌上協(xié)作中心。

這四大應(yīng)用中心依托于統(tǒng)一的消息推送和應(yīng)用倉庫的集成，統(tǒng)一消息接入所有外部應(yīng)用系統(tǒng)向用戶推送的各種消息，并推送到客戶端，由客戶端進(jìn)行匯總后統(tǒng)一呈現(xiàn)；應(yīng)用倉庫負(fù)責(zé)接入所有WebApp和Native原生應(yīng)用，包括數(shù)據(jù)中心所需的業(yè)務(wù)數(shù)據(jù)存儲(chǔ)，均在該模塊中實(shí)現(xiàn)。

通過上述的需求與技術(shù)分析，綜合掌上運(yùn)維整體的業(yè)務(wù)架構(gòu)如圖1所示。

統(tǒng)一消息推送主要解決人機(jī)交互、人人交互的消息整合過程，由消息接入對消息源進(jìn)行消息整合、清洗與標(biāo)準(zhǔn)化，并通過消息引擎路由給相應(yīng)的用戶。

四個(gè)中心特點(diǎn)

根據(jù)需求的分析，四個(gè)中心各有特點(diǎn)。首先，協(xié)作中心是人人、人機(jī)溝通的核心模塊，可以瀏覽查詢企業(yè)通訊錄，發(fā)起對話、建立群組、組織會(huì)議等。因此我們?nèi)诤狭讼⒔缑?，使之可以將?人消息、人-機(jī)消息有效地結(jié)合在一起，提供更加直觀的操作界面。

其次，維護(hù)中心主要面向人-機(jī)遠(yuǎn)程操作，這里會(huì)根據(jù)業(yè)務(wù)能力集成各類面向網(wǎng)絡(luò)操作類的應(yīng)用工具，因此，該中心以集成各類手機(jī)應(yīng)用為主，實(shí)現(xiàn)應(yīng)用倉庫功能。

再其次，數(shù)據(jù)中心提供用來支撐各類用戶工作的關(guān)鍵數(shù)據(jù)，這些數(shù)據(jù)通過其他業(yè)務(wù)生產(chǎn)系統(tǒng)生產(chǎn)，綜合掌上運(yùn)維系統(tǒng)通過采集獲得。采集后的數(shù)據(jù)經(jīng)過建立關(guān)聯(lián)關(guān)系、清洗、標(biāo)準(zhǔn)化后進(jìn)入數(shù)據(jù)中心的存儲(chǔ)層，并由本系統(tǒng)向訂閱這些數(shù)據(jù)的用戶進(jìn)行分發(fā)。

最后，知識(shí)中心在處理故障、網(wǎng)絡(luò)調(diào)優(yōu)時(shí)提供關(guān)聯(lián)案例進(jìn)行推送，并提供知識(shí)分享、下載、閱覽的操作，幫助維護(hù)人員提升工作能力。

這四個(gè)中心以協(xié)作為核心，通過實(shí)際業(yè)務(wù)場景串接起每個(gè)中心的功能，系統(tǒng)手機(jī)客戶端的界面如圖2所示。

圖2 手機(jī)客戶端的界面

數(shù)據(jù)建模方案

掌上運(yùn)維的數(shù)據(jù)中心的特點(diǎn)是推送、呈現(xiàn)和查詢業(yè)務(wù)數(shù)據(jù)，那么就需要在系統(tǒng)中接入大量的網(wǎng)絡(luò)數(shù)據(jù)報(bào)表，這些報(bào)表中的數(shù)據(jù)是數(shù)據(jù)來源系統(tǒng)負(fù)責(zé)提供的，由于數(shù)據(jù)來源系統(tǒng)的界面樣式的不確定性和操作模式的多樣性，為保證用戶的使用體驗(yàn)，我們必須對數(shù)據(jù)來源系統(tǒng)提供的數(shù)據(jù)進(jìn)行存儲(chǔ)，并提供統(tǒng)一的數(shù)據(jù)消費(fèi)體驗(yàn)。

在本案中，我們重點(diǎn)分析30多種來源于不同業(yè)務(wù)系統(tǒng)的數(shù)據(jù)格式，并整理出業(yè)務(wù)場景對數(shù)據(jù)維度的要求，這些統(tǒng)計(jì)維度主要包括部門、用戶、區(qū)域、時(shí)間、設(shè)備、網(wǎng)絡(luò)等。按這些數(shù)據(jù)維度進(jìn)行數(shù)據(jù)模型的抽象，建立邏輯模型和物理模型。這些模型用來存儲(chǔ)最終呈現(xiàn)的數(shù)據(jù)樣式，本案系統(tǒng)并不承擔(dān)數(shù)據(jù)的加工、清洗和匯總的數(shù)據(jù)處理過程，該過程由數(shù)據(jù)來源系統(tǒng)承擔(dān)。圖3是數(shù)據(jù)模型構(gòu)建時(shí)逐級匯總的過程。

通過上述模型的梳理和建設(shè)，對接采集業(yè)務(wù)系統(tǒng)的生產(chǎn)數(shù)據(jù)，這樣就在本系統(tǒng)內(nèi)實(shí)現(xiàn)了綜合掌上運(yùn)維所需的業(yè)務(wù)數(shù)據(jù)存儲(chǔ)平臺(tái)，能夠?qū)ι蠈拥臉I(yè)務(wù)應(yīng)用提供數(shù)據(jù)支撐了。

三、知識(shí)管理運(yùn)營方案

圖3數(shù)據(jù)模型構(gòu)建時(shí)逐級匯總過程

圖4運(yùn)營管理方法

在本案中，涉及到網(wǎng)絡(luò)維護(hù)知識(shí)管理，知識(shí)的收集與分發(fā)工作不只是行政命令或完全基于個(gè)人意愿的簡單分享，需要更多的思考用戶行為，并不斷運(yùn)營知識(shí)，才可以使用戶對知識(shí)的發(fā)布、分享、使用變得更有效率。在知識(shí)運(yùn)營管理中，運(yùn)用的運(yùn)營管理方法如圖4所示。

首先從產(chǎn)品設(shè)計(jì)上滿足知識(shí)管理體現(xiàn)要求的支撐平臺(tái)，將內(nèi)容建設(shè)作為運(yùn)營管理的基礎(chǔ)工作。本案中，根據(jù)用戶主體工作需要，主要面向故障處理、設(shè)備維護(hù)操作、日常維護(hù)等幾個(gè)方面進(jìn)行建設(shè)，引導(dǎo)用戶主動(dòng)分享故障處理過程、設(shè)備維護(hù)經(jīng)驗(yàn)等。

其次，通過內(nèi)容編輯審核、話題挖掘、內(nèi)容推送保證知識(shí)質(zhì)量，吸引用戶興趣，并為用戶實(shí)際工作提供幫助。該部分內(nèi)容涉及到管理崗位、職責(zé)的定義，需要在開展實(shí)際項(xiàng)目前落實(shí)管理職責(zé)。同時(shí)，保證知識(shí)的質(zhì)量需要大量的工作量，為了避免簡單粗暴的考核式管理，我們對知識(shí)的質(zhì)量設(shè)置閾值，讓每個(gè)用戶既是參與者也是評分者。那么，這些就需要系統(tǒng)能夠提供對知識(shí)的評分，并能夠讓真正幫助維護(hù)人員解決實(shí)際問題的知識(shí)獲得更高認(rèn)同度。

最后，持續(xù)的分析用戶訪問情況、功能使用情況等數(shù)據(jù)，優(yōu)化系統(tǒng)功能，并策劃專題活動(dòng)，保持內(nèi)容和產(chǎn)品功能的充分結(jié)合。因此，在知識(shí)管理運(yùn)營的過程，我們需要對知識(shí)的貢獻(xiàn)者提供一些獎(jiǎng)勵(lì)，在該功能模塊中，我們提供貢獻(xiàn)度排名、專家知識(shí)排名、知識(shí)評分排名等，對于位于排名前列的部門、專家、維護(hù)人員，給予精神和物質(zhì)上的獎(jiǎng)勵(lì)，使員工在貢獻(xiàn)知識(shí)的時(shí)候可以獲得極強(qiáng)的滿足感，推動(dòng)知識(shí)的積累和完善。

四、總結(jié)

本方案充分考慮到移動(dòng)化辦公對電信運(yùn)營商企業(yè)內(nèi)部的變革，提出了全新的綜合化移動(dòng)辦公方案，并結(jié)合代維知識(shí)的運(yùn)營，推動(dòng)代維組織的技術(shù)發(fā)展。電信運(yùn)營商可以根據(jù)自身特點(diǎn)及管理辦法，利用本案的技術(shù)架構(gòu)來實(shí)現(xiàn)符合自身運(yùn)維能力的綜合化移動(dòng)運(yùn)維平臺(tái)。