智慧银行新核心系统产品选型方案设计

1、智慧银行新核心系统产品选型方案设计技术创新，变革未来参考“泛核心”的理念，定义核心系统群保证核心系统转型顺利的最小集，结 合银行的IT架构和系统建设情况，定义核心系统群包含了交易的前中 后台关联系统以及核心业务的基础支 撑系统。通过多个IT系统的协同和处 理，为客户提供差异化的产品和服务，同时满足日常经营管理需要。通过调研分析，结合银行业务发 展和IT规划，定义核心系统一个交易 处理引擎，包括存款、借记卡等业务 处理，为核心业务处理提供客户、产 品、定价、运营等基础公共服务，同 时为核心系统群提供账户管理接口功 能。企业架构核心系统群核心系统2商业银行121软件包选型的主要目标是承接核心系统群

2、规划，兼顾业务要求及技术要求，采用量 化手段，分析相关软件包的适合程度，形成有针对性的分析结果，为后续实施相关 决策提供依据确定供应商系统验证厂商初选与测试 案例制定确定选型方法、范围与计划准备 阶段确定选型标准制定选型计划确认系统报价涉 及的度量指标确定厂商名单编写测试案例实地考察商务评估最终确认厂商制订实施进度和 资源计划准备和发出RFP评估厂商建议书组建项目组选型任务阶段 成果实施总体 方案选型计划选型标准测试案例招标书评估报告工作 要点建立专职选 型组织、收集 核心系统建设 的相关信息确定备选的 厂商名单，发 出方案咨询邀 请(RFI)对所收集的 到的RFI进行 筛选并确定进 入下一阶

3、段名 单邀请厂商进行 现场演示、案例 测试POC和系统 性能测试对所收集到的RFP进行评选选 并确定进入最后 的名单向各参选厂 商发出中标结 果，启动商务 谈判及签约工 作厂商交流建立评估 标准和评估 计划，准备 方案咨询邀 请（RFI）系统验证(POC)依据标准打分122产品选型项目组组织架构技术支持组（支持POC的环境）组长：科技部经理 成员：科技部的平台、网络、基础设施 等骨干，共计35人技术评估组（性能案例编写及技术评估）组长：开发中心经理 成员：技术部门骨干，包括了开发、管 信、运维、平台，共计610人业务评估组（功能案例编写及业务评估）组长：会计结算部经理 成员：业务部门骨干，每部

4、门12人 分行骨干，每分行12人组核心系统项目群实施筹备组长、副组长、成员专家支持组外部专家1.负责核心选型需求和案例 中的业务功能案例编写；2.负责核心选型过程中评估 软件包的业务能力和功能支 持情况；1.负责核心选型需求和案例 中的非功能性案例编写；2.负责核心选型过程中评估 软件包的架构、平台、数据 以及性能评估；1. 负责POC 的基础设施环境 准备和过程支持；组 织职 能123圈定出合理的具有代表性的产品选型需求是选型成功的前提，也是验证案例编写的基础功能验证常用业务关键业务现有系统问题厂商推荐的产品亮点及优点针对性建议产品薄弱点产品差异点其他必要案例补充性能验证联机性能低硬件配置情

5、况下的性能指标折算交易配比采集生产数据（Top 10） 对未来的交易预测与联机功能测试匹配性能指标达标要求处理极限批量性能模拟特定时点月末/峰值季末、结息日可在规划阶段形成的核心系统建设高阶业务需求基础上，筛选一些典型的功能与非功能性需求，形成产品验证关键需求，用于指导后续的选型评估工作124在新核心系统规划成果的基础上，充分利用IBM的核心评估方法论，确定评估维度，保证评估范围既覆盖核心系统的业务范围，也满足业务能力要求IBM核心评估方法论新核心业务能力要求新核心业务范围存款客户中心基本信息关系信息扩展信息参 数 预 警管 理 授 权机构 柜员基础业务层银行卡支付结算产品中心定价中心产品目录

6、费用及规则产品配置利率及规则产品服务汇率及规则运营中心现 金 账 户 清 算 对 账重 控 管 理 管 理 差 错多法人支撑冲正结售汇合约中心合约类型合约关系 合约生命周期流 水 日 志交易核算分离相对独立的核算引擎，核心业务 模块与核算引擎松耦合以客户为 中心以客户为中心运作客户信息管理，统一客户视图呈 现，支持客户成长管理，提高客 户统一体验、满意度和忠诚度3差异化定价要求，实现客户为中心的差异化2快速产品创新产品模型，支持产品快速创新， 适应业务的快速发展的需要154业务 多元定价模式满足市场化定价的能力 定价统一合约视图相对独立的核算引擎，核心业务 模块与核算引擎松耦合账户管理能力构建

7、以客户为中心，面向产品2统一运营能力灵活的机构/柜员管理，安全的 凭证/现金调拨管理，集中的参 数管理，提升业务对业务规则 调整的参与度1风险管控能力事前预警、事中授权、事后监 督的多维度的风险管控能力3管理设计的层次化、关系型客户账 能户体系力IT架构能力分层、模块化、松耦合的IT架 构服务能力；支持10年后日均交易300万笔，账户数1600万，客户700万12IT能数据支持能力 力核心系统对数据平台的支持能力，统一数据模型和数据逻辑5+3+2能力客户能力 产品能力 定价能力 合约能力运营能力 技术能力125根据评估范围，建立了13个评分主题，其中9个为业务主题 ，4个为技术主题，依据主题自

8、顶向下逐层分解选型需求，得出最终的评分细项评分模型建立银行部 门评分评分结 果汇总方法论 与知识库高阶需求 国外典型评测领先实践 部门人员访谈评分项评分项评分项评分项评分项评分项评分项评分项主题1主题2主题n子主题1.1子主题2.1子主题2.2子主题n.1子主题1.2新增主题新增子主题自顶向下根据能力 需求建立15个评分主 题为每个主题确定权 重汇总评分项，分组为若干子主题如果子主题无法覆 盖所有评分项，则新 增子主题为每一个评分项添 加优先级权重银行部门银行部门银行部门银行部门银行各部门根据同 合作厂商交流及POC的 情况，分别对相关评 分项进行打分评分汇总各部门完成打分 后，根据主题权重、

9、 子主题权重以及评分 项优先级权重计算核 心系统分值对于多个业务部门 打分的评分项进行汇 总计分备注主题建议占比IBM_USER:同客户协商后确定分类1产品7%业务2定价7%业务3客户5%业务4合约5%业务5运营11%业务为主题和每个评分项设置权重，针对评估项进行打分，最终根据主题权重、子主题评估项权重设置标准5：优先级高（属于关键、重要的能 力要求）3：优先级中（属于一般能力要求）2：优先级低（属于非重要要求；例如可选功能项）30%40%30%权重以及评分项优先级权重计算核心业务系统分值主题权重总体比例建议基本业务关键能力技术存款 结售汇支付结算 借记卡产品 定价客户 合约运营架构 接口数据

10、 平台:8对评估标准中的每个评分项，可根据 “权重”&“产品情况”的评分值进行多个维度的评估与分析在备注中注明本 次评估的发现及 被评估产品的具 体情况。如在评 估人评估的方案 书中有相关说明， 请在备注中明确 方案书的名称、 章节和页码。9产品情况代码含义分值代码简述C核心系统软件包以其标准的形式提供功能，无须对软件 做修改。5完全满足F功能包含在核心系统业务软件未来发布的版本当中，可 以在6个月之内获得这个新版本。请在回复的注释部分注明计划什么时候发布这个新版 本。4未来版本满足S所提议的核心业务系统需要作较小的修改（最多10人天的工作量）来满足此需求。3小修改满足M所提议的核心系统需要作

11、中等规模的修改（从10人天至30人天的工作量）来满足此需求。2中修改满足L所提议的核心业务系统需要作重大的修改（多过30人天 的工作量）来满足此需求。1大修改满足NC当前系统或第三方的解决方案不能满足此未来需求，且进行软件修改不可行或是从成本角度来看不划算。0无法满足号序评估 范围评估项评估子项说明是否 必需需求 优先 级况产品 产品情况 情描述备注关联测 试案例部门评估 标志5本、外币整存整取支持国内和海外分行YBNC无法满足TD0-0001 起存金额（人民币，外 币）TD0-0002 支持存入介质V本、外币零存整取 储蓄存款支持国内和海外分行YBNC无法满足TD0-0055 起存金额（人民

12、币）V16公司业务主要产品类别 本、外币活期存款YBNC无法满足SA1-0001 支持本币外币，一个账 号只能存取单一币别SA1-0002 自选账号/非自选账号V总体要6求个人业务主 储蓄存款要产品类别产品 种类测试编号业务要点操作步骤（交易码）关键验证点 编号关键验证内容参数会计分录及 核算科目备注个人整 存整取TD0-0001起存金额（人民 币，外币）3910 建立对私客户信息(已有客 户信息的不用执行此步)-1651产 品种类= *TD002001TD0-0001-K0150元起存，外币整存整取存款起存金额为 等值人民币100元的外币。产品参数： 起存金额TD0-0001-K02使用08

13、03机用储蓄存单TD0-0001-K03开户成功联动表外重控付出一份TD0-0002支持存入介质存入定期一本通/定活一本通：1654一本通存入-存款种类-整存 整取TD0-0002-K01存单，定期一本通，定活一本通，理财卡.注：考虑到POC阶段，备选厂商的系统对于验证人员而言是一个全新的系统，所以安排验证案例数建议人均 不超过10个/天。POC的总案例数，根据IBM的实践经验，不建议超过200个。10在编写验证测试案例时，建立测试案例与评分项的对应关系确定评估标准后，通过功能与性能两个维度进行产品验证及评估通过难易结合的典型案例设计， 能对备选系统在所关注的关键业 务能力上的表现有一个较充分

14、的 了解通过有针对性的联机、批量测试， 能对备选系统的关键处理能力有 一个比较充分的了解业务技术性能客户产品定价合约运营存款银行卡支付结算 结售汇架构数据接口平台联机处理能力 批处理能力 专项性能系统资源开销P O C验证11有效的选型验证需要包括功能验证和性能验证两大方面，并通过其验证核心系统的业务、技术 及性能情况功能验证性能验证通过性能验证为选型及未来生产环境资源配置提供参考依据通过联机混合场景测试以及批处理测 试，观察和分析系统的整体性能状况， 为选型提供依据在资源相对有限的POC环境下，通过 性能测试分析系统的线性扩展能力， 为未来生产系统资源配置提供参考性能验证主要关注指标性能验证主要目标单交易系统 资源消耗异常现象（超时，死锁等）130联机交易 响应时间专项性能批处理时间系统资源消耗（CPU，内存等）通过前期与厂商的沟通，确定待选产品，建议控制在4-5个，不同厂商的功能验证和性 能验证可以适度并行进行，以4家入围厂商为例，整体POC周期共计约46周1、功能验证串行进行，每家5天时间。2、性能验证分二轮，每一轮二家。二家并行验证，每轮10天时间系统验证 提交验证报告 功能测试 性能测试13图例：选型存在的局限性与风险这种情况