优秀QC成果中国移动通信集团广西有限公司守护者QC小组

制表人：覃义寒 制表时间：2010-4-13 综合考虑 4 个维度下各方案的优劣，最终选择得分最高的.NET C#平台。
（三） 服务器选择分析
服务器的选择主要考虑 CPU、内存、硬盘容量三方面，本课题采用 TPMC 值作为选择 的参考，tpmC 值在国内外被广泛用于衡量计算机系统的事务处理能力 。 ，它的计算等 式为： tpmC= （用户数 * 同时在线用户比例 * 平均每人每天访问网站的次数 * 日忙时集 中系数 * 每次访问操作（查询，更新，统计）所需事务数 + 接口每分钟获取工单最大数 *5+ 每 分 钟 分 析 工 单 最 大 数 * 分 析 一 条 工 单 所 需 事 务 数 ） /(1- 其 他 操 作 所 需 资 源 比 例 )/(1- 系统冗余系数 ) 。 对系统进行初步评估，各参数的需求如下，得到的 TPMC 值为 3786667。
（二）确定目标
小组认为发现批量预警不会大于测算的最慢的时间， ， 所以小组将本次 QC 活动的目标 定为：发现批量预警的时间<=5 分钟。
四、 提出各种方案并确定最佳方案
（一） 方案提出
为了能够实现目标，小组成员利用头脑风暴法对“研发批量投诉智能预警系统”的研发 进行讨论，得到如下工作流程及内容。
6-28
5 26 39 39
6 29 29 35
…… …… …… ……
16 34 36 37
17 21 29 46
18 30 34
19 45
20 32
2010年1月-3月预警时长分布
60 50 40 30 20 10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 预警序号
10-28
中国移动广西公司守护者 QC 小组
课题： 研发批量投诉智能预警系统
源”数据库方式，评价维度与权重如下表：
分别使用 3 种接口方式采集 10000 条工单，记录试验结果，得到交互时间和稳定性； “开发时间”是根据技术人员的开发经验以及对系统开发量的评估，得到的理论估计值； 安 全性是分析其传输的方式得到的结果。
中国移动广西公司守护者 QC 小组
课题： 研发批量投诉智能预警系统
“研发工作量”是根据技术人员的开发经验以及对系统开发量的评估，得到的理论估 计值； “程序性能”是使用 3 个方案分别试验相同的一段程序得到的运行时间对比； “对服务 器的要求”以及“维护性”主要从 3 个平台的特点进行分析，得到以下方案的比较评分表：
4-28
中国移动广西公司守护者 QC 小组
课题： 研发批量投诉智能预警系统
（四）
课题查新
在同行、 专利网站咨询搜索， 从检索报告中发现目前暂无此类软件引入， 需要自行研发。
三、 目标设定
（一）设定依据
系统模拟人脑发现批量预警的简化流程图
5-28
中国移动广西公司守护者 QC 小组
课题： 研发批量投诉智能预警系统
根据批量预警规则：半个小时内出现同类问题工单 5 单或以上，选择 30 分钟为测算 时间。首先，测算目前系统半小时内工单到达的最大数量：使用目前的客服系统从 2010-1-1 00:00:00 至 2010-3-31 23:59:59，每隔 1 分钟扫描半小时内的工单数量，部分数据如下表：
制表人：韦媚 制表时间：2010-4-6 通过比较半小时内测算工单的数据，比较得到最大值为 260，即半小时内到达系统最 多的工单量为 260 单。 进一步测算机器处理速度： 利用目前比较成熟的文本聚类工具对最近 的 10000 条工单进行机器处理模拟，一共耗时约 3 小时 7 分钟，所以：机器处理速度= 3 小 时 7 分钟/10000 条工单=约 1.12 秒/条工单。 系统发现预警时长——从同类问题的第 5 单进入系统到最终发布预警信息历时。 （1） 最快发现批量预警的情形 半小时内第 5 个工单进入系统，与前 4 个工单都为同一个问题，此时系统需要处理 5 个工单即可发现预警。所以：最快发现预警时间 =1.12 秒*5=5.6 秒。 （2） 最慢发现批量预警的情形 半小时内第 260 个工单进入系统， 与前 259 个工单进行比较， 出现同类问题达到 5 单， 此时，系统需要处理 260 个工单才能发现预警，所以：最慢发现预警时间=1.12 秒*260=4 分 钟 51 秒。 根据测算，系统发现批量预警时长的范围为：5.6 秒--4 分钟 51 秒。
制表人：蔡利群
制表时间：2010-4-3
3-28
中国移动广西公司守护者 QC 小组
课题： 研发批量投诉智能预警系统
制图人：蔡利群 制图时间：2010-4-3 由上面所描述的发现批量预警的流程可以得知： 批量预警的发现有赖于人工逐条查看每 一条投诉工单，工作方式仍然停留在手工阶段。而客服中心每月承载的投诉工单多达 14w 条，但处理批量专席人员只有 3 名，所以每人月均处理：14W/3=4.6W 条左右的工单，工作 量之大可想而知；同时，经过测算，一个有经验的员工查看一条工单需要 10 秒钟，从 2010 年 1 月-3 月平均每半小时工单量来看，半小时内工单最多可达 250 单，所以预警发布用时 最长可达 10X250/60=42（分钟） 。这就导致预警信息传递到监控室非常滞后。
制表人：凌俊民 制表时间：2010-5-3 各维度综合评分以后，我们选择得分最高的 webservice 标准接口方案。
2、
投诉信息预处理
投诉信息预处理阶段，就是对投诉内容进行文本挖掘，区别在于：最大反向匹配算法是 从文本末端开始匹配而最大正向匹配算法是从句首开始。举例说明：
11-28
中国移动广西公司守护者 QC 小组
5000 75% 3750 20 75% 300 400 10 10 50% 70% 3786667
制表人：覃义寒 制表时间：2010-4-13 根据 TPMC 值得到服务器性能的 CPU 和内存指标：CPU ：四核 2.40GHz；内存：4G。 该指标同样满足.NET C#平台对服务器的要求。 下面计算所需硬盘容量。分析需求：物理容量需求=有效存储容量需求*RAID 系数，先 计算有效存储容量需求，所需参数如下： 立单及关联案例分析结果 派发关联案例分析结果 回复关联案例分析结果 投诉案例库初期建设 每月新增投诉案例数 用户注册、日志等其他数据占用比例 系统冗余 120000 10000 10000 500 200 50% 30%
（二）
问题提出
作为运营支撑中心的前沿哨兵，监控室肩负着及时发现批量投诉的重任，但是，一直以 来，预警时长并不理想，统计最近的 2010 年 1 月-3 月每月批量预警的时长，如图所示。 序号 预警 时长
（分钟）
1 1月 2月 3月 37 41 30
2 31 48 47
3 19 38 36
4 34 32 31
制表人：覃义寒
制表时间：2010-4-13
9-28
中国移动广西公司守护者 QC 小组
课题： 研发批量投诉智能预警系统
（四） 数据库选择分析
e 通过 3 个维度“特性优点” “性能” “数据处理能力”对比 SQLServer、 DB2、 Oracl Oracle 三种数据库，各维度赋予一定的权重，见下表。
每月工单量
15.5 15 单位：万单 14.5 14 13.5 13 12.5 2009年11月 2009年12月 2010年1月 时间 2010年2月 2010年3月
制图人：韦媚
制图时间：2010-4-5
（三）
选题理由总结
针对预警滞后的问题， 小组成员在和云南移动、 安徽移动等几个省公司的交流中了解到： 其他省公司在投诉分析方面，没有引入批量投诉分析，只是分析热点问题，而热点问题的分 析一般要滞后一个工作日，没有系统支撑的实时机制。 所以， 小组提出全新的解决思路： 在工单产生后通过辅助系统智能发现批量投诉并预警。
小组成员主要来自运营支撑中心监控维护室的服务团队：
1-28
中国移动广西公司守护者 QC 小组
课题： 研发批量投诉智能预警系统
二、 选择课题
（一） 名词解释
投诉工单：客户通过移动公司服务渠道提出的投诉、咨询等问题记录单；简称工单。 批量投诉：当同类问题，同一段时间产生一定数量的工单指批量投诉；简称批量。 批量预警规则：半个小时内出现同类问题工单 5 单或以上就发布批量预警信息。 批量预警时长：从存在批量预警到发现批量预警最后发布预警信息所消耗的时间。 K 最近邻(k-Nearest Neighbor，KNN)分类算法：一个理论上比较成熟的方法，也是最 简单的机器学习算法之一。思路：如果一个样本在特征空间中的 k 个最相似(即特征空间中 最邻近)的样本中的大多数属于某一个类别，则该样本也属于这个类别。该算法用来对投诉 工单进行分类。
中国移动广西公司守护者 QC 小组
课题： 研发批量投诉智能预警系统
系统研发工作流程 根据系统建设思路画出方案树图：
系统建设方案树图
（二） 开发平台选择
开发平台有 3 个方案：C++、J2EE、.NET C#，通过研发工作量、程序性能、对服务器 的要求、维护性等四个维度对其评分，选出最佳方案。
7-28
课题： 研发批量投诉智能预警系统
例如文本：为什么农行网银在网上支付话费总是显示错误，我在淘宝刚买了东西，而你 们这边连接总是显示错误。 最大反向匹配算法处理结果：为什么，农行，网银，在，网上，支付，话费，总，是， 显示，错误，我，在，淘宝，刚，买，了，东西，而，你，们，这，边，连接，总，是， 显 示，错误。 最大正向匹配算法处理结果：为，什，么，农，行，网银，在网，上支，付话，费总， 是显，示错，误，我，在，淘宝，刚买，了，东西， ，而你，们，这，边，连，接总，是显， 示错误。 特别标注的文字就是算法把应该归为词组的文本拆分了，这样拆分影响了归类的准确 性，而最大反向匹配算法比最大正向匹配算法错误要少。 经试验 1000 条数据，最大反向匹配算法耗时 42 秒，准确度达到 95%，无论是历时还 是准确度都好于最大正向匹配算法。所以选择最大反向匹配算法对工单进行预处理。
通过试验 20000 条工单对比 3 个方案的数据处理时间， 根据研发经验比较其 “特性优点” 与“性能” ：
制表人：方焕 制表时间：2010-5-3 最后小组选择优势比较明显的模块方案选择分析
1、 投诉工单信息采集
目前的工单都存储在客服生产系统， 新系统需要先从客服系统把工单采集过来， 投诉工 单信息采集有三种方式： webservice 接口方式、XML 文件格式 FTP 方式、直接访问“数据
中国移动广西公司守护者 QC 小组
课题： 研发批量投诉智能预警系统
研发批量投诉智能预警系统
中国移动广西公司守护者 QC 小组
一、 小组简介
守护者 QC 小组成立于 2009 年 3 月，曾负责攻关型课题《缩短后台投诉工单处理平均 历时》 ，该课题 2010 年参加“海洋王”荣获全国 QC 小组成果发表赛一等奖，同时小组还获 得“全国优秀 QC 小组”称号。
8-28
中国移动广西公司守护者 QC 小组
课题： 研发批量投诉智能预警系统
用户数 同时在线用户比例 同时在线用户数 平均每人每天访问网站的次数 日忙时集中系数 接口每分钟获取工单最大数 每分钟分析工单最大数 分析一条工单所需事务数 每次访问操作（查询，更新，统计）所需事务数 其他操作所需资源比例 系统冗余系数 TPMC
制图人：韦媚 制图时间：2010-4-2 从图中可以看到每月的批量预警历时情况， 计算 3 个月的批量预警历时平均为 35 分钟 51 秒。缩短批量预警时长成为监控室的当务之急。 进一步对现状深入分析， 发现批量投诉预警的工作流程为： 客服部门话务员在接电话时 或投诉专员处理工单时遇到同类问题 5 单就会通知批量专员， 批量专员通过审核收集过来的 工单或每 30 分钟检查一次同类工单， 确认为批量投诉预警则电话通知运营支撑中心监控室。
时间（分钟）
1月 2月 3月
2-28
中国移动广西公司守护者 QC 小组
课题： 研发批量投诉智能预警系统
人工发现批量预警流程图 根据批量预警流程，抽取 2010 年 1 月-3 月所有预警，每个预警量在每一个环节所用的 时间绘成以下单值图。从图中可以看出， “批量专员发现核实”预警这一环节历时最久，大 部分预警分布在 30-45 分钟之间。
制表人：覃义寒 制表时间：2010-4-13 存储容量需求 =(（(立单分析结果 +回复分析结果 +派发分析结果 )*处理过程、立、派、 回分析结果每单占用空间(KB)+每月新增知识语料库*每条语料库占用空间)*保存时间+知识 库初期建设*每条知识占用空间）*(1+数据库索引比例)*(1+用户注册、日志等其他数据占用 比例)/(1-系统冗余)= 15.86（G） 采用 RAID5，系数=1.33，所以物理容量需求=有效存储容量需求*RAID 系数= 21.10G。 对比现有设备与新增设备两种方案， 在满足性能的情况下， 我们选择成本较低的现有设 备。