快速开机、快速停机,提升客户服务

1、快速开机、快速停机 ,提升客户服务北六省 BSS4.2 系统上线后，固网、移网用户合并在 一个系统中处理，数据量激增到原来两个系统之和，仅每月 月初开帐后产生的应停机用户量就高达 280 万到 350 万不 等，与北六省其他 5 个省分公司（北京，黑龙江，辽宁，山 东，河南）相比，要多约 100 万数据。以 2013 年 3 月份数 据为例，用图形展示如下：集中的停机会导致用户来集中缴费开机，缴费开机工单 积压严重，曾经发生高峰时积压在账管侧的开机工单达上万 条，引发大面积的投诉，影响服务质量。所以只好将停机工 单分散在几天里逐步执行。每月 2日到 5 日集中到晚上执行 信控停机操作，每晚停大

2、约 60 万到 100 万用户量，但时间 延后的停机同样会降低用户满意度，还会形成欠费。分析至 此，我们发现系统似乎陷入了集中停机会导致开机积压，分 散停机又会导致欠费增加的两难境地。为走出两难困境，在随后的几个月时间里，我们不断尝 试各种解决方法，虽然效果并没有想象中的明显，但也都起 到了相应作用，有一定的借鉴功能。下面以图示简要说明。在不断尝试的过程中，我们发现即便将影响停开机的周 边因素都解决掉，如已经建立了镜像库，耗用大资源的接口 数据提取已经转移到镜像库，但如果停开机本身程序不做彻 底优化，在月初停开机工单积压问题的解决上仍不会有明显 效果。没有办法之际，我们在应对开机积压问题时甚至

3、采用过 费时费力的纯人工方式，在积压环节将积压的开机清单取 出，填上必要信息，由服务开通系统直接发往网元，或者直 接提交给交换机房，由交换机房在交换设备上直接开机。这 种人工干预的方式可以快速开机，能缓解客户投诉。但也有 明显的缺陷，人为处理，效率低下，处理不及时，只能在用 户大面积投诉时，才能被动处理，积压的开机单仍会按正常 程序流程继续流转，带来不必要的重复开机工单，徒劳消耗 系统资源。我们在保证现有系统稳定，保证信控功能准确的原则 下，分析当前信控停开机流程和处理逻辑，确定快速通道的 业务逻辑和流程，实现思路如下：一、鉴于硬件资源、系统设计和客户感知的不同需求， 并且河北月初产生的大多数

4、停开机工单都是移网用户，所以 将固网和移网流程分开处理。固网按原流程执行，移网按优 化后流程执行。二、对 BSS4.2 系统信控功能中现有的处理停开机工单 的这部分程序做最小变动，避免影响信控的正常流程。三、基于现有信控停开机操作流程长的特点，尽量缩短流程，减少瓶颈通过分析工单指令逻辑，并调优各模块功能，快速停开 机通道流程去掉了 BO，IOM 系统，从环节上减少 2 个，可 以从根本上提高处理效率。在确定了减少工单处理环节的基本思路和调优方向后， 河北先以快速开机为切入点，解决当时最紧迫的客户缴费开 机延时问题。首先，账管系统做为快速开机通道功能的源头，单独增 加了快速开机程序，实时扫描用户

5、的开机工单，对符合发送 条件的开机工单直接发送至 CRM 侧并等待 CRM 后续处理。 同时定时扫描 CRM 侧工单处理情况， 及时将 CRM 状态信息 进行回写。发送开机工单和同步用户状态实行异步松耦合操 作，同时减少非必要的校验流程，极大提高了开机效率。原处理模式生成开机工单数据到信控表，调用 CRM 侧 的 TUXEDO 服务发送到 CRM 系统中， 在月初繁忙时， CRM 侧的 TUXEDO 服务因为还要处理其他营业单，经常发生拥 堵，甚至服务堵死情况都时有发生。快速开机处理模式则将 开机数据生成到一个中间表，通过 DBlink 方式直接写入 CRM 系统中，避免了 TUXEdo 服务

6、拥堵问题。其次， CRM 系统采用在系统功能外增加一个全新的业 务处理逻辑，采用定时任务多进程调用数据库存储过程方 式，每 30 秒扫描一次待处理数据，单进程一次处理500 条记录，最大限度提升处理数据速度。该系统着重解决两个问 题，其中又以第一问题为重点， " 快速准确获取开机数据其他 必要信息 " 。为提高效率， CRM 系统简化了处理逻辑，主要 体现在，对于网元指令需要的 GPRS、WLAN 服务信息只判 断是否存在。对于判断同一号码开机单之前的未竣工工单， 只判断影响用户状态的定单，而对于产品变更类的定单则不 影响开机单的执行。 第二个问题 " 开机成功后

7、完成后续处理 "， 在 NAS 系统将反馈结果回写到 CRM 后， CRM 系统采用直 接更新状态，同时同步账管数据方式，避免了CRM 侧的定单竣工处理逻辑，既提高了效率，同时又减轻CRM 的竣工处理系统 BPS 的压力。原处理模式发单时 TUXEDO 服务将信控单写入订单受 理表中， BO 接口读取；返单时， BPS 进行竣工处理。 BPS 作为一个复杂的逻辑处理功能点，效率无法保证。快速开机 处理模式在发单时由定时任务处理接口表中的数据；返单时 定时任务只更新用户状态，无需使用BPS，处理效率提升明显。最后 NAS 系统，即服务开通系统，将原来 IOM 系统指 令处理逻辑加以改造

8、，将处理营业受理单部分的逻辑去掉或 简化，直接从 CRM 系统中提取待处理数据，放至网元工单 表，由原有的提单程序进行处理，很好的与原系统融合在一 起。服务开通系统采用 WEBSERVICE 方式， 实时扫描 CRM 系统中等待处理的开机工单，直接写入服务开通系统中，采 用入库即发网元的方式，简化流程，提高效率。为不影响原 有信控流程，程序调优后新增了后台进程处理快速通道单， 对已经在网元平台处理完成的数据进行回单处理，将结果反 馈到 CRM 系统。快速开机通道的实施方案在 5月3日启动，5月 10日完 成系统调研进入开发阶段， 5月 27日进入联调阶段， 6月 2 日割接上线， 6 月 3

9、日正式启用，各个环节密切配合，关注 信控类投诉，及时发现问题，及时解决。程序上线后，河北采用先试点再全省方式逐步在全省运 行；前两月快速开机通道功能在每月月初都会按时启用，该 功能可以实现无人干预下正常稳定运行，在开机单积压时启 动，可以起到立竿见影的效果。运行平稳后，河北已于 8 月 份将快速开机通道作为常驻程序运行，情况稳定且效果显 著。快速通道功能在 6 月份处理开机单总量： 55042，7 月份 处理总量： 48149，共计 103191。快速通道中信控开机单整 个流程平均历时 170 秒，用户感知时间平均时长 80 秒，较 之前 5月初的平均历时 3689 秒，有了极大提高。在解决了集中缴费、开机延时的严重问题后，河北又把 关注点落在移网用户欠费率较高、移动客户离网率较高的严 峻现况上，希望通过账后及时停机，减少客户欠费，提升客户感知，提高客户满意度，从而提高在网率。有了快速开机通道的先例，再做快速停机就水到渠成了。利用快速开机通道平台，各模块添加上停机判断逻辑及 各种复合停开（先停后开或先开后停等）判断逻辑。快速通道中增加停机功能的实施方案在 9月 17日启动，9月 22日完成系统调研进入开发阶段， 9 月 26日进入联