经验总结
严格控制项目范围，如果遇到重大范围变更需走变更
流程，必须有邮件或者纸质档文档记录
确定分阶段里程碑，并细分到周计划等，可采用周例
会形式和里程碑汇报的方式，加强期望值管理
23
项目问题及教训（四）-----前后台架构

问题描述
大量的业务逻辑放在前台来处理，前台处理了很多拉
链表
前后台耦合性很高，前后台无法分开测试

经验总结
项目组内部，确保PM、前台Leader、后台Leader、模
型人员之间的沟通顺畅。
与客户之间有统一接口人，避免发生客户直接向开发
人员提需求的情况
22
项目问题及教训（三）-----项目管理

问题描述
项目范围控制力度不够，到项目最终快上线时新加两
个源系统
阶段性目标不明确
没有期望管理，客户期望一直和项目组的期望不一致
由FDM、GDM、DM合起来的被称作ODS的系统包含了传统ODS之外的CIF、DW基 础层、DW中间层、DW汇总层各层的部分内容，而这些内容主要以CRM的需求为出 发点。客户方面投诉认为我们没有模型，这大概是客户认为ODS的模型是由源系统 的实体加上客户CRM需求所要求的实体而构建的
感觉现有模型结构不是很清晰，不利于理解，合并所有内容的ODS使得理论上属于 ODS系统本身的特性不再鲜明，同时，弱化了被合并内容的特性，也许，将具有 ODS特性的FDM层拆出来作为ODS，将剩下的内容划分为公共服务层和应用层，公 共服务层从全行的角度来考虑和设计，展现这些层的特点，这样可以明确不同层次模 型的定位及其服务的对象和范围，给人更深刻的印象
架构层次不清晰

经验总结
对于前台需要进行复杂关联的查询，改用后台视图、
实体表或者存储过程的方式实现。
建议包括以下几层：缓冲层，基础层，共性层，DM层
数据模型层（三）
5、CRM基础层模型
CRM和ODS部署在不同的机器上，CRM基础层是客户级别的实体，主要是从ODS的FDM、 GDM、DM层抽取实体的原样影射和组织，同时还有和前端用户交互的“客户分配”模块， 最后还有一些简单的报表。
6、CRM应用层模型
CRM应用层主要是前端系统表、营销活动模块、汇总到机构的报表等内容。 模型总结：
北京银行对私CRM三期项目总结
杜啸争
目录

项目简介
项目管理
项目问题及教训 后续项目规划
2
北京银行对私CRM建设历程
北京銀行三期 (2009~2010)
北京銀行二期后期 (2008~2009) 北京銀行二期前期 (2007.12) • 营销管理 • 潜在用户 • 任务管理 • 增值服务 • 支持工具 • 客户评级 • 客户分配 • 客户筛选 • 团队管理 • 客户视图 • 客户事件 • 客户提醒

经验总结

制定调研大纲，客户确认需求；如果客户不确认，项 目暂停，风险及时提出 明确的项目变更流程 重复需求，不断验证
21

项目问题及教训（二）-----沟通

问题描述
和客户沟通不充分，未能理解客户真正的需求 项目组内部沟通不畅，前台后台缺乏沟通 沟通渠道不畅通，客户直接和开发人员接触
数据模型层（二）
3、GDM层模型
主要包含“客户整合”、“产品整合”两个主题域，数据库中保存月末 和当天数据。 “客户整合”主要整合了客户号（系统自建）来唯一识别客户，还整合 了客户基本信息（个人信息、所持有卡、地址、联系方式等信息） “产品整合”内容类似于我们DW中的中间层，完整和产品的属性信息 的基础上加工和月、季、年均值 总结：GDM层包含的内容类似于我们之前DW项目中的LDM客户主题 部分内容+DW中间层部分内容，项目组认为“客户整合”主题域体现 了CIF的特点，所以项目也包含了CIF。
向CRM系统推数
源系统
CRM系统
④ 、文本数据加载进入FDM层，使用Informatic直接加载到目标表，处理完根据CRM需求卸数。 ⑤ ⑥ 、 GDM层、DM层数据处理，处理完根据CRM需求卸数。ODS处理完毕。
说明：当前架构下①-- ④步之间的设计需要优化，源系统数据抽取时可以在产生落地文件的同时 直接加载到FDM层，在FDM层进行增量对比处理
物理架构
RAC架构 RAC架构
instance ODS2
instance PCRM2
instance ODS1
instance PCRM1
WAS
INFORMATIC A
INFORMATIC A
WAS
10.2.0.1 10.2.0.2
DATA 6T
采用Oracle RAC架构，两台机器部属crs 软件，并建立两套数据库：crm、ods； crs架构每个节点上运行两个实例，其中： 主机1运行：crm1、ods2； 主机2运行：ods1、crm2。 11
6
ODS数据处理流程（二）

系统按照数据层次建立ETL任务组，一个任务组整 体运行完毕后下一个任务组开始运行 数据层次为（标号为数据处理阶段）： 源系统文本数据-〉数据库缓冲区-〉增量文本
③ ④ ⑤ ① ②

-〉FDM层-〉GDM层-〉DM层

目前ODS整体运行时间为 7 小时左右 各数据处理阶段运行时间大概为：
营 销 数 据 平 台 （ ）
客户整合 接口信息 客户信息
ODS
核心
个贷
网银
三管
大前 置
基金
人事
保险
理财
5
ODS数据处理流程（一）
ODS 系统
核心 个贷 网银 三管 大前置 基金 人事 文本文件
①、抽取源系统数据并落地为文 件
ODM
文本文件 文本文件
①
文本文件 文本文件
②
③
文本文件
文本文件 文本文件 文本文件
CRM
CRM基础层 • 复杂逻辑处理 • 面向应用
DM（应用集市层） • 面向应用 • 按需定制 GDM层（公共数据层） • 客户归并和整合 • 产品整合 FDM（基础数据层） • 按主题整理，基本保持源系统 • 部分衍生实体 ODM（增量数据层） • 完全依照源系统建模 • 产生增量 文本层 • ETL专用的纯技术层 • 完全与源系统结构一致
DM
系统 功能
• 客户视图 • 客户事件 • 客户提醒
• 客户评级 • 客户分配 • 客户筛选 • 团队管理 • 客户视图 • 客户事件 • 客户提醒
数据 平台
DM
•数据集市
DM
•数据集市
GDM FDM ODM
ECIF
•营销数据平台
项目范围

建立营销数据平台，实现对私客户信息的整合，便于统一 管理。(ODS) 建立对私CRM三期分析系统。
客户视图 客户事件&客户提醒
新增重点功能 新增普通功能 二期已有功能
客户评级
客户筛选 团队管理
14
目录

项目简介
项目管理
项目问题及教训 后续项目规划
15
项目组织架构及成员
项目领导小组 项目总监 银行方领导 （无）
项目经理 项目经理 银行方 科技项目经理 业务项目经理
需求组
X
模型
1人
前端开发Leader
项目最终投入预计需要175人月，远远超过了当初的预算。
18
目录

项目简介ቤተ መጻሕፍቲ ባይዱ
项目管理
项目问题及教训 后续项目规划
19
项目问题及教训
20
项目问题及教训（一）-----需求

问题描述
需求不明确，客户未确认； 需求变更流程(包括数据源系统、项目范围控制等)；
需求理解（客户传递、内部传递）
数据库/ETL/ 应用
服务器 文件服务器
Unix服务器，
2台
IBM 8204-E8A 4*3.4G Power6
CPU,16G 内存，6T硬盘
Windows 服 务 器
1台
DELL6850，2*3G CPU，4G内存， 250G硬盘
12
系统软硬件配置（生产环境）
软件类别 1 2 数据库软件 ETL软件 软件功能 管理和存储数据 支 持 对 ETL 任 务 的 定 制和自动调度,以实现 数据自动抽取和装载 3 应用服务器 服务器/存储 支持B/S方式 类型 数量 Websphere 7.1 （64位） 配置 产品推荐 Oracle (10.2.0.4，64位) Informatica PowerCenter 8.6.1 （64位）
4、DM层模型
主要包含“客户视图”、“客户评级”、“客户事件”3个主题域，数 据库中保存月末和当天数据。
总结：本次是针对CRM服务的，本次的实体都会按原结构导入到CRM 基础层中，本层实体都是客户级别的实体，客户拥有的产品及产品的交 易信息都被汇总到客户，且客户按照CRM给定的业务规则被分配到一 个机构。
1）0.5小时 2）1小时 3）0.5小时
4）3 小时
5）2小时
7
数据模型层（一）
项目组根据总体架构分别设计了6个模型： 1、源数据层模型：
包含进入ODS的各源系统实体。
2、FDM层模型
包含和源系统结构相同的实体和衍生的实体，共96个，其中65个实体和源系统结构相同 （增加了系统别和数据加载时间戳），这些实体在数据库中数据只保存和源系统一致的当前 全量表，其余31个实体是在源系统实体基础上衍生出来的实体(拉链表)，如余额历史表，关 系历史表、 （源系统）删除数据表、新旧帐号对照表等 FDM模型重新划分了主题域（如右图所示） FDM模型对部分代码字段进行了标准化 总结：FDM层包含的内容类似于我们之前项目中的ODS+部分 DW，65个和源系统结构一致的实体是ODS部分的内容，而31个 衍生实体通常在DW中存在