业务需求质量控制QC小组-提高数据业务受理成功率.doc

中国移动通信集团上海有限公司 计 费 信 息 中 心 应 用 系 统 开 发 部 业 务 需 求 质 量 控 制 Q C 小 组2010年 1月 一、 小组概况随着移动通信语音市场的日趋成熟与饱和, 数据业务成为各运营商力争的领域。 面对数 据业务层出不穷的情况, 客户不断要求提升服务质量的现状下, 若能有效提高数据业务受理 成功率, 在相同时间内将能为更多的客户提供高质量的服务, 对提升客户满意度将起到显著 的推动作用。为此我们小组以 提高数据业务受理成功率 作为本次 QC 活动的课题。表 1-1小组概况表: 业务需求质量控制 QC 小组全由一线员工组成,具备长期的开发维护经验, 2008年 3月 QC 小组成立以来,小组不断地进行技术攻关和改进。 2009年,小组开展 QC 活动“降低业务 派单时间”成效显著,获得了 2009年上海市优秀质量管理小组称号。 图 1-1移动业务处理流程图: 二、 术语解释: 数据业务 :是运营商在基本业务(话音业务的基础上,针对不同的用户群和市场需求开通的可供用户选择使用的业务。数据业务是市场细分的结果,它充分挖掘了 移动网络的潜力,满足了用户的多种需求。 本次活动涉及的数据业务范围 :彩铃、来电提醒、 MISC 平台业务、 139邮箱、飞信、无线音乐俱乐部、便民气象、手机电视、炫彩天气、号薄管家 数据业务受理成功率 :受理时限低于 24小时的数据业务占总数据业务受理量的比例。注:总数据业务受理量是指本次活动涉及的数据业务受理量。 数据业务受理成功率计算公式为:受理时限低于 24小时的数据业务- *100% 总数据业务受理量三、 选择课题(1选题理由09年,上海公司计费信息中心将“提高数据业务受理成功率”作为“全面提升自助渠道 业务受理效率”的一项工作重点来抓,对其成功率提出了量化的指标要求。HLR交换机华为平台 中兴平台 其他平台(2选题依据我们采集了 09年 2月到 4月各数据业务成功率的数据,制成了以下情况表: 中国移动通信集团上海有限公司四、 设定目标根据中心指标要求,我们将本次活动的目标设定为:数据业务受理成功率 99% 图 4-1 目标值设定图 五、 目标可行性分析1. 现状分析根据目前 BOSS 系统受理流程, 完成一个业务受理必须经历 以下步骤:渠道受理(营业厅、网营、短营等 、发短信告知 用户受理结果、开通接口表、开通处理、业务平台。只有上述 多个步骤成功完成之后,业务受理才真正完成。经统计, 09年 2月至 4月间,数据业务受理失败量总共是 210963条,月平均受理失败量 70321条,详见下: 对 2009年 24月的数据业务失败量,根据其受理流程涉及到的环节,统计各环节的失 败量及其暂比,分类统计如下: 将汇总数据绘制成排列图如下: 图 5-1 各超时步骤情况排列图根据排列图可以明显看出,在各步骤引发数据业务失败中, “开通与业务平台交互失败” 占失败总量的 80.20%,是引发数据业务办理成功率低的主要问题。2. 可行性分析1 理论数据分析通过对 2009年 2月4月间的 210963条数据业务失败工单进行技术分析,发现其中 有正常维护、系统升级等不确定因素引起的数据业务失败无法解决,约占所有数据业务 失败量的 1.16%,相关统计数据如下所示: 除去这 1.16%的不可解决因素以后,我们又对剩余 98.84%因与业务平台交互产生的 失败工单进行了抽样分析。小组成员抽取了 100条此类失败工单,共同分析后发现其中 有 19条失败工单由于业务量波动、新业务上线等不可预知的原因而存在较大的随机性 和不确定性。 因此该主要问题的可解决程度应可达到 (1-1.16% (1-19/100 =80.06%。 如果解决了 80.06%可解决的失败工单后,数据业务受理成功率理论上的值可到达:月均成功率 + 月均超时率 * 与业务平台交互失败占比 * 可解决程度 = 98.26% + (100%-98.26% * 80.20% * 80.06% = 99.38%2 历史水平对比同时小组成员还查阅了 2008年的数据业务受理月成功率数据,结果发现 2008年 5月, 2008年 6月, 2008年 7月的数据业务受理成功率 达到 99%以上, 且最高曾达到 99.2%, 这一历史数据具有很高的参考价值。 3 结论综合以上两方面分析,数据业务受理成功率 99%的目标在理论上是完全有可能实 现的。 六、 原因分析小组运用头脑风暴法,针对主要问题 “开通与业务平台交互失败” 的原因进行了讨论, 经整理得到如下系统图: 图 6-1 系统图:开通与平台交互处理失败的原因分析小组成员经过分析和汇总, 找出了造成 “开通与业务平台交互失败” 的 末端因素共 7条 , 分别为:人工干预缺乏规范性、缺乏维护培训、网络瞬间中断、软件故障、服务器 CPU 负荷 超载、进程处理超时、 BOSS 与平台数据差异。 七、 要 因确认针对原因分析得到的 7条末端因素,小组成员根据公司相关文件,找到了量化的要因确 认标准,并制定了要因确认计划表,逐一判断每条末端因素是否为要因。 表 7-1 要因确认计划表末端因素 1:人工干预缺乏规范性确认方法:检查每日违规操作汇总,确认常规维护是否遵守维护规约确认标准:每日违规操作小于等于 0次(公司考核指标确认结果:小组成员收集了从 09年 2月至 09年 4月常规维护日操作记录,如下: 从结果来看,自 09年 2月到 09年 4月,没有 违规操作,每日违规操作小于等于 0次。 是否要因:否 中国移动通信集团上海有限公司 11末端因素 2:缺乏维护培训(chensj 确认方法:确认问题数据处理不规范及其相应培训的情况 确认标准:培训合格率不低于 100%(根据部门对于维护的指标确认结果:小组成员收集了从 09年 2月至 09年 4月部门统一的培训登记记录表和培训考试分数,与维护人员操作相关的培训如下:从结果来看,自 09年 2月到 09年 4月, 部门共进行了 8次与维护操作有关的培训, 且 8次出席率都为 100%(整组 ,合格率均为 100%。 是否要因: 否末端因素 3:网络瞬间中断确认方法:统计告警历史记录,计算因网络瞬间中断引起的数据业务失败工单量确认标准:因网络瞬间中断造成的开通失败情况,应小于总数的 4%(集团公司考核指标 确认结果:小组成员统计了 09年 2月到 4月间,因网络瞬间中断引发的数据业务失败工单 数量,该问题引起的数据业务失败次数为 342次,仅占数据业务失败总量的 0.16%,远低于 2%的标准。 12是否要因: 否末端因素 4:软件故障确认方法:统计历史记录,计算软件故障的次数确认标准:软件故障次数每季度 3次 。(中心考核指标确认结果:小组成员统计了 2009年 1月到 2009年 4月间, 软件故障发生的次数为 1次,低于每季度 3次 的标准。是否要因: 否末端因素 5:服务器 CPU 负荷超载确认方法:检查系统性能报表,检查是否存在服务器 CPU 负荷过高的情况 中国移动通信集团上海有限公司 13确认标准:服务器 CPU 平均占用应保持在 75%以下(系统设计说明书规定确认结果:小组成员分析了 2月到 4月间的系统性能历史数据,经统计该时间内服务器 CPU日均占用率为 64.05%,未超过系统设计说明书中规定的 75%的标准。7-5 服务器 CPU 负荷情况是否要因: 否末端因素 6:进程处理超时确认方法:统计 2月 4月工单 BOSS 与平台交互的平均时长 确认标准:BOSS 与平台交互时间平均 不超过 120秒。确认结果:小组成员,利用直方图,取样 09年 2月到 4月间工单数 200张,结果平均值为 150秒,远大于集团的标准 120秒。 147-6 2009年 2-4月 BOSS 与平台交互平均时长直方图是否要因: 是末端因素 7:BOSS 与平台数据差异确认方法:统计 2月 4月份工单,计算数据差异占总量的比率 确认标准:数据差异占总订购量的比率 =5%(公司考核指标确认结果:小组成员统计了 09年 2月到 4月间, BOSS与平台数据差异占总订购量的比例 中国移动通信集团上海有限公司 157-7 BOSS与平台数据占总订购量的比例是否要因: 是根据以上分析,我们确定造成 “开通与业务平台交互失败” 的要因为:1、 进程处理超时 2、 BOSS 与平台数据差异八、 制定对策针对上述确认的要因,小组进行了方案选优,制定了相应的对策措施表,明确了对每个 要因所采取的措施、目标、实施的内容和操作流程。 要因一:进程处理超时5月 26日由黄淑冬、 周立等人在 3楼会议室, 对进程处理速度慢问题提出了 3套优化对 策方案, 方案一:增加处理的进程数; 方案二:优化接口工单发送流程, 增加批量处理机制 。 针对三套优化方案, QC 小组也从可实施性、有效性等方面进行了分析与评估:对策方案分析表: 从上面的分析与评估表中可以看到,方案二综合得分最高, 最终小组选择 优化接口工单 发送流程,增加批量处理机制 方案。 同时得出了相应的优化需求:优化接口工单发送流程, 增加批量处理机制。要因二:BOSS 与平台数据差异5月 28日由李立恒、赵奇等人在 3楼会议室,对 BOSS 与平台数据差异问题进行讨论, 并提出了 3套优化对策方案, 方案一:改变 BOSS 核心处理模板, 从异步模式改成同步模式; 方案二:增加 BOSS 与平台数据对账机制 。针对二套优化方案, QC 小组也从可实施性、有效 性等方面进行了分析与评估:对策方案分析表: 对策评估表: 从上面的分析与评估表中可以看到,方案二综合得分最高, 最终小组选择 增加 BOSS 与 平台数据对账机制 方案。 同时得出了相应的优化需求:为了保证 BOSS 与平台数据一致性, 增加 BOSS 与平台数据对账机制。根据上述“对策选优”分析,制定以下对策与措施。坚持做到“三个要”即; “目标要 明确、措施要具体,责任要到人” 。 表 8-1对策措施表九、 对策实施对策实施一:优化处理工单的进程 1、 为相关程序的处理流程设计优化方案2009年 5月 27日6月 3日,由黄淑冬负责组织小组成员,协调应用开发人员共同对 相关程序代码进行方案设计, 以便实现对业务的批量处理。 最终决定将现有的程序处理流程 改为以下形式: 2、 实施步骤2009年 6月 4日23日,由开发人员根据设计方案进行相关程序的代码编写。 2009年 6月 23日 6月 30日,进行功能、集成测试。2009年 6月 30日晚上,程序上线,并安排人员进行实施后续跟踪,以确认实施的 有效性。 3、 效果检查:经过程序优化以后, 同样小组成员利用直方图, 取样 09年 7月到 10月间工单数 200张, 结果平均值为 41秒 ,远小于标准 120秒 。“进程处理超时”导致数据业务失败的问题得到基本解决。 图 9-1实施后 BOSS 与平台交互平均时长直方图 图 9-2进程处理超时实施后的失败量对比 结果:本项实施有效 对策实施二:增加 BOSS 与平台数据对账机制1、 为相关程序制定对账处理流程2009年 5月 27日6月 10日,由李立恒负责组织小组成员,协调业务需求人员, 共同对相关业务进行了确认。针对这些业务,整理出影响业务订购使用的全部要素(如 订购状态、生效失效时间、业务属性等 ,作为对账机制中数据比对的范围。同时,针对这些业务要素,明确了对账差异数据的处理原则:(1订购关系以 BOSS 侧为准, 如果平台有而 BOSS 侧无, 则平台自行删除; 如果 BOSS 有而平台无,则由 BOSS 侧进行重新同步(2涉及业务使用的属性信息,在订购关系一致的情况下,原则上以平台为准,以 确保用户使用不受影响2、 对账程序编写在对账业务范围和对账处理原则明确后,针对不同的业务,制定了每个业务的订购 关系对账文件格式规范,并安排相关开发人员,按照对账文件格式规范编写文件生成程 序和文件稽核程序。同时,通过业务管理部门协调各数据业务平台配合针对对账文件开发对账稽程序, 以期针对不同的业务,均能稽核出平台与 BOSS 数据不一致的情况。2009年 6月 15日8月 14日,小组成员与开发部密切配合,由开发人员负责进行 相关对账程序的代码设计,小组成员从中不断提出修改意见和建议,在开发中,针对对 账程序,着重强调以下几点:i. 对账程序尽可能明确反映所有有差异性的情况,并提供初步的原因分析 ii. 对账文件的生成考虑效率性和自动化程序,减少人工操作3、 程序上线运行并纳入日常维护工作经过分批改造后的对账机制,在平台配合下逐一进行了上线,在上线试运行之后, 小组成员安排将相关对账稽核工作纳入部门的日常维护矩阵中,针对不同的业务,按内 部人员侧重进行了划分,由专人对对账程序的运行情况、对账数据的稽核情况进行每日 跟踪,作为日常的维护工作的一部分,确保对账机制能有效运转起来,并且有稳定的人 员干预机制,真正起到对账的目的。 4、 效果检查:首先,小组成员针对每个涉及改造的业务,在其对账机制上线后,对对账结果进行 逐一跟踪和分析。从表 9-2图可以看到,通过对账机制,确实可以有效的发现数据不一致的情况,而按月 为单位来看,可以看到数据不一致的情况整体呈现下降的趋势。从这一点可以反映出,对账 机制可以有效在事后对不一致数据进行及时的稽核和修正。 通过修正, 可以有效的减少数据 异常的情况,使整个业务逐渐趋于稳定,形成良性循环。 缺乏对账的业务:139邮箱、飞信、无线音乐俱乐部、炫彩天气、号薄管家业务。其二,小组成员分析采用了对账机制后的失败量情况。从表 9-3图可以看到,而按月为单位来看,可以看到数据差异的情况整体呈现下降的趋 势。而且从实施完成后的 9月份开始数据差异占比的比例已经下降低于 5%的水平,从这一 点可以反映出,该措施有效。 结果:本项实施有效十、 效果检查 1、目标检查(1总体情况 图 10-1实施前后各时期及时率情况(2目标值达成情况确认 图 10-2目标达成情况对策实施以后, 小组成员分析了 2009年 5月2009年 12月的数据业务受理情况, 实施 后的成功率达到 99.08%,巩固期的成功率提升至 99. 17%。这样的结果与对策实施以前相比 提高非常显著,小组从整体上很好地完成了的预期目标。2、深入分析检验接下来,我们进一步分析了在实施后数据业务受理各步骤的超时情况,汇总如下: 将汇总数据绘制成排列图并与实施前对比如下:图 9-2实施前后各步骤延迟情况对比本次活动后,原来占超时总数绝大部分的“开通与业务平台交互”这一环节的失败 数量明显下降,只占到总超时量的 32.20%, 不再是造成数据业务受理成功率低的主要问题 。3、成果效益1 社会效益 :比较活动前后数据业务受理失败工单数量,可以看到在实施后到巩固期的 45个月间, 失败量相比活动前总共减少约 81695条。 有效提升了上海公司数据业务质量, 为公司带来了 良好的社会反响。同时由于增加了相应对账机制,能有效地减少了用户对数据业务订购问题的咨询和投 诉,减少客服条线的工作压力,并使客户感受到移动公司的优质服务,增加了客户对中国移 动的信任度;对提高客户满意率、增强企业在市场的竞争力、树立上海移动良好的企业形象 起到了积极的作用。2 经济效益:另一方面,经统计活动前、活动后的失败量减少 81695条,其中申请功能的量占 20%, 其收费的业务占 50%,如果失败量消除了,根据目前上海移动财务统计的结果,数据业务的 每月功能费平均在 5元 /月,在巩固期增加公司收入共计:5. 408475*50%*20%*81695 Fe e (*( P(元 =数 据 业 务 每 月 费 用 减 少 的 失 败 量 增 加 收 入 Total十、巩固措施 为了将本次 QC 活动的成果继续保持下去,小组成员制定了如下几项措施: 1. 针对对策一:制定批量处理机制以实现并发处理 针对活动中通过梳理确定下来具有 批量处理机制的数据业务, 同时小组成员 也在需求模板中增加了批量处理机制原 则, 对于今后新增数据业务是否涉及批量 处理机制均需参照集团规范 (文档编号: JFGF2009157 。2. 针对对策二:建立对账机制 针对活动中通过梳理确定下来需要建立机制的数据业务,小组成员在需求模板中增加了 对账机制的选项, 同时