相愛相殺：移動聯通IT支撐回憶錄（十四）

文 | 甯宇

我寫的不是小說，而是我的印象和記憶中，移動與聯通有關IT支撐的曆史往事。

在十數年間，雙方相互學習、相互借鑒，同時又相互競争、相互敵視，在不同的階段交替領跑。

在這些現象背後有什麼深層次的原因，又是哪些偶然的因素，造就兩家運營商前台營銷競争激烈，後台支撐相愛相殺？

容我慢慢講這段IT往事。

聯通升級集中化

移動打造第三代

時光飛逝，轉眼到了4G時代，聯通和移動在這兩年都各自完成了自己的新規劃，2015年開始，IT支撐系統走上了新的征程。

聯通的規劃主要是完成對cBSS系統的升級。

cBSS是目前電信運營商IT支撐集中化的極緻。它以4G為契機，完成了CRM和計費等核心系統全國大集中，同時和總部級幾十套生産系統、省級數百套本地生産系統進行交互與聯動。

相比3G時代ESS等集中化系統，cBSS的集中度更高。ESS是通過掌控資源，做到了集中受理，而計費環節以及CRM的絕大部分能力還是在省級系統完成的。換句話說，3G時代聯通的系統集中實現了一定程度的管控，但是具體的運營支撐工作還是在省級完成的。因此在實際運營過程中，也存在某些場景下，省公司繞過總部的管控，達成自己的目的。而cBSS的建設，又在集中化方面前進了一步。

對于運營商來說，傳統的屬地化運營，各地的業務差異，都使全網策略的落地執行有周期長、見效慢的弊端。核心能力的收斂，讓企業的執行力進一步上升。系統集中化後，一點部署上線，全網統一執行，極大提升了"下行"效率。不少人士認為，唯有如此，運營商才能實現互聯網化，與互聯網企業一争高下。

但是事物都是兩方面的：在"下行"提速的同時，"上行"又成了問題。正常情況下，如果需要集中化的能力做調整，需要将地方提出的需求進行收斂、審核，尤其要考慮其他地區是否有類似的想法，需求能否歸并整合，最終形成共性需求來驅動開發。而對基層一線來說，他們關心的是系統集中之後，IT支撐對需求的響應速度，以及對屬地化創新的支持力度。

這些問題的解決，取決于集中化系統與本地系統的分工與協同。雖然cBSS實現了集中化的支撐能力，但也并非所有的業務、功能、運營流程，全部在總部系統完成，本地系統仍是IT支撐體系的重要組成部分。随着标準化程度的深入，技術的革新，以及業務的延展，能标準化的規範化，能集中支撐的收上來，這是技術和業務發展的趨勢。而聯通是勇于吃螃蟹，在痛與快樂中，cBSS2.0向我們走來。

移動雖然在集中化方面做了嘗試，但巨大的存量市場以及兩級法人體系，導緻其在IT支撐集中問題上非常謹慎，第三代業務支撐系統規劃的整體框架，仍維持兩級系統的格局。

支撐系統規劃一般有來自于兩方面的動力：一個是業務驅動，一個是技術驅動。移動的第一代業務支撐系統是省級集中化為主的業務驅動，結合三層架構三戶模型的技術革新。第二代NGBOSS是要完成兩級體系的構建，新的業務模型是客戶運營與産品運營分離，之後又完成了CRM和BOSS的分拆解耦。

第三代業務支撐系統有别于NGBOSS，主要是從技術方面考慮的。一方面為解決IT系統雲化的問題，形成了CRM和BOSS系統實施雲化改造，以适應未來硬件基礎設施的雲化；另一方面為提升與互聯網企業的對接能力，構建兩級能力開放平台，将支撐系統的服務能力進行封裝，提升連接效率和開放程度。

與此同時，移動還在構建全國集中的大數據平台。

十年前建設一級經營分析系統時，由于當時的技術條件限制，還無法将所有數據集中，因此除了全量統計信息之外，系統裡隻能以抽樣方式，存儲部分詳單信息。而今，技術的發展不僅可以使系統集中存儲海量數據，而且用戶的上網信息、網頁爬蟲的結果，這些信息的獲取、清洗、轉換工作，沒有必要每個地方自己搞一套，經營分析系統搞集中化，技術方面不僅是可行的，也是必要的。

雖然數據是集中采集、集中存儲、集中管理的，但對數據的使用和分析行為仍然可以分散進行。以前的數據集市，後來演化成為數據沙盒，都是可以根據需要形成一個小的數據集，提供給各級單位的分析人員，由其對數據集合裡面的信息進行分析。也可以将數據集裡面的分析結果和生産系統形成互動，實現智能化營銷和服務。

建設集中化的大數據平台，不僅可以給"相關部門"提供數據服務和分析支撐，同時還可以考慮承接大數據變現的任務，這将是IT專業化之後一個重要的發展路徑。

我用十幾篇連載的方式，講述完了移動和聯通在IT支撐方面十多年的發展和演進路徑。這些年，雙方交替領先，相互學習借鑒，客觀上也推動了行業的整體發展和技術演進。那麼在技術背後，又反映出兩家的哪些特點，而這些特征又和企業的戰略、基因、業務、管理等方面是什麼關聯關系？請看下期：《相愛相殺·總結篇》。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!