??xml version="1.0" encoding="utf-8" standalone="yes"?>
SUN中国工程研究?软g技术中?j)王?/font>
摘要Q本文着gOSS/BSS发展的现Ӟ对于OSS/J的技术架构、API规范以及(qing)如何q行ZOSS/J的系l开发做?jin)简要介l?/span>
OSSQ?span lang="EN-US" style="FONT-FAMILY: serif">Operations Support SystemsQ是?span lang="EN-US">“运营支持系l”,BSSQ?span lang="EN-US" style="FONT-FAMILY: serif">Business Support SystemsQؓ(f)“业务支持系l”,OSS/BSS是这两类pȝ的结合在一起Ş成的l合的电(sh)信业务运营和理q_Q在国内OSS/BSS有时也被UCؓ(f)BOSS?/font>
标准化组l电(sh)信管理论坛(TMFQ对OSS/BSS提出?jin)被业界q泛接受的功能模型。在q个模型中,OSS/BSS包括三大功能Q业务开通、业务保障和计费Q或UC务计量)(j)。业务开通是指电(sh)信运营商接受客户订购?sh)信服务的订单,通过对电(sh)信资源的分配、配|、安装和部v为客h供所需的服务,q能够对服务q行计费?/font>
作ؓ(f)一U高效的信息理pȝQ?span lang="EN-US" style="FONT-FAMILY: serif">OSS/BSS已在国外?sh)信q营商中得到q泛的运用,q在实践中积累了(jin)大量的成功案例?span lang="EN-US" style="FONT-FAMILY: serif">OSS/BSS解决Ҏ(gu)也在q一q程中趋于完善,同时也暴露出来多的难以克服的问题Q?/font>
?span lang="EN-US">1、OSS/BSS的“集成的噩梦?/span>
l
OSS/BSS的Y件系l相对复杂,从而得网系l、计费系l、营账系l、客服系l等都是各成体系Q要x它们有机地整合在一P几乎是不可能的,对于q种“杂乱无章”的pȝl构Q参见图1Q,直可以称之ؓ(f)pȝ集成的噩梦(Integration NightmareQ?/font>
l 很多OSS/BSS开发商都有同感——缺训l有素的工程师,q也是由前一条所军_的,需要工E师同时_N电(sh)信的专业知识Q又能熟(zhn)各cYӞ的确要求比较苛刻?/span>
l 行业标准问题。尽在q几q来国际国内都陆l推Z(jin)一些标准规范,但大多是停留在纸面上Q同时也~少更直观的技术指导和成功案例?/font>
l 一?span lang="EN-US" style="FONT-FAMILY: serif">OSS/BSSQ往往?x)涉及(qing)若q个分离的系l,除了(jin)集成Q对pȝq行试、维护都是十分耗时的?/font>
以上各方面的问题Q?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J可以解冻I原因在于Q?/font>
l 采用W合OSS/J规范而开发的软g接口相对单,OSS/BSS内部的各个子pȝ是可以互换的Q?Interchangable Q?/font>
l
OSS/J是基?span lang="EN-US" style="FONT-FAMILY: serif">J2EE技术的Q开发h员只要熟(zhn)?span lang="EN-US" style="FONT-FAMILY: serif">J2EE的开发(甚至仅仅熟?zhn)?span lang="EN-US" style="FONT-FAMILY: serif">JAVA的开发)(j)p够了(jin)Q他们就能够与设计h员合作,完成pȝ开发?/font>
l
OSS/J不仅包括?jin)技术规范,而且有真实的代码实现以及(qing)试工具。这能够帮助开发h员很快的上手?/font>
l 因ؓ(f)各个子系l都W合标准的接口,所以系l的后期试和维护工作会(x)比较单?/font>
OSS/JQ?span lang="EN-US" style="FONT-FAMILY: serif">OSS Through JavaQ是?span lang="EN-US" style="FONT-FAMILY: serif">JAVA技术ؓ(f)动力的新一代的OSS/BSS解决Ҏ(gu)?/font>
说到OSS/JQ我们需要提?qing)一个称?span lang="EN-US" style="FONT-FAMILY: serif">OSS Through Java Initiative的工作组Q这个工作组׃多的业界新技术的倡导者(例如MotorolaQ?span lang="EN-US" style="FONT-FAMILY: serif">NokiaQ?span lang="EN-US" style="FONT-FAMILY: serif">Sun, BEA, IBMQ派出的专家l成。自2000q成立以来,他们一直在为加?span lang="EN-US" style="FONT-FAMILY: serif">OSS/BSS解决Ҏ(gu)的开发、简化其中的pȝlg的部|和集成而努力。工作组利用JAVA技术,?span lang="EN-US" style="FONT-FAMILY: serif">OSS/BSS定义实现?jin)一pd的开攄标准APIQ提供给OSS/BSS的开发者用。在不久的将来,?sh)信行业的设备制造商、Y件开发商、系l集成商都遵循这些标?span lang="EN-US" style="FONT-FAMILY: serif">API的定义,那么最后徏立v来的OSS/BSS是一个组件化的、有机结合在一L(fng)l合理q_Q参见图2Q,“杂乱无章”的pȝl构成厅R?/span>
?span lang="EN-US">2、采用OSS/J构徏的系l结?/span>
需要指出的是,OSS/Jq不是要定义另一个通用?span lang="EN-US" style="FONT-FAMILY: serif">OSS/BSS集成框架。工作组的成员在定义标准?span lang="EN-US" style="FONT-FAMILY: serif">API之前Q已l݅取了(jin)众多标准规范和协议中的精华,例如Q?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J很好的承了(jin)来自3rd Generation Partnership Project (3GPP), 3GPP2, Mobile Wireless Internet Forum(MWIF)以及(qing)TeleManagement Forum(TMF){组l或论坛推出的规范和框架体系。因此,工作l将所有的l历投入C(jin)JAVA API的定义和~码实现上,而且使用OSS/J规范的的用户可以免费地获得这些资料?/font>
TMF在NGOSS 3.0QNext Generation Operations Support Systems下一代运营支持系l)(j)的文档中Q推Z(jin)详细的OSS/BSS的定义。(参见http://
www.tmforum.org
Q。OSS/J的API定义遵守?jin)NGOSS eTOM Qenhanced Telecom Operations MapQ的规定Q详l内容请见“OSS/J API介”部分。概括地_(d)NGOSS为我们提供了(jin)独立于技术实现的普遍适用的框Ӟ而OSS/J则是以该框架为基Q提Z(jin)采用JAVA技术的实现Ҏ(gu)?/font>
OSS/J的规范的推出是在JCPQ?span lang="EN-US" style="FONT-FAMILY: serif"> Java Community Process, http://jcp.orgQ支持下完成的。通过讉KJCP的网站,或者光?span lang="EN-US" style="FONT-FAMILY: serif">http://java.sun.com/products/ossQ你都可以下载到OSS/J的规范、参考实现和兼容性测试工P下面逐一介:(x)
OSS/J的规范:(x)包括OSS/J API规范?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J J2EEpȝ设计指导。这些内容将在?span lang="EN-US">OSS/J API介”中详细叙述?/span>
OSS/J 参考实玎ͼ Reference Implementation?RIQ:(x)主要内容是根?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J API规范而完成的pȝ实现的代码。推?span lang="EN-US" style="FONT-FAMILY: serif">RI一斚w是ؓ(f)?jin)验证规范的可执行性,所?span lang="EN-US" style="FONT-FAMILY: serif">RI的代码未曄q很好的优化?span lang="EN-US" style="FONT-FAMILY: serif">RI的另一个重要的作用是它能够使得开发者很快的着手进行设计和开发工作,而且Q?span lang="EN-US" style="FONT-FAMILY: serif">RI中的所有代码可以被开发h员直接用到商业pȝ的开发中厅R所以,仔细阅读分析RI的代码能大大~短你用于熟(zhn)?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J的时间?/font>
兼容性测试工P Test Compatibility Kits?TCK Q:(x)当一?span lang="EN-US" style="FONT-FAMILY: serif">OSS/BSSQ或其中的一个子pȝQ的开发完成了(jin)以后Q我们如何才能知道它是否W合OSS/J 规范的规定呢Q?span lang="EN-US" style="FONT-FAMILY: serif">TCK可以完成q样的测试,q生一个测试报告。如果开发的产品W合OSS/J规范的要求,那么它将很容易和其它同样兼容OSS/J规范的品集成在一赗?/font>
OSS/J的规范推Z后,得到?jin)业界的q泛认可Q许多电(sh)信运营商、服务提供商、系l集成商争相q随。来自IDC?002q的报告_(d)“……随着SA、TT、Qos API的发布,许多服务提供商和供应商认?采用JAVA技术实现OSS已经C(jin)实际可行的阶Dc(din)?/font>
上文提到Q?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J可以帮助我们l结“系l集成的噩梦”,因ؓ(f)它ؓ(f)我们定义?jin)一pd的标?/span>APIQ只要各个厂商都能遵?span lang="EN-US" style="FONT-FAMILY: serif">API中的规定Q那?span lang="EN-US" style="FONT-FAMILY: serif">OSS/BSS的集成难的问题将q刃而解。那么具体的底层实现机制是怎样的呢Q?span lang="EN-US">—?/span>OSS/J采用?span lang="EN-US" style="FONT-FAMILY: serif">J2EE作ؓ(f)技术^台?/font>
J2EEQ?span lang="EN-US" style="FONT-FAMILY: serif">Java 2 Enterprise EditionQ即Java 2企业版,是提供给开发者的采用lg技术构建分布式pȝ的编E框Ӟ需要更深入?jin)?span lang="EN-US" style="FONT-FAMILY: serif">J2EEQ请览http://java.sun.com/j2ee/。M来说Q?span lang="EN-US" style="FONT-FAMILY: serif">J2EE使得开发h员无d考虑分布式系l中的底层技术实现细节,例如U程理Q网l通信{,而是集中_֊开发符合业务逻辑的代码,q无疑大大加快了(jin)应用E序的开发进E,而且化了(jin)pȝ的部|和后期l护工作。目前全球的J2EE开发h员L已经辑ֈ?jin)几百万Q这个群体还在迅速膨胀?/font>
?span lang="EN-US">3、采用J2EE实现OSS/BSS
作ؓ(f)服务器端的开发技术,企业JavaBeanQ?span lang="EN-US" style="FONT-FAMILY: serif">EJBQ、扩展标记语aQ?span lang="EN-US" style="FONT-FAMILY: serif">XMLQ以?span lang="EN-US" style="FONT-FAMILY: serif">JAVA Management ExtensionsQ?span lang="EN-US" style="FONT-FAMILY: serif">JMXQ都?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J中被采纳。因?span lang="EN-US" style="FONT-FAMILY: serif">J2EE?span lang="EN-US" style="FONT-FAMILY: serif">XML?span lang="EN-US" style="FONT-FAMILY: serif">JMX已经在很多的大型企业应用Q特别是服务器端的应用程序)(j)中获得了(jin)成功Q所?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J采用它们定义在组装、开发和部vOSS/BSS解决Ҏ(gu)时所需要的API?/font>
?span lang="EN-US">3是采用J2EE实现OSS/BSS的示意。以OSS/J API为基Q我们开发了(jin)支持SA、TT{功能的EJBQ这些EJB可以Ҏ(gu)需要通过JDBC存取数据库,或通过JNDI讉K目录服务器。对于已有的遗留pȝ以及(qing)EMSQElement Management SystemsQ,可以采用J2EEq接器的架构QJava Connector Architecture即JCAQ通过SNMP、CMIP或其他专有协议实现集成。OSS的客L(fng)可以是浏览器或定制的应用E序Q通过HTTP/XML/Java/IIOP和系l相联。与此同ӞJAVA的消息机制ؓ(f)我们提供?jin)更加灵zȝ“松耦合Qloosely-coupledQ”的集成方式Q利用它可以单地实现和Intranet/Internet中的其他pȝ的连接?/span>
?span lang="EN-US">4?/span>OSS/J中的核心(j)API?span lang="EN-US" style="FONT-FAMILY: serif">TMF?span lang="EN-US" style="FONT-FAMILY: serif">eTOM的各个过E做?jin)映。从图中可以看出Q?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J核心(j)API囊括?jin)客L(fng)理、订单管理、服务开通等20个,关于每个API的详l描qͼ可参?span lang="EN-US" style="FONT-FAMILY: serif">http://java.sun.com/products/oss/apis.html上的OSS/J API Roadmap。目前,已经完成?span lang="EN-US" style="FONT-FAMILY: serif">API有:(x)OSS服务开?span lang="EN-US" style="FONT-FAMILY: serif">APIQ?span lang="EN-US" style="FONT-FAMILY: serif">OSS故障?span lang="EN-US" style="FONT-FAMILY: serif">APIQ?span lang="EN-US" style="FONT-FAMILY: serif">OSS通用APIQ?span lang="EN-US" style="FONT-FAMILY: serif">OSS IP计费API?span lang="EN-US" style="FONT-FAMILY: serif">OSS服务质量控制APIQ?span lang="EN-US" style="FONT-FAMILY: serif">OSS 库存 API不久发行。除?span lang="EN-US" style="FONT-FAMILY: serif">APIQ?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J工作l还为开发者提供了(jin)?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J J2EE pȝ设计指导》?/font>
?span lang="EN-US">4、OSS/J API到eTOM的映?/span>
OSS通用 APIQ?OSS Common APIQ:(x)和其?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J API不同的是Q它本n没有?span lang="EN-US" style="FONT-FAMILY: serif">OSS/BSS在业务逻辑提供支持Q而是为开发者?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J API提供?jin)一个基框架。可以认部分API是?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J J2EE pȝ设计指导》一个具体实施。需要强调的是,既然是基框架Q以下提?qing)的所?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J API都是依赖于通用API的?/font>
OSS/J J2EEpȝ设计指导Q?OSS/J J2EE Design Guideline?OSS/J J2EE DGQ:(x)定义?jin)一pd的设计模式(Design PatternsQ,q些模式非常适合于采?span lang="EN-US" style="FONT-FAMILY: serif">J2EE/EJB搭徏|络服务理pȝ。M来看Q?span lang="EN-US" style="FONT-FAMILY: serif">DG中提?qing)的设计模式都是来自?span lang="EN-US" style="FONT-FAMILY: serif">J2EE设计模式Q关?span lang="EN-US" style="FONT-FAMILY: serif">J2EE设计模式的详l信息,请参?span lang="EN-US" style="FONT-FAMILY: serif">http://java.sun.com/blueprints/corej2eepatterns?span lang="EN-US" style="FONT-FAMILY: serif">DG中主要涉?qing)到以下要点Q?/font>
l
OSS中的功能都是采用EJBlg的Ş式实现的
l q些EJB提供?jin)面向业务逻辑的粗略的接口
l 应用服务器ؓ(f)OSS/BSSpȝ提供?jin)集、扩展和故障处理{功?/font>
l 采用消息Q?span lang="EN-US" style="FONT-FAMILY: serif">MessagingQ交换机制来减小lg之间的耦合E度
l l合消息机制?span lang="EN-US" style="FONT-FAMILY: serif">JCA架构实现pȝ的集成和工作的理
贯穿DG的一个重要概念就?span lang="EN-US">“Y件构ӞSoftware Building BlockQ”的概念。一块Y件积木是若干软glgQComponentQ的集合体,q些软glg怺协作Q从而满系l业务逻辑的需求。需要强调的是,OSS/J API的所有定义和实现方式都是遵从OSS/J J2EE DG的?/font>
OSS服务开?APIQ?OSS Service Activation API?SA APIQ:(x)主要提供?jin)对订单的管理功能(例如生成、修攏V删除、查询订单等Q和服务的管理功能?span lang="EN-US" style="FONT-FAMILY: serif">API中ƈ没有l出指定?span lang="EN-US">“服务信息模型(Service Information ModelQ?span lang="EN-US">”,而是这部分工作留给开发者去实现Q这样开发者可以根据自q业务逻辑的需要定义服务信息模型?/span>SA API中关于订单管理的定义是根?span lang="EN-US" style="FONT-FAMILY: serif">TMF 603中的“世界订单信息协定”(World Ordering Information AgreementQ以?span lang="EN-US" style="FONT-FAMILY: serif">OMG WMF/WfMC?span lang="EN-US">“订单状态模型(Order State ModelQ?span lang="EN-US">”的定义完成的?/span>
OSS故障?APIQ?OSS Trouble Ticket API?TT APIQ:(x)定义?jin)生成、更新、查询、关闭故障单的一pd操作。网系l可以通过调用TT API自动生成故障单,服务提供商也可以利用它生和处理故障单,客户xpȝ能够调用q些API故障单发送给服务提供商(见图5Q;如果故障单的理是在一个工作流E中完成的话Q那么开发h员可以用这?/span>API与工作流引擎q行信息传递?/font>
OSS IP计费 APIQ?OSS IP Billing APIQ:(x)定义?span lang="EN-US" style="FONT-FAMILY: serif">IP计费的数据源和计费系l之间的接口。这部分API适用于针?span lang="EN-US" style="FONT-FAMILY: serif">2.5G?span lang="EN-US" style="FONT-FAMILY: serif">3G|络?span lang="EN-US" style="FONT-FAMILY: serif">OSS/BSS开发。而且API的定义重Ҏ(gu)在(但不不局限于Q无UK信的领域。该规范的定义是Z(jin)实现计费pȝ、计Ҏ(gu)据采集系l、计Ҏ(gu)据源q些不同的子pȝ之间够实现无~连接,畅地完成各U记录类型(例如CDR?span lang="EN-US" style="FONT-FAMILY: serif">SDR?span lang="EN-US" style="FONT-FAMILY: serif">IPDR{)(j)的交换和传输?/font>
OSS服务质量 APIQ?OSS Quality of Service API?OSS QOS APIQ:(x) QOS API使得QOSpȝ能够从其他系l得到媄(jing)响服务质量的数据Q例如网l性能、极限g?qing)故障数据等{?span lang="EN-US" style="FONT-FAMILY: serif">QOS API主要涉及(qing)到性能和用情늚数据监测、系l极限值的监测?qing)故障数据的监测三个斚w的内宏V?/font>
OSS 库存 API Q?OSS Inventory API Q:(x) OSS/BSS在进行操作的时候,大多需要关于网l可以提供的产品、服务和资源的规划、用的情况Q这些功能要由库?span lang="EN-US" style="FONT-FAMILY: serif">API来提供。这部分API包括?jin)对产品和服务的目录理Qƈ且有跟踪用户预定和用品或服务的功能;同时API中对|络资源理Q例如网l上的设备和|络拓扑l构的管理)(j)的功能对?span lang="EN-US" style="FONT-FAMILY: serif">OSS/BSS来说也是不可或缺的?/font>
下图展示?jin)各?span lang="EN-US">OSS/J API之间的关p,其中椭圆形的边界可以看做是API的定义,矩Ş的内Ҏ(gu)由开发商来实现的Q而箭头代表方法或功能的调用,q些功能调用Q尤其是各个子系l之_(d)例如从Qos调用故障单中的功能)(j)应该使用OSS/J的API来完成?/span>
?span lang="EN-US">5、OSS/J API的关p?/span>
?jin)解?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J API的概况以后,可能你已l决定着手进行基?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J的系l开发了(jin)。无Z是系l设计h员还是程序员Q应该具?span lang="EN-US" style="FONT-FAMILY: serif">J2EE的开发经验,而且最好了(jin)解电(sh)信行业知识(特别是关?span lang="EN-US" style="FONT-FAMILY: serif">OSS/BSS斚w的知识)(j)。而且Q徏议你按照以下的步骤来开展工作?/font>
研读 OSS/J相关的资?
览OSS/J的网?span lang="EN-US" style="FONT-FAMILY: serif">http://java.sun.com/products/ossQ你可以下蝲?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J的规范和相关技术文章(如图6所C)(j)。前面提刎ͼ试着部v一?/span>RIq研I其代码能帮助你q速了(jin)?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J。如果你在学?fn)和使用的时候有什么疑问和意见Q都可以发表在相应的新闻l里Q新ȝ的地址参见OSS/J的网站)(j)?/font>
?span lang="EN-US">6、下载OSS/J规范、RIq行开?/span>
开?OSS/BSS 的设计与实现
q个q程和标准的软g开发没有大的区别,主要l历从制定计划、需求分析、系l设计、详l设计、编码实现和试{几个环节。由于进?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J的开发是ZJ2EE技术的Q所以选择E_高效的应用服务器Q?span lang="EN-US" style="FONT-FAMILY: serif">Application ServerQ和集成开发环境(IDEQ十分重要,好在׃J2EE的开放性,我们有很多选择Q例?span lang="EN-US" style="FONT-FAMILY: serif">Sun ONE应用服务器?span lang="EN-US" style="FONT-FAMILY: serif">BEA Weblogic?span lang="EN-US" style="FONT-FAMILY: serif">Borland Jbuilder{。在pȝ设计和详l设计时Q设计h员需要首先熟(zhn)?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J J2EE设计指导中内容,按照其中讲述的设计模式进行设计。至于编码实玎ͼ和一般的J2EE开发没什么区别,主要涉及(qing)?span lang="EN-US" style="FONT-FAMILY: serif">EJB的编E,同时需要程序员?span lang="EN-US" style="FONT-FAMILY: serif">XML比较熟?zhn)。进入到试阶段Q除?jin)完成普通Y件开发需要完成的一pd试以外Q?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J规范的兼Ҏ(gu)的试也是必须的,如上文所qͼTCK可以帮你完成q一个步骤(参见?span lang="EN-US">7Q?/span>
?span lang="EN-US">7、用TCKq行试
发布自己的品信?/font>
当你开发的产品成功地通过?span lang="EN-US" style="FONT-FAMILY: serif">TCK的测试以后,可以获?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J的认证?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J针对OSS/BSS产品规定?jin)一个灵zȝ“自我认证流E”,参见?。上文中提到Q?/span>TCK试你的产品Q将产生一个测试报告。如果测试成功,可以报告发布到你的公共|站上,同时通知OSS/J工作l的E序理组。经q核实以后,OSS/JE序理组会(x)更新OSS/J的网站,你发布的品测试报告的链接Q?span lang="EN-US" style="FONT-FAMILY: serif">URLQ加到通过认证的品列表中厅R到现在Q整?span lang="EN-US">“自我认证过E”就完成?jin)。获得了(jin)OSS/J的认证,意味着你开发的产品可以很容易地和其它厂商的也获得认证的产品集成hQ可以作为有机的一部分加入到基于OSS/J API的OSS/BSS中去。参?/span>http://java.sun.com/products/oss/adoption/ossj_certified_products_table.htmlQ在q里Q你可以看到IBM?span lang="EN-US">Ilog?/span>Nokia{许多厂商的产品都已l获得了(jin)OSS/J的认证?/span>
?span lang="EN-US">8、OSS/J的“自我认证?/span>
加入 OSS/J工作l?
如果你希望能最?qing)时C(jin)?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J的发展动向,获得最新的信息Q甚臛_望参与规范的制订和修改,那么最有效的方式就是加入到OSS/J的工作组中来?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J工作l中的成员有着不同的别,分别有不同的权利。请查看http://java.sun.com/products/oss/members.html?jin)解加?span lang="EN-US" style="FONT-FAMILY: serif">OSS/J工作l的l节内容?/font>
OSS/J为我们提供了(jin)一个采用Java技术实现OSS/BSS的技术框Ӟ它借鉴?jin)众多的既定行业规范Q以J2EE/XML技术ؓ(f)基础Qؓ(f)OSS/BSS的开发者提供了(jin)一个标准的环境Q以解决目前OSS/BSS中存在的集成问题。相信随着相关技术的q步QOSS/J?x)拥有越来越多的支持者,从而发展成为用JAVA实施OSS/BSS的技术标准?/font>
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
随着信息时代的到来,我国各行各业都面临着诸多机遇与挑战,党和政府适时地提?以信息化带动工业化,发挥后发优势Q实现社?x)生产力的跨式发?的伟大战略决{。在q几q的信息化徏设中Q一些企业在企业信息化徏设方面的投入较大Q但收效甚微。原因之一在于Q缺乏统一的信息化框架、标准和规范。在我国?sh)子商务、电(sh)子政务全面发展之际,此框架、标准和规范?yu)显得尤为重要,只有按照l一的框架、标准和规范Q才可能避免重复、实C息共享?/p>
目前Z都把?sh)信企业当作是信息化的排头兵Q这隐含有四层意思:(x) Q?Q电(sh)信企业是国家信息基础设施的主要徏设者和q营者,担负着基础的重要命; Q?Q电(sh)信业自n的信息化能够强化企业自n的管理规范,提高q营效率和综合竞争能力; Q?Q电(sh)信企业可以利用自w的信息化典范,为其他的企业提供信息化的解决Ҏ(gu)Q作ZU新的业务ؓ(f)客户提供更好的服务; (4)?sh)信企业自n的信息化更具有推q社?x)信息化、政府信息化、企业信息化的示范作用?/p>
信息化徏N要规范的业务程和管理流E做基础Q电(sh)信运营业务流E最新的国际规范eTOM3.0版对?sh)信相关企业的信息化和企业运营至关重要?/p>
一、eTOM?e"的含?/p>
"eTOM"中的"e"常规?增强"之意Q但它却包含?jin)与业务程框架有关的很多含义,如?x)企业程(Enterprise processes)、电(sh)子商务激z?eBusiness enabled)、扩展的(Expanded)、每?Everything)、每?Everywhere)、每?Every time){?/p>
二、eTOM业务程框架的目?/p>
eTOM业务程框架作ؓ(f)?sh)信q营业务程的向D囑֒业务?qing)运营支撑系l?分别为BSS和OSS)发展和集成的始发点,有助于推动和发展NGOSS(Next Generation Operations Systems and SoftwareQ下一代运营系l和软g)解决Ҏ(gu)。对于服务提供商来说Q当他们考虑内部程重组需求、合作关pR联盟以?qing)与其它服务提供商ȝ工作协议ӞeTOM提供?jin)一个中性的参考点。对供应商来_(d)eTOM框架l出?jin)Y件各lg的潜在边界以?qing)支撑品所需的功能、输入和输出?/p>
eTOM3.0版包含以下内容:(x) Q?QeTOM业务程框架的角色描qͼ Q?Q服务提供商的电(sh)子商务环境和所需的更为复杂的业务关系环境兌模型Q?/p>
Q?Q服务提供商的企业流E和子流E在高层面的业务流E框架和解释的侧重点是自上而下、以֮Z?j)、端到端QTOM正逐步向eTOM演变Q目前的eTOM业务程框架对于服务提供商来说是整个企业的框Ӟ Q?Q所有流E的分解Q从eTOM框架的最高层面的概念视图到工作层面,有选择地给出框架中很多较低层面的流E分解; Q?Q流E流向和分解程的选择描述Q包括流E目的或描述、业务规则、高U层面的信息{; Q?Q如何运用流E框架?/p>
eTOM的目的是通过对业务流E的实施来管理企业,帮助企业明确目标Q确保有x务交付和支持所有关键的企业支撑pȝq行集成。eTOMx的焦Ҏ(gu)Q服务提供商使用的业务流E、流E间的联pR接口的识别Q即如何利用客户、服务、资源、供应商/合作伙伴以及(qing)其它多重程使用的信息?/p>
eTOM业务程框架和相关的业务程模型描述?jin)流E及(qing)l成端对端的q接点,描述?jin)运营、战略、基设施与品流E区域中开通、保障、计费等客户q营程向。eTOM业务程框架对信息和通信服务、技术管理有Ҏ(gu)意义Q这U模型同样适用其它cd的业务?/p>
服务提供商应用这U通用的流E框Ӟ以确保与其它实体交易的高效和有效Q确保第三方软g的开发和应用不需太多的客户化定制。在?sh)子商务环境下,?gu)E的共同理解Q此框架在管理信息和通信业务?jng)场中十分关键。企业电(sh)子商务集成化已成为强大的程集成最成功的范例。eTOM不仅是电(sh)子N易或?sh)子商务程框架Q它q支持传l业务流E与?sh)子商务的集成?/p>
三、eTOM是什?/p>
eTOMQ是enhanced Telecom Operations Map的英文首字母~写Q英文全UCؓ(f)enhanced Telecom Operations MapTM (eTOM)。The Business Process Framework For The Information and Communication Services IndustryQ中文意思ؓ(f)增强的电(sh)信运营图(eTOM)信息和通信服务行业的业务流E框架。eTOM现在已经发展?.0版,q已?002q?月通过?sh)信理论坛QTM论坛Q的批准Q正式公开发布。eTOM大大增强?jin)TOM的功能,是服务提供商q营程实际依照的行业标准?/p>
eTOM是一U业务流E模型或框架Q它为服务提供商提供所要求的企业流E。但是,它不是服务提供商的业务模型。它不陈qC下策略:(x)服务提供商的目标客户、服务提供商所服务的市(jng)场、服务提供商前景、Q务等Q业务流E框架是业务模型{略的一部分Q是为服务提供商提出计划?/p>
eTOM是基于TOMQTelecom Operation MapQ发展而来的,eTOM把TOM扩展到整个企业架构,qq对?sh)子商务的?jing)响。虽然eTOM比TOM复杂得多Q在某种意义上,eTOM更ؓ(f)直接明了(jin)Q它消除?jin)TOM中企业管理(公司型)(j)程、市(jng)销程、保留客hE、供应商和合作伙伴管理流E之间的隔膜{?/p>
很多服务提供商(包括?jin)系l集成商、ASP和Y件供应商Q指出,在eTOM未被认前,他们已经在运用eTOMQ因为eTOM较好C表了(jin)他们的真实需要,他们在采购Y件、设备以?qing)面对业务关pȝl与其它服务提供商的接口Q都需要行业的标准框架。虽?dng)很多服务提供商已接受TOMQƈ把它作ؓ(f)程框架核心(j)或是作ؓ(f)保持相容性的标准Q但大多数服务提供商承认需要进一步扩展TOMQ以便反映电(sh)子商务集成化和全企业的框架。图1为eTOM业务程框架0U流E图?/p>
?Q?eTOM业务程框架—?U流E图 ?昄的是eTOM业务程框架最高层面的概念视图。该视图把战略和生命周期程从运营流E中分离出来QŞ成两大流E群l,同时把关键功能区域分成四个横向层面。此外,?也显CZ(jin)企业内、外部的怺影响、相互作用的五大实体(客户、供应商/合作伙伴、股东、雇员、其他利益相兌?。图2为eTOM业务程框架一U流E图?/p>
?QeTOM业务程框架—?一U流E?/p>
?l出?jin)eTOM框架中从0U视囄到的一U流E。该视图UCؓ(f)企业程框架CEO(卻I(x)首席执行?层面的视图。然而,Z們于用二U流E的一U视图,因ؓ(f)在分析业务时需要这些细节。图2l出?个纵向流E群l。这些端对端的流E用以支持客户和理业务。eTOMx的焦Ҏ(gu)以客戯营流E的开通、保障和计费(FAB)为核?j)。运营支持与qA程从FAB实施程中分出来单列Q以增强对FAB中实现支持和自动化的xQ即Q对在线和对客户实现x支持。战略与承诺?qing)两个生命周期管理纵向流E群l也分离出来Q因Zq营程组不同Q它们没有直接支持客P与运营流E群l有着本质差别Qƈ且工作在不同的业务周期。图2中的横向程组区分?jin)功能运营流E和其它cd的业务功能流E,如:(x)?jng)场营销寚w售、服务开发对服务配置{。左边的功能程Q在战略与承诺、基设施生命周期理、品生命周期管理纵向流E群l)(j)保证支持和指D营流E区域的U向程工作?/p>
四、TOM与eTOM的比?/p>
服务理业务程模型被称之ؓ(f)TOMQ是Ҏ(gu)服务提供商的q营理要求Q围l流E、输入、输出和zd开发。它x的焦点和范围是运营和q营理Q它竭力为电(sh)信业服务Q支持对服务提供商流E的理解Q在业务、运营系l和软g斚w为服务提供商的问题提供解x案。TOM仍然处于eTOM业务程框架的核?j)?/p>
TOM2.1版本是TM论坛成员现在认可的业务流E框架或模型。世界各地的服务提供商广泛接受它作ؓ(f)q营业务程框架Q而很多供应商把它作ؓ(f)产品开发和销售的基础。基于以下两点,把TOM的修改称为eTOM。第一Q成员们很久以来想把TOM扩展为全企业业务程框架Q第二,利用?sh)子商务和互联网取得成功很关键。TOMq没有充分地分析?sh)子商务对商业环境、业务驱动力、电(sh)子商务流E集成化要求的媄(jing)响,也没有分析日渐复杂化的服务提供商的业务关pR图3为电(sh)信运营图业务程模型?/p>
?为电(sh)信运营图QTOMQ业务流E模?/p>
如图2和图3所C,与TOM相比QeTOM做了(jin)以下改善Q?/p>
Q?Q把范围扩展到所有的企业程Q?/p>
Q?Q鉴于市(jng)销在电(sh)子商务环境中所处的重要CQ明标识市(jng)销程Q?/p>
Q?Q明标识企业管理流E,以便企业中的每个人都能够定其关键流E,从而整个企业都接受流E框Ӟ Q?Q把开通、保障和计费QF(tun)ABQ引入高U层面的框架视图中,从而强调客户优先流E是企业x的焦点; Q?Q定义运营支持与qAU向程组Q此定义可适用于除企业理以外的所有功能层面。ؓ(f)使电(sh)子商务集成和客户自助理成ؓ(f)现实Q企业必M(jin)解自己需要的程Q以保证客户q营支持和客戯助管理; Q?Q明SIP(StrategyQ?Infrastructure and Product)程Q战略与承诺Q基设施生命周期理和品生命周期管理,识别q三U企业流E群l,它们明显区别于客戯营流E; Q?Q识别战略和生命周期理程的不同周期时_(d)需要把q些程从最需要自动化的客户优先运营流E中分离出来Q可以通过把战略与承诺和两个生命周期管理流E从日常的客戯营流E中分离来实现?/p>
Q?Q从x客户或是面向服务转ؓ(f)面向客户关系理Q强调客戯助管理和控制Q增加客户对企业产生的h(hun)|利用信息来ؓ(f)单个客户个性化和客户化Q这可以为客戯营功能层面增加更多的元素Q更好地代表销售流E,完成?jng)场营销在客户关pȝ理范围内的集成; Q注意:(x)eTOM对客户关pȝ理进行了(jin)更广泛的定义Q比CRM某些定义的范围要大。)(j) Q?Q明了(jin)跨技术管理资源的要求Q即Q应用、计和|络Q,?|络和系l管?功能程?资源理与运?集成。它把IT理引入到该功能层面Q与外向程组形成对照?/p>
TOM是服务提供商q营理事实上的行业标准QeTOM与TOM相比保留?jin)TOM中以下优点:(x) Q?Q关注于业务程Q?/p>
Q?Q以客户Z?j)的驱动手段Q?/p>
Q?Q自上而下的定位; Q?Q通用直白的描q和手段Q?/p>
Q?Q本w吸引,服务提供商能立即?jin)解q营的工作方式; Q?Q一直关注运营管理; Q?Q在服务提供商、供应商和媒体之间广泛用; Q?Q灵zd支持大多数SP的流E模型?/p>
q些优点?j)TOM成ؓ(f)q营pȝh推动作用的架构,成ؓ(f)服务提供商的软g解决Ҏ(gu)Q它仍然作ؓ(f)业务程框架Qƈ涉及(qing)更多的流E和学科。在?sh)子商务环境下,实体间的联系是流E中最重要的环节。eTOM?x)加Z客户Z?j)的驱动途径Q因为目前和来的环境能够掌握客戗电(sh)子商务?jng)场从面向供货{为面向需求,或者说?推向客户"变ؓ(f)"客户拉动"。eTOM中保留自上而下的定位,不仅因ؓ(f)它是TOM的核?j)概念,而且它是良好的业务流E徏模?/p>
五、eTOM的用对?/p>
eTOM提供?jin)通用的服务提供商企业程视图Q较Ҏ(gu)转换成单个提供商的内部手Dc(din)?/p>
eTOM的优点之一是能为服务提供商Ҏ(gu)需要在不同层面qؓ(f)采用。eTOM也可作ؓ(f)译Q允许服务提供商参照行业框架l制其明流E。当程h开发出来,服务提供商就能利用和调整h以适应自己的业务环境?/p>
eTOM针对的是信息和通信行业q大的专业h员,对于有经验的通信专业人员来说QTOM和eTOM是直观的、强大而通用的服务提供商企业程?/p>
eTOM针对服务提供商和|络q营商的决策者,需要了(jin)解和输入通用的业务流E框Ӟ以较好的性h(hun)比实C业自动化。对于从事业务和q营自动化的专家Q它也是很重要的架构?/p>
eTOMlؓ(f)服务提供商和供应商提供一个通用的框架进行讨论,在复杂的行业中讨论复杂的技术和复杂的业务需求。这些复杂性来自:(x)从开发自q业务和运营系lYӞ转向更多的采购和pȝ集成的方式;服务提供商和|络q营商之间新型的业务关系?/p>
建立新型的业务关pd不进行内部开发是对市(jng)场驱动力的回应。市(jng)场驱动力要求服务提供商和|络q营商增加业务的范围、羃短新业务投向?jng)场的时间、提高服务速度以及(qing)降低pȝ和运营成本?/p>
eTOM业务程框架针对服务提供商和|络q营商涉?qing)业务流E重l、运营、采购和其他zd的h员,使他们能?jin)解q推动集成化和自动化q程的通用业务程框架Q参与提供流E、输入、优先和要求的zd?/p>
eTOM业务程框架也针对业务和q营理pȝ软g的设计者、集成者以?qing)设备供应商Q通过?jin)解理程和应用需求,为服务提供商和网l运营商带来利润?/p>
eTOM业务程框架提供一个通用架构Q支持大量的集成、合q活动,?jin)解好通用程和通用程框架ؓ(f)合ƈ大大改善集成性能。eTOM适用于所有的?sh)信服务提供商。不是所有供应商都要用到eTOM定义的所有流E。eTOM框架灉|Q服务提供商可以根据模块基和恰当的具体层面需求来选择所需的流E?/p>
下蝲地址Q?a >http://www.fruitres.cn/servlet/buyproductservlet?tag=single&tag1=info&PRODUCT_ID=994930817&number=0
更多下蝲Q?a >http://www.fruitres.cn
]]>
AGPS——Assisted GPSQ用中文来说应该是网l辅助GPS定位pȝ。通俗的说AGPS是在以往通过卫星接受定位信号的同时结合移动运营的GSM或者CDMA|络机站的定位信息,是一斚w由具有AGPS的手取来自卫星的定位信息Q而同时也要靠该手机透过中国Ud的GPRS|络下蝲辅助的定位信息,两者相l合来完成定位。与传统GPS(Global Positioning System全球定位pȝ)首次定位??分钟相比AGPS的首ơ定位时间最快仅需几秒钟,同时AGPS也彻底解决了(jin)普通GPS讑֤在室内无法获取定位信息的~陷?img src ="http://www.tkk7.com/sunfruit/aggbug/55944.html" width = "1" height = "1" />
]]>
使用
JAVA
技术实现新一?/span>
OSS/BSS
OSS/BSS
概述
什么是
OSS/J
OSS/J
?/span>
J2EE
OSS/J API
?/span>
OSS/J
开发指?/span>
ȝ
参考资?/font>
]]>
q年来,我国?sh)信业发展迅猛,电(sh)话普?qing)率已?3.7Q,?sh)话用户L跃居世界W一。与世界发达国家的电(sh)信业相比Q我国电(sh)信运营商在技术设备和|络基础设施{?g"斚w的差距ƈ不大Q但是在业务程、企业管理和力_生率等"软g"斚w仍存在较大差距。eTOMؓ(f)我国?sh)信业与国际接轨、羃?yu)?软g"差距带来机遇?/p>
eTOM的发?/p>
eTOMQ英文全UCؓ(f)enhanced Telecom Operations Map。(eTOMQ———The Business Process Framework For The Informationand Communication Services Industry?/p>
中文意思ؓ(f)增强的电(sh)信运营图QeTOMQ———信息和通信服务行业的业务流E框?eTOM源自TOMQTelecomOperationsMapQ。TOM侧重的是?sh)信q营行业的服务管理业务流E模型,x的焦点和范围是运营和q营理。世界各地的服务提供商广泛接受它作ؓ(f)q营业务程框架Q而且很多供应商已把TOM作ؓ(f)产品开发和销售的基础。随着企业在业务中使用因特|、集成电(sh)子商务机遇的需要,仅关注运营管理的TOM已显出极大的局限性。TOM没有充分地分析电(sh)子商务对商业环境、业务驱动力、电(sh)子商务流E集成化要求的媄(jing)响,也没有分析日渐复杂化的服务提供商的业务关pR因此,TM论坛的成员们很久以来想把TOM扩展为全企业业务程框架。eTOM中的e常规?增强"之意Q但它却包含?jin)与业务程框架有关的很多观念,如?x)企业程QEnterpriseprocessesQ、电(sh)子商务激z(eBusinessenabledQ、扩展的QExpandedQ、每事(EverythingQ、每处(EverywhereQ、每ӞEverytimeQ等。TOM仍然处于eTOM业务程框架的核?j)?/p>
eTOM作ؓ(f)?sh)信q营业务程向导的蓝图,是NGOSSQNextGenerationOperationsSystemsandSoftwareQ即下一代运营系l和软gQ的重要概念和关键组成元素。NGOSS中的"OSS"虽与通常?OSS"QOperationSupportSystemQ在字面上相同,但是内涵已经发生?jin)很大变化。NGOSS包含有文档、模型和代码{知识库的创建,侧重于业务流E和信息模型的定义、系l框架的定义、合作催化试炚w目的实施{关键元素?/p>
eTOM是什?/p>
eTOM是一U业务流E模型或框架Q它为服务提供商提供所要求的企业流E,但它不是业务模型?/p>
它不陈述以下{略问题Q谁是服务提供商的目标客P服务提供商所服务的市(jng)场是怎样的,以及(qing)服务提供商的愿景如何、Q务是什么等{?/p>
eTOM较好C表了(jin)?sh)信q营业的真实世界Q很多服务提供商Q包括了(jin)pȝ集成商、ASP和Y件供应商Q已l在q用eTOMQ因Z们在采购软g、设备,以及(qing)面对愈加复杂的业务关pȝl中与其它服务提供商的接口,都需要行业的标准框架?/p>
对于服务提供商来_(d)当他们考虑内部程重组需求、合作关pR联盟以?qing)与其它提供商的ȝ工作协议ӞeTOM提供?jin)一个中立性的参考点。对供应商来_(d)eTOM框架l出?jin)Y件各lg的潜在边界,以及(qing)支撑产品所需的功能、输入和输出?/p>
为方便v见,W者对TM论坛公布的eTOM?U和1U流E视图进行了(jin)l合。eTOM阐述?jin)?sh)信运营商?qing)其所处的l营环境Q给Z(jin)企业内、外部的怺影响、相互作用的五大实体Q客戗供应商/合作伙伴、股东、雇员、其他利益相兌?/p>
eTOMl出?jin)三大流E群l:(x)
1Q战略、基设施和品;
2Q运营;
3Q企业管理?/p>
q三大流E群l进一步分解ؓ(f)23个一U流E群l和87个二U流E以?qing)若q三、四U流E;其中7个一U的U向程组Q是端对端的程Q用以支持客户和理业务Q?6个横向流E群l区分了(jin)功能q营程和其它类型的业务功能程。eTOM的关注焦Ҏ(gu)以客戯营流E的开通、保障和计费QF(tun)ABQؓ(f)核心(j)Q运营支持与qA程从FAB实施程中分出来单列Q以增强对FAB中实现支持和自动化的x?/p>
eTOMҎ(gu)国电(sh)信业的意?/p>
我国?sh)信业经q前几年的快速发展,|络基础设施和用h量都已达到相当大的规模。如何有效地理和充分利用这些资源(|络基础设施、客戯源、信息资源等Q是各电(sh)信运营商都要面对的关键问题。eTOM的目的是通过业务程的实施来理企业Q它涉|?jin)战略、经营和保障{企业的三大高层程?qing)其怺间的集成。服务提供商需要这U通用的流E框Ӟ以确保有效和高效C其它实体q行交易和交互,保W三方Y件的开发和应用而不需太多的客户化定制。在?sh)子商务环境下,q种Ҏ(gu)E的共同理解Q在理?sh)信业务市(jng)场中愈来愈复杂的业务关pM极其重要?/p>
在经全球化、信息化时代Q在?sh)子商务环境下,业务程已经逐渐取代资金和技术,成ؓ(f)支撑企业赚钱的最主要因素。在价值网中,企业是通过紧密相联的业务流E,把技术、品和服务Q{变ؓ(f)现金。可以说Q业务流E已l成Z业核?j)竞争力的重要组成部分。在同等的h、胦(ch)、物的投入条件下Q不同的业务程所产生的结果将是完全不同的。eTOM从企业整体和所处的C会(x)l济环境的角度和高度来认识和看待?sh)信企业q营的业务流E框ӞҎ(gu)国电(sh)信业的稳步、快速发展将hp的现实意义?/p>
在战略流E方?/strong>QeTOM体现?jin)对企业资源的全生命周期理和一体化理的理c(din)eTOM明确识别?jin)SIPQStrategyQInfrastructureandProductQ流E群l:(x)战略与承诺,基础设施生命周期理和品生命周期管理。战略和生命周期理程h不同的时间周期,需要把q些程从最需要自动化的客户优先运营流E中分离出来?/p> 在运营流E方?/strong>QeTOM体现?jin)面向客户关pȝ理、对客户提供区别服务和营销的理c(din)除?jin)FAB外,eTOMq定义了(jin)q营支持与就l纵向流E群l。ؓ(f)使电(sh)子商务集成和客户自助理成ؓ(f)现实Q企业必M(jin)解自己需要的程Q以保证直接的、愈来愈多的在线以及(qing)客户q营支持和客戯助管理。从x客户或是面向服务转ؓ(f)面向客户关系理Q强调客戯助管理和控制Q增加客户对企业产生的h(hun)|利用信息来ؓ(f)单个客户个性化和客户化。明了(jin)跨技术管理资源的要求Q即Q应用、计和|络Q,由TOM?|络和系l管?功能程向eTOM?资源理与运?集成?/p> 在保障流E方?/strong>QeTOM明确标识?jin)企业管理流E,把企业管理流E和q营、战略作Z个整体,以便企业中的每个人都能够定其关键流E,从而整个企业都接受流E框架?/p> eTOM提供?jin)通用的服务提供商企业程视图Q它很容易{换成单个提供商的内部手段。eTOM能ؓ(f)服务提供商根据需要在不同层面qؓ(f)采用。eTOM的框架很灉|Q专门的服务提供商可以根据模块基和恰当的具体层面需求来选择自己所需的流E?/p> eTOM为服务提供商和供应商提供?jin)一个通用的框Ӟ便于在复杂的行业中讨论复杂的技术和复杂的业务需求。eTOM从企业整体的角度和高度,全方位地提供?jin)技术h员与理人员之间沟通的桥梁、语a与规范。而现实情况中Q技术h员与理人员因ؓ(f)看问题的侧重点不同,常常难以q行全面、深入、良好的沟通,难以从不同侧面、不同层ơ对企业q营的流E达成共识。eTOM特别x服务提供商用的业务程、流E间的联pR接口的识别Q如何利用客戗服务、资源、供应商/合作伙伴以及(qing)其它多重程使用的信息。在?sh)子商务的环境下Q从业务的各个方面来充分利用信息Q实现自动化以提高生产率和收入以?qing)改善与客户的关pd为重要?/p> 除了(jin)?sh)信q营商,eTOM也适用于业务和q营理pȝ软g的设计者和集成者,以及(qing)讑֤刉商和供应商。他们通过?jin)解理程和应用需求如何共同工作,为服务提供商和网l运营商带来利润Q而他们也从中获利?/p> 几点 l过q几q的信息化徏设,不少企业在企业信息化斚w的投入很大,却见效甚微。原因之一是:(x)~Zl一的业务流E框架、标准和规范。信息化需要规范的业务程和管理流E作为基。在?sh)子商务、电(sh)子政务全面出M际,框架、标准和规范?yu)显得尤光要;只有按照l一的框架、标准和规范Q才可能避免重复Q实C息共享。h们都把电(sh)信企业当作是信息化徏讄排头兵,q实际上隐含有四层意思:(x)1Q电(sh)信企业是国家信息基础设施的主要徏设者和q营者,担负着基础的重要命;2Q电(sh)信业自n的信息化能够强化企业自n的管理规范,提高q营效率和综合竞争能力;3Q电(sh)信企业可以利用自w的信息化典范,为其他的企业和单位提供信息化的解x案,Z业开拓新的信息化业务Q作ZU新的业务来为客h供更好的服务Q?Q电(sh)信企业自w的信息化徏设更h推进C会(x)信息化、政府信息化、企业信息化的示范和带头作用。因此,?sh)信企业在信息化q程中应该率先垂范,成ؓ(f)"以信息化带动工业化,发挥后发优势Q实现社?x)生产力的跨式发?的伟大战略实늚先行者?/p> 在电(sh)子商务环境下Q业务流E的互动牵动着各企业之间的互动Q各l济实体之间的联pL程中最重要的环节。ؓ(f)此,W者徏议:(x)?sh)信q营商应从业务流E的梳理与再造着手,先梳理然后再造业务流E,理顺业务程各环节的关系Q真正关注客戯够感受到的服务质量?/p> 内部程的梳理与再造?/strong>q是指在企业内部围绕业务程来安排各工作,光Ҏ(gu)大规模削减企业组l内部的成本Q提高质量和生率。以eTOM为指|整体规划Q徏立比较完善的XSSQXSupportSystemsQ如OSSQBSSQMSS{)(j)。在软g开发和业务关系斚wQ无论是服务提供商,q是|络q营商,都要考虑Q?Q从开发自q业务和运营系lYӞ转向更多的采购和pȝ集成的方式;2Q服务提供商和网l运营商之间新型的业务关pR徏立新型的业务关系和不q行内部开发是?jng)场驱动力所致。市(jng)场驱动力要求服务提供商和|络q营商增加业务的范围、羃短新业务投向?jng)场的时间、提高服务速度以及(qing)降低pȝ和运营成本?/p> 外部程的梳理与再造?/strong>从改善企业内部的l效开始,在跨企业组l界U的操作与处理过E中考虑更多的改良,Z业的q营方式带来H破性的革新。也是_(d)(x)通过q泛应用信息技术,重新规划跨越l织界线的业务流E,以实现经营W效的H破性提升。这要企业重新审视、梳理整个企业的l营模式Q对业务程和其中各个环节之间的怺关系q行审查Q审查的对象不仅仅是企业与客L(fng)关系Q还应包括企业与供应商、合作伙伴、员工和竞争Ҏ(gu)之间的关pR各?sh)信q营商之间既是竞争对手,同时又是合作伙伴Q应该采取有效措施加快和保?sh)信|络基础设施之间的互联互通?/p> 服务质量和服务等U协议?/strong>l织研究和实?客户QoSQQualityofServiceQ?SLAQServiceLevelAgreementQ管?。以前,?sh)信q营商只x|络的QoSQ而轻视客L(fng)QoSQ今后,?sh)信q营商更需要看重客戯够真正感受到的服务质量(QoSQ,而不仅仅是网l的QoS。因为,客户能够真正感受到的服务质量Q其内涵q远多于|络Q(jng)oS。这需要监视、管理和报告在企业的服务描述、客户合同或产品l合中有具体定义的和实际提供l客L(fng)服务质量的对比;同时Q关注与企业的业l、某些专门服务的服务{协议QSLAQ相关的产品与服务,以及(qing)其他与服务相关的文档Q包括:(x)|络、资源性能和可用性等q营参数Q还包含跨服务合同或规则参数的性能Q如Q订单请求的准时完成率,修复承诺的时_(d)客户联系的实施等。如果不能满_同规定的SLA要求Q就要采取向客户报告、ƈ对客戯行计费调整等措施Q以取得客户的理解和谅解Q让客户感到满意。(人民邮电(sh)报)(j)
]]>
վ֩ģ壺
ͬ˧GAYƬ߹ۿ|
ձһƷƵ|
µĻ|
AVר4SE
|
ձѴ߹ۿ|
Ʒһߵ|
߹ۿר|
ɫһ|
AV߲|
AVþþƷɫ|
þþþóƬѹۿѿ
|
vƬƵ߹ۿƵ|
þˮAV뾫Ʒ|
߲|
ƷؼһëƬѹۿ|
ŷۺ߹ۿ
|
182tvѹۿƵ|
ۺƵ߹ۿ|
ձ|
Ʒ|
ƷA߹ۿ|
һ|
av߲|
AëƬƵ|
һaƬþëƬ|
ۺϽ|
һѿ|
˻ɫַ|
ձһ|
hdѿ|
ƷƵ|
ѿƸվƵ|
ŮjƵڵ|
߶ר|
vaƷѹۿ|
ĻƷѾþ|
þþƷavպ|
ƷŮ߹ۿ|
aëƬѹۿ|
ŷղ|
պ߶ȸ|