云计算·大数据 频道

中台之于银行,蜜糖还是砒霜?

一场疫情,让银行数字化转型再次提上日程。“无接触银行”不再是战略规划中亮眼的提法,而是如今各银行经营中不得不面临的切实问题。而中台,作为数字化转型中最火热的概念,这两年在行业里风头无两。中台是数字化转型的一剂良药,还是另一个风投炒作的概念?银行应该做中台吗?盲目上马中台项目有什么后果?本文尝试给出一个答案。

为什么要做中台?

数据中台

(1)打通数据孤岛

主流的观点认为,做数据中台是为了打通数据孤岛。在互联网企业确实可以理解, 但是银行对于数据的应用很早就开始了。大行普遍 2008 年前后就建成了数据仓库,数据层面早已将烟囱系统打通,那么数据中台的意义何在?

银行确实在数据方面很早就开始了尝试,加上金融是个低频场景,因此在相当长的一段时间内,T+1 甚至 T+2 的整合数据基本够用了,更多数据整合和加工为的是满足监管需求。

随着移动互联网时代的到来,用户行为、市场、监管都发生了变化,各类服务移动化的趋势下,用户的使用时间碎片化,金融,特别是支付、理财等行为也变成了中高频交易,并且随着互联网巨头的进入,市场变化不可同日而语,银行的危机感日渐增加。

业务需求响应再快,也赶不上市场、客户、监管的变化速度,而应用开发速度就更慢了,大银行半年左右,中小银行三个月左右是常态。应用系统上线后,传统的基于数仓、数据集市的数据采集和整合方式在时效性上已经很难满足要求。可以说,银行在打通数据孤岛方面,或者更全面的说,在数据加工、分析,及发挥数据价值方面,尝试得很早,但是效果不佳——既不快,也不好。

不快很好理解,即时效性达不到要求,利用最新的流数据处理,分布式 ETL 技术, 数据中台可以更快的整合、加工数据。可是打通效果不好该如何理解呢?

(2)业务数据化

有句话说得好,数据是物理世界在数字世界的投影。既然是投影,那么光源和视角的不同,可能投影的结果也不同。

举个例子,同样一个事件,比如客户刷卡消费,在财务视角看来,是一笔应收账款;在业务视角来看,是一笔客户消费,账户/卡活跃,积分增加;从科技角度来看,交易流水表增加一条记录,账户余额表修改一条记录。我们很难用数据去精确描述一个事件,或者说,在银行的实际使用场景中,每个部门看待同一个事件的角度就是不同的,各部门需要从不同的角度看待同一件事,以便更好的完成自己的职能。在这里,各部门其实都是数据的使用者,即数据用户,那么,我们可以得到一个结论:数据用户对于数据的需求各不相同。

这也是银行要打造数据集市的原因,数据仓库采用相对标准化的数据模型(如FS-LDM)将数据聚合了起来,但是仍然难以满足所有业务人员的需求。因此各部门都提出了自己的数据集市需求。

正如上节中提到的,随着市场变化越来越快,客户变化越来越快,业务需求已经越发追不上他们变化的速度了,而数据的采集和加工速度则更慢,难以支持数据决策。于是,各部门又经常提出各类报表和数据提取的需求,这些都是针对临时的、紧急的、监管要求的、营销统计的数据需求,虽然这些需求更加贴近业务需求,但是在分析和开发上通常也要花费不少时间。

现在,我们可以回答上一节末尾提出的问题:数据孤岛打通的效果不够好,指的是数据的业务友好度不够。

总结银行数据加工的现状,可以得出下图:

在我们传统的数据应用中,随着数据对于业务友好度的增加,其时效性也在减弱。而我们的目标,显然是数据又快又好。既然各部门的需求都不一样,为何不让业务自助分析数据呢?于是我们有了右上角的目标状态。但是这个理想状态和我们现在的数据应用中间有巨大的空隙,靠什么来填补?答案是数据中台。

业务中台

(1)优化烟囱系统架构

银行的数据之所以很早就在进行打通的尝试,主要原因就在于产生数据的业务系统,长期存在重复建设和烟囱系统的问题。到底是什么原因,造成了这个现象。我们其实可以从软件工程中经典的康威定律中窥见一斑:

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

——Melvin Conway(1967)

换句话说,就是组织的沟通方式,决定了其设计的系统架构。回想银行内部的沟通方式,我们不难发现这些现象:以部门为中心,以部门 KPI 为导向,部门墙现象严重,跨部门沟通协作及其困难。由于 A 部门管理的 A 系统无法配合改造,为了实现相似的功能,B 部门只好新建一个 B 系统,这种情况屡见不鲜。这种种现象导致了银行信息系统的建设和管理都是面向部门的,换句话说,形成了烟囱式架构。

因此,中台的建设,必须包含组织架构的相应调整。否则,如果我们把中台具象为一个具体的产品,仍然按照原来归属某一部门或业务条线管理的话,无非是又增加了一个大烟囱而已。

那么,烟囱式架构到底带来什么问题呢?

对外,可能造成同一机构的不同产品、不同渠道,对客服务的体验不一致,甚至账号不互通,每用一个产品还需要客户新注册、开户,体验极差。

对内,成本高,可能造成重复建设,浪费本就紧张的科技资源,挤占排期时间, 激化内部矛盾;烟囱系统产生的数据,形成数据孤岛,为后期统计分析带来极大的困难,进而造成数出多门,甚至错误数据导致错误决策的严重后果;模块无法复用,经验无法共享,烟囱系统各自独立,无法复用其他烟囱的模块或经验,哪怕他们高度相似。

其实,银行也很早就开始烟囱式架构的治理,比如在渠道层,新建渠道整合平台, 在用户层,新建 ECIF 系统,所以说,银行并不是中台战略的追随者,而深感数据孤岛、烟囱式架构之痛的银行人,一直是中台战略的践行者,只是没有把这些尝试体系化、结构化而已。

(2)支持前台快速迭代

前文提到,市场、用户和监管的变化速度,远远快过业务系统迭代的速度,为了抹平这个差异,我们需要让业务系统,尤其是前端面向客户的系统尽量的敏捷。这也是目前业界流行的“小前台、大中台”提法的由来。

中台的故事,在国内起源于阿里,而其核心思想,来源于一家游戏公司(SUPER CELL),相比游戏行业,甚至电商行业的业务领域,银行的业务要复杂得多。因此在谈到业务中台时,我们难免会有疑虑:银行的业务系统,真的有那么多可以复用的功能模块吗?

我们不必照搬互联网企业的中台思路,仔细梳理银行业务流程,我们不难发现, 银行对于同类客户的产品,流程虽不同,功能多相似。以零售对客产品为例,站在用户视角,功能可以抽象为:注册、绑卡开户、充值提现、转账、购买赎回等, 站在机构视角,还可细化出反欺诈、数据采集、客户打标、交叉销售等。由于银行一直以来大多数依赖第三方供应商的成熟产品,为了应对不同银行的需求,这类产品通常是“大而全”的,包含了所有必须和非必须的流程和功能。这就导致直销银行、手机银行、微信银行等等渠道,都重复实现了类似的功能。

其实微服务的思想就是将大的系统,拆分为小的应用和服务,高内聚、低耦合, 发布有价值的服务,即可被使用和共享的服务。而高内聚、低耦合也一直是银行设计架构的基本原则。因此,我们可以看到,银行的架构设计、微服务体系、中台架构一脉相承,都是为了共享功能下沉复用,减少重复造轮子的现象。

这带来的好处,就是新建应用的时候,可以通过已有成熟模块的组装,实现快速上线,从而加快业务系统的迭代,真正实现“小前台”,更好更快的相应市场、客户和监管的变化。

综上所述,中台建设是银行进行数字化转型的关键举措,势在必行。

中台是什么?

2019 年被称作中台元年,一时间,各种中台概念、各种形式的中台方案如雨后春笋一般层出不穷。目前,中台并没有一个放之四海而皆准的标准定义,根本原因, 在于中台并不是一个标准化的产品,根据每个企业自身的情况,中台的建设方案可能千差万别。

不过,可以达成共识的,是中台的特点,它是企业共享能力、共享数据的组织或平台,并且具备业务属性,能够实现业务价值,有响应的组织架构支撑。

中台的形式也五花八门,除了公认的数据中台、业务中台以外,还有技术中台、研发中台、AI 中台、移动中台、算法中台等等。参照中台的特点,我们认为凡是与业务不直接相关的,都应算作后台,虽然其他中台也是能力的复用,或者间接产生了业务价值,但是为了厘清边界,明确讨论范围,我们将集中就数据中台和业务中台展开论述。

数据中台是什么

上一节我们探讨了做数据中台的原因,由此我们可以给出数据中台的使命,是为了打通数据孤岛、实现业务数据化,让数据更快更好的产生价值。

结合数据中台的使命,我们可以将其分为狭义的数据中台和广义的数据中台。

狭义的数据中台,指的是一套数据应用和工具,包括分布式 ETL、数据资产管理、数据标签管理、数据沙箱、自助分析平台、元数据管理、数据质量管理等等,底层则已现有的数仓、大数据平台等为数据源,为企业提供数据资产管理的能力, 并持续挖掘数据价值,持续提供数据智能服务。

广义的数据中台,则在狭义的数据中台基础之上,包含了顶层数据战略,数据治理体系以及数据管理及运营、数据文化培养和组织架构支撑,是一套持续管理和运营的体系。

可以这么说,狭义的数据中台,是专为达成数据中台的使命而打造,一类是让数据更快的处理、整合、加工,比如分布式 ETL 工具。随着传统数据被大数据平台逐步替代,ETL 工具对于大数据平台的适配也需要与时俱进,支持分布式计算、弹性计算,并且减少开发量。

另一类是让数据更好的产生业务价值,比如数据标签管理,自助分析平台等。数据标签大家都在用,但是真正深度使用的企业都会感觉:建好容易用好难,如果没有一套标签管理系统,标签是否重复加工,标签的使用率、准确性等都无从掌控,业务部门想要针对近期营销活动新建一个标签,还得走开发流程,时效性也难以保证。

数据标签管理系统就是为了解决数据标签的使用问题而建立。自助分析平台则是方便业务人员自助进行数据分析、加工、探索的平台,它与数据沙箱结合,直接将去隐私话的生产数据提供业务人员分析,使数据更快的产生价值, 支撑关键决策。

广义的数据中台,则是辅助狭义数据中台达成使命的机制,虽然看起来都很“虚”,但是却是数据中台成功落地的必要保障。

没有数据战略,在推进数据中台建设,甚至建成后的日常运营中,难以沟通协调各部门利益,缺少“尚方宝剑”。没有数据治理体系,数据管理无凭无据,无章可循,很容易造成 Garbage In-Garbage Out 的现象。

但是这里必须澄清一点,在银行信息系统这样复杂的环境中,数据质量的问题永远存在。因此,“等数据治理好了,等数据质量控制好了,我们再开始做数据应用,做数据中台”,这种想法是不切合实际的,因为不存在数据质量控制好了,数据治理好了的那一天,这是一个持续的过程,好到什么程度算好?谁来决定这个标准?

我们认为,数据质量很重要,需要持续改善,但是不影响数据中台建设, 应该以用促治,在使用场景中有针对性的开展数据质量管理和数据治理。

没有数据管理及运营,数据应用的价值无法持续产出,甚至会出现便宜甚至错误。缺乏数据文化,则会造成数据应用没人会用,没人想用,没人愿意相信数据结论, 没人愿意尝试数据驱动,没人愿意基于数据决策。没有组织架构支撑,则会让数据中台这样跨部门的体系难以推行,最终胎死腹中。

业务中台是什么

同样,业务中台也可分为狭义与广义,狭义的业务中台,指的是由多个共享中心组成的服务整合平台,通过梳理各业务系统共性的功能,在每个中心里将服务拆分、共享。我们建议,可以按风控中心、产品中心、用户中心和旅程中心等维度整合共享,底层的数据能力由数据中台提供。

广义的业务中台则包含了支撑各中心运营的组织架构和体制机制。正如前文提到, 没有组织支撑,中台不过是另一个大烟囱。每个业务中台的子中心,都应有对应 的组织支撑,可以是虚拟的,也可以是实体的,最好由业务+科技+风险+数据的 综合人员构成,小团队作战模式,以产品使用率、稳定性、客户满意度等为 KPI, 为业务中台保驾护航。

风控中心管理全行所有的风控模型,以及对客产品交易、账户层面的动态安全策略,以底层机器学习平台为支撑,共享全行风险管理能力。产品中心管理全行所有渠道的产品,控制购买额度、购买条件,灵活上下架等。

用户中心基于数据中台打通的全行用户信息,建立用户成长体系、权益体系,管理用户标签画像,分析用户行为轨迹,为旅程中心完成客户全渠道一致体验打下基础。

旅程中心以用户视角出发,以用户体验为最终目标,梳理、贯穿各渠道流程,整合、复用各渠道功能,最终达成全渠道客户体验统一。

结语——中台的边界

了解了中台是什么,最后,我们来看看中台不是什么,或者说,中台的边界在哪里。

首先,中台不是银弹。

没有银弹:没有任何技术或管理上的进展,能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步

——《人月神话》

软件工程领域的“圣经”《人月神话》早就提出了没有银弹的说法,中台也不例外。不要妄想通过中台,解决企业内部一切的数字化问题。即使是上文提到的广义中台,也仅仅是包含了企业数字化转型中,与数据、业务中台相关的组织和机制,但是仍然无法涵盖一个组织在数字化转型过程中遇到的各种问题。中台与其他新技术体系一样,可以帮助企业降本增效,但是如何选择业务方向,如何团结一心,如何切入市场,如何找到目标用户等等,都是企业在中台之外还需要努力的方向。

其次,中台不是一个可以买来的即插即用产品。

不必为了做中台而做中台,也不必大干快上,一起步就是一个五年大工程。由于中台与企业内部的数据、业务系统高度相关,虽然有相对标准化的产品可以预先研发,但是更多的工作,在于中台与存量系统的对接、优化。

最后,中台不是一个筐,别什么都往里装。

当一个新技术体系难以明确定义时,最常见的现象就是边界模糊,什么都可以放进去。最典型的例子就是“大数据”了。虽然有类似“5V”的定义,但是大数据的定义从来没有统一,这也导致现在只要提到数据,都会冠以“大数据”之名。实质上,大家所指的绝大多数数据,并非是“大数据”,都是“小数据”。

概念的模糊,使得炒作时,无数企业挤破头往里冲,也导致行业发生合规风险时, 与“大数据”沾边的企业都风声鹤唳,草木皆兵。这种现象,对于行业的发展弊大于利。

因此,我们必须厘清中台的边界:无共享,不中台;无业务,不中台;无组织, 不中台。

没有共享能力、数据的整合,不算中台;没有直接服务于业务,产生业务价值, 不算中台;没有组织支撑,仍然服务于某个部门,不算中台。

行文至此,希望解答了大家心中的疑问。简言之,做了中台不见得就是数字化领军企业,不做中台也不见得就是古典互联网时代的落后作坊。关键是认清自身的数字化现状,拟定数字化目标,制定数字化路径,优选场景,实现价值。中台只是这条道路上,一套切实可行的行动方案。糟糕的公司治理,三天打鱼两天晒网的战略定位,部门银行的组织架构,即时搭建了中台,也徒有其表,如此,中台是砒霜。

坚定的战略,清晰的目标,合理的组织架构,搭配中台,可以使数据更快更好的发挥其价值,业务模块更好的融合,用户体验得以更好的提升,如此,中台是蜜糖。

0
相关文章