业务运营支撑系统

2024-06-02

业务运营支撑系统（精选十篇）

业务运营支撑系统篇1

1 建设广电BOSS系统的重要性

有线电视在不断地发展,解决了当前信息孤岛以及信息系统的筹划问题,促进了运营商高效地使用该系统,提高了业务的处理效率。在有线网络的发展中,广电BOSS系统进一步发展了用户的群体,降低了运营的成本,提高了用户对服务的满意度,并且满足了用户具有特征的个性化服务。因此,加强BOSS系统的建立十分有必要,可以在使用的过程中强化管理与科学决策,保障用户资源以及业务整合,并且充分实现了信息的共享性、规范了业务的操作流程、提高了服务的运行效率。此外,该系统在发展的过程中逐渐地朝着多元化的方向改进,提高了整个有线网络的使用效率。

2 广电网络BOSS系统

2.1 广电网络BOSS系统的特点

广电网络在使用BOSS的过程中能够系统的涵盖,开展有线电视业务、数字电视业务以及数据业务等全方位的支持平台,并结合广电有线电视收费系统以及数字电视用户管理系统的所有功能。其特征表现在以下几个方面:一个统一、两个集中、三个综合。具体来说,“一个统一”是:BOSS系统在运行中能够统一客户的资料,掌握基本的信息;“两个集中”是:集中进行收费、集中认证并且将系统的收费以及认证中心融入到广电网络中,网络系统的运行中提高了运营商对下属区县的管理范畴,节省了系统的维护成本;“三个综合”是:综合的运营、综合的财务以及综合的客服,可以与客户在连接过程中实现“一单清”的效果,这样就方便了用户的使用。

BOSS系统在运行中能够全面地为客户提供服务,整个系统的体系主要围绕客户进行详细的构架。

2.2 广电网络BOSS系统的体系架构

由于广电网络在运行和维护系统中需要为公司提供最好的业务流程以及处理程序。这就要求广电网络BOSS系统要采用复杂并且多层次的分布式结构,在运行中主要是根据广电网络公司的相关的信息进行实时的处理,其中选用的是JavaRMI技术,节省了运营商在中间环节的投资。JavaRMI技术在多层次体系中主要的分为用户界面层、业务逻辑层以及数据库接入层和数据库层等,其中用户界面层主要采用的是以用户为核心进行系统连接的方案;业务逻辑层主要是将各个子系统模块之间进行连接;而数据库主要是将关系数据库进行连接,它需要将用户以及业务数据进行存储。由此,使用JavaRMI技术可以将各个模块进行功能联合,共同促进广电网络BOSS系统的体系架构的形成。

3 广电网络BOSS系统的开发和实施

广电网络BOSS系统在开发中需要将多个领域的网络运营商进行综合分析。在现代广电领域中,软件开发主要集中在用户管理、计费财务系统、综合营业、统计分析以及各个接口管理上,并且能够具体的分配各个使用功能。在该软件的开发过程中,需要进行的是可视化的系统分析以及设计,提供业务建模、需求分析、设计分类、测试以及最终实现和发布。每一个阶段必须进行严格的管理,才能为客户提供高效可行的服务。

广电网络BOSS在实施的过程中,是根据广电网络运营商的用户实际情况进行的。该系统主要以运作流程为主线,并且借助相关的辅助工具,不断地扩展网络功能、扩大用户量、提高信息服务效率,并根据现有的资源进行整合,通过客户模型进行统一处理,大大提高了用户的使用效率,加强有线电视网络在运营支撑系统上的使用。

4 总结

笔者重点阐述了搭建BOSS于广电网络的重要性,并对相关的具体信息进行分析,为进一步促进新兴的电信级运营商提供了可行的建议。广电网络BOSS系统的建设,最终实现了以客户为中心的经营理念,在体系架构中主要采用的是多层次分布式,助于其在使用中能够进行不断的扩展。当然,在广电业务BOSS系统中,需要根据具体的情况制定严格可行的管理计划,在合理的规划设计中制定可行的方案,才能不断地增加业务数量,并为用户提供高质量服务。

摘要：随着台网分离的实施以及广电业务的不断发展,广电网络当前已经成为一个电信级的网络运营商。本文主要介绍了广电网络建设综合业务运营支撑系统的必要性,以及在建设的过程中该系统最终实现了以客户为中心的经营理念,最终提高了广电网络的市场竞争力。该系统构架在多层技术软件系统之上,并将该系统进行扩充,为用户提供了切实可行的方案。

关键词：广电业务,运营支撑系统,市场竞争力

参考文献

业务运营支撑系统篇2

《以下言论，只代表个人观点，不具有针对性，请勿对号入座》

地球人都知道，中国XX公司是以个人移动用户起家的，业务支撑系统从诞生那天起，就是建立移动用户档案，按套餐计费，最后把钱收上来，随后建设的经营分析系统，核心目标也是分析个人市场提供市场决策，中国XX公司业务支撑系统也就是BOSS1.0诞生于2003年前后，业务支撑系统的雏形已经形成。在2004年前后在中国XX公司市场部下组建了集团客户中心，随着三大运营商对高端移动市场的争夺，集团客户中心逐渐从市场部独立出来，甚至由集团客户中心升级为集团客户部，与之同时，增值业务中心、数据部也随之出现。随着中国XX公司的组织机构的变革，业务支撑体系也在发生裂变，BOSS从BOSS1.0到B0SS1.5、2.0、3.0，甚至NGBOSS，时至2012年的今天，中国XX公司业务支撑体系能否支撑全业务运营呢？近段时间，这个问题一直困惑着我。困惑一：ADC前途未卜？ 2006年中国XX公司全国打造ADC（应用数据中心）今后的路在何方，6年了规范没有更新，让人匪夷所思，ADC前途未卜呀。困惑二：ESOP生逢其时，但被边缘化了！2009年推出的ESOP规范，总称“中国XX公司集团客户业务综合运营平台”，帽子的确不小，但遗憾地是在一些省落地时变成了“门户”，所为门户顾名思义是“入口”，不好听点说是一张皮。造成这个结果，依照个人的理解有两个方面的原因，一是省分公司没有认识到ESOP的重要性，不客气地说是集团客户战线的同志们，也没有想清楚想要啥；二是规范很全面，缺少统一规划，分布实施，总部和一些专搞IT咨询的人士看的远，但与各省管理和工作流程相差远；三是ESOP的建设和支撑由计费中心承担了，计费中心同志们的头上两把剑：计费准确性和系统稳定性，这也好理解ESOP成了计费中心的附属系统，边缘化了，也因此ESOP离“中国XX公司集团客户业务综合运营平台”的差距还很远，但反观中国XX公司其它省份，也不尽如此，一些省份就是由数据部主导ESOP建设的，离市场近也能保持中立，尽量不给BOSS添乱，BOSS该干嘛干嘛，ESOP也有发挥的余地，这个时候就体现了省分公司的差距了。困惑三：面向集团客户的渠道建设，迫在眉睫。中国XX公司个人客户渠道还是非常不错的，不管是实体渠道，还是电子渠道。非常惭愧地说，中国XX公司集团客户渠道还是空白，集团客户业务营业厅无法办，网上营业厅也没“门”。难道集团客户渠道就靠千千万万的客户经理吗？非也，动力１００已在中国XX公司门户上占了一席之地，ＡＤＣ门户也存在数年，但大多省分公司动力１００门户只是些花架子。冷静下来想想，这种现象与集团客户市场发展还处于初级阶段，即维稳。维稳是第一位的，维稳就要维ＡＢ类集团的稳，这些集团客户对产品的需求，无外乎专线＼Ｖ网，更重要的是靠关系维稳、靠营销成本终端补贴维稳，甚至靠信息化项目投入维稳，可惜又可庆的是这类客户一个省分公司是有限的，几万家十几万家足矣，可惜的是更多C类集团甚至是微型集团未完全纳入集团客户的篮子，可庆的是这些集团有限，否则就要投入更多的客户经理，更多的营销、投资成本。说句抱怨的话，大多省分集团战线的同志们“不拿客户当客户”，他们无视城市里写字楼上下班簇拥的人群，他们当中尤其是一些私企老板是很关心他的驻地销售人员，很关心公司仅有的几辆车有没有被员工私用，他们靠的是固定电话报到，靠的是每天统计车的里程数，他们需要的不仅仅是彩铃，这里是集团信息化产品的蓝海和沃土。当然，“不拿客户当客户”放到中国XX公司的企业文化里，是没有将这些客户纳入KPI，“集团客户占比”的力度还不够，屁股决定脑袋，一任也不超过三年，也难为集团客户战线的绝大多数同志们了。说到这里，又不得不提中国XX公司的老大哥省分公司了，比如广东省分公司在网上集团单位能够体验产品、订购、支付和查询了。OneCM不是一两年了，贫富差距怎么这么大呢。中国XX公司从上到下都在全员挖空心思创新，都在比拼PPT,真不如树个标杆，做些实实在在的再基础不过的事情。总而言之，中国XX公司到了面对全业务运营，需要静下心来反思、自问中国XX公司业务支撑信息化体系准备好了吗！

业务运营支撑系统篇3

关键词：移动通信；运营系统；支撑技术

中图分类号：TN929．5文献标识码：A文章编号：1000-8136(2009)24-0143-02

1引言

本论文主要针对移动业务运营支撑系统在面向3G多媒体业务平台时所需要进行的转变及设计展开分析讨论，以期给出一些可供借鉴的平台建设方案和技术指导，并与同行分享。

23G多媒体业务支撑平台要求分析

3G网络所支持的业务与2G网络相比有较大的变化，从基本的语音业务拓展到多媒体业务，新业务的特点对业务支撑系统提出了新的要求：

2．1业务捆绑

3G业务众多，针对用户的消费习惯细分客户群，推出各种捆绑业务和服务营销包，业务支撑系统需要支持业务捆绑打包销售。

2．2更灵活的计费方式

3G业务增加了对QoS的要求，除了要实现传统的实时计费和按内容计费模式外，业务支撑系统还需要将QoS作为计费要素之一。业务支撑系统还需要根据不同业务采用按时长、流量和使用次数等方式计费。3G的计费采集点众多，协议复杂。业务支撑系统应该能够统一而不失灵活性地计费。

3移动业务运营支撑系统的设计及实现分析

3．1基于软交换技术的业务支撑平台开发

3．1．1平台的软交换开发

随着计算机和通信技术的不断发展，通过在一个公共的分组网络中承载话音、数据、图像已经被越来越多的运营商和设备制造商所认同。在这样的业务驱动和网络融合的趋势下，诞生了NGN(Next Generation Network)下一代网络模型，实现在分组网络中，采用分布式网。

网管中心软交换综合网管系统遵循TMN系列规范设计，分为网元管理层、网络管理层和业务管理层等功能层次。软交换体系各种设备都提供相应的管理器，实现设备的本地操作维护功能，同时在网管系统中可基于SNMP管理协议与TELNET实现对各设备的集中管理，包括相关参数的指配。

3．1．2多媒体业务的平台实现

在对3G多媒体业务平台的设计布置中，采用WCDMA3G平台协议，其中WCDMA系统设置了WAP网关、LCS定位服务平台、MMS、Java平台、短信中心和网关、流媒体服务器；CDMA2000系统设置了定位平台、Java平台、多媒体邮件平台、流媒体平台、WAP平台、可视电话平台、BREW平台以及短信中心和网关。其中的多数业务平台对于不同的3G技术是可以共用的，具体情况如下：

短信系统通过信令网与3{3网络相连。WCDMA中，短信系统可以与核心网MSC相连，也可以通过Gd接口与SGSN相连。CDMA2000中，短信系统只与核心网MSC相连，由于WCDMA与CDMA2000所支持的信令协议不同，2种技术应分别设置短信系统。

定位业务既可以通过信令网也可以通过IP网连接3G网络。由于WCDMA与CDMA2000网络所支持的协议不同，而且WCDMA、TD-SCDMA与CDMA2000在无线定位的实现方式上各不相同，3种技术应分别设置。

WAP、Java、彩信、流媒体等同属于口网上开展的业务，它们对不同技术的网络所支持的IP协议是通用的，只要承载在同一个IP平台上，3种技术能够实现业务平台共享。

3．2运营平台对多媒体业务的接入设计

3G时代相比于2G时代，移动多媒体业务成为了应用的主流，这也是3G的魅力所在。然而，要实现多媒体数据业务与平台的接入，在目前的3G网络平台中也不是那么容易实现的。为此，本论文主要讨论HSDPA(高速下行分组接入)多媒体数据的接入，从而实现3G平台的多媒体业务运营支撑。

HSDPA的基本原理是在R99的空中接口体系中，数据重传方式是由RNC来负责完成的，数据重传需要绕经Iub接口。数据重传的周期较长~NodeB仅仅起到一个根据RNC的指令完成物理层编码、传输的功能，NodeB本身基本不具有对物理资源的控制和调度能力，而在HSDPA中，为了在空中接口上实现更大的吞吐能力，对NodeB的功能进行了增强，在NodeB的层面引入了物理层重传和快速资源调度的概念，通过在更靠近空中接口的NodeB上引入这些原本只RNC才具有的功能，加快了重传以及对空中资源调度的效率。

为了实现HSDPA的功能特性，以及更好的完善移动多媒体数据在平台上的介入，需要在物理层规范中引入设计三种新的物理信道：

3．2．1高速下行链路共享信道(HS-DSCH)

在下行链路上，传输用户的业务数据。采用固定的扩频因子，由于需要给公共信道、HS-SCCH及相关的DCH预留可用的信道码，所以最大可用信道数为15。传输时间间隔定义为2 ms(3个时隙)，远小于R99中规定的10 ms、20 ms等长度。从而大大缩短了数据重传时终端和NodeB之间的往返时延。

3．2．2高速下行共享控制信道(HS-SCCH)

在下行链路上，传送HSDPA的专用信令，如传输格式和系统资源指示等；采用固定的扩频因子SF=128，每个终端最多可以同时监测4个HS-SCCH。

3．2．3高速专用物理控制信道(HS-DPCCH)

在上行链路上，发送反馈信道信息(如信道质量指示CQl)和传输块发送确认信息(承载HARQ进程需要的ACK／NACK信息)。用户终端通过测量CPICH得到CQl信息，cQI的上报周期和映射可由网络定义。NodeB通过用户从上行专用控制信道HS-DPCCH中反馈的信息得到用户的下行信道情况，然后NodeB根据所收集的所有用户的信道情况，通过一定的调度策略，为当前用户分配HSDPA的下行数据传输的物理资源(HS-DSCH、HS-SCCH)，同时选择相应的最合适的AMc方案，以此来实现系统吞吐量最大化、用户吞吐量最大化、用户QoS保证等资源调度目标。

4结束语

业务运营支撑系统篇4

关键词：业务平台,业务逻辑优化,接口优化

0 引言

每一项增值业务的背后, 都有一个或多个业务平台来提供能力支撑, 这些业务平台纳入统一的BOSS (业务运营支撑系统) 来进行用户信息管理, 业务平台接受BOSS对用户数据的统一管理, 并根据BOSS提供的用户数据提供服务。

在这种业务管理架构下, BOSS对用户的订购关系具有最终的管理权, 同时业务平台作为业务能力的提供者, 也必须同时管理一套用户数据, 它们之间通过各类实时或非实时接口进行数据同步。由于各种人为或自然原因, 如接口故障、系统bug、人为干预等, 使得系统运行一段时间后必然会出现业务平台与BOSS之间用户数据不一致的情况, 这种情况极易引发客户投诉、大量转人工岗处理、数据统计误差等各类问题。

本文主要针对以上问题, 从业务逻辑优化和接口处理方式优化两个方面进行详细分析, 探讨提高平台接口容错能力, 缓解接口故障带来的压力, 解决数据差异问题的可行性及实现方式, 并就此类问题提供一套切实可行的解决方案。

1 业务逻辑优化方案的探讨

业务平台与BOSS间的运行模式, 通常是由业务平台提供实时或非实时接口, 由BOSS向业务平台发起用户业务变更指令, 这些指令通常包括开通、取消、暂停、恢复、修改5大类。在传统的业务逻辑中, 业务平台通常就这些操作提供标准的指令格式和返回码, 并对业务处理逻辑进行详细的校验, 将成功或失败的处理结果以返回码的方式通知BOSS。

在理论上, 如果双方用户数据完全一致, 这样的处理方式非常合理、准确。但是正如上面所述, 由于不可避免地存在业务平台与BOSS间数据不一致的情况, 当针对不一致的用户数据进行指令操作时, 可能由于处理失败而产生失败工单或人工工单, 这样的错误除非进行认真的人工干预, 否则误差数据将继续存在, 业务受理也无法成功。

为了解决以上问题, 基于一个公认的前提, 即BOSS是用户数据的唯一管理者, 业务平台应以BOSS中的用户数据为准来提供服务, 所有的业务开通、取消、修改均以BOSS指令为准, 我们对接口间的业务逻辑进行一定优化, 举例说明如表1。

表1中所列的是几种较为简单和通用的业务逻辑优化思路, 不同的业务平台应从自身平台业务特点和容错能力要求出发来制定自己的业务逻辑优化方案。

2 接口优化方案的探讨

大部分业务平台都向BOSS提供了实时的业务受理接口, 通常采用C/S (客户机/服务器) 的架构, 业务平台接口作为服务端, 供BOSS的客户端调用;而业务平台接口本身又作为一个客户端, 调用平台内部的其他接口或直接操作数据库, 将用户数据写入数据库。

业务平台在7×24 h运行中, 内部不可避免地会出现各类故障, 可能由硬件故障、软件bug、数据库故障或人为操作失误等各种原因造成。这些故障的出现难免会影响BOSS对平台接口的调用, 导致BOSS中工单无法竣工, 进而导致大量堵单或转人工岗的情况出现, 影响BOSS自身的正常运行。

基于对业务逻辑优化方案的探讨, 可以认为, 业务平台应完全以BOSS的指令为准来操作自身数据。也就是说, BOSS发送的指令在业务平台应该绝大部分是操作成功的。因此在平台故障的情况下, BOSS可以不用理会业务平台对指令的返回, 而业务平台也应当完全依照BOSS的指令来处理用户数据, 这样一来就可以在发生故障时将原本必须实时处理的操作拆分为两个异步的过程。

我们可以考虑对业务平台接口进行如下改造和优化:

1) 当业务平台接口调用平台内部接口或数据库出现异常时, 直接向BOSS返回操作成功, 同时将BOSS的指令记录入库或记录文件日志;

2) 业务平台接口启用一套定时重做机制, 定时扫描查询未处理成功的指令并进行重做, 直至重做成功;

3) 根据业务平台自身实际情况, 对定义的少量无法按照BOSS指令操作成功的数据, 输出错误日志进行人工处理。

3 接口的进一步优化

增值业务具有丰富和灵活的特点, 为满足业务发展的要求, 增值业务平台相对与其他核心平台来说, 需要面对频繁更新和升级带来的各种的问题:每次更新和升级都有可能导致与BOSS连接的中断, 无法处理的指令将会在BOSS中产生大量积压。

这一问题可以通过两种途径来解决:一是BOSS提供指令重发的能力, 对业务平台未反馈结果的指令定时重发, 直至指令受理成功。二是业务平台进行一定改造, 参照接口优化方案, 平台可以对外提供一套临时接口:当业务平台进行更新升级时启用该临时接口, 接受BOSS的指令, 录入文件并反馈成功, 平台升级完成后, 通过平台的重做机制对这些积压指令进行重做。这样可以最大程度地保障平台与BOSS间接口的通畅。

4 结束语

本文讨论的业务逻辑和接口优化方案在实施后, 可以最大程度地提高平台接口容错能力, 解决由于业务平台自身原因造成的BOSS堵单或大量转人工岗的问题, 同时也可以在BOSS和业务平台之间产生一种对原有不一致数据进行自我净化的效果, 通过接口的长期运行, 逐步将原有不一致的数据调整为一致。当然, 各业务平台应当从自身业务特点出发, 制定适合的业务逻辑优化方案和接口优化方案。

业务运营支撑系统篇5

摘要：首先分析了基于云架构的业务支撑网技术方案及存在的安全问题，结合目前云安全的常用技术，提出了云架构4A认证系统和移动业务支撑网相结合的云安全技术方案以及实现流程，总结了这种方案的优点。

关键词：云计算；4A系统；业务支撑网云计算现状

云计算[1]是一种按使用量付费的模式，这种模式提供可用的、便捷的、按需的网络访问，进入可配置的计算资源共享池（资源包括网络，服务器，存储，应用软件，服务），这些资源能够被快速提供，只需投入很少的管理工作，或与服务供应商进行很少的交互。好比是从古老的单台发电机模式转向了电厂集中供电的模式。它意味着计算能力也可以作为一种商品进行流通，就像煤气、水电一样，取用方便，费用低廉。云计算为人们带来便利的同时其安全性也不容忽视：2011年4月22日，Amazon的云计算服务器再次出现大面积的岩机；2009年2月24日，Google Mail邮箱爆发全球性故障，服务中断长达4小时；同年3月17日，Microsoft的云计算平台Azure停止运行约22小时；众多的案例引发了人们对云计算安全的思考，安全问题解决不好，将严重制约云计算的可持续发展，有效解决云计算的安全问题势在必行。基于云架构的业务支撑网技术方案

目前移动业务支撑系统包括BOSS系统、经营分析系统、运营管理系统等子系统，云架构的移动业务支撑系统平台，通过采用iaas私有云技术，把BOSS系统的众多服务器，网络设备，数据库等设备组成“云端”基础设施服务提供给维护人员[2]。并将CPU计算能力、内存、I/O设备和存储整合成一个虚拟的资源池为BOSS业务提供所需要的存储资源和虚拟化服务器等服务。经营分析系统和运营管理系统则通过采用SaaS技术将应用软件统一部署在业务支撑网云平台上，营业厅、客服、渠道、市场部门的营业人员、客服人员、业务管理人员及集团客户经理等用户根据需求通过互联网使用软件服务[3]。

这种模式在为业务人员和维护人员提供快捷便利的同时，业务支撑系统的安全性和保密不容忽视。采用传统4A系统和业务支撑系统相结合后在一定程度上提高了系统的安全性，但仍然存在以下三个问题：（1）账号管理变更频繁，每天营业员、集团客户的权限都有大量的变更需求，不能建立岗位权限互斥的安全模型。（2）随着业务支撑网内应用系统的不断增多，各自独立的缺乏关联分析（以自然人为核心进行关联的统一集中的系统登录、登出、正常维护、异常操作）的审计系统已不能满足需要。（3）在日志量达到T级别后，系统的检索性能急剧下降，无法进行有效的数据检索和日志分析，导致无法实时分析和告警正在发生的危险行为。云架构的4A系统应用在移动业务支撑网

云架构的4A系统[4]在系统架构上划分为三层：统一入口层；云采集层；云审计层。

统一入口层：为普通人员和管理人员提供了Web方式登录界面以及堡垒主机群。

采集层：主要功能是实现用户资源系统之间的数据交互，资源从账号的收集和同步管理，日志采集以及告警数据发送。为了避免出现日志采集遗漏等情况，并提高采集系统的运行稳定性以及日志解析处理能力，通过使用云架构，使采集系统能够支持分布式采集功能，同时引入搜索引擎，以达到优化底层查询逻辑，减少垃圾数据量，提升用户使用好感度。

审计层：统一身份管理，资源及认证管理，账号授权管理，访问控制管理，安全审计管理，安全合规管理，安全事件管理。云架构的审计选择Hadoop作为审计数据分布式处理的技术框架，通过存储方式的变化、存储结构的变化以及分析、检索框架调整，提供高效、多任务并发的数据分析处理能力以及高效的审计数据全文检索能力。该云架构的4A系统应用在移动业务支撑网中的优点

云架构的4A系统应用在移动业务支撑网系统架构图，如图1。

4A认证云平台为业务支撑网各应用系统提供统一、多样化的帐号、认证、授权和审计方面的安全服务机制，主帐号与从帐号实现集中化、基于角色的管理，针对应用资源实现角色级授权；针对系统资源的权限控制实现实体级别授权。自然人通过与主帐号的关联，对身份信息和岗位角色进行统一规划与管理，不同应用系统中的帐号的创建、分配、同步进行集成到4A管理平台进行统一管理，建立起从帐号的单一视图（业务支撑实体资源-应用资源及后台系统资源），以及主帐号的单一视图管理（业务支撑系统中使用者）从而有效的解决了授权变更频繁以及岗位权限互斥的安全模型的建立。

采用基于统一访问入口的主帐号的集中指纹强身份认证方式，并根据用户使用业务支撑网各应用系统中的应用资源和系统资源的具体情况进行相应的权限分配与稽核，实现不同岗位、角色的用户针对对不同部分实体资源的访问权限控制。建立完善的自然人对实体资源的的授权管理。从而解决问题2（自然人登录缺乏相应从账号的关联问题）。

采用Hadoop分布式文件系统（HDFS）的可靠数据存储服务对原始数据进行存储，可以轻松应对PB级的海量数据而且硬件成本低；利用MapReduce技术的高性能并行数据处理服务可以大大提高运算的效率，从而解决了问题3（数据量超大后缺乏有效分析）。

参考文献

[1]MellP，GranceT.The NIST definition of cloud coputing.National Institute of Standards and Technology（NIST），Washington，USA：Technical Report Special Publication 800-145，2011.[2]田峰，等.中国移动业务支撑网4A系统安全技术规范v3.0[S].中国移动集团技术规范，2013，4：88-92.[3]田峰，等.中国移动业务支撑网数据安全管理办法[S].中国移动集团技术规范，2008，4：1-3.[4]鲍伟民.基于云计算的安全审计系统研究与设计[J].软件产业与工程，2012（6）：41-45.作者简介：王雪娟（1977，8-），女，民族：汉，籍贯：河北省新乐市，单位：山东圣翰财贸职业学院，职称：中级工程师，研究方向：网络安全。2007-2014年曾就职于山东移动业务支撑部负责网络安全建设。

数字电视运营支撑系统的设计与实现篇6

关键词：数字电视；运营支撑；设计

中图分类号：TN948 文献标识码：A文章编号：1007-9599 (2011) 08-0000-01

Digital TV Operations Support System Design and Implementation

Lei Huoxin

(Guangdong Sihui TV,Sihui526200,China)

Abstract:With the deepening of the digital transformation,and now,digital television gradually replace analog TV broadcasting industry to become a national trend,two-way cable network transformation has also been booming,making the entire network of value-added significant.

Keywords:Digital TV;Operations supports;Design

一、数字电视运营支撑系统需求的分析

作为一种将客户作为核心的管理机制，数字电视运营支撑系统对账务和客户实行统一管理，围绕客户开展各种新增业务，三大主营业务是关注的焦点，不断扩充着系统中的新增业务管理。在资费方面采取自选套餐或服务-产品-套餐/促销的方式确定，使运营政策的不同需求得到满足。银行、网银以及第三方支付等可以通过系统的统一支付平台进行对接。调查并收集广电行业主要需求的相关数据，结合上述设计思路，对数字电视运营支撑系统的需求进行确定。

二、功能模块设计

（一）个人业务受理。个人客户的开户和业务办理共同组成了个人业务手里。在系统中为个人客户注册账号即个人客户开户，机顶盒以及CA卡需要在开户时赠送给客户，以客户办理地址为依据，确认机顶盒是否已领，以规则引擎为依据，对相关费用是否向客户收取进行确定。

对个人资料进行修改、产品订退、停复机、故障申告、销过户、充值续费、查询账单等属于个人客户业务办理的范围。将信息录入每个业务办理界面后，适合客户的规则便显示出来，对所需要的规则由操作员指定，然后在数据库中保存业务和应用规则的相关信息。

（二）集团业务受理。集团客户开户以及业务办理共同组成了集团业务受理。在系统中为集团客户注册账号即集团客户开户，将合同的有效期、金额等信息进行记录，且将合同金额录入后，系统便默认费用已经由操作员收取。集团的加入和退出、机顶盒和以卡的购买和更换、维护子集团、业务定制、合同的续签和修改等都属于集团客户业务办理的范围。在相同时间内，一个客户的有效合同只能有一份；业务修改、办理新的以卡业务等，可在合同有效期内完成，且相关费用不再收取；业务可以根据子集团的不同而不同，但一个合同只能与一个业务相对应。

（三）运营管理。对产品、条件、服务、服务类型、业务附加信息等进行管理，即运营管理模块所包含的内容。其中，修改、增加或禁用服务类型，即对服务类型的管理，需要有不同的类型提供器的接口对应每种服务类型，禁用时，该服务类型在服务定义中将不显示，但在之前定义的服务中其效力依然存在。视频点播，宽带，数字、模拟电视等是不同的服务类型种类。有三种方法连接服务类型提供器的接口和外部系统，即Start（）：调用命令开始；finished（）：命令处理完成；invoke Command（）：对业务的具体命令进行处理。

提供器的类名称的字符串是在服务类型的类中保存，从而对业务类型的去除或动态增加进行支持。要注意不能重复服务的名称活编号，必须填写服务的授权号等。服务通过其服务类型的类型提供器接口来实现与外部系统的对接。

三、设计和实现数字电视运营支撑系统运营管理模块

运营商定义产品、收取资费的地方即运用管理模块，其是数字电视运营支撑系统的核心所在，业务的优惠、收取客户费用等都会受此影响，对产品、条件、服务以及收费项目的管理等都属于运营管理模块管理的范围。

（一）服务管理。运营商为客户提供的视频、音频等即服务，实现服务的启用、禁用、修改、增加等即服务管理的内容。对服务的唯一标识需要通过服务编号来实现；系统通过授权号与外部认证系统进行通讯；“无服务提供商”是系统默认的状态；VOD、宽带、数字、模拟电视等目前系统所支持的四种服务类型；客户对服务包月购买时每月应支付的相关费用，通过月使用费来标识。若用户选择生成产品，则系统将对单服务、单月的产品进行生成。“定义中”是生成后的产品状态。

（二）产品管理。打包组合各种服务，进而形成各类营销组合，即产品。产品有一般、赠送以及客户自选产品等不同类型，此处只对运营商定义的一般产品进行讨论。定义中、已发布、已冻结和已过期是产品的状态类型。对产品进行发布、修改、增加、冻结以及解冻等，是本模块的功能；处于“定义中”状态的产品才可修改；修改产品在“已发布”状态即发布产品；实施冻结的只能是已发布的产品，变为“冻结”状态，冻结产品不能再向客户出售，但已订客户的续订不受此影响；重新启用冻结产品即解冻，使产品显示“正常”状态。对产品的唯一标识需要通过产品编号来实现；有“包月”、“线性”两种计费方式，包月为默认；产品发布后并开始销售即为活动开始时间，产品销售的截止日期为活动结束时间，以“YY-MM-DD”来表示；每月需支付费用即月功能费；是否优惠以客户的购买时常为依据；适用区域，即产品在该区域内发布和销售；必须对产品包括的服务项进行选择，对产品服务列表进行确定。

（三）收费项目管理。运营商定义的，向客户一次性收取的费用即收费项目，修改、增加以及冻结收费项目等都包含在内。在使收费项目增加的同时，使应用条件直接生成，并显示为“已发布”状态，即收费项目增加；运营商冻结收费项目即收费项目的冻结，此时该收费项目在条件定义中将不显示。

（四）条件管理。定义中、已发布、已冻结以及已过期是四种条件状态。发布、修改、增加、冻结以及解冻实现条件，是条件管理的主要内容；条件在“定义中”状态时才可修改；修改产品在“已发布”状态即发布条件；条件发布后才可实施冻结，相关业务中不再应用冻结条件；重新启用冻结条件即解冻条件，使条件显示“正常”状态。规则和结果是条件包含的两个部分，条件只有完全与规则相符，条件结果才能应用。

参考文献：

[1]卢官明.数字电视原理[M].北京:机械工业出版社,2004

[2]中软公司.数字电视运营支撑系统总体技术方案[J].2009

业务运营支撑系统篇7

随着信息技术和通信技术的迅猛发展, 电信网、广播电视网以及互联网正在进入全面融合的时代。在三网融合时代下, 广播电视业务形态和运营模式将发生根本性的变化。广电运营商也将面临从单一业务提供商到综合信息服务提供商的转变。广电运营商虽然在公共服务领域占据主导地位, 但与电信运营商相比, 在基础网络、业务形态、业务支撑、用户服务、规范体系、技术储备等方面有着一定的差距。在此巨大挑战和机遇下, 广电运营商必须对现有的运营支撑体系进行全方位、多角度的审视, 对业务形态、运营模式、用户服务等方面进行深入剖析, 认清不足、找准方向、正视困难, 建成符合三网融合要求, 具有“设计清晰、融合支撑、架构扁平、控制集中”特征的新一代广电全业务运营支撑系统[1]~[3]。

全业务运营支撑系统在数字化、互动化以及三网融合的进程中, 扮演着不可替代的重要角色, 是江苏有线信息化架构的基础。江苏有线全业务运营支撑系统与原有的运营支撑系统相比, 不仅能够支撑数字电视、互动电视和宽带业务, 并且能够支撑基于江苏有线云媒体的可视电话、电视支付、卡拉OK、电视阅读、电视虚拟网、PPTV、电视互联网、电视商城、电视游戏、电视游戏等业务;支撑跨用户跨业务的融合套餐和产品管理;引入了时间量、使用量的新型收费方式, 并可按次、按时间量、按使用量、按时长、按栏目等多种计费方式;支撑外围29个系统300余个子系统接口接入, 并能够通过ESB快速进行接口的封装和接入;建立了单独的CP和SP的结算管理子系统, 此外还能够实现按业务的工单组合。目前已经实现了对融合业务套餐的支撑管理:支持跨用户的融合业务开展;支持共享资源的融合套餐销售;新增融合套餐新装、加装、重组、拆单功能;实现了有线电视与宽带业务统一客户管理, 为推进三网融合业务发展做好了铺垫。

1 全业务运营支撑系统建设目标

根据三网融合业务要求和江苏有线IT支撑体系的整体规划, 江苏有线全业务运营支撑系统目标建设为具有“设计清晰、融合支撑、架构扁平、控制集中”特征的新一代全业务运营支撑系统, 可实现对数字电视、宽带、多媒体通信、增值业务和融合业务的支撑管理;实现网间结算、网内结算、CP/SP结算管理;支持时间量、使用量、余额等多种计费方式;拓展服务渠道, 完善网上、电视营业厅, 短信、电话自助服务等;实现外围业务系统的快速对接和新业务的快速上线部署。

2 全业务运营支撑系统软件介绍及特点

江苏有线全业务运营支撑系统基于J2EE体系架构的分布式企业应用, 采用B/S的方式, 使用户免于安装、更新客户端, 使用IE浏览器即可访问操作。成熟的J2EE技术为项目提供了性能、可维护性、安全等各个方面的有力保证。采用APPFrame应用开发平台作为实施J2EE架构的技术工具, 以达到代码开发的高效率及系统运行的稳定性。在订单处理、服务开通等流程性较强的模块中采用了Com Frame工作流开发管理平台作为流程开发与管理的工具, 从而达到对业务流程的灵活配置和管理监控。在全业务运营支撑系统内子系统间的互联, 以及全业务运营支撑系统与外系统的互联中使用AIService Weaver产品进行系统间的交互, AIService Weaver是一个具备安全机制、可全程监控、支持集群化高性能的企业服务平台, 是企业联系各种外部系统服务的总线;支持可二次开发扩展的通信接口协议、定制应用组件机制, 使用高性能的内部调度模式并兼容业界标准的BPEL规范。

江苏有线全业务运营支撑系统中的综合帐务管理系统采用标准的多层结构体系, 前台界面采用WEB方式;中间件采用Open Broker, (Open Broker支持目前比较通用的Tuxedo、CORBA、CICS、SOCKET) ;后台服务采用C++语言实现。综合帐务管理系统从逻辑横向层面来看, 大致可以分为三层结构, 分别为接入层、业务层、数据层。从技术层面来看系统采用Browse/Application Server/Web Server多层结构设计, 支持前端浏览器访问方式。整个体系为B/S架构, 最前面一层是客户端 (即浏览器端) ;第二层为Web Server层, 采用Struts架构, 通过相应的协议调用OBD接口和后台应用服务之间通信;第三层为应用服务层, 采用C++实现, 和Web Server之间通过OBD接口实现, 应用服务层之间还存在互相调用的情况, 采用PMGR或MGR OBD接口实现两个App Server之间的互联。第四层为DB层。

江苏有线全业务运营支撑系统采用MDB技术, MDB是整个系统的内存数据共享区, 由一个单独运行的服务程序来管理, 客户端通过SOCKET访问它, 它具有和数据库相似的访问特性, 但速度却和内存相当, 使用MDB的目的是为了提高系统的大数据量的处理能力。通过把分业务信控状态、信控队列、账本余额、信用额度等相关资料存放入MDB, 实现秒级的信控管理, 做到实时的欠费停机, 减少了系统坏账率。整个账务的计算处理完全在内存中进行, 使系统出账性能得到了较大提升。

全业务运营支持系统涉及客户关系管理、服务开通、账务管理等多个子系统, 为了实现多个子系统间的单点登录和工号、角色、权限的统一配置, 采用了Sec Frame。Sec Frame提供单点登录、统一管理和统一认证的功能。操作员只要登录一次, 即可使用多个子系统下的功能, 并且在统一权限平台下管理组织、操作员、角色、权限及赋权等功能, 不需要在不同系统下做重复的管理操作;子系统全部通过调用统一权限平台提供的分布式服务进行权限验证, 各业务系统本身不再保留权限模块。

3 全业务运营支撑系统总体架构设计

江苏有线全业务运营支撑系统体系架构采用全省集中架构, 架构图如图1所示。

江苏有线全业务运营支撑系统提供本地的业务支撑 (BSS) 、运营支撑 (OSS) 、管理支撑 (MSS) 、决策分析支持 (DSS) 、业务支撑网网管 (NMS) 等功能, 并在今后与国家级全业务运营支撑系统对接, 实现数据和业务的共享。在全业务运营支撑体系的集中架构中为各地市提供所有业务受理、统一授权和认证鉴权、账务处理、费用收取等支持。DSS为市场和营销提供报表和客户兴趣走向的分析。NMS为系统的监控和健康和平稳运行提供保障。生产系统为正常进行业务运营的系统。另外还有容灾系统为备份系统, 为系统遭受自然灾害和人为破坏后的系统全面恢复提供保障。

3.1 功能架构

江苏有线全业务运营支撑系统的功能划分为若干个逻辑上和功能上相对独立的子系统, 子系统之间有明确、规范的接口划分。各个子系统有机结合, 协同工作, 共同完成完整的业务运营支撑功能。系统的应用体系结构从功能角度可以划分为若干个子系统:客户关系管理子系统、账务管理子系统、账务处理子系统、综合结算子系统和统一授权子系统, 各个系统间通过单点登录实现界面集成。

3.2 技术架构

江苏有线全业务运营支撑系统技术架构分为三层架构:接入层、业务层和数据层, 如图2所示。

1.接入层

接入层是全业务运营支撑系统与外部进行数据交换的平台, 提供各种输入输出, 实现对业务逻辑的共享。接入层可分为界面展现和接口服务。

2.业务层

业务层是全业务运营支撑系统业务处理的逻辑平台, 它通过对数据服务子层的调用访问业务数据, 实现不同的功能模块, 满足不同的业务需求。业务层由若干业务流程组成, 通过调用业务组件, 为接入层提供业务服务, 实现业务逻辑的共享, 完成相应的业务功能。

3.数据层

数据层分为数据存储子层和数据服务子层, 是全业务运营支撑系统对业务数据进行统一组织、集中管理的平台, 它为业务层提供规范、高效的数据服务, 实现业务数据的充分共享, 是整个系统的基础。

3.3 部署架构

江苏有线全业务运营支撑系统部署架构图如图3所示。

4 系统建设方案

4.1 客户关系管理子系统

客户关系管理子系统, 又简称为CRM系统, 包含了各项业务的受理和产品的销售等, 涵盖了业务受理、营业缴费、综合查询、客户投诉建议处理和应急营业终端等功能, 其功能架构如图4所示。

客户关系管理子系统的开发技术框架主要应用J2EE开发框架——APPFrame, 其技术架构图如图5所示。

4.2 账务管理子系统

账务管理子系统是对用户的资金信息、消费情况、积分信息以及信用度信息进行管理的系统, 同时账务系统对用户的消费状态进行监控, 一旦出现欠费或异常的消费现象, 便及时采取相应的措施 (如欠费提醒、欠费停机等) , 其功能架构如图6所示。

账务管理子系统采用标准的多层结构体系, 前台界面采用WEB方式;中间件采用Open Broker, (Open Broker支持目前比较通用的Tuxedo、CORBA、CICS、SOCKET) ;后台服务采用C++语言实现, 数据库采用oracle数据。账务管理子系统从逻辑横向层面来看, 大致可以分为三层结构, 分别为接入层、业务层、数据层。技术架构图如图7所示。

4.3 账务处理子系统

账务处理子系统是全业务运营支撑系统中的重要计费环节, 主要是累计用户的使用费用和月租费等生成帐单, 进而为用户缴费或查询余额、经分系统、帐务管理销账等提供依据, 相关功能架构和技术架构如图8、图9所示。

4.4 综合结算子系统

综合结算子系统是将其他业务系统所提供的计费数据, 经过采集和按照一定规则的处理后进行相应的计费和计算。其总体功能如图10所示。

4.5 统一授权子系统

统一授权子系统主要为业务系统提供了统一的授权激活管理。对于业务系统, 无需关心网元的相关信息, 通过调用统一的业务接口来实现网元的激活开通等控制。统一授权子系统主要包括配置管理、激活处理、信息查询、后台任务等功能模块。统一授权子系统的系统内部关系图如图11所示。

5 系统集成关系

江苏有线全业务运营支撑系统的子系统通过ESB、表接口、Web Service以及文件接口的方式实现系统间的集成, 其集成关系如图12所示。

6结束语

综上所述, 本文系统地介绍了江苏有线全业务运营支撑系统的现状、建设目标, 并从功能架构、技术架构和部署架构三方面介绍了系统的架构设计。对于系统中的五大子系统的功能和相关架构进行了详细说明。江苏有线业务运营支撑系统目前承载着江苏省11个省辖市, 57个县 (市、区) 及1个省外城市 (马鞍山) 的业务受理、服务开通、计费等支撑工作, 支撑全省2000万用户规模, 1000多个营业厅的日常业务, 年受理量达到亿级。

伴随着三网融合事业的不断深入, 建设一套技术先进、全面集成、动态管理的全业务运营支撑系统得到广泛的关注和认同。江苏有线全业务运营支撑系统是对广电业务流程和模式变革的一次探索, 为江苏有线三网融合业务的运营和推广奠定了坚实的基础。

参考文献

[1]乌家培.三网融合的历史与现实[J].中国信息界.2010, (12) .

[2]卢薇.三网融合背景下广电面临的挑战[J].通信企业管理, 2010 (07) .

业务运营支撑系统篇8

1 有线电视广播的运营现状与业务分析

随着数字电视业务的逐步深入, 原来的业务系统正成为制约广播电视发展的瓶颈, 主要表现为三个方面。一是缺乏统一的客户资料。每个业务系统分散且完全独立, 形成了大量信息孤岛, 客户资料无法共享, 不能得到及时、客观、真实、准确的分析结果, 无法推出快速响应市场的高效优惠方案, 也无法为客户提供更个性化、人性化的服务。二是各种业务系统封闭分散。广播电视各业务系统各自为政、独立运行, 不仅不利于各种业务的开展和各种新产品的推出, 还不利于广电的内部管理和协调。三是无法实现统一管理。分散的系统造成管理的分散, 使得业务管理环节众多、不规范, 资料管理、客户管理、合作伙伴管理滞后, 增加了管理难度, 浪费了相关资源。

可见, 处在模拟电视、数字电视交替的过渡时代, 广电需要一个完善的、高可靠性、高可用性、高稳定性、高灵活性、高可扩展性、高兼容性以及高可管理性的、面向未来的综合业务运营支撑系统 (B O S S系统) 来整合替代原来各个分散的系统。随着用户数量的增长和数字电视增值业务的迅猛发展, 为提高管理水平、运营效率和服务水平, 增强企业竞争核心力, 建设多业务综合运营支撑系统成为广电系统的首要问题。

2 面向未来的多业务综合运营支撑系统的建设思路

2.1 以客户为中心, 提高客户服务水平

B O S S系统的最终目标应该是建设成“以客户为中心”的广播电视综合业务运营支撑系统, 为客户提供个性化、社会化、信息化服务。首先, 要解决广电长期以来的客户资料残缺问题, 只有建立完整、准确的客户信息和用户资料, 才能把握市场。其次, 建立以客户为中心的产品化营销模式, 资源被包装成视频和数据产品包, 由营销部门和分销商进行销售和服务。更为重要的是以客户的需求为要素来制定、包装产品和促销, 同时提供个性化的客户销售、服务和管理。第三, 对客户进行分析, 通过BOSS系统对客户细化、分类、分解, 从而发现高端客户。不同等级的客户, 可以有不同的促销和优惠;可以有不同的服务方式和通道, 从整个网络范围内将客户数据收集并加以整合以获得客户的完整视图, 真正了解每一个客户, 识别带来最大利益的客户, 以保证平均每客户利润 (ARPU) 。

2.2 BOSS建设要以面向未来的综合业务系统为目标

除传统业务外, 可以支撑更广泛的增值业务, 成为满足未来业务发展需要和具备实时处理能力的综合性的业务处理平台。此外, 广电BOSS系统必须建立涵盖业务运营、市场营销、客户服务、网络优化、信息共享、数据整合、决策支持等环节的一体管理流程, 将广电网络整合成为一个更加经济有效的新实体, 从而解决数字电视平移阶段过程中各种业务分散管理的状况, 最终实现统一管理, 拓展增值业务, 提高网络运营商的价值。广电数字化改造后, 传统业务利润有限, 为增加利润, 提升网络运营价值, 挖掘网络潜力, 开发新业务和拓展增值业务是网络运营商势在必行的发展方向。为此, B O S S建设必须充分考虑将来增值业务的迅猛发展, 制定增值平台、服务的接入规范和运营规则, 统一增值业务的计费规则, 将增值业务纳入有序管理的环境中, 确保增值业务的健康发展。广电B O S S系统必须建立全面集成的业务流程, 以期在快速多变的市场当中紧贴客户的需求。

B O S S建设还必须充分考虑业务运营网络和分销渠道, 提供营业厅直接接入、各种分销渠道的简单业务连接以及Call Center、网站、多媒体自助终端、银行现金代收、实时划账等多种数据交互模式, 极大拓展业务运营支撑系统的运营渠道和运营空间, 为多业务的发展准备好条件。此外, 建立完整的资源管理系统, 加强对各种资源的集中管理, 提高资源管理的效率、为各种资源组合打包、调整服务提供支持, 达到物尽其用的目的。

2.3 必须建立准确、可靠的计费和帐务体系

在模拟电视时期, 当用户欠费拖费时, 运营商只能采用剪断电缆线这种原始的方法进行控制, 而且用户数据不准确, 使得呆账坏账极为普遍, 用户欠费率非常高, 广电的损失非常大。广电数字化平移后, C A S可以很好地控制到每个用户, 因此, 建立灵活、准确和及时的计费和账务处理系统, 提高计费、出账、收款的效率和准确性成为B O S S系统建设的重要目标之一。每个客户对应一个帐本, 可以拥有多个账户, 通过帐务系统, 对客户进行细化, 形成业务级帐户, 客户对不同产品的消费使用不同的账户, 加强业务管理。同时, 建立多渠道缴费体系, 方便客户灵活支付。为实现对多业务的融合处理, 模型设计思想通过一套统一流程来处理对多种业务的计费, 通过逻辑上统一的一个流程完成所有的帐务处理动作。通过帐务管理, 实现对帐单、缴费、欠费、查询的管理, 支持多种缴费形式, 同时提供各种帐务数据的统计报表。支持各种预存款、零头、退费的处理和转换, 通过催缴、停机、预拆、呆坏帐处理等手段来减少欠费。通过灵活、准确和及时的计费和账务处理系统提高计费、出账、收款的效率和准确性, 提高收视费的回收率, 减少坏账的产生几率, 能有效地防止欠费, 从而有效地改善广电长期以来的欠费拖费现象。

3 结语

多业务综合运营支撑系统将为广电未来开展多元化业务运营打下良好的基础, 带来真正意义上的业务运营;充分发挥双向网络的优势, 通过电视终端, 可实现多样化的双向互动业务。依靠B O S S这个全面集成的业务运营支撑平台, 不仅可以对已有业务进行灵活运营, 而且在新产品的推出上同样能够赢得主动。B O S S系统具有强大的产品定义及配置能力, 只要发现有市场需求的产品和服务, 只需在广电B O S S中进行配置, 就可以立即构建出相应的系统支持以实时配合市场推广和销售, 为广电业务的发展拓展了空间。

参考文献

[1]王斌.试论广电网络企业信息化建设[J].广播与电视技术, 2004, 3.

[2]王斌, 陈伟中, 王晓红, 等.广电网络BOSS系统建设维护的几点经验[J].电视技术, 2005, 6.

业务运营支撑系统篇9

关键词：业务,支撑系统,项目管理,系统设计

一、目前电信业务支撑系统的关键技术

新一代BSS不再以满足单方面某一业务需求为目标, 而是通过BSS最终达到提升电信运营商整体运行效率的目的。新一代BSS的建设满足四个需求层次:第一是能完全管理网络上运行的服务;第二是管理这些服务提供给用户的过程;第三是管理售出服务的收入从数据采集到最后收款的过程;第四是当运营商从一个简单的语音运营商变成多服务提供商之后, 在服务、内容提供等方面需要很多合作伙伴提供配合, 因此应能提供支持与合作伙伴的管理沟通工作系统。电信管理论坛提出了TOM (Telecom Operation Map) 模型, 该模型把电信运营的所有活动归结于四个方面, 分别为:客户接入管理、策略、实施和产品管理、运营管理和企业管理。TOM模型较全面地反映了电信企业运营活动的所有层面, 其结构层次划分清晰, 各层面实现功能完备, 代表着电信企业管理运营方向。

作为TOM模型的进一步发展, ETOM (Enhanced Telecom Operation Map) 模型包括了客户、运营、策略、实施和产品、企业管理, 阐述了通信企业运营管理的所有方面。它把企业运营管理作了系统的描绘, 具有全面性和整体性, 对于通信企业未来的管理体系及应用系统具有很强的指导作用。BSS系统采用了ETOM模型, 但所有的模型都是不断发展的, ETOM也不例外。对于BSS来说, 如何在保障业务连续性的前提下, 采用新技术, 满足新需要, 方便快捷的系统维护升级是非常重要的, 在技术上引入企业应用集成 (EAI) 的技术思想, 建立一个应用软件承载平台。作为一个独立于任何系统的软件基础设施, 应用软件基础平台由工作流平台、信息交换总线和共享核心数据组成。通过标准的适配器, 将应用系统连接在一起, 应用系统向信息总线提交要发送的数据, 并接受自己订阅的信息。由于每个应用系统都不依赖于其他应用系统而独立工作, 所以信息交换总线可以大大降低应用系统接口的复杂性;核心数据是所有系统赖以生存的基础, 也是企业正常运作的命脉。通过建立一套规范, 这些核心数据就可以在企业内共享, 以便充分挖掘出其应有价值。

通过这个信息交换平台, 各系统或应用模块按照事先制定的接口标准进行交互, 通过信息交换平台处理事务、消息、数据的转换工作。各个专业系统将不再是企业中孤立的信息小岛, 而是有机地融合在一起, 标准接口的应用使得运营商一方面可以保证BSS能适应企业工作流程的变化, 另一方面也使企业的核心技术不依赖于某个应用软件开发商。这样, BSS就能真正成为运营商参与商战的工具。

二、电信全业务支撑系统开发与实施步骤

因此业务支撑系统实施过程也分为五个阶段:实施前准备阶段、开发阶段、试运行阶段、割接上线阶段.、运行维护阶段, 各阶段具体工作如下。

1、实施前准备阶段

首先成立项目统筹规划组织 (电信业务支撑系统领导小组) , 负责制定项目全局规划、项目实施路线和阶段计划, 明确项目目标和实施办法。然后根据制定的项目规划, 开展总体沟通工作, 进行项目实施有关业务和需求调研工作, 掌握现有业务流程和模式, 与项目规划进行比较差异分析, 制定解决方案。组建项目实施团队, 明确项目实施组人员, 明确项目实施职责。另外完成硬件环境准备和数据库、应用软件安装工作。

2、开发阶段

开发阶段要完成系统概要设计, 详细设计, 在第一阶段给出详细设计文档草版, 模块的具体解析, 各模块的接口定义等文档;第二阶段实现基本的框架, 基本功能, 提交详细设计文档修这个版;第三阶段进行代码开发阶段, 实现全部预定功能, 项目基本完成, 给出详细设计文档最终版, 并提供用户使用手册;第四阶段由测试人员对系统进行全面测试工作, 并根据测试反馈结果由开发人员进行修改完善系统功育旨。

3、试运行阶段

首先根据业务情况及公司实际状况选择试点单位, 明确试点相应任务和职责, 试点要达到的目的;然后对试点单位开展支撑系统功能、业务、操作等培训工作, 使使用人员理解系统设计目的, 掌握系统操作方法;在此基础上开展试运行, 试运行期间实行日报制度, 开发团队根据试点反馈情况及时修改源程序, 完善系统功能。

4、割接上线阶段

根据试运行和用户测试情况综合进行评估系统是否具备上线运行的条件, 在评估条件具备后进行割接准备工作, 包括环境准备、割接方案制定、应急方案制定、相关数据准备、割接版本确定。其中重点是割接方案和应急方案的准备, 另外割接版本至关重要, 并完成割接版本发布工作。同时组织完成业务配合和操作培训工作, 从人员上具备系统上线条件;最后按照割接方案实施割接, 完成系统上线工作。系统割接完成后, 要对系统的运行进行严密的监控, 及时发现系统潜在的故障并处理。对于割接后的系统运行情况, 每天要进行综合的记录, 以用于系统割接工作的评估。

5、运行维护阶段

系统上线运行后, 即转入运行维护阶段, 首先完善系统维护制度, 制定需求管理办法和流程, 需求变更必须在严格的流程控制下执行, 并遵循版本管理流程进行。常规维护和新需求开发由相应的维护小组负责, 严格按照需求管理流程执行。

参考文献

[1]梁伟展.3G业务支撑系统体系演进的探讨[J].联通通信技术专栏, 2006, 1:12-18.

[2]戴和义.电信业务支撑系统软件质量管理初探[J].江苏通信技术, 2005 (21) :38-41.