论文部分内容阅读
天津移动通信有限现任公司网管中心网络故障处理QC小组
QC小组简介
天津移动网络生产管理中心作为网络生产指挥调度部门全面负责天津移动网内交换、数据、传输、无线等专业网络运行的24小时统一实时监控，保证网络的正常运行及故障的及时处理。
相关名词解释：
1、电子运行维护系统([-OMS)：电子运行维护系统(E-OMS)是网络部门用以指挥调度、管理日常生产任务的主要工具手段，实现了各种工单的电子化。
2、网络故障预处理时间：
设备发生故障后监控人员进行初步处理至故障恢复的时间；或设备发生故障后监控人员经初步处理未能使故障恢复，则派发故障工单至相应责任部门的时间。设定目标
小组把目标值定为：网络故障预处理平均时长缩短至40分钟。
可行性分析
1、我们对监控室2004年的历史数据进行了采集分析并绘制成折线图：
从图中可以看出，在2004年的监控工作中，3月份和11月份的网络故障预处理时长曾达到了38．7分钟和36．2分钟的历史最好成绩。这说明，我们是有达到目标值的能力的。
2、对2005年4月监控室人均网络故障预处理时长进行统计：(单位：分钟)
根据统计结果可知，在未采取任何措施的情况下，在监控室中已有25％的人员能达到要求标准。
进一步对这5名达标人员进行分析(见下页图)：
通过分析，我们发现这5名监控人员的学历与工作年限均与其他监控人员水平相当，属于监控室的普遍水平，因此我们认为其他监控人员通过努力也可以达到目标值。
3、对2005年4月份监控室造成超长故障预处理的主要环节分析如下：
(1)对影响故障预处理时长主要环节的发生频率及占用时长进行调查统计并制定了排列图如图(1)、(2)：
根据以上2张排列图我们发现“对告警进行初步处理操作时间较长”是造成网络故障预处理时间过长的症结所在。该问题发生频次占总数的57．69％，时长占总历时的58．34％，如果把该问题解决，则故障预处理时长就可以缩短一半以上，由此找到了解决该问题的切入点。因此我们认为，目标值是可行的！
原因分析
小组使用头脑风暴法进行原因分析，整理成如下系统图：
根据此系统图，我们共得到了10条末端原因
制定对策计划
针对主要原因，小组成员制定了相应的对策计划对策实施
[实施一]
1．对全部设备告警制定《网络生产管理中心网络监控维护手册》，统一规范故障处理步骤．
2．按照“工单和经验库关联”的思路。将工单类别与经验库类别进行关联对应，形成既可以由关键字方式搜索，又能够直接通过王单查询的方式。监控人员在受理某个故障或投诉工单时，可以直接在电子工单上选取与该工单相关的经验库内容进行浏览。
3．8月中旬QC小组组织汇接专业6名监控人员再次对同一故障写出故障处理步骤，并进行了计时实际操作，与实施前的结果比较如下(见下页图)：
根据结果发现，监控人员对同一告警的处理步骤、时间基本保持一致且有明显的缩短，达到了预期的目的。
[实施二]
1．小组组织监控人员集中编写了《移动通信网络维护基础知识》手册。每周组织手册知识的交流、培训。
2．每周组织安排5个专业各1名监控人员进行专业基础知识讲座，并编写讲座教材，为其他专业的监控人员进行专业知识交叉讲解。
3．每月组织至少2个厂家的高级专业知识讲座及答疑活动．
4．建立共享知识库系统
对于网络生产方面的工程、管理规定、技术报道、设备知识等相关材料均可导入知识库系统，此外也可以直接将可供参考的典型故障工单的内容、处理过程等相关信息导入知识库中。
5．实施二效果检查
8月中旬我们对监控人员跨专业的学习情况再次进行了基础知识测试，与对策实施前进行比较：
监控人员的跨专业知识测试合格率由25％提高到了95％。达到了预期的目标。
[实施三]
1．通过与网络优化中心协调，7月中旬网络优化中心对全部遗留的基站门开告警进行了下站清除及确认工作，经1个月的时间，共清除了89个遗留的门开告警。
2．经小组分析每日发生的门开告警中其中99．7％是由于工程人员进站维护且操作外围告警设备不当造成的告警，对此，我们利用公司的网络资源，采用了“双向短信互动平台”，自主开发了“基站出入登记管理工具”。即维护人员进站前，向系统发送指定格式的短信，系统自动进行登记，并下发可以进站的消息，维护人员收到消息后方可进入，离开基站时再次向系统发送出站消息，系统自动登记后下发出站确认短信。
根据此软件提供的监控界面监控人员就可以有效的分辨基站门开告警产生的原因是否为人为因素造成。
3．由于此类告警的处理流程没有统一的规范，又组织了监控人员，制定了《基站门开告警的规范处理流程》，统一规范基站门开告警的处理流程。
4．为了能让“基站出入登记管理工具”得到最大限度的应用，我们又同网络优化中心等9个涉及进站的部门共同制定了《基站维护人员进出基站管理规定》，用以规范基站维护人员进出基站行为、及时发送短信等相关问题。
5.实施三效果检查：
统计2005年8月下旬平均每日产生的门开告警：
借助软件工具，结合相关管理制度的严格贯彻，基站门告警数量迅速下降，同时监控人员根据工具软件就可以迅速判断门告警的产生原因，完成相关后续管理工作，使得人为原因造成的门告警数由99．7％降至6％下降了93．7％，达到了预期的目标。
效果检查
1、与最初制定的目标进行比较
统计8月下旬监控平均故障预处理时间为：27分钟。
根据统计结果可知，达到了预期的目标！
一、制订巩固措施
1、在《监控维护工作手册》、《天津移动网络监控维护手册》基础上形成了员工应知应会考核管理办法，部门将其作为管理制度下发至全中心学习。
2、形成了《网管中心监控人员学习制度》，将专业知识讲座活动、监控人员轮流进行讲解作为制度主要内容之一，每周进行一次。
1、 形成了《故障经验库管理制度》，网管中心将其形成文件并下发，并建立故障处理经验月例会制度，每月召开故障处理经验交流会。
2、将“基站出入登记管理工具”固化到系统中，协助完成日常工作。
3、 根据《基站维护人员进出基站管理规定》形成基站维护人员管理办法。
4、将知识库、经验库固化在电子运行维护系统中，应用于日常工作。
二、巩固效果检查
小组统计了9、10月份，并于活动结束后继续监控了11、1 2月份的监控室平均故障预处理时长及人均预处理时长：
根据统计结果可见，活动成果在巩固期内得到了有效的巩固!
点评：
本次活动，小组全体成员全面运用质量管理的思想和方法，遵循PDCA循环的科学程序，从工作的各个细节出发，充分运用了科学的工具方法，经过5个月的时间，小组整理了包含5大专业、27种设备、近92个流程的监控专业手册及基础知识手册两套，汇总整理了监控制度一套，梳理了大量的监控流程，规范了各类相关工作，利用“短信互动平台”自主开发了一套软件管理工具，完善了基站门开告警的监控手段，为公司保证基站安全方面节省了大量投资。
本课题在总结材料中也存在着一些不足：在可行性分析中，把完全解决“初步操作时间较长”这个造成网络故障处理时间过长的结症，做为能完成本课题的依据不是很充分。这在后面原因分析中找出的末端因素，以及在实施阶段都没有用数据说明100％的解决了这个问题。另外在原因分析中找出的末端因素不是很科学。如：无故障处理考核标准、没有规范的故障处理流程都是不符合该中心的实际情况，虽然在后面要因确认过程中予以排出，但这种找末端因素的思路不是解决问题的思考方法。在要因确认表中没有确认标准，这就造成了后面用大量的文字叙述来解释，都不太符合QC小组成果总结的思路。因此，该成果还有很多需要提炼之处。
编辑／张君
QC小组简介
天津移动网络生产管理中心作为网络生产指挥调度部门全面负责天津移动网内交换、数据、传输、无线等专业网络运行的24小时统一实时监控，保证网络的正常运行及故障的及时处理。
相关名词解释：
1、电子运行维护系统([-OMS)：电子运行维护系统(E-OMS)是网络部门用以指挥调度、管理日常生产任务的主要工具手段，实现了各种工单的电子化。
2、网络故障预处理时间：
设备发生故障后监控人员进行初步处理至故障恢复的时间；或设备发生故障后监控人员经初步处理未能使故障恢复，则派发故障工单至相应责任部门的时间。设定目标
小组把目标值定为：网络故障预处理平均时长缩短至40分钟。
可行性分析
1、我们对监控室2004年的历史数据进行了采集分析并绘制成折线图：
从图中可以看出，在2004年的监控工作中，3月份和11月份的网络故障预处理时长曾达到了38．7分钟和36．2分钟的历史最好成绩。这说明，我们是有达到目标值的能力的。
2、对2005年4月监控室人均网络故障预处理时长进行统计：(单位：分钟)
根据统计结果可知，在未采取任何措施的情况下，在监控室中已有25％的人员能达到要求标准。
进一步对这5名达标人员进行分析(见下页图)：
通过分析，我们发现这5名监控人员的学历与工作年限均与其他监控人员水平相当，属于监控室的普遍水平，因此我们认为其他监控人员通过努力也可以达到目标值。
3、对2005年4月份监控室造成超长故障预处理的主要环节分析如下：
(1)对影响故障预处理时长主要环节的发生频率及占用时长进行调查统计并制定了排列图如图(1)、(2)：
根据以上2张排列图我们发现“对告警进行初步处理操作时间较长”是造成网络故障预处理时间过长的症结所在。该问题发生频次占总数的57．69％，时长占总历时的58．34％，如果把该问题解决，则故障预处理时长就可以缩短一半以上，由此找到了解决该问题的切入点。因此我们认为，目标值是可行的！
原因分析
小组使用头脑风暴法进行原因分析，整理成如下系统图：
根据此系统图，我们共得到了10条末端原因
制定对策计划
针对主要原因，小组成员制定了相应的对策计划对策实施
[实施一]
1．对全部设备告警制定《网络生产管理中心网络监控维护手册》，统一规范故障处理步骤．
2．按照“工单和经验库关联”的思路。将工单类别与经验库类别进行关联对应，形成既可以由关键字方式搜索，又能够直接通过王单查询的方式。监控人员在受理某个故障或投诉工单时，可以直接在电子工单上选取与该工单相关的经验库内容进行浏览。
3．8月中旬QC小组组织汇接专业6名监控人员再次对同一故障写出故障处理步骤，并进行了计时实际操作，与实施前的结果比较如下(见下页图)：
根据结果发现，监控人员对同一告警的处理步骤、时间基本保持一致且有明显的缩短，达到了预期的目的。
[实施二]
1．小组组织监控人员集中编写了《移动通信网络维护基础知识》手册。每周组织手册知识的交流、培训。
2．每周组织安排5个专业各1名监控人员进行专业基础知识讲座，并编写讲座教材，为其他专业的监控人员进行专业知识交叉讲解。
3．每月组织至少2个厂家的高级专业知识讲座及答疑活动．
4．建立共享知识库系统
对于网络生产方面的工程、管理规定、技术报道、设备知识等相关材料均可导入知识库系统，此外也可以直接将可供参考的典型故障工单的内容、处理过程等相关信息导入知识库中。
5．实施二效果检查
8月中旬我们对监控人员跨专业的学习情况再次进行了基础知识测试，与对策实施前进行比较：
监控人员的跨专业知识测试合格率由25％提高到了95％。达到了预期的目标。
[实施三]
1．通过与网络优化中心协调，7月中旬网络优化中心对全部遗留的基站门开告警进行了下站清除及确认工作，经1个月的时间，共清除了89个遗留的门开告警。
2．经小组分析每日发生的门开告警中其中99．7％是由于工程人员进站维护且操作外围告警设备不当造成的告警，对此，我们利用公司的网络资源，采用了“双向短信互动平台”，自主开发了“基站出入登记管理工具”。即维护人员进站前，向系统发送指定格式的短信，系统自动进行登记，并下发可以进站的消息，维护人员收到消息后方可进入，离开基站时再次向系统发送出站消息，系统自动登记后下发出站确认短信。
根据此软件提供的监控界面监控人员就可以有效的分辨基站门开告警产生的原因是否为人为因素造成。
3．由于此类告警的处理流程没有统一的规范，又组织了监控人员，制定了《基站门开告警的规范处理流程》，统一规范基站门开告警的处理流程。
4．为了能让“基站出入登记管理工具”得到最大限度的应用，我们又同网络优化中心等9个涉及进站的部门共同制定了《基站维护人员进出基站管理规定》，用以规范基站维护人员进出基站行为、及时发送短信等相关问题。
5.实施三效果检查：
统计2005年8月下旬平均每日产生的门开告警：
借助软件工具，结合相关管理制度的严格贯彻，基站门告警数量迅速下降，同时监控人员根据工具软件就可以迅速判断门告警的产生原因，完成相关后续管理工作，使得人为原因造成的门告警数由99．7％降至6％下降了93．7％，达到了预期的目标。
效果检查
1、与最初制定的目标进行比较
统计8月下旬监控平均故障预处理时间为：27分钟。
根据统计结果可知，达到了预期的目标！
一、制订巩固措施
1、在《监控维护工作手册》、《天津移动网络监控维护手册》基础上形成了员工应知应会考核管理办法，部门将其作为管理制度下发至全中心学习。
2、形成了《网管中心监控人员学习制度》，将专业知识讲座活动、监控人员轮流进行讲解作为制度主要内容之一，每周进行一次。
1、 形成了《故障经验库管理制度》，网管中心将其形成文件并下发，并建立故障处理经验月例会制度，每月召开故障处理经验交流会。
2、将“基站出入登记管理工具”固化到系统中，协助完成日常工作。
3、 根据《基站维护人员进出基站管理规定》形成基站维护人员管理办法。
4、将知识库、经验库固化在电子运行维护系统中，应用于日常工作。
二、巩固效果检查
小组统计了9、10月份，并于活动结束后继续监控了11、1 2月份的监控室平均故障预处理时长及人均预处理时长：
根据统计结果可见，活动成果在巩固期内得到了有效的巩固!
点评：
本次活动，小组全体成员全面运用质量管理的思想和方法，遵循PDCA循环的科学程序，从工作的各个细节出发，充分运用了科学的工具方法，经过5个月的时间，小组整理了包含5大专业、27种设备、近92个流程的监控专业手册及基础知识手册两套，汇总整理了监控制度一套，梳理了大量的监控流程，规范了各类相关工作，利用“短信互动平台”自主开发了一套软件管理工具，完善了基站门开告警的监控手段，为公司保证基站安全方面节省了大量投资。
本课题在总结材料中也存在着一些不足：在可行性分析中，把完全解决“初步操作时间较长”这个造成网络故障处理时间过长的结症，做为能完成本课题的依据不是很充分。这在后面原因分析中找出的末端因素，以及在实施阶段都没有用数据说明100％的解决了这个问题。另外在原因分析中找出的末端因素不是很科学。如：无故障处理考核标准、没有规范的故障处理流程都是不符合该中心的实际情况，虽然在后面要因确认过程中予以排出，但这种找末端因素的思路不是解决问题的思考方法。在要因确认表中没有确认标准，这就造成了后面用大量的文字叙述来解释，都不太符合QC小组成果总结的思路。因此，该成果还有很多需要提炼之处。
编辑／张君