导读：10月29日下午，在2020年深圳市金融科技界（银行）行业交流会上，平安银行技术总监储量以《建设中台能力，助力开放生态》为题进行了分享。储量分享了平安银行进行中台建设的经验。

储量 平安银行技术总监

以下为演讲全文

01

银行业面临的挑战及应对策略

第一，用户行为发生改变。当前已经进入90后、00后主导国家经济活动的时代，他们对互联网工具的掌握程度高，更多依赖线上获取信息和互动。据有关数据显示，2019年人均手机使用时间是5.59小时。

第二，用户使用场景呈多样化，更多聚集在传统金融企业的外部生态。相比金融行业APP，用户的使用场景更多地出现在电商、新媒体、传媒、自媒体等，场景呈现多样化的趋势。

第三，用户不仅聚集在头部生态企业，在尾部的企业增速也非常明显。头部5000万-1亿级用户APP中，2019年上半年增速在10%左右；尾部的100-1000万级用户APP中，2019年上半年增速在100%左右，增速非常快。

金融业尤其在零售领域，如果希望占领客户心智，通过与客户进行频繁的互动做到KYC，就要思考如何利用外部生态来达到目的。包括平安银行在内，很多银行都尝试建商城，但很难形成很大的市场趋势，因为大部分客户会被天猫、京东、拼多多等占领。

反过来，我们要看建商城的目的是什么？其实目的很简单，就是利用优惠活动吸引流量；其次，再进行相对精准的画像描述，了解消费调性、理财调性从而获得更加准确的画像。同时，这些信息也可以通过与外部生态合作方共同经营获取，外部生态合作方需要流量变现的场景，金融则是他们最希望合作的。平安的策略是，不仅与规模大的头部平台电商合作，同时也广泛跟中小平台合作。

外部合作多样性主要体现在三个方面：一是合作模式多样化；二是合作产品多样性；三是合作渠道多样化。

对内，呈现另一种态势：

一是业务模式过度单一依赖。银行业是在牌照体制下的业务经营，对外部行业而言有进入壁垒，导致业务经营模式较为单一，不够创新和灵活。

二是银行产品复杂度高。固有产品服务体系成熟且复杂，导致银行很多产品系统复杂度比较高，不利于把关键能力快速包装出来并对外部提供服务。

三是内部运作效率较低。内部精细化的职能分工治理模式，高度依赖人的专家经验运作，导致难以高效、低成本地与外部合作，与生态对接。

这些问题该怎么解决？这是平安银行建设开放银行生态的原因。

02

平安银行中台建设经验

平安银行分四阶段：

阶段一：系统重构（2016年底-2017年），核心系统改造，自主可控，系统稳定性得到显著提升；

阶段二：技术中台和数据中台（2018年），建设技术中台，零售大数据平台和数据中台服务，敏捷开发模式建立起来，让IT交互效率变高。

阶段三：业务中台（2019年），通过智能化体系改造业务，通过零售AIBank项目，体系化建设11大业务中台能力，赋能480多个前台场景。

阶段四：开放银行（2020-）开始建立中台开放银行平台体系，进行外部合作对接。

这是中台三大组成部分（见PPT）：数据中台，技术中台、业务平台。

技术中台分为应用工具类和研发工具类。应用工具类，智能化公共服务、公共算法都是依靠平安集团的技术支持；研发工具，交付诉求必须靠自动化研发过程来实现，所以研发过程的工具本身也成为技术中台能力。业务中台，每个大的业务板块需要建立的中台能力。

数据中台，最底层是大数据基础平能力，这是大数据特有的基础架构的能力，也是底层大数据算法的工程化能力。大数据平台指的是有没有一套接近业内可以快速利用大数据开源组件的Hadoop能力。

其次是AI平台能力，这是为构建数据模型提供服务。举个例子，大量采购GPU集群需要有管理体系，包括要建立联邦学习的工具体系，和外部合作做数据对接时联邦学习能力不需要每次都要重新沟通、重复建设。还有包括决策引擎、区块链等核心组件都集中在基础平台，可以理解为是大数据和AI的基础架构。

数据治理很重要。银行真正想用大数据最大的障碍在于源系统和业务系统。要建立全行的大数据体系时，会发现最需要的是把每一个厂商软件背后的数据结构都了解清楚，这些数据最终能归整一起有效使用。比如最基本的客户信息管理，信用卡、借记卡分别都有客户信息，虽然有关联打通，实际上整合时发现字段不齐。如果数据治理做不好，数据无法整合，跨业务线使用就更做不到了。

数据安全，以前在数据安全或应用安全投入很少。安全团队要做的是合规，包括内部的合规管理、应用的合规管理、权限的合规管理。很多合规并非用技术手段而应是使用管理手段，这是很大的缺陷。最开始建设时如没有使用系统和工具保障安全的体系，信息泄漏的风险很大，包括钓鱼的风险。外部合作过程中也会有很多反欺诈的诉求，这正是信息安全要关注的，最重要的是要如何保证数据的安全性。客观来说，不能靠人工审核，要靠系统工具保障，按照原先定好的规则，通过系统进行系统风险防范。

数据治理分为几个阶段：第一阶段是做到数据覆盖；第二阶段开始建立数据标准；第三阶段是建立安全应用规则建立；第四是创造数据价值，基本上形成这样的循环。目前做到数据资产化率，资产化率是什么？全量数据库数据里面大概有60%左右是能够进入到大数据的标签体系，而通过标签体系能够对外输出产生一定的调用价值，我们称之为数据资产。资产化率，意思是已有一些业务利用这些数据标签产生价值，我们大概有60%的数据可以做到这一点。

数据治理做好后产生的效果是什么呢？以我们的指标系统为例，比如传统给行领导、分支行行长、团队长提供管理决策数据的系统，从需求澄清、数据探源、数据开发、报表制作、上线验收，需要12天的开发周期。我们建立指标系统进行指标沉淀和重用，越来越多的指标可以直接继承和拖拽，不需要重复开发，大幅缩短开发周期，譬如6天就可以完成交付。

又如知识库系统，现在都用智能机器人在线回答客户的问题。在这之前首先要想到第一个问题，过往沉淀在每一个总行、分行，某个层级岗位管理人员电脑上的红头文件、作业规则，怎么让这些信息从个人PC文档里变成系统化数据，所以我们建立了数据产品的知识库产品，专门把所有文档型数据结构化，这是一个耕地、种植、插秧、浇水、收获的过程。耕地，发动全行把原始数据、文档全部找出来；然后开始种植，就是插秧、浇水，持续呵护知识库体系，沉淀220万条知识；基于这220万条知识才能真正做到前台应用，我们得出来的效果，月均500万次知识调用，全都靠系统解决。

AI陪练，平安银行零售转型过程中，要短时间培养出一支经验丰富、运作成熟的团队非常困难，传统线下培训方式效率低、成本高，因此通过线上化的方式培训柜面人员、客户经理，把优秀的展业经验、操作经验变成剧本，通过线上化情景模拟方式，让所有队伍都可以进行一对一的模拟培训通关。目前已经已完成整个零售业务条线近4万人的覆盖，相比传统线下培训，周期由1个月缩短至1周左右，且实现100%的人员通关。

接下来是讲的技术中台，举个例子：智能语音平台。我们现在有70多个语音场景，完全由机器人完成与客户互动的语音场景，还有14个在实施过程中，每日的外呼量70万通电话，通话完成率大于70%。在建设过程中，最开始要投200左右的座席去做语音标注，不要想象今天智能语音找一个厂商的软件过来，就可以正式使用，因为在识别率和场景接入效率会比较低，一定是需要经过与内部业务场景的深度训练和结合的过程。如果每一个场景都做一次效率很低，我们当时是通过几个大的场景把完整的中台能力孵化出来，未来新场景接入效率可以变得非常高。

这是研发团队关心的，就是数字化、一体化的DevOps研发过程一体化工具。传统意义上的开发过程全部做到工具化、线上化，把它整合成一套完整的工具，而且把研发过程管控放在这个平台上能够实现。通过过程的管理，可以看出研发效率和研发过程中的质量问题，这是一个很重要的管理体系。最终可以发现一直延伸到发布管理、自动化发布，可以想象未来成熟的金融企业发布可以随时上线版本。这是我们未来要追求的，尽量让应用灰度发布。

最后是应用业务中台，这是最复杂的。传统意义上大家做业务，往往是一个业务场景做一套开发过程、实现一个功能，N个场景就要做N次。但当我们与外部合作时，每个合作方提的需求大同小异时，如果每个合作方都垂直开发，效率很低。怎么办？假设业务场景有很多种不同的组合方式，但是后台的某些关键能力是可被抽象提取的，只要做好组合定义，定义好系统之间的边界，就能通过快速配置就可以完成。这是我们需要做的中台能力。但是要做到这一点挺难的，只有部分领域做到了，为什么？我认为受面向过程的开发思维方式影响，缺少面向对象的思维方式，所以要去改造，这是我们接下来面对的挑战。

平安银行的业务中台从技术角度分两步：

第一步，核心系统重构升级。系统能够自主可控，具备快速迭代能力；内部可以用微服务的方式提供服务。

第二步，中台化NoCode，大部分业务逻辑可参数化、配置化、流程可自定义，领域建模，高内聚、低耦合，灰度发布，ABTest，确保未来可以快速测试验收。

平安银行正在全面向第二阶段推进。

以平安银行风险管理体系为例，它的每一个模块都快速自我迭代、自我测试验证不影响整体审批结果；其次，把多个场景通过统一的接口进行风险中台进行计算。我们认为个性化模块也可以用中台化的架构实现，于是做了这方面的重构，让风险管理越来越自动化，迭代效率也越来越高。

受今年疫情影响，我们在去年搭建了全行统一的催收平台，基本上所有零售业务催收都可以按照这样的架构进行标准化的作业和管理，大幅提升催收效率，基本上每一个新产品的催收接入，可以在1周内完成相关规则配置，经历 2周的规则验证后即可正式投产。

快站就是为营销活动开发一套完整的业务体系，让业务人员编排营销活动页面，把所有营销活动内容、广告图片、素材标准化，把营销活动规则全部都系统化，变成自动化的工具。到目前为止，我们自主创建了接近1万个页面，覆盖30多个业务领域，每个月营销活动流量达1亿。这个系统做到了所见即所得、可视化搭建页面、支持各业务组件，而且与业务系统结合紧密，高度共享，多渠道自适应，在各种小程序上都可以自适应，可以通过后台运营管理分析体系快速评估效果。

可以看出我们仍然在风险领域和营销领域中台化这两个领域数字化能力比较强，其他板块的能力建设也在持续完善。

在建立中台的过程中，我们认为存在四个挑战：

第一要做好中台，中台服务需要有职责清晰的组织治理结构，实现专业化管理和统筹规划。

第二，中台服务抽象边界的把握，要兼顾统一性和差异性。过于统一会阻碍业务的发展，过于差异又达不到中台共享的目的，这是技术人员和业务人员新的挑战。

第三，面向对象的抽象设计，需要经验丰富的应用架构师，但在这方面人才稀缺。

第四，中台上线后的持续闭环优化能力，中台最终体现的并不只是IT系统能力，还有业务运营能力能否固化至中台，使得业务场景不断丰富。这也是个很大的挑战。

03

中台建设的误区

第一，不是一场运动或者一个项目就能把整个中台建立起来。中台要持续支持前台，从前台业务中孵化，并根据前台业务的变化进行动态调整。

第二，仅通过行政命令方式，就可以把中台建设好。实际上还需要建立中台团队的治理结构。

第三，中台建设是不是迫在眉睫的事情？这是每个组织要想的问题。平安银行搭建中台，是因为假设生态化场景是我们的战略，这个战略的实施必须要有中台能力。

最后，千万不要理解做中台建设不投入，没有不投入就能产出结果。

以上就是我分享的全部内容，谢谢大家！

（来源：深圳市金融科技协会）

推荐阅读：

不是你需要中台，而是一名合格的架构师（附各大厂中台建设PPT）

架构设计和常见误区

超详细280页Docker实战文档！开放下载

PPT | 硅谷的数据中台实践

干货：数据中台的深度思考与总结

网易架构师朱剑锋：网易中台的博弈与演进

小米中台架构分享，小米市值2690亿是因为这群可爱的人