全业务支撑（精选9篇）
全业务支撑 篇1
在当前激烈的市场竞争中, 中国移动在支撑方面还存在着长流程支撑的短板。因此, BOSS系统需要全面提升融合的全业务支撑能力, 提升全业务的灵活、快速部署能力。为了使能“全业务运营”落实和贯彻精细化营销的经营策略, 福建公司信息系统部门综合10多年的支撑经验, 明确提出以产品融合运营为核心的“331”的全业务支撑战略方针。
以产品融合运营为核心
根据全业务支撑系统规划目标积极推进各项目建设开发, 我们初步构建起“331”全业务支撑体系, 包括如下内容。一是“三项流程贯通”, 包括项目运营流程、服务开通流程与投诉处理流程, 打通客服系统、BOSS与EOMS这3个系统间的服务开通与投诉处理流程, 实现售前、售中与售后的流程全面贯通。二是“三类业务受理”, 通过系统融合支撑与流程贯通, 实现了专线业务、宽带业务、固话三类业务营业受理与业务管理。三是“一个系统融合支撑”, 全业务支撑各专项项目均遵照总部NGBOSS规范, 统一在BOSS系统中安排改造开发, 实现全业务融合受理、融合账务与融合计费。
完成融合运营的升级改造
福建移动信息系统部在分析全业务产品特性和NGBOSS系统的特点后, 认为融合运营是全业务发展的必然趋势, 针对性地启动并完成了融合的产品管理项目, 对BOSS系统产品模型进行升级改造, 构建面向为TD业务、家庭业务、集团业务、固话业务、宽带业务、互联网业务等业务融合发展的产品运营核心。
在该项目中, 我们通过建立统一的产品目录, 搭建共享的、全方位的产品信息视图, 提供灵活的产品组合和包装能力, 为市场营销、客户服务、销售管理等前端应用以及融合计费、综合账务、服务开通等后端应用提供业务支撑能力。以统一的CRM承载融合的全业务、全产品客户运营, 实现全渠道一体化的营销、服务、业务受理, 以强大的融合计费引擎和灵活的账务配置支撑融合的全业务产品设计和实现, 缩短新业务开发周期, 提升全业务快速支撑能力。
率先具备宽带业务融合支撑能力
福建移动信息系统部经过半年多宽带业务支撑改造项目的建设开发, 在全国范围内率先在BOSS系统中具备宽带业务融合支撑能力, 实现了宽带业务受理、用户管理、服务开通、账号认证、计费账务处理等宽带业务运营支撑, 同时汇编了《广电合作宽带运营支撑体系》, 作为总部宽带PBOSS规范编制参考以及全业务运营支撑经验交流材料。
同时, 福建移动还启动了“中国移动福建公司IP认证计费系统优化改造项目”, 协调配合龙岩、泉州等分公司逐步将本地系统支撑的宽带用户迁移整合到BOSS系统, 实现了自建自营、广电合作、铁通合作等多种模式宽带业务运营支撑与市场推广。
从2009年开始, 在固话业务支撑方面, 福建移动在统一营销支撑、统一受理支撑和统一服务保障的融合支撑方针指导下, 目前已完成有线固话、集团固话、无线固话和铁通合作固话等业务支撑系统的改造。当年1月实现了基于窄带交换机 (企业直连) 、IMS核心网不同方式的固话业务运营支撑, 提供面向个人用户和家庭市场的固话业务支撑解决方案。4月在现有集团语音专线业务的基础上, 建设开发了集团固话业务支撑平台, 率先在全国范围内具备了面向集团客户的固定语音业务运营支撑能力。5月启动无线固话业务支撑, 7月实现了一阶段需求, 进一步完善了全业务系列产品线。
在推进全业务运营支撑同时, 信息系统部门还开展了全业务障碍台研发项目, 2009年5月份割接上线, 实现了10086与10088基于投诉工单系统的宽带/固话业务投诉受理和处理的支撑, 并实现了与EOMS接口对接。
全业务支撑 篇2
导语：竞聘演讲稿又称竞聘报告、竞争上岗演讲稿、竞聘书，是竞聘者在竞聘会议上向与会者发表的一种阐述自己竞聘条件、竞聘优势，以及对竞聘职务的认识，被聘任后的工作设想、打算等的工作文书。它是公文应用写作研究的重要文体之一。
尊敬的各位领导，同志们:
大家好！
我是，岁，学历，目前在的岗位从事工作，我的工作内容主要是各类业务录入指导、渠道拓展管理、渠道酬金结算、各类经营、考核数据提取与分析、规定动作执行检查等方面。今天，我参加竞争的职位是业务支撑一职。今天，我能参加这次竞选，心中百感交集，首先要感谢各位领导多年来对我的教育和培养，感谢与我同舟共济、朝夕相处的全体同事对我的帮助和信任；我很荣幸自己赶上了这次挑战自我、展示自我的大好时机，使我有机会争取一个我喜爱且需要我的工作岗位。
在工作的年里，我将青春与热忱投入到自己所从事的平凡岗位上，履职尽责，努力工作，先后获得、荣誉，在的发展历程中发挥了我应有的作用。
竞聘该职务我有如下优势：
我从年起就部门从事工作。工作中我热心、仔细、处处以人为本，长期的工作实践，使我具备了眼界宽、悟性好、出手快的特点，善于把握工作重点，准确领会领导意图，及时而创造性地完成交办的工作任务；同时我还掌握了业务支撑工作的程序和要求，服务能力、科学判断能力、执行能力、沟通协调能力都有了较大的提高。
责任与能力是密不可分的。信誓旦旦的喊口号却因为能力不足无法办到绝不是我想要的。我深知新时代的电信部门业务支撑职工应该是一个全面加特长的复合型人才，不仅要掌握精深、广博的知识，拥有吃苦耐劳的健康体魄，还要有良好的修养。“学习型”社会强调的就是不断充电，学习的步伐要大于或等于变化的步伐才行。为了提高自己的素质，我无时无刻不在加强学习，提高自己。
如果这次我能竞聘成功，我将努力做好以下工作：
找不准位置，也就找不准工作的立足点、切入点、着力点，工作起来也就会茫然。为此首先要做好“战斗员”，围绕业务支撑工作，对上认真执行领导的工作指示和要求，对下加强沟通协调、联系员工，团结大家一起做好部门的各项工作责任。同时，精准把握好工作岗位的角色定位，做到管理无巨细，参谋不决断，助手不揽权，不越权，不越位，不缺位，工作要到位。
一是协调好上下的关系。对上做到尊重而不盲从，服务而不奴婢，在实际工作中，做到机动灵活，坚持原则，按章办事。对下做到以礼待人，以诚交人，以情聚人。不盛气凌人，不搞瞎指挥、乱指挥，切实做到以大局为重。二是协调好内外关系，外求支持协作，内求团结向上，努力做到以发展的眼光看问题，以和谐的氛围促发展。
明确自身责任，努力按照政治强、业务精、善管理的复合型高素质的要求对待自己，加强政治理论与业务知识学习，全面提高自己的政治、业务和管理素质，在提高自身素质的同时，还要学会尊重，学会理解，学会“给予”，并善于“换位思考”。做到爱岗敬业、履行职责，吃苦在前，享乐在后，全力实践“团结、务实、严谨、拼搏、奉献”的时代精神。
古人云：不可以一时之得意而自夸其能；亦不可以一时之失意而自坠其志。不论这次竞聘结果如何，我将继续勤奋学习、勇于实践，不断提高科学判断形势、应对复杂局面及配合全局的能力。进一步增强事业心、责任感和使命感，尽心尽责做好各项工作，为公司事业发展添砖加瓦！
全业务支撑 篇3
我们知道, 网管支撑系统 (OSS) 担负着支撑电信网络规划、开通和运行, 保障电信网络正常、经济、可靠、安全运行的任务。当电信运营进入全业务运营时代, 从传统的以产品为边界的分割运营向综合服务转型时, 与之相对应的OSS系统也迎来了规划和建设的关键时机。
各大运营商都正在积极研究和探索, 全业务运营到底给当前的网管支撑系统建设带来了什么样的挑战和要求?网管支撑系统的建设应该在哪些方面进行调整或改进, 来更好地满足新形势下的需求、提升企业市场竞争力?更好地服务于全业务运营环境下的内外客户?
回顾电信行业的技术发展, 当固网占据主导地位时, 提供的服务单一、用户类型和规模固定。移动技术的兴起导致固话业务没落, 当移动用户规模超过固网用户后, 个人用户个性化需求日益凸现。价值链从过去的用户、运营商和设备提供商延长到用户、运营商、设备提供商、系统集成商和平台、内容提供商。
在全业务运营环境下, OSS建设有着如下突出的特征。全业务环境下, 运营商终于可以为客户提供综合的信息服务解决方案了, “一站式”和“一个账单”服务也十分诱人。电信运营商要实现由“以生产为中心”向“以客户为中心”的经营战略的转变, 以客户为中心进行精细化管理, 要尽快地推出更多的业务, 给客户带来更好的服务, 加强电信服务个性化、人性化, 满足客户的“DIY”需求, 提高客户对企业产品的忠诚度和满意度。OSS建设需要把关注焦点从面向网络设备的管理, 转移到面向客户和业务的管理上, 整合分散在在不同的管理平台上的客户基本信息、订购的产品/业务信息、所占用的资源信息、以及服务投诉信息等数据, 建立客户与网络资源之间的关联关系, 逐步实现对业务、客户 (主要指集团客户) 以及企业运营的关联分析与综合分析, 形成对统一客户视图和客户体验的支撑能力, 缩短网管支撑体系与客户之间的距离, 有效支撑客户需求的挖掘, 形成满足客户共性化需求和个性化需求的服务支撑能力和资源支撑能力, 支撑业务开通、业务保障等各个环节中客户的业务要求和服务要求。
二、融合
如今的网络与技术融合是面向融合的原动力, 由于网络与应用已经从原来单一化发展逐渐变为业务间跨层支撑, 网络层间复杂融合, 对多业务与技术的支撑系统提出了更高的数据处理要求。业务发展不仅仅是现有网络基础, 同时也需要向下一代网络技术支撑扩展, 未来网络与业务融合要求在统一的平台上支持多种技术和业务。
OSS的融合首先是指网络与业务管理融合。业务是运营商在竞争环境下最为看重的企业核心竞争力资源, 运维支撑的目的, 也就是要支持业务的开通、维护和计费。传统的网络管理一般是与业务管理相分离的, 这不利于运营商的业务管理:一方面, 网络管理发现的网络问题无法映射为对业务的影响, 从而提前实现业务预警, 通过资源重配置保障业务不受或少受网络故障的影响;另一方面, 业务出现中断时, 无法判断引起业务中断的原因是网络故障还是业务系统故障, 从而进行故障精确定位, 恢复业务。需要将网络管理与业务管理进行融合化, 通过统一建模等技术手段, 对网络与业务进行关联性建模和分析。
融合还指系统融合。传统的OSS体系基本可以认为是一张网一个网管, 随着网络技术的不断发展, 新网络的不断涌现, OSS系统也越来越多, 产品数量越来越多, 产品之间的交叉关系越来越复杂。这给运维工作带来了很大的困难, 主要体现在:运维人员培训成本提高、跨域的资源配置复杂、网管系统间数据一致性问题突出等方面。需要建立统一平台、统一登录、统一数据、统一管理、统一维护的融合性OSS系统, 实现跨域的统一管理;在系统层面, 保证GUI界面、操作风格统一;在数据层面, 通过对全网的统一建模、数据集中存放等方式, 保证数据的一致性。通过规范化接口, 解决前后端系统的数据共享、信息沟通、流程衔接, 打造一个前后贯通、全业务、灵活高效的OSS体系。真正做到全程全网、对重要客户、大客户的客户资料/业务/资源信息的统一管理。同时融合也指将相同或类似的流程或功能尽可能地融合考虑, 屏蔽网络技术差异, 建立完整的流程化管理手段。
三、协同
部门协同:从内部实现前端业务部门和后端支撑部门的协同, 从外部实现体系与外部合作伙伴的协同。
流程协同:灵活和完善的工作流逻辑确保随空间和时间流转的业务能够更自动和更准确地传递, 从横向上实现售前-售中-售后的全流程协同, 从纵向上实现服务协同和资源协同;从而快速地满足客户的多样化需要。
系统协同:网管支撑系统需要以IT系统的方式固化和强化协同服务能力, 支持各领域的管理、控制, 实现跨领域的协同, 进行统一的用户管理, 建立一体化的运维管理体系, 实现信息流、业务流、管理流的顺畅流转, 实现端到端的全程监控、管理和考核。
1、全业务环境下的OSS建设范围
(1) OSS建设覆盖的功能范围
国内运营商所指的OSS系统原本关注电信网络本身的管理、运行和维护, 所以也称为网管支撑系统。传统的OSS基本上都是由运营商内部维护人员使用的, 又称为后端系统。而如今OSS已经响应企业的战略转型目标, OSS的功能边界由主要面向设备、面向网络, 逐步扩展为面向业务、服务、客户、市场和规划。
产品全生命周期管理包括两层意思, 首先是指对产品从开发、上市、增强到退出市场全过程的管理, 其次是指在产品推向市场后, 对客户订购的产品实例在售前、售中、售后全过程进行管理。
(2) 从纵向来看包括:
(1) 完整的产品生命周期管理:包括快速灵活的产品开发上市、高效的产品增强和完善的产品退出管理等;
(2) 完善的运营支持和准备:包括运营的服务支持和准备、运营的资源支持和准备两个方面;
(3) 高效的开通处理:包括快速的开通响应、完善的开通流程、高水平的开通服务等;
(4) 高质量的业务保障:包括健全的例行维护体系、精细化的质量管理体系和快速灵活的故障解决体系。
2、全业务运营对网管支撑能力的突出要求
全业务运营环境下OSS将以客户为中心进行精细化管理, 这包含三个内容:业务开通与保障, 客户满意度和网络运行质量。OSS系统建设的目的始终是为了提高业务效率、增强管理灵活性、降低运营成本。
3、提高面向客户、面向产品的端到端的业务开通能力
在全业务环境下, 伴随着网络的融合和随着客户对捆绑业务的需求不断增长, 开通管理、存量管理和业务激活功能已经超越了单一的业务层面, 需要同时支持跨越多种技术的多项业务开通, 才能最大化地发挥融合网络的优势, 降低产品入市的时间, 推进快速捆绑语音、数据和视频流的一系列全业务产品的创新。
另外, 随着捆绑业务的不断推出, 套餐间的更换或升级也更加频繁, 给业务开通带来了更多的复杂性。
因此需要构建统一的开通平台, 灵活地支持全业务产品的组合开通, 包括前端产品目录和后端资源的统一映射, 售前阶段的资源确认和预占, 售中阶段的及时开通。这需要OSS和前端相关系统共享客户、产品、业务和资源等信息, 并提高端到端业务的自动开通能力, 减少人工干预环节。
构建统一的业务激活平台, 提供集中、统一的网络配置和激活服务, 向网元发送业务开通工单, 实现业务的自动开通激活。同时提供标准化的网络配置接口和业务配置接口, 实现与移动、固网中与开通相关网元的适配, 减少服务开通系统与网络之间的耦合度和相互影响, 并消除各个厂家网络设备在服务配置上的差异性;
加强业务开通整体管控能力, 实现业务间开通流程的有效协同, 支持新业务开通流程的快速定制, 提高开通效率和开通流程的灵活性, 提高业务开通阶段的客户满意度。
4、提高面向客户、面向产品的端到端的业务保障能力
增强业务的集中监控能力, 尤其是集团客户业务监测能力, 实现集团客户业务的端到端性能测试, 充分利用客户、产品、业务和资源等共享信息, 准确地定位故障及其影响的客户和业务, 灵活快速地调度资源修复故障。
增强面向客户的主动保障能力 (如预警) , 与多个专业网管建立统一的接口, 实现主动发现故障, 减少判别时间, 变被动服务为主动服务, 变事后管控为事前管控, 省去客户报修过程的交互时间和对故障的判别时间。
提供面向客户的投诉、咨询、建议、报障等综合性的一站式客户问题受理接口, 提高受理效率, 降低信息沟通成本;实现就近派障, 缩短障碍处理时间。
提供针对不同层面集团客户的不同等级的差异化服务。提供规范的服务质量报告, 有效支持SLA。
加强业务保障整体管控能力, 提高业务保障阶段的客户满意度。
增强快速支持新业务保障流程定制和实施的能力。
5、加强客户自助服务的能力
OSS应该加强和前端系统互相协作, 共同支撑客户通过自助服务终端输入的各种请求, 包括产品的订购、业务的申告、SLA报告的查询、客户信息的修改、服务的预约等, 加强对客户自助服务的支撑能力。
6、加强OSS数据质量管控和分析的能力
当所有的运营商都提供的业务都逐渐趋同之时, 运营商之间的竞争其实也是运营效率和运营成本的比拼。必须加强对网络运营支撑里面最关键的核心数据进行管控, 对客户数据、网络资源数据、故障数据进行质量管控, 提高对数据进行多维度、综合分析的能力, 才能尽最大可能改善网络运营支撑体系, 减少人员, 使得运营支撑更自动化, 使得网络资源实现一体化。
四、结束语
总的来看, 企业战略转型成为OSS建设最根本的驱动力。OSS已经得到了国内各大电信运营企业的高度重视, 并且已经成为企业核心竞争力的组成部分。但是国内OSS与国际先进运营商的OSS仍有较大差距, 在建设过程中还面临不少的技术和管理方面的问题。
比如, 在BSS/OSS/MSS三大体系的建设上缺乏统一的整体规划, 系统建设步伐不一致, 系统之间接口不健全, 数据调用和共享缺乏IT支撑手段。IT系统的灵活性、高效性因为规划不到位、接口不完善等没有发挥出来, 反而在一定程度上成为部门之间信息共享和协同作业的障碍。因此, 要通过OSS和BSS、MSS的全面联动, 才能加快实现信息化与业务的融合, 更好地满足全业务运营的要求。
参考文献
[1]Enhanced Telecom Operations Map (eTOM) For The Information and Communications Services Industry, Release7.5 GB921Version7.3
全业务支撑 篇4
构建绩效管理体系,支撑业务持续发展
构建绩效管理体系,支撑业务持续发展 (中国大学网 ) 常言道，要什么就考什么，考什么就得到什么。在快速成长型民营企业里，当老板感到市场机会特别多，别人能够抓住，而自己却抓不住时，就认为是对人的管理出了问题，于是就期望通过绩效考核来给员工压力，逼出他们的积极性，但效果可想而知。这类企业在绩效管理方面存在如下一个或多个绩效管理的典型问题。 1.高层的绩效管理理念没有得到贯彻。首先，没有明确的指导思想与原则，在考核中倡导一种什么的思想不清晰，或者公司绩效理念与政策没有得到贯彻。其次，绩效考核与战略脱节，绩效指标未能成为战略实施和业绩监控的有效工具。再者，没有建立绩效管理平台。只是停留在绩效考核的理念上，没有上升到绩效管理与改进的阶段，缺少计划、辅导、评价、诊断、改进等绩效管理的过程，没有将考核融入到日常管理过程中，变成了为考核而考核，没有起到改进绩效，提升能力的作用。 2.绩效管理组织不健全。考核的组织机构不够完善。没有明确的考核小组，没有明确考核的组织者及监控审核者。同时，没有建立申诉制度，也没有监控机制，存在制度上的缺陷，难于保证部门之间、部门内部的考核的公平与公正。 3.考核方法设计不科学、不合理。没有与工作计划的结合。除了KPI考核外，通常还要结合工作计划进行考核，否则过程失控，如何保证结果?主要实行扣分制。这是做减法，员工心里不容易接受，认为考核就是惩罚。 4.考核指标设计方法不恰当。一个常见的误区是什么都考。没有区分工作的重点，眉毛胡子一把抓。在指标设计上，往往缺少过程指标。多为结果指标，缺少对过程指标的关注。另外，绩效考核标准模糊，指标缺乏量化，工作成果难于衡量，凭印象考核。指标值设置不合理。某些指标值根本完不成，也就不去关注如何改进了，失去了激励作用。 5.考核运作不规范。前面几个原因导致考核走形式。如果因为客观原因完不成时，考核时可以调整指标值(事后进行)。还有一种情况是鞭打快牛。干得好下一考核周期目标就越高，造成能力强的员工工作上有保留。 6.考核结果没有得到有效运用。没有用于改进工作。没有明确如何针对考核结果进行分析，缺乏绩效改进沟通，没有确定下步工作改进点。考核结果没有有效地运用于培训、职业生涯规划等人力资源管理其他模块当中去。 7.适宜绩效考核的公平公正的文化气氛没有建立起来。 从上面的问题分析可以看出，管理者显然对绩效管理的认识停留在低层次上。大多数这类企业不仅仅是需要绩效考核，更需要的是体现绩效改进思想的绩效管理系统。 绩效管理系统是一种以实现股东及员工价值为驱动力，以关键绩效指标为载体,通过绩效计划、绩效指导、绩效评估、结果运用四大环节实现对各类人员工作绩效的客观衡量、及时监督、有效指导、科学奖惩，从而调动全员积极性以提高公司绩效，创造股东和员工价值的管理系统。它将公司的战略、资源、业务和行动有机地结合起来，是一个完整的管理体系。 绩效管理的方式有很多，比如目标管理、以战略实施为基础的平衡计分卡、以使命愿景为目标的关键结果领域与关键结果指标(简称KRA/KPI法)方法等等。这些方法各有优势，适用于不同管理水平的企业。 对平衡计分卡我就不介绍了，因为市面上有很多这方面的书籍，现在我来介绍一下KRA/KPI法，因为KRA/KPI法在绩效管理的实践中表现出其独特的优势，特别是在提高运营管理能力方面。下面，我想通过一个实际案例来详细介绍KRA/KPI法的设计步骤。 KRA/KPI法是基于使命愿景及战略目标的，其设计思想如图1。 这里主要分析上图右边的部分，即基于战略目标的硬要求。 公司最高决策层如何经营一家企业?他们有何思路?这是我们首先需要明晰的。如何将他们经营企业的思路清晰的表达出来，从而在公司各个层面进行传播并进行压力分解，这里我们将会用到鱼骨图。 公司需要弄清楚到底需要在哪些领域特别关注，即关键结果领域(KRA)，才能不断提升公司的运营管理水平，从而向公司的使命/愿景方向持续地迈进。同时，如何衡量公司在各个关键结果领域上的进展，需要建立一系列的可量化的关键指标体系，即KPI体系。 KRA、KPI组合起来，就形成了鱼骨图(如图2)。需要注意的是，不同公司的鱼骨图各有特点，并不相同。 接下来，我们就要将公司的指标分解到各部门，并结合部门的职责，形成部门的KPI库。见表1。 生产部KPI管理表 KRA KPI 计算公式 收集部门 审核部门 收集周期 考核周期 考核对象 生产管理 准时交货率 准时交付的批次数/总的交付批次数 销售部 总经理 月度 季度 经理、副经理、工序主管 插单及时完成率 插单的按期完成批次数/插单总批次数 销售部 总经理 月度 季度 经理、副经理、工序主管 生产计划完成率 当月按计划完成的生产计划批次数/当月需完成的生产计划总批次数 计划部 主管副总 月度 季度 经理、副经理、工序主管 生产周期 生产时间*此周期的订单款数/本期订单总款数 计划部 主管副总 月度 季度 经理、副经理、工序主管 补投率 补补投次数/总订单数量 计划部 总经理 月度 季度 经理、副经理、工序主管 …… …… …… …… …… ……&, amp;, lt;, B style=mso-bidi-font-weight: normal> …… 品质管理 客户投诉率 (投诉次数-客户误投诉数)/总的交货批数 市场部 总经理 月度 季度 经理、副经理、工序主管 直通率 各工序合格率相乘 品保部 总经理 月度 季度 经理、副经理、工序主管 …… …… …… …… …… …… …… 在此基础上，我们结合公司短期的策略，即年度经营计划，进行年度内的绩效管理。需要说明的是，绩效管理需要组合KPI、支持KPI的工作计划、以及由此产生的.预算，从而形成一套系统化的绩效管理体系：三张管理表，包括KPI绩效计划表、工作计划表、预算表，三者拧到一起(如图3)。 图3：组织、部门KPI、工作计划、预算制定关系图 下面是某家公司的做法： 某公司绩效管理制度摘录： 1. 每年一月五日前,由公司经营层根据公司的KRA和KPI确定本年度主要经营、管理目标和工作计划和预算初稿; 2. 每年一月十日前，各部门根据公司目标、计划和预算初稿，从各部门KPI管理表中选取KPI,并拟定KPI目标值、年度计划、年度预算初稿; 3. 每年一月十五日前,由总经理、主管副总和部门经理一起反复沟通确定公司年度KPI及目标、年度经营计划、年度经营预算以及各部门年度KPI及目标、年度经营计划、年度经营预算。 4. 每年一月二十日前各部门根据年度KPI指标及目标、年度计划和财务预算制定第一月的KPI及目标、工作计划、财务预算。每月上旬设定当月的KPI及目标、工作计划、财务预算。 5. 由于公司业务发展计划的变更，组织结构的调整，市场外部环境的重大变化，或遇到一些不可抗拒因素等非个人主观因素，绩效目标确实难以达到，需要调整的，被评估单位负责人可以向总经理提出书面申请，经批准后，可以进行调整。 通常，对不同层级的人员需要采取不同的管理方式。比如对于中高层采取述职管理、对于其它员工(管理/专业/营销/研发等)采取绩效评估管理。需要说明的是，绩效管理不太适合于一线生产、检验、后勤人员，对他们我们可以采取更加及时的管理方式，比如制定行为规范，并配合管理人员的检查等措施来提高他们的工作成效。 下面是某家公司的做法： 某公司绩效管理制度摘录： ? 中高层述职是对中高层进行绩效管理一种形式，通过计划制定、过程的跟进、述职评估、结果应用四个环节，促进中高层管理人员明确责任，抓住重点，有效落实公司的战略，不断提升组织的绩效。 ? 员工绩效管理是公司对员工进行绩效管理一种形式，通过计划制定、过程的辅导、考核评估、结果应用四个环节，促进员工明确个人责任，抓住工作重点，有效落实部门的计划，不断提升个人的绩效。 对于目标值的确定，我们建议需要同时制定基本目标与挑战目标： 基本目标是公司和部门的业绩在正常情况下应该达到的目标，是被考核者跳一跳可达到的目标，是大多数人(60%-80%)正常发挥情况下可以达到的目标，是与行业平均发展水平相类似的目标。基本目标也是改正工作中明显缺陷后可便可达到的目标。制定基本目标时应参考:部门计划和预算、上期本指标实际值、行业指标、监管指标等。 挑战目标是上级对下级的很高的期望值，是被考核人需要付出超常努力才能达成的目标，一般情况下，在一个组织内部，只有10%-20%的人才能达到挑战目标。 无论是基本目标还是挑战目标，均需要上下级之间充分沟通，协商制定。同时需要从以下两个方面对目标进行检查：由于一个指标可能要几个部门共同承担，要检查不同部门指标的目标值是否一致;要检查上级目标在下级目标中是否得到合理分解。 设计通过各级评审和人员认可后，接下来就是实施了。然而不同的企业实施效果却差异显著。有的公司凭借这套绩效管理体系真正落实了企业战略、并提升了员工的工作积极性，公司业绩大大超过行业平均水平;而个别企业却强差人意，不仅没有达到预期效果，反而造成内部合作更加困难，好人难于在公司生存，企业的政治氛围浓厚，公司业绩停滞不前。所以，在实施过程中，我们要避免关注短期绩效而弱化对长期绩效的持续追求、高层一言堂等问题，同时还要建立信任文化，这样才能减小绩效管理实施的阻力，落实企业战略，真正提升员工及组织的绩效。 绩效管理只能解决一部分管理问题，它不是灵丹妙药，需要各方面的配套措施才能有效地发挥效用。这些配套措施当然也包括高层管理习惯的转变，他需要战胜他自己。正如一位公司老板所说的，一个老板的水平有多高，就决定了一个企业能够发展到多高，我深以为然。
全业务支撑 篇5
接入网建设提出高要求
三网融合下的全业务包括语音、图像、数据等综合多媒体服务, 以及上述各类业务融合创新的新业务, 主要包括了VoIP业务、互联网接入业务、视频业务、IPTV业务、多屏合一互通业务等。目前IPTV、视频业务、宽带接入业务是三网融合竞争的核心领域, 但随着三网融合深入推进, 3D电视、3D游戏、家庭监控、家庭医疗、智能家居控制等创新业务也将不断涌现。IPTV、视频业务和不断涌现的创新业务将对接入带宽、对业务的稳定性和时延、对接入网的多业务承载能力提出了更多的要求。
需要更高的接入带宽
目前家庭全业务承载主要是基于家庭多媒体网关来实现, 通过多媒体网关可实现语音电话、可视电话、高速互联网接入、宽带无线接入、IPTV、网络游戏、远程医疗、家庭监控等各种丰富多彩的业务和应用, 主要业务对接入带宽的需求如表1所示。综合考虑家庭用户多人同时使用的情况, 10M～20 Mbit/s的接入带宽将是目前的主流标准;在中期考虑高清互联网视频、网络游戏等内容应用, 其需要的接入带宽需求为30～50 Mbit/s;长期考虑3D电视、3D游戏等内容应用需要的接入带宽需要达到100M以上。
需要更好的Qo S保证
全业务运营必然是为用户提供类型丰富的业务组合, 以满足不同用户的个性化和多样化需求, 而不同业务对QoS的要求也有所不同 (如表2) 。语音业务对带宽要求不高, 但却对时延和抖动非常敏感, 若时延超过150ms, 就会产生失真、语音断续等现象, 造成用户的语音通信体验效果不佳。视频业务不但对时延抖动敏感, 且对带宽要求较高, 若网络带宽过窄, 网络时延过长, 就会产生数据拥塞, 造成图像出现马赛克甚至停顿;数据业务由于内容越来越丰富引起数据量将越来越大, 对带宽和稳定性的要求也越来越高。因此宽带接入网应具有良好的QoS保证机制, 提供低丢包率、低时延、快速切换的传输, 保证用户体验。
需要对新业务的可靠承载
三网融合对业务创新提供了良好的条件, 随着三网融合的推进和用户需求的不断增加, 各种特色业务将不断涌现。多种业务均通过同一接入网承载, 所以宽带接入网须实现支持多样化创新业务的可靠承载, 否则接入网将面临小规模承载简单数据业务可行, 而在大规划实现多样化、差异化的业务承载时, 面临带宽不够、网络可靠性差、网络安全事故频发等问题。另外随着业务的规模增长, 将会有部分业务的控制点前移到接入网层面实现, 以提升整体网络的运营效率和性能。如随着IPTV业务规模的增长, 为了节省IP城域网带宽, 组播控制点会逐步下移到接入网, 因此接入网设备应支持组播功能, 并支持用户组播请求的快速处理、组播路由的快速收敛。
现有接入网全业务承载乏力
在三网融合的大趋势下, 电信运营商提出了“光进铜退”的战略, 加大了对FTTx的投入, 全国宽带用户的接入带宽将在3～5年内提升10倍以上, 2012年实现大多数城镇用户接入带宽达到100M, 实现所有城市光纤化, 为城市用户提供光速互联网体验。在当前电信运营商大力发展FTTH的大趋势下, 广电运营商接入网络尚存在一定差距。
HFC网络不能实现双向互通
首先广电网络绝大部分是光纤同轴混合网HFC (Hybrid Fiber Coaxial) , 该网络主要由前端、分前端、光节点以及同轴接入部分组成, 同时采用光纤干线、同轴电缆支线和用户配线混合组网。HFC网络只有下行通道, 只能提供单向的广播业务。其业务单一, 既不能承载多媒体交互业务, 也不能有效的管理运营, 无法适应三网融合后的业务运营要求, 因此向双向、互动、高速网络全面升级成为必然的趋势。
接入网改造缺乏统一规划
目前各地网络双向改造缺乏统一规划和前瞻性考虑。各地接入网的双向改造单纯从当前业务发展角度考虑, 仅以当前用户需求、业务发展需求进行网络的改造升级, 造成网络双向改造不彻底。目前仅部分网络完成双向化改造, 并且其接入带宽仍然不足。网络改造要从应对竞争、业务发展方面进行统一规划, 既要在竞争中保持优势地位, 也要充分满足未来全业务发展的需要。
未来全业务竞争将成为必然趋势, 带宽提速、“光进铜退”已经成为共识, 广电运营商也需要建设自己的精品接入网。广电拥有着庞大的HFC接入网络, 而主流的宽带接入技术已达数十种之多, 不同接入技术具有不同的技术特点、适应性和优缺点, 因此广电运营商应因地制宜, 结合业务规划, 权衡考虑网络实际情况从而更好地进行接入网的改造升级。
双向网改四向并进
通过HFC+CMTS覆盖偏远农村/山区等地广人稀区域
HFC+CMTS模式是利用原网络中预留的光纤和无源分配到户的电缆网络组成双向传输系统, 只需要在前端和用户端分别加装CMTS和CM即可实现双向传输。
其优点是利用现有的CATV网络提供双向通信, 大面积广覆盖较好, 低开通率情况下成本较低, 前期投入少。缺点是可承载业务有限, 大带宽业务无法满足, 并且后续系统扩容成本巨大。当用户的带宽需求增加时, 需要投入大量的CMTS设备、光传输设备和光纤资源, 不具备和电信运营商相竞争的能力。
HFC+CMTS模式因具备广覆盖好、前期投入少, 低开通率情况下成本较低等特点, 更适合在偏远农村/山区等地广人稀的区域所采用, 满足此区域用户基本宽带接入的需求。
通过EPON+LAN覆盖对高带宽有需求的新建楼盘/小区、敷设了五类线的区域及未布设Cable接入网络区域
EPON+LAN是在HFC网络的基础上将OLT放置在分前端, 将ONU放置在原来的光节点处, 通过ONU提供以太网接口, 而用户接入通过以太网五类线实现。
它的优点是技术成熟, 设备商较多, 接口和标准规范, 运营商不需要承担用户终端的投入, 并且网络升级改造方便, 可扩充性好。不足之处在于对已经开通有线电视的老用户需要重新进行布线, 而小区楼道和入户布线施工难度大、工作量多、投入成本高, 对维护人员素质要求较高。
EPON+LAN模式因符合网络IP化、宽带化、光纤化的发展趋势, 未来向FTTH可方便升级改造特点, 因此适合在对高带宽有需求的新建楼盘/小区、敷设了五类线的区域及未布设Cable接入网络地区所采用。
通过EPON+EoC模式对现有HFC网络进行双向化改造
EPON+EoC是在现有的HFC网络基础上利用广电网已有的Cable网络作为传输介质, 通过EoC头端将以太网信号合成在同轴电缆中与原有的CATV信号一起传输。在用户家中放置Eo C终端, 用于信号的接收和分离。
其中EoC包括无源EOC、低频有源EOC、高频有源EOC。无源EoC, 其成本低, 但是无法穿透分支分配器, 应用场景受限;高频有源Wi-Fi技术衰耗大, 对同轴电缆的质量要求较高, 应用也不广泛;而低频有源EOC又包含MOCA、HomePNA、HomePlug AV、HomePlug BPL、Wi-Fi降频五种技术 (表3) , 其中MOCA带宽高, 其成本也较高。Home PNA抗干扰性能较差, 使用较少;Wi-Fi降频缺点是对线路要求比较高, 信号衰减大;使用较广泛的是Home Plug AV/BPL技术。Home Plug AV技术完善, 是当前主流的技术, 其成本低, 网络要求低, 技术完善, 可演进到P1901。并且演进方案明确, 芯片供应完善, 市场响应积极。
EoC技术具有良好的适应性和灵活的组网方案, 充分利用了广电原有的同轴接入网资源, 不需重新布线, 入户施工难度非常小, 节省了入户部分的线路投资, 节省驻地网资源。其改造成本最低, 也具备提供高带宽和QoS保证的能力, 因此应作为HFC网络双向化改造的首选组网方案。
通过FTTH实现接入网最终改造目标
全程光纤接入 (FTTH) , 从局端到用户端一根光纤到底, 真正实现了三网融合和接入网的终极目标, 符合“光进铜退”的发展趋势, 但考虑广电现有的丰富同轴电缆资源及光纤接入的成本, 短期内难以大范围普及。
因此广电运营商在采用FTTH时应综合考虑成本收益, 对于新建高档小区、别墅区、高档房产区、商业区可进行试点建设, 同时在经济发达地区、竞争激烈的地区可一步到位直接采取FTTH模式进行接入网改造建设。
全业务支撑 篇6
3G时代, 中国移动面临严峻的全业务竞争格局, 中国移动在现有移动业务的基础上, 还可以运营固话、宽带等其他业务, 为了满足全业务运营的需求, 弥补固话和宽带业务上的短板, 可通过整合铁通在固话、宽带方面的资源, 借助铁通多年来在这些业务领域的运营经验, 快速提升全业务运营的能力。
为了适应全业务竞争的需要, 长远规划业务支撑系统, 移动采用SOA (Service Oriented architecture, 面向服务的架构) 技术对业务支撑系统进行了改造, 并把铁通资源融合进SOA架构, 改造项目以业务支撑系统SOA架构为基础, 进行宽带业务合营和IPPBX固话业务合营, 构建基于SOA架构的一体化服务营销支撑体系。
全业务运营中国移动优劣势分析
全业务竞争环境下中国移动的优势和劣势如下。
网络导向:
优势:具有丰富的移动网络资源, 针对移动网具备先进的运维服务水平。
劣势:对固网、宽带业务的受理, 维护和故障处理缺乏资源与经验。
业务导向:
优势:对个人客户进行了区分, 产品线丰富, 新业务开发能力强。
劣势:对面向政企、家庭的宽带和固话的业务产品开发及维护能力有待提高。
根据以上全业务运营中国移动的优劣势分析, 中国移动的全业务运维模式为:整合铁通在固话、宽带方面的资源, 借力铁通多年来在这些业务领域的运营经验来补齐中国移动在固话和宽带业务上的短板。
技术方案研究
(1) 业务支撑系统采用SOA架构
采用SOA技术对业务支撑系统进行改造, 构建Web2.0和多渠道整合、统一认证权限服务、服务封装、流程引擎、规则引擎、信息服务、企业服务总线、接入服务等8个基础技术能力的SOA架构。并对CRM、BOSS、经分、PBOSS、铁通Radius、铁通汇聚局话单生成、铁通施工等系统可重用的模块进行封装, 形成可调用的服务。各业务系统基于SOA架构之上, 通过调用基础服务模块, 构建全业务的竞争体系, 支撑个人、家庭、集团业务的竞争。如图1所示。
(2) 技术实现方案
(1) 宽带业务合营情况
宽带业务组网 (如图2) :
通过双方省公司之间专用通道的建设, 实现移动传输网与铁通传输网的贯通, 为宽带业务联合运营提供了网络基础。移动提供GPON网络, 接入铁通的Radius设备实现宽带业务的统一认证计费能力。
业务支撑系统通过调用SOA架构中CRM能力复用、BOSS计费能力复用、PBOSS服务保障及资源管理能力复用、铁通施工、铁通radius实现对宽带业务的支撑功能。
宽带典型处理流程:
移动主要实现宽带业务的受理、订单流程调度及账务信控处理;铁通主要负责外线施工及服务保障, 并提供宽带指令处理接口。
宽带业务联合运营支撑的关键能力:
充分发挥NGBOSS系统支撑能力, 通过接口打通、流程贯穿手段实现与铁通系统能力贯通, 实现宽带业务的全流程支撑, 快速补齐有线宽带业务运营支撑的短板, 助力联合运营的宽带业务发展。
(2) 固话业务合营情况IP-PBX固话业务组网:
通过移动传输网与铁通传输网的贯通, 为固话业务联合运营提供了网络基础。
采用铁通固话号码, 由移动IPPBX发起固话业务, 通过铁通汇接局出局, 实现固话业务合营。
业务支撑系统通过调用SOA架构中CRM能力复用、BOSS计费能力复用、PBOSS服务保障及资源管理能力复用、铁通施工、话单生成实现对IP-PBX固话业务的支撑功能。
IP-PBX业务售前、售中、售后支撑流程:
通过CRM和BOSS的改造, 打通与铁通的施工开通流程及计费流程, 实现售前、售中、售后的全流程支撑。移动主要实现IP-PBX业务的受理、订单流程调度及计费、账务信控处理;铁通主要负责外线施工及服务保障, 并提供IP-PBX服务开通指令、话单采集接口。
IP-PBX固话业务联合运营支撑的关键能力:
充分发挥NGBOSS系统支撑能力, 通过接口打通、流程贯穿手段实现与铁通系统能力贯通, 实现固话业务的全流程支撑, 快速补齐有线固话业务运营支撑的短板, 助力联合运营的业务发展。
中国移动通过与铁通公司联合运营支撑了宽带及固话的业务开展, 迅速补齐中国移动的业务运营短板;全面满足集团和个人全业务支撑需求, 使中国移动迅速成为一家名副其实的全业务运营商。
总结
通过完善中国移动现有NGBOSS的营销服务能力, 支撑宽带、固话与移动已有产品的捆绑, 以及加快全业务融合产品推出, 中国移动加大了市场业务的推广力度, 有力提升了市场竞争力, 改善了客户感知, 提升了服务效率。
全业务支撑 篇7
面对全业务运营和网络的融合，宽带作为融合的核心，已经成为全业务竞争的焦点。宽带数据业务已成为各大运营商的业务收入最重要的增长点之一。基于宽带的新业务不断地推出，宽带用户数一直保持较高速的增长，并导致宽带业务的快速发展。由此，中国移动明确了积极进入宽带市场的竞争策略。因此，要快速形成宽带业务部署能力，中国移动必须立即开始开发宽带业务支撑系统。
本文重点探讨了中国移动福建公司宽带业务的支撑策略与方案。
1 宽带支撑现状
宽带业务是中国移动业务运营和支撑的薄弱环节，竞争对手在此有着多年投资积累的网络资源基础和丰富的运营经验，是竞争对手最强的业务之一。目前中国移动福建公司已部分开展的集团专线(宽带)业务，基本采用包月方式进行计费，使用手工或者简单信息系统管理的方式进行数据管理，缺少专门的宽带业务支撑系统的支撑。存在业务单一、数据分散、效率低下等各种问题。这种情况将无法满足今后大规模开展的家庭小区宽带业务要求的灵活的计费方式、高效的用户权限认证、综合业务捆绑销售等要求。
随着铁通公司与中国移动的融合，须考虑铁通宽带与移动宽带的整合。福建铁通宽带用户全省共有20万家庭个人用户，使用ADSL方式接入。为了满足宽带业务的受理、收费、配线需要，铁通分地市开发了“地市宽带业务管理系统”，主要功能包括宽带业务的受理、收费(只能包年收费)、号线管理等功能。功能简单，系统分散，系统缺乏整体规划，支撑系统之间缺乏有效衔接，在中国移动与铁通宽带业务合作模式未确定的情况下，不适合在铁通原系统架构上做进一步发展，必须要新建自有宽带业务支撑系统。
2 支撑策略
按照综合业务支撑的方案，宽带业务将与传统语音业务或其他业务捆绑成新的产品套餐。参考其他电信运营商的建设经验，宽带支撑系统已经逐步从独立系统向综合支撑系统融合，不适合建设与现有业务支撑系统 (BOSS) 完全独立的宽带支撑系统。因此，在现有移动业务支撑能力的基础上，遵循中国移动下一代支撑网 (NGBOSS) 总体技术体系规划，确定中国移动福建公司宽带业务支撑系统的技术框架，将宽带支撑功能融入BOSS系统中。对BOSS系统功能模块进行改造，使之具备宽带业务支撑功能，这样将便于后续多种业务融合支撑。
而且，这种模式将有利于今后宽带与语音等其他业务捆绑营销，融合计费与综合账务处理，有利于综合业务的灵活支撑。也有利于充分利用现有BOSS系统硬件与软件资源，缩短开发周期，尽快实现宽带业务支撑，初步形成融合计费、多业务管理的支撑能力。
3 支撑功能分析
宽带业务的接入方案主要有LAN、ADSL和WLAN方式，计费方式主要有包月、限时+超时计费、限流量+超流量计费、上网卡限时等方式，系统要求灵活的费率，可提供针对用户类型、时段等的不同费率政策和优惠措施。而且，要满足宽带用户申请和日常使用要求，宽带业务的主要支撑功能还必须包括宽带用户注册和管理、用户权限认证和控制、宽带费用计算、宽带账务处理、宽带资源管理等主要功能。并且，应采用全省集中的认证计费体系采用集中认证、统一计费的方式管理业务，便于系统的快速部署与管理。
4 系统方案
继承业务支撑系统分层结构的思想，结合业务支撑系统多年来的最佳实践，，宽带业务支撑系统结构设计遵循以下原则：
(1) 可复用原则：系统核心由一系列服务组成，服务又由一个或多个组件构成，组件的粒度满足高可复用性要求。
(2) 可扩展原则：系统结构可以按层次进行分布式部署，提高系统可扩展性。
(3) 流程与服务分离原则：将流程与服务实现进行分离，提高系统的灵活性和快速部署能力。
根据以上原则，宽带业务支撑系统结构分为接入层、业务层、数据层，如图1所示。
(1) 接入层是宽带支撑系统与外部进行数据交换的平台，由接入逻辑构成。对于系统使用者，提供多样化的集成逻辑，实现对业务逻辑的共享。
(2) 业务层是宽带支撑系统业务处理的逻辑平台，它通过对数据访问子层的调用访问业务数据，实现不同的功能模块，满足不同的业务需求。业务层由若干业务流程组成，通过调用业务组件，为接入层提供业务服务，实现业务逻辑的共享，完成相应的业务功能。
(3) 数据层是宽带支撑系统对业务数据进行统一组织、集中管理的平台，它通过数据访问子层为业务层提供规范、高效的数据服务，实现业务数据的充分共享，是整个宽带支撑系统的基础。
宽带业务支撑系统主要涉及到对系统中的如下部分进行建设：综合采集子系统、统一预处理子系统、综合计费子系统、综合帐务子系统、营销与服务平台：
(1) 综合采集子系统：实现宽带帐号使用计费记录的采集、码制转换、错单剔除、重单检查、数据分发与入库处理，实现上网话单从网元采集到支撑系统，并进行初步处理。
(2) 统一预处理系统主要功能模块包括数据接收、格式化、话单分析、数据分发、异常处理、监控等6个功能模块，主要接收来自采集系统的话单文件，根据可配置的分析规则，结合基础资料信息，完成对路由、号码、处理类型的分析，在话单分析过程中规范话单字段信息、加插后续系统业务分析处理过程所需的必要的基础信息，并根据数据源，对包含多种业务的话单文件按业务代码进行分业务的话单文件分拆。并且，对格式化、话单分析、数据分发等模块产生的异常话单进行回收处理;对异常情况下需要冲销、补处理、回退的话单可进行相应冲销、补处理、回退操作。该模块的回收、冲销、补处理、回退均具有人工和自动模式的选择或组合。
(3) 综合计费系统：综合计费系统主要功能模块包括数据接收、批价、数据分发、异常处理、监控等五个功能模块。接收来自统一预处理系统的计费话单文件，对话单完成批价前的分析准备，包括帐期分析、超频等步骤;再根据业务批价规则，对正常计费话单进行批价要素分析后匹配相应费率，完成对话单的标准批价，对套餐用户的话单按套餐资费标准进行批价以供参考或分析所用;可根据设置的高额预置标识高额清单，生成业务清单文件。
(4) 综合账务平台：实现对综合计费系统的计费后话单的合帐处理，生产汇总账单与明细账单，并根据用户账本余额信息，进行销账处理，按照手机用户的新业务套餐方式进行账务管理和处理;按手机用户方式处理月固定套餐费用。如图2所示。
(5) 营销与服务平台：包括业务受理、客户服务、订单管理、用户管理、资源管理、投诉建议模块。实现宽带业务开通、宽带密码变更、宽带用户资料查询、宽带用户状态查询功能;宽带用户管理、投诉等功能，并且，与宽带计费认证系统(Radius)进行实时接口交互，实现用户资料、状态更新。如图3所示。
全业务支撑 篇8
电信业务支撑系统因其承载着企业的战略目标实现企业的基本生产功能, 而成为企业的生产线和生命线。随着电信市场竞争的加剧和服务水平的提升电信用户对于业务支撑系统的支撑能力和体验感知的要求不断提升, 业务支撑系统、电信产品的用户用户体验结果又直接影响了产品的销售及推广, 影响到企业的经济效益。
运营商对用户体验的重视程度和需求的提升, 必然对业务支撑系统的研发提出了更高要求, 因此, 需要在传统的测试方法、技术基础上进行深入研究, 改进和完善新时期的测评方法, 以适应深层次的用户体验监测需求。
随着用户数和业务的增长, 业务支撑系统的业务越来越复杂, 操作复杂性日渐增加, 在资源不增加的情况下业务性能势必不断下降。同时, 由于用户使用习惯、业务特性等因素, 在月底月初业务忙时、系统压力大的情况下, 容易产生系统白屏、菜单打开缓慢、多次提交报错等问题, 致使业务办理平均时长拉长, 内外部用户用户感知均会受到一定程度的影响。当前业务支撑系统性能优化和管理存在的问题主要包括:
(1) 后台系统的运维指标不能直接反映用户的真实体验
面对规模庞大的IT系统和繁重的支撑任务, 业务支撑部门尽最大努力以确保系统的稳定高效运行但用户投诉仍然不断增加。通过与用户直接沟通, 发现用户的问题往往很难与后台系统的运维指标划等号。换言之, 资源的繁忙程度与用户感受到的系统快慢并没有直接联系, 业务功能的正确性与用户感受的系统友好度并没有直接联系。因此, 仅抓好后台系统的KPI显然不能满足用户的真实需求。
(2) 传统的问题处理方式往往影响用户感知的事后处理方式
随着用户规模的激增和业务复杂度的提高, 影响用户用户感知的问题越来越难以通过后台系统的运维KPI及时体现出来, 往往需要问题影响范围积累到一定程度时才能引起足够的重视, 但这时已经无法挽回受到较大规模影响的用户体验, 企业对问题的响应非常被动。
(3) 获取问题现场困难 , 对用户感受到的问题没有直观的认识
用户投诉问题时往往很难在短时间内把问题描述清楚, 这不仅增加了查证问题的难度, 甚至有时难以引起业务支撑人员的重视。在处理问题时, 很难获取用户的问题现场, 常常需要逐个电话回访, 导致问题的定位和处理效率较低。
(4) 难以回溯、分析问题的深层次原因
由于庞大的业务系统涉及的环节繁多复杂, 并且缺乏对问题现场的追踪和深层次挖掘能力, 传统的运维方式难以在问题发生后进行细致的回溯和分析, 难以从根本上解决问题。
针对上述问题, 某电信企业积极研究实现基于用户体验的对业务支撑系统的实时业务监测, 在实时掌握用户用户真实体验数据的基础上, 进一步与主动服务、系统优化结合起来, 以提高业务质量精细管理和问题处理效率, 最终达到提升用户满意度的目的。
2 用户体验体系与业务监测的研究
(1) 用户体验的五个层次
用户体验要素可以划分为五个层次: 战略层、范围层、结构层、框架层、表现层。
1) 战略层:产品价值观及目标用户定位。成功用户体验的基础是一个被明确表达的“价值”。清晰定义企业与用户对产品的期许和目标, 有助于制定用户体验的各方面策略。
2) 范围层:用户需求与功能说明。进一步落地、展现产品价值和用户需求, 将其转述为产品应该提供给用户什么样的内容和功能。
3) 结构层:体系结构与交互设计。在收集完用户需求并定义其功能后, 最终展现的图像已经具备基本骨骼。但是, 这些结构还是零散放置的, 并未形成完整的视图。
4) 框架层 :界面设计、信息设计。进一步提炼结构, 细化交互设计, 确定详细的界面外观、导航和信息设计。
5) 表现层:视觉效果展示。实现产品的最终展示, 产品成型。
良好的用户体验涵盖了有用性、可找到性、可获得性、满意度、可靠性等元素。易用性、性能和可靠性成为衡量业务支撑系统用户体验好坏的三大重要指标。为及时了解用户体验情况, 基于用户体验的业务监测成为必不可少的重要评估手段。
(2) 基于用户体验的业务监测
为了监控、管理业务运营质量和用户用户服务感知, 某电信企业上线了业务监测平台。业务监测平台通过多种探测方式 (业务主动探测、被动监听、业务日志等) , 获得包含多种渠道的用户用户服务感知数据 (包括各地市实体厅、合作厅、客服IVR、短厅、网厅等渠道, 包括查询类、受理类、空中充值等业务类型) 。
业务监测平台实现了多项突破:自下而上建立多维分层指标体系, 建立用户用户感知评估能力。该指标体系打破了原有运营质量指标体系构建模式, 拓展了用户感知的量化探知标准, 创新性地从设备层、业务层、用户层自下而上地构建了各渠道运营质量监控的分层多维指标体系。包含系统运营、业务运营和用户用户感知三个维度, 以及50余项指标和多种监控方法, 具有客观性、可比性、全面性等特点。通过多种探测方式, 建立全省集中业务监测平台, 实现端到端的全流程用户用户感知探测。同时, 该平台具有统一可扩展的服务模拟架构, 实现了分布式、跨地市的服务模拟, 并通过开放的接口, 易于与第三方系统有机结合;通过流程化的服务模拟定义, 实现了探测业务的快速部署;通过界面良好、准确迅速的信息传递, 完成了对业务服务质量的预警、分析和管理。最后, 通过获取多维探测数据进行分析与建模, 对影响用户用户感知的因素进行螺旋式优化和提升, 实现了用户用户感知质量的闭环管理。
业务监测平台彻底改变了用户用户服务质量数据被动获取, 依赖用户投诉、反映的纯平台层面的监管模式, 通过主动性的用户感知分析、预警和处理, 定位问题和处理更加准确、及时, 营业厅服务质量进一步提升, 用户用户满意度也有了很大提高。
3 解决方案
3.1 业务监测平台功能架构
业务监测平台的功能架构 (图1) 包括数据层、探测层、服务层和展现层四部分。数据层指所包括的监测的各类渠道的业务;探测层是各渠道监测点和相关代理服务的部署;服务层主要是探测的调度和数据采集的功能;展现层是将业务监测的相关数据的实时展现。
3.2 业务监测平台监测方法
基于应用性能管理能力的五个功能维度, 设计多角度的监测和评估方法。五个功能维度主要包括:终端用户体验、业务交易剖析、应用组件发现及建模、基于上下文的应用组件深潜、应用性能数据管理及分析。其中, 终端用户体验是指从终端用户角度出发, 关心各项交易的端到端时间;业务交易剖析是指帮助缩小问题范围, 细分交易在每一环节上的消耗;应用组件发现及建模是指掌握交易全貌, 包括交易涉及到的各个组件;基于上下文的应用组件深潜是指对具体组件进行剖析, 深入到代码级别发现根本原因;应用性能数据管理及分析是指关联前四个维度的数据, 协同发挥应用性能管理最大作用。
从探测方式上, 可以分为主动式最终用户检测和被动式真实用户监测。
(1) 主动式最终用户检测
利用分布在不同运营商和地域的计算机, 通过事先定义好的测试页面 / 交易、测试频率、测试地点主动访问目标页面进行性能探测。通过对分公司各核心营业厅关键业务进行模拟探测, 监控业务可用性和性能。
主动式最终用户检测主要通过主动发起用户使用请求, 实现从用户视角进行的端到端业务性能测试, 探测事务的响应时间和业务的可用性, 从而分析业务的性能趋势。
(2) 被动式真实用户监测
被动式真实用户监测利用的是真实用户的访问来采集性能数据。被动式监测从监测样本采集点的位置来区分, 包括用户用户端监测和服务器端监测两种。用户用户端监测是从最终用户终端上采集性能数据, 一般通过在内部业务系统插入Agent方式来获得业务系统性能;服务器端检测是利用部署在数据中心端的探测设备, 采用旁路监听的方式持续收集来自网络交换机的业务交互数据, 对用户请求流量进行分析, 记录所有用户的应用及交易。
3.3 业务监测平台部署
业务监测平台, 模拟用户通过用户用户端与服务器进行底层交互, 通过设定事务和操作检查点, 来获取执行事务的执行时间和成功失败结果;通过实现搭建业务探测服务器, 部署各地市探测终端设备, 其物理部署图如图2所示。
4 应用效果
4.1 业务监测平台实施效果
(1) 量化服务质量指标
传统的指标量化方式, 是以面向服务和运营商为主的, 以系统设备层为入口, 向业务层延伸。业务监测平台依据价值链理论, 在指标量化的过程中, 改为以用户感知为入口, 进一步制定用户感知的服务级别针对不同级别的感知质量进行预警和主动关怀, 然后继续向业务层关联、向设备层延展, 将业务参数进行逐级量化, 并将业务指标、服务指标和系统指标进行关联分析, 将业务参数解释为设备机制能力理解和实现的参数, 进行表达和实现, 进而将服务提供能力与企业成本投资 (设备利用率等) 挂钩, 大幅度提升了指标量化后实施的可操作性。
(2) 准确计算用户访问业务成功率
通过业务监测平台, 可以获得各业务的Web站点错误、服务器错误、网络错误、内容错误等方面的详细数据。
(3) 建立业务访问的时延
通过业务监测平台, 可以获得各业务详细的访问时延数据, 即该业务在指定时间段内的平均响应时延。
(4) 数字化评价业务质量
借助业务监测平台海量实时的用户体验监控数据, 不仅能掌握业务访问的时延数据, 还可获得详细的用户信息, 如IP、用户ID等, 从而更细致地对不同地区、不同用户群进行分析, 通过考察业务响应时延分布在2秒、5秒、8秒等区间的概率, 来获得更加详细的业务质量评价。
4.2 业务监测平台应用案例
(1) 应用案例一:BOSS系统页面优化
通过用户体验质量指标体系的纵横分析, 可以发现页面调用次数过高、CAB文件对象过大、JSP加载时长过长、无效对象 / 图标链接、某对象报错等情况, 虽然不一定产生投诉, 却会影响用户打开BOSS系统页面的速度和感知。业务监测平台定期针对各项的TOP5进行持续优化, 极大提升了用户体验和使用感知。如图3所示。
(2) 应用案例二:全省业务监管地图
如图4所示, 通过业务监管地图, 可以清晰地看出目前地市业务办理状况, 是否有异常发生。如有异常, 可以通过钻取方式, 获得异常的明细数据, 如图所示。
5 结束语
通过对基于用户体验的业务支撑系统业务监控的研究, 构建了业务支撑系统业务监测的方法, 建立了业务监测平台。通过业务监测平台实时对业务支撑系统运行情况的监测, 针对故障、问题, 做到了提前发现、准确定位、快速排除;针对用户感知, 做到了提前发现用户不良感知、提前应对优化、及时给用户反馈挽回用户并带来良好感知。从而使业务支撑系统性能的满意度得到大幅度提高, 业务办理成功率大幅度提高, 营业厅忙时满意度大幅度提高, 客服中心忙时处理满意度大幅度提高。
摘要：本文从电信行业用户体验入手, 分析了运营商业务支撑系统的用户体验需求, 提出并探讨了电信行业用户体验测评体系及测评方法, 结合实例说明了用户体验监测方法在业务支撑系统中的实际应用。
关键词：业务支撑系统,业务监测,用户体验
参考文献
[1] (美) 特里斯 (美) 阿伯特著.用户体验度量.周荣刚等译.北京:机械工业出版社, 2009
全业务支撑 篇9
日益激烈的市场竞争和不断提高的客户服务质量需求对业务支撑系统 (简称:BOSS系统) 业务支撑能力和可靠稳定运行的要求越来越高, 从面向客户服务的角度而言, 需要中国移动提供不间断的业务支撑服务, 以保证客户满意度、客户服务质量等不受影响, 增强企业竞争力。
2009年期间, 由于数据库故障、生产机房网络故障等原因, 造成广西BOSS系统当年累计退服时长达近20个小时、故障期间因无法缴费、充值后无法开机等问题造成的用户投诉/抱怨工单件数共5000多件, 严重影响了本地客户的满意度和使用感知。由于数据库故障和网络故障等突发性问题可控度不高, 因此如何降低故障处理期间对用户的影响、更进一步地考虑实现故障期间系统不中断运行, 成为广西公司业务发展和客户满意度提升工作面临的一项紧迫任务。
2 研究思路
根据广西公司运营支撑水平的实际情况, 采用关键业务应急的方案, 建设一个覆盖BOSS系统各主要业务受理渠道 (包括:营业前台、短信厅、网厅、客服系统、IVR充值等) 关键业务的应急系统。当BOSS系统出现重大故障的情况下, 应急系统对外提供各类关键业务的受理, 确保业务服务连续性, 满足客户最迫切的业务需求。
由于涉及较多渠道和系统, 切换环节众多, 手工切换时间较长, 而且存在人为误操作的风险, 为了达到快速切换和减少人为操作风险的目的, 应急系统提供应急切换统一操作管理平台, 提供自动快速的应用切换手段, 缩短服务重启等耗时长的操作时间。
用户在应急系统办理业务, 使用的是生产系统同步过来的数据, 并且在应急系统办理的业务数据, 在生产系统恢复正常后, 同步回生产系统, 保证用户在生产系统中正常的办理业务和使用服务。因此必须保证应急系统和生产系统之间的数据同步, 采取有效手段保障两个系统之间的数据一致性, 从而保证业务受理和数据的准确性。
3 建设方案
3.1 系统部署
广西生产中心和应急中心的双中心体系采用同城异址的建设方式、保证了硬件设备的独立性, 生产中心部署生产设备, 容灾中心部署应急设备, 保证灾害或故障发生时系统冗余可用。其中生产中心设在608第三机房、容灾中心设在608第二机房。
根据广西公司的实际情况, 当前广西公司应急系统硬件配置约为生产系统的1/2、业务承载能力约为生产系统的1/2, 性能足够支撑当前应急系统中提供的关键业务。
应急系统部署分为三层结构:
(1) 客户端:生产系统和应急系统的客户端的PC机是共享的。应急系统和生产系统之间的切换, 通过F5的请求指向修改来完成。在启动应急系统时, 营业员只需要通过统一的URL重新登录即可。
(2) 应用服务器:生产系统的WEB服务和中间件服务部署在生产中心主机上, 应急系统的WEB服务和中间件服务部署在容灾主机上。生产系统和应急系统的切换/回切通过F5实现。当BOSS系统出现故障时, 通过F5将前台业务请求接入到应急系统。生产系统恢复正常后, 通过F5进行回切, 将请求发送到生产系统。
(3) DB层:应急系统使用的是生产系统的克隆库, 克隆库与生产库是互相独立的。应急系统数据同步采用DSG方式从生产库中同步至应急库。
3.2 体系架构
广西生产系统及应急系统逻辑架构相同、部署的应用程序一致, 减少了程序部署和系统升级的复杂度、也保证了应急系统的可用性。应急系统采用B/S结构的处理方式。首先采用B/S结构的业务受理界面, 是BOSS系统设计的主流发展方向, 可以方便系统的升级, 利用前台用户的使用, 收敛后台的业务流程等优点;其次, 采用B/S结构, 使得生产系统与应急系统的受理界面互不影响, 便于快速实现系统的切换, 也避免了对现有前台营业受理界面修改对系统的影响。
BOSS应急系统架构可以分为三层结构, 分别为接入层、业务层、数据层。
(1) 接入层:跟用户接触的各个渠道的接入方式, 包括:营业厅WEB方式接入、网厅、IVR自动语音充值管理平台接入等。
(2) 业务逻辑层:进行各种业务操作和业务规则处理。采用组件技术实现, 将所有的业务逻辑都封装在组件中, 并利用组件提供业务服务。
(3) 数据层:主要功能是存储核心数据, 包括用户资料数据、卡资源数据、号码资源数据等。
3.3 系统功能
应急系统功能包括两大部分:应急系统管理和应急业务受理。
1) 应急系统管理:包括应急切换控制、应急系统初始化、应急业务数据恢复等功能。
(1) 应急切换控制:包括应急自动切换平台和应急切换后台控制。
i.应急自动切换平台:对整个应急切换操作进行了整合, 实现全自动化应急系统应用切换与回切, 有效避免了人为误操作的风险;并设计了申请、审批两级操作流程, 操作人员和管理人员能通过平台进行切换操作管理。切换的时候生成前台切换通知, 告知操作员启用应急系统, 并提示能办理哪些业务;当从应急系统回切到生产系统时, 告知系统已经恢复正常, 可正常办理业务。
ii.应急切换后台控制:控制营业前台、各渠道系统和接口连接到应急系统还是生产系统。后台自动切换功能采用切换消息发布服务器+切换消息接收代理进程模式实现, 有效降低自动切换平台的复杂度。将应用程序的实际切换操作封装成可执行脚本、仍放置在应用主机上, 相应地在应急主机部署了一套切换代理进程, 由代理进程解析切换请求、调用执行脚本完成实际切换操作。
(2) 应急系统初始化:应急系统使用的数据库是BC复制库, 每天凌晨会全量备份并覆盖应急系统数据库中的数据, 然后通过DSG增量同步定时同步生产系统和应急系统的数据, 由于应急系统与生产系统在业务控制的细节上的差异, 所以, 每次同步完成后应急数据库中的数据还不能直接用于应急系统, 要进行一些数据上的清理与准备工作。
(3) 应急业务数据恢复:针对在应急系统受理的业务, 在BOSS系统恢复正常后, 自动同步受理的业务数据到生产系统。
2) 应急业务受理:由于业务支撑系统中各个系统以及外围系统的关联性, 要实现对应急系统的业务受理和服务功能使用, 除了受理业务的各个渠道要进行业务受理功能改造外, 相关的后台 (如计费、开通) 和外围系统 (如充值卡平台) 也需要进行相关的改造。主要改造的系统和功能如下:
(1) 受理渠道改造
各受理渠道要实现对应急系统的改造, 一方面需要支持实时读取应急切换标记, 另一方面需要修改系统内部业务受理的实现模式, 将跨子系统或跨库等跳出自身系统范围内的功能调用都改造成不执行实际调用, 仅保存数据在应急数据库中, 待生产系统恢复正常之后进行数据恢复时再执行实际外部系统接口调用;同时, 还需要提供生产系统恢复正常之后的数据恢复方式, 并保证数据正确性与生产系统正常受理结果一致。下面列出具体改造点:
i.实时读取应急切换标记
通过应急控制平台界面进行切换时, 应急控制系统向受理渠道发送应急切换标记, 受理渠道要能及时获取, 并切换到应急状态;实现方式可以为socket或中间件接口, 由应急控制平台连接或调用。
ii.调用跨库跨系统接口逻辑修改
当应急标记切换之后, 受理渠道内部业务受理逻辑进行修改, 以适应应急系统的软、硬件环境。
iii.数据恢复的实现
受理渠道提供生产系统恢复正常之后, 应急期间办理的业务恢复手段, 同时提供稽核恢复数据正确性的手段。
在生产系统恢复正常后, 需要把应急系统受理的业务数据以业务办理当时场景的信息恢复到生产系统。应急系统的数据恢复, 是一个后台进程 (多线程) , 恢复进程启动后, 会按受理时间顺序检索应急工单主表所受理的业务记录, 并根据业务类型, 去相关的业务记录表中获取业务数据, 再分别调用生产系统中的对应的后台服务, 将应急业务的业务数据送给生产系统的后台受理服务接口中, 由生产系统的后台受理完成应急业务在生产系统中的再受理过程, 从而保证数据正确性与生产系统正常受理结果一致。通过生产环境执行业务受理过程, 对应的用户编号、工单编号等通过序列号产生器产生的编号存在不相同的情况, 相同的情况机率也非常小, 避免了将应急系统数据库相关序列号值同步到生产环境的问题。
为了缩短业务中断的时间, 应急系统回切回生产系统后, 应急系统办理业务的数据恢复回生产系统的同时, 生产系统对外提供业务办理, 应急业务数据恢复完成前, 在应急系统办理过业务的用户不能在生产系统办理业务, 以保证数据的一致性。
(2) 相关系统改造
i.充值卡平台
当应急系统启动时, 充值卡平台需要将原来BOSS生产系统提供的调用接口, 转发到BOSS应急系统提供的调用接口, 完成充值流程。
ii.统一开通平台
统一开通平台与应急系统走接口表的方式, 应急系统把需要开通的记录插入接口表中, 由统一开通平台负责后续的开通指令拼装和发送, 并回写开通结果到接口表, 不需要与应急系统程序进行交互, 直接由统一开通平台读取接口表数据。具体接口表的字段或格式与生产系统类似。
统一开通平台在完成开通操作之后, 根据HLR的结果, 将开通处理结果回写到接口表中, 应急系统调度进程定时读取接口表开通结果, 更新应急受理工单状态。
iii.计费平台
应急系统新装开户完成之后, 需要将新用户资料上发给计费平台, 计费平台与应急系统走接口表的方式实现数据交互, 应急系统在完成开户受理之后, 将新的用户资料插入到接口表中, 计费平台定时从接口表获取新的用户资料到应急MDB系统进行计费, 避免出现用户高额欠费等问题。另外, 其它如产品变更、计划变更等与计费相关的资料上发规则处理原则一致。
4 应用效果
应急系统建设完成后, 根据集团公司《业务支撑网应急保障管理办法》要求, 广西公司定期进行应急系统切换的应急演练。演练按照各个流程进行操作, 演练的结果达到了预期的目的:
(1) 应急系统和生产系统之间的切换/回切, 通过应急调度管理界面进行切换, 后台通过F5的请求指向修改来完成, 各个受理渠道的切换过程可以在10分钟之内完成, 较好的保证了BOSS重要业务受理的连续性。
(2) 在应急系统受理的缴费、停开机等涉及HLR开通的业务, 能实时发送到开通系统和HLR, 处理效率跟生产系统相比没有明显降低。
(3) 当生产系统恢复正常, 从应急系统切换回生产系统后, 把应急系统受理的业务数据以业务办理当时场景的信息恢复到生产系统。通过后台进程 (多线程) 进行生产系统数据恢复, 在恢复过程中, 在应急系统办理过业务的用户暂时限制在生产系统办理业务, 对其它用户则没有影响, 因此一旦应急系统回切到生产系统后, 即可正常为用户办理业务, 对业务连续性起到了较好的保障。
(4) 应急系统回切回生产系统后, 在生产系统恢复正常并且数据恢复完成后, 经过稽核, 生产系统和应急系统的数据一致, 确保了应急业务受理的数据一致性要求。
5 小结和展望
中国移动广西公司通过建设BOSS应急系统, 实现了当BOSS系统出现重大故障时, 能够快速切换到应急系统, 在各个渠道提供关键业务的受理, 提升了BOSS系统重要业务的服务连续性, 对提升客户服务满意度起到良好的效果。
下一步将考虑扩大应急系统业务受理的范围, 并且通过技术手段对应急调度自动切换的功能进行优化, 进一步缩短应急切换及回切环节的耗时, 同时考虑将应急后台自动切换的关键步骤及流程展现在应急自动切换平台界面上, 有助于操作及管理人员实时监控后台切换管理过程, 对切换过程中的异常情况及时发现处理。
参考文献
[1]中国移动通信有限公司《业务支撑网应急保障管理办法1.0.0》, 2010年11月