使用 JAVA 技术实现新一代 OSS/BSS

SUN中国工程研究院 软件技术中心王刚

摘要：本文着眼于OSS/BSS发展的现状，对于OSS/J的技术架构、API规范以及如何进行基于OSS/J的系统开发做了简要介绍。

OSS/BSS 概述

OSS（Operations Support Systems）是指“运营支持系统”，BSS（Business Support Systems）为“业务支持系统”，OSS/BSS是这两类系统的结合在一起形成的综合的电信业务运营和管理平台，在国内OSS/BSS有时也被称为BOSS。

标准化组织电信管理论坛（TMF）对OSS/BSS提出了被业界广泛接受的功能模型。在这个模型中，OSS/BSS包括三大功能：业务开通、业务保障和计费（或称业务计量）。业务开通是指电信运营商接受客户订购电信服务的订单，通过对电信资源的分配、配置、安装和部署为客户提供所需的服务，并能够对服务进行计费。 作为一种高效的信息管理系统，OSS/BSS已在国外电信运营商中得到广泛的运用，并在实践中积累了大量的成功案例。OSS/BSS解决方案也在这一过程中趋于完善，同时也暴露出越来越多的难以克服的问题：

图1、OSS/BSS的“集成的噩梦”

l        OSS/BSS的软件系统相对复杂，从而使得网管系统、计费系统、营账系统、客服系统等都是各成体系，要想把它们有机地整合在一起，几乎是不可能的，对于这种“杂乱无章”的系统结构（参见图1），简直可以称之为系统集成的噩梦（Integration Nightmare）。

l        很多OSS/BSS开发商都有同感——缺少训练有素的工程师，这也是由前一条所决定的，需要工程师同时精通电信的专业知识，又能熟悉各类软件，的确要求比较苛刻。

l        行业标准问题。尽管在近几年来国际国内都陆续推出了一些标准规范，但大多是停留在纸面上，同时也缺少更直观的技术指导和成功案例。

l        一个OSS/BSS，往往会涉及若干个分离的系统，除了集成，对系统进行测试、维护都是十分耗时的。

以上各方面的问题，OSS/J就可以解决，原因在于：

l        采用符合OSS/J规范而开发的软件接口相对简单，OSS/BSS内部的各个子系统是可以互换的（ Interchangable ）。

l        OSS/J是基于J2EE技术的，开发人员只要熟悉J2EE的开发（甚至仅仅熟悉JAVA的开发）就足够了，他们就能够与设计人员合作，完成系统开发。

l        OSS/J不仅包括了技术规范，而且有真实的代码实现以及测试工具。这能够帮助开发人员很快的上手。

l        因为各个子系统都符合标准的接口，所以系统的后期测试和维护工作会比较简单。

什么是 OSS/J

OSS/J（OSS Through Java）是以JAVA技术为动力的新一代的OSS/BSS解决方案。

说到OSS/J，我们需要提及一个称为OSS Through Java Initiative的工作组，这个工作组由众多的业界新技术的倡导者（例如Motorola，Nokia，Sun, BEA, IBM）派出的专家组成。自2000年成立以来，他们一直在为加速OSS/BSS解决方案的开发、简化其中的系统组件的部署和集成而努力。工作组利用JAVA技术，为OSS/BSS定义实现了一系列的开放的标准API，提供给OSS/BSS的开发者使用。在不久的将来，电信行业的设备制造商、软件开发商、系统集成商都遵循这些标准API的定义，那么最后建立起来的OSS/BSS将是一个组件化的、有机结合在一起的综合管理平台（参见图2），“杂乱无章”的系统结构将成为过去。

图2、采用OSS/J构建的系统结构

需要指出的是，OSS/J并不是要定义另一个通用的OSS/BSS集成框架。工作组的成员在定义标准的API之前，已经汲取了众多标准规范和协议中的精华，例如，OSS/J很好的继承了来自3rd Generation Partnership Project (3GPP), 3GPP2, Mobile Wireless Internet Forum(MWIF)以及TeleManagement Forum(TMF)等组织或论坛推出的规范和框架体系。因此，工作组将所有的经历投入到了JAVA API的定义和编码实现上，而且使用OSS/J规范的的用户可以免费地获得这些资料。

TMF在NGOSS 3.0（Next Generation Operations Support Systems下一代运营支持系统）的文档中，推出了详细的OSS/BSS的定义。（参见http:// www.tmforum.org ）。OSS/J的API定义遵守了NGOSS eTOM （enhanced Telecom Operations Map）的规定，详细内容请见“OSS/J API简介”部分。概括地说，NGOSS为我们提供了独立于技术实现的普遍适用的框架，而OSS/J则是以该框架为基础，提出了采用JAVA技术的实现方案。

OSS/J的规范的推出是在JCP（ Java Community Process, http://jcp.org）支持下完成的。通过访问JCP的网站，或者光临http://java.sun.com/products/oss，你都可以下载到OSS/J的规范、参考实现和兼容性测试工具，下面逐一简介：

OSS/J的规范：包括OSS/J API规范和OSS/J J2EE系统设计指导。这些内容将在“OSS/J API简介”中详细叙述。

OSS/J 参考实现（ Reference Implementation或 RI）：主要内容是根据OSS/J API规范而完成的系统实现的代码。推出RI一方面是为了验证规范的可执行性，所以RI的代码未曾经过很好的优化。RI的另一个重要的作用是它能够使得开发者很快的着手进行设计和开发工作，而且，RI中的所有代码可以被开发人员直接使用到商业系统的开发中去。所以，仔细阅读分析RI的代码能大大缩短你用于熟悉OSS/J的时间。

兼容性测试工具（ Test Compatibility Kits或 TCK ）：当一个OSS/BSS（或其中的一个子系统）的开发完成了以后，我们如何才能知道它是否符合OSS/J 规范的规定呢？TCK可以完成这样的测试，并产生一个测试报告。如果开发的产品符合OSS/J规范的要求，那么它将很容易和其它同样兼容OSS/J规范的产品集成在一起。

OSS/J的规范推出以后，得到了业界的广泛认可，许多电信运营商、服务提供商、系统集成商争相追随。来自IDC的2002年的报告说，“……随着SA、TT、Qos API的发布，许多服务提供商和供应商认为,采用JAVA技术实现OSS已经到了实际可行的阶段。”

OSS/J 与 J2EE

上文提到，OSS/J可以帮助我们终结“系统集成的噩梦”，因为它为我们定义了一系列的标准API，只要各个厂商都能遵守API中的规定，那么OSS/BSS的集成难的问题将迎刃而解。那么具体的底层实现机制是怎样的呢？——OSS/J采用了J2EE作为技术平台。

J2EE（Java 2 Enterprise Edition）即Java 2企业版，是提供给开发者的采用组件技术构建分布式系统的编程框架，需要更深入了解J2EE，请浏览http://java.sun.com/j2ee/。总体来说，J2EE使得开发人员无须去考虑分布式系统中的底层技术实现细节，例如线程管理，网络通信等，而是集中精力开发符合业务逻辑的代码，这无疑大大加快了应用程序的开发进程，而且简化了系统的部署和后期维护工作。目前全球的J2EE开发人员总数已经达到了几百万，这个群体还在迅速膨胀。

图3、采用J2EE实现OSS/BSS

作为服务器端的开发技术，企业JavaBean（EJB）、扩展标记语言（XML）以及JAVA Management Extensions（JMX）都在OSS/J中被采纳。因为J2EE、XML、JMX已经在很多的大型企业应用（特别是服务器端的应用程序）中获得了成功，所以OSS/J采用它们定义在组装、开发和部署OSS/BSS解决方案时所需要的API。

图3是采用J2EE实现OSS/BSS的示意。以OSS/J API为基础，我们开发了支持SA、TT等功能的EJB，这些EJB可以根据需要通过JDBC存取数据库，或通过JNDI访问目录服务器。对于已有的遗留系统以及EMS（Element Management Systems），可以采用J2EE连接器的架构（Java Connector Architecture即JCA）通过SNMP、CMIP或其他专有协议实现集成。OSS的客户端可以是浏览器或定制的应用程序，通过HTTP/XML/Java/IIOP和系统相联。与此同时，JAVA的消息机制为我们提供了更加灵活的“松耦合（loosely-coupled）”的集成方式，利用它可以简单地实现和Intranet/Internet中的其他系统的连接。

OSS/J API 简介

图4将OSS/J中的核心API和TMF的eTOM的各个过程做了映射。从图中可以看出，OSS/J核心API囊括了客户管理、订单管理、服务开通等20个，关于每个API的详细描述，可参见http://java.sun.com/products/oss/apis.html上的OSS/J API Roadmap。目前，已经完成的API有：OSS服务开通API，OSS故障单API，OSS通用API，OSS IP计费API和OSS服务质量控制API，而OSS 库存 API不久将发行。除了API，OSS/J工作组还为开发者提供了《OSS/J J2EE 系统设计指导》。

图4、OSS/J API到eTOM的映射

OSS通用 API（ OSS Common API）：和其他OSS/J API不同的是，它本身没有对OSS/BSS在业务逻辑提供支持，而是为开发者使用OSS/J API提供了一个基础框架。可以认为这部分API是《OSS/J J2EE 系统设计指导》一个具体实施。需要强调的是，既然是基础框架，以下提及的所有OSS/J API都是依赖于通用API的。

OSS/J J2EE系统设计指导（ OSS/J J2EE Design Guideline或 OSS/J J2EE DG）：定义了一系列的设计模式（Design Patterns），这些模式非常适合于采用J2EE/EJB搭建网络服务管理系统。总体来看，DG中提及的设计模式都是来自于J2EE设计模式，关于J2EE设计模式的详细信息，请参见http://java.sun.com/blueprints/corej2eepatterns。DG中主要涉及到以下要点：

l        OSS中的功能都是采用EJB组件的形式实现的

l        这些EJB提供了面向业务逻辑的粗略的接口

l        应用服务器为OSS/BSS系统提供了集群、扩展和故障处理等功能

l        采用消息（Messaging）交换机制来减小组件之间的耦合程度

l        结合消息机制和JCA架构实现系统的集成和工作流的管理

贯穿DG的一个重要概念就是“软件构件（Software Building Block）”的概念。一块软件积木是若干软件组件（Component）的集合体，这些软件组件相互协作，从而满足系统业务逻辑的需求。需要强调的是，OSS/J API的所有定义和实现方式都是遵从OSS/J J2EE DG的。

OSS服务开通 API（ OSS Service Activation API或 SA API）：主要提供了对订单的管理功能（例如生成、修改、删除、查询订单等）和服务的管理功能。API中并没有给出指定的“服务信息模型（Service Information Model）”，而是将这部分工作留给开发者去实现，这样开发者可以根据自己的业务逻辑的需要定义服务信息模型。SA API中关于订单管理的定义是根据TMF 603中的“世界订单信息协定”（World Ordering Information Agreement）以及OMG WMF/WfMC的“订单状态模型（Order State Model）”的定义完成的。

OSS故障单 API（ OSS Trouble Ticket API或 TT API）：定义了生成、更新、查询、关闭故障单的一系列操作。网管系统可以通过调用TT API自动生成故障单，服务提供商也可以利用它产生和处理故障单，客户关怀系统能够调用这些API将故障单发送给服务提供商（见图5）；如果故障单的管理是在一个工作流程中完成的话，那么开发人员可以使用这些API与工作流引擎进行信息传递。

OSS IP计费 API（ OSS IP Billing API）：定义了IP计费的数据源和计费系统之间的接口。这部分API适用于针对2.5G和3G网络的OSS/BSS开发。而且API的定义重点放在（但不不局限于）无线通信的领域。该规范的定义是为了实现计费系统、计费数据采集系统、计费数据源这些不同的子系统之间够实现无缝连接，流畅地完成各种记录类型（例如CDR、SDR、IPDR等）的交换和传输。

OSS服务质量 API（ OSS Quality of Service API或 OSS QOS API）： QOS API使得QOS系统能够从其他系统得到影响服务质量的数据，例如网络性能、极限值以及故障数据等等。QOS API主要涉及到性能和使用情况的数据监测、系统极限值的监测及故障数据的监测三个方面的内容。

OSS 库存 API （ OSS Inventory API ）： OSS/BSS在进行操作的时候，大多需要关于网络可以提供的产品、服务和资源的规划、使用的情况，这些功能要由库存API来提供。这部分API包括了对产品和服务的目录管理，并且有跟踪用户预定和使用产品或服务的功能；同时API中对网络资源管理（例如网络上的设备和网络拓扑结构的管理）的功能对于OSS/BSS来说也是不可或缺的。

下图展示了各个OSS/J API之间的关系，其中椭圆形的边界可以看做是API的定义，矩形的内容是由开发商来实现的，而箭头代表方法或功能的调用，这些功能调用，尤其是各个子系统之间（例如从Qos调用故障单中的功能）应该使用OSS/J的API来完成。

图5、OSS/J API的关系

OSS/J 开发指导

了解了OSS/J API的概况以后，可能你已经决定着手进行基于OSS/J的系统开发了。无论你是系统设计人员还是程序员，应该具备J2EE的开发经验，而且最好了解电信行业知识（特别是关于OSS/BSS方面的知识）。而且，建议你按照以下的步骤来开展工作。

研读 OSS/J相关的资料

浏览OSS/J的网站http://java.sun.com/products/oss，你可以下载到OSS/J的规范和相关技术文章（如图6所示）。前面提到，试着部署一下RI并研究其代码能帮助你迅速了解OSS/J。如果你在学习和使用的时候有什么疑问和意见，都可以发表在相应的新闻组里（新闻组的地址参见OSS/J的网站）。

图6、下载OSS/J规范、RI进行开发

开始 OSS/BSS 的设计与实现

这个过程和标准的软件开发没有大的区别，主要经历从制定计划、需求分析、系统设计、详细设计、编码实现和测试等几个环节。由于进行OSS/J的开发是基于J2EE技术的，所以选择稳定高效的应用服务器（Application Server）和集成开发环境（IDE）十分重要，好在由于J2EE的开放性，我们有很多选择，例如Sun ONE应用服务器、BEA Weblogic、Borland Jbuilder等。在系统设计和详细设计时，设计人员需要首先熟悉OSS/J J2EE设计指导中内容，按照其中讲述的设计模式进行设计。至于编码实现，和一般的J2EE开发没什么区别，主要涉及到EJB的编程，同时需要程序员对XML比较熟悉。进入到测试阶段，除了完成普通软件开发需要完成的一系列测试以外，OSS/J规范的兼容性的测试也是必须的，如上文所述，TCK可以帮你完成这一个步骤（参见图7）。

图7、使用TCK进行测试

发布自己的产品信息

当你开发的产品成功地通过了TCK的测试以后，就可以获得OSS/J的认证。OSS/J针对OSS/BSS产品规定了一个灵活的“自我认证流程”，参见图8。上文中提到，使用TCK测试你的产品，将产生一个测试报告。如果测试成功，可以将报告发布到你的公共网站上，同时通知OSS/J工作组的程序管理小组。经过核实以后，OSS/J程序管理小组将会更新OSS/J的网站，将你发布的产品测试报告的链接（URL）加到通过认证的产品列表中去。到现在，整个“自我认证过程”就完成了。获得了OSS/J的认证，意味着你开发的产品可以很容易地和其它厂商的也获得认证的产品集成起来，可以作为有机的一部分加入到基于OSS/J API的OSS/BSS中去。参见http://java.sun.com/products/oss/adoption/ossj_certified_products_table.html，在这里，你可以看到IBM、Ilog、Nokia等许多厂商的产品都已经获得了OSS/J的认证。

图8、OSS/J的“自我认证”

加入 OSS/J工作组

如果你希望能最及时地了解OSS/J的发展动向，获得最新的信息，甚至希望参与规范的制订和修改，那么最有效的方式就是加入到OSS/J的工作组中来。OSS/J工作组中的成员有着不同的级别，分别有不同的权利。请查看http://java.sun.com/products/oss/members.html了解加入OSS/J工作组的细节内容。

总结

OSS/J为我们提供了一个采用Java技术实现OSS/BSS的技术框架，它借鉴了众多的既定行业规范，以J2EE/XML技术为基础，为OSS/BSS的开发者提供了一个标准的环境，以解决目前OSS/BSS中存在的集成问题。相信随着相关技术的进步，OSS/J会拥有越来越多的支持者，从而发展成为用JAVA实施OSS/BSS的技术标准。

参考资料

l        Operations Support Systems, http://www.iec.org

l        OSS through Java Initiative, By Philippe Lalande

l        OSS through Java Initiative, Simplifying Integration with Common APIs, http://java.sun.com/products/oss

l        OSS/J API Roadmap

l        Case Study: From NGOSS Map to OSS/J Roadwork, http://www.tmforum.org/browse.asp?catID=1483&sNode=1483&Exp=Y&linkID=28103, By Peter Lambert

l        OSS through Java Design Guidelines, http://java.sun.com/products/oss/apis.html

l        OSS Trouble Ticket API

l        OSS Service Activation API

l        OSS Common API

l        OSS IP Billing API

l        OSS Quality of Service API

l        OSS Inventory API

    随着信息时代的到来，我国各行各业都面临着诸多机遇与挑战，党和政府适时地提出"以信息化带动工业化，发挥后发优势，实现社会生产力的跨越式发展"的伟大战略决策。在近几年的信息化建设中，一些企业在企业信息化建设方面的投入较大，但收效甚微。原因之一在于：缺乏统一的信息化框架、标准和规范。在我国电子商务、电子政务全面发展之际，此框架、标准和规范就显得尤为重要，只有按照统一的框架、标准和规范，才可能避免重复建设、实现信息共享。

    目前人们都把电信企业当作是信息化建设的排头兵，这隐含有四层意思：

    （1）电信企业是国家信息基础设施的主要建设者和运营者，担负着基础建设的重要使命；

    （2）电信业自身的信息化建设能够强化企业自身的管理规范，提高运营效率和综合竞争能力；

    （3）电信企业可以利用自身的信息化典范，为其他的企业提供信息化的解决方案，作为一种新的业务为客户提供更好的服务；

     (4)电信企业自身的信息化建设更具有推进社会信息化、政府信息化、企业信息化的示范作用。

    信息化建设需要规范的业务流程和管理流程做基础，电信运营业务流程最新的国际规范eTOM3.0版对电信相关企业的信息化建设和企业运营至关重要。

    一、eTOM中"e"的含义

    "eTOM"中的"e"常规指"增强"之意，但它却包含了与业务流程框架有关的很多含义，如：企业流程(Enterprise processes)、电子商务激活(eBusiness enabled)、扩展的(Expanded)、每事(Everything)、每处(Everywhere)、每时(Every time)等。

    二、eTOM业务流程框架的目的

eTOM业务流程框架作为电信运营业务流程的向导蓝图和业务及运营支撑系统(分别为BSS和OSS)发展和集成的始发点，有助于推动和发展NGOSS(Next Generation Operations Systems and Software，下一代运营系统和软件)解决方案。对于服务提供商来说，当他们考虑内部流程重组需求、合作关系、联盟以及与其它服务提供商总的工作协议时，eTOM提供了一个中性的参考点。对供应商来说，eTOM框架给出了软件各组件的潜在边界以及支撑产品所需的功能、输入和输出。

    eTOM3.0版包含以下内容：

    （1）eTOM业务流程框架的角色描述；

    （2）服务提供商的电子商务环境和所需的更为复杂的业务关系环境关联模型；

    （3）服务提供商的企业流程和子流程在高级层面的业务流程框架和解释的侧重点是自上而下、以顾客为中心、端到端，TOM正逐步向eTOM演变，目前的eTOM业务流程框架对于服务提供商来说是整个企业的框架；

    （4）所有流程的分解，从eTOM框架的最高层面的概念视图到工作层面，有选择地给出框架中很多较低层面的流程分解；

    （5）流程流向和分解流程的选择描述，包括流程目的或描述、业务规则、高级层面的信息等；

    （6）如何运用流程框架。

    eTOM的目的是通过对业务流程的实施来管理企业，帮助企业明确目标，确保有关服务交付和支持所有关键的企业支撑系统进行集成。eTOM关注的焦点是：服务提供商使用的业务流程、流程间的联系、接口的识别，即如何利用客户、服务、资源、供应商/合作伙伴以及其它多重流程使用的信息。

    eTOM业务流程框架和相关的业务流程模型描述了流程及组成端对端的连接点，描述了运营、战略、基础设施与产品流程区域中开通、保障、计费等客户运营流程流向。eTOM业务流程框架对信息和通信服务、技术管理有特殊意义，这种模型同样适用其它类型的业务。

    服务提供商应用这种通用的流程框架，以确保与其它实体交易的高效和有效，确保第三方软件的开发和应用不需太多的客户化定制。在电子商务环境下，对流程的共同理解，此框架在管理信息和通信业务市场中十分关键。企业电子商务集成化已成为强大的流程集成最成功的范例。eTOM不仅是电子贸易或电子商务流程框架，它还支持传统业务流程与电子商务的集成。

    三、eTOM是什么

    eTOM，是enhanced Telecom Operations Map的英文首字母缩写，英文全称为enhanced Telecom Operations MapTM (eTOM)。The Business Process Framework For The Information and Communication Services Industry，中文意思为增强的电信运营图(eTOM)信息和通信服务行业的业务流程框架。eTOM现在已经发展到3.0版，并已于2002年6月通过电信管理论坛（TM论坛）的批准，正式公开发布。eTOM大大增强了TOM的功能，是服务提供商运营流程实际依照的行业标准。

    eTOM是一种业务流程模型或框架，它为服务提供商提供所要求的企业流程。但是，它不是服务提供商的业务模型。它不陈述以下策略：服务提供商的目标客户、服务提供商所服务的市场、服务提供商前景、任务等，业务流程框架是业务模型策略的一部分，是为服务提供商提出计划。

    eTOM是基于TOM（Telecom Operation Map）发展而来的，eTOM把TOM扩展到整个企业架构，并陈述对电子商务的影响。虽然eTOM比TOM复杂得多，在某种意义上，eTOM更为直接明了，它消除了TOM中企业管理（公司型）流程、市场营销流程、保留客户流程、供应商和合作伙伴管理流程之间的隔膜等。

    很多服务提供商（包括了系统集成商、ASP和软件供应商）指出，在eTOM未被确认前，他们已经在运用eTOM，因为eTOM较好地代表了他们的真实需要，他们在采购软件、设备以及面对业务关系网络与其它服务提供商的接口，都需要行业的标准框架。虽然，很多服务提供商已接受TOM，并把它作为流程框架核心或是作为保持相容性的标准，但大多数服务提供商承认需要进一步扩展TOM，以便反映电子商务集成化和全企业的框架。图1为eTOM业务流程框架0级流程图。

    图1： eTOM业务流程框架——0级流程图

    图1显示的是eTOM业务流程框架最高层面的概念视图。该视图把战略和生命周期流程从运营流程中分离出来，形成两大流程群组，同时把关键功能区域分成四个横向层面。此外，图1也显示了企业内、外部的相互影响、相互作用的五大实体(客户、供应商/合作伙伴、股东、雇员、其他利益相关者)。图2为eTOM业务流程框架一级流程图。

    图2：eTOM业务流程框架—— 一级流程

    图2给出了eTOM框架中从0级视图看到的一级流程。该视图称为企业流程框架CEO(即：首席执行官)层面的视图。然而，人们倾向于使用二级流程的一级视图，因为在分析业务时需要这些细节。图2给出了7个纵向流程群组。这些端对端的流程用以支持客户和管理业务。eTOM关注的焦点是以客户运营流程的开通、保障和计费(FAB)为核心。运营支持与就绪流程从FAB实施流程中分出来单列，以增强对FAB中实现支持和自动化的关注，即：对在线和对客户实现即时支持。战略与承诺及两个生命周期管理纵向流程群组也分离出来，因为与运营流程群组不同，它们没有直接支持客户，与运营流程群组有着本质差别，并且工作在不同的业务周期。图2中的横向流程群组区分了功能运营流程和其它类型的业务功能流程，如：市场营销对销售、服务开发对服务配置等。左边的功能流程（在战略与承诺、基础设施生命周期管理、产品生命周期管理纵向流程群组）保证支持和指导运营流程区域的纵向流程工作。

    四、TOM与eTOM的比较

    服务管理业务流程模型被称之为TOM，是根据服务提供商的运营管理要求，围绕流程、输入、输出和活动开发。它关注的焦点和范围是运营和运营管理，它竭力为电信业服务，支持对服务提供商流程的理解，在业务、运营系统和软件方面为服务提供商的问题提供解决方案。TOM仍然处于eTOM业务流程框架的核心。

    TOM2.1版本是TM论坛成员现在认可的业务流程框架或模型。世界各地的服务提供商广泛接受它作为运营业务流程框架，而很多供应商把它作为产品开发和销售的基础。基于以下两点，把TOM的修改称为eTOM。第一，成员们很久以来就想把TOM扩展为全企业业务流程框架；第二，利用电子商务和互联网取得成功很关键。TOM并没有充分地分析电子商务对商业环境、业务驱动力、电子商务流程集成化要求的影响，也没有分析日渐复杂化的服务提供商的业务关系。图3为电信运营图业务流程模型。

    图3为电信运营图（TOM）业务流程模型

    如图2和图3所示，与TOM相比，eTOM做了以下改善：

   （1）把范围扩展到所有的企业流程；

   （2）鉴于市场营销在电子商务环境中所处的重要地位，明确标识市场营销流程；

   （3）明确标识企业管理流程，以便企业中的每个人都能够确定其关键流程，从而使整个企业都接受流程框架；

   （4）把开通、保障和计费（FAB）引入高级层面的框架视图中，从而强调客户优先流程是企业关注的焦点；

   （5）定义运营支持与就绪纵向流程群组，此定义可适用于除企业管理以外的所有功能层面。为使电子商务集成和客户自助管理成为现实，企业必须了解自己需要的流程，以保证客户运营支持和客户自助管理；

   （6）明确SIP(Strategy， Infrastructure and Product)流程：战略与承诺，基础设施生命周期管理和产品生命周期管理，识别这三种企业流程群组，它们明显区别于客户运营流程；

   （7）识别战略和生命周期管理流程的不同周期时间，需要把这些流程从最需要自动化的客户优先运营流程中分离出来，可以通过把战略与承诺和两个生命周期管理流程从日常的客户运营流程中分离来实现。

   （8）从关注客户或是面向服务转为面向客户关系管理，强调客户自助管理和控制，增加客户对企业产生的价值，利用信息来为单个客户个性化和客户化，这可以为客户运营功能层面增加更多的元素，更好地代表销售流程，完成市场营销在客户关系管理范围内的集成；

（注意：eTOM对客户关系管理进行了更广泛的定义，比CRM某些定义的范围要大。）

   （9）明确了跨技术管理资源的要求（即：应用、计算和网络），由"网络和系统管理"功能流程向"资源管理与运营"集成。它把IT管理引入到该功能层面，与外向流程群组形成对照。

    TOM是服务提供商运营管理事实上的行业标准，eTOM与TOM相比保留了TOM中以下优点：

    （1）关注于业务流程；

    （2）以客户为中心的驱动手段；

    （3）自上而下的定位；

    （4）通用直白的描述和手段；

    （5）本身吸引，服务提供商能立即了解运营的工作方式；

    （6）一直关注运营管理；

    （7）在服务提供商、供应商和媒体之间广泛使用；

    （8）灵活地支持大多数SP的流程模型。

    这些优点促使TOM成为运营系统具有推动作用的架构，成为服务提供商的软件解决方案，它仍然作为业务流程框架，并涉及更多的流程和学科。在电子商务环境下，实体间的联系是流程中最重要的环节。eTOM会加强以客户为中心的驱动途径，因为目前和将来的环境能够掌握客户。电子商务使市场从面向供货转为面向需求，或者说由"推向客户"变为"客户拉动"。eTOM中保留自上而下的定位，不仅因为它是TOM的核心概念，而且它是良好的业务流程建模。

    五、eTOM的使用对象

    eTOM提供了通用的服务提供商企业流程视图，较容易转换成单个提供商的内部手段。

    eTOM的优点之一是能为服务提供商根据需要在不同层面广为采用。eTOM也可作为翻译，允许服务提供商参照行业框架绘制其明确流程。当流程样本开发出来，服务提供商就能利用和调整样本以适应自己的业务环境。

    eTOM针对的是信息和通信行业广大的专业人员，对于有经验的通信专业人员来说，TOM和eTOM是直观的、强大而通用的服务提供商企业流程。

    eTOM针对服务提供商和网络运营商的决策者，需要了解和输入通用的业务流程框架，以较好的性价比实现企业自动化。对于从事业务和运营自动化的专家，它也是很重要的架构。

    eTOM将继续为服务提供商和供应商提供一个通用的框架进行讨论，在复杂的行业中讨论复杂的技术和复杂的业务需求。这些复杂性来自：从开发自己的业务和运营系统软件，转向更多的采购和系统集成的方式；服务提供商和网络运营商之间新型的业务关系。

    建立新型的业务关系和不进行内部开发是对市场驱动力的回应。市场驱动力要求服务提供商和网络运营商增加业务的范围、缩短新业务投向市场的时间、提高服务速度以及降低系统和运营成本。

    eTOM业务流程框架针对服务提供商和网络运营商涉及业务流程重组、运营、采购和其他活动的人员，使他们能了解并推动集成化和自动化进程的通用业务流程框架，参与提供流程、输入、优先级和要求的活动。

    eTOM业务流程框架也针对业务和运营管理系统软件的设计者、集成者以及设备供应商，通过了解管理流程和应用需求，为服务提供商和网络运营商带来利润。

    eTOM业务流程框架提供一个通用架构，支持大量的集成、合并活动，了解好通用流程和通用流程框架将为合并大大改善集成性能。eTOM适用于所有的电信服务提供商。不是所有供应商都要用到eTOM定义的所有流程。eTOM框架灵活，使服务提供商可以根据模块基础和恰当的具体层面需求来选择所需的流程。

近年来，我国电信业发展迅猛，电话普及率已达33.7％，电话用户总数跃居世界第一。与世界发达国家的电信业相比，我国电信运营商在技术设备和网络基础设施等"硬件"方面的差距并不大，但是在业务流程、企业管理和劳动生产率等"软件"方面仍存在较大差距。eTOM将为我国电信业与国际接轨、缩小"软件"差距带来机遇。

eTOM的发展

eTOM，英文全称为enhanced Telecom Operations Map。（eTOM）———The Business Process Framework For The Informationand Communication Services Industry。

中文意思为增强的电信运营图（eTOM）———信息和通信服务行业的业务流程框架.eTOM源自TOM（TelecomOperationsMap）。TOM侧重的是电信运营行业的服务管理业务流程模型，关注的焦点和范围是运营和运营管理。世界各地的服务提供商广泛接受它作为运营业务流程框架，而且很多供应商已把TOM作为产品开发和销售的基础。随着企业在业务中使用因特网、集成电子商务机遇的需要，仅关注运营管理的TOM已显出极大的局限性。TOM没有充分地分析电子商务对商业环境、业务驱动力、电子商务流程集成化要求的影响，也没有分析日渐复杂化的服务提供商的业务关系。因此，TM论坛的成员们很久以来就想把TOM扩展为全企业业务流程框架。eTOM中的e常规指"增强"之意，但它却包含了与业务流程框架有关的很多观念，如：企业流程（Enterpriseprocesses）、电子商务激活（eBusinessenabled）、扩展的（Expanded）、每事（Everything）、每处（Everywhere）、每时（Everytime）等。TOM仍然处于eTOM业务流程框架的核心。

eTOM作为电信运营业务流程向导的蓝图，是NGOSS（NextGenerationOperationsSystemsandSoftware，即下一代运营系统和软件）的重要概念和关键组成元素。NGOSS中的"OSS"虽与通常的"OSS"（OperationSupportSystem）在字面上相同，但是内涵已经发生了很大变化。NGOSS强调包含有文档、模型和代码等知识库的创建，侧重于业务流程和信息模型的定义、系统框架的定义、合作催化试点项目的实施等关键元素。

eTOM是什么

eTOM是一种业务流程模型或框架，它为服务提供商提供所要求的企业流程，但它不是业务模型。

它不陈述以下策略问题：谁是服务提供商的目标客户，服务提供商所服务的市场是怎样的，以及服务提供商的愿景如何、任务是什么等等。

eTOM较好地代表了电信运营业的真实世界，很多服务提供商（包括了系统集成商、ASP和软件供应商）已经在运用eTOM，因为他们在采购软件、设备，以及面对愈加复杂的业务关系网络中与其它服务提供商的接口，都需要行业的标准框架。

对于服务提供商来说，当他们考虑内部流程重组需求、合作关系、联盟以及与其它提供商的总的工作协议时，eTOM提供了一个中立性的参考点。对供应商来说，eTOM框架给出了软件各组件的潜在边界，以及支撑产品所需的功能、输入和输出。

为方便起见，笔者对TM论坛公布的eTOM的0级和1级流程视图进行了组合。eTOM阐述了电信运营商及其所处的经营环境，给出了企业内、外部的相互影响、相互作用的五大实体：客户、供应商/合作伙伴、股东、雇员、其他利益相关者。

eTOM给出了三大流程群组：

1）战略、基础设施和产品；

2）运营；

3）企业管理。

这三大流程群组进一步分解为23个一级流程群组和87个二级流程以及若干三、四级流程；其中7个一级的纵向流程群组，是端对端的流程，用以支持客户和管理业务；16个横向流程群组区分了功能运营流程和其它类型的业务功能流程。eTOM的关注焦点是以客户运营流程的开通、保障和计费（FAB）为核心，运营支持与就绪流程从FAB实施流程中分出来单列，以增强对FAB中实现支持和自动化的关注。

eTOM对我国电信业的意义

我国电信业经过前几年的快速发展，网络基础设施和用户数量都已达到相当大的规模。如何有效地管理和充分利用这些资源（网络基础设施、客户资源、信息资源等）是各电信运营商都要面对的关键问题。eTOM的目的是通过业务流程的实施来管理企业，它涵括了战略、经营和保障等企业的三大高层流程及其相互间的集成。服务提供商需要这种通用的流程框架，以确保有效和高效地与其它实体进行交易和交互，确保第三方软件的开发和应用而不需太多的客户化定制。在电子商务环境下，这种对流程的共同理解，在管理电信业务市场中愈来愈复杂的业务关系中极其重要。

在经济全球化、信息化时代，在电子商务环境下，业务流程已经逐渐取代资金和技术，成为支撑企业赚钱的最主要因素。在价值网中，企业是通过紧密相联的业务流程，把技术、产品和服务，转变为现金。可以说，业务流程已经成为企业核心竞争力的重要组成部分。在同等的人、财、物的投入条件下，不同的业务流程所产生的结果将是完全不同的。eTOM从企业整体和所处的社会经济环境的角度和高度来认识和看待电信企业运营的业务流程框架，对我国电信业的稳步、快速发展将具有深远的现实意义。

在战略流程方面，eTOM体现了对企业资源的全生命周期管理和一体化管理的理念。eTOM明确识别了SIP（Strategy，InfrastructureandProduct）流程群组：战略与承诺，基础设施生命周期管理和产品生命周期管理。战略和生命周期管理流程具有不同的时间周期，需要把这些流程从最需要自动化的客户优先运营流程中分离出来。

在运营流程方面，eTOM体现了面向客户关系管理、对客户提供区别服务和营销的理念。除了FAB外，eTOM还定义了运营支持与就绪纵向流程群组。为使电子商务集成和客户自助管理成为现实，企业必须了解自己需要的流程，以保证直接的、愈来愈多的在线以及客户运营支持和客户自助管理。从关注客户或是面向服务转为面向客户关系管理，强调客户自助管理和控制，增加客户对企业产生的价值，利用信息来为单个客户个性化和客户化。明确了跨技术管理资源的要求（即：应用、计算和网络），由TOM的"网络和系统管理"功能流程向eTOM的"资源管理与运营"集成。

在保障流程方面，eTOM明确标识了企业管理流程，把企业管理流程和运营、战略作为一个整体，以便企业中的每个人都能够确定其关键流程，从而使整个企业都接受流程框架。

eTOM提供了通用的服务提供商企业流程视图，它很容易转换成单个提供商的内部手段。eTOM能为服务提供商根据需要在不同层面广为采用。eTOM的框架很灵活，专门的服务提供商可以根据模块基础和恰当的具体层面需求来选择自己所需的流程。

eTOM为服务提供商和供应商提供了一个通用的框架，便于在复杂的行业中讨论复杂的技术和复杂的业务需求。eTOM从企业整体的角度和高度，全方位地提供了技术人员与管理人员之间沟通的桥梁、语言与规范。而现实情况中，技术人员与管理人员因为看问题的侧重点不同，常常难以进行全面、深入、良好的沟通，难以从不同侧面、不同层次对企业运营的流程达成共识。eTOM特别关注服务提供商使用的业务流程、流程间的联系、接口的识别，如何利用客户、服务、资源、供应商/合作伙伴以及其它多重流程使用的信息。在电子商务的环境下，从业务的各个方面来充分利用信息，实现自动化以提高生产率和收入以及改善与客户的关系尤为重要。

除了电信运营商，eTOM也适用于业务和运营管理系统软件的设计者和集成者，以及设备制造商和供应商。他们通过了解管理流程和应用需求如何共同工作，为服务提供商和网络运营商带来利润，而他们也将从中获利。

几点建议

经过近几年的信息化建设，不少企业在企业信息化方面的投入很大，却见效甚微。原因之一是：缺乏统一的业务流程框架、标准和规范。信息化需要规范的业务流程和管理流程作为基础。在电子商务、电子政务全面出击之际，框架、标准和规范就显得尤其重要；只有按照统一的框架、标准和规范，才可能避免重复建设，实现信息共享。人们都把电信企业当作是信息化建设的排头兵，这实际上隐含有四层意思：1）电信企业是国家信息基础设施的主要建设者和运营者，担负着基础建设的重要使命；2）电信业自身的信息化建设能够强化企业自身的管理规范，提高运营效率和综合竞争能力；3）电信企业可以利用自身的信息化典范，为其他的企业和单位提供信息化的解决方案，为企业开拓新的信息化业务，作为一种新的业务来为客户提供更好的服务；4）电信企业自身的信息化建设更具有推进社会信息化、政府信息化、企业信息化的示范和带头作用。因此，电信企业在信息化建设进程中应该率先垂范，成为"以信息化带动工业化，发挥后发优势，实现社会生产力的跨越式发展"的伟大战略实践的先行者。

在电子商务环境下，业务流程的互动牵动着各企业之间的互动，各经济实体之间的联系是流程中最重要的环节。为此，笔者建议：电信运营商应从业务流程的梳理与再造着手，先梳理然后再造业务流程，理顺业务流程各环节的关系，真正关注客户能够感受到的服务质量。

内部流程的梳理与再造。这是指在企业内部围绕业务流程来安排各项工作，其重点是大规模削减企业组织内部的成本，提高质量和生产率。以eTOM为指导，整体规划，建立比较完善的XSS（XSupportSystems，如OSS，BSS，MSS等）。在软件开发和业务关系方面，无论是服务提供商，还是网络运营商，都要考虑：1）从开发自己的业务和运营系统软件，转向更多的采购和系统集成的方式；2）服务提供商和网络运营商之间新型的业务关系。建立新型的业务关系和不进行内部开发是市场驱动力所致。市场驱动力要求服务提供商和网络运营商增加业务的范围、缩短新业务投向市场的时间、提高服务速度以及降低系统和运营成本。

外部流程的梳理与再造。从改善企业内部的绩效开始，在跨越企业组织界线的操作与处理过程中考虑更多的改良，为企业的运营方式带来突破性的革新。也就是说：通过广泛应用信息技术，重新规划跨越组织界线的业务流程，以实现经营绩效的突破性提升。这须要企业重新审视、梳理整个企业的经营模式，对业务流程和其中各个环节之间的相互关系进行审查，审查的对象不仅仅是企业与客户的关系，还应包括企业与供应商、合作伙伴、员工和竞争对手之间的关系。各电信运营商之间既是竞争对手，同时又是合作伙伴，应该采取有效措施加快和确保电信网络基础设施之间的互联互通。

服务质量和服务等级协议。组织研究和实施"客户QoS（QualityofService）/SLA（ServiceLevelAgreement）管理"。以前，电信运营商只关注网络的QoS，而轻视客户的QoS；今后，电信运营商更需要看重客户能够真正感受到的服务质量（QoS），而不仅仅是网络的QoS。因为，客户能够真正感受到的服务质量，其内涵远远多于网络QoS。这就需要监视、管理和报告在企业的服务描述、客户合同或产品组合中有具体定义的和实际提供给客户的服务质量的对比；同时，关注与企业的业绩、某些专门服务的服务等级协议（SLA）相关的产品与服务，以及其他与服务相关的文档，包括：网络、资源性能和可用性等运营参数，还包含跨服务合同或规则参数的性能；如：订单请求的准时完成率，修复承诺的时间，客户联系的实施等。如果不能满足合同规定的SLA要求，就要采取向客户报告、并对客户进行计费调整等措施，以取得客户的理解和谅解，让客户感到满意。（人民邮电报）