0 前言
伴隨國內電信運營市場的改革、重組和不斷優化，以及計算機及互聯網應用技術的驅動，運營商支撐信息系統的概念在20世紀末被提出并不斷明晰。經過10余年的建設、發展和演變，支撐系統的構成越來越龐大，支撐的流程和功能越來越復雜，支撐系統也已成為企業的管理和運行、業務的運營等方面的重要基礎設施、手段，企業對其的依賴性不言而喻，就如同通信網絡是運營商在電信業務和服務能力方面的基礎設施一樣。支撐系統也是企業核心競爭力的重要因素之一。
運營商支撐系統通常包含了管理支撐系統域（MSS）、業務運營支撐系統域（BSS）、網絡運維支撐系統域（OSS）3個組成部分，各運營商在系統名稱上的叫法不同或界面劃分略有差異。
長期以來，運營商支撐系統的建設管理參照通信網絡工程的模式，而對于支撐系統建設的特殊性未予充分關注或重視，主要原因也包括在運營商的基建中通信網絡建設投資占絕對的主導地位。但是，隨著企業對支撐系統的期望越來越高、依賴性越來越大，加之系統越來越復雜等原因，現行的支撐系統建設管理模式和流程的不適應性的相關矛盾日益凸顯。本文旨在對這一問題進行討論，也是筆者的一些思考，更是希望起到拋磚引玉的作用。
1 支撐系統建設的相關特點
相對通信網絡工程建設而言，支撐系統建設項目有其特殊性，主要表現在以下幾個方面。
a）支撐系統的定制開發特性。通信網絡廣泛互聯的需要決定了其設備組件的標準化和產品化基礎很成熟，通信網絡工程的主要任務是根據運營商自身的網絡規劃和設計（也包括相關企業級標準）選擇合適的產品設備來構建或擴充電信網絡。而支撐系統建設中，基本上不太可能在市場上選到即買即用的產品，而需要進行應用系統的定制開發。事實上，支撐系統建設的使命在于：要通過支撐系統構筑運營商企業內部的管理、運行、運營等方面的邏輯或關系。而不同企業內部的這些邏輯、關系不可能都一樣，因此支撐系統需要進行定制開發。
b）支撐系統的標準化基本限于企業級，且待深化。運營商在支撐系統的標準化方面正做著不懈的努力，企業級的標準體系初步形成，但顯然不盡完善，不盡人意。目前的現狀主要表現為：關注系統應具備的功能，關注并能及時解決系統之間的接口問題（無論付出多大代價），標準的指導性強于約束性（即標準研究制定過程中的對相關方面的指導性更有效），而標準在對系統內部（例如信息模型/數據結構）的約束、模塊化、組件化、系統的可擴展性、可維護性、質量和性能等方面的要求較弱。當然，也還達不到產品級約束的程度。
c）工程建設周期客觀上較長。支撐系統的一個建設項目通常就是一個軟件工程周期，其中需求分析與設計、系統概要設計、詳細設計、軟件編制與調試、驗證與測試等都需要合理的周期，因此較復雜的工程項目基本上不可能在一年內完成真正意義上的竣工驗收。而且，基于現在的資源條件，建設單位很難很好地主導項目周期中的一些重要環節，而更多的自主權掌握在開發廠家方面。
d）由分散、多級到統一規劃設計、集中化管控的趨勢。對于運營商而言，支撐系統的集中化管控應該是一種趨勢，包括規劃、建設乃至運行和維護。這主要是由多方面因素決定的，例如企業跨地域的一體化運營管理方面的要求、支撐系統自身越來越龐大和復雜的互聯關系、應用技術上也基本不存在障礙。集中化管控對于集中管理者在業務和技術方面提出了更高的要求和挑戰。
e）支撐系統建設管控的有效性主要取決于運營商自身的管控能力，這種管控能力包括企業是否有明確并可落地的IT規劃、發展和建設節奏的掌控以及具體建設項目的掌控等。而管控能力的有效性需要由相應的機制和技術資源予以保障。
總之，相對通信網絡工程而言，支撐系統建設項目中對運營商自身的要求更高，提出的挑戰更多。而且，關于支撐系統建設投資的評價也不應簡單地以投入產出為原則，而是取決于運營商自身的總體IT戰略和發展規劃，因為支撐系統建設所追求的目標是支持企業運營和管理上的降本增效、以及運行上的高效，而不是直接形成某種電信業務層面的生產力。
2 支撐系統建設管理模式的基本現狀
目前支撐系統建設項目的管理流程與通信網絡工程基本類似，主要包括三年的建設滾動規劃、年度建設計劃、工程可研、廠家開發、工程設計、實施及調試、工程驗收等。以下僅就幾個方面予以分析。
a）滾動規劃及年度計劃。在IT戰略規劃薄弱或者規劃落地性不強的情況下，滾動規劃和年度項目計劃安排缺乏足夠的輸入和依據，往往基于對現狀改造方面的需求、業務經營發展方面的支撐需求等因素，而在前瞻性、有序發展方面不夠充分。進而導致年度計劃中的安排可能被打亂或做較大調整。
b）具體工程項目的可行性研究。具體項目的可行性研究主要解決工程方案、并回答投資額及工程周期等問題，從而作為決策的參考依據。限于客觀條件（例如可行性研究的費用、報告文本提交周期等），可研工作的視野往往局限于怎么最好地實施好工程，即工程項目本身，同時盡可能細地對工程量（包括對相關聯系統的影響）予以評估。而運營商有時候關注的項目上的必要性、合理性，則應該是在規劃層面或年度計劃安排層面予以解決。這種糾結往往會成為一個死循環。
c）廠家開發。運營商提出的業務支撐需求更多地限于業務規則和業務流程層面，而結合潛在需求、結合系統現狀等的系統需求分析與設計的工作開展得不夠充分，系統開發（包括升級改造）的主動權主要掌握在廠家方面，雖然運營商提出的業務功能需求可能得到很好的滿足。
d）產品測試與驗證。廠家開發的系統產品在被測試時，更多地是在業務功能或功能概念層面、以及系統之間的接口層面，而其他方面往往被忽略，這與運營商支撐系統的標準的現狀也基本一致。由于對系統產品內部（結構設計、模型設計、質量、性能等）掌握不夠，這很可能導致后續系統升級、擴充、或與外部互聯時的改造不易評估，盡管本期完成的系統很好地實現了當前提出的功能要求。
總體上看，在支撐系統的建設和發展過程中，運營商自身的掌控力度還不夠充分。原因主要是運營商與廠家之間在資源和能力上不對等，而顯然雙方在利益上追求最大化方面本身就是一對矛盾。具體地講，運營商缺乏的資源可能包括：企業關于支撐系統的明確發展規劃及持續的調整機制較弱、缺乏系統規劃設計和需求分析設計方面的技術資源、相關的企業級技術標準有待深化（包括相應的機制和資源）等等。
3 支撐系統建設管理流程優化的設想
基于上述的相關分析和思考，對支撐系統建設管理流程的優化提出如圖1所示的設想。
對于支撐系統建設流程優化的設想，主要是強調了現行流程中有些環節的增強或增加，主要包括以下幾個方面。
a）支撐系統規劃設計及持續的優化、深化及調整。系統規劃設計不僅要解決系統的整體架構及系統組成、流程及集成關系等，也要落實系統有序建設發展的策略和節奏，確保可落地、可執行。在此基礎上，結合業務支撐需求、系統現狀等因素，可靠的年度建設項目計劃應該可以很好安排。
b）加強業務支撐需求分析與設計、系統建設需求分析等相關的技術工作。運營商在這方面的工作目前可能比較薄弱，但這是運營商增強對建設項目和系統的掌控力度的基礎，應逐步加強。
c）加強驗證測試工作。這方面包括：對運營商制定的技術標準進行驗證、對廠家開發的系統產品進行測試和驗證等，以逐步確保系統與企業標準的一致性。
上述幾個方面在客觀上都要求運營商要加強自身相應的技術資源隊伍的建設，而不太可能主要依靠廠家來達到目的。運營商應通過建立相應的團隊來形成這些工作的常態機制，從而在實質上逐步加強對系統的掌握和管控。
4 支撐系統建設管理的癥結探尋
支撐系統的建設管理從本質上看也是一種工程管理，可為什么經過這么多年的實踐，從事這項工作的人仍然覺得一言難盡呢？最根本的原因在于三點：一個是系統功能標準化不足，一個是系統間缺乏清晰的界限和穩定的接口標準，另一個是新需求提出缺乏可控的模板。
系統功能標準化不足的具體表現為：系統功能描述停留在籠統的功能說明層面，未對功能實現的具體環境、條件限制和輸出結果進行準確的定義，導致功能開發和最終驗收很大程度上依靠主觀標準來判斷功能實現與否；功能要求中忽略細節，整體看各種功能均已實現，具體使用時細節表現難以讓人滿意。
系統間缺乏清晰的可分割的界限和接口標準表現為：系統間功能替換時理不清兩者間的關系，很多功能實現隱含在代碼中，割接后發現原有功能缺失；系統實現過程中，遷就原有系統的能力或開發廠商，無原則劃定功能的責任系統；接口標準沒有延續性，信息的變動未做到有效的隔離，通過接口傳遞到后續系統時，引發關聯系統的接口變化。
新需求提出缺乏可控模板的表現為：業務部門和技術部門定義需求時，沒有需求量化的標準模板，缺乏需求定義的參考約束，高估軟件實現的靈活性，導致不同時期或不同人員的需求定義結果差別較大，很容易超出應用系統自身架構設計的能力邊界。
系統功能標準化不足和接口標準不穩定的直接后果就是支撐系統工程管理中對功能或性能不佳的模塊難以找到可替換品，已經很完備的功能在后續割接中不能延續，難以打破軟件工程重復造輪子的怪圈。在系統不斷的升級割接過程中，原有功能不斷面臨被重寫的命運，而新寫的模塊通常也很難注意到在原模塊生命周期內不斷夾雜進去的“私貨”。
新需求提出缺乏可控的模板帶來的后果是新需求可能對系統架構造成沖擊，為完成需求必須對現有軟件系統架構進行改造或打補丁，使得健壯的系統架構逐漸處于崩潰的邊緣，工程建設管理陷于“救火隊”的角色。
5 支撐系統建設管理的未來方向展望
從長遠的角度來看，未來的支撐系統也需要向工業化革命的方向去發展，走向標準化的道路。運營商應該能夠選擇適合自己的模塊產品，進行有效的組裝，把支撐系統建設的精力集中在業務流程重組和配置優化上，而不是集中在功能實現和改進上。
我們可以看一個城市的發展，雖然一些新的高樓在不斷建設，但是一些幾十年的住宅也仍在發揮作用。對支撐系統而言也是一樣的，只有形成軟件功能模塊的良好進化機制，才能真正降低支撐系統建設的無序和復雜性，走上一個良性的發展道路。