银行数据中心应用平台项目需求说明书

银行数据中心应用平台项目

需求说明书

1

目录

1.

项目概述 1.1项目背景 1.2项目目标 1.3项目范围 1.4项目进度要求 2. 现状描述 3.

总体要求

3.1.

总体概述 3.1.1. 总体业务需求 3.1.2. 总体技术需求

3.2.

项目实施原则 3.2.1. 业务驱动 3.2.2. 规范性 3.2.3. 稳定性 3.2.4. 开放性 3.2.5. 可扩展性 3.2.6. 安全性 3.2.7. 集成性 3.2.8. 易用性 3.2.9.

经济性

4. 详细需求

2

5 5 5 7 8 8 11

1010121313131313141414141415

4.1.业务要求 4.1.1总体要求

4.1.2 具体业务功能要求 4.2技术要求 4.2.1系统性能要求

4.2.2系统架构要求 4.2.3环境要求 4.2.4平台安全性 4.3与其他系统接口的要求 4.4系统建设要求

4.4.1架构建设要求 4.4.2安全保障要求 4.4.3优化完善要求 4.4.4二次开发要求 4.5项目开发方式 4.6数据标准要求 4.7安全性要求 4.8培训需求 4.9共组团队要求 5.

项目实施内容 5.1项目启动 5.2产品差异分析

3

15 15 16 23 23 23 23 24 24 25 26 26 26 26 27 27 27 27 28 28 29 29

5.3项目建设策略 5.5用户验收测试 5.6用户培训 5.7上线运行 5.8 最终验收 6.

实施管理要求

6.1. 项目管理要求 6.2. 实施要求 6.3. 后续服务支持 7. 项目交付成果 8.

项目验收

8.1. 项目验收的组织机构8.2. 初步验收 8.3. 质保期 8.4. 最终验收

4

29 31 32 32 32 32 32 32 33 33 35 35 36 36 37

1. 项目概述

1.1项目背景

目前，商业银行已经建立了可以覆盖全省的网络中心，随着业务的发展，行内已拥有多个业务系统，众多业务系统的建立使我行的业务在准确性、实时性上得到了极大的提高，同时也降低了业务人员的办公出错概率。虽然，电子化系统能极大的提高业务效率，但是，随着电子化系统的不断增多，其存在的缺点也逐渐的暴露出来：

 

数据孤岛，使得各业务系统之间数据共享困难。

不同业务系统的相同指标数据有可能不一致，使得系统之间的衔接困难，不能满足后续应用系统的快速构建的需要。  

大量数据冗余。

为满足多个应用系统，需要同时对多个源系统进行频繁数据采集，且每个应用系统都会向源系统采数，效率不高，对源系统的压力较大。  

不能满足后续应用系统快速构建的需要。

每个系统的开发商不同，其数据模型和标准也不同，数据的可用程度降低。

这些缺点，降低了行内数据的数据抽取、数据转换、数据整合、数据加载、数据归档、数据监控调度等，影响了相关部门对数据的管理分析。

1.2项目目标

本项目的目的是立足于全行数据治理的基础之上，整合所有业务系统的源数据，准确完整地分析商业银行现有的数据、流向以及数据使用标准，建设一套高数据标准、高数据质量、高可用、高性能、高稳定的数据中心系统，为各个业务部门的管理分析提供统一而且完整的数据支持，为今后各个面向主题的分析型应用的开发建设提供数据基础

5

和技术基础。

通过建设集中的数据中心平台来实现统一数据视图和数据的服务和共享，提高商业银行企业管理电子化水平。

商业银行数据中心平台，首先是一个基础性的数据汇集、分发和整理的平台，是为了能对生产和管理数据进行集中、清理、整合和分发，为各类管理信息系统和决策支持系统提供准确、统一、全面的基础数据而建立的。

此外商业银行数据中心平台同时需要引入了更为先进的业务和技术理念。数据中心平台给商业银行带来的不仅仅是系统能力的提高，同时也会带来业务上，管理理念上的提升。

商业银行数据中心平台的目标应该达到：   

数据处理、分发、流转平台；

为目前商业银行已经存在的应用以及未来的应用提供数据。

系统建设反过来会促进各个业务系统的发展，特别是数据质量的提升。通过统一数据清洗，为各级机构相关应用系统提供干净、一致、全面的数据。 

符合银监会《银行监管统计数据质量管理良好标准》的相关要求，并配合商业银行完成《银行监管统计数据质量管理良好标准》外部评估工作以及人行金融统计标准化试点工作的建设。   

通过技术手段提升行内数据治理能力。 综合分析、集成报表平台。

逐步构建起面向商业银行的各个业务条线、各分析角度的全面地、综合的报表平

6

台。  

构建数据、业务的单一视图。

通过抽象和集成，构建企业级数据中心的数据模型，保证其扩展性、稳定性、灵活性。满足综合的分析型业务需求应用。  

专题分析应用

通过引入经济资本管理、产品定价、资产负债管理、盈利性分析、客户关系管理、风险管理，引入先进的业务和管理理念，提升商业银行的管理水平。 

未来要求支持关键的准实时、实时应用。

数据中心平台最终要统一基础数据源，为各级机构管理层满足其管理、分析、上报的基础数据需要，保证有阶段性成果。项目应遵循以下原则： 

远景规划、分步实施、重点突破，务求实效，作为整个数据中心建设的指导思想；    



采用成熟的技术，配置要平衡；

具有良好的稳定性、高效性、安全性、灵活性； 具有开放性，有较好兼容能力； 具有较强的线性扩充能力； 需要能保护现有投资。

1.3项目范围

本项目主要包括如下工作内容：

7

      

数据中心应用平台的开发 配合相关系统改造实施 成品软件采购（配置见附件） 系统测试 系统试运行及上线 系统培训 系统升级维护

1.4项目进度要求

综合分析项目整体进度、实施内容及难度，项目整体周期要求在自合同签署日起6-8个月内完成本项目所要求系统建设并交付使用。

2. 现状描述

商业银行已经建立了可以覆盖全省的网络中心，1个营业部27个机构网点主要分布在德阳市、成都市、广汉市、什邡市、绵竹市、罗江县、中江县；2010全行总资产已超过300多亿。

目前有以下业务系统：信贷系统、核心系统（改造中）、财务系统、中间业务、大额支付、小额支付、银联前置、微贷系统、网上银行系统、ATM&POS&CC、黄金交易系统、短信系统、第三方存管、支付宝前置、实物票据管理系统、网银跨行转账、电票系统、工商行政验资、支票影像、财税库银、身份核查、电子回单柜系统、银医联名卡系统、理财业务系统、渠道平台。

 业务系统现状

8

 核心系统目前正在改造，综合报表系统（包含1104报表、人行支付报表、反洗钱报表、行内监管报表）需要更新。

 商业银行针对目前应用系统对业务系统的数据使用情况出台了一套数据标准，目前还没有进入到具体实施阶段。

 数据使用现状

目前行内所使用的各种应用和来源数据之间交叉成网状。

主要问题：

   

数据信息孤岛，各业务系统数据共享困难。 不同业务系统的相同指标数据有可能不一致。 大量数据冗余；

为满足多个应用系统，需要同时对多个源系统的进行频繁数据采集，且每个应用系统都会向源系统采数，效率不高，对源系统造成较大压力。  

不能满足后续应用系统的快速构建的需要。

这些源系统的开发商不同，其数据模型和标准也不同，数据的可用程度降低。

9

 

在商业银行数据标准化工作的基础上，完成标准落地工作。 完成商业银行数据质量工作系统落地工作。

3. 总体要求

3.1. 总体概述

数据中心应用平台在功能上需覆盖商业银行现有业务系统，需满足外部监管要求。数据中心应用平台作为商业银行的数据整合中心，需与核心系统、信贷管理系统、全行总账系统、票据系统、征信系统、报表报送系统等现有系统紧密衔接、并且需考虑到商业银行未来将要建设的系统的接入问题。此外在平台建设及上线过程中需要充分考虑历史数据迁移及数据初始化的复杂性。

数据中心应用平台建设过程是一个长期的过程，为了保证投资的连续性和良好的投资回报率，要求投标方必须满足以下要求（具体要求细节见后面章节中的描述）。这些要求都是保证商业银行数据中心应用平台建设成功的基本要素。



要求投标方对商业银行的业务现状、IT现状有一定的了解的基础上提出科学、有针对性的、实际可行的技术方案。 

技术设计方案不但要解决现有数据中心应用平台建设的需求，又要有一定的前瞻性，要求方案中包括针对商业银行数据中心应用平台建设的长期规划内容。 

投标方要有成熟的数据中心应用平台方面的项目管理和实施方做指导, 有类似的成功经验。 

商业银行将对投标方的服务团队进行资格认定。

10

 要求投标方对商业银行IT人员在实施过程中进行技术培训，包括方、数据模型、软件产品。

 解决方案的整体性要求，为了避免不必要的IT资源投入，要求投标方提供的解决方案具有整体性。方案中的建设规划咨询、软件产品、硬件产品以及相关的产品服务、实施服务及后期维护服务由投标方整体提供。（包括系统上线后的服务）。

 解决方案的前瞻性要求，要求投标方遵循整体规划、分步实施的策略对商业银行数据中心应用平台建设做出长远的规划，规划内容包括IT和业务两方面。

 数据中心应用平台建设方要求， 要求投标方提供的解决方案要有业界认可的经过实践的方作为指导，并在应标书中加以适当的解释。

3.1.1. 总体业务需求

商业银行数据中心应用平台旨在构建全行统一的数据服务平台，建立统一的、层次合理的、灵活的企业级数据标准模型，提供全行统一的视图。并以数据中心应用平台为基础，建立各种主题应用、专题分析应用，建立全面完整的分析体系和应用平台，借助各种高级分析、报表和灵活的查询功能，为招标人的业务经营决策提供全面的支持。

数据中心应用平台应支持多法人实体，普查行内数据，理清各系统数据架构，将核心系统、信贷管理系统、网银系统、历史数据等的数据整合到数据中心应用平台中，建立适合我行需要的银行数据仓库主题模型；建立稳定高效的数据抽取、转换、装载处理和调度管理监控平台；建立行领导驾驶仓，给高管层提供决策支持；建立统一报表平台，完成现有报表平台迁移；将部分报表处理过程从生产系统迁移至数据中心应用平台处理，减轻交易系统压力；验证数据质量，确保数据质量过硬，系统安全可靠，为其他分析管理系统提

11

供基础数据（如客户关系管理、人力资源系统、1104、征信、反洗钱、分析管理报表等）。系统需适应业务发展规模的不断扩大及规则的多变性，达到高效性、高并发处理能力、可扩展性和灵活的参数化管理。

3.1.2. 总体技术需求

基于现状梳理和分析的结果，结合业界最佳实践，制定我行基础数据平台的总体技术方案，从应用架构、数据架构、基础架构等几个方面提出完整的技术方案，方案应当全面、详细，达到可以直接指导实施的程度。

应用架构：从数据抽取、数据交换、数据加工、作业调度与监控、数据访问、数据管控等维度制定基础数据平台的功能框架；

数据架构：设计层次清晰、功能合理的基础数据平台数据架构，数据架构应当能支持我行各类分析型应用的需求，并在此基础上给出各层次模型的设计策略与原则；

特别的，在此阶段需要结合实施厂商对于现有数据标准的理解，为商业银行设计数据中心应用平台核心的数据模型，并完成与主要源系统的数据映射

基础架构：对我行基础数据平台数据量进行合理估算，在此基础上给出基础数据平台的物理架构建议。

提供数据标准模型化的设计方案，对我行业务系统现状、数据现状和信息应用现状进行全面梳理，在此基础上，结合国内外同业的相关最佳实践，依照我行现有的数据标准，为我行制定数据模型方案以及相应的实施方案。数据模型设计必须紧密结合商业银行的业务特点和未来发展，在模型的适用性、灵活性和拓展能力等各个方面符合数据标准的发展与业务需求。

12

3.2. 项目实施原则

项目要求以成熟软件产品为基础，基于商业银行各业务系统的数据特色、相关制度要求、项目规划阶段所制定的高阶需求，细致开展软件产品客户化的差异分析，并在产品差异分析的基础上以客户化开发方式进行系统实施，尽可能缩短项目实施周期，降低项目实施的风险。

3.2.1. 业务驱动

数据中心应用平台须基于商业银行业务特色、相关制度要求、规划阶段制定的高阶需求以及产品差异分析进行客户化开发，须满足监管机构相关要求、符合商业银行系统管理规范。系统不仅要能够支持行内现行系统的功能，还需具备良好的参数体系以支持未来业务的变化，从而达到业务快速发展和创新。

3.2.2. 规范性

系统的设计需符合业界标准，功能、界面、内容与业务需保持高度统一性和标准性，从而达到服务的规范化和管理的高效性。

3.2.3. 稳定性

系统应采用稳定可靠的软件平台、成熟的开发技术，保证系统的高可靠性和稳定性，确保系统的正常运行。

3.2.4. 开放性

系统应具备足够的开放性和灵活性，系统支持主流的标准或规范。

13

3.2.5. 可扩展性

伴随商业银行业务的不断发展，管理水平的持续提升，行内对系统的要求也会随之提高，因此系统应具备良好的扩展性，在不影响系统已有业务功能的情况下，易于扩展，易于创新的业务模块或功能，持续支持核心业务发展。

3.2.6. 安全性

数据中心应用平台应具备统一完善的安全管理机制，提供安全的身份认证机制和完善的加密机制，确保信息不被他人窃取。同时要有严格的权限控制机制，既要满足信息共享的要求，又要保障信息的安全性。

3.2.7. 集成性

数据中心应用平台需要与行内所有系统对接，这就需要系统本身能够提供开放和标准的接口，一方面在项目实施过程中可以很好的与其他系统完成集成对接，另一方面在日后周边系统发生变化时也可做到快速灵活集成，实现不同应用系统的互联互通，并且充分考虑周边系统因为升级改造而产生的集成性要求。

3.2.8. 易用性

数据中心应用平台能根据技术的更新和行内业务的创新方便地进行升级和维护，应具有良好的用户界面，容易学习和使用，并能提供在线帮助，还需针对不同的使用角色提供专用的管理和维护平台，便于维护并能记录相关的日志。

3.2.9. 经济性

该数据平台须基于成熟平台的产品，能够根据商业银行相关需求进行配置或客户化开发，并且支持未来业务需求的扩展，可方便实现新功能的上线投产，缩短系统实施周期，降低实施成本，提高实施效率。

14

4. 详细需求

4.1.业务要求

4.1.1总体要求

1）总体目标

 

运行模式：实行总行业务大集中的模式。

针对我行的情况和各应用系统的特点，系统的设计思想应风险控制功能完善；业务参数灵活配置；信息统计功能强大；外围接口规范”进行。

2）系统设计原则



功能全面、安全稳定。

平台要求功能强大，应涵盖行内所有应用系统功能。并以规范业务操作流程、保障安全运行及风险控制作为设计的基本原则。该平台必须是一个成熟的平台，一旦投入正式运行，不应再有大的修改或者频繁的小修小补，即使不得不修改，对平台的修改也绝不能影响正常业务的连续进行；具备后台备份平台，一旦主平台出现故障，确保最短时间内恢复主平台的所有数据，保证业务的连续运行。



权责严密、操作方便。

以控制风险为宗旨，各级业务人员的责任和权利范围设置严密、明确，确保业务操作的安全；同时系统应界面友好、便于操作、系统提供灵活的、人性化的提示及业务风险控制。



接轨国际惯例，业务流程自动化。

平台应在工作流的控制下运行，对数据操作实现自动化控制。 

结构先进、维护工作量小、扩展能力强。

平台结构先进，采用参数化设计，以便于维护和扩充；采用模块化设计；平台的维护及

15

升级放在后台，实现前台的零维护工作量，即在后台进行程序的修改；开放式的结构框架，为未来的业务扩展留出接口，从而更好地适应我行今后业务发展的需要。



立足全局重视管理

平台在提供内部的业务操作处理同时，应立足全局重视管理。 

系统应融入全行的全局化系统建设中，与行内各系统实现信息的互通。

4.1.2 具体业务功能要求

 数据中心

能够方便完成数据处理、数据存储、数据使用、数据备份、恢复等工作的全程管理。提供自动化处理管理机制，能够管理任务调度和查询日志。



数据源整合

数据中心应整合的源系统数据有（但不限于）信贷系统、核心系统、财务系统、中间业务、理财业务系统、债券业务系统、大额支付、小额支付、银联前置、微贷系统、网上银行系统、ATM&POS前置、黄金交易系统、短信系统、第三方存管、支付宝前置、实物票据管理系统、网银跨行转账、电票系统、工商行政验资、支票影像、财税库银、身份核查、电子回单柜系统、银医联名卡系统、理财业务系统、渠道平台。

能基于数据中心管理业务系统产生的新的数据。针对缺失的数据： 1、 2、



能提供手工补录功能与通过固定格式导入功能。

能够分析缺失数据的源头并针对数据源提出合理的改造方案。 数据抽取

采用先进的ETL工具，将不同数据平台、不同源数据形式、不同性能要求的源数据数据抽取到数据中心系统中。

16

在数据抽取时需要重点考虑数据抽取的效率，以及对现有业务系统性能及安全的影响。 数据采集过程应该是自动化的，在每天业务系统日结完成后立即自动化进行数据采集，不需手动触发。

 数据转换

对从不同数据源采集到的数据，根据数据模型的要求，进行数据的转换、清洗、拆分、汇总等处理，保证来自不同系统、不同格式的数据的一致性和完整性，为应用平台提供高质量的数据服务。

项目前期确定数据转换的粒度和规则。 

数据加载

采用高效的加载性能数据加载工具，将处理加工后的数据载入数据中心。 

历史数据归档

数据中心的建设应充分考虑行内至少20年的历史数据的存储及在线查询。 

统一监控调度

数据中心做为全行的数据交换中心，是一个非常庞大的系统，其投产后的运转情况均是自动化的，那么必然需要一套合理的、健全的、成熟的、统一的监控调度策略，以保证整个系统安全、稳定、简单的运行。  金融数据模型



建立高度抽象、实用的数据中心模型：数据中心项目对数据模型要求较高，数据模型的合理与否将关系到项目的成败，因此必须选择先进合理的建模理念，紧密契合已有业务系统，深刻了解银行业务和核心系统，建立高度抽象、实用的数据中心模型。

17

 数据模型是数据标准落地的产物，是基于商业银行的数据的数据标准的体现，要符合商业银行现有数据的标准体系和要求

 数据模型落地过程至少分为四个步骤，1）数据标准到概念模型，2）概念模型到逻辑模型，3）物理模型建立，4）ETL和应用的映射，这四个部分每一个阶段都要有相应的评审阶段，对内容和相应的文档代码进行评审，方可进入下一个阶段

 

提交物包括模型设计说明书，ER图和相应的建库参考代码

数据模型要有一定的扩展性和灵活性，能够支撑数据中心平台的建设和应用的需求，并且能够对数据标准有一定的反馈，能够促进数据标准的提升和演变

 

建立适合商业银行的指标库体系。

数据中心模型的建立应充分考虑下列应用（但不限于）对数据的使用：

 综合报表系统（1104报表、人行大集中报表、人行利率报表、人行金融稳定

报表、人行理财产品统计报表、人行反洗钱报表、人行支付报表、国际收支申报报表、其他监管类报表以及行内各类定制报表）  行长决策系统（领导驾驶舱）  财务管理系统  管理会计系统  绩效管理系统  非现场审计系统

 操作型客户信息系统（OCRM）  分析型客户关系管理系统（ACRM）  银行风险管理系统

 建立统一的报表集成平台

18

主要目的是为了统一集中的管理行内报表，能对一些公共报表及相关资源进行共享，并且可以集中监控报表的使用情况。该平台包括但不限于以下要求：   

支持多种报表类型发布：cognos报表、excel电子报表等； 统一报表门户，形成行内的报表管理门户；

建立一套完善的报表授权、分类、发布机制，从而保证信息的共享及一致性，为业务分析提供技术保障； 

建立一套集中的信息展示环境，满足不同层次不同机构用户的信息获取需求以及个性化展示需求；屏蔽不同系统、不同报表工具给用户带来的差异性。 

具有良好的质量控制功能，能自动实现总分、表内、表间检验和预警提示的需要，能灵活设定参与检验的机构、指标的逻辑关系，自动提示异常变动及错误情况。 

该平台具有批量报表的功能

 分为自动批量生成和手工批量生成。

 该功能实现某报表日期、某机构的一张或多张报表的批量生成。  系统要提供批量报表生成的日志。 

系统管理功能

系统需要满足安全管理要求。包括：机构、权限、柜员角色、密码，监控等等，符合银行日常管理规范的功能。

通过先进的展现工具及多样化的展现方式，向用户提供灵活而强大的查询、统计、分析功能，并按要求生成报表。报表主要通过表格形式展现，数据可以转化为图形，并且要求在页面展示和导出到excel、PDF等类型时不失真。支持分页浏览，支持图文混排，支持垂直表、水平表、交叉表、柱图、饼图、线图、雷达图、甘特图、速度计、气泡图、漏斗图等图标类型；支持双坐标轴图形展示。可以同时查看多个报表、并且可以选择多种排版方式进行

19

展现。 表格与图形能够输出到EXCEL、HTML、PDF等格式、要求所见即所得。

指标的告警展示，系统可以设置统一的指标进行报警展示，用户也可以选择多个不同的指标向设置动态报警展现。

有权用户可以对每个具体报表进行批示或者评论。

可以根据模板自动生成分析报告，模板具备从表格中取数与函数计算功能，可以编辑并且导出

用户查看某个报表时，可以链接相关的报表。

提供手工报表填置与汇总功能，提供报表数据逐级汇总，支持多种汇总关系。 提供统一的报表发布、分发功能。可以保存个人自定义报表模板，可以设定为共享报表模板或私人报表模板。

支持分析要求，可视化、零编程的实现分析、图形展现的定制；具有上钻、下钻、层钻、切片、旋转、过滤、排序，TopN等OLAP分析功能。可以基于多为模型灵活定义各种扩展指标。具有丰富的图标功能，包括直方图、饼图、趋势图、点图、区域图、雷达图、双Y轴图、气泡图等。

在数据中心基础上需要建立的业务应用包括：

 综合报表系统 除1104报表、人行大集中报表、人行利率报表、人行金融稳定报

表、人行理财产品统计报表、人行反洗钱报表、人行支付报表、国际收支申报报表、其他监管类报表等各类监管报表外，定制报表200张左右。  行长决策系统（领导驾驶舱）（要求实现在移动终端上的展示）

要求多种元素：导航条，图形表格、文字、滚动信息等，有丰富的图形展现：支持面积图、横条图、圆环图、双Y轴图、漏斗图、金字塔图、雷达图、油量表、

20

散点图、泡泡图、联合图、容器图、温度计图、进度条、红绿灯、瀑布图等多种图形方式。

支持地图分析：将带有“地域性”或者“区域性”特征的信息通过地图进行展现。

并且提供可视化工具，通过鼠标拖拽即可针对不同角色进行个性化定制仪表盘的形式。

联动分析：具备联动分析、关联跳转、明细分析等能力。可以查看指标的鞥详细报表与关联信息。

支持仪表盘的元素（图形、表格、文字）向下钻取，可以从仪表盘中钻取到任何一张报表，并且在当前仪表盘中展开。

支持将仪表盘直接生成为EXCEL、WORD、PDF、HTML等文件，方便有权用户进行离线数据分析。

 报表补录平台



在实际的数据源系统中，可能存在部分报表需要，但无法采集到的数据、信息，要求数据中心平台具有数据补充采集功能； 

补充采集的数据，可以通过手工单条录入，也可以通过一定的数据格式，例如：Excel，批量导入数据中心； 

数据补录受操作权限和数据权限的控制，如：罗江支行的操作员不能录入成都支行的数据； 

补充采集的数据，必须经过审核流程，确认后才能生效。

 元数据管理

21

建立有效的元数据管理平台，保证系统与业务的运作保持同步并且根据市场和业务需求的变化随时作出调整，一旦业务需求发生改变，用户可以通过对元数据的维护使系统的运行作出快速的响应。  数据质量管理

建立有效的、可视化的数据质量管理平台，能够通过建立检验规则，对源数据质量进行持续监测，并自动生成数据质量管理报告；能够实现可视化的数据追溯展示，清晰展示数据指标与源数据之间的逻辑关系。 

移动BI

为了使我行各级领导随时随地掌握企业的运营状态，提升业务效率，对市场做出快速、准确的反应迁引出了移动BI的需求；移动BI不仅是在BI系统上添加一种终端，而应包含以下要求（但不限于）：

1、 展示的内容范围包括领导驾驶舱、决策支持辅助分析报表； 2、 在IOS及Android平台上通过Apps实现

3、 界面直观性：要根据移动终端和应用面向的用户进行优化；

4、 易操作性：尽量减少输入的复杂操作，尽量选用点击、下拉等操作来满足业务需求； 5、 易安装性；

6、 安全性：移动终端上的数据是我行的机密，因此移动BI应具备高安全性要求。 7、 在平台技术上开发不少于10份KPI报表

22

4.2技术要求

4.2.1系统性能要求

 满足7*24小时处理业务。

 报表平台访问简单报表响应时间在3秒以内；复杂报表不超过15秒；能同时支持

多个并发业务，至少同时满足100个并发访问。

 在现有的数据量下（核心数据库250G左右，一般工作日交易量不超过5万笔，

结息日交易量不超过150万笔）要求一般工作日批处理时间不会超过180分钟，结息日、月末、年末等特殊工作不超过300分钟。

4.2.2系统架构要求

项目实施采用“架构建设一步到位，应用系统分步实施；逐步验证、迭发、螺旋上升”的方式，按照“整体规划，分步实施”的原则进行，在充分考虑商业银行系统现状及系统复杂性的基础上，通过分阶段实施逐步完成行内系统整合工作。

4.2.3环境要求

要求应用发布、ETL工具、OLAP在线数据分析工具、前端展现工具必须基于第三方商用软件进行开发，不能使用自行开发的工具软件。

硬件不在本次招标范围内，但是标书要求明确列出支持系统正常运行及全部功能的第三方软件及硬件设备配置，系统架构应能支持水平与垂直扩容。 名称 操作系统 型号 支持：AIX、HP_UX、LINUX、Windows等主流操作系统 23

数据仓库 应用发布服务器 IBM InfoSphere Warehouse Base Edition(IBM 数据仓库) 支持：Weblogic、Websphere等主流产品。（我行已有上述软件） 硬件要求 系统运行的硬件环境须满足软件性能的要求（要求明确列出建议硬件配置，但硬件不在本次招标内容中） 测试环境 ETL工具 前端展示工具 其他未指定软件 尽量保证与正式投产的运行环境一致 DADASTAGE 8.5 Cognos 10 应标方应把支持平台正常运行的全部软件、版本都予以列出，并都包含在本次招标价格中。 4.2.4平台安全性

平台应能够实施数据和系统的安全管理，包括但不限于： 

做到不同的功能需要有不同层次的安全接入，即不同级别、只能进行各自权限范围内的操作；    

确保平台内部网络不受到外部恶意攻击； 确保数据在通讯的各个环节中的安全性与保密性； 确保数据安全、用户安全、网络安全等； 确保数据安全修改等。

4.3与其他系统接口的要求

数据中心应用平台需要与行内所有系统互联。

24

4.4系统建设要求

   

充分考虑商业银行数据标准的落地；

充分考虑银监会《银行监管统计数据质量管理良好标准》的相关要求； 充分考虑指标库的落地； WEB系统以B/S模式实现。

系统要求采用符合J2EE标准的三层体系结构以及B/S应用模式，程序设计采用JAVA EJB技术，对系统的业务用户采用浏览器接入方式（要求客户端零配置，系统更新升级时不要求客户端下载任何程序），对系统的管理用户及设计用户可采用B/S模式或C/S模式。

 系统异常情况的处理

系统必须有能力处理各种异常情况，这些异常是由于输入错误、无效口令或识别控制失效、软硬件和通信系统失灵而造成。  故障恢复

必须考虑必要的措施来挽救故障发生带来的影响。要求支持当日错误重跑机制。  数据的分级存储及管理

对数据按照使用频度、用途的不同制定分级标准，按照不同的级别进行不同的存储粒度的设计。

 定制数据的维度分析及展现功能

提供设计分析的手段，便于商业银行设计人员在此基础上对分析应用进行扩展。客户端在实现分析功能时只操作后端主机的数据，不对本地数据进行处理。  对外数据接口的提供

系统能够提供对外数据接口，通过配置可以灵活实现数据落地的方式，例如文本等。对于现有系统的数据接口，要求从原来直接访问业务系统迁移至数据中心提供数据

25

源。

4.4.1架构建设要求

结合本行的实际情况，根据IT系统建设的现状，采用成熟的系统平台和技术，架构合理，接入分布，处理集中，业务管理分散。

系统各个功能采用模块化集成，实现新的业务模块能够增加新的系统功能，实现系统各功能相互之间的有效集成。

4.4.2安全保障要求

提供系统全方位的安全保障，支持网络、硬件、软件和数据全方面的安全措施。从网络接入、数据传输、系统管理、业务权限控制等多个方面采取措施，充分保证系统安全性。实现方便可视化的系统运行实时监控，及时了解系统运行情况，准确定位故障点。

4.4.3优化完善要求

系统提供其内部使用的模型原理、公式、数据来源及加工过程，避免系统黑箱效应，实现本行管理人员对自行开发或有疑问的输出结果进行合理性检查，避免系统风险。

招标人根据行业管理和业务发展的需要，自行进行功能的升级、完善、修改和增加，实现本行应用此套系统适应不断变化的经营环境和监管要求。

4.4.4二次开发要求

应标人中标后，需提供全部系统源代码，并进行技术培训。

26

4.5项目开发方式

本次项目采用的方式为招标人与投标人共同合作实施，版权归招标人所有。 双方共同设立项目开发小组，项目开发小组的开发地点在招标人所在地。

4.6数据标准要求

符合商业银行数据标准需求，实施的设计方案要符合商业银行数据标准，数据架构及数据模型应符合商业银行相关IT规范及数据标准的要求。

 实施方有类似的参照行业主流的数据标准定制数据模型的经验

 实施方的数据建模和ETL有一整套完整的工具和模版来保证数据的标准性

 实施方的数据仓库定制的模型能够随着我行数据标准的演进而改变，并做到对系统的

影响最小

4.7安全性要求

数据库安全：支持数据库级备份和恢复，使得在异常情况发生时，系统可以得以快速恢复，避免数据的丢失或将其影响降到最低限度，对数据丢失可以快速追溯和查询。同样，要保证存储过程中数据不被非法访问和篡改。

4.8培训需求

软件供应商负责对商业银行技术人员、业务人员进行高质量的培训。培训的目的及主要内容有：对软件技术实现细节以及维护、操作方面进行培训，提交相应培训文档资料，使行内技术人员对软件有一个全面的了解，掌握数据中心应用平台日常维护、处理能力。

27

4.9共组团队要求

商业银行数据中心应用平台项目实施团队由商业银行、软件供应商共同组成项目实施团队，项目工作以商业银行项目团队为主导，软件供应商配合的方式开展,统一协调和管理项目的实施。

当项目现场工作都已完成，系统正式上线，并达到稳定运行要求时，项目验收工作由软件供应商发起。具体步骤如下：

1) 软件供应商项目经理把项目现场工作报告和相关资料提交项目验收小组，如果验收小组通过了项目组的工作报告，那么项目组可以启动现场验收工作。

2) 软件供应商项目经理向商业银行负责人提交项目各阶段文档、系统维护及使用手册等。

3) 商业银行负责人收到相关资料后组织内部审核，若认为所接收文档没有问题，则给予通过，并填写验收报告。若认为所接收文档存在问题，则告知软件供应商项目经理相关改进意见，软件供应商对相关工作进行进一步完善后再次提交申请。

4) 文档资料验收通过后，软件供应商向商业银行移交现场维护工作和设备。移交过程中，软件供应商工作人员负责指导接手相关工作的人员参照相关手册自行开展工作。

5) 移交工作完成后，商业银行负责人为软件供应商签字确认项目正式验收。 6) 项目验收过程是最重要的过程之一，软件供应商须按照公司质量管理部门所确定的严格而完整的步骤进行相关工作。

5. 项目实施内容

28

5.1项目启动

软件供应商进场后与商业银行以及相关人员共同召开项目启动会议，明确工作目标，确定项目工作组人员组织架构，制定项目整体实施计划。 5.2产品差异分析

商业银行及软件供应商共同完成商业银行需求与软件产品的差异分析，软件供应商负责软件产品的现场安装、产品培训以及差异分析的相关支持工作，并协助商业银行完成用户验收测试方案。 5.3项目建设策略

需求调研、规划、建模阶段

 以当前的数据源系统和报表集市为主要调研对象，结合商业银行数据标准化工作成

果，详细分析加载到数据中心平台数据源信息、对数据的加工处理、数据中心平台之上实现的应用功能

 根据需求调研结果，给出数据中心的架构设计。

 完成数据源分析，根据商业银行数据标准化成果与公司积累，完成商业银行数据仓

库建模工作。

 根据商业银行IT与业务现状及战略规划，针对数据仓库系统及基于该平台的业务应

用的长期建设给出详细规划。

 此阶段完成，应标方应编制与提交《模型设计说明书》，《数据ER图》，《 建库参考

代码》并通过评审后才能进入实施阶段。

项目实施阶段（在需求调研与规划阶段评审结束后进入该阶段 数据中心与报表平台都应该支持多法人实体。

29

 数据中心应用平台建设

1. 数据仓库及ODS，数据集市搭建。 2. 元数据管理平台 3. 数据质量管理平台 4. 数据统一调度平台  综合报表平台建立

1. 搭建统一数据架构的报表平台，实现T+1报表的展现

2. 由于新核心系统正在建设过程中，因此综合报表系统部分可以先完成需要迁

移的报表的设计及开发

3. 逐步完成1104报表、人行大集中报表、人行利率报表、人行金融稳定报表、

人行理财产品统计报表、人行反洗钱报表、人行支付报表、国际收支申报报表、其他监管类报表，并且根据自身业务积累与行内需求，制作自定义报表200张左右。

4. 针对需要迁移的报表对源系统进行整合

5. 按主题完成面对报表应用的集市区数据的分析与加工

6. 项目建设及质保期内，由于上级监管部门标准、制度变化造成的新增报表需

求

 统一数据展现门户

1. 综合报表展现都按照统一展现规范集成到门户中 2. 实现统一登录、统一认证、统一权限管理

3. 实现页面个性化定制，不同角色的用户可以自行根据自己的喜好、习惯及关注

的内容定制不同的展现页面。

30

 根据商业银行数据标准化及高管驾驶舱的成果，完成高管指标落地及展示，要

求实现移动BI。

 根据银监会《银行监管统计数据质量管理良好标准》要求，辅助商业银行完成

数据良好标准的检查工作

5.4软件产品客户化设计及开发

此阶段是软件供应商项目工作的主体，软件供应商根据商业银行完成的差异分析成果，制定软件产品在商业银行的客户化技术方案，制定数据中心平台相关基础设施的设计及部署方案（主机、网络、操作系统、中间件、数据库等），制定数据中心平台与周边系统间接口及集成技术方案，与个应用系统厂商共同讨论并制定数据迁移技术方案及数据切换方案，完成软件产品客户化配置及开发，编制系统单元测试方案并执行单元测试，编制系统集成测试方案并执行集成测试。

在此阶段，软件供应商需要编制并提交《功能设计说明书-软件产品客户化技术方案》、《基础设施设计及部署方案》、《详细设计说明书》、《数据迁移及数据切换说明书》、《系统单元测试计划》、《系统单元测试方案》、《系统集成测试计划》、《系统集成测试案例》、《系统部署计划》等。 5.5用户验收测试

按照用户验收测试计划及案例的要求，搭建用户验收测试环境，协助商业银行执行用户验收测试，支持测试执行以及完成测试问题修改等工作。此外软件供应商需要搭建系统数据迁移测试环境，需要提供相应的执行数据切换测试，编制并提交《系统集成测试报告》、《系统技术测试计划》、《系统运维计划》等交付文档。

31

5.6用户培训

编制数据中心应用平台《用户操作手册》，编制用户培训教材，进行用户培训工作。 5.7上线运行

软件供应商需要制定详细的系统上线方案、系统上线应急预案（业务及技术），搭建生产环境并完成系统生产软件版本部署，完成生产数据的迁移及系统上线，此阶段需编制并提交《系统上线计划及方案》、《系统上线应急预案》、《系统运维手册》等。 5.8 最终验收

平台上线后稳定运行6个月（必须包含一次年结过程），软件供应商应提请商业银行进行项目终验，经商业银行确认系统已经稳定运行满6个月（必须包含一次年结过程），则应视为验收通过，由商业银行在出具的《项目总结报告》上签名确认。

6. 实施管理要求

6.1. 项目管理要求

商业银行数据中心应用平台项目实施团队由商业银行、软件供应商共同组成项目实施团队，项目工作以商业银行项目团队为主导，软件供应商配合的方式开展,统一协调和管理项目的实施。

6.2. 实施要求

在项目实施期间，数据中心应用平台厂商实施团队的项目开发人员、项目经理、应用架构师、系统设计师及专家等成员须以全天驻场方式提供开发实施服务，数据中心应用平台厂商须保证首席架构师及专家等关键实施人员的时间投入，并承诺不发生重大变更。

32

数据中心应用平台厂商实施团队应由一流开发能力的专业人士或专家组成，要求团队成员深刻了解国际、国内金融行业的发展状况和发展趋势，有国内金融机构业务系统开发、建设、实施经验，能够有效地将国际、国内相关领域的先进经验相结合，根据商业银行特点和业务现状，提供具有前瞻性、可实施的项目成果，推进业务发展。

6.3. 后续服务支持

软件供应商必须提供系统上线后12个月内的免费后续支持服务，保证系统的稳定运行，并满足因上级监管部门要求的标准与制度变化造成的新增报表需求，后续支持服务的方式包括但不限于：热线电话、电子邮件、现场技术支持、软件修补包等。

软件供应商提供免费服务期后有偿技术服务方案。包括但不限于：服务方式、服务价格和服务响应速度。

7. 项目交付成果

分类 生命周期/过程域 文档 需求差异分析说明书 分析 用户验收测试计划 概要设计说明书 数据模型ER图 模型设计说明书 设计 建库代码 功能设计说明书-软件产品客户化技术方案 基础设施设计及部署方案 33

详细设计说明书 系统单元测试计划 系统单元测试方案 ETL规则说明书 需求与系统功能跟踪分析报告 系统集成测试计划 系统集成测试案例 开发 系统部署计划 用户验收测试案例 系统集成测试报告 系统压力测试报告 用户验收测试报告 测试 用户验收测试总结分析 系统技术测试计划 系统技术测试报告 系统运维计划 用户操作手册 培训 系统培训计划 系统培训课件 系统运维手册 上线运行 系统上线运行报告 34

系统上线计划及方案 系统上线应急预案 推广总结报告 最终验收 项目计划管理 项目总结报告 项目计划书 项目周报 项目监督与控制 项目阶段评审报告 项目风险跟踪表 度量与分析 项目管需求跟踪矩阵 理内容 需求管理 需求变更单 供应商协议管理 项目交付审批清单 项目质量保证月报 过程与产品质量保证 项目交付评审记录表 项目问题跟踪表 项目度量与分析月报

8. 项目验收

8.1. 项目验收的组织机构

商业银行负责组织验收工作。软件供应商应组建由有关技术人员构成的测试小组，并在验收小组指导监督下开展工作。验收小组提出的验收测试要求及质量保证要求，软件供应商应积极响应，并会同商业银行共同制定合适的验收和质量保证方案。

35

8.2. 初步验收

1） 软件供应商应按需求书完成相关工作并提交项目成果。对于不满足需求书要求的软件供应商交付物，软件供应商应及时予以整改、修订、完善以满足要求；

2） 通过相关的功能测试并达到相关性能要求，上线试运行三个月，系统运行稳定，无宕机，各功能模块能支撑业务正常运作。运行期间若出现功能故障、系统不稳定现象，解决故障时间不计入试运行时间，上线试运行时间向后顺延。

3） 阶段成果交付后，商业银行将依据需求书要求，组织进行阶段成果的审查、确认工作，商业银行签字确认初步验收完成。

8.3. 质保期

验收完成后第二日起12个月内，即为项目的质保期，软件供应商在期内须提供质保服务。支持和服务包括但不限于：

系统技术支持：对商业银行提出的与现有方案及系统有关问题及时进行答疑与解释。 定期回访与评估，前2个月每1个月进行一次，之后每2个月进行一次。每次回访时双方提前5个工作日共同确认时间及参加人员安排，对商业银行数据中心应用平台应用状况进行评估，并提交回访评估报告，报告内容包括但不限于：系统应用情况、问题分析、改进建议等，协助商业银行完善系统应用。对系统运作和故障情况的支持、服务要求：

重大故障：由于系统原因造成应用平台瘫痪或由于应用软件原因造成对大量用户的服务无法正常进行；30分钟内响应，4小时之内恢复正常运行。如果软件供应商不能在4小时内远程解决，软件供应商必须在收到商业银行到现场服务要求后24个小时内提供现场支持服务。

36

严重故障：由于系统原因导致应用平台部分功能丧失或因应用软件问题影响部分用户的服务无法正常进行。或者该故障对应用平台存在重大隐患；1小时内响应，1天之内恢复正常运行。如果软件供应商不能在1天内远程解决，软件供应商必须在收到商业银行到现场服务要求后2天内提供现场支持服务。

轻微故障：应用平台故障基本不影响业务；1天之内相应，5天之内恢复正常运行。如果软件供应商不能在5天内远程解决，软件供应商必须在收到商业银行到现场服务要求后3天内提供现场支持服务。

8.4. 最终验收

根据质保期要求完成质保期工作内容。

按照商业银行科技部门要求，编制相关归档文件，完成项目归档工作，得到商业银行科技部门的签字确认。

完成以上工作、提交《项目总结报告》并通过商业银行签字确认。

37