上海电信BSS项目数据整合和迁移经验交流

上海电信 BSS项目 数据整合和迁移经验交流 上海电信企业信息化部 2005年 9月 16日 目录 项目整体 情况介绍 1. CRM数据导入工作 2. ODS数据整理工作 3. 面临的问题和困难 4. 项目整体 情况介绍 上海电信 MBOSS目标系统总体架构图 业务流程的衔接和闭环 F实现 A保障 B计费 管理支撑 EAI企业应用集成平台（ IBM WBI） OSS-业务实现（ IBP综合业务处理） 元数据 WF 施工调度 路由 设计 资源 指派 RM 网络资源管理 资源 创建 资源 维护 本地 数据 内容 长途 / 无线 资源 调配 数据 管理 资源 调配 数据 管理 资源 调配 数据 管理 资源 调配 数据 管理 采集 本地 数据 内容 长途 无线 融合计费 融合帐务 综合结算 帐单打印发放 产品目录（ 从） 帐单核 销 财务数据 批价处理 开帐处理 帐单定制 欠费和催缴 BSS计费帐务 网元管理 FCAPS OSS-服务保障 TEST测试 TT用户故障处理 MR网络 维护与 恢复 MM综合网络管理 出错告警分析 综合网络配置 用量数据采集 运行性能监测 网络安全管理 SM 服务 管理 CN 用户 网络 管理 本 地网管 数据网管 无线网管 长 途 网管 内 容 网 管 投诉管理 故障受理与跟踪 信用审核 定单受理 与跟踪 CRM BSS客户关系管理 客户 客户数据 产品数据 交互记录 Mail & Fax&SMS 10000号 CTI/IVR 代理商门户 CSP客户自助门户 市场营销 产品销售 忠诚度管理 客户 SLA管理 客户信息查询 营销知识库 产品目录 (主 ) 代理商信息管理 帐户变更 帐单征收 客户合同管理 帐单查询 财务 管理 (FI) 单点登录 身份认证 自助服务 URL重定向 内容管理 个性化界面 ICE 集成 协作 环境 OA EL KM MSS-管理支撑 ERP EIP 员工 信息 门户 人力 资源 工 程 管 理 财务管理 OSS-业务实现 (IBP） OP 订单处理 （ 本地 、 数据 、 内容 、 长途 、 无线 ） NA 网络激活 （ 本地 、 数据 、 内容 、 无线 、 长途 ） 工单 分解 指令 分解 处理 流程 订单 分解 工单 管理 BP 业务开通 CRM BILLING ETL数据 整合平台 ODS 运营数据仓储 统一客户视图 数据同步 综合报表 平台 EDW 企业数据仓库 CUBE IBP 其它 SAP/R3 SAP/SEM 战略管理 绩效管理 预算管理 （数据存储 24 1) 内部客户 数据查询 BAS OAS 数据挖掘 CUBE EDA-企业数据架构 CRM 数据 BILLING 数据 IBP 数据 其他系统 数据 收入摊分 CQ D 对外客户 数据库 外部客户 数据查询 SAP/BW 预处理 预付费 GL 总帐模块 AR 应收模块 AP 应付模块 AM 固定资产 LM 贷款管理 JM 岗位管理 CEA成本 要素会计 SPL特殊 分类帐 CCA成本 中心会计 CO-PA获利 能力分析 PCA利润 中心会计 FM 基金管理 EC-CS 合并报表 OM 组织管理 PA 人员管理 PY 薪资管理 IM投资 管理 PS项目 管理 MM物料 / 库存管理 TEM 培训管理 PD 人员发展 ESS 员工自助 CM 现金管理 PM资产 实物管理 SD 销售管理 SAP/R3 代理商 MetaSolv BO XI Siebel CSG Kenan/BP Informatica AIS 审计模块 BSS项目总体思路 目标应用系统架构以 EAI总线为信息流转的基础 , 以松耦合的方式建置，支撑上海电信的需求 通过采用国际一流的成熟的商业软件包，引进行业最佳实践和先进的管理经验，提升上海电信总体竞争能力 目标应用架构突出统一面向客户的 CRM系统 ,提供现有业务和新业务的统一受理界面，实现市区和郊县范围内部的统一计费、统一优惠折扣，规范客户、产品、计费和资源数据模型，有效共享订单、计费、客户数据，减少业务受理时间，提供灵活的优惠折扣，固化 BPR需求，实现端到端的运营流程 97系统改造应分成 5个模块进行 97系统 号线资源管理 系统 CRM系统 订单管理 业务开通系统 运营数据存储 （ ODS） 企业应用整合平台（ EAI） 重点 松耦合，同步实施 每个模块的实施必须遵循 CTG-MBOSS制定的基本规范 BSS项目建设目标 客户信息整合，建立全公司统一的客户信息视图，实现上海电信的客户管理模型，从系统上支撑从面向产品向面向客户的转变。 提供全公司统一的产品目录管理，提供灵活的产品配置，捆绑，组合。 业务流程优化，全程状态掌控；渠道全面整合，信息集中共享；兼顾现有业务，面向未来发展 BSS项目管理办公室 上海电信 BSS项目总监、项目经理 IBMBSS项目总监、项目经理 架构、业务、培训 IBP组 行政支持 ODS组 EAI组 CRM组 项目指导委员会 电信公司领导、相关部门领导 IBM公司领导 BSS项目组织图 Billing组 质量风险控制 CRM数据导入工作 全部导入 增量导入 分两个步骤实施 CRM数据导入的工作（全部导入） 从 97系统获得全部生产数据表备份； 导入 Siebel数据库中的 97数据表（在 Siebel数据库中建立了与 97数据表完全相同的表，便于统计比较）； 在 Siebel数据表中按照产品统计资产数量； 在 97数据表中按照产品统计资产数量； 两边比对资产数量； 将 97中遗漏的未处理数据导入 Siebel数据库； CRM数据导入的工作（增量导入） 9 7 数 据 导 入 预 处 理 表9 7 数 据 导 出检 查 方 晟 程 序 的日 志检 查 数 据 L o a d 的日 志9 7 数 据 转 换 处 理脚 本 检 查 数 据 处理 的 结 果转 换 后 数 据 导 入 E I M表检 查 数 据 导 入 的日 志E I M 表 导 入 B a s e 表脚 本 检 查 数 据 处理 的 结 果人 工 最 终 检 查 所有 数 据 处 理 步 骤的 结 果 日 志步骤一：从 97数据表中获得每天的增量数据，通过 Oracle工具导出到文件。这步有数据导出的应用程序日志供检查 步骤二：通过 Oracle工具将 97数据导入 Siebel预处理表，通过检查 Load数据的日志文件，检查数据导入的正确性 步骤三：对 97数据进行转换处理，将 97的数据处理成 Siebel的数据格式。这步工作可以通过检查脚步检查处理结果。 步骤四：将转换后的数据导入 Siebel的 EIM数据表。通过检查Load数据的日志文件，检查数据导入的正确性。 步骤五：将数据导入 Siebel的基本表。通过检查脚本检查导入的结果 在每天增量数据同步完后，通过对以上几步操作的结果检查，保证每天增量数据的正确性。对于出现错误的情况，通过单独处理将遗漏的数据补充入 Siebel数据库。 CRM数据导入的工作量 600多万客户 6700多万资产（设备） 100多个产品 几千种营销活动和 2000多万的营销活动 ODS数据整理工作 ODS/EDW实现了在 BSS架构中最重要的客户信息整合； ODS/EDW整合了客户树 (客户层级 ),客户与客户经理的关系等其他非常重要的客户数据 ODS/EDW统一了收入类指标的定义，整合了产品分类和收入分类，提供了上海电信在最准确和完整的收入类数据，这部分数据将提供给各个系统作进一步的统计和分析 ODS/EDW在整个 BSS项目数据迁移中扮演了至关重要的角色 企业三户数据模型 客户 B 客户 A 客户 C 资产 1 资产 2 拥有 拥有 使用客户 付费 付费客户 帐户 2 帐户 客户 D 使用客户 帐户 1 集团客户 1 上级客户 上级客户 对一个客户而言，可能拥有几个账户，几个资产；而对某一个资产而言，存在着 2个角色，使用客户角色和付费客户角色，这些角色可以是同一客户，也可以是不同的客户。 整合客户与账户、资产这三者关系，对于电信企业来说有着非常重要的意义： - 能够形成对电信客户最完整的视图 - 能够从各个角度分析客户对电信的价值和贡献 （目前只能从付费者的角度统计客户对电信的贡献） - 能够对不同性质的客户展开针对性的营销 BSS建设的客户数据结构 客户与资产的关系 客户所购买的所有的上海电信的产品，在 Siebel中以资产的形式存放 客户的三种属性并不直接体现在树状结构中，而是体现在客户与资产的关系中 任何一个资产，都分别有产权客户，使用客户，和付费客户与之对应，可能是同一客户，也可能是不同的客户 一个客户在一项资产上，可能是产权客户，可能是使用客户，可能付费客户，也可能是其中的两项或三项都是 付费关系使用关系产权关系客户产品 资产 产权客户域 使用客户域 付费客户域1 ： MM ： M联系人 使用，产权，付费 CRM 97 老计费 CRM终 端老 计 费 终 端97终 端产权与付费 付费者信息变更 资产与付 费者 资产与产权 ,付费者 资产与产权信息 老计费有最准确的资产与付费者信息 CRM 有最准确的资产与产权信息 但是没有一个地方有完整的三户视图？客户的付费信息的变更也没有及时地反映到 CRM 在 ODS整合三户之前的上海电信 客户 现状 使用，产权，付费 CRM 97 老计费 CRM终 端老 计 费 终 端97终 端产权与付费 付费者信息变更 资产与付 费者 资产与产权 ,付费者 ODS 资产与产权 ,使用者 资产与付费 ODS整合了资产与产权者，付费者，使用者的完整信息，形成了完整的三户视图 ODS最后将完整的三户信息返回给CRM 在 ODS如何整合 客户数据 付费者丙 : 客户 B=付费者甲 客户 A CRM Billing 客户 A 客户 B 客户 C 付费者甲 付费者乙 付费者丙 客户 C=付费者乙 ODS整合以后 仅存在CRM的客户 CRM和老计费都存在的客户 仅存在老计费中的客户 ODS客户整合结果示意 CRM 97 Existing Billing ODS CSS 1. 从 CSS获得客户（大客商客）、客户经理和客户（大商）的关系、客户经理和分帐要求的关系（公客）、分帐要求、分帐要求和客户的关系 2. TMP从 CRM获得客户 3. TMP整合客户后返还给 CRM 1. 整合后增加的 CSS的大商客 2. 客户（大商客）的层级关系 3. 分帐要求和客户的关系（大商客相关的） 4. 合并成功的大商客和客户经理的关系、客户经理和分帐要求的关系（公客） 4. CRM给 ODS所有客户、客户经理和客户的关系（大商）、资产、分帐要求（大商客）和客户的关系 5. 从老计费获得所有分帐要求、设备业务细节、帐单、详单 6. 从 97获得历史的一次性费用 7. 将资产和设备业务细节整合， 97一次性费用整合，全部的付费客户、全部的分帐要求（ req_id）、匹配上的资产及其之间的关系返还给 CRM， CRM根据分帐要求创建帐户，一些需要 CRM手工增加的资产。 8. CRM修改后给 ODS，给 ODS公客客户和客户经理的关系，所有的帐户给 ODS，帐户和资产的关系 ODS initial load（整合步骤 1） TMP1 1 2 3 4 7 5 8 6 1 2 3 4 5 6 7 8 客户 CSS的大客 商客 CRM客户 需要新增的客户 大客 商客 CRM的公客 需要新增的客户 全部 分帐要求 全部 全部 资产 CRM初始资产 需要新增的资产 客户经理 全部 客户和分帐要求 CSS的 大客 商客 大客 商客的 大客 商客的 现有的客户 全部 客户和资产 产权 付费 分帐要求和资产 全部 客户和客户经理 客户经理和分帐要求的关系（公客） 客户经理和客户的关系（大商） 全部 CRM 97 Existing Billing ODS 3 5 4 1. CRM将每天受理的定单传到 97系统用于开通 2. 97每天将完工信息通过接口批量传送给老计费 3. 老计费每天将分帐要求（帐户）和设备业务细节传给 ODS，每月将帐单和详单传给 ODS 4. 每天 CRM将客户、定单和资产批量送到 ODS，部分一次性费用 5. 每天 ODS将帐户和资产关联后，将资产和帐户的关联关系、帐户、需要新生成的客户传给 CRM 6. 97每天将 CRM没有覆盖的局向的客户、定单、资产（已经配置了产品的资产，且删除拆机的资产）传送给 CRM 7. 每月老计费将分帐要求、帐单传给 BAS/CSS 8. 从 CRM获得所有的客户、资产、帐户数据用于测试 9. 从老计费获得所有需要的信息进行测试 10. 每月的一次性费用 11. 每天同步客户和客户经理的关系 New Billing After ODS on going Before CRM Have all Asset （整合步骤 2） 2 1 6 8 9 BAS/CSS 7 10 11 CRM 97 Existing Billing ODS BAS 3 5 4 1. CRM将每天受理的定单传到 97系统用于开通 2. 97每天将完工信息通过接口批量传送给老计费 3. 老计费每天将分帐要求（帐户）和设备业务细节传给 ODS，每月将帐单和详单传给 ODS 4. 每天 CRM将客户、定单和资产批量送到 ODS（ 所有产品的资产 ） 5. 每天 ODS将帐户和资产关联后，将资产和帐户的关联关系、帐户、需要新生成的客户传给 CRM 6. 不需要再反馈数据给 CRM 7. 每月老计费将分帐要求、帐单只传给 BAS， CSS被全面替代 8. 设备与金卡银卡客户对应关系变更细节，用于摊分 9. 从 CRM获得所有的客户、资产、帐户数据用于测试 10. 从老计费获得所有需要的信息进行测试 11. 开始从新计费倒测试数据，以保证将来从新计费过来的数据和现在从老计费过来的数据一致 New Billing After ODS on going After CRM Have all Asset （整合步骤 3） 2 1 7 9 10 数据营帐 长途营帐 8 * 与前面有变化的用红色标明了 11 CRM 97 Existing Billing ODS 2 3 1. 在初始化之前的 A点， 97需要将 A点所有完工工单数据全部倒入老计费 2. 老计费根据这些完工工单生成帐户和设备业务细节，将最后一部分增量分帐要求倒入 ODS，由 ODS检查所有的数据是否和老计费相同。（根据上阶段测试， ODS应该做到这部分数据和老计费一致，也和将来新计费过来的一致） 3. ODS将最后一批需要更新的帐户、资产和帐户的关系、需要新增的客户倒入 CRM 4. CRM将所有的客户、帐户、资产数据给新计费 5. 新计费从老计费获取其他数据 New Billing New Billing Initial Load （整合步骤 4） 1 4 5 CRM 97 Existing Billing ODS 3 5 4 1. CRM将每天受理的定单传到 97系统用于开通 2. 97每天将完工信息通过接口批量传送给老计费 3. 老计费每天将分帐要求（帐户）和设备业务细节传给 ODS，每月将帐单和详单传给 ODS 4. 每天 CRM将客户、定单和资产批量送到 ODS（所有产品的资产），金山的客户、帐户、完工资产数据 5. 每天 ODS将帐户和资产关联后，将资产和帐户的关联关系、帐户、需要新生成的客户传给 CRM 6. 设备与金卡银卡客户对应关系变更细节，用于摊分 7. 实时从 CRM获得金山的客户、资产、帐户数据 8. 将金山的收费信息传给老计费 9. 倒入新计费的金山开帐数据、收费数据，同时倒入老计费相同数据只是用于比较 New Billing New Billing on going (golden mountain) （整合步骤 5） 2 1 7 8 数据营帐 长途营帐 6 9 CRM 97 ODS 3 1. CRM将每天受理的定单传到 97系统用于开通 2. 实时从 CRM获得所有的客户、资产、帐户数据 3. 每天 CRM将客户、定单和资产批量送到 ODS（所有产品的资产） 4. 新计费每天将收费信息给 ODS，每月将帐单和详单传给 ODS 5. 设备与金卡银卡客户对应关系变更细节，用于摊分 New Billing New Billing on going （整合步骤 6） 1 2 数据营帐 长途营帐 5 4 CRM客户 CSS客户 1600 23万 19万 共 6727万 5578万（ 55777073） 第二次 62673587 一期 共 5066万 1979万 关闭 163万未找到设备号（ 其中 215351 一期资产 ） 3087万未关闭 1150万 660万 26万 8300 设备业务细节 资产 大 商 公 客户整合结果 资产整合结果 440万设备号找到但没有对应关系（包括二期） 15368个没有找到设备号（ 7400） 37.2万 572.9万 18.9万 2400万匹配上的（ 23975393） 289万（第二次） 1115万没有对应 （ 11153789） 第二次 4605609 从分帐要求来整合 34万设备业务细节（第二次） 整合结果统计 问题 原因 建议 数量 CRM有的资产，而老 Billing没有对应业务细节 CRM（ 97）会缺省生成一部分业务细节，而老 Billing在用户使用时才生成相应业务细节 需要市场部确认，是否这些数据不需要 Billing profile，如果需要 Billing profile，是否可以缺省为根资产上的Billing profile 其中声讯总数为： 830万 其馀还包含来电显示 , PHS 短消息等等 老 Billing有 CRM没有的资产 老 Billing根据用户使用而缺省生成的业务细节 需要市场部确认这些数据是否需要 CRM（ 97）来补齐，如何补齐数据 其中 IDD， DDD， ISA，NSA， IP主叫直播业务为 60万 CSS整合策略 CSS 集团客户与主客户归并规则还没完全确认 , 其中已经确认的包含 ： 同客户群（集团客户）的归并原则 同客户群（主客户和集团客户）跨树的归并原则 同客户群（集团客户）的归并原则 需要市场部确认 ： 跨客户群（主客户和集团客户）的归并原则 异常数据需要市场部确认 数据整合工作挖掘出的问题 将老计费系统的设备与设备业务细节与 CRM的资产进行对应； 将老计费系统的分账序号 (付费者信息 )与 CRM得客户信息进行对应 ； 如果来自老计费的付费者信息存在对应的客户信息则合并该付费者信息，否则根据该付费者信息在 CRM中创建新的客户； 将老计费系统的分账序号 (付费者信息 )与老计费的设备业务细节关系转换到CRM的资产与付费者的关系； ODS客户的整合结果： 在 ODS整合 客户数据 的关键环节 数据的一致性： CRM 和 老 计费 的数据的一致性 数据的源头： CRM 和 老 计费 数据以谁为源头 数据归并： CSS 集团客户与主客户归并 CRM ODS 老计费 产品 资产 组织 帐户 营销活动 优惠 合同 客户 订单 一次性费用 帐单 收费记录 产权客户属性 关注重点 数据整合工作关注点 CRM的资产大部分从 97过来，但是根据 CRM的产品定义和资产生成原则，将会产生大量的资产，对于每一个资产，必须定义其资产的产权拥有者，付费者和使用者 同时在老计费系统中，由于历史的原因，老计费会根据自己的业务类型和实际开帐与否定义设备与设备业务细节以及相应的付费者关系 必须将 CRM的资产与老计费的设备与设备业务细节作匹配，否则将无法为 CRM的资产定义准确地付费者关系！ 难点在于不能简单地根据设备号做匹配，因为同一个设备号可以有多个设备业务细节！ 客户整合过程最关键的部分 CRM资产 (产品实例 )与设备业务细节的比对 为此定义了完整的对应关系 (将 CRM的产品目录与老计费系统的设备类型作了匹配 ) 老计费中的设备类型与设备业务细节类型 CRM中的产品代码