谈谈银行核心系统建设--篇2：核心系统的需求定义

文章来源：e路向上，文章仅供个人学习

“一艘没有目的地的航船，任何风向都是逆风”。要做成一个项目，三个方面的工作准备和能力建设是必不可少的，它们分别是：需求定义–“define what you want”，定义清楚项目要达成的目标； “know how” –知道如何将项目目标进行子任务分解，完成总体设计和子系统的设计，为项目做好必要的组织设计；“enable”–将分解的子任务逐一实现。其中，需求定义是任何复杂工程或科研项目的基石，其重要性体现在对目标的精准锚定、资源的合理配置以及执行路径的科学规划上。要对新核心系统建设的需求进行定义，首先就要回到为什么要建设新核心这一根本性的问题上来…

当前核心建设的动因

新核心的建设，通常需要大笔的投资，因此也就常被董事会、管理层寄予厚望：希望核心系统的建设能带来科技能力的跨越式发展，实现效果更佳的科技赋能等等。但实际上的业务价值或许不尽如人意的巨多，核心系统的特点决定了面向一线的经营单位基本不会有特别的感觉，而中后台的集中作业、网点柜台，体验和效率好不好，跟系统本身的技术指标好不好、技术栈先不先进关系不大，体验和效率有没有大幅度的改善，取决于新核心建设的过程中，有没有好好进行体验设计和流程重构：将人工作业转为机控作业，提供更好的查询入口、更好的交互设计、大量减少纸质流程等等。

与2000年前后的大集中核心建设时期相比，08年之后直到当前在进行的换心项目，在业务价值上都面临越来越大的挑战。原因不难解释，最早一代的核心建设，是从无到有，实现了全行一本账、全行统一的作业流程、将区域性的数据孤岛进行了打通，将大量的手工账变为了系统自动处理，在全行内实现了通存通兑，并为各种报表的产出铺平了道路，其业务体验前后对比十分强烈。而大集中之后的核心建设，其建设动因，很多时候并不完全因为业务价值驱动，而是加入了大量的业务不易感知的技术因素，常见进行新核心建设的原因有：

旧系统事故频发，行内IT团队和供应商无法进行有效优化，银行上下苦“心”久矣。这种情况下，银行管理层通常会考虑另请高明，从外部引入IT高管来彻底改变这一局面，而新任IT线的高管改变这一局面的最好办法，就是更换核心，彻底甩开历史包袱，以项目为抓手，重建人才队伍，实现对新核心的自主可控。

旧核心无源码，导致运维风险增加、需求响应缓慢、****开发成本高企。部分在核心系统建设时，没有提出提供源码请求的银行，通常面临这一困境。其一，监管机构对IT外包监管有个原则，即“工作可以外包，责任不能外包”。但在没有源码时，承担主体责任就只能是一句空话；其二，没有源码时的脖子，几乎是想怎么卡就怎么卡，1个人月可以做完的工作，跟甲方要10个人月如何？除非业务不想做了，不然最后的结果就只能是乖乖就范。长此以往，在忍无可忍的情况下，甲方需要考虑核心替换。

旧核心运行多年，系统在功能和性能方面都开始显得吃力，需要进行升级替代。有些银行的核心系统运行多年，一方面早期系统缺乏在客户统一视图、产品、定价、费用、机构管理等方面的统一规划，很多好的设计理念要引入旧系统，改造量及改造风险都很大；另一方面随着业务量的指数级增长，系统在高并发支持等方面，受限于此前的设计，也显得力不从心。这种情况下，有可能以核心建设为抓手，发动一场大规模战役，从根本上解决问题。需要说明的是，从纯技术角度看，只要有源码，功能和性能就都有替代解决办法，比如功能通过逐步迁移改造，性能通过应用优化、服务器扩容等；但从组织动员、获得必要的资源支持等角度看，最佳策略仍是建设新核心–吸引全行关注，保证资源投入。

核心技术基座的升级。信创与国产替代背景下，适应新的技术发展趋势，以云原生+分布式架构+微服务为主要特点的新核心建设。这种模式下的新核心建设，技术因素是主因，在建设过程中，一并解决一些业务问题，反而是项目产生的附加值。这种模式下，更需要在项目启动阶段，向业务单位说清楚打算解决的业务问题，将产生的业务价值，不然，单靠行政命令，而不能与业务单位同频共振，赢得支持，项目推进过程将困难重重。

以上几点，只是常见的启动核心建设的动因，一般来说，一家银行启动核心建设，通常不会是单一因素，很可能是多种因素的共同作用，但不管是何种因素，可以看到，新的核心建设，其源动力很大一部分在IT本身。了解为什么要做这件事，对后面去定义这件事要做成什么样非常重要，因此我们先大致做个分析….

核心建设面临的风险因素

钱老在《工程控制论》中曾提出过”前馈控制”思想，在需求定义阶段即进行风险预判。银行核心系统建设，与导弹工程、航天工程等复杂非线性系统相比，基本不存在进行技术可行性验证的必要性，也没有技术路径选择的困难，银行核心系统的技术复杂度，不论是开发式核心，还是分布式核心，都可以认为不存在技术风险。在实施能力部分，市场主流集成商的核心系统的实施与集成能力、经验，也不构成实施风险。可能导致核心系统建设风险的，主要在于需求定义，需求定义不清晰可能导致的问题，一是在项目建设期间，中途出现大范围需求变更，由此带来新的开发和测试工作，影响项目建设计划，更有甚者，甚至直接影响投产计划（比如数据迁移时间过长导致无法如期回复对客服务）；二是系统投产后，有线上的客户需求在建设过程中未被覆盖，导致上线后系统提供的服务不及预期；三是技术指标定义不清晰，导致特别关键的系统性能指标、批处理作业时间等不达标，影响对客服务稳定性。总之一句话，需求定义不清晰，相关分析工作不充分，因此而导致的项目过程中，出现大范围的需求变更，造成建设周期偏离计划，出现超支、延期，或上线后建设成果不及预期的风险，是核心系统建设过程中的最大风险。“凡事预则立，不预则废”，对主抓核心建设的关键管理者而言，抓住了需求定义，项目便成功了一半。

核心系统的需求定义

做核心系统的建设，名义上是核心，实际上决不可只关注核心，核心系统的特点和其在全行系统架构中的定位，决定了核心系统的需求定义，至少要关注到五个大的方面：一是与核心相关的全行企业级治理体系相关的需求；二是新核心系统承载的本身的业务需求；三是新核心系统对周边系统的影响；四是新核心本身的技术指标与需求；五是新核心采用的技术栈对全行技术架构演进的影响。我们逐一简单谈谈：

与核心相关的全行企业级治理体系****相关的需求。包括但不限于以下命题：统一客户视图、产品管理、收费管理、定价管理、机构设置。其中，统一客户视图需要在新核心建设中被考虑内部包括但不限于：统一客户视图的建立和存储、哪些系统和场景可以修改客户信息、客户信息的哪些要素允许被修改等等；产品管理则涉及全行统一的产品目录的梳理、产品定义、强制统一还是允许分布、产品工厂的建设等等；收费管理涉及核心相关的费项、收费模式、减免规则等的定义，对收费的控制–比如收费必须关联客户、账户或者债项（以用于计算客户的综合贡献度）；定价管理涉及利率、汇率的发布、更新、与使用机制，特别是客户优惠利汇率的抽象与设定、利汇率风险的控制等等；机构设置涉及全行机构在核心系统的层级定义及关系维护等等；这些命题中，提供核心的厂商一般都会自带客户信息管理、产品工厂、费用工厂、定价与机构管理等服务，但其着眼点只是面向核心本身的，在核心系统建设时，如果行方不做企业级的梳理与设计，并不会影响项目的推进，但从全行业务治理和架构设计的角度看，都殊为遗憾，尤其是这些底层设计，会影响到后续客户贡献度计量、产品设计时的灵活定价、部门间准确的收益分配等一揽子业务诉求。

新核心系统自身承载的业务需求。这涉及两大体系、一类基础服务的需求定义。两大体系即“运营体系”和“账务体系”。核心建设时通常会伴生的一类建设通常包括统一柜面和集中运营体系的建设（流程银行），运营体系建设涉及到新系统中现金柜与非现金柜的设计、柜员管理、业务授权体系与模式的确定、各类交易涉及的影像的分类与归档、凭证的管理、现金尾箱的管理、日终轧账与流水勾稽等等，需要花时间逐一确定，其根本原则是：尽量减少纸质件，尽量减少线下业务流程的衔接。核心建设时另一项强相关的工作便是账务体系的重新建设，包括是否启用新的科目账账套，因应新的产品体系或者业务更为精细化的管理要求，是否设置新的账套，原来在旧系统没有机会解决的核算混用、不符合会计准则的问题（如应摊未摊）、错账、历史的挂账问题的清理等等，交易与核算分离，内部户的治理、会计账的对账规则、要求及对应的报表等等。事实上，新核心建设过程中，IT部门通常有两个强帮手，分别是运营管理部门与财务部门，这是项目的性质决定的（偏中后台），所以，IT部门与这两个部门在项目过程中做到同气连枝，是项目能够顺利推进的关键因素。除了两大体系外，还有一类基础服务，即账户功能的建设，账户功能建设，又可以简单分为3个层次，首先是账户体系的构建，即考虑在个人和企业活期结算户、储蓄户、定期存储户、内部户之外，根据业务的管理需要，是否需要将保证金账户、存放同业账户独立建设，个人结算户对二、三类账户的支持（不要再弄出来一个什么互联网核心）等等，这是一个基础性问题，需要思考清楚；其次是基础账户能力的构建，如开销户、多币种账户的支持、存入、支取、状态设定、久悬不动户的管理、计提、结息、7*24小时功能支持等等，这一块的能力在市场主流供应商的产品中都沉淀的很好，是最不需要担心的部分；最后是基于基础账户能力建设的银行自己的特色产品的需求梳理，比如定活通、存抵贷、法人账户投资、协定存款、智能存款、伞形账户体系，甚至现金管理等各家银行差别较大的产品，需要在需求定义阶段进行明确。

新核心系统对周边系统的影响。新核心系统对周边系统的影响，主要以交互方式的变化进行体现，这不仅仅包括各类实时接口，还包括：以文件方式进行交互的内容、对下游数仓及最终对各类计量系统的影响、7*24小时机制下不同系统与核心交互的时点、会计日期同步机制、以异步消息方式进行的动账通知等等。新核心建设中，为了屏蔽对周边系统的大范围影响，有一种做法是保持旧系统的接口不变，但一方面，采用分布式微服务架构的模式下，全局流水号在交易链路中扮演着重要角色，接口是不是真的可以完全不变，需要详细的论证；另一方面，如上节所述，如果账户体系发生了变化，比如保证金从结算户应用中进行了剥离，则信贷、票据、国结、外汇等与其强相关的系统，不可避免地要改变接口。其他几点内容，关键在于IT团队的设计，通过类似ACL的设计，来规避大规模的改造，避免核心系统建设的大范围影响。

新核心本身的技术指标与需求。一些关键性的技术指标，在核心建设启动时，必须进行评估和定义，如核心系统的交易处理能力，TPS（含QPS）的峰值能力设定为多少合适；简单交易（如一对一转账）的处理响应时间要求；系统支持的账户规模，数据库分片的策略（单库支持的记录数）；系统批处理要求的最高耗时目标；银行未来5到10年的客户规模和交易量增长及对应需要的系统交易处理能力预测等等。对应地，这会直接影响的核心的方案设计，甚至成本投入。以TPS为例，设计指标过低很可能造成投产第一天就系统瘫痪，设计指标过高则是浪费资源–做任何事都要考虑成本，至于怎么设定TPS合理，未来有机会再另文探讨。总之，技术指标在需求定义阶段，其实如业务需求一样，也要做好评估，并且有效传达给开发团队，这会关系到为达成技术目标，是否要引入一些新的设计，比如缓存，比如在批处理过程中对零余额账户的特殊处理，多线程，热点账户的专题解决方案等等。

新核心采用的技术栈对全行技术架构演进的影响。当下的新核心建设，已经逐步转向信创要求下，云原生+微服务+分布式核心系统的一揽子技术体系的建设，其中涉及的私有云服务器集群的搭建、K8S资源调度平台建设、分布式数据库选型、云原生devops体系建设、分布式微服务治理及分布式事务管理工具在银行内的标准化等等，对核心系统建设本身，以及云原生背景下的IT治理提出了新的要求，实际上是一次新的IT蓝图构建，在核心之外，还有很多其他的各类异构系统，这些系统未来如何在同一套技术栈下进行重构，包括IT团队人员结构优化和能力的建设，都是需要考虑的重大命题。

除以上大的几点外，新核心建设通常还会带出来一些比较小，但是业务意义重大的问题，比如开户流程的优化，支持一键签约多类不同产品（综合签约），核心如何让账户交易记录中的交易对手交易摘要变得更准确等等。

总之，无论如何，将需要考虑的问题考虑在前面，做好需求定义，是核心建设有效实现成本管控、保证项目不大幅度偏离计划、顺利达成预期成果，取得良好业务效果的前提和保障。核心系统很难如产品类或渠道类系统一样，产生肉眼可见的业务价值，但核心系统及其关联的运营体系、账务体系，是银行经营的地基，这个地基打得越牢，往上生长的产品与IT能力，才越能够长袖善舞，为业务发展创造真正的价值。但这一切，都需要专业与负责人的人才队伍，下一篇，我们聊聊怎么识别项目中的关键人员，以及如何进行项目组织。