為什么要建設綜合資源管理系統
為什么要建設綜合資源管理系統，這看似一個不用回答的問題。然而，也存在以下這樣一些疑問。
●資源管理系統是必要的嗎？網管系統是否也能解決我發現的問題？
●為什么要建設跨專業的綜合資源管理系統？我們的管理架構是分專業管理的，分專業的網管系統或者資源管理系統建設更能符合各個專業的需求。
●資源管理系統到底能給我們帶來多大的益處？從投入產出比來看是值得的嗎？
因此，對于綜合資源管理系統建設必要性的分析還是需要的。
首先，綜合資源管理系統建設不是IT系統架構的需要，而是網絡和業務發展的必然。隨著電信網絡規模日益擴大、層次日益復雜，網絡或專業之間關聯和整合的需求逐漸增多。在下一代運營環境中，這種趨勢更為明顯，多樣化的接入層承載在融合的IP承載層上，業務的融合使得專業之間的界限日益模糊。從網管角度來看，專業網管往往是面向某專業網絡的，只能反映網絡的局部或者單個層次，無法形成跨專業的全局視圖。這就對跨網絡、跨業務的橫向一體化的資源管理系統提出了需求。
其次，資源管理系統是運營支撐系統的應用基礎。資源管理系統通過對網絡實體的全程全網和全生命周期管理，可以支持服務開通、服務保障（故障處理、綜合告警）、運行維護（網優、備品備件）、網絡規劃和資產管理。
再次，資源管理系統是企業精細化管理的必然要求。準確、動態的資源管理，可以對服務開通和服務保障提供有效支持，從而提高客戶服務質量，降低運營成本（Opex）。同時，通過對于網絡規劃和資產管理的支持，可以降低企業的資本性支出（Capex）。
資源的定義
什么是資源的內涵？雖然經過了多年的資源管理系統建設，我們仍然有必要對資源的內涵給出一個明確的定義。這對如何控制資源管理系統的業務需求以及如何驅動資源生命周期變化都有重要意義。
資源是可以提供業務能力的、可調度的電信網絡基礎設施單元及其組合。
首先，資源一定要是能夠提供業務能力的。僅僅工程建設完成的網絡實體，只是所謂“轉固”，成為了固定資產。而資源必須是可以提供業務能力的，是面向業務的。它一般不需要包括現網中的所有設備信息，而是以可以提供業務能力的可調度的信息為主，包括物理資源、邏輯資源以及資源之間的關聯關系。
其次，資源還必須是“可以調度的”。這是因為資源與網管信息的最重要的區別是，資源是“通過流程來驅動其生命周期的變化”，這里的流程包括資源進入（工程）、運維（開通、保障）、退出等，而網管是通過網絡協議主動、實時獲取的網絡信息，通過協議實時配置設備，網管是資源配置后的主要執行者之一。
最后，資源是電信網絡基礎設施單元及其組合，這種定義使得資源不僅包括網絡物理與邏輯資源，還包括空間資源如機房、機位、號碼資源等。
應用不足與應用過度
到底是先數據還是先應用，其實這是一個“先有雞還是先有蛋”的問題。數據是應用的基礎，而應用是數據得以歷久彌新的保證。在資源管理系統建設中，對應用的把握至關重要。資源系統建設必須關注應用不足和應用過度的問題。
所謂應用不足，是指資源系統缺乏應用，導致資源本身不能形成動態的數據，而逐步變成一堆死數據。應用不足而導致資源系統建設的失敗，這是有實際的經驗教訓的。因此，資源管理一定要明確核心應用。
所謂應用過度，是指對資源管理的應用范圍和方式沒有控制，任意將本不屬于資源管理范疇的應用納入系統建設范圍。例如，資源管理對于某應用的支持可以是數據提供的支持，不等同于該應用必須在資源系統中實現。例如，無線覆蓋的設計、管道桿路的設計、根告警分析等。
固網與移動網絡資源管理的異同
固網和移動網絡資源管理的異同分析有相當的現實意義。一方面，正在逐步展開的移動資源管理建設需要借鑒固網資源管理的經驗教訓，另一方面，運營商的重組使得幾大運營商都逐步成為全業務運營商。固網和移動網絡資源管理應用的異同本質上源自于網絡與業務本身的異同。
●固網有大量的外線資源，PSTN與寬帶業務是重點。
●除企業用戶接入的部分傳輸/光纖資源外，移動網基本無外線資源。移動話音及及其增值業務是其重點業務，企業數據業務（如GPRS）和企業短信業務量根據地域不同差別較大。
從網絡與業務的異同可以進一步分析資源管理應用的異同。
●相同點：都需要實現多技術多業務的管理，從而實現跨網絡、跨業務的關聯；都需要對開通、報障、規劃、資產等幾大應用的支持。
●固網與移動資源管理的區別主要在于應用的重點不同：資源管理范圍不同，除核心傳輸/光纜網和IP承載網以外，固網資源管理重點管理的資源范圍包括外線資源、號碼資源、交換/寬帶/傳輸/光纖網的接入側資源；移動資源管理的重點在于GSM網核心和無線側資源及其對應的傳輸網資源，以及企業業務接入對應的IP和傳輸接入側資源。
應用重點也不同，對固網來說，服務開通支持是資源管理的最重要應用，是資源數據生命周期變化的主要驅動力；對移動網絡，資源管理的服務開通支持主要只面向企業業務，業務量不足以驅動整個資源數據的生命周期變化。而運維支持（如網絡設計/割接/內部資源調度）和保障支持（綜合告警及故障處理支持）是移動資源管理的重點應用。
服務層封裝不僅僅是概念
從TMF的ServiceModelFramework到國際幾大資源管理產品不約而同地推出服務層模型及應用，服務層管理正逐步成為資源管理的重要內容。不僅如此，如果仔細研究運營支撐域的其他產品，如服務激活、SDP等，其本質也都是一種網絡能力或者智能業務使能部件能力的服務封裝。
服務層封裝絕不僅僅是概念炒作，服務封裝關注的是資源的使用，它的出現最本質原因是資源管理的重點從“理清家底”向“有效使用”的轉變。在下一代運營環境中，隨著接入層的多樣化和產品推出速度的加快，這一趨勢更為明顯。
對服務封裝的理解往往存在誤區，它往往會被與業務層資源相混淆。實際上，服務不是資源，它反映的是網絡（資源）提供的能力，也有人稱之為后端產品；服務配置（模板）也不是資源，而是怎樣用資源，它定義的是需要哪些資源支持這個服務，怎么支持（派配）。一種服務可以有多種服務配置；服務實例也不是資源，它實際上是表示“這些資源為這個用戶提供的這個服務”，通過它可以不僅可以將資源與用戶關聯起來，還可以管理資源從投用到退服的生命周期。
商用軟件如何解決定制業務邏輯問題
商用軟件具有成熟、擴展性好的數據模型和技術架構，但是，如何解決定制業務邏輯是一個難點。例如，任意選取中國電信固話業務里面的兩個業務邏輯：“公務電話不能開通17909”，“直線電話不能選擇Centrex業務”。這些業務邏輯與運營商的網絡、業務環境甚至管理結構密切相關，商用產品中不可能窮舉。而且，在下一代運營環境中，核心層的融合和智能化使得資源管理更關注接入層乃至終端層。這一層次廠商和設備種類更多，對應的資源派配業務邏輯更為復雜。
因此，商用軟件必須解決定制業務邏輯如何無縫嵌入平臺核心業務邏輯的問題。而這一點通過傳統的面向對象的軟件架構很難實現，這就需要從軟件架構層面進入新的模式。
資源配置流程該放在哪里
實際上，“資源配置流程該放在哪里”的問題一直存在爭論。在中國電信的資源管理系統建設早期，資源配置流程放在資源管理系統中。隨著服務開通系統建設，資源配置流程逐步剝離到開通流程。然而，目前也出現一些反對的聲音，因為資源配置流程涉及到的后端網絡相對比較復雜，開通流程的設計人員很難懂得資源配置。
要回答這個問題，首先要搞清楚流程是什么？實際上，流程是人或者部門之間分工協作共同完成一個事務處理過程。因此，如果資源配置涉及多個部門或者系統之間的協作，則應放在整個開通流程中，以便于流程整體控制、異常處理和回滾。目前大多數業務對應的資源配置都屬于這種情況。
然而，資源配置流程的設計確實是比較專業和復雜。這就要求在系統建設規劃和實施層面進行有效的控制。服務開通流程平臺最好能與資源管理系統并行建設。然而，針對具體情況可以有以下對策。
●對于服務開通系統已建而資源管理系統新建的情況,如果原服務開通流程系統可以支持復雜的資源配置流程，則可以采用對該平臺進行同步改造的方式，將資源配置流程納入整體流程。
●如果原服務開通流程系統不足以支持復雜的資源配置流程，則應選擇新建流程平臺，初期僅僅在其上新建資源配置流程，后期逐步納入原開通流程系統的整體流程。
●對于新建資源管理系統而服務開通系統未建的情況，則最好同步選型服務開通流程平臺，并將資源配置流程在該平臺上實現，以利于今后服務開通流程系統的整體建設。
●如果不能做到以上的并行建設方式，則只能將資源配置流程部分納入資源管理系統建設范疇，并與服務開通大流程采用單據交互的方式，但這種模式將不利于流程整體控制、異常處理和回滾。
資源數據準確性問題
數據是應用的基礎，如何保持資源數據的持久彌新，是關系到系統建設最終成敗的重要問題。要最終解決資源數據準確性問題，應堅持流程驅動為資源管理系統數據生命周期變化的主要驅動力，這里的流程包括服務開通流程、工程建設流程、維護流程等。
現網到資源系統數據的網絡發現與同步是有效的補充，特別是在資源系統建設的初期以及流程不閉環的情況下（如圖2所示）。
另外，TMFMTOSI規范的發展與應用值得關注。MTOSI致力于解決網絡層與OSS層的接口問題，使不同的設備廠商，不同的應用之間有一個互操作的統一標準。
資源管理系統該如何實施
資源管理系統的實施是一個系統工程，需要從規劃、技術和管理多個層面進行綜合考慮。
首先，應該有一個統一的規劃，包括業務和IT建設規劃。業務需求是根本，定義好業務應用的目標、內容和邊界，是資源管理建設的首要任務。IT建設規劃包括新老系統的銜接、與其他系統的集成關系、方法以及系統演進路線等。
其次，應該建立統一的實施和管理部門。資源管理系統建設應納入企業IT建設的高度加以重視。從以往的經驗來看，只有管理、實施和應用部門緊密合作，資源管理系統建設才有可能成功。
再次，應該有一個長期的合作伙伴。資源管理系統建設是復雜而艱巨的，需要軟件供應商、系統集成商等的良好支持。
最后，應該有一個好的軟件平臺。軟件平臺的選擇應慎重，需要從建模能力、集成能力、可擴展性、售后支持等多方面綜合考慮。
