银行业务中台建设
——业务设计方法
非常有幸能在这里跟大家见面，一起聊聊银行业务中台建设，本次选题主要围绕业务设计方法展开，以下愚见有不妥之处，请多多包涵，若能不吝赐教，甚是感激。
『初识业务中台』
先简单介绍下认识银行业务中台的“起承转合”。阿里于2014年参观芬兰游戏公司SuperCell，将 “中台”概念引入阿里体内；2015年互联网大厂刮起中台建设旋风；2019年金融界，尤其银行业内也谈架构必中台；市面上各种“中台”概念层出不穷，企业级中台、碎片化中台、技术中台、业务中台、数字中台、体验中台、AI中台等等。为了让自己也能跟着这股流行之风，将我们于2012年提出的“企业级业务资源运营管理”概念瞬间包装成“业务中台”概念，我们的解决方案与产品就此华丽转身。在此，先说说何为“企业级业务资源运营管理”，即“四中心一平台”，“四中心”分别是客户中心，产品中心、交易中心、核算中心，“一平台”是流程引擎平台；客户中心即为客户信息与客户关系管理、客户计价、客户营销、客户权益、客户联络、客户服务；产品中心即为产品创意、产品配置、产品组合、产品上下架、产品定价、产品促销、产品评价、产品退市；交易中心也称订单中心，即为订单创建、订单核准、订单计价、订单支付、订单交付；核心中心即为会计核算、管理会计、绩效管理；流程引擎平台即为面向客户业务场景的流程编排与面向银行内部管理场景的流程编排。乍一看，与互联网大厂的业务中台差异非常之大，只有寥寥四个中心。我的理解是，业务中台是基于分布式的微服务架构，以服务的方式进行发布注册，提供给消费者使用，所以无所谓几个中心或者几个应用，又或者几个系统，各中心都是按照一种逻辑关系聚合而成，切分粒度似乎也没有什么定论，随着业务复杂性与应用体量增大呈逐步细分的态势，后面有了碎片化中台的概念，也跟此相关吧。
『认知业务中台』
先说说中台、业务中台是什么吧。中台是企业发展到一定程度，现行的组织架构、业务架构、IT架构制约了多条业务线并行发展，为解决这一实际问题而提出的一种重新组织前台与后台关系的全新解决方案。中台大的来说可分为技术中台、业务中台、数字中台。其中业务中台不仅是共享能力中心，也是一种企业级上层场景应用的组件化开发设计平台，还是一种可配置、可拓展、可视化的企业级运营资源管理平台，更是一种基于企业价值链进行纵向分域横向分层的应用架构思想。
『话说企业价值链』
谈到银行业务中台建设的业务设计，首先，我想说的是，银行，尤其是商业银行也是一种盈利性的企业，与我们日常生活中所接触的企业并没有多大的区别，其区别在于银行经营的是货币，以货币交换获取利益（当然随着银行数字化经营管理能力提升，很多银行已经跳出资本经营，转向风险经营，更有甚者已经迈入信用经营，10月份上海陆家嘴金融峰会上马云老师也提到了信用经营）；普通企业经营的是商品，更多为有型商品，当然也有数字商品，比如游戏、电影、电子唱片、电子书籍、视听权益等等。那么它们又有那些相同之处呢？大家试想下普通企业的经营价值链，是品牌、采购、设计、生产、营销、销售、服务（售后）吧？当然还包括企业内部经营管理的风险、定价、核算与绩效，银行内部经营管理要复杂太多了，尤其是风险管理与定价管理，内部经营管理不属于对客服务，我们暂搁置一边不谈。大家再对照下银行的经营价值链是不是也是如此呢？从经营价值链的角度来看，它们之间的区别于生产环节不同，普通企业是按照设计好的BOM、工艺流程进行产品制造，以物流或电子形式交付；银行是按照设计好的程序进行账户开户、合约创建完成产品或服务交付。
基于对经营价值链的理解，我画了下图：企业运营示意图（看起来比较繁杂，原本是个PPT动画，能比较清晰的表达银行从产品创设，到上架，到客户营销、到客户选购、到客户支付、到产品/服务交付、到内部核算与绩效、到产品迭代优化的全过程）。
（图一：企业运营示意图）
『业务设计之顶层设计』
基于企业运营示意图的抽象，结合业务中台业务设计理念“纵向分域、横向分层”，我把“业务中台”按照业务价值链划分了20个中心，分别是渠道中心、用户中心、客户中心、产品中心、账户中心、营销中心、权益中心、限额中心、额度中心、风险中心、计价中心、支付中心、交付中心、订单中心、合约中心、调度中心、机构中心、员工中心、核算中心、绩效中心，这下跟上面提到的“四中心”又细化太多了，为什么会如此呢？我在接触广大银行客户朋友的过程中，他们看到之前的“客户中心、产品中心、交易中心、核算中心”，他们第一反应是对照某某行或者某某大厂的能力中心，就觉得我们做得少了；另外也接触到一些客户提出一些个性化的中心，比如限额中心、合约中心等等，所以我干脆一不做二不休，做了更为细致的划分，中心远比大厂还多。客户朋友第一眼看的感觉就是“哇，这么多中心，什么都有！”，然后再跟他们说，其实中心是把业务对象按照一定逻辑关系聚合而成，可以按照业务发展需要及系统复杂程度等因素自由选择、自由组合，他们也就更能理解与接受了。
眼尖心细的朋友可能会想“纵向分域、横向分层”是什么呢？纵向分域，是基于企业价值链划分边界，形成高内聚低耦合的业务能力中心，也就是共享能力中心；横向分层，是基于纵向分域的每个单一业务领域再进行横向切割，将业务中台的共享能力中心与业务场景应用进行横向隔离，面向多个业务场景应用的业务功能进行分类、聚合、归纳、抽象，形成业务能力，并下沉到共享能力中心，以实现底层横向打通，同时支持多个上层业务场景应用。
（图二：纵向分域示意图）
（图三：横向分层示意图）
基于“纵向分域、横向分层”的顶层设计，是属于企业级应用架构的范畴，所以除了梳理出核心业务领域、规划出关键业务能力中心，还需要明确各个能力中心内部如何协同，与行内渠道、后端产品工厂系统之间的集成关系，与外部渠道或外部生态间的集成关系。那么，核心业务领域有哪些呢？客户、产品、交易就是最最核心的，风险（不是风险不重要，属于内控范畴，我们都是基于客户销售与服务而言的业务运营）、营销、计价、支付是次核心。每个业务领域又有那些关键业务能力呢？比如产品业务领域，其关键能力就是产品目录管理、产品配置、组合配置、产品定价、产品上下架是最最关键的，产品创意、产品促销、产品评价就属于次关键的。
『业务设计之领域设计』
通过顶层设计明确了核心业务领域，划分了关键的能力中心，接下来就是领域设计。此时需要领域专家、业务专家、业务运营人员进行头脑风暴，需要一定的细节把控能力，需要结合自底向上的反向推导，来补充与验证顶层设计中明确的业务领域与能力中心。具体做法就是基于核心业务领域，进行业务场景推演，过程中会梳理出一些配合核心业务领域的业务子域，每个业务子域可以单独作为一个能力中心，也可以归属到关联的业务领域对应的能力中心，前面也说了，所谓能力中心一种逻辑关系的聚合，没有绝对的划分标准。领域设计的过程就是要梳理出完整的业务领域、业务对象、业务行为、业务能力，以形成业务能力全景视图，也就是能力地图。
举例来看看针对每个业务领域的业务场景进行端到端推演过程，比如客户注册开户，新客户在柜面、手机银行、网银等渠道上录入个人信息，系统完成客户信息验证，再创建客户信息，并准实时同步给相关业务系统，然后开立个人活期结算账户，这个过程涉及到哪些业务领域、哪些业务对象、哪些业务行为、哪些业务能力、哪些系统呢？想必至少涉及到渠道、用户、客户、账户等业务领域及业务对象；涉及到渠道填单、用户注册等业务行为；涉及到客户开立、账户开户等业务能力；涉及到柜面或手机银行或网银、身份认证或联网核查系统，ECIF或核心CIF，核心，卡系统等吧。渠道、用户、账户我们可以认为是业务子域，是否需要建立独立的能力中心呢？暂且不做定论。
再比如客户购买理财，客户在手机银行选择基金，逐一浏览比较，心仪的基金加入购物车，输入购买金额，试算整体金额，提交订单，完成支付，查看投资组合，这个过程涉及到哪些业务领域、哪些业务对象、哪些业务行为、哪些业务能力、哪些系统呢？涉及到渠道、产品、计价、交易、支付、合约等业务领域及业务对象；涉及到客户登录、产品浏览、产品选择、添加购物车、提交订单、付款、查看投资组合等业务行为；涉及到客户识别、产品目录查询、产品详情查询、购物车管理、交易下单、交易支付、合约查询等业务能力；涉及到手机银行、产品中心、计价中心、交易中心、支付中心、合约中心、银基通系统或综合理财销售系统吧。同样计价、支付、合约我们也可以认为是业务子域，是否需要建立独立的能力中心呢？也暂且不做定论。基于此方法，逐一推演每一个业务场景就能把业务领域、业务对象、业务行为、业务能力、系统集成关系梳理得八九不离十了，当然后续的中心设计过程中可能会稍有补充与调整。
『业务设计之中心设计』
再接着就是针对每个业务领域和业务子域的能力中心做详细的设计，称之为中心设计。中心设计主要工作包括业务实体设计，业务活动设计、业务组件设计。中心设计阶段需要实现业务中台完整的业务组件。此时需要业务分析师、系统架构师、模型设计及程序设计人员精诚配合，确保业务能力能够不偏不倚地落地。业务实体设计其实就是大家熟知的数据模型设计，并针对这些数据模型通过自动化代码构建工具生产对应的CURD(Create Update Read Delete)原子服务。业务活动设计就是具体业务场景项下的，抽象化的业务能力设计，这些业务能力一定需要进行抽象封装，源自于场景又超脱于场景。比如用户开立这个业务能力是从用户在渠道端自助申请注册，管理员在后台替客户开通用户权限，运营人员在运营管理端代客申请注册等业务场景抽象而来，它脱离了具体场景的角色，仅从本质上实现用户创建与用户权限初始化的业务能力。此时的业务活动设计是基于BIP（Business Integrate Platform业务集成平台）的原子服务编排，形成具备一定业务能力的组合服务。比如用户开立，就是组合UserInserted、UserAuthorityCreateed两个原子服务，形成CreateUser组合服务，实现用户开立的业务能力。业务组件设计，就是以业务领域或者能力中心为单位，将所有的业务能力打包成一个可独立运行的业务应用组件，注意包括对应的前端界面与后端应用服务，否则无法依托前端具体应用场景来呈现相应的业务功能，对客户朋友来说吸引力是不够的，因为业务能力过于抽象，是技术化的程序接口表达，只有依托前端界面驱动才能完整、形象地呈现出业务功能，才够具象化，才可被业务人员所感知，不再只是科技人员才看得懂的程序接口。
（图四：业务实体设计示意图）
（图五：业务活动设计示意图）
（图六：业务组件设计示意图）
『业务设计之场景设计』
最后就是场景设计，直白的说就是做个应用系统，比如财富管理系统，大零售系统，对公营销系统，社区服务平台、产业服务平台等具备对客服务与销售及银行内部管理等功能的应用系统。此时需要领域专家、业务分析师、业务运营人员、UED（User Experience Design用户体验设计）、流程设计人员、程序设计开发人员围绕业务需求展开讨论，明确用到的业务对象，业务行为与业务能力，设计业务流程与客户体验。在场景设计过程中会用到居多的业务组件，比如客户组件、产品组件、营销组件、权益组件、交易组件、支付组件、核算组件、绩效组件等等，基于业务组件提供的业务能力，采用BIP（Business Integrate Platform业务集成平台）、BPM（Business Process Management业务流程平台）分别完成对客的服务与销售流程编排和银行内部管理、营销管理、待办任务与流程审批相关的流程编排。对客的服务与销售所以对应的前端由渠道系统完成设计开发，以对客服务与销售；银行内部管理、营销管理、待办任务与流程审批由场景设计方采用银行统一操作门户的形式完成设计开发，提供给行内人员使用。不管是对客渠道，亦或外部生态渠道，还是内部管理渠道，都需要业务运营人员、UED（User Experience Design用户体验设计）、流程设计人员密切配合，就各个业务场景的客户旅程展开讨论，充分考虑客户跨渠道触点迁徒，反复推导以确定最短路径、最优流程、最好体验，当然安全前提不可丢。
（图七：业务场景设计示意图）
到此，银行业务中台的业务设计方法就白话完了，一家之言，不可以偏概全，大家如有兴趣，欢迎私下交流讨论，携手共创，谢谢！
『下篇概述』
大家感兴趣，可关注后续推出银行业务中台的具体业务设计内容，也就是每个能力中心该具备哪些业务能力，这些业务能力如何协同服务，基于这些业务能力可以快速构建哪些有价值的上层业务应用场景。
网友评论