数据集中工程一期项目可行性研究报告

中国WK银行

数据集中工程一期项目可行性研究报告

2002年7月

目录

1 引言 ............................................................ 1

1.1 1.2

编写目的 ................................................. 1 背景和目标 ............................................... 1

项目背景 .......................................... 1 项目目标 .......................................... 4 项目名称 .......................................... 5 项目范围 .......................................... 5 项目时间 .......................................... 5

1.2.1 1.2.2 1.2.3 1.2.4 1.2.5 1.3

条件和约束 ............................................... 6

实施本项目具备的条件 .............................. 6 可利用的资源 ...................................... 7 所受到的限制和约束 ................................ 8

1.3.1 1.3.2 1.3.3 1.4

参考资料 ................................................ 10

2 系统需求及现状 ................................................. 11

2.1

系统需求概述 ............................................ 11

系统的账务体系 ................................... 11 系统处理的业务范围 ............................... 16 系统的服务功能 ................................... 21 系统的风险控制体系 ............................... 25

2.1.1 2.1.2 2.1.3 2.1.4 2.2

对现有系统的分析 ........................................ 28

一级分行数据集中情况 ............................. 28 一级分行数据集中后存在的主要问题 ................. 29 CCBS系统简述..................................... 30

2.2.1 2.2.2 2.2.3

3 总体技术方案 ................................................... 33

3.1

总体技术方案描述 ........................................ 33

数据集中模型 ..................................... 33 数据集中体系架构 ................................. 36 数据中心基础设施 ................................. 43

3.1.1 3.1.2 3.1.3

3.1.4 3.1.5 3.1.6 3.2 3.3

主机系统架构 ..................................... 48 应用架构 ......................................... 50 实施方法 ......................................... 53

和现有系统的比较 ........................................ 54 和相关系统的关系 ........................................ 57

数据中心与相关系统的关系 ......................... 57 一级分行交易平台与外系统的关系 ................... 60

3.3.1 3.3.2 3.4 3.5

采用该技术方案可能带来的影响 ............................ 65 实施风险 ................................................ 68

4 技术可行性评价 ................................................. 71 5 经济可行性 ..................................................... 75

5.1 5.2

成本投入分析 ............................................ 75 效益分析 ................................................ 76

成本的降低 ....................................... 76 经营损失的降低 ................................... 77 经营收益的增加 ................................... 77 无形资产的增值 ................................... 78

5.2.1 5.2.2 5.2.3 5.2.4

6 社会可行性 ..................................................... 78 7 可选技术方案 ................................................... 79 8 结论意见 ....................................................... 80

1 引言

1.1 编写目的

本可行性研究报告阐述了数据集中工程一期项目的背景、目标，以及实施的必要性、紧迫性，对本项目实施的主要内容、总体技术方案进行了概要描述，对本项目所需的资源、前提条件以及实施风险进行了分析，同时对本项目的技术、经济、社会可行性进行了充分的论证。

编写本可行性研究报告的目的是为我行业务、技术专家论证本项目的实施范围、目标、总体实施草案的可行性，以及有关部门审批该项目时提供相关材料。

1.2 背景和目标

1.2.1 项目背景

1997年6月总行计算机应用领导小组第一次全体会议决定开发全行新一代柜面业务系统。新一代柜面业务系统开发项目也是1998年9月制定的中国WK银行计算机应用总体设计方案中重要一步。2000年12月柜面业务系统ES9000（以下简称CCBS）系统在上海分行全面投产，2001年5月在深圳分行推广成功。

2000年8月第20次党委会议审议通过的《中国WK银行科技工作规划》，确定了科技工作发展目标和“六年三步走”的实施步骤：“第一步用一年半左右充分利用现有资源实现一级分行数据物理集

中，同步建立全行灾难备份中心，完成管理信息系统总体框架设计。第二步再用一年半左右在一级分行推广总行统一开发的柜面业务系统，建立基于企业网平台的管理信息总中心的雏形。第三步在接下来的三年或更多一些时间内实现总行数据集中。”

规划中明确了实施数据集中工作的指导原则：“总行统一开发、推广以客户为中心、集中帐务、统一核算、本外币一体化、综合柜员制的核心业务处理系统（柜面业务系统）是我行实施数据集中的关键任务。整个经营行为的规范化、标准化和相应管理体制的配套改革对在一级分行范围内推广柜面业务系统是至关重要的。总行要在柜面业务系统上海实施项目的基础上，统一组织柜面业务系统的开发、试点与推广。”

2001年3月第12次行长办公会议通过的《关于加快科技规划实施步伐的工作安排》，将数据集中的步骤由“六年三步走”调整为 “三年二步走”：“用三年左右时间完成全行的数据集中。首先在CCBS 2000年版本基础上，进行总行数据集中的试点工作，以积累经验。同时引进国际先进的软件技术，优化我行软件系统，使之更具有适应性和前瞻性。结合网络优化，建立两至三个总行数据处理中心，实现全行核心业务的集中处理。以数据处理中心为依托，建立全行管理信息系统，为分析、决策和控制风险提供及时、准确、全面的支持。为进一步将数据处理中心发展成为全行业务处理中心奠定坚实的基础”。根据上述决议，2001年4月，总行开始了对ALLTEL银行核心业务处理系统的评估工作。

2002年1月，总行对引进ALLTEL软件的先期工作进行了论证，在权衡各方面因素的情况下，决定停止ALLTEL软件的引进工作。

2002年3月总行组织进行“加快科技创新和产品开发”的专题调研工作，结合建行的实际情况，对包括数据集中在内的科技发展策略进行了研究和论证。调研报告认为“应继续坚持总行科技规划中关于全行数据集中的规划方向，同时鉴于形势的严峻性和时间的紧迫性，建议适度调整数据集中实施步骤，加快数据集中建设步伐”，建议“建立区域中心，分两个阶段完成全行数据集中工作”。5月行党委认可了调研报告，要求由信息技术部牵头，尽快启动“中国WK银行数据集中工程项目”。

目前国内大多数中小商业银行基本是全行数据集中模式，如招商银行、光大银行已实现全行核心业务集中于一个数据处理中心处理。四大国有商业银行目前均在进行数据集中的规划和实施。农业银行第一步是在2002年底全面完成全国36个省域数据中心的建设，全面推广“新一代”系统软件，第二步发展战略是到2005年全面建成全国数据中心，实现全国数据大集中。中国银行截止2001年9月30日，基本上实现了省分行的业务集中处理，全辖数据中心已收并到47个，国内处理中心最终将缩并成华北、华南、华东、西南、西北5个中心，现有的11个平台将集中到UNIX、ES9000两个平台上。工商银行业务集中处理工作走在了其他银行的前面，99年已完成了35个省级数据中心的建设，并启动了“9991”工程，开始区域中心的建设，目前北京中心已完成20个省级中心的迁移，预计今年年底完成全部工程。

基于没有数据集中就没有风险的集中控制，核心竞争力的形成就没有基础的认识，工商银行坚定不移地走数据集中的道路，虽然集中仍在实施过程中，但市场竞争方面的优势已经显现出来。“数据集中”已经成为中国银行业发展的大趋势。

随着加入WTO，我国金融业面临的竞争形势更加严峻。一级法人治理结构和我们面临的竞争形势要求建行进一步提高风险控制能力、客户服务水平、产品开发和市场响应速度，进一步提高盈利和降低成本，从而提高我行的核心竞争力，所有这些都需要改善目前的技术支撑环境。此时加快数据集中建设步伐，尽快启动“中国WK银行数据集中工程项目”，对建行的发展而言有着重要的战略意义。

1.2.2 项目目标

根据“加快科技创新和产品开发”专题调研的建议，我行数据集中工作的目标是：

1. 建立区域中心，区域中心的具体数目在实施过程中，根据数

据中心处理能力、管理可能性和法人治理结构的要求再最后确定。

2. 全行数据集中划分为两个阶段。第一阶段（至2003年底）

基于IBM大型主机先期建立上海、北京两个数据中心，在优化改造CCBS的基础上，力争完成三个至四个省、市分行的上挂工作，并实现全行的业务需求和技术规范统一，培养人才队伍、积累区域中心的运行管理经验；第二阶段

（2004-2006）确定并启动其它数据中心建设，并同步进行灾备中心建设，根据各一级分行对全行数据集中需求的迫切性以及一级分行数据中心系统的运行状况，逐步进行一级分行上收，最终完成全行数据集中。

根据上述目标，本项目即中国WK银行数据集中工程一期项目，

将完成全行数据集中第一阶段的工作任务。

1.2.3 项目名称

本可行性研究报告所拟立项目名称是：中国WK银行数据集中工程一期项目。

1.2.4 项目范围

拟立项项目的范围包括：至2003年底，

1. 基于IBM大型主机先期建立上海、北京两个数据中心； 2. 在优化改造CCBS的基础上，完成数据中心核心业务处理系统的开发；

3. 在上述两项任务的基础上，力争完成三个至四个省、市分行的上挂工作，并实现统一的总行业务需求和技术规范，培养人才队伍、积累区域中心的运行管理经验。

1.2.5 项目时间

根据对项目工作量的估算，本项目预计自立项之日起17个月内完成。依照目前计划，预计至2003年底完成项目范围内所规定的任

务。

1.3 条件和约束

1.3.1 实施本项目具备的条件

第一, 总行各级领导对科技工作的高度重视。总行新一届领导集体，本着实事求是的精神，对科技工作现状进行了深入了解，科学论证了今后建行科技发展的策略和方向，对包括数据集中在内的战略性问题有了准确的判断。

第二, 明确了当前形式下数据集中的实施步骤。在为期五个月的“加快科技创新和产品开发”专题调研过程中，行内外专家就数据集中的目标、策略和实施步骤进行了充分地讨论，并对今后如何实施数据集中工作形成了统一的思想认识。

第三, CCBS成为我行核心业务处理系统的成功范例。1997年开始开发的CCBS柜面业务系统已在上海、深圳投产并稳定运行一年多时间。该系统已通过行内验收和人民银行的签定，行内验收结论是：中国WK银行柜面业务系统设计思想先进，结构合理，扩展灵活，业务适应性强，系统安全控管措施较严密。业务处理模式符合商业银行的发展方向，项目管理工作有效，功能范围和质量达到了项目任务要求，具有较大推广价值。人民银行鉴定意见是：中国WK银行柜面业务系统设计思想先进，结构合理，扩展灵活，业务适应性强，系统安全控管措施严密。CCBMAIN业务处理平台属国际首创，系统技术应用反映了近年来国际同类系统的最新进展，达到国际先进水平。

第四, 一级分行数据的数据集中为进行进一步实施本项目奠定了良好的基础。截止2002年6月21日，我行38家一级分行以不同方式实现了辖内数据的集中处理，大部分一级分行实现了核心业务处理系统版本的统一和帐务数据的逻辑集中。集中后，一级分行明显感到风险控制手段加强、管理信息准确、经营数据及时、新品开发推广速度加快。一级分行数据集中工作的完成，提高了各行的经营管理水准和市场竞争能力，降低了整体运行成本。

第五, 一级分行的数据集中和CCBS项目的实施工作，丰富了我行对数据集中的认识和经验，逐步形成了一支专业的业务和技术队伍。

第六, 数据集中市场的成熟，提供了外部支持力量。工行、中行、农行以及其他国内外同业的数据集中项目，为我们提供了可供参考案例和模式；国内系统集成厂商广泛参与了中国银行业数据集中的过程，积累了丰富的实践经验和成熟的外部资源；WK银行的数据集中工作可以从外部获得支持。

1.3.2 可利用的资源

1. 一级分行数据集中和CCBS项目试点的经验和成果

在一级分行数据集中和CCBS项目试点过程中，各行对项目开发、组织、系统切换，以及数据集中使用的技术、业务积累了丰富的经验，并形成了诸多可供利用的成果，如核心业务系统、前端系统、前置系统、中间业务平台等。

2. 行内形成了具有一级分行数据集中经验的技术和业务队伍

通过近年来一级分行数据集中和CCBS项目的开发工作，形成了一支有战斗力的集体，包括熟悉系统开发的业务骨干，熟悉项目开发的项目管理专家，以及在IBM大型主机、Unix平台、AS/400平台和Unisys A机平台上积累了丰富经验资深技术专家。 3. 有可利用的成熟的数据集中关键技术

数据集中的关键技术（如SYSPLEX技术、大前置技术）已经成熟，在国内外拥有大量成功的案例。国内计算机厂商逐渐掌握了数据集中实施过程的关键技术。 4. 网络和设备

建行全国骨干网改造项目的完成为全行数据集中创造了良好的网络条件，各分行现有设备可在数据集中项目中得到充分利用。

1.3.3 所受到的限制和约束

1. 时间的限制和压力

由于市场环境的压力，总行党委要求在2003年底完成两个数据中心的建设、数据集中版本的改造、以及四个试点行的推广。在项目实施过程中，时间成为首要约束条件。 2. 业务统一的限制

业务统一是全行数据集中的前提，没有统一的产品及其流程，没有适应全行数据集中需要的核算制度、管理规定和业务标准，就没有适应全行数据集中的统一的软件。没有统一的软件，数据集中就失去

了基础。目前我行各部门已制定了相关业务的制度、规定和标准，但对于全行数据集中系统，还缺乏完整统一的业务需求标准，缺乏对数据集中业务需求集中、统一的有效管理。如何有效地解决与数据集中配套的业务管理问题将成为决定数据集中成效的关键因素。 3. 业务管理模式、组织模式与数据集中的一致性限制

数据集中不是简单的技术实现，业务经营模式、业务管理模式、以及组织模式都需进行相应的调整。如果这些工作不积极推进并调整到位，数据集中将只是技术平台的统一、交易数据的统一存放，数据集中将无法充分发挥对经营管理的支持作用。 4. 业务发展的压力

数据集中需要大量的人力、财力投入。既要保证加快数据集中实施进度，又要保证新产品的开发和市场响应速度，在人力资源、财务经费有限的情况下，将存在一定的困难。因此在数据集中过程平衡好数据集中工作和新产品开发是非常重要的。 5. 对外部资源的依赖性

按照本项目的总体技术方案，我行在短期内不仅将在系统硬件、系统软件等方面依赖于IBM的技术服务，而且在应用软件的设计、开发也要与IBM技术人员进行合作。因此，IBM的人员变动以及与IBM的合作关系可能会影响我行项目的进展。对于分布广泛的前端系统依赖单一合作厂商，也会存在厂商全方位支持能力和服务质量保障等问题。

6. 数据中心的系统运行管理能力限制

按照本项目的总体技术方案，我行将基于IBM大型主机系统先期建立两个数据中心。我行目前只有北京、上海、深圳三个分行使用IBM大型主机系统，系统运行管理的人员数量不多，缺乏全国性数据中心的运行管理经验。能否在一年时间内迅速培养一支能支持全国性数据中心运行的系统运行管理队伍，是决定项目实施成败与否、保证数据集中安全运行的关键。 7. 财务约束性

全行数据集中需要大量的资金投入，对财务构成极大的压力。在项目实施过程中，应充分考虑原有软硬件设备的保护问题，平衡好技术先进性与财务约束之间的关系。

1.4 参考资料

1. 《中国WK银行信息开发项目管理办法（试行）》

2. 《中国WK银行应用开发项目可行性研究实施细则（试行）》 3. “加快科技创新和产品开发调研组”专题调研报告 4. “中国WK银行柜面业务系统ES9000项目”验收报告

5.

“中国WK银行柜面业务系统ES9000项目”人民银行鉴定报告

6.

柜面业务系统ES9000项目相关文档

2 系统需求及现状

2.1 系统需求概述

本项目将以客户关系为导向、以账务为中心、基于本外币一体化系统架构实施开发，实现全行数据共享和统一的账务体系、业务处理、服务功能以及风险控制体系。

2.1.1 系统的账务体系

2.1.1.1 会计核算体制

依据《中国WK银行会计核算制度》（本外币），依托计算机网络系统，结合各一、二级分行的管理体制及考核要求采用多级核算制。

营业机构作为系统的营业前端，主要工作是将经济事项录入计算机。支行（或二级分行）作为核算主体，是具有完整账务体系的基本核算单位。一个核算主体既可定义为多个营业机构组成，也可定义为一个营业机构。

多级核算体制示意图 多级核算体制示意图总行 总行 一级分行 一级分行 一级分行 一级分行 一级分行 一级分行 一级分行 一级分行 二级分行 二级分行 二级分行 二级分行 支行 支行 支行 支行 营业网点 营业网点 营业网点 营业网点 营业网点 营业网点 营业网点 营业网点

2.1.1.2 会计账务组织

 按本外币统一会计核算制度，将本外币公司业务、本外币储蓄业务、银行卡业务在系统中整合，实现本外币一体化的集中会计核算。

 可按一级分行/二级分行甚至到营业机构为单位设置总账，以营业机构为单位设置明细账、登记簿，以柜员为单位设置库存现金尾箱登记簿、重要空白凭证登记簿。

 账务数据集中存放，核算处理集中。会计核算账务数据集中存放于数据中心主机，各营业机构负责向主机传输、提交、采集账务

数据，数据中心负责对核算账务数据集中存放和加工处理，并向各营业机构反馈相关会计交易，同时为满足各行内部管理和当地人民银行、地方财政、审计、税务等部门对我行的各类监管、检查、审计需要数据中心按规范统一的要求在指定时点向各管理层反馈会计信息。 2.1.1.3 总账

总账是总括说明各科目的增减变化情况。本系统使用本外币统一会计核算制度进行核算，科目采用三级科目制，一级科目采用4位数字编码，二级科目采用2位数字编码，三级科目采用2位编码，一、二、三级科目代号合并长度为8位。

本系统按一级分行/二级分行甚至到营业机构为单位设置总账。对于按一级分行设立总账的分行，一级分行所辖的二级分行以及二级分行所辖的支行或营业机构，可按机构级别分别生成二级分行及支行或营业机构的科目汇总数据。

本系统按币种设置各级科目总账。 2.1.1.4 明细账

明细账是指按照会计科目所规定的核算内容，在各科目的统驭下进行详细分类核算的账户。根据明细账核算的范围和内容，可分为两大类即客户明细账和内部明细账。  客户账号

客户账号是根据账户管理规定，客户在我行开立的存款、贷款会计账户的编号。为保持客户账号稳定性，将银行用于自身核算而与客户无直接关联的科目号从账号中剔除，避免银行自身科目号变动客户账号随之变更，并在全行范围内保持唯一。

由于各行、各业务的客户账号编排规则不同，为减少对外界的影响，保持对客户账号编排规则的延续性，因此系统在考虑客户账号的编排规则时采用客户系统账号编排规则与对外账号编排规则的对应，即系统账号为统一的28位编排，对外账号仍以原编排保持。

客户系统账号编排规则 客户系统账号编排规则 CC CC 币币别 别 DD DD 帐帐号号类类别 别 E E 钞钞汇汇类类别 别 FFFFF FFFFF 自自定定义义域 域 GGGGGGG H GGGGGGG H 顺顺序序号 号 校校验验位 位 AAAAAAAAAA B AAAAAAAAAA B 机机构构号 号 帐帐本本别 别  内部账号

内部账号是银行以内部核算为目的而开设的会计账户的编号；考虑到会计人员对内部账户的核算需要和对账户类别的辨认与管理，内部账号仍包含目前使用的科目号，但科目号调整时（核算内容未变），需将原账号中的科目号域调整至新科目号，不影响已存在内部账号的使用。

内部账号编排规则 内部账号编排规则 CC CC 币币别 别 DD DD 帐帐号号类类别 别 KKKKKKKK KKKKKKKK 自自定定义义域 域 GGGGGG GGGGGG 顺顺序序号 号 AAAAAAAAAA B AAAAAAAAAA B 机机构构号 号 帐帐本本别 别 2.1.1.5 流水账

流水账是记录当日所发生的每一笔业务的详细信息，按交易发生的时间顺序排列，系统对每一笔业务自动编号，存放于主机。它包括以交易驱动方式产生的流水和以会计分录方式产生的流水。

交易驱动方式产生的流水号是以一笔交易所产生的一套或多套会计分录为一个编号。

会计分录方式产生的流水号是一笔交易所产生的每一条会计分录为一个编号。

2.1.1.6 账务体系的内部关系

在系统中，交易信息根据系统会计分录表产生交易流水、平行登记明细账和当日科目发生，根据程序登记登记簿；日终批处理根据交易流水登记总账，进行总账、明细账的自身平衡，以及总账与明细账的总分核对，并进行总账与当日科目发生核对。

账务体系各部分的内部关系如下图所示：

交易信息交易信息会计分会计分录表录表交易流水交易流水明细账明细账当日科目发生当日科目发生账务体系内部关系账务体系内部关系总账总账核核对对登记簿登记簿 2.1.2 系统处理的业务范围

根据我行目前开办的业务，系统处理的业务范围主要包括：本外币存款业务、贷款业务、银行卡业务、金融机构往来、现金业务、票据清算、单证管理；本币支付结算业务、证券业务以及外汇买卖业务、中间业务和电子银行业务等。 2.1.2.1 存款业务

存款业务包括本外币的单位存款业务和个人储蓄业务。 单位存款业务：包括本外币单位活期存款、协定存款、保证金存款、单位定期存款、单位通知存款、财政性存款以及外汇双重货币存款等。

个人储蓄存款业务：包括本外币个人活期存款、个人定期存款、个人通知存款等，其中个人定期存款含各储种的定期存款。

系统处理的范围包括上述存款的开户、存入、支取、销户以及结计利息、存款过户、存款归户等账务性业务，以及账户冻结、解冻、

挂失、解挂、换折、存款种类的设置维护、查询等非账务性业务。 2.1.2.2 贷款业务

贷款业务包括本外币单位贷款业务和人民币个人贷款业务。 单位贷款业务：包括人民币单位贷款、银团贷款、代理政府投资贷款境内外币贷款、境外借款转贷款等。

个人贷款业务：包括个人住房贷款、个人消费贷款、国家助学贷款等。

系统处理的范围包括上述贷款的贷款开户与发放,贷款收回、结清与担保(保函)解除,利息与手续费计算,贷款展期,垫付款/改贷,贷款批处理,认定不良贷款，转列呆滞、呆账,呆账核销,垫付款、呆滞、呆账收回,贷款业务别变更,错账更正，账务信息数据维护,数据查询,批处理报表。 2.1.2.3 银行卡业务

银行卡业务包括信用卡（准贷记卡）、储蓄卡、贷记卡、IC卡、国际借记卡等。

系统处理的范围包括上述卡种的开户、存取款、转账、消费、销户以及结计利息等帐务性业务，还包括冻结/解冻、注销、挂失/解挂、换卡、卡档维护、查询等非帐务性业务，同时提供各卡种的代扣付费功能和信用卡（准贷记卡）、贷记卡的透支、免息功能。 2.1.2.4 金融机构往来业务

金融机构往来业务范围包括分行级的系统内活期资金调拨、系统内定期资金调拨、向中央银行借款、同业拆借等业务及相关业务查询；支行级的向分行上存定期、借款、上缴经营调节基金等业务及相关业务查询。

系统处理的范围包括计划信息录入、记账、资金账户的利息计算、业务查询。 2.1.2.5 现金业务

现金业务包括人民币现金领缴、外币现金运送；柜面现金收付；现金清点；经费现金1等。

系统处理的范围包括机构现金调拨、柜员现金调拨、现金出纳机、大额现金预约、现金清点以及查询等。 2.1.2.6 票据清算业务

票据清算业务包括本外币的同城票据清算，人民币资金异地清算。其中同城票据清算方式由票据交换和大额实时、小额批量；异地清算方式由与总行清算系统的电子汇划业务和速汇通业务；与人行清算的天地对接业务。

系统处理的范围包括同城票据交换中的交换场次转换、收妥抵用票据登记，交换提入票据的批次入账、退票处理，交换资金清算；大额实时、小额批量的汇出和汇入；电子汇划、天地对接的单笔、批量汇出和汇入、查询查复、退汇等；速汇通业务支持现金、折、卡的单

1

经费现金需参见各分行的业务需求

笔、批量的汇出、汇入、查询查复、申请退汇、退汇解付以及查询打印等。

2.1.2.7 单证管理

系统中的单证管理包括单证类别维护、重要单据入库、重要单据调拨、凭证出售、重要单据作废、重要单据存量查询、重要单据状态查询、重要单据销毁和他行重要单据挂失登记等。 2.1.2.8 支付结算业务

支付结算业务包括银行汇票、商业汇票、银行本票、支票、信用卡和汇兑、托收承付、委托收款等结算方式进行货币给付及资金清算的业务。

系统处理的范围：支票付款；支票查询；银行汇票出票、银行汇票付款、银行汇票退款、银行汇票查询；银行承兑汇票：银行承兑汇票承兑、银行承兑汇票到期收款、银行承兑汇票付款、未用注销、银行承兑汇票查询；银行本票出票、银行本票付款、银行本票查询；汇兑汇出、汇兑汇出查询、汇兑汇入、汇兑汇入查询；：发出托收承付、发出托收查询、收到托收承付、收到托收查询、托收承付付款；发出委托收款、发出委收查询、收到委托收款、收到委收查询、委托收款付款；支付结算业务收费等。

信用卡的业务处理由银行卡业务中进行描述。 2.1.2.9 证券业务

债券业务包括记名债券和不记名债券、开放式基金、凭证式国债、记账式国债、银证转账、银证通等。

系统处理的业务范围包括记名、不记名债券的债券信息维护、发行、兑付、挂失/解挂、冻结/解冻、质押，其中凭证式国债还包括额度控制、柜台买卖。

开放式基金、记账式国债见证券登记系统业务需求。 银证转账、银证通的开户、转账、股票买卖等。 2.1.2.10 外汇买卖业务

外汇买卖业务包括结售汇业务、代客外汇买卖、经营性外汇买卖。 系统处理的业务范围柜台结售汇、结售汇平盘；外汇买卖，即期/远期委托外汇买卖，个人外汇买卖，外汇买卖平盘以及查询统计等。 2.1.2.11 中间业务

中间业务包括委托贷款、保证业务、代理中央财政授权支付业务、代收业务、代扣业务、代付业务、住宅商品维修基金、期货结算、社保卡业务、代理商业银行业务。

系统处理的业务范围委托贷款同贷款业务。 代理中央财政授权支付业务见重要客户系统需求。

代收业务有代收公用事业费、代收保险费、代收行政罚没款、代收税款等模式。

代扣业务主要根据委托单位递交的数据，由网点或核算中心进行批量扣款。

代付业务主要有批量代发工资款和代付保险费模式。 2.1.2.12 电子银行业务

电子银行业务包括CALL-CENTER业务、网上银行（包括B2B）、手机银行。上述需求参见各分行相关需求。

2.1.3 系统的服务功能

2.1.3.1 实现以“一级分行/二级分行”为单位的数据大集中

柜台通过终端方式将交易要素录入系统，主机根据上传的交易信息自动产生相应的会计账务流水。所有的业务数据和系统处理都集中在一级/二级分行，实现以“一级分行/二级分行”为单位的业务数据大集中。

2.1.3.2 实现“交易驱动为主，分录驱动为辅”的业务处理模式

会计凭证录入方式分为交易方式和会计分录录入方式。交易方式指系统将银行不同业务品种处理划分为若干个不同交易类型，每个交易类型分别对应不同的交易要素和会计分录。柜员受理的会计业务经审查无误，根据会计事项先确定交易类型，再根据计算机提示将交易要素（主要是会计凭证要素）健入计算机，会计分录及账务核算由计算机完成。业务品种及其交易类型发生变化时，修改其对应的会计分录即可。

会计分录录入方式是考虑业务发展和存在部分业务会计分录不确定因素时，系统提供的以授权约束为前提的单笔借、贷或单笔收、付的录入方式。

绝大部分的业务采用交易驱动方式，同时辅以分录驱动方式，实现以“交易驱动为主，分录驱动为辅”的业务处理模式，提高工作效率的效果。

2.1.3.3 实现资金清算处理自动化

数据集中区域内的机构之间资金清算由系统根据机构隶属关系自动清分，并进行相应的账务处理，使系统内资金往来类科目的的余额保持一致，既减少了人员对账的工作量，又有效地防范了资金风险。

通过总行清算系统的款项划转采用直联方式，即由营业机构发起交易，经一级分行/二级分行的核算中心联机编押后直接向清算系统发送；异地汇入资金则由核算中心（或各联行机构）接收，联机（或手工）核押后自动入账。

通过人行系统的款项划转，如天地对接、大额实时、小额批量等也采用直联方式处理。因此加快了资金的到账速度，形成了一条资金的快速通道。

2.1.3.4 实现贷款核算处理程序化

系统将贷款的贷前、贷中、贷后核算处理程序化。

贷前：根据信贷管理要求，在系统中建立“中心额度”控管。中

心额度分为贷款额度、外汇额度、贴现额度、信用担保额度、票据承兑额度、透支额度、银行卡授信额度等。依据各类分额度的风险程度,在实际使用各类分额度时,与抵押物、质押物和第三方保证人相关联,建立相应的担保物和保证人资料,使实际动用的额度有相应的担保物和保证人作保障。从而控制客户在建行的总负债,达到降低和控制风险的目的。

贷中：系统在贷款发放时自动与建立的额度进行比对，检查贷款发放是否超过额度、检查贷款的使用范围等。

贷后：系统对发放的贷款进行追踪，提前提示到期信息，到期时根据额度设定的条件自动进行还款处理；对不良贷款按规定进行一逾二呆以及五级分类的处理；对核销的呆账进行保留追溯权的处理；系统提供计提坏账准备金等。系统自动控制，降低业务风险，杜绝人为差错。

2.1.3.5 实现参数化设置，根据业务和管理需要灵活进行调整

系统采用通过交易方式进行参数设置，便于根据业务和管理需要灵活进行调整。

交易定义参数化，会计分录参数化等；科目属性参数化，存、贷款种类属性参数化；机构定义参数化；利率、汇率、税率、费率等参数化。因此系统通过调整参数来适应业务变化。 2.1.3.6 实现综合柜员制

建立在本外币会计核算基础上的业务整合系统，可实行综合柜员制。综合柜员制是指临柜业务人员在划分事权的前提下，独立完成多业务品种、多币别的金融业务交易，并独立承担相应经济责任的一种劳动组合形式。系统满足营业终端同时具备所有业务的交易录入功能，可处理本外币公司业务、本外币储蓄业务以及银行卡等不同业务，实行一机多能；柜员在授权约束下可办理多种业务，实行一人多能。在理论上，客户可在数据集中区域内的任何一营业机构办理存、贷、委托代理、转账、现金、查询等业务，为客户提供快捷、方便、优质全方位的服务环境。

2.1.3.7 实现“以客户关系为导向”的信息管理机制

以客户关系为导向，建立基本客户信息，同时把该客户下的所有账户直接和客户信息有机地联系，并提供基础数据，为进一步对客户进行全面、透彻的分析，进行差别化服务提供第一手资料。

数据集中区域内的客户信息全辖共享，实现集各类金融产品一体化的综合理财账户体系。 2.1.3.8 提供24小时营业功能

系统支持24小时的正常营业，并可按营业机构和分业务种类进行支持，如银行卡、个人外汇买卖业务等；也可拓展对公24小时的业务。

2.1.4 系统的风险控制体系

风险的防范及控制是系统的一项重要内容贯穿于每个业务的始终，它从业务操作权限、营业机构、操作员、业务处理过程、日结等方面，在时间、空间上形成系统的风险防范体系，充分发挥计算机的自动实时控制效能，加强风险控制，提高业务管理的控制能力。 2.1.4.1 业务操作权限管理

系统对科目使用的控管。根据核算办法及各行的管理需要，业务参数维护人员对不同层次的机构（如总行、一级分行、二级分行、支行、营业机构）可使用的会计科目加注标志，规范会计核算。

系统对营业机构经办业务的控管。系统将机构划分为：核算中心、国际业务部、龙卡中心、支行、营业机构，建立机构业务控管表，选择机构可经办的业务，明确机构的操作权限，防止不同类型机构的柜员对本机构非经办业务的介入。在机构升格时，可调整相应的机构权限。

系统对操作柜员的控管。系统将操作柜员划分为A级主管、B级主管、现金柜员和普通柜员四类，建立交易控管表，对每一个操作员根据业务操作的管理要求选择可执行的交易组，明确了其操作权限，由计算机对每个柜员的操作权限进行自动控制，不得越权处理。 2.1.4.2 营业机构管理

系统对各营业机构的工作日及营业时间进行管理，设置人行交换

营业日历、对公营业日历、全年营业日历等，对非营业日的相应柜面交易以及账号类型进行严格控制，防止账务在非营业时间被非法修改。

2.1.4.3 操作员管理

由一级分行核算中心统一管理全辖各机构的操作员。各核算中心可以查询所辖所有机构的操作员信息，机构只能查询本机构的操作员信息。

操作员以划卡并输入密码方式进入系统，系统为每位操作员提供更改本操作员密码功能；操作员操作员密码具有时效，每隔一段时间必须修改一次密码，否则无法进入系统。

2.1.4.4 业务处理过程

临柜业务操作形式管理。临柜业务操作形式分为单人临柜和双人临柜。在合理划分业务处理类型的基础上，单人临柜形式处理的业务以交易完成系统打印认证并由人工检核的方式进行控管；双人临柜形式处理的业务以换人双敲复核的方式进行控管；对办理风险系数比较高的业务（如大额取款等）可结合划卡密码授权等手段对业务处理进行控管。

对现金进行实时监控。系统设置联动的出纳机交易，将每笔现金交易必须进行券别张数的记载，并与现金账务交易金额自动核对，并登记柜员库存现金尾箱登记簿，有效地控制了现金差错的发生。

对重要单证的全程监控。系统从重要单证的入库、调拨、出售、使用、作废、销毁的全过程进行控制。单证入库时登记号码，内部使用时必须连号使用并注销号码；出售凭证时号码记录在购买凭证的账号下，在客户使用时注销号码；单证调拨采用由上级机构或现金柜员发起交易在调出方和调入方同时记账；每笔涉及重要单证的交易必须进行单证号码的记载，登记柜员重要空白单证登记簿，强化了重要单证的管理。

2.1.4.5 日结管理

柜员日结管理。柜员日结时，采用将清点的库存现金、重要空白凭证的结果输入系统，由系统自动核对的柜员主动方式，减少了柜员结账过程中的随意性；系统自动将柜员的当日流水进行借、贷平衡，并打印柜员交易流水清单，柜员科目日结清单，确保交易处理正确。

机构日结管理。机构日结时，系统自动检查本机构柜员的日结情况，并打印出本机构的交易汇总表、柜员结账时间表等，同时在柜员结账时间表中将各柜员的最后一笔账务性交易流水反映出来，加强柜员日结的管理和监督。

核算中心日结管理。核算中心在规定的时间进行日结处理，系统自动检查所辖各营业机构的日结情况，进行账务体系中的各项平衡检查和处理。对于未日结的机构次日打印出营业机构未结账清单；对于流水不平的营业机构系统自动进行宕账处理，同时打印流水不平错误

清单；对于系统批处理过程产生的不平账户，打印异常挂账清单；核算中心根据不同清单督促营业机构或有关部门查明原因进行账务处理，起到监督作用。

2.2 对现有系统的分析

2.2.1 一级分行数据集中情况

截止2002年6月21日一级分行数据集中的现状是：33个一级分行已完成数据集中；3个分行（广东分行、辽宁分行、江苏分行）省行系统和省会城市行系统未整合，存在省市行两套系统。在实施数据集中的分行中集中方式各不相同。

从应用整合情况分析，部分分行已实现了会计、储蓄、信用卡等应用系统、数据及服务器的整合，如湖北行、浙江行、安徽行、内蒙分行、宁波分行、新疆分行、大连分行、河南分行、黑龙江分行、厦门分行、上海、深圳分行等；部分分行其会计、储蓄应用系统是分别独立的，未整合，但各独立的应用系统的业务处理和数据在一级分行内是整合的，如甘肃分行、海南分行、吉林分行、广东分行、陕西分行、天津分行、北京分行、江苏分行、江西分行、山西分行、重庆分行、宁夏分行、青岛分行、四川分行等；部分分行应用系统整合，但各二级分行的数据是彼此独立，如河北分行等。

37个一级分行中有34个集中的主机平台是UNIX系统平台，有3个分行（陕西分行、青岛分行、海南分行）集中的主机平台是A机，

2

2

摘自总行“加快科技创新和产品开发调研组”2002年6月对全行一级分行数据集中情况所做调查。

有4个分行（福建分行、吉林分行、宁波分行、天津分行）集中的主机平台是AS400。3个分行（广东分行、辽宁分行、江苏分行）集中后存在UNIX和A机两种平台。

一级分行数据集中大多采用了帐务数据集中到省分行，并对全省业务进行统一、集中地处理和管理。中间业务通过市前置系统处理但帐务集中到省行的方式（部分行将省内具有共性或统一的中间业务集中到省行前置机）。在数据中心的核心业务系统中，包含了所有的帐务数据和具有共性的业务应用逻辑；在市分行的前置系统中，只包含本地特色业务应用逻辑及相应的系统参数和管理数据；市分行仍保留中间业务平台、人行天地对接系统、人行金卡系统、ATM前置机（部分分行ATM前置机上收到省行）、POS前置机等前置系统通过市分行交换系统与数据中心进行信息交换。与总行龙卡网络系统、资金清算系统、网上银行系统、重要客户系统、证券登记系统、以及国际结算系统等的联接是通过省行前置交换系统实现的。

2.2.2 一级分行数据集中后存在的主要问题

数据集中后，系统故障的影响面和风险性大大增加，对数据中心的日常操作运行和维护工作有很高的要求，迫切需要提高自动化操作和监控的程度，减少人为因素的出错，提高对风险的预防、提示和应急处理能力。同时急需加强灾难恢复、远程数据备份、网络集中监控方面工作。

由于数据集中后的业务处理模式的变更，使得现行的业务管理体

制与之产生冲突，主要表现为现行的相关业务制度和操作流程不能满足数据集中后的业务管理和操作的需要。

外围接入系统较多，总行各种本外币系统都需以不同的接口接入，重要客户既有重要客户系统的入口又有清算企业终端的入口，为系统的整合增加了难度。

分行对下一步全行数据集中的要求还不清楚，对数据集中后的一些问题，无法确定是自行制定方案和投资予以解决，还是与全行数据集中一并考虑。希望总行尽快提出全行数据集中的有关要求和标准，使分行明确下一步工作，为数据集中做好准备，而不只是处在观望之中。

2.2.3 CCBS系统简述

CCBS是总行1997年下达的计划项目。该项目属于金融行业中的银行计算机应用项目，它涵盖了主要的银行核心业务，包括活期存款、定期存款、贷款、代理、结算、信用卡/储蓄卡、会计、电子汇划、清算、帐簿、客户信息、共用、外汇买卖、证券等。

CCBS参照1997年总行组织的业务需求说明书进行开发，主要应用设计目标包括：

 集成各种主要的银行业务。同时也为未来融合新业务作了充分的考虑。

 使用操作简单，实现业务的统一连动和全面自动转帐。

 系统维护容易，使用结构化编程及基于组件设计，各种类型的程序有相对应的程序模板。

 业务扩充性强，可以方便地增加新业务或调整现有业务，适应不断变化的市场，组合新的金融产品。

 系统稳定可靠，严格的安全控管设计、严密的日志和数据库变动记录设计、并且充分发挥IBM服务器高可靠性和可用性的特点。

 平台独立性，适应各种主流平台、操作系统、中间件、数据库和通讯协议等。

 开放的系统架构，可以方便地连接各种外部设备和系统，包括ATM、POS、金卡网络、龙卡网络、电话银行、电子银行、电子商务、电话中心(Call Center)、信息管理系统等等。 CCBS的先进性和优势主要表现在：

 应用业务控制平台（CCBMAIN）——抽象银行业务的处理流程，实现交易流程和信息处理等模式的标准化，简化应用程序逻辑。

 业务知识（KB）——将各业务处理规则归纳为处理模块，通过零件装配方式将KB及其它处理单元组成各种交易，支撑各类金融业务和金融产品。

 连线批处理——打破联机交易和批处理的界限，使同一业务

交易可以在此两种模式下运行。

 24小时运行——设计24小时交易帐务和处理的架构和原则，任何交易只要遵循此原则，即可加入24小时运行。由于采用驱动表格联机切换方式的设计，实现了不下CICS的联机编译和切换。

 会计记帐规则——通过参数化和表格化的设计，业务会计规则的变化可通过表格定义完成，而不影响交易程序逻辑。  参数化——将所有可变的业务变量以参数形式定义在记录中，以应对业务变量的随时调整。

 综合理财系统提供了集各类金融产品为一体化的综合性帐户；并且以客户身份识别卡为载体，以各类电子自助设备和各种渠道（如网上银行）为媒介，为客户提供可选择的人工、自助和自动的各类银行金融产品的综合理财服务。综合理财在以往的银行系统中是难以实现的，而该核心系统是以面向客户关系为基础整合的、全业务的柔性系统，在先进的业务平台的支持下，充分发挥了联机24小时不间断服务的特长，和KB（业务知识模块）的灵活性和可组合性，构筑了如此创新的业务模型。

CCBS于2000年12月在上海分行首先投产成功；2001年5月1日在深圳分行成功推广。

3 总体技术方案

3.1 总体技术方案描述 3.1.1 数据集中模型

此模型分为三层，即总行、分行、网点，并且将功能（Function）与数据（Data）分布在三层架构上，在业务功能的设计上可依实际需要以最佳化的方式做分布组合。在分布的原则上差异大的部分则往大前置（F2）下移，例如代理业务的输入文件与客户回单等非标准化的处理。如果是标准化的处理，则在主机处理如扣帐，入帐处理。

D1交易传输D2总行交易传输主机F0文件传输前置F1外接实体F3D3外接实体分行大前置F2交易传输报表传输D4网点Web-Teller服务器D5终端D1＝业务与客户主档D2＝前置运行流水数据D3＝前置运行流水数据＋中间业务的数据＋交换数据＋制卡数据D4＝分行的管理数据＋分行运行报表D5＝网点的运行报表＋电子日志＋密钥

模型说明：

实 体 业务功能 技术要点 备 注 F0 中心主机 AG(帐务处理)、CB、CI、SYSPLEX、分行独CCBS优化改造、核CM、CR、FL、FS、FT、立批处理、数据分算中心与客户管GL、LN、RE、SA、TD、区、跨分行实时帐理中心设置 XT 务处理、负载平衡 龙网、清算、网银、证报文转换和转发、F2和F2’可直连券登记、重要客户、汇协议转换、流量控F1 价(路透)、金网、国际制、交易组装 卡、SWIFT F1 中心外挂系统前置 AG(签约及信息转换)、报文转换和转发、定义统一开发标主机信息的接受和管协议转换、网点版准 F2 一级行大前置 理、网点管理、制卡、本管理、流量控 ATM/POS、自助设备管制、交易组装、本理控制 地特色业务开发、Java及浏览器支F2’ 二级行大前置 持 证券、重要客户(过通讯和密钥管理、与大前置以IP协渡)、金网、银证通(转Java及浏览器支议连接 帐)、企业银行、CALL 持 Center、天地对接等中间业务平台 主机和外挂系统交易处理、连线报表、通讯和外设管理、所有业务功能的网点的信息管理 密钥管理 交易处理 F3 一、二级行外挂前置 F4 网点服务器 注：

AG － 代理业务子系统 CB － 债券子系统

CI － 客户信息及中心额度子系统 CM － 公用子系统 CR － 银行卡子系统 FS － 综合理财子系统 GL － 会计子系统

FL － 电子汇划子系统 FT － 资金调拨子系统 LN － 贷款子系统

RE － 结算子系统 TD － 定期存款子系统

SA － 活期存款子系统 XT － 外汇买卖子系统

3.1.2 数据集中体系架构

体系架构包含逻辑架构与实体架构，逻辑架构的基础是大集中的模型，描述初期阶段由中心、分行、网点所含盖的应用体系。实体架构是以硬件为基础的北京、上海两中心的体系结构。

1. 逻辑架构

此逻辑架构在应用设计上将遵守四大原则： （1） 逻辑集中，物理独立

数据集中后在逻辑上将各省市数据集中，在物理上各地区数据独立存放，将各行的数据集中在一个IMS上。 （2） 联机、批量独立运行

各省级分行的业务由系统自动调度分派到多个CICS上运行，各行数据库相对独立，不同行可通过不同的CICS处理各自联机交易和独立运行批处理，既确保数据的统一，又不影响各地区业务的独立运作。

（3） 独立切换，不影响没有上线的分行、支行

系统将实行独立切换上线计划，确保不影响已集中上线的各行的生产营业，保证系统的安全性。在大集中的系统架构 – 将数据在数据库中按不同省市区分，不影响他行的正常营业，支持这种方式的可行性。 （4） 业务管理运作独立

这种架构同时也支持各地业务管理运作的独立性，即规范统一了一般常规业务，又为各地区的特色业务提供了灵活的前置开发的空间和管理的便利，满足不同区域的业务要求，发挥当地特色，提高整体经济效益。

2. 实体架构

 双中心设计

数据中心的数目完全取决于业务的需求，中心越多，运行成本越大，管理越复杂，并且中心数量的增加将使灾难备份的方案设计、实施和管理更加复杂。初始系统模式可以先建立在两个地方，一个在北京，另一个在上海。两个中心将通过高速线路与WK银行全国网

络相连，为全国中心WK银行银行客户提供服务。如经过适当改变，也可以为国际客户提供服务。DCC中心将支持标准的WK银行核心业务系统-新一代柜面业务系统，还会逐步开发并支持增强建行市场竞争力的新兴业务，如电子商务、商务智能等。用户将按地域分为两个主要区域。北京的中心将支持北部中国，上海的中心将支持其余地区的用户。用户的划分将主要以业务量计算，当然也包括其他相关因素。

 跨地域的并行系统综合体GEOPLEX设计

北京与上海的两个数据中心之间设计成Geoplex。两中心通过高速通讯线路相连， 利用异步远程拷贝技术XRC进行数据的相互备份。两物理中心之间的连接距离可近似 无限远。以这种形式连接在一起的中心称为：'Geographically Dispersed Parallel Sysplex' (GDPS)。

GDPS是一个对多异地数据中心实施管理的机制，它结合系统码及自动管理工具， 运用Parallel Sysplex技术，存储子系统异地镜像技术及数据库的管理机制来管理处理 器，存储及网络资源。

其设计宗旨为尽可能减少或潜在地消除灾难或计划内的场地维护所带来的影响。 它提供一种可控的场地切换能力，无论这种切换是由计划内的或计划外的场地故障导 致的，极少数据丢失，保证跨卷间及不同磁盘子系统间的数据完整性，而且具有在备份场地执行

数据库重启动的能力。(注意：不是数据库恢复操作)。

GDPS通过磁盘存储子系统，Sysplex，及环境触发器来管理异地之间的数据的一致性。GDPS提供跨地域的系统自动化管理，与磁盘纠错恢复过程相结合，产生一个新存储子系统功能来管理跨地域的数据一致性。

 PPRC（Peer-To-Peer Remote Copy）设计

另一种选择为北京与上海分别采用自己的线上备份方式，其限制为备份的数据中心不能大于ESCON的距离，其好处是几乎同步备份。假如主中心有DASD产生硬件错误则可切换而采用备份中心的数据。只可能丢失(Inflight)的部分，同步的程度非常高。

3.1.3 数据中心基础设施

基本上基础设施的定义包含硬件服务器，系统支撑软件，通信传输，网络协议，储存系统及应用，并由一套完整的管理机制所建立。在本节只针对主要部分，即硬件，网络与软件加以说明，其他部分将会在后面单节描述。 1. 硬件架构

初期的数据中心并行系统综合体中主机系统主要设备及连接如下图所示。 主要包括处理器、存储系统、通讯系统等部分。

以建行上海数据中心第一阶段并行系统综合体中主机系统及主要设备说明

设备类型 设备型号 功能说明 并行系统综合体生产主2064-xxx zSeries 900 企业级服务器，以其64位的z系列机#1 体系结构，与z/OS结合，提供动态电子商务环境下无与伦比的系统可靠性、可用性、可扩展性；单机处理能力从249MIPS 到3110MIPS。与两台以上的同系列主机组合成并行系统综合体环境，构成CCB-DCC的生产主机。即可做为生产主机与#2主机均衡CCBS系统的工作负载，同时也可与#2主机进行互为备份。 并行系统综合体生产主2064-xxx 同上。即可做为生产主机与#1主机均衡CCBS系统机#2 的工作负载，同时也可与#1主机进行互为备份。 并行系统综合体外置藕2064-100 实现并行系统综合体环境中的工作负载均衡，和合器 资源共享。 并行系统综合体时钟控9037-002 同步并行系统综合体环境中所有处理器单元的制器#1 时钟，保证该环境中使用一致的时间标记。 并行系统综合体时钟控9037-002 保证整个系统的高可用性，做为#1的冗余备份。 制器#2 ESCON转换器#1 9032-005 提供主机ESCON通道和外设ESCON控制单元间的光纤链路连接和切换 9032-005 与ESCON转换器#1均衡工作负载，同时互为备份。 2074-002 实现单点控制，提供多个逻辑分区的系统映像管理。 2074-002 与控制台控制器#2均衡工作负载，同时互为备份。 2105-F20 提供主机系统和CCBS应用系统的磁盘存储需求。 2105-F20 与企业存储服务器#1均衡工作负载，同时互为备ESCON转换器#2 控制台控制器#1 控制台控制器#2 企业存储服务器#1 企业存储服务器#2

份。 虚拟磁带服务器#1 3494 含有虚拟磁带服务器的3494磁带库，使用高速磁盘做为磁带机系统的缓存，大大提高磁带机性能；采用先进的虚拟技术，充分利用磁带空间，降低系统成本；自动的磁带装卸和保存管理，避免人工操作的失误。 独立的3590磁带机提供系统、应用系统日常维护时的数据存储或检索 高速激光打印机 并行藕合体的高速连接 CISCO SNA与IP协议转换器 开放系统适配卡连接主机与本地网 磁带机 3590 打印机 藕合器 路由器-ICP 系统适配卡 IP4000 ICB OSA-E

2. 软件架构

R A C F Z O S S Y S T E M M A N A G E M E N T T O O L S R E S O U R C E M O N I T E R T O O L S D B C T L System Auto TPNS Stress Testing Tool DITTO Fault Analyzer App Monitor LIB MGT Tools PSF COBOL v3 File Manager z/os v1.3 VTAM/TCPIP CICS TS V2.2 CICS PA CICS IA CICS VR A P P 1 A P P 2 … A P P n M Q S e r i s e I M S D B T O O L S A P P C C B M A I N B M P 1 . . n C E N T E R C U T 1 . CCBmain IMS/ DB V7 VSAM/QSAM

主要产品说明如下：

Prog No. 5694-A01 z/OS V1 5655-G53 COBOL for z/OS & OS/390 V 5648-B33 AFP FONT COLLECT V2 FOR S 5655-B17 Print Svcs Fac V3 for OS/ 5655-103 DITTO/ESA for MVS 5688-121 TPNS V3R1 5697-E93 CICS Transaction Svr z/OS 5655-H91 CICS VSAM Recovery V3R1 Description 中文说明 Z/OS 操作系统 COBOL编译工具 打印字库 PSF高级打印管理软件 数据操作工具 网络仿真及应用测试工具 联机事务处理软件 CICS VSAM 数据恢复软件 CICS 性能分析器，提供offline CICS性能报告 在线CICS资源分析器，提供CICS 资源利用和分布的集成报表，存储在DB2中。 IMS 层次式数据库 5655-F38 CICS PERFORM ANALYZER OS/ 5655-G76 CICS/IA z/OS and OS/390 V 5655-B01 IMS Version 7

3.1.4 主机系统架构

主机由前置连接终端进入主机的交易负载平行CICS-TOR（Terminal-Owning Region）分区由其自主分至应用处理CICS-AOR（Application-Owning Region）分区调用CCBS的应用程序，进行业务处理，而数据的处理则由IMS进行存取服务，其多分区的数据

完整性由IRLM控制。在数据库的物理设计上以分行为单位进行分区，以有利于分行批处理的独立运行，与数据转换的独立性，但在逻辑上仍以视为一个整体的数据库，以简化应用的逻辑处理。

Branch 1Branch 2Branch 3...Branch nCICS-TOR* 21 LparCICS1CICS2CICS3CICS4CICS5CICS6...CICS-AOR *nCICSnCICS-SwitchCross Branch Data BaseBranch 1Branch 2Branch 3...*2Branch nIMS/DBBatch 1Batch 2Batch 3Batch n

在本地的数据库可运用PPRC(Peer-To-Peer Remote Copy)的技术进行数据库的线上备份（READ ONE，WRITE TWO），当其中一个盘有问题时可及时切换保证系统的可持续运行。

3.1.5 应用架构

公用程序Utililty programSystem Service Call系统伺服调用OS390 SNAUnix TCPIPOthersCCBExit Routine出口程序架构控制main模组Message Format输出入格式器应RHISSGTLAEOVMessage StandardlizationInput Message FMTPKPCSCPPIHPR用Message BehaviorOutput Message FMT伺Application Transactions服应用业务Trigger Manager联动控制器务器ProductTransactionKnowledge BlockCommon FunctionApplication Server产品交易业务知识公用函数DBImain数据界面IMS Hirerarchical DBDB2 Relational DBHybird Mix SystemDB E数据Access 引擎EnginesG12345678910111213n

说明：

 公用程序：由多个工具程序所组成用来生成架构控制模组的内存表格

 系统伺服务调用：提供操作系统(OS)的基本服务，其目的在使CCBS应用系统能适应于不同的硬件与操作系统(OS)环境。同时增加了对渠道服务的弹性，是应用架构中非常重要的环节。

 架构控制模组：是处理银行的共通的业务流程。例如：安全性检查，业务连动控制，冲正控制，交易调用，流水处理，会计帐处理，重要单据控管，清算柜员收付，网点科目帐等，同时提供各种出口程序给各应用做例外处理。

 输出入格式器：是在使输出入的讯息标准化，这样可使各种服务设备非常容易的接入CCBS应用系统。

 应用伺服器：是应用程序对平台服务要求的界面程序。应用程序可以透过该界面要求CCBMAIN进行核心业务的处理。  应用业务：是CCBS的应用系统的主要组成部分，CCBS应用由产品交易，业务知识与共用函数所组成。产品的定义可充分的再使用业务知识的组成。由此四层的架构可提供弹性的应用解决方案，进而保证银行业务的成长及业务处理流和变更。透过联动控制器可让业务的水平非常容易达成，以此达到服务质量的提高。

 数据界面：是在简化复杂的数据处理环境。其目的在降低应用的复杂性及提供不同的数据库系统在不同的应用需求上。例如；阶层数据库应用于固定逻辑的柜面业务，回应速度要求高，关联数据库应用于随机的处理模式及回应速度要求低的应用，如信息管理系统。

 数据引擎：是数据处理的底层模组，是由存取产生器所生成。同使使用者可提供自由定义模组，以满足各种不同的需求。



出口程序：在CCBMAIN提供多种的出口程序供应用业务在特殊或共同的处理上有一个出口，以达到应用弹性的最佳化。

3.1.6 实施方法

数据集中实施的方法可分为八大步骤。由业务的标准化着手，当集中数据量到一定的程度时将发生质的变化，此时可再进一步的优化CCBS以配合管理的简化与产品的创新，让CCBS的弹性应用架构支撑CCB的快速业务成长。

实施方法：业务标准化系统架构改造数据中心建立压力测试中心切换问题评估分行切换应用再优化Step1Step2Step3Step4Step5Step6Step7Step7Step7Step8流参核管程数算理制制方办定定法制定法制定硬/软件设计网络设计备份/恢复设计CCBS应用改造大前置设计网点终端改造数据分区设计批处理分区设计硬软应系人中 规件件用统员心则定安安调培管制装装装整训理定测试方法设计标准制定测试报告数柜业模切上北据员务拟换海京转培测测计切切换训试试划换换问题收集分类问题解决问题追踪管理数据转换柜员培训功能切换简化业务流程创新服务产品3-5年

3.2 和现有系统的比较

比较的基础是以上海行目前的应用版本与未来DCC的版本做比较。

类别 S Y S 系 统 端末 网络协议 Web+SCO-UNIX SNA+IP 2个 集中 三级 多分行并行 前置机 集中 SCO-UNIX SNA 多个 分散 二级 单一分行 1/LINK 分散 支持多种模式 以开放的IP协议为主 数据逻辑集中 北京与上海两中心 主机、大前置、网点 支持不同时间关帐与跑批 由主机下放至分行前置机 安全性提高 比较项目 Sysplex支持 性能（吞吐量，回应时间） 支持 多分行 未来 不支持 上海行 现在 CICS命令修改 进行压力测试 说明 数据中心 系统管理 A P P 应 用 ATM/POS控制 密码管理 架构 批处理

报表信息 B I Z 业 务 清算体制 错误信息表示 交换模式 业务参数 帐号 中间业务 业务标准化 数据转换 培训工具 前置机 已上线分行不停业 多媒体 多级 明确 多种 多分行 全国分行 只处理帐务 容易 网点服务器 停业务 无 三级 不明确 一种 单一分行 上海/深圳 全部业务 不易 文件传输 不影响已上线分行 自学工具 以总行角度 方便柜员操作 归纳全国交换模式 业务多样化 以不改变客户帐号为原则 下放至前置平台 应用集中在基地开发

3.3 和相关系统的关系

数据集中项目有三层架构组成，数据中心；一级分行交易平台；网点端末或用户接入渠道。从逻辑上分，对相关系统的关系主要表现在数据中心和一级分行交易平台这二层上，下面分别于以描述。

3.3.1 数据中心与相关系统的关系

1. 数据中心与人民币清算系统的关系

由于数据集中系统初期由二个数据中心组成，在数据中心架构设计上，应具有同一数据中心下不同分行间的通存通兑和清算功能，跨数据中心之间的通存通兑和清算功能。在数据中心建设初期，数据中心与人民币清算系统的关系主要体现在已接入数据中心的一级分行与未接入数据中心的分行之间的汇划和清算，可通过数据中心与清算系统或分行交易平台与清算系统的连接来实现。当全部分行都接入数据中心后，数据集中项目的功能将取代目前的人民币清算系统。

总行清总行清算系统算系统前置 前置 数据中心A 数据中心A 分行分行间清间清算 算 数据中数据中心间清心间清算 算 数据中心B 数据中心B 分行数据中分行数据中心间清间清心间清间清算 算 算 算 总行清总行清算系统算系统前置 前置 总行清总行清算系统算系统前置 前置 分行交易平台 分行交易平台 分行交易平台 分行交易平台 总行清总行清算系统算系统前置 前置 网点端末或用网点端末或用户接入渠道 户接入渠道 网点端末或用网点端末或用户接入渠道 户接入渠道 数据中心与人民币清算系统关系示意图 数据中心与人民币清算系统关系示意图

2. 数据中心与B股清算系统、PC-CONNECT系统（外汇清算系统）的关系

目前各分行B股清算通过TCS，其它外汇的汇出、汇入通过PCC连接总行的ALLIANCE系统与SWIFT系统相连，实现外汇资金清算。目前各分行没有一个统一的清算系统来实现账务系统与外汇清算接口的连接。数据中心通过外汇清算前置系统与PCC接口连接，实现外汇的汇入、汇出，头寸申报和平盘的，外汇清算的其他特殊处理由外汇清算前置系统完成。由数据中心统一通过外汇清算前置系统连PCC，需实现分行国际业务部柜面终端能接入数据中心的外汇清算前置系统。（也可由各分行的外汇清算前置系统连PCC。）

PC-CONNECT PC-CONNECT 外汇清外汇清算前置算前置系统 系统 数据中心A或B 数据中心A或B 外汇清外汇清算前置算前置系统 系统 分行交易平台 分行交易平台 网点端末或用网点端末或用户接入渠道 户接入渠道 数据中心与B股清算系统、PC-CONNECT系统（外汇清算系统）关系示意图 数据中心与B股清算系统、PC-CONNECT系统（外汇清算系统）关系示意图 3. 数据中心与路透网国际汇率和人行人民币汇率系统的关系

数据中心建立后，可通过统一的汇率前置系统与路透网连接，安设定的时间间隔连续向柜面系统传送外汇汇率，每天一次传送人民币汇率。各分行的点差可由柜面系统分别计算。

路透网接点 路透网接点 汇率前汇率前置系统 置系统 数据中心A或B 数据中心A或B 数据中心与路透网国际汇率和人行人民币汇率系统关系示意图 数据中心与路透网国际汇率和人行人民币汇率系统关系示意图 4. 数据中心与总行龙网系统的关系

在二个数据中心完全建立后，根据数据中心与人民币清算系统的关系的描述，表明数据中心的功能将取代龙网的作用。在全部分行接入数据中心前，可通过由数据中心的龙网前置机与总行龙网系统连

接，实现数据中心与其他分行之间的龙卡清算。

总行龙网 总行龙网 龙网前龙网前置系统 置系统 数据中心A或B 数据中心A或B 或分行交易平台 或分行交易平台 数据中心与总行龙网系统的关系示意图 数据中心与总行龙网系统的关系示意图 5. 数据中心与重要客户服务系统的关系

重要客户服务系统是在总行还没实现数据集中前，为满足客户即时的跨分行的划账或查询及客户自助银行的要求而设计的，数据中心建成后，其功能将全部取代重要客户服务系统的作用。在数据中心建设过程中，各分行可将分行的重要客户服务系统分中心服务器通过分行交易平台与柜面系统连接，实现账务的实时处理。

3.3.2 一级分行交易平台与外系统的关系

根据数据集中系统的系统架构，对于按省、市级运作的外系统（有的是按地市级运作的，可按省、市级运作的外系统的相同方式处理），通过一级分行交易平台与其连接。

1. 与信贷系统、总账传输系统、稽核系统及管理信息系统的关系

分行交易平台将发往数据中心的每笔交易信息送入账务信息数据库，数据中心每日批处理后将当日的账务信息下载到账务信息数据

库，上述各系统从账务信息数据库中获得信息源。

2. 与代收、付委托单位系统、外管局监管系统、人行交换系统的信息交换关系

分行交易平台将相关交易的信息及各网点发来的批量信息，通过整理归类，存入代理信息库，转换成上述系统的格式，分别发往。 3. 与总行重要客户系统、证券系统的关系

上述系统的前端交易嵌入数据集中项目的前端平台中，后台的账务处理通过分行交易平台的报文转换，完成账务处理。 4. 与企业自助银行系统、人行天地对接系统等的关戏

上述系统均通过分行交易平台的报文转换，完成各系统所需的柜面交易。

5. 与CALL CENTER、网银系统、银证通（银证转账）系统的关系

上述系统的客户签约均采用前端的前置应用系统交易，记入共享的客户签约信息库，各应用系统的柜面交易通过分行交易平台的报文转换实现，CALL CENTER、网银还可通过本分行的TCP/IP网，接入其它的前置应用系统。

6. 与海关、税务等EDI系统的关系

上述系统的申报可采用前端的前置应用系统交易完成，后台的账务处理由海关、税务系统前置机通过分行交易平台的报文转换，完成账务处理。

7. 与商品房维修基金等需记二级信息账的应用系统关系

二级信息账的处理在外系统的应用中完成，一级客户账的处理由外系统的应用汇总，通过分行交易平台的报文转换，完成柜面记账及其它功能。

8. 与各地金卡网络的关系

各一级分行通过分行交易平台的报文转换，交易管理及连接驱动器实现与当地的金卡网络连接。

DCC项目分行交易平台与外系统的关系示意图 SNA 主机交易平台 批后数据下载 业务信息库 连机交易信息输出 路由选择 代收、付信息及外系统需信息处理 输入、输出报文转换 企业自助银行前置机 CALL CENTER 企业自助终端 电话接入 数据中心主机 管理信息系统、实时监控系统、总账传输、信贷系统、稽核系统 外接系统交易管理TCP/IP 客户签约库 网银系统 金卡网接口 商品房维修基金、二级账系统 海关、税务等EDI前置银证通、银证转账前置机 人行天地对接前置机 INTERNET 外系统 EDI网络接口 券商系统 代理单位、外管局等 代收、付信息库 前端交易管理 人行网接口 总行系统 总行系统 总行重要客户服务系统前置机 TCP/IP 总行证券系统前置机 WEB SEVER 单位委托代理信息 纯主机交易 前端交易平台 单笔或批量代收、付交易 前置应用系统的前端交易（可改造） 外系统的前端交易 （不可改造） 低柜前端

3.4 采用该技术方案可能带来的影响

1. 对设备的影响

本项目将先期建立北方和南方两个数据处理中心，基于IBM公司z系列大型主机并采用Parallel Sysplex技术搭建运行平台。两数据中心组成GDPS，以高速线路连接，利用异步远程COPY技术XRC互为备份，或PPRC的备份方式。中心所需处理主机、存储设备、网络通讯设备，除少部分可以利用目前上海、北京等分行现有的主机设备，绝大部分需另行购置。

根据技术方案，在38个一级分行将部署大前置系统。目前各一级分行的数据集中主机应能够满足大前置系统的性能要求，无须另行购买。各分行现有网络通讯设备、存储设备可以在未来运行中继续使用。

保护现有投资是数据集中项目的一个重要原则，最大限度的兼容和利用现有网点硬件设备是数据集中项目努力的方向之一。 2. 对现有软件的影响

本项目成功实施后，全行的帐务数据和相关客户数据将集中到总行的数据中心。总行统一的核心业务系统将取代目前各一级分行使用的柜面系统或综合业务系统。

未来数据中心的系统环境将基于IBM公司的z系列大型主机，采用IBM公司的z/OS操作系统，CICS TS，IMS V7.0数据库。这些软

件将在数据中心的建立过程中，随数据中心硬件一起购买或升级。各一级分行现有的操作系统、中间件、数据库产品，应可以在大前置系统或其他系统中继续使用。 3. 对用户的影响

数据集中系统将替换各一级分行的现有帐务处理系统，总行各部、数据中心、以及各一级分行辖内的业务人员、管理人员和技术人员，应接受相关的业务和技术培训。 4. 对系统运行及管理的影响

总行数据中心将负责集中后全行数据中心的运行和管理工作，相对目前各一级分行的运行管理工作，在工作量、难度和质量方面都提出了较高要求。数据中心需要大量熟悉IBM大型主机的系统人员，熟悉全行数据集中系统的应用技术人员，以及熟悉全行数据集中系统业务需求的业务和管理人员。这些人员的数量和素质，以及如何培养和保持这只队伍的稳定，是数据集中系统平稳运行和有序管理的充分必要条件。

此外，为了更加有效率的管理数据中心，应建立一套完善的管理工具和策略来实施日常运行管理。管理的对象包括网络管理、应用管理、存储管理、中间件管理等。管理的策略涉及操作管理、故障及问题的管理、性能和容量管理、安全管理、资产管理等。

各一级分行将从目前繁重的运行管理工作中解脱出来，专注于大前置系统的运行管理工作，降低对分行运行管理人力资源的要求，总

体上减少了一级分行运行管理工作的成本投入。 5. 对开发和运行环境的影响

数据集中系统的开发和维护工作，将在总行统一领导下，由指定软件开发基地负责。各分行现有的柜面业务系统将在数据集中的过程中被逐步替换，集中后各一级分行不再专门保有负责核心业务系统开发和维护工作的开发队伍。从WK银行总体看，在核心业务系统开发和维护的人力成本将大大降低。版本的简化和统一，使开发过程更加简单，新业务的推广更加迅速。使建行有能力将从核心业务系统开发和维护上节省下来的人力资源投入其它方面的工作，从而提高建行信息技术工作的运行效率和运行成果。

数据集中系统将基于IBM公司z系列大型主机环境当中，需要培养大批熟悉主机系统的系统人员和熟悉核心业务系统的应用人员,建行目前科技队伍中大部分技术人员将通过培训实现技术转型或转岗。 6. 对保密和安全的影响

本项目对系统的安全性提出了很高的要求。由于数据中心在全行业务运行中所处的核心地位，数据中心运行主机的安全性、数据中心业务数据的安全性、数据集中系统网络的安全性，以及数据集中系统管理的安全性都将对全行业务的开展造成重大影响。

数据集中系统将遵循总行对于安全方面的规定和规范，采用硬件设备冗余、网络设备冗余、备份及灾难恢复技术、通讯安全加密技术，以及授权、审核、稽核等多种手段保证系统的安全性。

7. 对经费支出的影响3

本项目是一个创新项目。其费用支出主要表现在以下三个方面：  数据中心：包括数据中心所需的软件和硬件设备的购买费用，数据中心的场地建设费用，数据中心未来的运营费用等。  开发费用：包括开发/测试环境所需软硬件购买费用，办公环境的支持费用，开发过程中的人力成本，食宿差旅费用，合作公司/系统集成厂商的费用等；

 试点分行推广费用：包括数据转换费用、系统切换改造、培训、可能的设备更新费用等；

3.5 实施风险

由于本项目规模大、范围广、任务重且时间紧，所以合理的规划、各部门间的相互配合、稳步的计划执行和有力的组织保证对于项目实施风险的防范、保证项目的顺利完成尤为重要。

以下所列描述了本项目实施中可能存在的风险以及建议的防范措施。

风险描述 1、技术方面 系统压力 数据备份与灾难恢复 合理的系统配置，应用架构优化，充分的测试 建立数据备份中心，制订备份和恢复方案， 模拟恢复演练 防范计划 3

详细经费支出请参见“数据集中工程一期项目”立项申请报告之《项目概算申请表》

技术方案及实施能力 引入专家，利用和优化建行和相关厂商已有的合作成果和经验以减少因首次开发的风险 尽快建立标准和指导原则，统一领导协调，尽早介入 统一标准，前期培训，实施指导，成立专项组织，尽早介入 明确规定，制订流程，专人负责 上挂行的应用改造 上挂行的数据清理及转换 系统版本控制 2、人力方面 人力投入及技术水准 3、管理方面 项目实施的组织保证 开发厂商间的配合 上挂行的工作配合 投产后的日常运作 按岗设人，明确要求，余量备份，简化录用流程 “第一把手原则”，建立专职机构，充分授权 明确职责，合同约束，建立总分包制 统一认识，组织保证 设立合理机构，建立制度，明确管理办法，保持维护支持队伍 统一规划协调，建立优先级别的取舍原则，明确相应人员继续维护 建立规划协调制度，按轻重缓急原则，合理规划和控管 与现有运行系统优化的冲突 与其它项目开发的关系处理 4、业务方面 业务需求标准化及审定机制 需求变更控制 5、环境方面 数据中心的规划及建立 数据中心与上挂行间的通迅 建立权威机构，统一标准，统一管理 尽早规划，加强预测，严格控制 明确责任人，尽早计划启动 建立有效的通信平台和备份方案，合理规划系统和应用架构，合理分布前后台数据，保障适当的离线作业和离线补传恢复

开发环境及工具 6、时间方面 开发时间的限制

尽早规划，提前准备 合理规划，严密计划，明确关键点，加强控管

4 技术可行性评价

对于本项目的技术可行性将从硬件、技术、业务需求、分行配合、人力资源4等五个方面进行评价。具体结果请参阅下表：

评价项目 目前状况 目标 可控程度 必要工作 1． 硬件设备 基地sysplex测试主机 有非sysplex 主机RCA，R35 500mips 2CPU, sysplex主机 2000MIPS 2CPU sysplex主机 加上1200MIPS 2CPU sysplex主机 2． 技术重点 Sysplex enable 有现成技术 实现 高 修改CCBS，SYS Service Call 总体设计 总体设计 总体设计 数据库分区设计 中 订货 中 订货 上海中心运行主机 有1C3 700 MIPS 北京中心运行主机 有476MIPS*2 中 订货 前置方案 网络架构 系统优化 数据库分区 初步方案 初步方案 初步方案 初步方案 完整方案 完整方案 完整方案 建立以分行分区数据库 在Sysplex下完成压力测试 中 高 高 高 压力测试 有TPNS测试经验 高 压力测试计划 3． 业务需求 4

本报告假设人力资源范围包括CCBS现有参与方（建行、IBM公司、神州数码公司）、上海开发基地、北京中心和上海中心。具体的人力资源安排需待项目展开后进行进一步调整。

评价项目 目前状况 目标 可控程度 中 必要工作 标准化 已有总行在上海的实施标准 没有数据集中模式的管理办法 全国数据集中标准 总行制定标准 管理办法 制定数据集中模式的管理办法 中 总行制定 4． 分行配合 人员培训 目前上海有10位讲师 承担省分行正常业务运作 中 针对讲师团，骨干，一般柜员，后台管理人员制定培训计划 1． 分析新老系统 2． 转换程序开发 3． 切换流程制定 应用调整 有上海和深圳成功的实施经验 有上海和深圳成功的实施经验 有上海和深圳成功的实施经验 满足业务要求 中 现有系统分析，调整 数据转换 有上海和深圳成功的实施经验 满足切换要求 中 外系统接口 满足切换要求 中 现有系统分析，前置端末配置 测试 配合项目联合测试 低 按测试方案组织测试 5． 人力资源 主机系统 北京，上海，深圳已有部分MVS系统人员 建行、IBM公司系统分析员 根据项目需要配置 中 数据中心主机系统培训 CCBS 应用 根据项目需要配置 中 人员培训和建立队伍

评价项目 目前状况 目标 可控程度 中 必要工作 前置系统 一级分行有部分人员 建行、神州数码公司系统分析员 建行、IBM、神州数码公司项目管理人员 建行现有人员 建行、IBM现有版本管理人员 根据项目需要配置 到位 端末系统 根据项目需要配置 高 到位 项目管理 根据项目需要配置 中 到位 网络管理 版本管理 根据项目需要配置 根据项目需要配置 中 中 到位 到位

根据上表的评价项目，可以看出可控程度的分布

评价项目 高 1．硬件设备 2．技术重点 3．业务需求 4．分行配合 5．人力资源 总计 可控程度说明：

高—— 已有方案或初步方案，项目组内可控制解决

中—— 已具备一定投机条件但还不满足要求。涉及到项目组外的配合才能解

决 低—— 涉及的因素较多，落实和控制较难

5 1 6 可控程度 中 3 1 2 4 6 16 低 1 1 通过上述分析，尽管本项目的实施是艰巨的，但主要的难点不在技术而主要在设备、业务、人力和相关工作方面。若提供强有力的组织保证措施，这些方面的困难和问题是可以解决的。

根据上述分析，在可预见的范围内，本项目已具备了实施的基本条件。

5 经济可行性

5.1 成本投入分析

本项目成本投入概要如下表所示

单位： 元人民币

一. 人员费用 二. 场租费 三. 专家论证费 四. 非项目组人员会议费 五. 培训推广费 六. 其它非对外合同付费 七. 测试、试点及检验费 八. 行外设备使用费 九．支持与服务费 十．工具软件购置费 合计 82,748,910 880,000 997,500 886,860 33,910,800 11,942,407 5,000,000 1,000,000 443,958,800 591,800,000

十一．设备购置费 十二．其它需对外合同付费 总计 746,230,800 1,000,000 1,920,356,077 注：详见“数据集中工程一期项目”立项申请报告之《项目概算申请表》

5.2 效益分析

本项目成功实施后，将为WK银行带来可观的经济效益和社会效益，有助于赢得更多的优质客户，提高资产质量和资产收益率，减少运营管理费用开支，降低经营风险损失，形成建行的规模效应，提升核心竞争能力,为建行创造非常巨大的经济效益。

5.2.1 成本的降低

1. 减少系统运行的成本，降低计算机设备维护和运转费用

本项目成功实施后，总行数据中心将取代目前38个一级分行的运行中心，与外系统的连接更加便捷。由于全行数据集中，目前运行的部分总行系统，例如清算系统、龙卡网络、大客户系统等，可以被简化或者取代，从而大大节省运行维护费用。 2. 减少开发成本支出

本项目成功实施后，将用总行统一的核心业务处理系统取代现有38个一级分行的帐务系统，减少了重复开发，降低了版本维护的工作量和难度，大大降低了核心业务系统的开发、维护成本支出。

3. 减少日常管理成本

本项目成功实施后，可由系统自动生成各级管理部门所需的报表。各级管理部门可以准确、迅捷的从系统中提取管理数据，大大提高了管理的效率，将后台管理部门从繁重的统计工作中解脱出来，从而大大节省了日常管理的成本。

5.2.2 经营损失的降低

1. 减少资产经营损失

本项目成功实施后，业务部门将有能力全面了解客户的相关信息、资产情况和历史信用记录，在开展业务的过程中迅速、准确地对客户资信进行评判，减少了由于信息匮乏而造成经营损失。 2. 降低案件风险损失

数据集中系统通过对业务操作权限、营业机构、操作员、业务处理过程、日结等的监控，形成了完备的风险防范和控制体系，充分发挥了系统自动实时监控效能，提高了业务管理的控制能力，降低了案件发生的可能性，减少了案件风险所造成的损失。

5.2.3 经营收益的增加

本项目成功实施以后，将有助于提高客户信息的透明度，有助于提高决策的准确性，加快信贷结构调整，提高贷款质量，提高贷款收息率。

数据集中系统注重客户关系管理，有助于WK银行发掘优质客户，

有助于WK银行为客户提供全面的理财服务。项目建成后，将提高WK银行吸引大客户、优质客户的竞争能力，并因此带来可观的业务收入。

数据集中系统建成以后，将统一WK银行中间业务的操作平台，有利于迅速推广新的中间业务，有利于增加结算、委托代理、委托收费等中间业务收入。

5.2.4 无形资产的增值

本项目的成功实施，有助于提高全行的经营管理水平，支持业务创新，树立现代商业银行的企业形象。通过数据集中项目，可以在全行范围内推广先进的管理模式和管理经验经验，优化营业网点柜台设置，优化业务操作流程，提高服务质量，形成WK银行的优质品牌，进一步提升WK银行在客户心目中的形象，提高银行的核心竞争力。许多成功的企业案例证明，优质的品牌是企业成功的一项极其重要的无形资产，其作用是难以估量的。数据集中项目的建立，将为WK银行带来巨大的品牌效益，极大的增强其市场营销、竞争能力。

6 社会可行性

数据集中系统的核心业务将基于上海CCBS系统进行改造和优化，建行对现有CCBS系统，以及改造优化后的CCBS软件产品拥有版权。数据集中项目的开发和在建行范围内的实施，不会造成侵权、违法和责任。

基于CCBS改造和优化的数据集中系统，采用了整合、联动的处理方式，自动产生会计分录，由系统保证了借贷平衡，降低了对前台

人员的业务要求，使前台人员能够专注于客户服务与操作。整合的交易界面，简化了柜员在办理复杂业务时的操作。综合柜员制的设计和系统功能的丰富，使节约前台人员成本成为可能。

通过数据集中工程，将使建行有能力在全国范围内建立服务品牌。客户将有可能在全国范围内得到统一的服务品种和统一的服务品质。跨地域、跨业务类型的迅捷服务成为可能。

全行数据的集中，以客户为导向的设计，多级风险防范和控制，加强了银行后台部门的管理力度，有助于提高我行业务管理信息的准确性和时效性，有助于防范风险，提高资金运行水平，有助于未来基于客户关系管理进行深层次的市场开拓和提供个性化的客户服务。

数据集中系统将以总行认可的统一的业务需求进行开发。总行将根据现行业务制度和管理规定，借鉴目前上海、深圳等先进分行的业务需求，并充分考虑各分行的实际差异，制定建行统一的、可行的业务需求，为本项目提供稳固的组织保障。业务需求将根据项目实施情况、市场竞争的要求，进行有序地调整，从而最大限度地避免由于业务处理流程和管理方式变更所带来的风险。同时，对于实施数据集中项目的各分行，将建立完善的系统切换流程，强化培训力度，使试点分行尽快适应新系统的功能和流程，充分发挥数据集中系统的优势。

因此，通过上述方面的分析，我们认为本项目具备社会可行性。

7 可选技术方案

一个完整的技术方案，应在满足项目的业务要求前提下，在系统

环境和应用系统构建等方面提供一个整体的解决方案。

从全国性数据集中的高度考虑，除了本报告所建议的基于IBM公司Z系列大型主机的技术方案外，目前还没有充分的证据表明在其它硬件平台，或采用其它技术，可以满足全行数据集中后对业务量、数据量、处理能力和稳定性的要求。

本项目所涉及的业务范围广，重新开发所需时间长、投入高、管理难度大。基于目前现有成熟系统进行改造优化，是满足市场竞争和强化管理要求的必然选择。对于在IBM 公司Z系列大型主机上运行的核心业务系统，目前除了在上海分行和深圳分行运行的CCBS以外，在建行范围内还没有成熟产品可以替代。CCBS以总行需求为蓝本，并通过了总行的论证，可以满足总行的各项业务规范和管理规定。在上海和深圳分行两年多的运行实践表明，CCBS是稳定的，能够满足不同分行的业务要求。

因此我们认为，本报告所建议的技术方案，在已知的范围内，是目前数据集中工程唯一可选的技术方案。

8 结论意见

通过以上对项目目标、业务和技术方案、技术可行性、经济可行性和社会可行性等方面的分析，我们认为启动“数据集中工程一期项目”的必要条件已经具备，项目启动的时机已经成熟。为了早日解决目前建行在核心业务方面所面临的业务和技术问题，提升管理水准，强化核心竞争能力，建议立即着手组织实施“数据集中工程一期项

目”。