1、1 介绍 101.1 文档目的 .101.2 目标 101.3 范围 101.4 目标读者 .101.5 假设 102 应用体系架构的整体说明 112.1 应用体系架构的定义 .112.2 对某银行 IT 战略的建议 132.2.1 应用服务战略 .132.2.2 数据管理战略 .132.2.3 基础设施战略 .142.2.4 体系架构战略 .142.3 应用体系架构设计中的关键点 .142.3.1 银行的核心业务系统 142.3.2 客户信息的管理 .162.3.3 企业应用系统集成（EAI） .172.3.4 管理信息系统 .192.3.5 合理的应用系统功能 202.3.6 数据分布模式
2、 .212.3.7 应用分布模式 .212.3.8 应引起关注的技术问题和技术管理问题 .232.3.9 IT 规划的管理机制问题 243 应用体系架构的整体设计 253.1 应用体系架构的整体设计图 253.1.1 应用体系架构中的系统功能和全行的应用需求的对应关系 263.1.2 对核心业务体系系统的说明 .283.1.3 总行层面的系统总览 313.1.4 一级分行层面的系统总览 .324 建议的转型计划大纲（待项目计划出） 344.1 某银行现有的应用系统和目标模式的差异分析 3425 核心业务系统的目标功能模式 365.1 核心业务系统核心层的目标功能 .365.1.1 系统的总体功
3、能和特性 365.1.2 客户信息管理功能 365.1.3 帐户管理功能 .375.1.4 产品管理 功能 405.1.5 帐户交易管理功能 415.1.6 报表管理功能 .425.1.7 出纳/分行交易管理功能 .435.1.8 管理和监控功能 .445.1.9 现金管理功能 .445.1.10 总帐功能 455.1.11 应用安全管理功能 465.2 核心业务系统的业务层的目标功能 475.2.1 核算管理及账务体系 475.2.2 内部资金管理 .495.2.3 结算管理 495.2.4 银行卡业务的管理 505.2.5 现金管理 505.2.6 凭证管理 505.2.7 国际结算 51
4、5.2.8 对各级机构作业的支持 515.2.9 营运风险控制体系 525.3 金融产品提供 55 公司业务（仅包含帐户处理） 555.3.2 个人业务 555.3.3 银行卡业务 555.3.4 现金业务 565.3.5 资金调度业务 .565.3.6 票据清算 565.3.7 外汇买卖业务 .565.3.8 中间业务 5636 大前置的目标功能模式 .586.1 大前置系统的建设目标 586.2 大前置架构说明 606.3 大前置系统功能说明 .616.4 前端设备 .636.5 技术考虑事项 637 某银行信息总线目标功能模式 647.1 信息总线的整合层 .657.1.1 概述 .65
5、7.1.2 系统接入子层 .667.1.3 输出整合 697.1.4 BPM.707.2 门户技术 .807.2.1 门户要求 807.2.2 两级门户个性化实现方案 .817.2.3 多种前端接入实现方案 837.3 统一的安全认证机制 .847.3.1 建立客户信息管理系统 847.3.2 建立认证 LDAP 服务器 857.3.3 实现单点登录 .858 MIS 系统目标功能模式 898.1 数据仓库架构 898.1.1 图 1 数据仓库一般架构源系统 .898.1.2 ETL908.1.3 操作数据存储（ODS） 918.1.4 多维数据存储（数据集市） .918.1.5 OLAP.9
6、28.1.6 数据挖掘 938.1.7 表现层 958.2 管理信息系统体系结构 968.2.1 管理信息系统数据仓库体系架构 968.2.2 管理信息系统演进策略 10148.3 分析型客户关系管理应用架构 .1038.3.1 分行层面的客户区分 1058.3.2 分行层面的多维利润分析 .1068.3.3 分行层面的客户需求分析 .1068.3.4 分行层面的客户行为分析 .1078.3.5 分行层面的交叉销售分析 .1088.3.6 分行层面的客户满意度分析 .1088.3.7 总行层面的客户区分 1098.3.8 总行层面的客户需求分析 .1098.3.9 总行层面的多维利润分析 .1
7、108.3.10 总行层面的市场趋势分析 .1118.3.11 总行层面的重大事件分析 .1118.3.12 总行层面的客户行为分析 .1128.4 管理会计系统应用架构 1138.4.1 全面预算 1148.4.2 多维的成本盈利管理 1158.4.3 帐户的利润贡献度计算 .1158.4.4 产品/客户的利润贡献度计算 1198.4.5 渠道的利润贡献度计算 .1198.4.6 机构的利润贡献度计算 .1198.4.7 业绩考核指标 .1198.5 资产负债管理信息系统应用架构 .1228.5.1 市场风险分析和预测 1238.5.2 利润分析 1278.5.3 内部资金转移定价（FTP）
8、 1298.5.4 资本管理 1318.6 信贷风险管理信息系统应用架构 .1328.6.1 信贷风险管理信息系统数据仓库 1338.6.2 信贷风险模型 .1348.6.3 信贷风险管理决策支持 1418.6.4 信贷风险管理监控及报表生成 1429 信贷业务和风险管理系统目标功能模式 14659.1 信贷业务管理系统 .1469.1.1 目标模式信贷业务管理系统特性 1469.1.2 信贷业务管理系统所支持的信贷关键业务流程的具体说明 .1479.1.3 信贷业务管理系统的数据结构 1599.1.4 信贷业务管理系统的数据流图 1639.1.5 信贷业务管理系统的系统技术体系结构 .164
9、9.2 信贷风险管理系统 .1679.2.1 信贷风险管理系统的功能模块和整体逻辑视图 1679.2.2 信贷数据集市及数据管理系统 1709.2.3 联机数据分析及报表处理系统 1759.2.4 信贷业务管理系统和信贷风险管理系统的接口 17810 操作型客户信息管理 .17910.1 操作型客户信息管理平台的总体目标规划 .17910.2 CIF 的设计方法 .17910.3 操作型客户信息结构模型分析 .18010.4 本规划操作型客户信息设计 .18310.5 操作型客户信息存放方式 18410.6 操作型客户信息的建立和维护 .18611 资金管理系统的目标模式 18711.1 资金
10、管理系统目标模式介绍 .18711.2 资金管理系统对资金流程的全线支持 18711.3 资金管理系统功能介绍 18811.4 资金管理系统的数据结构介绍 .18911.5 资金管理系统技术体系结构介绍 19012 个人理财系统 19212.1 目标模式的个人理财系统支持的业务： .19212.2 个人理财系统整体应用流程 .19312.3 个人理财系统功能模块 19413 ERP 系统 19813.1 总帐管理 19913.2 人力资源/薪资管理 200613.2.1 目标模式的人力资源管理系统功能 .20013.3 固定资产管理 20313.4 采购管理 20413.5 库存管理 2061
11、3.6 合同管理 20813.7 ERP 系统与其它系统的接口 20813.7.1 ERP 系统与 OA（办公自动化）系统的关系 20813.7.2 ERP 系统与其它 MIS 的关系 .20813.7.3 ERP 系统与业务支持系统的关系 .20914 办公自动化系统的目标应用体系结构 210企业办公自动化的主要功能模块 210某银行的办公自动化系统的主要基础功能模块 .210某银行的办公自动化系统的主要应用功能模块 .213对某银行办公自动化系统功能模块的建议 214与其它系统之间的信息交换结构图 .215某银行的办公自动化系统的基础平台的选择 21515 档案管理的应用体系结构 218档
12、案管理在某银行 IT 应用体系中的作用与地位 .218某银行档案管理系统应具备的特点 .218档案管理与其它系统的关系 .219档案管理与办公自动化系统的关系 .219档案管理与银行业务系统的关系 .219档案管理与企业信息站的关系 219档案管理系统的主要功能模块 219数据录入、压缩、转换与存储 220档案检索 .221档案信息发布和使用 .222档案修改与销毁管理 .223系统管理 .223档案管理系统的系统流程 .223某银行档案管理系统的数据中心建设 .22516 投资管理、证券、保险和基金业务系统 2277投资管理 227投资管理的应用范围 .227投资管理的系统架构 .227投资
13、管理系统的功能需求 .228投资管理系统的主要接口 .228证券与基金管理系统 229证券与基金管理系统的业务特征 .22981 介绍1.1 文档目的1.2 目标1.3 范围1.4 目标读者本文档的目标读者为对于某银行当前 IT 系统有一定了解的 IT 管理人员及系统管理人员。 1.5 假设 在本文档的制作过程中采用了一些前提和假设，这些假设将作为文中分析与结论的重要依据。所做假设如下：所提供的关于 IT 系统及其相互间关系的信息是准确的；关于每个系统的目的及功能的描述是准确的；调查及访谈结果符实。92 应用体系架构的整体说明2.1 应用体系架构的定义本文所指的应用体系架构是支持某银行业务体系
14、架构的相关应用系统的体系架构。在某银行业务体系架构最佳实践一文中指出，银行的业务活动，可以分为：战略规划、资产负债管理和市场风险管理、信贷风险管理、财务管理、客户关系管理、渠道管理、产品管理、营运管理、人力资源管理共九个方面。银行的各类应用系统，在功能上应该直接针对以上九个方面的业务活动的需求或者为这些业务活动提供相关信息。在应用体系结构上，应该和业务体系结构的要求相适应。银行的大部分应用系统，是为银行的营运服务的。一般零售和批发的银行的营运包括本外币条件下的以下操作，这些操作形成了某银行的应用系统在银行营运方面的基本需求：1) 面向客户，提供各种金融产品和服务，包括零售银行业务、对公银行业务
15、和卡业务等2) 操作型的客户信息管理3) 银行提供金融产品和服务的分销渠道的运作4) 核算和帐务体系5) 营运风险控制体系，包括柜员管理、额度管理、业务处理流程的规范、内部审计等6) 结算处理7) 清算处理8) 现金管理9) 票据管理10)贷款的审批和管理11)资金运作12)柜台业务处理流程13)对外接口的处理某银行作为一家企业，自然需要有：1014)企业基本资源的管理，包括机构、人力资源、采购、营业性费用等方面的管理15)办公的自动化16)档案的电子化管理银行的管理，自有它的专业特色，正如在某银行业务体系架构最佳实践一文中指出的：17)资产负债管理和市场风险管理18)财务管理中的银行管理会计
16、19)银行客户关系管理20)信贷风险管理需要专门的银行管理信息系统的支持。鉴于某银行有决心发展混营业务，逐步建设成为金融集团，就还应该考虑：21)投资活动的营运和管理22)个人理财金融产品的管理营运和管理23)证券业务金融产品的营运和管理24)保险业务金融产品营运和管理所以，在应用体系架构的规划中，要考虑上述的业务操作和业务管理职能在 IT的环境中，如何实现及如何互相交互方面，为这些需求的实现和今后系统功能的扩充建立基本的框架。在解释毕博对某银行近三年的应用体系架构的规划之前，先要阐述毕博对某银行IT 战略的建议。2.2 对某银行 IT 战略的建议某银行需要开发稳定的 IT 战略。在这个过程中
17、，需要将业务战略所需的 IT 环境与现有的 IT 环境进行比较，从而识别目前的 IT 环境多大程度上适应业务战略，然后识别差距、开发能弥补缺陷的 IT 战略、确定 IT 的工作方向，以启动 IT 战略的实施。11毕博的方法论认为，完整的 IT 战略包括以下五个方面：1) 应用服务战略2) 数据管理战略3) 基础设施战略4) 体系架构战略5) IT 组织和 IT 管制方式的战略其中“IT 组织和 IT 管制方式的战略”不在本项目的范围内。在本项目的进行过程中，随着对某银行业务战略和愿景认识的深入、对某银行 IT现状的深入，毕博建议以下的 IT 战略作为全行的 IT 战略2.2.1 应用服务战略1
18、) 充分利用现有系统的功能和潜力2) 最大程度地使用自动的工作流管理优化应用系统的客户服务能力和效率4) 在全行逐步实施业务规则管理创造一个稳定、可扩展的开发环境2.2.2 数据管理战略1) 实施管理信息/决策支持2) 提供操作型和分析型的所有客户信息3) 逐步形成全行的一致的数据储存技术和数据储存方式2.2.3 基础设施战略1) 将全行 IT 规划、开发和管理的过程规范化2) 需要开发完整的营运维护方案2.2.4 体系架构战略1) 规划和实施银行应用体系架构2) 规划和实施银行数据体系架构3) 规划和实施银行安全体系架构4) 规划和实施银行技术体系架构122.3 应用体系架构设计中的关键点本
19、节所述的关键点，既是某银行 IT 规划中所应处理的重点业务或技术问题，也是毕博对整个规划的设计的基本起点。在介绍整体的应用体系结构规划前，读者很有必要了解这些关键点。2.3.1 银行的核心业务系统按国际通行惯例，一般银行核心业务系统的分类较专针对零售银行、批发银行、信用卡（国际贷记卡）、投资银行等提供专用系统，很少有大一统的系统包罗所有的业务。这不仅体现在国际上主要银行的系统部署的实践中，也体现在国际上产品化的核心业务系统的分类上。道理很简单，因为业务的性质不同，所需的系统功能和技术架构会有不同的侧重点。举例说，零售银行一般面向的客户是个人和规模较小的商业客户，因此业务重点是临柜、ATM、电话
20、银行、小额支付等。由于此类业务的特点是客户和帐户量大、交易量大、金额小、需要通存通兑和 7X24 小时服务等，所以在考虑系统效率、数据储存、系统与渠道接合这些方面会是设计的重点。对批发银行而言，客户和帐户量与零售银行比较小，但交易金额是比较大的，所以系统的设计的重点在于交易的安全、交易流程的控管、资金结算的快速、资金管理服务的多元化、信贷风险管理的严谨等方面。从应用来说，范围包括对公存款、贷款、贸易融资、外汇、资金市场等。由于面对对公的客户为主，所以批发银行系统对于“7X24”的需求会稍低一点。至于信用卡系统，一般是独立于核心应用业务系统的。因为信用卡的发行机构不一定是银行，而且以这产品的特点
21、来说，信用卡户的额度完全基于个人的信贷能力，也不一定需要在银行有帐户。一般来说，信用卡系统分为发卡和代理经营两大类，所需的系统是业务代理系统和业务处理系统两大类。某银行的 DCC 项目规划，将核心业务系统 CCBS 规划为对私业务、对公业务、卡业务、代理业务、理财业务、证券和保险业务的大一成的系统，这既反映了某银行对建设与数据中心的宗旨相一致的核心业务系统的决心，也反映了某银行对企业应用集成技术（EAI ）（EAI 技术，请参见本节第三段的论述、本文的正文论述和附件的介绍）的使用尚不熟练。13基于此，毕博对某银行的核心业务系统的规划的基本点是：CCBS 将本外币的对私和对公金融产品的帐务处理、
22、操作型客户关系的处理、对私金融的业务流程、核算和帐务体系集成为一体是可行的也是合理的。其它类型业务的核心系统，考虑另建或另购系统实现，并通过信息总线连接起来，成为逻辑意义上的大核心业务系统。核心业务系统除了所提供的金融产品外，该系统的核心机制也是很重要的，毕博专门对该机制的国际最佳实践作了介绍，希望对某银行的 CCBS 系统的开发有所帮助。2.3.2 客户信息的管理 不论是什么类型的系统，银行现在都会相当讲究如何配合客户关系管理的观念、怎样推进“面向客户、面向管理”，以协助银行去管理和挖掘客户和产生新的高盈利的业务。现在国外银行的应用系统都强调支持中央客户信息，每个客户在银行系统内都是一个唯一
23、的个体，而所有客户的信息都是与所有的业务应用子系统共享，确保银行的每一个用户都可以基于自身的权限看到客户的所有资料，从而提供更集中的控管和优质服务。所以一个设计优秀的客户信息系统是现代化的银行系统的一个非常重要的基础。 国外银行的客户信息比较注重怎样支持业务营销、客户关系管理、风险管理等各方面的需求和应用，因此客户信息的定义会根据数据分析（MIS 、DSS 、CRM 等系统）的需要而增加了许多数据项，并让用户在有需要的时候新增自定义字段。这个对于未来的管理信息、决策支持、商业智能等系统来说是一个非常重要的铺垫，没有充足、一致的数据来源，再好的数据挖掘和分析工具都是派不上用场的。而且基于以客户为
24、中心的结构，系统更容易提供综合理财类的新兴业务和综合对帐单等。本规划是完全基于以客户为中心的设计思想，因此必须有 CIF 系统的支持。从目前银行业的发展趋势来说 CIF 系统应该是一个独立的统一心系统，其它系统应该只是通过标准接口使用该系统。但某银行的 CIF 系统的建立已由总行统一规划和实施的 DCC 项目所包括，是 CCBS 核心业务系统的一部分，毕博尊重这样的决定。无论 CIF 系统以何种方式存在，全行其它系统只是通过与 CIF 系统的接口去访问CIF，而不需要建立自己的 CIF 系统。以下是我们某银行 CIF 系统建立的一些建议。14考虑到某银行客户规模这么大，客户种类繁多的银行的中央
25、客户信息，如何在总分行的结构下存储和使用，以怎样的步骤进行实施，和其它系统及信息总线的关系是什么，也是本次应用体系结构规划的总要内容。规划的详细内容见第章操作型客户关系管理。2.3.3 企业应用系统集成（EAI）银行的应用系统，无论先期规划得多么有远见、项目执行得多么有出色，终究会出现 IT 应用及基础设施不能满足日趋迅猛的市场变化的需求的现象。遇到这种情况，国际上最佳实践的银行往往首先奉行整合的技术路线。他们将使用系统整合技术，挖掘现有应用系统的潜力作为第一选择，这就需要使用 EAI 技术。毕博建议某银行全面、系统地使用 EAI 技术，来联系横贯整个企业的异构系统、应用、数据源等。EAI 是
26、将进程、软件、标准和硬件联合起来，在一个企业内或更多的企业系统之间实现无缝集成，使它们就像一个整体一样。EAI 通常表现为对一个商业实体的信息系统进行业务应用集成，或者是为不同公司实体之间的企业系统集成。由于 EAI是建立一个灵活的、标准化的企业应用底层架构，可以允许新的基于 IT 的应用和商业处理能够更容易和更有效的被部署。EAI 涉及到结构、硬件、软件以及流程等企业系统的各个层面：业务过程集成应用集成数据集成集成的标准：要实现完全的数据集成，必须首先选择数据的标准格式。集成的标准化促成了信息和业务数据的共享和分布，构成了企业应用集成的核心。平台集成：要实现系统的集成，底层的结构、软件、硬件
27、以及异构网络的特殊需求都必须得到集成。平台集成处理一些过程和工具，以保证这些系统进行快速安全的通信。15在 EAI 技术的支撑下，现有的应用系统在全行的范围内成为了特定的功能模块。例如：对于金融市场上利率和汇率的信息，银行的资金系统、信贷系统、管理信息系统中的 ALM 管理、财务会计管理等都需要这类信息。银行一旦建立了市场数据汇入接口，就不必为所有需要此信息的系统都安装接口，而可以通过将数据接口视为全行的标准功能模块，将其挂接在今后的信息总线上，供各个系统共用。通过进行 EAI，银行可以建立系统整合的基础，从而在业务上获得下列好处：1) 业务流程标准化、自动化、流程化利用 EAI 产品的自动化
28、能力，确保业务流程管理（BPM）得到清晰的划分，局部的变化不再对企业整体运作造成影响。随着某银行各项业务变革的深入，参照国际先进模式，为提高业务操作的效率和效果，或进行前瞻性业务流程改造，对现行业务流程的变动将越来越频繁。如果对支持这些业务流程的系统直接进行更改，系统开发的周期、成本和风险都是相当可观的，并且会拖延业务变革的步伐。通过EAI 的 BPM，将原有系统所支持的基本业务操作单元视为全行的通用标准模块（如支付、账单处理等），在标准模块的基础上配置新的业务流程，全行系统的灵活性、有效性将得到极大的改善。2) 集成的，基于 WEB 的基础设施和通用用户体验银行可以对后台系统的数据传输进行控
29、制，并在基于 WEB 的企业门户中显示这些信息。3) 降低系统实施和运作的成本EAI 架构能够更加灵活地根据战略市场转移添加或者改变业务能力，同时在现有系统中对数据集成进行有效的管理。4) 降低对于多个系统的依赖银行可以对那些功能和数据重复的系统进行有选择的淘汰和整合，从而降低旧有系统的人力操作成本。通过进行 EAI，某银行可以在技术上获得下列好处：EAI 解决方案带来的技术好处主要是建立在这样的一个事实之上：该架构是可以重复使用的，具有很高的升级性和可配置性。它结合了以下的能力：1) 方便地集成新的组件和系统；高度集成的工作流引擎，可以实时地对面向客户的业务流程中的任何事务进行有效的管理和监
30、控；通用消息总线，在应用系统之间传递消息；16通过连接器将分散的应用系统整合为一个单一、有效的事件驱动系统。在数据大集中和大前置建立后，根据所选用的形式不同，这时应该规定哪些数据保存在中心数据库中，并制定相应的交换格式和交换方法。由于这些与所选择的方式以及以后的某银行信息总线有很大的关联性，甚至有可能与未来的某银行信息总线融为一体，所以这里不详细展开讨论，而在下面的信息交换平台中提及其可能用到的技术。在中心数据仓库逐步建立后，我们应该建立与之相配套的各种系统，例如客户信息系统，对中心数据库进行挖掘分析的系统、信贷系统、风险预警、国际结算等等，这些系统的建立与后面的某银行信息总线所采用的技术有很
31、大的相关性，总而言之，必须能够与某银行信息总线很好地互连。2.3.4 管理信息系统某银行使用管理信息系统（MIS）一词，主要指的基于数据仓库技术，面向不同的银行管理主题的，对集中的业务数据和其他银行内/外数据的综合分析、处理和应用的系统。在本规划中， 管理信息系统被划分为分析型客户关系管理系统、管理会计系统、信贷风险管理系统、资产负债管理信息等系统。（其中信贷风险管理系统和信贷业务系统的关系紧密，一同在第章中论述）我们对管理信息的这种划分，直接和某银行业务体系架构最佳实践相对应。由于总、分行之间的管理职能有所不同，总分行管理信息系统对数据的要求也随着不同的管理需求有所不同。此外，由于越来越多管
32、理决策需要详尽的、多维的支持信息；同时也要求管理信息系统能具备一定的分析预测和知识发现能力。2.3.5 合理的应用系统功能国内银行应用系统的开发经常发生的问题是：或者因为应用系统的需求来自于某个业务部门的业务操作和管理的需要而没有全行视野；或者需求没有前瞻性；或者作为需求的提出者的业务部门和作为需求实现者的技术部门的沟通问题；或者对国际同行同类系统的信息或参考不够，导致应用系统功能不足。对某银行而言，这种案例很多，例如：养老统筹系统、计算机设备管理系统、离休干部信息管理系统、机构信息系统等一批小型的企业资源管理系统，在功能上都属于 ERP 系统的范畴，不应独立开发、互不关联；信贷审批系统、信贷
33、管理信息系统（CMIS），股票质押信息系统、坏帐核销系统、信贷清分系统、抵债资产系统等，在功能上都归属于全面的信贷业务管理和风险管理系统的范畴（参见）。17本次某银行 IT 规划的重点，在应用功能的规划上。虽然对银行信息总线的规划，是解决某银行系统功能割裂的问题的一个方案。但如何使某银行的各个应用系统的功能逐步具备完备性、前瞻性依然是主体问题。为此，在讨论某银行 IT 规划主体方案（第三章）的基础上，本规划，从第五章起，详细介绍了国际先进银行的各个应用系统的具体功能要求，供某银行参考。2.3.6 数据分布模式银行保存大量的数据包括业务数据以至统计分析性的数据，也运行很多不同的系统（如业务处理系
34、统、ATM、POS、客户服务中心、各种基于数据仓库技术的 MIS系统等）。在毕博建议的 IT 规划中，不是所有的数据都存放在总行或区域数据中心。某些数据（包括业务数据和统计性数据）可能需要存放在分行以至网点的服务器中。数据存放在分行或网点可能是因为这些数据纯粹是本地的数据而没有存放在总中心或区域数据中心的价值；也可能是为了提高交易处理效率；也可以是为了在系统离线时（与总中心或区域数据中心通讯断掉）进行必须的业务处理。银行的数据从种类可以分为系统数据、业务数据和管理数据；从地域方面可以分为全行数据与本地数据（分行、网点）。在本次规划中，总数据中心或区域数据中心与灾难备份中心保存几乎所有的系统数据
35、、业务数据，也包含总行层面的数据仓库与其他后续系统的数据。在分行层面主要保存系统数据和本地业务数据，部分的本地业务数据也会存放在总数据中心或区域数据中心。在分行层面还保存了部分存放在总数据中心或区域数据中心的业务数据，主要的原因是在于提高交易的预处理能力，减小传送主机的交易量及通讯量。如柜员在柜面终端键入了客户号或帐号时需要马上显示客户或帐户姓名，以方便柜员核对的话，该等数据存放在分行是可以更快的把资料送到柜员终端，也不需要到主机提取。原则上，这些数据是不应该经常改动的。但当这些数据被改动时，分行保存的相关数据也应该同时被改动以保持数据的一致性。但帐户余额等敏感就不应该存放在分行里面，以减低银
36、行所面对财务风险。由于部分系统的静态数据是同时存放在数据中心和各个分行的，所以需要制定一套数据同步的过程，建议是在每天的日终处理后联机交易开始前进行静态数据的同步。这个时间点也是分发新的程序到每个分行的最佳时机。保证数据同步的另一套机制是依靠某银行的信息总线，详细情况可以参看本规划的第章。182.3.7 应用分布模式某银行是通过不同的系统来完成所需的操作（包括业务处理和后续的其他处理）。银行在实施集中以后，不同的应用将会分别运行在总中心，区域数据中心，分行以至网点。决定各个应用运行的地点取决于几个条件：应用的性质（本地应用或全行应用）、使用数据性质、接口系统要求等等。某银行的应用应该是按该应用
37、的特性分布在不同的中心、地方。例如：总数据中心或区域数据中心是运行核心业务系统的环境，也是总行 MIS（即数据仓库、决策支持系统和商业智能系统）运行的理想环境，因为这些系统都需要全行的数据。网上银行的用户可以通过互联网来进行操作，也适宜在总数据中心运行。由于手机用户的流动性，手机银行系统也应该在总数据中心运行。因为客户关系管理(Customer Relation Management, CRM)系统需要管理分布在不同分行的集团客户，也建议在总数据中心运行。由于一级分行是连接总数据中心的枢纽，其地位非常重要。在大集中模式下分行的角色在起了很大的变化，所以分行需要考虑一个很完善的“大前置”系统来负
38、起与总数据中心、本地系统、支行/网点与本地其他金融机构的通讯连接。在后面会讨论到“大前置”系统的基本功能要求。ATM/POS 是比较适合在分行里面运作，主要的原因是这些系统都需要跟本地其他金融机构(如金卡)的系统联系。银证转帐系统也需要跟券商进行通讯而比较适合在分行运作。中间业务平台也是需要很多的本地通讯功能，在分行运作是比较理想的。电话银行和 Call Centre 系统就比较适合在分行运作，主要的原因是在于中国地方比较大，所使用的方言也比较多，很多时候拨近来的客户不一定很懂普通话，在分行运作对总体操作有好处。操作员也能够更亲切的提供优质的服务。但有些银行倾向把电话银行和 Call Cent
39、re 系统在总数据中心里面运行，这也是可以的，但需要解决了语言方面的问题，譬如电话银行除了提供普通话的服务外，也可能需要提供其他多种常用语言(如广东话、上海话、四川话、潮州话等等)的服务。Call Centre 由于是客户与操作员的直接对话，懂得当地的语言与俚语是比较理想的。分行里面的报表生成系统是指在实施了集中处理后在总数据中心或区域数据中心可能会把很多的业务数据下发到各个分行，以便生成所需的运作报表。总数据中心只传送原始数据会减轻网络的传送量，也让分行更有弹性来生成本地报表。如果银行的策略是在总数据中心生成所有报表后发送到分行打印的话，则分行的报表系统只需要具备接收、打印和重打功能。19支
40、行、网点当然只需要运行柜面系统，也可能需要接收从分行送过来的报表进行打印。2.3.8 应引起关注的技术问题和技术管理问题本次 IT 规划的主体是系统的应用体系结构和应用功能规划，不着重于系统的各项技术问题。这里我们简要的强调一下应用体系结构下，个个应用系统在开发和实施过程中应注意的技术问题和技术管理问题。某银行应该努力使得各个应用系统在以下的技术特性上，达到最佳的综合分值：1) 系统的安全性2) 系统的适应性适用于多种软硬件平台3) 系统的扩展性模块化和参数化4) 系统的稳定性、可靠性、可用性5) 系统的开放性相对稳定的核心与不断丰富的外围功能的统一6) 系统的配置灵活性7) 系统吞吐量8)
41、系统效率9) 系统的可维护性某银行应该努力使得自己在各个应用系统的开发过程中，逐步做到：1) 一致的开发平台和开发工具2) 一致、成熟的软件工程方法3) 一致、成熟的软件过程方法2.3.9 IT 规划的管理机制问题要使 IT 规划能长期的起到反映业务的驱动力、指导 IT 开发和建设工作的作用， IT 规划本身需要得到长期的维护，以反映最新的业务环境的变化、某银行业务操作能力的变化、某银行 IT 系统的发展所带来的变化等，对全行的应用系统所带来的不同需求。20这需要某银行有一套成熟的 IT 规划的管理机制，这套机制的几个要点是：1) 在 IT 规划部门和各个业务和技术部门充分沟通的基础上，确保被
42、普遍认同的 IT 规划，能对全行的 IT 工作起指导作用2) 跟踪和记录外部业务环境的变化、全行业务战略的变化、全行业务能力的变化和全行的应用系统的变化，及时评估这些变化的影响，特别是对应用系统需求的影响3) 除了定期（建议以一年为单位）审视、修订和完善本行的 IT 规划外，但发生重大的内外部环境、战略或能力的变化时，适时修订 IT 规划4) 需要行级领导和 IT 主管领导的大力支持、适度介入，并给于方向性的指导和合理的资源配置的保证5) 成熟的 IT 规划方法论6) 合格的 IT 规划人员和 IT 规划团队，对团队成员要仔细甄选213 应用体系架构的整体设计3.1 应用体系架构的整体设计图这
43、是毕博对某银行 IT 应用规划的整体架构。22上图中，蓝色代表核心业务体系中的关键应用系统。核心业务体系的范畴和某银行正在进行的以 CCBS 为核心业务系统的 DCC 规划的范畴大体相仿。但在局部上的考虑，二者有所不同。红色代表某银行的总行和一级分行的信息总线。绿色代表除核心业务系统以外的，某银行的其他关键应用。这些应用往往有自身的体系结构，其服务器和客户端分布在总分行。黄色代表某银行的对外接口部分，大体分为五类：外联交换型接口、终端驱动型接口、增值服务型接口、中间/特色业务型接口、全国性业务接口。总行的核心业务系统以外的其他关键应用，在物理上存在于某个数据中心里，但在逻辑上属于总行层面。总行
44、和数据中心业务职能的不同决定了它们各自所辖系统的功能的不同。3.1.1 应用体系架构中的系统功能和全行的应用需求的对应关系应用体系架构中所涉及的系统，其功能应该涵盖第一章中总结的某银行的各类应用需求。本规划中，这个对应关系如下表所示：系统名称 所实现的业务需求 备注面向客户提供各种金融产品和服务，包括零售银行业务、对公银行业务和卡业务等大部分对公业务，在核心业务体系只完成账户处理部分。银行提供金融产品和服务的分销渠道的运作核算和帐务体系核心业务系统体系营运风险控制体系，包括柜员管理、额度管理、业务处理流程的规范、内部审计等结算处理清算处理现金管理票据管理外汇处理23系统名称 所实现的业务需求
45、备注柜台业务处理流程对外接口的处理操作型的客户信息管理信贷业务管理信息系统和信贷风险管理系统贷款业务操作和信贷风险管理资金业务系统 资金运作全行 ERP 系统 企业基本资源的管理，包括机构、人力资源、采购、营业性费用等方面的管理全行办公自动化系统办公的自动化电子档案管理系统档案的电子化管理资产负债管理和市场风险管理MIS 系统财务管理中的银行管理会计客户关系管理系统银行客户关系管理 本规划中，将分析型客户关系管理系统归为 MIS 系统投资管理系统 投资活动的营运和管理全行个人理财系统个人理财金融产品的管理营运和管理证券业务系统 证券业务金融产品营运和管理保险业务系统 保险业务金融产品营运和管理
46、24在本章应用体系架构的整体说明中，只阐述这些某银行今后的关键应用系统在应用体系结构中的地位和相互间的主要关系。这些系统的具体功能，是本次规划的主体内容，也是应用体系架构之所以包含这些应用的原因所在，同时也体现着本规划“借鉴国际先进经验，前瞻性、合理的规划应用系统功能”的原则。各个关键应用系统的具体功能规划，从本文的第五章开始，逐个做详细的介绍，我们称之为各个应用系统的目标功能模式。3.1.2 对核心业务系统体系的说明核心业务体系，从逻辑上可以视为一个大的应用系统，并与总行的信息总线相连。核心业务体系中的系统，包括某银行 DCC 项目规划中所提论述的 CCBS、大前置系统、各个前端系统以及设备
47、前置接口。25和 DCC 项目规划的认识一致，毕博认为：在全国所有 38 个省市分行全部集中以后，北京和上海两个数据中心，以及今后可能会规划的更多的数据中心，在逻辑上可看作是一个数据中心。在数据中心的前置系统中，目前的清算和龙网均已消失，重要客户系统可能保留部分管理信息。某银行系统全国范围内实现通存通兑处理，总行的资金部门可实时理解各个分行的资金头寸的使用状况，实现实时的头寸管理和资金调度。省市分行的大前置机所连接的外挂系统有银联接口、电话银行、ATM/POS 等自助设备的前置机。 毕博建议的某银行的核心业务体系的架构，在以下几方面和某银行的 DCC 规划有所不同：1）接口的处理方面引发大量业
48、务交易的接口，即终端驱动型接口、增值服务型接口，因为在目前的情况和实际应用中，由于要保证大前置的效率，所以需要的是快速反应，所以我们应该单独从专有技术例如 TP Monitor 来实现。其他的接口，即外联交换型接口、中间/ 特色业务型接口、全国性业务接口，强调的接口的公用性和集成性， 应该挂接在总分行的信息总线上。2）对公业务：对公业务的操作流程，如信贷的审批、拟定、放款、管理和不良贷款的清收；票据业务的处理流程等，不在核心业务系统体系中实现。核心业务系统体系只实现对公业务的账户处理部分。3）操作型客户信息：操作型客户信息的各项内容，应该由首先由开户的分行管理，包括客户基本资料、客户组织资料、
49、帐户信息、权限信息、和关联信息等。这里需要指出的是客户帐户信息包含客户交易往来帐户信息，其内容包括客户转帐的对方帐户、客户分公司的帐户等。操作型客户信息采用分布式存储的优势在于客户信息的易维护性，客户的信息修改、更新由开户行完成，不存在数据不一致性的问题。同时，如果在客户登录合法性校验的过程中，如果每次与操作型客户信息相关的请求都要送到数据中心进行客户信息的检查或查询，明显地会加重了网络返回负担。客户信息的同步问题，可以借用信息总线技术实现。具体的实现技术和实现，可参见第七章信息总线中的论述。263.1.3 总行层面的系统总览在业务体系架构中，总行层面的主要业务职能是：业务运作管理、客户关系管理、金融产品的开发营销和管理和信贷级市场风险的管理。相应的，总行层面的系统，包括全行的关键的应用系统的主机。核心业务体系的主机CCBS 核心业务系统，虽然位于各个数据中心，但由于各个数据中心的逻辑上的一体性，实际也是总行层面的系统。总行系统还维护着证券、外汇清算、路透牌价、国际卡、SWIFT、国际合作伙伴接口这些是真正独立于核心业务系统而存在的外挂系统，而这些外挂系统应考虑挂接在总行的信息总线上。3.1.4 一级分行层面的系统总览27分行的主要系统是总行个关键业务系统的本地服务器或者客户端。在核心业务系统体系中，分行的大前置系统要负责本地渠道的交
