本文主要是介绍做足项目启动前的准备——关于核心银行系统项目建设实施的几点思考，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
一般而言，替换或建设核心银行系统之前，必须先要考虑清楚下面四个问题：第一是为什么要换核心银行系统？第二是如何界定核心银行系统范围，即做成“胖核心”还是“瘦核心”？第三是通过外购还是自行开发的模式建立核心银行系统？第四是如果选择外购方式建设，那么要明确外购的系统是跟随厂商的版本走还是通过消化吸收外购系统形成自身的版本？只有想清楚了上述问题，才能启动新核心银行系统建设项目。本文结合中国银行新一代核心银行系统建设的实践，谈一谈个人的体会和感受。为什么要换核心银行系统
要回答这个问题，我们必须明确核心银行系统的建设、业务流程的重组，和组织架构的调整之间是完全互动的关系。表现在：
在组织架构调整方面，比如机构的撤并，在银行兼并重组时，需要考虑是否用兼并行的核心系统替换被兼并行的系统，比如苏格兰皇家银行收购国民西敏寺银行时就采用了自身核心替换被收购行核心的做法，这是由于组织架构调整引起核心银行系统变动的典型案例。
在业务流程重组方面，银行做业务流程重组整合的过程中，可能会发现核心银行系统制约业务整合的要求，在这种情况下核心银行系统的替换就成为支持业务发展的必要手段。
在核心银行系统自身情况方面，银行经过反复审视、分析后发现，原有系统存在诸多问题，从自身系统需求角度讲，需要走向下一代的核心银行系统，这是从IT部门自我发起的挑战。
以中行为例，我们换核心银行系统的初衷要追溯到2003年，当时中行的数据主要集中在全国的五大中心，这样我们就面临了两个亟待解决的问题：一是中行必须要做全国的数据集中；二是怎样统一内部多个核心银行系统的版本。当时的境遇要求我们必须上一套新的核心银行系统，以统一原先的老版本，进而将原数据集中。因此，中行当时换核心的理由是很充分的，系统项目启动的动因也很自然，决策更加容易。
如何界定核心银行系统范围
目前，业界并没有公认的核心业务范围的标准定义，各家厂商所提供的产品和包含的业务范围也不一样。归纳起来，主要有“胖核心”和“瘦核心”两种说法。
笔者认为，“胖核心”对于中小银行来讲更为适用，核心功能的完整性更加重要，如果将系统切割过细，系统数量过多、范围过大，其建设和运营成本将会过高；而“瘦核心”对于大银行来讲更为适用，大银行的产品相对丰富些，核心应更专注于客户信息、账户管理，以及基本存贷支付功能。
但是，银行规模大小对核心业务范围划分的影响也并非绝对，还要结合自身的实际情况以及核心银行系统产品的实际功能来界定业务范围，核心产品中已经集成的功能最好能够被充分地应用。
以中行为例，核心银行系统业务范围包括：客户信息文件系统即CIF、账户管理、基本存贷支付功能。
选择外购还是自行开发模式
此话题也是业界争论的焦点之一。
自行开发的优点很明显，易于根据本行实际情况掌握产品开发的进度以及灵活地根据需求变化随时进行调整。但其缺点亦很突出，如果选择自行开发核心，则意味着必须要由业务部门提出需求并按其执行，这就导致开发出来的替换系统很有可能仅仅停留在目前行内业务的发展水平，不会有太大的提升和改进。举例来讲，国内银行业的上一代核心银行系统部分还停留在会计电算化的水平，即“会计即银行”的模式，以账务（会计核算）为中心的经营理念从银行后台一直延伸到前台，并不是强调客户交易或客户服务的处理，这种思维模式通过核心系统的展现已经根深蒂固。笔者认为，新一代核心银行系统的特点应该至少包括交易处理和会计核算相分离、前台后台相分离、全行一本账，而自行开发系统的模式将无法避免会计和业务部门的一贯强势所引发的系统建设导向问题，直接导致自建系统无法达到国际先进银行系统建设水平。
选择外购的优点及缺点同样明显。优点是，外购厂商的产品已经有多家银行的实施经验，产品本身也吸收并借鉴了很多国际银行的先进理念、做法和流程，这将对选型银行的内部经营产生深远影响。缺点是，外购风险较高，一是产品是否真正适合本行实际（与业务流程的差距有多大）；二是产品是否易于实施（一般厂商的开发能力较强而实施能力却较弱，大多会找集成商协助实施，而集成商对于原开发厂商产品的理解、与实施银行内部项目管理团队的配合默契度都是不确定的）。
综上所述，在新建核心银行系统时，选择外购方式的风险要高。从业界工、农、建三家大行来看，全部选择了“以我为主、自行开发”的模式，其原因也很明显，业内目前还很难找到能够安全支撑如此大交易量及产品数量的单一厂商系统产品。具体到中行来讲，我们希望通过外购的方式提升核心系统的档次，希望将新系统打造成为符合国际先进水平的新一代核心系统，将数据集中和旧系统版本替换两项艰巨任务合二为一，只有这样才能使系统实现跨越式的发展。
选择外购模式后怎么办
当外购模式确定后，要明确是跟随厂商的产品走，还是“以我为主”自己做，通过消化吸收外购系统形成自身的版本？
如果选择跟随厂商的产品走，好处在于可以随时享受厂商产品在功能方面的升级成果；而缺点是被厂商锁定后自身业务发展就存在不确定性，因为选型银行只是厂商众多客户中的一个，厂商会收集所有客户产品改善的需求，并根据自身产品发展的策略要求决定满足哪些需求，这就意味着选型银行的需求一定有不被接受的案例，而且实施时间也未必满足选型银行的要求。从这个角度来讲，本行业务发展进程受厂商产品策略的制约是在所难免的。
如果选择“以我为主”的方式，一方面继承了产品当前的优势，另一方面将业务发展的控制权牢牢掌握在自己手中。中行的策略很明确，购买厂商的源代码后，中行的技术人员进行分析了解、消化吸收，最终将厂商版本转变为中行自身的版本。这种方式在同业市场中已有先例，比如花旗银行、美州银行（BOA）在选型时均采用了Fidelity公司的 Systematics产品，但后来，两家银行都选择了“以我为主、自主开发”的模式。
从中行核心系统建设的全过程看，决策虽然顺利，但执行过程还是非常艰辛的。我们在2004年7月专门成立了“IT蓝图办公室”，2006年上半年选型工作才基本结束，历经近2年时间。产品选型一旦失误对银行的影响将是灾难性的，我们的选型过程非常慎重。我们的实施过程从2006年下半年开始，到2008年底，经过消化吸收中行对于该产品的掌握能力已经相对深入，因此从2009年1月开始，系统实施工作基本由中行为主进行实施。2009年10月，中行河北分行顺利上线，2010年我们用一年的时间完成了23家分行的上线工作，到2011年，我们将系统版本提升的同时计划完成其余分行的上线工作。最终实现全国范围内的核心银行系统的版本统一和全国数据集中工作。
作者：中国银行信息科技部副总工 邢桂伟
这篇关于做足项目启动前的准备——关于核心银行系统项目建设实施的几点思考的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
