基于CRM系统重构方案的实施与研究

时间:2022-03-20 06:47:21

基于CRM系统重构方案的实施与研究

摘 要

随着通信网络科技的不断演进和发展,融合业务和电商时代的到来,作为运营商核心计费系统,上海移动的核心系统模型迄今已有10年,面临着核心模型过旧、系统开放性差、配置化率低、全业务受理分散、实时信控精确程度不足等困难,本文主要通过对CRM&BOSS重构项目的方案及实施进行深入研究,较全面阐述了上海移动CRM系统重构方案和技术应用亮点。本次重构项目涉及70多个子系统的相关改造、2000多个功能菜单的梳理和开发测试、2200多个平台接口的联调测试、2500多万用户数据的割接,创造了用一年半时间同时换掉CRM&BOSS的纪录,创造了割接后的一周就能上线新业务的纪录以及成为第一个将“云”架构的BOSS系统用于生产系统的省公司。

【关键词】上海移动 CRM BOSS 重构 SOA 云架构

1 项目概述

1.1 项目背景

近年来,上海移动在集团公司领导、本地技术发展规划驱动下,结合本地的用户及业务特点,进行了多项CRM/BOSS系统的优化和能力提升工作,现有CRM/BOSS已经能较好支撑业务运营发展,但也客观的看到离“成就客户卓越”的目标还有一定距离,同样,对于需求越来越迫切的全业务营销、互联网转型也逐显心有余而力不足之境。

上海移动CRM/BOSS系统主要面临的问题有:

核心模型过旧:上海公司核心系统模型迄今已有10年,期间做了多轮优化,但核心模型并未发生根本改变。对融合业务支撑不足,导致在现网系统中,个人业务、固网宽带类业务彼此独立,流程分散,业务打包能力较弱。单笔融合业务操作,需要用到数个菜单完成,不利于融合业务的发展。

系统开放性差:在移动互联网时代、电商时代,系统对CRM、BOSS的接口开放能力要求与日俱增,实现从点对点支撑到点对面支撑的转变。腾讯、百度、亚马逊、淘宝、DoCoMo公司已纷纷推出能力开放平台实现对移动互联网长尾生态链的点对面支撑。而目前上海移动系统的开放性远远达不到能力开放的要求。

配置化率低:现系统对个人业务支持比较顺畅,但对固网业务、家庭宽带业务、捆绑销售等新兴业务的配置化能力明显不足,业务规则配置点比较分散,缺乏有效的配置管理手段。对跨流程的融合业务需要逐个开发。

实时信控精确程度不足:现网计费、优惠、分账、扣款完全分离,话单采集后经过多次落地,无法对在线计费用户提供精确计费和信控能力。

1.2 上海移动业务支撑系统的发展和现状

2008年,BBOSS框架升级,提升集团客户业务支撑能力;NGBOSS一期项目,实现业务功能的初步整合;创新的双屏营销管理系统项目,提升营业厅服务水平。

2009年,营帐解耦,迈向客户与产品运营分离;PBOSS建设,领先支撑家庭宽带业务;ESOP建设,实现集团客户经理的工作台。

2010年,计费帐务优化余额管理,实现实时帐务,NG2-3.0规范实施。

随着移动通信业务的发展、客户服务以及内部管理的需要,上海移动业务支撑系统在不断的壮大、完善。现有的CRM系统涵盖OP/工作平台、渠道基础平台、(代销)渠道管理、客服中心管理、营业厅综合管理、营业厅双屏系统、BBOSS、营业、家庭宽带支撑系统、投诉管理系统、CLM、CBOSS、营销管理系统、集团商管理系统、统一客户视图、统一资源等系统模块。

现有CRM系统生产环境统一部署在钦州机房,数据层采用SRDF实现金桥机房的异地容灾。前端的web通过RADWARE实现接入负载均衡。应用服务器分组部署实现现有BOSS30、BBOSS、DSMP等后台应用,并通过应用中间件集群技术实现负载均衡。数据库采用RAC,BOSS30数据库主机承载现有所有CRM应用数据。

1.3 重构项目研究目标

目前采用的是按业务垂直建设系统的模式,现有系统技术架构与数据模型的难以扩展限制。业务支撑能力的不足。全业务捆绑营销的模式难以有效支撑,移固捆绑、个人与企业组网营销等都需要跨系统操作,人工判断因素较多,易出错。架构扩展能力的不足。以个人业务支撑为主的BOSS30构建于2002年,缺少订单模型概念,难以支撑融合业务和长流程业务订单分解与处理。开发响应能力的不足。捆绑业务的实现大多通过代码开发实现,对捆绑业务的配置能力较低,开发周期较长。跨业务捆绑需要对多个系统进行设计开发,增加开发难度,增加出错概率,维护成本加大。

针对目前系统面临的不足,确定了CRM&BOSS重构项目方案的整体目标如下:

业务目标:实现全业务统一产品管理;实现融合业务受理能力;支持长流程过程中三户异步创建的模式;满足集团分散帐期的支撑能力;支持互联网等电子渠道的营销与业务办理能力。

系统目标:提升系统配置化支撑能力,降低维护成本,提升业务快速响应能力;提升系统高可用能力,满足业务连续性要求;提升系统的可扩展性,实现应用层能力可平滑扩展,提高应用资源调配方便性;提升系统的安全性,增强系统访问日志管理,记录数据访问痕迹,加强系统敏感数据安全控制。

2 CRM重构研究思路及实施方案

2.1 新CRM系统应用软件总体思路

建设思路:主体重建、周边稳定。

重构全业务运营密切相关的产品管理、业务受理、营销资源管理和客户管理功能;

完成上述功能数据模型、技术架构、应用功能的全面升级;

CRM域内其他管理功能如代销渠道管理、集团商管理系统本期原则上维持现状配合改造;

周边的电子渠道类系统、其他后台管理类系统维持现状配合改造。

主要内容包括:

整合业务受理功能,实现一站式业务受理;

整合订单管理,实现统一订单管理;

整合客户管理,实现个人、家庭、集团客户融合管理;

整合产品管理平台,实现移固产品统一管理;

保留CBOSS与集团一级系统接口枢纽功能;

整合终端销售至综合业务受理,终端营销管理至产品管理;

重构营销活动管理,接管交叉销售功能;

重构积分管理,接管统一积分功能;

新建资源管理,割接统一资源SIM卡、号码资源、手机终端资源数据,保留其它统一资源的其他资源管理功能;

新建权限管理,实现新建CRM系统内部各功能模块的统一权限管理,保留统一权限对其他保留系统的权限管理功能;

继承或优化所有被割接系统或功能与外部的接口。

2.2 应用软件方案

2.2.1 统一的产品管理

提供移动、固网、数据、集团组网、移固捆绑、集团群组、家庭群组、营销活动、终端销售等所有面向客户销售的产品/套餐的统一配置管理,并提供销售纬度、统计纬度等的产品分级目录管理。

产品管理提供统一对外服务,实现营业受理、渠道销售的统一访问,并实现与BOSS、PBOSS等系统的产品映射。

产品管理采用缓存技术,实现产品服务与内存数据的解耦,提升产品的访问速度。

2.2.2 融合业务受理

整合原有BOSS30、BBOSS、HBOSS、DSMP、CBOSS系统,形成全业务融合受理平台,集销售管理、订单管理、客户管理、产品管理及统一工作流管理于一体。

提供一站式业务受理界面;

提供购物篮式订购信息;

提供快速菜单搜索引擎;

提供快捷常用菜单设置。

2.2.3 统一客户管理

统一模型:以客户基础模型为中心,扩展不同类型客户的特征信息;

唯一标识:客户在系统中存在唯一标识,用于客户的识别和认证;

统一服务:客户数据对外提供统一的服务;

个性化展现:针对不同的业务场景提供不同的展现内容模板。

2.3 新CRM系统应用部署总体思路

2.3.1 总体目标

业务支撑方面:可在CRM重构项目上线后,提供对近3000万规模用户数的业务支撑能力,并能够满足移动后续业务发展的需要

稳定、可连续方面:系统在web、app和数据库各个层面都具备高可用性,确保系统不存在应用的单点故障 ;具备快速的容灾回复能力和平滑扩展能力。

能力提升方面:通过web、app应用的集群部署、前后台应用分开部署、产品应用独立部署等方式,提升系统整体处理能力

2.3.2 总体思路

机房部署:结合新CRM系统技术架构的特点,WEB和APP采用双中心部署模式,实现单中心故障不影响应用访问 ;数据库存储采用现有SRDF技术实现异地容灾,并借助数据库的恢复技术和应用级的快速切换能力实现快速应用恢复。

服务器设备高可用:Web服务器通过Radware设备进行负载均衡,部分服务器故障不影响系统应用;App服务器基于中间件的集群方式实现跨机器的cluster,部分服务器故障不影响系统应用;Web集群和应用集群基于J2EE中间件实现,相对于WTC的连接方式更加灵活、高效;DB服务器采用ORACLE-RAC双节点方式。

应用部署高可用:

(1)对于浏览器->WEB->APP->DB的调用,考虑到越到后端网络流量越大(如APP->DB流量最大,WEB->APP其次),优先对后端的应用部署结构进行均衡优化,不可优化的情况下再对上一层的应用部署结构进行优化的总体策略进行应用部署。

(2)Web应用部署根据访问区域分为DMZ和DCN,保障外网访问的安全性控制,同时考虑降低各渠道WEB访问的相互影响,原则上分离部署不同渠道、不同应用WEB。

(3)App应用部署根据访问渠道和接口(营业厅、客服、IVR、社会渠道等)的安全等级和业务量大小,划分不同的应用集群组,渠道之间互不影响,故障可以隔离。

(4)集群内app应用服务访问指定的数据库实例,避免RAC-WAIT的问题。

(5)App应用集群组中单独一组备用服务,当某个渠道的应用服务出现故障或者压力过大时,可以将备用服务加入集群,灵活地扩展应用处理能力。

2.4 应用部署具体方案

2.4.1 WEB层

根据提供的终端客户类型和应用访问类型不同,分为营业厅WEB、客服WEB、渠道WEB和产品配置WEB和单点登录集群。

每个集群跨两个中心机房在两台设备上进行部署,实现WEB访问层的负载均衡和容灾能力

2.4.2 接口层

根据外部接口对象的不同,分为BOSS接口、IVR接口、电子渠道接口、CBOSS/DSMP接口、其它接口和系统监控接口

每个集群跨两个中心机房在两台设备上进行部署,实现WEB访问层的负载均衡和容灾能力

2.4.3 应用层

根据应用的对象不同,划分为多营业应用、客服应用、渠道应用、IVR接口应用、电子渠道接口应用、CBOSS/DSMP接口应用、其它系统接口应用、备用中间件、CACHE和工作流后台进程集群组,每个集群跨两个中心机房设备上进行部署,实现WEB访问层的负载均衡和容灾能力

2.4.4 数据库层

考虑避免跨库事务处理的风险,在现有业务量尚未达到系统处理瓶颈的前提下,考虑投资优化等因素,暂不考虑跨机房的分库部署,但从长远考虑本期项目将CRM系统数据库进行物理拆分,分别创建基础和营业2个物理库分别部署不同主机,降低单库数据访问压力。

3 CRM系统重构方案中的关键技术

3.1 新CRM系统的主要数据模型设计

3.1.1 产品模型

将资费、服务作为产品的属性,支持多角色策划,支持账务资费重定义、优惠资费重定义、免费资源重定义,对产品前项后项进行清晰限制。

3.1.2 客户模型

BOSS30目前是一个帐户可以有多个用户,客户和用户的关联关系是一对一的关系。

新CRM客户模型设计参照SID的参与人Party模型设计,一个客户可以有多个帐户,一个客户有多个用户,用户与帐户通过帐务关系建立对应关系。新CRM的客户模型更体现以客户为中心的概念,也可以更好的支持客户融合业务的支撑。

3.2 新CRM系统的标准SOA体系架构

新CRM系统采用全新设计的分布式体系架构实现应用层的灵活与平滑扩展能力,并通过强大的系统管控功能极大提升系统的可管可控运维管理能力。

标准SOA体系架构设计。

提供二级路由访问控制功能:一级服务调用路由实现了web层调用应用层的访问控制,将业务实现和系统部署隔离开来;二级数据访问路由实现了应用系统对数据的访问控制,将业务实现同数据分布进行了隔离。两级路由控制实现web、应用和数据库部署的松耦合,提升系统的部署扩展性,具备多中心部署能力,支持数据的分布式部署。二级路由均采用动态域名方式,借助智能DNS实现物理IP地址的快速切换,以及服务访问的多路径设置。

应用服务基于工作流平台,将各类进过封装的业务组件,并通过可视化的BCE业务生成环境进行服务组装,实现业务流程的配置。

系统管控实现对系统所有服务的注册管理和服务关联性管理,并对服务的运行进行监控和管理,提高系统可维护性。流量控制根据前台、后台服务的优先级别和时效性要求,合理调度服务运行的时机,保障系统的稳定性。

数据库可按照地域和数据类型进行拆分。 对于特定类型的数据,引入数据缓存结构,提高数据访问效率。

3.3 新CRM系统与外部系统关系

CRM系统与系统的集成技术主要采用ESB和CRM统一接口2种方式,其中: ESB技术应用于实时同步的Webservice等服务接口, ESB侧的实时交易并发处理性能问题由ESB厂商保证。CRM对外统一接口应用于界面接口、数据接口、异步服务接口。

3.4 CRM系统的技术特点

3.4.1 应用服务器负载均衡实现系统的高可用性

通过ViewList同步机制、 长连接实现机制和CLUSTER机制保障。

3.4.2 多级缓存技术提升系统处理效率

对于数据量交大的缓存数据,如产品数据缓存,引入MemryCache管理工具,提高大数据量的访问效率。CAP(Customer、Account、ProductInst)将客户、账户和产品实例的路由表示,提供应用使用进行路由判断。对于轻量级的数据,如权限、静态类型等,数据量不大,直接放在JVM的缓存里,通过底层平台提供对外服务。

3.4.3 对外接口的集中化管理提升外部接口适配

所有的对外发送的接口都配置在CRM业务逻辑中,作为流程中单独的节点进行处理。发送接口的任务通过按照统一的数据格式进入接口队列,根据不同类型的接口,定义不同的队列,对应不同的接口调度策略。

对应接口的协议类型,开发不同的接口适配器,提供不同的接口发送服务。

集中化的接口管理收敛了接口实现,利于接口的统一监控和管理,同时在部署上更加灵活,可扩展。

3.4.4 批量管控分离式设计保障前台业务稳定

批量管控平台提供对批量任务的处理调度和进程控制,针对不同类型的任务提供TF、TASK、FTP三种处理框架。

3.4.5 服务框架实现全方位服务管控

系统对外的所有服务,都是通过服务框架提供的,每个服务在服务框架中有唯一的服务定义。服务框架主要包括: 接入管理、服务注册、服务、 服务监控、服务升降级、日志管理、异常管理。

3.4.6 作业调度平台实现后台应用的集中管理。

包括命令管理 、流程管理、流程调度、系统监控 、运行情况分析、便捷化运营管控设计极大提升系统运维能力。系统底层平台实现监控信息输出,开发人员不用关心监控实现。采用内存实时刷新机制,避免海量日志文件的产生给系统带来的影响。

3.4.7 自动化的应用版本可降低人工出错的概率。

实现开发与部署分离,允许开发时环境可以与运行环境部署方式不一致。开发人员无需考虑系统实际部署情况。通过平台进行集中,实现的流程化,可监控化,可管理化。分布式并行部署,所有设备的并发进行,节省时间。

BCE业务框架有效沉淀业务组件、提供快速组装开发配置框架,提高系统开发效率。业务生成环境(BCE)借助SOA架构体系收敛系统中各类应用功能,构建出可复用的、基于标准的业务服务组件。通过提炼出的各类业务框架,剥离出功能实现逻辑中包含的业务流程规则以及业务规则,实现集中管理和灵活配置。

4 项目总结与展望

4.1 预期目标实现

建立全新的CRM模型,实现个人业务、集团业务、宽带业务的模型融合;实现产品可配置能力;实现活动可配置能力;实现规则可配置能力;

建立全新的BOSS模型,支持全业务融合计费;实现资费包计费;

建立SOA接口管控平台,为建设OPEN-API创建基础。实现电渠支撑从点对点到点对面的转变;

在全国范围内创新采用云技术,以X86替代小型机,将系统设备投资降低2/3,批价性能预期将提升3倍,达到1:8;

实现计费账务一体化,有效提升计费准确性和实时性;

实现了资费包计费能力,为资费商品化流通做好了充分准备;

重点业务响应效率显著提升:13个关键业务中,8个业务的响应时长不足老系统的30%、甚至10%;3个业务的响应时长是老系统的50%,2个业务和老系统基本持平。

4.2 CRM系统重构项目技术亮点

4.2.1 业务支撑能力

实现统一产品管理、融合业务受理;

增强捆绑营销销售支撑能力;

提升个人、家庭、集团复杂客户群关系管理能力;

提升终端资源的库存管理管理。

4.2.2 系统运行能力

系统分布式设计、二级路由调度提供应用系统线性平滑扩展能力;

应用负载均衡、批量管控、产品内存管理机制提升系统稳定运行能力;

服务框架、运营管控设计提升系统安全运营管理能力;

多级缓存技术、产品内存管理机制提升系统服务效率。

4.2.3 开发管理能力

BCE业务生成环境提供提高业务开发快速响应能力(必须管理跟上才能真正体现价值);

自动化降低出错效率,提高效率。

4.3 CRM重构项目所创造的记录

创造了一个用一年半时间同时换掉CRM&BOSS的纪录。本次NG-CRM/BOSS重构项目,是上海公司10年来最大一次IT支撑系统的全面升级重构,也是全集团支撑条线首次一次割接完成CRM和BOSS系统重构,开创了同类项目群实施的先河。

创造了割接后的一周就能上线新业务的纪录。为了应对上海激烈的市场竞争,项目割接前即开始考虑对新需求开发的支持,在上线后仅一周即投入常规工单节奏,使项目割接对新业务开发的影响尽可能地降低。

第一个将“云”架构的BOSS系统用于生产系统:“ 云”架构的计费系统(应用云)和“云”架构的详单系统(详单云)。

4.4 项目后期展望

本次CRM&BOSS重构是上海移动支撑系统的一次革命性的里程碑,它助力IT支撑往IT运营方向的转变,进一步提升系统对市场、服务、客户和业务的支撑能力,助力公司经营发展,提高企业竞争力。为移动互联网时代、电商时代下进一步实现对创新项目的开放和支撑,使支撑能力成为核心竞争力,提升公司经营和管理水平,转优势为胜势,助推公司跨越式发展。

参考文献

[1]中国移动通信集团NGBOSS2-BOSS(V4.5)业务规范,2012.

[2]中国移动通信集团NGBOSS2-BOSS(V4.5)技术规范,2012.

[3]中国移动通信集团NGBOSS2-BOSS(V4.5)系统流程框架规范,2012.

[4]上海移动CRM重构项目应用软件方案,2012.

[5]上海移动NG重构项目割接方案,2013.

作者简介

吴敏(1980-),女,上海市人,硕士,工程师。研究方向:IT项目管理。

作者单位

中国移动通信集团上海有限公司 上海市 200060

上一篇:对矿用软起动器热稳定性试验的探讨 下一篇:基于B/S的学生虚拟学习社区的构建