06_CRM系统建设分析、挑战与解决方案

CRM系统建设分析、挑
战与解决方案
2016/6/2
XX银行

 分行使用CRM系统功能的情况
 分行对CRM系统功能的需求
 CRM系统开发现状与推广的阻力
 CRM系统建设管理所面临的挑战
 应对CRM系统建设所面临挑战的建议措施
 2014年CRM系统开发规划建议

被调研分行对当前CRM系统使用情况汇总
东
莞
佛
山
杭
州
南
京
郑
州
北
京
天
津
1. 客户管理分析
单一客户信息
单一客户视图
客户分配管理
集团客户视图
客户群
客户航标分层
客户数统计
客户综合收益
EVA&RAROC
2. 产品管理分析
单一产品维护1
3. 绩效管理
账户分配管理
客户经理绩效
营销业绩双算
机构属地绩效
机构属人绩效
团队业绩
分行协作存款
中收补录
计划管理
公共户管理
东
莞
佛
山
杭
州
南
京
郑
州
北
京
天
津
4. 营销管理
潜在客户管理
5. 管理工具
机构管理
人员管理
团队管理
消息提醒
报表管理2
通讯录
公告管理
存贷款预测
利率管理
知识库
任务下达
利率审批
图例
在使用
未使用
备注
1. 目前仅有根据总行贸易融资部所提出的部分国内/国际贸易融资产品的维护功能
2. 总行级报表，分行仅可看且仅可看到自己辖内数据

被调研分行对当前CRM系统使用情况总结
• 大部分功能已推广到各分行，包括：单一客户信息、单一客户视图、客户分配管理、客户航标分层、
客户数统计、客户综合收益和EVA/RAROC试算
• 客户群仅XX省内部分分行在使用
• 集团客户视图仅在总行层面的得以应用
 1. 客户管理分析
• 目前仅有根据总行贸易融资部所提出的部分国内/国际贸易融资产品的维护功能，分行基本不使用
 2. 产品管理分析
• 分行均在使用绩效考核功能
• 各分行的绩效考核KPI基本都与总行一致，部分分行也有自己独特的KPI（系统尚不支持）
• 分行协作存款功能尚未被彻底推广到分行
 3. 绩效管理
• 功能目前仅包含潜在客户管理，且总分行层面基本无人使用
 4. 营销管理
• 部分功能已推广到各分行，包括：机构管理、人员管理、团队管理、报表管理（总行级报表，分行
仅可看且仅可看到自己辖内数据）
• 部分功能在行内基本无人使用，包括：通讯录、公告管理、存贷款预测、知识库、任务下达
• 利率审批仅覆盖到公司条线，仅在XX省内2家分行在做试点
 5. 管理工具

分行对CRM系统建设的诉求汇总
东莞佛山杭州南京郑州北京天津
1. 客户管理分析
• 通过客户细分找
出目标市场，进
而预先制定营销
策略
• 现金流分析对撰
写授信报告有帮
助，还可分析中
找出业务机会并
做预警
• 提供供应链上核
心企业与上下游
小企业间的业务
信息与数据，从
中找出业务机会
• 以行业、规模等
多重维度细分市
场，然后预先制
定营销策略
• 以现金流分析来
发现商机，分析
可用形象化的图
形展示
• 需要有行业、规
模等之外更多的
细分维度
• 通过现金流分析
来寻找业务机会
并提供预警，未
来要做到现金流
预测
• 提供供应链企业
关联信息，便于
以核心企业为依
托向上下游小企
业提供融资
• 看重按行业和区
域做细分，风险
条线要参与细分，
引导业务导向
• 以现金流分析和
预测功能来协助
客户经理寻找业
务机会
• 提供供应链交易
信息，方便从核
心企业向上下游
挖掘业务机会
• 需要提供行业、
规模等之外更多
的维度用于细分，
然后做定制营销
来寻找商机和做
出预警
关联交易信息，
便于客户经理挖
掘上下游企业业
务机会
• 各种维度做客户
细分，找到目标
市场，定制营销
策略
来发现商机并防
范风险
• 以供应链信息为
基础，推经供应
链金融业务
• 以多维度细分来
制定细分后市场
的营销政策
• 以现金流分析来
找到业务机会
关联关系信息，
方便供应链金融
业务的开展
2. 产品管理分析
• 可对每个客户综
合分析，给定组
合形式的产品以
及产品的价格
及产品的价格
及产品的价格
及产品的价格
及产品的价格
及产品的价格
及产品的价格
3. 绩效管理
• 希望绩效考核功
能能更方便地提
示和引导客户经
理向着完成绩效
的方向前进
的方向前进
的方向前进
的方向前进
的方向前进
的方向前进
的方向前进
4. 营销管理
• 向客户经理提供
各类与业务相关
的数据、信息和
工具自我积累的，
但买来的可能多
是上市公司的数
据
营销过程管理的
功能
据
各种业务提醒的
服务
功能
据
功能
据
功能
据
各种业务提醒的
服务
功能
据
功能
据
功能
5. 管理工具
• 客户经理休假期
间，系统中将其
工作转移到指定
他人
策略
策略
策略
策略
策略
策略

分行对CRM系统建设的诉求总结
• 通过提供多维度的客户细分及分析，揭示出各细分市场的业务规模、成本及风险因素，协助制定针
对各个细分市场的定制化营销战略和方案
• 通过客户现金流分析以及之后的现金流预测工具协助客户经理做到发现现有客户及潜在客户身上的
业务机会，同时做到对客户还款违约风险进行防范
• 提供供应链上核心企业及上下游企业信息数据及关联关系的信息数据的展示，来协助客户经理发现
供应链中的融资、理财及其它业务的机会
 1. 客户管理分析
• 针对每个客户的行业业务特点、对金融产品的实际需求、为银行所闯在的实际贡献度及信用等级等
因素，有针对性地为各个客户定制化的产品组合及综合定价
 2. 产品管理分析
• 希望绩效考核功能能更方便地提示和引导客户经理向着完成绩效的方向前进
 3. 绩效管理
• 向客户经理提供更多的与客户、客户所在行业、产品、金融市场、绩效等相关信息和数据；同时要
提供诸如各类业务开展指导、产品销售指导、产品定价、试算、现金流分析、客户财务分析等工具
• 建立营销过程管理功能，全流程引导和监控客户经理管理客户和销售产品过程中的每个环节
 4. 营销管理
• 提供外部金融市场的实时数据（利率、汇率等），同时建立行内人员互通经验和知识的平台
 5. 管理工具

总行对CRM系统建设的现状分析
传统战略
注重业务
总量及
会计利润
传统业
务规则
原业
务需求
系统开发
2013年
提出
因公司条
线人员不
够而尚未
完成规则
细节
战略改革
向注重效
益、成
本、风险和
增长转型
符合改革
方向的
业务规则
？
新业务
需求
？
传统的业
务思维
符合传统
业务思维
的规则
2010年起规划的
业务需求。但与
业绩相比，如中
行OCRM系统建
设，需求标准化、
文档化、规范化
和资源投入不足*
分行反应
绩效考核
功能是按
照新业务
需求进行
开发
符合改革方向业
务规则缺失而导
致分行尚未完成
改革转型，也造
成对新绩效考核
功能的不适应。
系统已按
照原业务
需求开发3
年多
分行处在
新旧业务
模式的交
替转型期
针对公司条线改
革仅提出了绩效
考核的需求，因
公司条线人员不
足而尚未根据改
革方向对需求进
行梳理与再造
挑战1：
业务需求
管理
挑战2：
项目管理
* 详见下一页YY银行OCRM系统建设组织架构及人力资源配置

案例：YY银行OCRM系统建设组织架构及人力资源配置
项目管理委
员会（PMO)
业务需求组技术开发组架构组
名称银行成员外部成员
项目管理委员
会（PMO)
• 项目经理（1人）
• 项目管理助理（2-3人）
• - 均来自科技部
• 项目经理（1人）
• 项目管理助理（2人）
架构组 • 总架构师（1人）
• 业务架构师（2人）
• 技术架构师（2人）
业务需求组 • 业务协调员（2人）- 总
工作时间的约70%，均
来自科技部
• 13个部门的高级经理及
普通成员的临时支持
（人数不不固定）
• 业务专家（1人）
• 业务需求分析师（10人）
• 负责数据和BI（2人）
• 负责功能（8人）- 15
个功能模块）
技术开发组 • 技术专家（1人）
• IT工程师（30人）
注：在项目不同阶段，人员配置会根据实际工作性质及工作量做调整与增减。

 分行使用CRM系统功能的情况
 分行对CRM系统功能的需求
 CRM系统建设所面临的挑战

• 对需求框架设计的完整性、精细度和实用性不足，在时间和人力投入的评
估与实施方面欠缺，影响到后期开发的质量，也造成各部门/分行提出修
改甚至提出新需求；也一定程度上造成基层使用率不高
 A1. 需求框架设计、落实与细化
挑战A – 业务需求管理方面
• 对各部门/分行所提出的突发临时需求修改缺乏统一的梳理与控制；一定程
度上对原规划的实施造成影响
 A4. 突发需求应对
• 新的对公业务改革方向尚没有完整和成熟的明细业务规则，也没有针对改
革新方来对原有需求做梳理和调整
 A2. 针对业务改革方向调整需求
• 在调研中及之前其它渠道了解到很多分行都提出针对系统的本分行特色需
求，满足这类需求会有助于分行提高系统使用率，但也会对原需求内容和
计划产生影响
 A3. 分行个性化需求的应对

• 公司部缺少足够的具备设计和落实业务需求的人员，造成目前项目开发的
业务管理能力不足
 B1. 业务需求人员不足
挑战B – 项目管理方面
• 需要建立需求管理的机制，也要对需求做出梳理和重整，但当前项目进程
仍然需要继续推进。两项工作如何配合是个挑战
 B2. 需求梳理与项目推进的安排

 分行对CRM系统建设的诉求
 CRM系统建设所面临的挑战

应对挑战A1/A2/A3 - 建立常规业务需求管理流程
需求框架
设计
需求落实
规划
项目组内
审阅
V2.0
项目组外
审阅
V3.0
与技术开发
组沟通
V4.0
需求生成
V1.0
• 设计流程：业务
需求组内公司部
业务专家与外部
业务专家共同商
谈敲定各功能模
块的框架及内容
细项
• 设计依据：XX银
行实际情况和未
来发展方向以及
值得借鉴的同业
经验
• 规划流程：业务
需求组内业务专
家与外部专家对
各功能模块需求
落实的工作量作
出评估，并制定
时间计划及人员
投入计划
• 规划依据：各需
求落实所需的工
作量以及现有的
资源（人员、人
天等）
• 设计流程：由外
部业务需求专家
为主导，根据规
划的各需求框架
和内容细项，通
过访谈公司部和/
或其它相关部门
业务人员，完成
需求文档V1.0
• 设计依据：公司
部和/或相关部门
的实际业务需求
及值得借鉴的同
业经验
• 审阅流程：公司
部和/或其他相关
部门业务人员对
需求文档V1.0做
审阅并提出修改
意见
• 修改流程：外部
需求专家根据修
改意见对需求文
档做修改，生成
V2.0
• 审阅/修改依据：
公司部和/或相关
部门的实际业务
需求
• 审阅流程：项目
组将需求文档
V2.0以及问卷分
批次汇总定期
（月、季或其它
类型时间点）下
发各部门/分行来
征求分行意见；
部门/分行限时日
（如：5个工作日）
提交意见反馈，
过后提交则不再
接受
• 修改流程：外部
需求专家及公司
部/和或其他相关
部门业务人员对
所征集分行意见
进行梳理，由外
部需求专家负责
将其中可采纳地
反映到需求文档
中，形成V3.0。
需求文档V3.0即
为供启动技术开
发的版本，分批
次（月、季或其
它类型时间点）
提供给技术开组
进行下一步开发
工作。
• 审阅/修改依据：
• 审阅流程：技术
开发组对需求文
档3.0中的疑问通
过邮件或共享空
间等形式向业务
需求组寻求解答；
有重大分歧时可
召开双方组相关
人员参加的会议
进行解决。

应对挑战A4 - 建立临时业务需求管理流程
临时需求
提出
临时需求
评估
临时需求
处理
• 提出流程：总行各相关部门和各分行可对
CRM系统提出临时需求，但必须定时提出
（月或季的某时间点），且必须以统一标
准格式（word文档）提出，同时必须由部
门/分行的实现指定的CRM系统项目联络
人以正式方式（如：文档库专门功能模块）
提出
• 提出依据：各部门/分行的实际业务需求
• 评估流程：临时业务需求随时对临时需求
做评估。
• 评估依据：需求是否语义表达清晰、内容
是否完整、是否符合CRM系统建设的总体
规划思路、是否在CRM规划范围内、是否
与现有需求重叠、是否可由现有需求替代
等
• 处理流程（临时业务需求组）：临时业务
需求组根据评估结果，作出直接退回、解
释后退回和采纳等决策。若采纳则将需求，
连同与已规划需求的差异分析、对项目的
影响度分析及具体实施的建议（修改需求、
修改系统功能设计或修改系统程序，在哪
个时间点实现等）提交到业务需求组；所
有其它类型的决策也随时传递给业务需求
组；同时向需求提出方提供反馈
• 处理流程（业务需求组）：业务需求组在
接到所提交的临时需求后作出评判，决定
是添加到已规划需求中还是增加独立新需
求，然后对需求落实的工作量作出评估并
对需求落实作出规划，并根据规划安排需
求落实；原则上其优先级应在已规划需求
之后。有异议时应随时与临时需求组进行
沟通。若临时需求对项目影响重大，可召
开有业务需求组和临时需求组成员参加的
联席会议来决定对需求的处理。还可提交
给项目管理办公室或项目管理委员会做评
判。对于需要修改系统功能设计的或修改
系统程序的，转交给技术开发组。
• 处理流程（技术开发组）：技术开发组对
根据临时需求所更改的业务需求、独立新
需求或对系统功能设计或程序修改的要求
进行系统功能设计和系统实现工作量作出
评估并对这些工作作出规划，常规业务需
求组对临时需求作出评判，并根据规划安
排系统功能设计和系统实施；原则上其优
先级应在已规划需求之后

应对挑战A4 - 使用临时业务的评判逻辑

• 组成：项目管理委员会、项目质量委员会、项目管理办公室（PMO）、项
目规划组、业务需求组、临时业务需求组和技术开发组
 1. 搭建项目管理架构
应对挑战B1 - 搭建管理架构
项目管理
委员会
项目质量
委员会
业务需求组技术开发组
临时业务需
求组
项目管理办
公室（PMO)
项目规划组
1 2
3
4 5 7
6

应对挑战B1 - 搭建管理架构：1. 项目管理委员会
职责
XX银行成员外部成员
岗位职责岗位职责
对项目进行高阶层管理科技部负责人（1人）
公司部负责人（1人）
1

应对挑战B1 - 搭建管理架构：2. 项目质量委员会
职责
对项目的质量进行全程
监控；定期或不定期向
项目管理委员会提供项
目质量方面的反馈和建
外部独立项目质量管
理专家（1人）
2

应对挑战B1 - 搭建管理架构：3. 项目管理办公室（PMO)
职责
对项目进行计划制定、
进度追踪并实施日常管
理
科技部专家（1人）项目经理（1人）
公司部专家（1人）项目管理助理（2人）
3

应对挑战B1 - 搭建管理架构：4. 项目规划组
职责
A 评估公司业务改革的影响：
公司部
业务专
家
（1人）
业务管
理专家
（1人）
理解公司业务部新的业务发展战略，分析对
系统开发的的影响，重点在于对架构设计的
修改和项目实施的时间与人员资源投入。
向外部业务管理专家解释公司条线改革的内
容，并与外部业务管理专家共同评估改革对
系统开发的影响。
与公司部业务专家共同评估改革对系统开发
的影响。
B 业务细则制定：
B1 确定需要制定的具体细则清单。 B1 确定需要制定的具体细则清单、向外
部业务管理专家解释理解业务政策并审核
外部业务专家所制定的业务细则。
B1 审定需要制定的具体细则清单。
B2 制定作为业务需求基础的公司业务细则。 B2 与外部业务管理专家共同制定作为业
务需求基础的公司业务细则。
B2 与公司部业务专家共同制定作为业务需
求基础的公司业务细则。
C 系统架构规划：
C1 梳理和重新审视当前系统架构 C1 与外部业务管理专家共同梳理和重新
审视当前系统架构及功能模块
C1 与公司部业务专家共同梳理和重新审视
当前系统架构及功能模块
C2 借鉴国内外同业的领先实践，修订
CRM系统的功能架构。
C2 与外部业务管理专家共同修订CRM系
统的功能架构
C2 借鉴国内外同业的领先实践，与公司部
业务专家共同修订CRM系统的功能架构。
C3 产出《公司银行CRM系统架构规划》。 C3 审核外部业务专家所产出的《公司银
行CRM系统架构规划》。
C3 产出《公司银行CRM系统架构规划》。
D. 系统建设路线图规划：
D1 基于新的功能架构，制定新系统的功
能模块建设路线图。
D1 与外部业务管理专家共同基于新的功
能架构，制定新系统的功能模块建设路线
图。
D1 与公司部业务专家共同基于新的功能架
构，制定新系统的功能模块建设路线图
D2 产出《公司银行CRM系统建设路线
图》。
D2 审核外部业务专家所产出的《公司银
行CRM系统建设路线图》。
D2 产出《公司银行CRM系统建设路线
图》。
4
4.1 4.2

应对挑战B1 - 搭建管理架构：5. 业务需求组（一）
职责
A 管理所有业务需求的落实进程：
公司部
业务专
家
（1人）
业务需
求专家
（1人）
A1 制定业务需求建立、新增与变更管理流
程与细则。
1.1 与外部业务需求专家共同制定业务需
求建立、新增与变更管理流程与细则。
1.1 与公司部业务专家共同制定业务需求建
立、新增与变更管理流程与细则。
A2 负责人员配置与调整，具体功能模块的
向外部业务分析师的分配与调整。
1.2 与外部业务需求专家共同负责人员配
置与调整，具体功能模块的向外部业务分
析师的分配与调整。
1.2 与公司部业务专家共同负责人员配置与
调整，具体功能模块的向外部业务分析师
的分配与调整。
A3 制定、追踪并监控具体需求落实的进
程。
1.3 与外部业务需求专家共同制定、追踪
并监控具体需求落实的进程。
1.3 与公司部业务专家共同制定、追踪并
监控具体需求落实的进程。
B 安排业务需求访谈：
B1 确定各业务需求的对口部门及人员。 B1 确定各业务需求的对口部门及人员。
B2 安排业务需求分析师与对口人员访谈。 B2 安排业务需求分析师与对口人员访谈。
C 审核业务需求文档（项目组内审核）：
C1 审核由业务需求分析师提交的业务需
求文档（V1.0）。
C1 独立审核由业务需求分析师提交的业
务需求文档（V1.0）。
C1 独立审核由业务需求分析师提交的业务
需求文档（V1.0）。
C2 提出修改意见并监督业务需求分析师
对业务需求文档进行修改。
C2 与外部业务需求专家讨论后提出修改
意见并监督业务需求分析师对业务需求文
档进行修改。
C2 与公司部业务专家讨论后提出修改意见
并监督业务需求分析师对业务需求文档进
行修改。
C3 二次审核由业务需求分析师提交的修
改后的业务需求文档（V2.0）。
C3 独立二次审核由业务需求分析师提交
的修改后的业务需求文档（V2.0）。
C3 独立二次审核由业务需求分析师提交的
修改后的业务需求文档（V2.0）。
D 推动项目组外对业务需求文档的审核：
D1 将业务需求文档（V2.0）提交相关部
门和分行进行审核。
D1 将业务需求文档（V2.0）提交相关部
门和分行进行审核。
D2 督促各部门和分行反馈意见，并将意
见转交业务需求分析师。
D2 督促各部门和分行反馈意见。 D2 将各部门和分行的反馈意见转交业务需
求分析师。
D3 三次审核由业务需求分析师提交的修
改后的业务需求文档（V3.0）。
D3 独立三次审核由业务需求分析师提交
的修改后的业务需求文档（V3.0）。
D3 独立三次审核由业务需求分析师提交的
修改后的业务需求文档（V3.0）。
5
5.1 5.2

应对挑战B1 - 搭建管理架构：5. 业务需求组（二）
职责
E 监督与技术开发组针对业务需求的沟通：
公司部
业务专
家
（1人）
业务需
求专家
（1人）
E1 将业务需求文档（V3.0）转交给技术
开发组。
E1 将业务需求文档（V3.0）转交给技术开
发组。
E2 督促技术开发组与业务需求分析师通过
邮件或共享空间等形式针对业务需求文档
（V3.0）进行答疑解惑。
E2 督促技术开发组与业务需求分析师通过
邮件或共享空间等形式针对业务需求文档
（V3.0）进行答疑解惑。
E3 接到技术开发组就业务需求文档
（V3.0）的疑问召开与业务需求分析师的
沟通会的申请，决定是否、何时召开沟通
会，以及沟通那几份需求文档。
E3 接到技术开发组就业务需求文档（V3.0）
的疑问召开与业务需求分析师的沟通会的
申请，决定是否、何时召开沟通会，以及
沟通哪几份需求文档。
F 处理临时业务需求：
F1 评估由临时业务需求组提交的临时需求，
决定是否需要对需求做修改或增加、对系
统功能设计进行修改或者对系统程序进行
修改。
F1 与外部业务需求专家及对口业务分析
师共同评估由临时业务需求组提交的临时
需求，决定是否需要对需求做修改或增加、
对系统功能设计进行修改或者对系统程序
进行修改。
F1 与公司部业务专家及对口业务分析师共
同评估由临时业务需求组提交的临时需求，
决定是否需要对需求做修改或增加、对系
统功能设计进行修改或者对系统程序进行
修改。
F2 对于需要对需求进行修改或增加，同时
对项目影响重大的，可决定是否召开有业
务需求组和临时需求组成员参加的联席会
议来决定对需求的处理。也可决定提交给
项目管理办公室或项目管理委员会做评判。
F2 对于需要对需求进行修改或增加，同
时对项目影响重大的，可与外部业务需求
专家共同决定是否召开有业务需求组和临
时需求组成员参加的联席会议来决定对需
求的处理，并出席会议。也可与外部业务
需求专家共同决定提交给项目管理办公室
或项目管理委员会做评
对项目影响重大的，可与公司部业务专家
共同决定是否召开有业务需求组和临时需
求组成员参加的联席会议来决定对需求的
处理，并出席会议。也可与公司部业务专
家共同决定提交给项目管理办公室或项目
管理委员会做评
F3 将需要对需求进行增加或修改的，责令
组内相关负责的外部业务分析师进行需求
的增加（V1.0）或修改（V4.0）。
F3 将需要对需求进行增加或修改的，责令
组内相关负责的外部业务分析师进行需求
的增加（V1.0）或修改（V4.0）。
F4 对需要修改系统功能设计或系统程序的，
转交给技术开发组做处理。
F4 对需要修改系统功能设计或系统程序的，
转交给技术开发组做处理。
5
5.1 5.2

应对挑战B1 - 搭建管理架构：5. 业务需求组（三）
职责
G 设计业务需求：
业务需
求分析
师（5
人）
G1 通过阅读相关将业务文档了解需求。 G1 通过阅读相关将业务文档了解需求。
G2 通过访谈对口人员了解需求。 G2 通过访谈对口人员了解需求。
D3 撰写业务需求文档（V1.0)。 D3 撰写业务需求文档（V1.0)。
D4 根据项目内审核意见修改业务需求文
档，生成V2.0。
D4 根据项目内审核意见修改业务需求文档，
生成V2.0。
D5 根据项目外审核意见修改业务需求文
档，生成V3.0。
D5 根据项目外审核意见修改业务需求文档，
生成V3.0。
D6 根据临时需求修改业务需求文档，生
成V4.0。
D6 根据临时需求修改业务需求文档，生成
V4.0。
D6 根据临时需求撰写新业务需求文档
（V1.0）。
D6 根据临时需求撰写新业务需求文档
（V1.0）。
H 解答技术开发组对于业务需求文档（V3.0）
的疑问：
H 解答技术开发组对于业务需求文档（V3.0）
的疑问：
H1 通过邮件或共享空间等形式解答技术
开发组对业务需求文档（V3.0）的疑问。
H1 通过邮件或共享空间等形式针对业务需
求文档（V3.0）进行答疑解惑。
H2 通过沟通会解答技术开发组对业务需
求文档（V3.0）的疑问。
H2 参加业务需求组安排的与技术开发组人
员的针对业务需求文档（V3.0）的沟通会
F 处理临时业务需求：
F1 评估由临时业务需求组提交的临时需求，
决定是否需要对需求做修改或增加。
F1 与公司部业务专家及外部业务需求专家
共同评估由临时业务需求组提交的临时需
求，决定是否需要对需求做修改或增加。
对项目影响重大的，可决定是否召开有业
务需求组和临时需求组成员参加的联席会
议来决定对需求的处理。
F2 出席有业务需求组和临时需求组成员参
加的联席会议来决定对需求的处理
5
5.3

应对挑战B1 - 搭建管理架构：7. 临时业务需求组6
职责
A 评估临时业务需求：
公司部
业务专
家
（1人）
业务需
求专家
（1人）
A1 对由部门或分行所提出的临时需求做评
估，包括是否应当做直接退回、解释后退
回或采纳；对于可采纳的则进行与已规划
需求的差异分析、对项目的影响度分析及
具体实施的建议分析（修改需求、修改系
统功能设计或修改系统程序，在哪个时间
点实现等）。
A1 与外部业务需求专家共同对由部门或
分行所提出的临时需求做评估，包括是否
应当做直接退回、解释后退回或采纳；对
于可采纳的则进行与已规划需求的差异分
析、对项目的影响度分析及具体实施的建
议分析（修改需求、修改系统功能设计或
修改系统程序，在哪个时间点实现等）。
A1 与公司部业务专家共同对由部门或分行
所提出的临时需求做评估，包括是否应当
做直接退回、解释后退回或采纳；对于可
采纳的则进行与已规划需求的差异分析、
对项目的影响度分析及具体实施的建议分
析（修改需求、修改系统功能设计或修改
系统程序，在哪个时间点实现等）。
B 处理临时业务需求：
B1 根据评估结果，将应当退回的需求做直
接退回或解释后退回处理，同时将退回的
处理连同相关临时需求通报给业务需求组。
B1 与外部业务需求专家共同根据评估结
果，将应当退回的需求做直接退回或解释
后退回处理，同时将退回的处理连同相关
临时需求通报给业务需求组。
B1 与公司部业务专家共同根据评估结果，
将应当退回的需求做直接退回或解释后退
回处理，同时将退回的处理连同相关临时
需求通报给业务需求组。
B2 根据评估结果，对于可采纳的需求，连
同与已规划需求的差异分析、对项目的影
响度分析及具体实施的建议（修改需求、
修改系统功能设计或修改系统程序，在哪
个时间点实现等）提交到业务需求组；同
时向需求提出方提供反馈。
B2 与外部业务需求专家共同根据评估结
果，对于可采纳的需求，连同与已规划需
求的差异分析、对项目的影响度分析及具
体实施的建议（修改需求、修改系统功能
设计或修改系统程序，在哪个时间点实现
等）提交到业务需求组；同时向需求提出
方提供反馈。
B2 与公司部业务专家共同根据评估结果，
对于可采纳的需求，连同与已规划需求的
差异分析、对项目的影响度分析及具体实
施的建议（修改需求、修改系统功能设计
或修改系统程序，在哪个时间点实现等）
提交到业务需求组；同时向需求提出方提
供反馈。
B3 出席有业务需求组和临时需求组成员参
B3 出席有业务需求组和临时需求组成员
参加的联席会议来决定对需求的处理
B3 出席有业务需求组和临时需求组成员参

应对挑战B1 - 搭建管理架构：8. 技术开发组
职责
对系统功能设计及后续
技术开发进行直接运作
科技部专家（1人）技术专家（1人）
IT工程师（15人）
7

应对挑战B1 - 制定项目管理制度和需求推进的机制
• 负责组：项目管理组（负责需求及需求实施的标准化、可追踪化、可检索
化的管控）
• 标准化：需求实现全面标准文档化和编号化，所有文档以单一文档库所存
放版本为准
• 可追踪化：全程记录每个需求的落实人、功能设计人及编程人等；文档内
明确写明文档撰写和修改的内容及责任人；由专人负责维护和更新需求及
与需求相关文档的版本及状态，同时还要负责保管和维护各需求内各细项
当前内容及历史内容的提出来源（部门/分行及具体提出人）、原始依据
（会议纪要、电子邮件；口头及电话提出的若无文档则视为无效）及时间
• 可检索化：项目组内成员及项目组外各部门/分行CRM项目联络人经授权
可在单一文档库内查询到任何需求及相关文档的所有信息
• 可重复使用化：文档库内的文档可用于项目升级或其它项目开发的参考
 3. 需求及需求开发的标准化、可追踪化、可检
索化和可重复使用化机制
• 由总行科技部和公司部以及外部专家共同在项目的需求管理、开发管理、
需求落实进度管理、系统功能设计进度管理、系统开发管理和资源管理等
方面制定详细制度
 2. 制定项目管理制度

2014年CRM系统开发规划建议
其中2014年具体建设任务建议安排如下：
4月 5月 6月 7月 8月
5.1 5.15 6.1 6.15 7.1 7.15 8.1 8.15 12.31
前
期
准
备
组
织
建
设
系
统
规
划
需
求
落
实
完成管理
组结构、
人员构成
建议的行
内讨论和
批准
建立项目管
理组及下属
各小组，并
逐步实现人
员到位
管
理
建
设
项目管理组完成相关管理制度建立，其中主要
是需求部分的管理办法。这些管理办法应该包
括业务流程和岗位职责：
需求建立管理；
需求新增及变更管理。
项目规划组规划整体系统规划工作：
• 理解公司业务部新的业务发展战略，分析对管理工作和业
务拓展工作的影响；
• 借鉴国内外同业的领先实践，重新审视和修订CRM系统的
功能架构 – 产出《公司银行CRM系统架构规划》；
• 基于新的功能架构，制定新系统的功能模块建设路线图 –
产出《公司银行CRM系统建设路线图》。
X
X
银
行
科
技
部
埃
森
哲
项
目
管
理
组
项
目
规
划
组
业
务
需
求
组
规划组专家继续支持具体模块的设计落地工作，以确保详细设计能符合规划设计要求
业务需求组对2014年所有需求进行细化（含客户管理分析、产品管理分析、绩效管理、营销管理
和管理工具）。在此过程中，需求组应补充外部业务专家支持，并与规划组密切沟通，以确保
2014年需求制定和细化能符合整体规划
业务需求组对2014年新增需求做应对。考虑整体实施时间，这
部分需求应以业务需求急、系统改动量中等的需求为主。这部
分应充分考虑规划成果的安排。
业务需求组参与
2014年系统功能建
设和测试
12月

应对挑战B1 - 建立共享文档库和知识留存机制
• 建立项目内人员共同使用的文档库，集中存放与项目需求管理及技术开发
管理的所有文档（如：业务需求书、业务需求更改书、临时需求更改需求
书、系统功能设计书、系统功能设计更改书等），由专人负责文档的上传
及维护，同时所有相关人员均可在该文档库内查询到所有所需要的文档
 4. 建立共享文档库
• 鼓励项目内成员将所有文档存放在文档库
• 岗位换人时要做到基于文档库内文档的知识转移工作
 5. 制定留存项目内知识的管理制度

应对挑战B2 – 采纳双规制的推进模式
• 业务需求组负责梳理、细化和落实2014年计划中的业务需求
• 同时项目规划组对原需求规划做出梳理，对系统做出整体规划
• 详见“2014年CRM系统开发规划建议”页
 6. 采纳双规制的推进模式

目前2014 - 2016年CRM系统开发规划
按照此前的规划，2014至16年功能建设规划如下：

06_CRM系统建设分析、挑战与解决方案

Recommended

Recommended

More Related Content

Similar to 06_CRM系统建设分析、挑战与解决方案

Similar to 06_CRM系统建设分析、挑战与解决方案 (20)

More from Ye Meng

More from Ye Meng (9)

06_CRM系统建设分析、挑战与解决方案