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

中国移动通信集团上海有限公司上海有限公司中国移动通信集团2010年1月计费信息中心应用系统开发部业务需求质量控制QC小组一、 小组概况随着移动通信语音市场的日趋成熟与饱和，数据业务成为各运营商力争的领域。面对数据业务层出不穷的情况，客户不断要求提升服务质量的现状下，若能有效提高数据业务受理成功率，在相同时间内将能为更多的客户提供高质量的服务，对提升客户满意度将起到显著的推动作用。为此我们小组以提高数据业务受理成功率作为本次QC活动的课题。l 表1-1小组概况表： 小组名称业务需求质量控制QC小组成立时间2008年3月15日 课题名称提高数据业务受理成功率登记编号09-SY-JF-16课题类型攻 关 型活动时间2009年5月-2009年12月活动次数15次出勤率100%小 组 成 员姓名性别职务文化程度组内分工QC培训（小时）黄淑冬女技术督导硕士组长20李立恒男技术督导硕士组员24周立男技术支撑本科组员12章高清女高级技术督导博士组员36董亮男技术督导本科组员24陈颂劼女技术支撑本科组员24赵奇男技术支撑硕士组员24唐韵清女技术支撑本科组员32孙轶青女技术督导本科组员12任申骏男技术支撑本科组员20王玎女技术支撑硕士组员24谢黎女技术支撑硕士组员20业务需求质量控制QC小组全由一线员工组成，具备长期的开发维护经验，2008年3月QC小组成立以来，小组不断地进行技术攻关和改进。2009年，小组开展QC活动“降低业务派单时间”成效显著，获得了2009年上海市优秀质量管理小组称号。l 图1-1移动业务处理流程图：二、 术语解释：l 数据业务：是运营商在基本业务（话音业务）的基础上，针对不同的用户群和市场需求开通的可供用户选择使用的业务。数据业务是市场细分的结果，它充分挖掘了移动网络的潜力，满足了用户的多种需求。l 本次活动涉及的数据业务范围：彩铃、来电提醒、MISC平台业务、139邮箱、飞信、无线音乐俱乐部、便民气象、手机电视、炫彩天气、号薄管家l 数据业务受理成功率：受理时限低于24小时的数据业务占总数据业务受理量的比例。注：总数据业务受理量是指本次活动涉及的数据业务受理量。l 数据业务受理成功率计算公式为： 受理时限低于24小时的数据业务 - *100% 总数据业务受理量三、 选择课题(1) 选题理由09年，上海公司计费信息中心将“提高数据业务受理成功率”作为“全面提升自助渠道业务受理效率”的一项工作重点来抓，对其成功率提出了量化的指标要求。 根据上海公司计费信息中心的考核指标，数据业务受理成功率应99。(2) 选题依据l 我们采集了09年2月到4月各数据业务成功率的数据，制成了以下情况表：统计周期受理量(条)失败量（条）成功量（条）受理成功率 (%)2009年2月份6505498.50%2009年3月份7200998.30%2009年4月份7390097.90%合计294.68%月平均7032198.26% 从表中看出：目前数据业务的成功率为98.26%，低于中心指标99%。因此，我们选择提高数据业务受理成功率为本次QC活动的课题。中心指标: 数据业务受理成功率99提高数据业务受理成功率中心要求部门问题点选定课题2月份3月份4月份月平均：98.26中心指标：99.00四、 设定目标根据中心指标要求，我们将本次活动的目标设定为：数据业务受理成功率99%图4-1 目标值设定图五、 目标可行性分析1. 现状分析根据目前BOSS系统受理流程，完成一个业务受理必须经历以下步骤：渠道受理（营业厅、网营、短营等）、发短信告知用户受理结果、开通接口表、开通处理、业务平台。只有上述多个步骤成功完成之后，业务受理才真正完成。l 经统计，09年2月至4月间，数据业务受理失败量总共是条，月平均受理失败量70321条，详见下：2009-022009-032009-04合计平均数据业务受理失败量(条)65054720097390070321l 对2009年24月的数据业务失败量，根据其受理流程涉及到的环节，统计各环节的失败量及其暂比，分类统计如下：序号失败步骤失败量百分比累计百分比1开通与业务平台交互80.20%80.20%2开通处理3274115.52%95.72%3送开通接口表65393.10%96.82%4各渠道受理24891.18%100.00%合计100%100%l 将汇总数据绘制成排列图如下：图5-1 各超时步骤情况排列图根据排列图可以明显看出，在各步骤引发数据业务失败中，“开通与业务平台交互失败”占失败总量的80.20%，是引发数据业务办理成功率低的主要问题。2. 可行性分析1) 理论数据分析通过对2009年2月4月间的条数据业务失败工单进行技术分析，发现其中有正常维护、系统升级等不确定因素引起的数据业务失败无法解决，约占所有数据业务失败量的1.16%，相关统计数据如下所示：时间工单总量失败量正常维护引起的超时量正常维护引起超时所占比例2009年2月650548841.36%2009年3月720098501.18%2009年4月739007000.94%总计2434平均值703214521.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%，这一历史数据具有很高的参考价值。2008年1月2月3月4月5月6月7月8月9月10月11月12月月受理成功率97.54%98.15%98.50%98.45%99.04%99.20%99.01%98.30%98.42%97.90%97.80%97.85%3) 结论综合以上两方面分析，数据业务受理成功率99的目标在理论上是完全有可能实现的。六、 原因分析小组运用头脑风暴法，针对主要问题“开通与业务平台交互失败”的原因进行了讨论，经整理得到如下系统图：开通与业务平台交互失败人机法维护人员处理有误人工干预缺乏规范性工单超时连接无响应网络瞬间中断服务器无响应软件故障服务器CPU负荷超载调用无效返还BOSS与平台数据差异进程处理超时人员业务不熟练缺乏维护培训图6-1 系统图：开通与平台交互处理失败的原因分析小组成员经过分析和汇总，找出了造成“开通与业务平台交互失败”的末端因素共7条，分别为：人工干预缺乏规范性、缺乏维护培训、网络瞬间中断、软件故障、服务器CPU负荷超载、进程处理超时、BOSS与平台数据差异。七、 要因确认针对原因分析得到的7条末端因素，小组成员根据公司相关文件，找到了量化的要因确认标准，并制定了要因确认计划表，逐一判断每条末端因素是否为要因。序号末端因素确认内容调查方法确认标准确认人确认时间1人工干预缺乏规范性常规维护是否遵守维护规约检查每日违规操作汇总每日违规操作小于等于0次（公司考核指标）唐韵清赵奇2009年5月23日2缺乏维护培训确认问题数据处理不规范及其相应培训的情况检查维护数据处理脚本单培训合格率不低于100%（根据部门对于维护的指标）黄淑冬 陈颂劼2009年5月23日3网络瞬间中断确认因网络终端造成的工单失败比例统计告警历史记录，计算因网络瞬间中断引起的失败工单量因网络瞬间中断造成的工单失败情况，应小于总数的2%（公司考核指标）董亮任申骏2009年5月9日4软件故障确认软件故障的次数统计历史记录，计算软件故障的次数软件故障次数每季度3次。（中心考核指标）董亮任申骏2009年5月9日5服务器CPU负荷超载确认服务器CPU负荷检查系统性能报表，确认是否存在服务器CPU负荷过高的情况服务器CPU平均占用应保持在75%（系统设计说明书规定）唐韵清2009年5月15日6进程处理超时确认BOSS与平台交互平均所费的时间统计2月4月工单与平台交互的平均时长BOSS与平台交互平均时间120秒。（集团考核指标）黄淑冬 赵奇2009年5月15日7BOSS与业务平台数据差异确认BOSS与平台数据差异情况统计2月4月份工单，计算数据差异占总量的比率数据差异占总订购量的比率5%（公司考核指标）章高清李立恒2009年5月26日表7-1 要因确认计划表末端因素1：人工干预缺乏规范性确认方法：检查每日违规操作汇总，确认常规维护是否遵守维护规约确认标准：每日违规操作小于等于0次（公司考核指标）确认结果：小组成员收集了从09年2月至09年4月常规维护日操作记录，如下：从结果来看，自09年2月到09年4月，没有违规操作，每日违规操作小于等于0次。是否要因： 否末端因素2：缺乏维护培训（chensj）确认方法：确认问题数据处理不规范及其相应培训的情况确认标准：培训合格率不低于100%（根据部门对于维护的指标）确认结果：小组成员收集了从09年2月至09年4月部门统一的培训登记记录表和培训考试分数，与维护人员操作相关的培训如下： 时间 培训名称 人数 合格分数 冯志隽 朱立羽 金斌 钱卓艳 2009.2数据处理事项460929488892009.2数据操作审批注意事项460887885802009.2常规操作矩阵维护460909390922009.3开通问题处理汇总460808077802009.3避免二次影响460959397912009.3修复问题的艺术460918589842009.4解决问题和避免问题460929496882009.4新统一开通培训46096909589从结果来看，自09年2月到09年4月，部门共进行了8次与维护操作有关的培训，且8次出席率都为100%（整组），合格率均为100%。是否要因： 否末端因素3：网络瞬间中断确认方法：统计告警历史记录，计算因网络瞬间中断引起的数据业务失败工单量确认标准：因网络瞬间中断造成的开通失败情况，应小于总数的4%（集团公司考核指标）确认结果：小组成员统计了09年2月到4月间，因网络瞬间中断引发的数据业务失败工单数量，该问题引起的数据业务失败次数为342次，仅占数据业务失败总量的0.16%，远低于2%的标准。统计周期网络中断次数本因素失败工单量失败工单总数比例2月2312650540.48%3月130720090.04%4月00739000.00%总计33420.16% 7-3 网络瞬间中断引发数据业务失败工单数量是否要因： 否末端因素4：软件故障确认方法：统计历史记录，计算软件故障的次数确认标准：软件故障次数每季度3次。（中心考核指标）确认结果：小组成员统计了2009年1月到2009年4月间，软件故障发生的次数为1次，低于每季度3次的标准。统计周期软件故障次数2009年1月02009年2月02009年3月02009年4月109年一季度总计1 7-4 软件故障次数是否要因： 否末端因素5：服务器CPU负荷超载 确认方法：检查系统性能报表，检查是否存在服务器CPU负荷过高的情况确认标准：服务器CPU平均占用应保持在75%以下（系统设计说明书规定）确认结果：小组成员分析了2月到4月间的系统性能历史数据，经统计该时间内服务器CPU日均占用率为64.05%，未超过系统设计说明书中规定的75%的标准。7-5 服务器CPU负荷情况是否要因： 否末端因素6：进程处理超时确认方法：统计2月4月工单BOSS与平台交互的平均时长确认标准：BOSS与平台交互时间平均不超过120秒。确认结果：小组成员，利用直方图，取样09年2月到4月间工单数200张，结果平均值为150秒，远大于集团的标准120秒。组编号区间下限值 ( 区间上限值 组中值 %频数频数统计频率 %11 26 13 31.50%226 51 38 73.50%351 76 63 147.00%476 101 88 94.50%5101 126 113 2010.00%6126 151 138 3618.00%7151 175 163 4723.50%8175 200 188 3819.00%9200 225 213 115.50%10225 250 238 84.00%11250 275 263 42.00%12275 300 288 31.50% 7-6 2009年2-4月BOSS与平台交互平均时长直方图是否要因： 是末端因素7：BOSS与平台数据差异确认方法：统计2月4月份工单，计算数据差异占总量的比率确认标准：数据差异占总订购量的比率=5%（公司考核指标）确认结果：小组成员统计了09年2月到4月间， BOSS与平台数据差异占总订购量的比例平均7.27%，远高于5%的标准。统计周期BOSS与平台数差异量总订购量差异占比2月295357.00%3月315356.92%4月391677.80%总计7.27%7-7 BOSS与平台数据占总订购量的比例是否要因： 是根据以上分析，我们确定造成“开通与业务平台交互失败”的要因为：1、 进程处理超时2、 BOSS与平台数据差异八、 制定对策针对上述确认的要因，小组进行了方案选优，制定了相应的对策措施表，明确了对每个要因所采取的措施、目标、实施的内容和操作流程。要因一：进程处理超时5月26日由黄淑冬、周立等人在3楼会议室，对进程处理速度慢问题提出了3套优化对策方案，方案一：增加处理的进程数；方案二：优化接口工单发送流程，增加批量处理机制。针对三套优化方案，QC小组也从可实施性、有效性等方面进行了分析与评估：对策方案分析表：序号方案内容预计效果提升可实施性实施成本运行成本1增加处理的进程数30%可自行实施无需硬件支撑高2增加批量处理机制70%可自行实施无需硬件支撑低3开通系统扩容改造90%无法自行实施需硬件支撑低对策评估表：序号方案内容预计效果提升（得分）可实施性（得分）实施成本（得分）运行成本（得分）综合得分选定方案1增加处理的进程数2551132增加批量处理机制3553163开通系统扩容改造511512从上面的分析与评估表中可以看到，方案二综合得分最高，最终小组选择优化接口工单发送流程，增加批量处理机制方案。同时得出了相应的优化需求：优化接口工单发送流程，增加批量处理机制。要因二：BOSS与平台数据差异5月28日由李立恒、赵奇等人在3楼会议室，对BOSS与平台数据差异问题进行讨论，并提出了3套优化对策方案，方案一：改变BOSS核心处理模板，从异步模式改成同步模式；方案二：增加BOSS与平台数据对账机制。针对二套优化方案，QC小组也从可实施性、有效性等方面进行了分析与评估：对策方案分析表：序号方案内容有效性可实施性经济性可靠性1从异步模式改成同步模式效果90%无法自行实施费用高，需申请彻底改造2增加BOSS与平台数据对账机制效果70%可自行实施无需费用绝大部分改造对策评估表：序号方案内容有效性(得分)可实施性(得分)经济性(得分)可靠性(得分)综合得分选定方案1从异步模式改成同步模式5115122增加BOSS与平台数据对账机制355417从上面的分析与评估表中可以看到，方案二综合得分最高，最终小组选择增加BOSS与平台数据对账机制方案。同时得出了相应的优化需求：为了保证BOSS与平台数据一致性，增加BOSS与平台数据对账机制。根据上述“对策选优”分析，制定以下对策与措施。坚持做到“三个要”即；“目标要明确、措施要具体，责任要到人”。序号要因对策目 标措施实施者完成时间地点1进程处理超时优化处理工单的进程BOSS与平台交互平均时间120秒。1. 分析原因2. 制定优化方案3. 优化程序代码4. 功能、集成测试5. 程序正式上线运行黄淑冬周立赵奇董亮孙轶青2009年6月23日钦州54号楼3楼2BOSS与平台数据差异增加BOSS与平台数据对账机制数据差异占总订购量的比率5%1. 分析原因2. 为相关业务制定对账机制3. 对账程序编写4. 程序正式上线运行并纳入日常维护措施章高清李立恒陈颂劼任申骏唐韵清2009年8月23日钦州54号楼3楼表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秒。 “进程处理超时”导致数据业务失败的问题得到基本解决。组编号区间下限值 ( 区间上限值 组中值 %频数频数统计频率 %11 9 5 42.00%29 18 13 157.50%318 26 22 136.50%426 34 30 3015.00%534 42 38 4522.50%642 51 46 3115.50%751 59 55 2311.50%859 67 63 199.50%967 75 71 115.50%1075 84 79 52.50%1184 92 88 21.00%1292 100 96 21.00%图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、 效果检查： l 首先，小组成员针对每个涉及改造的业务，在其对账机制上线后，对对账结果进行逐一跟踪和分析。从表9-2图可以看到，通过对账机制，确实可以有效的发现数据不一致的情况，而按月为单位来看，可以看到数据不一致的情况整体呈现下降的趋势。从这一点可以反映出，对账机制可以有效在事后对不一致数据进行及时的稽核和修正。通过修正，可以有效的减少数据异常的情况，使整个业务逐渐趋于稳定，形成良性循环。业务月份用户数对账结果(BOSS与平台不一致)缺乏对账的业务9月10月11月12月表9-2 业务与BOSS与平台的对账结果缺乏对账的业务：139邮箱、飞信、无线音乐俱乐部、炫彩天气、号薄管家业务。l 其二，小组成员分析采用了对账机制后的失败量情况。从表9-3图可以看到，而按月为单位来看，可以看到数据差异的情况整体呈现下降的趋势。而且从实施完成后的9月份开始数据差异占比的比例已经下降低于5%的水平，从这一点可以反映出，该措施有效。统计周期数据差异量总订购量差异占比2月29535 7.00%3月31535 6.92%4月39167 7.80%5月48397 9.45%6月55853 10.67%7月47412 9.23%8月30272 5.64%9月27872 4.34%10月20496 3.23%11月16461 2.52%12月9041 1.20%表9-3 数据差异占比实施前、后对比结果：本项实施有效十、 效果检查1、目标检查（1）总体情况阶段实施前实施中实施后巩固期时间2月3月4月5月6月7月8月9月10月11月12月月平均成功率（%）98.598.397.998.8998.798.9598.899.199.0599.1599.18图10-1 实施前后各时期及时率情况（2）目标值达成情况确认 图10-2目标达成情况对策实施以后，小组成员分析了2009年5月2009年12月的数据业务受理情况，实施后的成功率达到99.08%，巩固期的成功率提升至99. 17%。这样的结果与对策实施以前相比提高非常显著，小组从整体上很好地完成了的预期目标。2、深入分析检验接下来，我们进一步分析了在实施后数据业务受理各步骤的超时情况，汇总如下：序号超时步骤失败量百分比累计百分比1开通处理2139160.52%60.52%2与业务平台交互1138132.20%92.72%3送开通接口表14494.10%96.82%4各渠道受理11233.18%100.00%合计35344100%100%表10-1对策实施后的各步骤超时情况将汇总数据绘制成排列图并与实施前对比如下： 图9-2实施前后各步骤延迟情况对比 本次活动后，原来占超时总数绝大部分的“开通与业务平台交互”这一环节的失败数量明显下降，只占到总超时量的32.20%，不再是造成数据业务受理成功率低的主要问题。3、成果效益1) 社会效益：比较活动前后数据业务受理失败工单数量，可以看到在实施后到巩固期的45个月间，失败量相比活动前总共减少约81695条。有效提升了上海公司数据业务质量，为公司带来了良好的社会反响。同时由于增加了相应对账机制，能有效地减少了用户对数据业务订购问题的咨询和投诉，