中国联通2010年集中CRM系统部署的方案.pptVIP

CRM系统在BSS中的位置 系统架构与功能现状 当前架构下面临的挑战 CRM系统传统的总部-省分两级架构在过去很好的支撑了2G、固网、融合业务的发展，但在新的形式下面临诸多挑战： 规划思路 根据上述分析并结合现状，根据业务统一管控的力度及业务需求的统一程度，计划分三阶段建设一个集中的CRM系统，以达到管理层目标，应对未来的挑战 第一阶段： 建设集团集中的CRM系统，搭建整体技术框架 将省分系统中的客户资料管理、产品管理、业务资源管理、渠道管理、客户评价管理（积分/信用/俱乐部）、订单管理等功能及数据割接至集中系统 省分保留客户评价（维系挽留）、销售管理、市场营销、客户问题管理（客服）、应急开通等功能 客户投诉数据定期上传集团，客服系统与集团集中CRM系统通过界面集成方式实现互访 第二阶段： 将省分的客户评价（维系挽留）、销售管理、市场营销、客户问题管理（客服）等功能及数据割接至集中系统 省分保留应急开通、公众客户社区经理等功能，满足一线营销管理以及紧急状态下业务开通的需要 第三阶段（可以和二阶段交叉并行）： 在实现全国31省核心功能及数据的集中后，在整体技术框架下对功能划分、业务流程进行优化调整 银行集中经验借鉴 集中CRM系统建设需要投入大量的资源，参照银行业的系统集中经验： 全国集中一阶段，从全国各个分行抽调业务专家共60到70人； 制订业务规范，进行业务梳理，共梳理16个应用模块， 2000多个功能点； 选取北京、上海、江苏作为试点，为时一年试点上线； 现阶段两运行中心400多人，灾备、测试、研发中心1000人左右。除了以上两大中心外还有多个软件开发中心，人数达到几千人。 经验借鉴： 从省分抽调业务专家参与系统集中的讨论与方案制定； 重视规范编制，规范先行； 先试点，后推广； 需要探索全新的运维管理体制 * 数据服务调用频度 = 峰值业务量 X 业务处理平均所需服务调用次数/8小时/3600秒×峰值系统 = 820000×6/8/3600×3 = 513笔/秒 * * 省分VAC、OCS、省分BI、号簿、114、112 客服 一卡充 社区营维 * 省分VAC、OCS、省分BI、号簿、114、112 客服 一卡充 社区营维 * 省分VAC、OCS、省分BI、号簿、114、112 客服 一卡充 社区营维 * * * * 原有省分CRM系统功能 * 关注点：集团客户支撑与营业受理的关系 划分思路 降低业务耦合度，减少系统间相互调用，避免系统互相影响 保证集团业务的统一管理，提高客户感知 业务处理分布 说明 新增集团（含新增成员）的新装业务在集团客户支撑系统中统一受理（包括租线类、语音类等全业务）并生成客户订单，后续处理环节营业稽核、资源分配、施工处理（程控、测量、装机等）都由省份IOM系统提供支撑 成员用户的非集团业务的变更在营业受理系统中受理 业务场景 营业受理 集团客户支撑 集团开户、新装（含新增成员） ● 在网成员用户加入集团（含批量） ● 成员用户非集团业务变更 ● 成员用户集团业务变更 ● 集团客户 管理域 公众客户管理域 集团 客户 支撑 总体部署架构 产品 管理 公共 支撑 管理 报表 统计 流程引擎 业务运营门户 公众 渠道 管理 三户资料 产品资料 业务资源 渠道资料 业务逻辑总线（S-ESB） 数据服务总线（ D-ESB ） 集中数据管理中心 业务 资源 管理 公众 客户 评价 管理 …… 营业受理 1…N 营业受理 1…N 集成关系整体视图 1 2 3 4 集中CRM系统通过ESB实现与外围系统的对接（总部BI可通过数据库同步） 为保证工程实施进度，保持VAC的现有路由策略不变，可以研讨总部一点对接的技术与工程可行性 集中CRM系统直接与省分运营中枢中的数据管理平台对接，完成省分数据的下发 原有省分系统与省分CRM系统的接口全部由省分运营中枢的统一接入平台继承，避免周边系统大范围改造。 关注点1：营业受理按地域支撑 营业受理做为CRM系统的核心支撑能力，在方案设计中采用按地域部署多套应用的方式： 利于厂商互备：一旦厂商资源发生变化，支撑响应出现问题的时候，可以考虑由其他应用厂商接管 利于业务分担：可以有效实现业务分担，避免出现单系统性能压力过大的情况；一旦某个应用发生重大故障且无法短期恢复，影响面可局限在部分地域，同时可以考虑由其他应用接管 利于个性化需求响应：在集中初期业务统一管理力度有限的情况下，可以通过点对点方式快速响应省分个性化需求 利于并行实施：工程割接过程中，可以充分调动多厂商资源并行实施，降低对单个厂商的资源需求，分散工程压力