文档库 最新最全的文档下载
当前位置:文档库 › 2010电信计费大会-许安特

2010电信计费大会-许安特

2010电信计费大会-许安特
2010电信计费大会-许安特

面向客户和业务流程的OSS建设规划

HP

咨询与集成事业部

电信业总经理

许安特

各位来宾早上好。去年大概这个时候,我们举行了同样一个类似题目的会议,去年我主要讲BSS的这些方面的内容,今年我认为我们叫OSS年,把重点放在运维支撑体系这方面。惠普在这方面做了一些工作,今天我想跟大家分享一下。首先简单介绍一下全球OSS发展的趋势和最佳实践。另外做一些调研和分析工作,介绍中国运营商OSS现状和诊断分析,最后介绍一下某个运营商OSS规划和案例。

首先从OSS来看,未来的需求从客户驱动,OSS尽管比较远离前端,前面有一个BSS,但是我认为也是客户驱动的。所以我们后边会提到OSS前移的理念。各国运营商在IP界,在OSS方面重点考虑服务质量。所以这种客户感觉的服务质量,客户驱动,OSS发展的驱动。我刚才讲到驱动力是业务驱动,支撑系统前移,从左边来看,主要确保通过SLA实现端到端的接口质量。右边就是由于3G的来临,使OZS面临一个新的机遇和挑战。总的来说,各国运营商除了靠公司员工的积极性,怎么样建设一个灵活、可靠的支撑系统体系是非常重要的。从网络来看,一个是标准和界面一定有开放性,软硬件分离技术不断发展,最主要从过去的电路交换转变为IP为主的宽带网络交换,最后就是我们3G的到来。总的来说,我们认为下几年运营商会在IT支撑,OSS方面会提供大的投入。

资源管理是运营商最大的重点之一。资源需求会对运营商产生比较大的影响,尤其是怎么通过有效的配置企业资源,管线调度,盘活企业的存量资产,提高利用效率,通过这样才能最大限度满足客户需求,提高网络效能。所以精细化管理和OSS前移能够保证这方面目标的实现。

OSS也是我们给全球最大的无线运营商做的时候简化成这么三块,一个从USER来看,一个是Damain来看,一个是资源管理,通过后面的Ressource来实现,我们把3GOSS简化成三大块。

我们也知道,全球标准化是TMN和TMF和ETOM。eTOM设置了保障流程定义,设置了服务管理,服务质量管理,还有跟踪客户开通等等,这些都是eTOM有详细规定。所以进行OSS建设的时候,要充分考虑,通过流程驱动的方式管理来进行OSS的建设和规划。刚才我提到了,TMF和TOM要串起来,我们认为这种业务模型在全球运营商用的比较多。我刚才讲的要以客户为对象,以客户为主的业务流程模型,通过左边的市场渠道服务开发,一直到开通、保障、计费,通过这个流程最后进行分析。从网络层来看,我们要进行分析、计划、开发、采购、进行适当的资产管理。固定资产管理也是运营商去年大部分运营商都做固定资产管理的工作,现在怎么跟资源管理系统整合在一块,从OSS来看,他管资源管理的位置,财务方面来看,他要考虑资产怎么进行折旧。所以现在数据两边,就是OSS跟财务系统的接口,数据的整合还不是很好。

我们也知道,运维管理体系比较分散,通过网员管理、IP管理、系统管理、应用管理,今后应该从最佳实践首先有一个纵向的专业网络管理,或者集中网络管理,建立统一的专业网络管理。所以,在这个基础上进行整个的运营管理。

从左边来看一个是管控,管控有时候比技术手段还重要。从管理来看,我们通过刚才所讲的前移要进行融合的网络管理,提高资源的使用率,另外要提供KPI的新服务,通过SLA 来实现。最后快速响应,快速响应必须要根据业务的等级以及客户所要的QOS来进行,在

进行分批的时候可以有不同的价格。我们认为理想的服务开通支撑体系,这显示不同的层,我们分成EML、SML,等等他们之间的关系,可以说比较理想的系统应该是这样,尤其3G 来临的时候。

服务保障体系,包括投诉、网关管理、故障管理和性能管理,还有施工管理,整个的资金关系,以及他们端到端的流程,都在这儿体现出来。

从技术架构来看,我们认为使用套装软件比较好,他是快速布置,也是快速灵活配置,通过二次开发,而不是重新开发、重头开发。通过服务等级发现服务,我们要动态提供新功能和新服务。支持数据多功能持久共享,减少数据的不一致性。要有明确的功能接口,专注于业务的提供。功能模块来看,最好要能够易于替换和更新。在业务流程既要优化物化也要梳理,灵活的能够改变。

下面介绍一下我们通过一些调研发现中国运营商OSS的现状。中国运营商来说有四个阶段。第一阶段就是我们所讲的基本阶段,也就是主要用手工,整个网络和业务数据模型基本上没有。第二阶段正在处于发展阶段,开始有完善的,或者逐步完善的业务流程,业务数据模型在不断地进行建立之中。第三个阶段是比较领先的,我们讲OSS阶段,也就是说整个业务流程,自动化的程度比较高。数据模型相对完善,最后我们认为是全球比较好的最佳实践。我们通过发现有大概十个主要问题,功能系统方面来看,我们觉得刚才所讲的面向客户,业务端到端的系统管理不足,快速相应不够。尤其网管设备,网络设备,网络管理的维护系统。另外管理“监”强于“控”,这样不能快速实现业务开通,这样造成孤岛现象,OSS 系统建设层面来看,难点在于运营商缺乏统筹规划、统筹安排、整体规划的OSS规划,建立出来的系统相对比较孤立。在投资方面不足,研究也不错,但是我觉得还不是很够,整体的OSS大框架方面还没有比较好的理论性框架。管理流程方面,我们觉得端到端的流程没有建立起来,另外由于部门所有制可能造成前后台的信息不能互通,也就是我们所讲的OSS 不能前移。我们认为OSS系统工程是一个表面建设,我们认为从建设层面和管理层面才是本质现象,只有解决了右边的问题,左边的问题就相对比较容易。我们采取的策略改善运维体系,提高管理水平,同时梳理优化和固化端到端的业务流程。另外前移进行快速业务开通,提高监控水平。

这是我们无线运营商的场景分析做一个案例,左边列出了出现哪些问题,人工能解决什么问题,通过网管能够解决和不能解决的问题,这是我们做的一个简单案例。

我们认为从建设OSS整体规划思路来看,中心的目标应该以市场为导向,以客户为中心进行精细化管理,包含三个内容,一个服务开通与保障,客户满意度和网络运行质量。服务开通与保障来说,我们认为首先要解决市场响应慢的问题。客户满意度方面来看,基于流程化管理,突破部门所有制,为客户提供快速相应,提供高效的服务,这是比较主要的。从网络运行质量方面来看,有些工作应该加强,比如系统整合、动一的服务和数据模型,系统之间的接口等等。整体思路一定我们叫OSS前移,不是整个系统前移,而是前端客户信息后置,后端运行状态前移,这样能打通端到端的客户前移,满足客户需要。

最后介绍某运营商的OSS规划和咨询案例。首先我们进行调研,设置中期和远期的业务目标,通过这个制定一个演进路线图。运营商是面向3G,尽管会把OSS整体,OSS一般要跟业务支撑系统还有管理支撑系统他们之间的关系要列清楚,另外本身OSS他有好几个子系统,运维管理,这些要理顺,最主要要把下一代的3GOSS网络系统规划好。从我们规划的项目范围来看分四大块,第一是我们讲的流程,包括服务开通、服务保障,运维管理。技术架构最主要要把系统总体架构规划出来,还有它的边界与接口,还有技术和产品的选型。从演进计划来看,有三到五年的OSS系统建设路线图,同时我提到,到底用自我开发还是上游软件要进行分析,让运营商做出选择,最后做出估算。管控是最重要的,怎么理顺OSS 管控模式,是集中还是分散,都是要在规划里最好能理清楚。

惠普做咨询和规划项目基本从Why,这个从业务视图,业务驱动力和业务目标是什么。基础确定业务功能,管理和数据使用原则。What,什么系统架构,应用系统和数据原则等等。最后采用什么样的技术和产品实施,包括合作模式,实施原则等等。这个项目一个是业务开通管理保障,质量,业务范围和前瞻性进行分析,我们发现这个运营商目前的OSS系统普遍形象于特殊的需求,忽略管理与决策性的支持,我刚才讲管理非常重要,还有怎么可前瞻性,这三方面,包括人、技术和流程,都有一些问题。我们通过项目发现,包括整个运营商,如果我把这整个看成一个海,上面是一个冰山,冰山下面又是海平面,实际中间的技术方面基本只占15%,大部分的冰山,海平面下面的冰山,就是我们所讲的人、流程和文化,这几方面实际处理好,这个技术我们认为只占15%,85%都是管理、流程、人员文化方面。

我们这里简单举例一下,业务需求应该是规划建设的驱动力,所以我们列出市场与竞争,内部业务与管理,哪些业务驱动力是能够驱动OSS为今后业务发展服务的。所以,OSS前移,一定要考虑前端的客户信息后置,后端的运行状态前移。我们这里举了一些整体的3G 和OSS目标功能应该比较广,我们提出未来的整个框架,这里主要讲功能,我们发现运营商在满足要求方面,资源数据维护方面比较好,但是在黄色这部分,部分满足,很多地方,比如SLA和QOS还是没有的。我们先看服务开通流程,大部分运营商做规划的时候,要把我们讲的流程进行梳理和优化,BPI或者BPR,通过梳理和优化然后把流程,端到端的流程进行场景分析,比如我们举一个业务咨询,我们就发现他响应速度慢,系统数量繁多,而且继承性比较弱,形成大量的孤岛。3G的系统建设有重叠,没有进行协调,不够融合。在SLA 方面,从工单质量查询到有一些不能很好满足客户的需求。在响应速度方面跟资源配置有关系,跟资源查询有关系。业务定单刚才所讲的系统上比较多,所以它的流程从网络告警、网络配置之间怎么串起来,都没有实现。最后,要跟考核,从管理的角度来看,这些必须要串起来,这些有一些不足之处。

服务开通系统,他是以业务为主线纵向建设数量比较多。大家知道,前端要求市场不断推出新业务,我们知道有些客户有上万个套餐,这样对后台支撑会产生很大的技术支撑难度。这是开通流程做一个简单的场景,不多说了。

看一下服务保障流程,在故障申告方面,故障单的调度、故障判断、销障的确认、回访,整个流程出现了不太好的问题,比如前端部门的服务相对比较被动,投诉的量比较大。经常由前端部门发现大量的用户申告造成网络故障,后面没有集中的进行监控能力不足,不能及时的修复和反馈。另外没有实现我们所讲的网管告警自动生成工单。

从运维管理流程来说,从右边这块运维管理包括作业计划、报批、组织管理等等,我们感觉这里包括所有这些都应该包括在运维管理的体系里。从网络性能分析到网络优化、资源规划和优化审批方面,应该加强这方面的工作,尤其资源动态采集、资源配置、资源查询和统计和数据维护,这几个方面应该串起来的。最后我们认为如果3G的OSS业务目标支撑,应该包括方方面面,所以从整体来看,还是比较复杂的,我们还是采取一些“非瑟掊斯”来解决。

相关文档