典型运营支撑系统的实现和应用

    在商业支持系统和运营支撑系统(BSS&OSS)领域，存在很多变化的因素，如技术不断发展、服务不断创新、产品不同组合、客户需求的差异性、运营商具体流程的差异性、运营商组织结构的不同、软件实现技术的变化等，这些变化因素都为形成稳定的运营支撑系统带来了很大困难。对于构建BSS&OSS来说，寻找相对稳定的因素是非常重要的。运营支撑系统(OSS)价值链上的运营商、集成商、软件厂商一直也在寻找这些稳定的因素。电信管理论坛(TMF)的新一代运营系统和软件(NGOSS)对一些规律性的因素进行了比较深入的研究，在TMF NGOSS的核心理念、方法论、知识库中得到了体现。如何深入理解TMF NGOSS的核心理念、工具并在实际的OSS系统规划、软件设计、系统集成中遵循，同时适应外界变化的因素是中国运营商和相关厂商需要研究和解决的问题。

1 运营支撑系统的理念和方法论
    NGOSS虽然是由TMF来倡导和推动，但NGOSS的思想却来源于电信管理网、企业管理、业务过程管理、商业套装软件(COTS)，是这4个方面有机的结合和提升(如图1所示)。提炼了3个稳定的因素：业务过程框架(BPM)-增强的电信运营图(eTOM)、共享信息模型(SID)、系统架构。

    在扩展的电信运营图中有机地结合了电信管理网(TMN)的分层的构想和业务过程管理的思想，站在企业管理的高度提出了面向客户的端到端的、完整的过程框架，同时将企业内部的管理过程也纳入到整个过程框架图中。在共享信息数据模型(SID)中，提出了完整的电信运营信息模型的框架，强调信息共享要从全局、整体上考虑，贯穿于系统规划、系统设计、实现、集成和部署的整个过程中，为解决信息“孤岛”提出了一个从根本上解决问题的方法。

    在系统框架上，充分吸收了COTS的理念，希望在BPM、SID的基础上逐步打造适合电信运营的COTS。

    TMF定义NGOSS生命周期的4个阶段：业务视图、系统视图、实施视图和部署视图，并定义了4类指导性的文档：eTOM[1]、SID[2, 3]、技术中立架构(TNA)[4]和一致性测试工具文档[5]。

    在业务视图中描述了目前电信行业所面临的挑战以及对电信运营支撑系统所提出的要求，在系统视图中提供了业务解决方案，在实施视图中描述了如何打造解决方案，在部署视图中描述了如何部署和使用业务解决方案。

    生命周期和工具文档之间的管理如图2所示。eTOM跨越了业务视图、系统视图两个阶段，SID跨越了业务视图、系统视图、实施视图，TNA跨越了系统视图、实施视图两个阶段，一致性测试则跨越了全部4个阶段。

1.1 增强的电信运营图
    TMF采用图形化的方法(即eTOM视图)来描述电信运营过程中的主要过程框架，如图3所示。顶层过程域划分为3个部分：战略、基础设施和产品，运营，企业管理。其中战略、基础设施和产品，运营横向过程分为市场、产品、客户、服务、资源、供应商与合作伙伴等层次，在纵向上分为战略与决策，基础设施生命周期管理、产品生命周期管理、运营支撑就绪、业务开通、业务保障、业务计费7个流程组。按照横向和纵向的交叉可以对每一块的过程进行进一步细化。

    eTOM给出的是一个过程的框架，反映的是一个电信运营共用的过程。eTOM把运营中的活动按照不同的层次、分类有序地描述出来，为人们展现了不同层次的视图。通过过程框架视图eTOM展现了OSS软件所需要完成的功能，为OSS的COTS软件实现形成了一个相对稳定的功能框架。

    eTOM的框架特性主要体现在4个方面：用静态过程元素去构造动态的流程，与具体产品、服务、资源无关，与组织架构无关性，具有过程的分解特性。横向和面向客户纵向的划分，在整体上形成了一定程度的流动性。但从微观的角度(子过程或活动)来看，eTOM提供的是一个静态的子过程或活动的集合。这是由于实际运营工作中流程复杂，难以用确定的流程来准确概括，采用静态过程来描述，为实际流程变化提供了自由定制的空间。在eTOM的附件中给出了数字用户环路(DSL)开通的过程流的范例，可以让人们理解如何应用过程框架中的子过程去搭建完成动态的流程。在实际的流程中，产品、服务和资源的不同，带来具体的流程流转的不同。eTOM与组织架构的无关性，为eTOM适应不同的组织架构的要求提供了适应的空间。过程的可分解特性反应了过程不断细化的框架特性。

1.2 共享信息模型
    SID为运营商、系统集成商、软件提供商提供了讨论电信运营的共同概念和语言。SID在顶级域的划分上与eTOM域的划分和业务过程横向划分是一致的。SID共分为市场、销售、产品、客户、服务、资源、提供商合作伙伴、企业、公共业务实体8个域。和eTOM可分解特性一致，SID也可以逐级分解，并且和业务过程相关。SID框架的特性在于其可以被继承和发展。SID的框架特性可以像插件那样被继续发展下去，如图4所示。SID这种特性解决了服务和资源多样性的问题。

    图5所示为BSS&OSS主要域之间的相互关系，是信息模型中基本实体间最原始的关系，为描述业务规则提供了最基本的事实模型。

1.3 系统框架
    NGOSS中，系统框架主要分为共享信息模型、安全、策略、业务过程、应用与服务5个部分，如图6所示。5个部分构成一定的相互支撑和服务关系。共享信息模型是最基础的部分，其他各个部分都以共享信息模型为基础，而且需要用模型来描述。如果把SID中主要域之间的关系描述出来就形成如图5所示的关系，这种关系就是业务规则管理中的事实模型[6]，而业务模型是策略管理中业务规则描述的基础。NGOSS强调策略管理的重要性，NGOSS重视将具体的流程控制和应用分离开来，使应用软件不受流程改变的影响。在应用中，NGOSS强调采用Web的服务机制来实现应用软件。

2 订单管理系统的实现和应用
    本文以OSS中的订单管理系统来具体分析如何应用NGOSS思想和工具来实现订单管理系统，以及如何适应前面描述的变化因素的要求。订单系统主要完成开通流程管理，以及订单处理、服务配置和激活子过程所需要完成的职责；主要从过程框架与功能框架、信息模型、系统架构考虑、系统部署与个性化定制4个方面展开。

2.1 过程框架与功能框架
    从过程框架中的定位来看，订单管理系统过程主要涉及到客户接口管理、订单处理、服务配置与激活、资源配置与分配、供应商/合作伙伴管理5个子过程，由5个子过程构成系统的过程框架，如图7所示。

    从系统功能角度来看，订单管理系统主要实现两类功能：第一类是对端到端流程的管理，包含了由5个子过程构成的程流管理；第二类是支撑订单管理、服务配置与激活子过程所需要完成的功能，客户接口管理、资源配置与分配、供应商/合作伙伴管理的功能可以在其他系统中实现。通过对这两类功能的归纳，订单管理系统的功能框架如图8所示。

    功能框架支撑过程框架，通过流程管理来支撑对具体流程的定制和调度。每一个子功能模块本身也是一个框架，支撑对不同产品、服务、资源的支撑。每个功能模块提供流程的基本元素环节，具体的环节的划分和产品、服务、资源的划分相关。

2.2 信息模型
    订单管理系统的主要信息模型遵从NGOSS的模型框架，其客户、产品、服务、资源的关系框架遵从图7所示的过程框架。系统可以按照SID提供的模式和细化模型，对具体的产品、服务和资源进一步细化。

2.3 系统架构
    订单管理系统系统的架构遵从NGOSS理念，采用J2EE软件架构实现。具体架构分4个层次：数据层、信息服务层、业务逻辑层和控制层，如图9所示。数据层要求数据模型尽可能支持元数据设计来支撑模型的改变；信息服务层将信息封装起来提供基本的信息服务；业务逻辑层通过构件来封装，构件细分为业务构件和展现构件；在控制层将业务规则抽取出来放到策略管理中满足业务规则定制的要求，业务流程的功能和其他应用模块分离，集中在流程管理模块实现，减少对应用功能的影响。

2.4 系统部署与个性化定制
    订单管理的系统部署主要考虑系统和其他系统之间的衔接问题，需要考虑流程衔接、数据衔接、功能衔接。组织架构不同，直接影响系统的部署。多级的组织架构可能会形成多级的系统部署，不仅要考虑订单管理系统和CRM、资源系统之间的集成问题，还要考虑不同级别系统之间的集成问题，往往一个客户流程贯穿于不同级的多个相同类系统。

    对于订单管理和服务配置COTS软件，在系统部署时还有不少个性化定制工作需要完成，如从COTS软件中定制出满足运营商要求的具体的流程，定制新产品开通流程等。

3 结束语
    打造OSS COTS软件是中国运营商和制造商比较关心的问题。TMF NGOSS的方法论提供了业务流程框架、共享信息模型、技术中立架构，为构建OSS COTS提供了业务流程框架、数据框架、系统架构3个方面的基本要求，在具体实现和应用OSS COTS时还需要考虑电信产品、服务、资源的特性以及具体软件实现技术，当然，还有其他OSS领域、软件工程、软件技术等方面的因素需要更进一步地研究和探讨。

4 参考文献
[1] TMF GB921 v4.0. Enhanced Telecom Operations Map (eTOM)—The Business Process Framework[S]. 2004.
[2] TMF GB922 v4.0. Shared Information/Data(SID) Model—Concept ,Principle and Domains[S]. 2004.
[3] TMF GB926 v4.0. Shared Information/Data(SID) Model—System View：Concept and Principles[S]. 2004.
[4] TMF 053 v4.0. The NGOSS Technology Neutral Architecture (TNA)[S]. 2004.
[5] TMF 050 v4.0. The NGOSS Compliance Testing Strategy Technical Specification[S]. 2004.
[6] Ross R G. 业务规则方法原理 [M]. 韩柯, 孟海军译. 北京: 机械工业出版社, 2004.

收稿日期：2005-11-21

[摘要] 客户需求、运营商组织结构、软件实现技术不断变化为形成稳定的运营支撑系统(OSS)带来了很大困难，因此寻找相对稳定的因素非常重要。电信管理论坛(TMF)的新一代运营系统和软件(NGOSS)对一些规律性的因素进行了比较深入的研究，并在NGOSS的核心理念、方法论、知识库中给予体现。结合OSS中的订单管理和服务配置系统的实施，探讨了如何开发符合NGOSS要求的OSS，认为在具体实现时还需要考虑电信产品、服务、资源的特性以及具体的软件实现技术。

[关键词] 电信管理论坛；运营支撑系统；商业套装软件；订单管理

[Abstract] The continuous changes of clients; demands, operators; organizational structures and software implementation technology make it difficult to form a steady Operation Support System (OSS). Therefore, it is important to find relatively steady factors for an OSS. The Next Generation Operation System and Software (NGOSS) program of TeleManagement Forum (TMF) deeply studied the regular factors, and the core concepts, methodology and repository of NGOSS reflect the study achievements, This paper uses the implementation of order management and service deployment system in the OSS to discusses how to develop an OSS by the NGOSS concepts and tools. It also points out that the implementation of such an OSS should take the characters of telecom products, services and resources and specific software implementation technology into account.

[Keywords] TMF; OSS; COTS; order management