中国移动渠道协同系统的设计与实现

摘要
近几年，伴随着电信业的迅猛发展，国内移动运营商间的竞争日趋激烈，为了取得行业竞争优势，移动运营商们采取的重要手段之一是提高面向客户方面的服务质量。

中国移动渠道协同系统是中国移动客服系统的组成部分，客服系统旨在提高客户服务的效率和用户的满意度，渠道协同系统的服务宗旨也在于此。

渠道是中国移动面向客户进行销售和服务的载体，各种渠道的集合构成中国移动营销服务网(例如客服渠道、营业厅渠道、短信渠道、宽带渠道、无线音讯互动服务渠道、网厅渠道等)。

本文根据中国移动湖南分公司客服系统的现状分析，为了实现各个渠道之间协同工作以提高客户的感知度和满意度，设计此渠道协同系统。

本文采用面向对象的思想，以统一建模语言为分析设计工具，对渠道协同任务处理过程中的相关业务进行详细的需求分析，根据需求和系统特点采用标准有效的软件设计架构来完成系统需求任务。

系统的主要功能包括业务请求接入管理、随机密码服务、协同调度管理、规则管理以及流程发布。

系统采用B／S架构模式，功能上采用多层次的软件功能架构，技术上基于MVC基础的Spring框架，以Java为编程语言，利用XML配置以及DAO、Hibernate等相关技术实现了渠道系统之间协同工作的业务要求，渠道协同系统通过WebService方式向外部渠道系统提供服务。

本文详细描述了系统的设计过程，包括系统类结构设计和数据库设计，从各个层面展现渠道协同系统的开发研究过程。

渠道协同系统的突出特点是处理的协同业务流程复杂纷繁，分支众多，并且业务流程多变，随时有添加协同业务流程实例的需求，针对这种特点，渠道协同采用工作流引擎技术处理业务流程，并且提供GUI配置界面，方便开发人员和非开发人员进行业务流程的发布和业务决策规则的制定。

这种体系架构大大提高了系统处理业务流程的吞吐量和执行效率，避免了大量逻辑判断的存在；增强了系统的可维护性。

该系统应用后收到了良好的效果，不仅提高了移动客户服务方的客户满意度，并且全面提升了移动的品牌影响力，有效的维持了老用户和争取了新用户入网，在一定程度上拓展了移动增值服务的市场。

第1章绪论
1．1系统开发背景
中国移动通信集团公司(简称“中国移动")于2000年4月20日成立，注册资本518亿元人民币，中国移动全资拥有中国移动(香港)集团有限公司，由其控股的中国移动有限公司(简称“上市公司”)在国内31个省(自治区、直辖市)和香港特别行政区设立全资子公司，并在香港和纽约上市。

目前，中国移动有限公司是中国在境外上市公司中市值最大的公司之一，也是全球市值最大的通信公司。

中国移动主要经营移动话音、数据、IP电话和多媒体业务，并具有计算机互联网国际联网单位经营权和国际出入口局业务经营权。

除提供基本话音业务外，还提供传真、数据、IP电话等多种增值业务，拥有“全球通"、“神州行"、“动感地带’’等著名客户品牌。

随着中国移动的发展壮大，对移动使用的客服系统也提出了更高的要求，逐渐加大对用户的服务项目，提升移动运营商的市场价值。

目前，移动增值服务成为移动通信的新的利润增长点，主要类型包括短消息、小区广播、WAP应用、多媒体消息和语音信箱等。

短消息业务近年来在中国发展迅速，取得惊人成绩并有望进一步拓展潜力；小区广播处于起步阶段；另外，多媒体短消息服务成为热点并且正在推出。

近年来，全球各运营商在语音业务方面的竞争日趋激烈，话音通信的利润空间日益缩小，移动通信网络的单位客户平均收益(ARPU)正在逐年下降。

ARPU的下降，意味着收益的减少和投资回收期的延长，这对于投资兴建新一代移动通信网络的运营商来说，无疑是一个挑战。

未来巨大的移动增值服务市场潜力，吸引了大量的服务提供商跳入洪流，一试身手。

现阶段，移动增值服务五大类基础业务发展得如火如荼，预示着一个新的服务经济时代已经到来，未来的体验经济时代亦杏帘在望。

究其本质，服务的核心存在形态是应用，高性价比的应用需要开放的软件系统平台承载，这将促使在未来的移动增值服务领域中，计算体系与通讯体系在无线网络环境下的完美统一。

所以，加强这些渠道的协作能力，将有力推动移动增值服务市场的发展。

中国移动渠道协同系统是中国移动客服系统的组成部分，渠道是中国移动面向客户进
行销售和服务的载体，各种渠道的集合构成中国移动营销服务网(例如客服渠道、营业厅渠道、短信渠道、网厅渠道等等)。

随着移动的发展壮大，面对庞大的使用移动产品的用户群，如何更好的对在网用户进行维系和挽留，提升用户群的满意率，加强服务效果，减少失散用户群，争取竞争对手用户，需要各个渠道之间的协同工作。

所以渠道协同系统就应运而生了。

1．2研究现状
目前，中国移动各个渠道系统之间都是独立工作的，存在着很多的问题。

比如在湖南地区移动服务存在着的问题：
问题一，顾客通过营销中心外呼业务介绍或者朋友介绍等途径对某项业务产生兴趣，于是打电话给移动客服要求办理，有些业务客服系统可以直接办理，但有些业务只能到营业厅办理，此时客服话务员会要求客户去营业厅办理，客户到营业厅之后，营业厅人员并不知道该客户要办理什么业务，只能通过询问客户需要办理什么业务得知，这样造成客户感知非常不好，并且使得营销部门的营销效果严重打折扣。

问题二，营销中心通过号码10086外呼向目标客户进行营销推广，或是因欠费提醒电话。

但因客户没有接到电话而未完成，客户回来看到手机上有10086电话来电显示，并回拨电话查询来电原因(用户回拨10086直接连接到移动客服)，客服接到电话后，不知道客户来电原因(客服方面不知道营销中心外呼需要向客户推销什么)，而无法给客户一个满意的答复，造成客户对客服产生负面印象，也使得营销效果大打折扣。

在营销、终端资源预约等方面也存在类似情况。

这就要求建设渠道协同系统来完善这些问题。

1．3本文的主要工作
本文主要对渠道协同系统的设计和实现进行描述，分析了系统开发的背景及业务场景，
采用典型的软件设计方法进行系统的设计，主要分需求分析阶段、系统架构设计、详细设计和实现几个步骤，论文对这几个阶段分别进行描述，在各个环节上展示系统的设计和开发过程，对系统的技术难点即协同调度处理过程和重点功能进行了更一步的叙述，更深层次的展现开发研究的过程，并通过实现部分描述系统功能实现情况。

具体内容分以下几个部分：
1、背景分析，渠道协同系统是中国移动客服系统的组成部分，渠道是中国移动面向客户进行销售和服务的载体，这部分分析了目前各个渠道系统之间没有实现协同工作的现状，由此获取渠道协同的需求；
2、需求分析，该部分将功能性需求分为了几个部分进行详细的阐述，并通过UML建模的方式对需求进行分析描述；
3、系统设计，对渠道协同系统的软件体系架构和系统功能结构进行设计，以需求分析作为依据，将系统所采用的技术架构和功能架构用UML包图和序列图等进行详细的描述；
4、详细设计，设计系统实现的类组织结构，分析系统业务信息以及调用关系，对业务建立实体类，并类和类之间的联系，分析业务请求信息和业务处理过程，进行数据库表设计；
5、系统实现，整合各个实现框架，通过xml配置参数，利用工作流引擎实现业务预约的流程，以及环节配置和流程发布的方法和过程。

1．4本文的组织结构
第l章绪论，首先描述了系统开发背景和研究现状，其次描述了本文的主要工作。

第2章需求分析与获取，首先对业务进行总体描述，其次描述本系统的目标和需要解决的问题，最后对需求分析按照功能需求和非功能需求两个类别进行描述。

第3章是系统概要设计，首先阐述了系统的软件架构设计，阐述系统所使用的技术；其次，
详细描述了系统功能架构的设计。

第4章是系统的详细设计部分，主要描述了类结构设计和数据库的详细设计。

第5章主要描述了系统的实现和测试，针对系统实现过程中的主要流程配置和解决的技术问题进行了阐述。

第6章总结与展望部分，对本文进行了总结，并对下一步的工作进行了展望。

第2章需求分析与获取
2．1总体系统描述
移动用户接触的渠道有：客服、营业厅、短信、网厅等。

渠道协同系统对用户不可见，系统外部关系图如图：
渠道协同与CRM(即营业系统)核心业务逻辑关系：渠道协同向营业系统核心组件转发其他渠道的服务请求协同，营业系统核心业务组件处理服务请求；同时营业系统核心业务逻辑也可以向渠道协同申请其他渠道的协同处理，共同完成客户服务处理逻辑。

渠道协同与RBOSS(即账务系统)核心业务逻辑关系：渠道协同向账务系统核心组件转发其他渠道的服务请求协同，账务系统核心业务组件处理服务请求；同时账务系统核心业务逻辑也可以向渠道协同申请其他渠道的协同处理，共同完成客户服务处理逻辑。

渠道协同与统一接口平台关系：统一接口平台向渠道协同申请业务协同处理，渠道协同系统负责协同的拆分，转发及跟踪管理。

系统框架图如图：
系统描述：
规则元数据管理：规则元数据是对协同规则参考因素的定义，包括元数据类型定义，取值约束，取值来源等；元数据是协同处理的数据基础。

协同规则管理：协同规则管理实现协同处理规则、流程节点、动作、执行路径等相关协同策略信息的管理。

在渠道协同管理中使用工作流引擎来实现协同规则的管理。

协同调度：协同调度是渠道协同的执行引擎，支持异步和同步处理两种模式。

负载均衡管理：渠道协同系统实时收集各电子渠道业务处理量和性能指标(排队量、业务处理量、处理时长)及经验负载情况分析信息进行渠道业务转发，实现跨渠道的业务负载均衡。

请求转发：业务请求转发内容包含客户通过渠道提交的业务请求，以及营业系统中的市场营销、销售、客户服务功能域发起的业务请求。

转发的方式支持异步、同步两种处理模式。

随机服务密码管理：随机服务密码管理功能使渠道协同系统各电子渠道和实体渠道提供的一项基础服务功能，主要是通过快速的短信方式协助其他渠道快速获取随机密码。

随机密码功能支持密码生成，密码验证，密码有效期管理等。

预约管理：预约管理功能是客户通过电子渠道申请到实体渠道的预约服务。

通过与实体营业厅的排队系统的接口，可为客户提供快速业务办理通道。

业务协同管理：业务协同管理是指将业务处理流程分解，由渠道协同负责渠道／跨渠道接触调度来完成客户服务功能；业务协同管理典型的应用有业务办理短信通知，客户二次确认等。

协同内容管理：主要实现服务转发或业务协同时各渠道之间的内容的转换，生成，加工等。

接口管理：接口管理完成协同调度逻辑与相关渠道和营业系统核心业务逻辑之间的交互；交互接口要求是同步调用接口。

渠道协同总体需求如下：
1．接收各个渠道的跨渠道业务请求信息；
2．针对不同的业务请求信息进行转发或处理；
3．对业务协同流程进行监控；
4．提供同步的随机密码服务。

2．2系统目标和解决的问题
渠道协同系统要实现与渠道基础平台的连接，实现客户接触过程中的连接、监控、异常等管理与控制，并根据客户或业务需要实现跨渠道的业务请求接收、拆分、发送、监控功能。

协同调度根据协同逻辑对来自各渠道和营业系统内部的协同请求进行解析、分解成各渠道的协同任务及其执行策略，并根据渠道特性对协同任务进行封装后发给渠道执行。

如下图所示：
当一个协同任务产生时，渠道协同系统根据业务情况进行协同处理，比如业务预约这个案例，如下图所示，渠道协同系统要达到这样的功能。

业务预约场景中，渠道协同作为一个信息记录和转发的中心，有效的将多个渠道在业务办理流程中串接起来，为实现闭环化的服务能力提供了技术可能。

另外，渠道协同系统要对协同处理过程进行监控，针对异常情况做出反应，或告知用户或进行相关的处理，并且用户可查询到协同处理状态。

渠道协同系统本身要有一定的健壮性，对多变的业务规则的现状有较高的适应性。

2．3系统需求分析
软件开发的目标是在预算内按时开发符合客户真正需要的高质量软件。

需求分析主要通过建立模型的方式来描述用户的需求，为客户、开发方等不同参与方提供一个交流的渠道。

这些模型是对需求的抽象，以可视化的方式提供一个易于沟通的桥梁。

用户需求的分析与用户需求的获取有着相似的步骤，区别在于分析用户需求时使用模型，以获取用户更明确的需求。

分析用户的需求，需要执行下列活动。

通过建立图形，描述系统的整体结构。

渠道协同功能结构图基本如下：
渠道协同系统按功能分可分为业务请求接入管理、规则管理、随机服务密码、协同调度处理、流程发布五个功能模块。

2．3．1系统功能性需求
系统的核心功能大致分为：
接入。

主要实现将接收到的协同请求以一定的数据格式保存在系统中；
请求处理。

主要实现将渠道请求分解成各个系统能够独立施工的子任务，并与之交互。

然后回写处理结果(如果有需要进行回写的话)；
请求回复。

根据各个协同渠道的处理结果，向源请求系统发送处理结果。

系统总体状态图如下：
详细分析系统的需求可以归纳为以下几个方面：
1．接入管理
完成来自其他渠道的协同请求接收，并形成协同请求实例。

在渠道协同中，所有交互用到的数据都要满足元数据要求，因此从协同请求接口中接收到的请求数据，都转换为元数据格式，然后保存到业务请求数据表。

每个协同请求实例数据都以统一的“数据语言’’(元数据)进行表达，形成“数据池”。

因此在处理过程中各环节都可以从访问数据池中的数据。

为了避免错误的请求进入渠道协同平台，在接收请求的时候，还会进行如下逻辑判断：
(1)权限认证：为欲接入的渠道配置一定的权限(如认证密码等)。

权限以及渠道信息存储在数据库表里，建议认证密码以密文的方式传入。

(2)冲突检查：为避免重复的业务请求，渠道协同应该提供冲突检查的功能。

将其设置为数据库表里的一个字段，在冲突检查的时候结合数据库表里的相关字段来进行验证。

业务流程如下：
2．协同调度处理
协同调度完成协同请求的分解及调度功能。

这部分是渠道协同的核心功能，除了协同请求的分解之外，还有分解后的协同任务与各渠道交互的功能。

协同调度管理完成两大部分的功能：
(1)协同请求分解及协同
通过建模的过程将协同请求进行分解，并通过分解后的各个环节来完成各个协同任务的协同功能。

(2)协同任务处理
在流程中的各个环节，都完成对应的协同任务。

在渠道协同中，可以通过自动的方式将协同任务发送到其他渠道进行处理，也支持通过手工的方式完成协同任务处理。

对接收到的协同请求处理过程大致如下：
在接收到协同请求之后，根据流程模板适用规则，匹配到正确的流程模板，并通过工作流引擎的接口，创建流程实例，并开始进行调度。

协同逻辑是在流程模板上实现的，在匹配流程模板的过程就是选择分解规则的过程。

每环节的协同任务处理是需要根据各个业务逻辑来实现的，在渠道协同中环节执行功能定义就是配置每个环节处理协同任务所需要执行的功能。

另外，协同请求的元数据适配也是在协同调度过程中完成的。

在每个环节的协同任务开始处理之前，由系统根据数据提取组件来获取该环节配置的元数据，并维护到协同请求的数据池中。

业务流程如下：
对于渠道协同平台来说，预约服务管理也是一种特殊的渠道协同服务请求管理，渠道
协同平台只是按照需要将这样的请求转发给相应的渠道平台即可。

下面将通过预约服务作为特例讲述一下协同调度处理的过程：
预约是指客户通过各个渠道申请预定服务或资源等，并由电信运营商在预约保留期内提供此项服务的过程。

预约服务涉及多个渠道，工作人员的协同工作；
预约服务管理在渠道协同的处理模式上属于异步处理模式。

在预约服务管理流程中，针对预约任务的执行，工作流引擎负责预约业务流程的执行控制。

流程描述如下：
(1)渠道协同系统接收预约请求，根据预约请求的处理规则，生成预约处理任务单。

(2)协同调度进行执行任务类，调用规则配置接口，启动预约执行流程，工作流引擎开始执行业务流程。

(3)工作流引擎向资源配置模块发送资源配置请求，等待资源分配。

(4)资源配置模块完成分配后，调用渠道协同预约资源确认接口，触发流程继续执行。

(5)工作流引擎触发生成预约编号，并发送预约办理短信。

(6)客户根据预约短信到营业前台进行业务办理，输入预约编号，查询预约信息后进行相关业务办理。

业务办理成功后调用渠道协同预约成功接口，触发渠道协同预约流程继续执行。

(7)回写预约任务单执行状态。

业务流程：
3．随机密码管理
随机密码服务是一种同步的协同业务请求，按照上述业务流程处理接口。

随机服务密码管理功能是渠道协同系统提供的基础功能，系统功能包括服务密码的生成管理，随机服务密码的有效期管理，服务密码的验证管理等功能。

平台接收到随机服务密码生成请求后，生成一条记录到数据库表，其有效时长通过系统参数配置。

随机密码生成后需要通过短信网关将短信发送给密码发送给用户。

随机密码验证步骤如下：
(1)接收到随机密码验证请求：
(2)根据输入参数获取系统中的随机密码；
(3)判断随机密码是否过期，若过期，转5；
(4)验证密码是否正确；
(5)向短信网关发送密码验证结果。

业务流程：
4．管理规则
（1）环节参数配置
流程模板发布之后，通过触发渠道协同系统流程发布回调接口，保存流程模板信息和模板相关的环节信息。

通过配置信息，可以通过模板名找到与之对应的环节，通过可视化的配置，对每一环节进行规则配置(即配置每个环节的调用接口和对应参数)
(2)元数据管理
元数据管理主要是针对渠道协同中涉及到的参数进行管理，此功能目的主要是维护系统中参数一致性，保证各个渠道在协同工作时的参数一致。

(3)协同决策规则管理
协同决策规则主要是对接入进来的业务请求适配相应的流程模板。

要制定出匹配规则
即协同决策规则，以业务请求的相关字段匹配不同的流程模板，也即配置渠道和业务请求对应的模板。

主要功能有：渠道协同决策规则的配置(增加，修改，删除)、渠道协同决策规则的查询。

5．流程发布
渠道协同系统提供图形化的发布流程方法，这样使得开发和维护变得简单，非开发人员也可以制定业务流程，通过流程发布工具发布业务流程并进行参数配置，使整个系统更加灵活，发布流程的过程如下图：
使用渠道协同来实现协同业务将变得更为简单。

大概需要实现下面的几项工作即可：
(1)制定协同请求处理流程
使用jbpm提供的建模工具，根据协同业务要求，制定协同请求处理流程。

因为这是图形化的工具，所以使用起来非常简单。

(2)开发各环节与渠道交互的组件
编写各环节协同任务处理组件，即环节与各渠道交互接口组件，在该组件中完成本环节的协同任务处理。

(3)定制协同请求规则数据
包括配置各环节使用的元数据、各环节执行的组件、流程模板的适用规则
上述3个步骤，只有第2个步骤是需要开发的，其他步骤都可以通过配置完成。

2．3．2系统非功能性需求
非功能性需求分为几个方面：
1．性能方面。

响应时间。

分日常交互类、日常查询类、批量处理分别考虑。

日常交互指传统的大量交互业务，以及一次完成多笔业务处理的交易，日常交互类业务具有较高的响应要求。

查询类业务如查询业务处理状态、查询业务规则信息等。

查询业务由于受到查询的复杂程度、查询的数据量大小等因素的影响，需要根据具体情况而定，给出一个参考范围。

批处理业务如批处理业务转发等业务处理，该类业务处理复杂、操作数据量大、处理时间长。

响应时间指标包括：平均响应时间参考值(秒)、峰值响应时间参考值(秒)。

吞吐量。

系统交易量的估算。

指标有年交易笔数(笔／年)、高峰期交易笔数(笔／天)。

数据存储量。

每年的数据存储容量及未来几年该数量的预期(增长)值。

指标包括累计存储容量、年增长。

2．系统可靠性：
渠道协同系统应该满足7×24小时都可以使用，客户在任意时间发出的协同请求都能够及时处理；
3．可扩展性：
可实现负载均衡；日后若信息量较大，则系统可相应增加服务器实现扩展。

并且针对。