银行IT的敏捷转身

[摘要]

中国银行业的数字化转型才刚刚拉开帷幕,作为转型重点的银行IT部门正在经历从开发模式到组织定位的巨大变革。本文从时下银行IT广泛的敏捷转型开始分析,揭示了中国银行业面临的数字化挑战,分享了应对挑战的一些共识,同时给出了中国银行数字化转型的大方向。

数字化挑战

过去的3年时间里,我作为敏捷转型顾问,合作频次最多的,就是全国大大小小的银行。银行业IT这一波的敏捷转型,很多人会归因为互联网金融的冲击,认为银行业IT被迫从原来的内部职能部门走上前台,迎战外部市场的挑战。也有不少银行从业人员,对此持有不同看法:类似P2P这样的互联网业务,对中国的银行业还谈不上任何的冲击。在我看来,真正冲击中国银行业的,是以下两个方面:

  • 服务渠道的变迁——渠道从过去实体的网点向数字化渠道转移。注意,这并不是说所有的服务都变成了移动APP,而是所有的服务都会用某种数字化的形式呈现,比如现在到工行建行网点办卡都是通过一台综合服务机;交行几年前开始试点网点机器人,而招行已经在刷脸取款。由于银行之前是没有数字化部门的,所以这些要求自然跟IT挂上了钩。
  • FinTech的冲击——技术突破正在改变业务形态。最近火过了头的加密货币(比特币)正是这样的技术案例,它可能对未来银行业务产生颠覆性影响。在欧美很多利用智能技术做征信的平台也快速崛起,替代了传统费时费力的背景调查。对比之前的传统银行科技,FinTech拥有非常大的不确定性,这给习惯于购买成熟软件产品的银行带来了不小的挑战。当然由于又是科技相关,所以这口锅自然也得IT背了。

以上两点带来的变化显而易见,所以,无论提不提敏捷,银行IT都得转型。建立在支撑基础业务、保证业务稳定运行之上的IT部门,不可能自然而然演进成为“以用户为中心,思考服务体验,并保持对业界先进技术洞察”的新型数字化IT部门。下面就结合我过去3年中,近10家银行的顾问经历,谈谈这个转型中的挑战和可能的应对之策。

稳与快

我们辅导过一家外资银行,一上来就要求全球范围实施DevOps,“全面”敏捷。作为顾问,感觉很爽,改进起来气贯长虹。半年之后,已经没有不做敏捷改进的项目了,就连基于小型机AS/400的系统也都走上了DevOps的持续发布之路。

中国的银行业可就不是这样一个情况了。我和业内熟悉的几个人,经常开玩笑说“‘喝茶’就是悬在中国银行敏捷转型头上的‘达利摩斯之剑’”——高管们心里羡慕着互联网玩法的“小、快、灵”,脑子里却时刻担心着因生产事故被请去“喝茶”。转型需要经历烟斗曲线,当刚好处于曲线下挫点时,很可能因为一次事故而被全面叫停。一位银行科技高管曾经在内部会议上对我直言:“不要以为我不支持敏捷,正是因为我支持,所以才拉着你们跑慢一点”。

团队里有顾问找到我说不想做中国的银行了,太纠结,犹抱琵琶半遮面。于是我反问这位顾问,为什么中国的银行不能像外行一样一步到位呢?是因为太保守或者太官僚?一时问得对方语塞。其实,外行比起咱们可能更保守,生怕有一点负面消息,有的机构更庞大,更官僚。那么是什么原因,让我们中国的银行不敢“全面”敏捷呢?

就我目前认知,中国银行和外资银行有两点显著不同:一是中国银行集中精力办大事儿的构建方式;二是中国银行IT的历史定位。

如果我们对比中外银行的业务架构,会发现咱们的银行在业务设计上非常集中。这样的集中思路投射到IT系统建设上也是非常明显的:一般会考虑一套系统支持多条业务线。经典的例子是咱们的银行一般只有一套清算、核算平台,而外行每条业务线可能有自己的独立平台。集中建设的好处自然已经体现出来了,短时间我们就构建起来了一个相对完善的金融电子平台,但带来的问题就是系统非常复杂。

(图:中外行典型组织结构区别)

在敏捷转型过程中,有两个领域的复杂度是让我头疼的:电信和金融。大家可能想象不到,打通一次电话和完成一笔转账都要涉及近亿行代码!一条业务需求动辄要求修改十几个独立应用!咱们集中建设的银行系统显然不是随便就敢改的,早期即使在银行大型机系统上引入迭代开发都是很困难的。而这些系统往往又是银行的核心主干,任何小错误都可能造成致命的连锁反应。

在IT定位上,从国有五大行到各大股份制银行,基本都将IT归到了科技部下面统一管理。从组织结构上,可以看到IT的定位是一个共享的内部服务部门,或者说,是一个成本中心。最初的IT只是管理一些购买的商业软件和平台,并没有作为一个强自研能力的组织存在。银行IT的自有员工和外包人员比例,普遍都在1:6左右,一个主要的IT系统可能也就能投入两三个长期自有员工。到了现代,这个以科技为核心(Tech@Core)的时代,这样的人员配置显然已经捉襟见肘了。

以上两个因素,从技术架构和人员架构两个方面制约了敏捷的大规模推广。所以,银行想要“快”起来,往往不那么容易。各家银行的转型,都会选择相对新的技术领域,或和用户结合比较紧密的应用开始试点。而初期的转型目标,也会设定为“探索在现有约束条件下,如何进行敏捷模式落地”。最终,大多数银行都会走向“双模”:明确哪些系统和应用更看重业务表现的稳定性(采用瀑布模式),哪些更看重市场变化的响应速度(采用敏捷迭代模式)。

(图:源于Gartner总结的双模IT架构基本示意图)

理论上讲,“双模”只是一个过渡状态,这种方式也受到了不少专家的批评。“双模”可能会掩盖掉一些更深层次的问题,比如系统快不起来,根本原因其实是架构质量问题。从科技的发展趋势来看,确实止步于“双模”是不明智的,微服务化和平台化架构的逐步成熟会让以前稳定第一的系统也快起来。但就目前的约束来看,“双模”是已有成型建制银行IT的必经之路,其意义更多是在组织里植入管理不确定性的能力,从而构建对市场变化的快速响应能力。

效率与响应力

“唯快不破”是互联网服务发展的必备条件,而这个“快”其实是被很多管理者误解的。这个误解也造成了银行IT管理者们对“快”的提法有些许反感。这个误解的根源,在于对效率和响应力的混淆。

如果我们正确分析互联网成功服务的特质,就会发现他们根据市场变化推出和改变服务的速度特别快,而这个快很明确是在响应力上。举个日常生活中的例子,作为干洗店的客户,我们其实并不关心干洗店内部的效率问题(例如单位时间处理多少件衣服、干洗机的利用率等),我们关心的是干洗店能多好多快地把我们衣服洗好。

互联网时代给银行业带来的一个明显转变,就是从过去“以自身服务为中心”,到现在“以客户为中心”。从前在以自身服务为中心的时候,我们的管理方法及技术实践都是围绕效率来做的;到了这个时候,显然我们必须用客户的视角来思考问题,所以就需要更加关注响应力。当我们在追求效率的道路上走到一定程度,就有可能伤害响应力。比如为了干洗机的利用率,我们批量分类客户的同类型衣物放一个批次,显然这样的做法在订单达到一定数量的时候,会减缓每个客户的交货时间,让客户等待更久,伤害了对客户的响应力。

同理,这也是为什么在敏捷组织里,我们提倡少分角色、跨职能协作。当我们的分工过于细化时,对外部的变化响应能力就下降了。在传统银行IT系统里这样的情况是很普遍的,一个业务需求需要分解到十几个应用模块完成,而每个模块都只能由一个专人完成。

理解响应力的重要性并不难,但实践高响应力的管理却是相当困难的。银行业是一个重流程管理的行业,银行IT显然也继承了这样的基因。重流程标准化的管理方法,造成大家习惯性地进行自身局部效率的优化,实则增加了端到端的响应时间。我经常举一个发生在我们每天日常工作中的例子让大家意识到这个问题的严重性。

你是一位IT管理者,小王是一位认真负责的开发人员。一天他告诉你,现在项目A上他的工作进入尾声了,接下来只需要占用他一半的工作时间。这样的情况下,小王希望请示接下来的工作安排。在实际工作过程中,大家会赶快告诉小王启动项目B的工作,或者分配给他项目C的部分工作。假设小王启动了项目B的工作,很快他发现需要小李协助才能开展分析工作,而小李这个时候正在项目A上忙得不可开交。接下来有意思的事情就发生了,小王显然会要求小李配合,而这事儿如果真正发生了,显然就耽误了项目A的工期,那么项目A的完成时间就要推后了。小王和小李有可能找到你来请示工作优先级,然而,可怕地是,在你的意识里,会觉得这显然是“加加班”就能解决的问题!

于是,整个IT产业陷入了做不完的需求和越来越严重的内耗!

(图:小王工作安排示意,由于项目B的引入工作越来越多,成效却变少了)

实际上,如果我们认识到项目A的关键要素是快速推向市场,那么我们给小王的安排应该是让他继续专注于项目A,看看什么地方能够协助团队尽快完成项目。这个认知的转变是困难的:

  • 作为管理者,要放弃过去对人员利用率的执着,理解利用率和响应力不是正比关系,在一定阶段后甚至和效率也没有正比关系。
  • 作为员工,要放弃一个萝卜一个坑的工作模式,保持持续学习和跨职能工作的能力,把自己构建成一个T型人才。这个案例中,小王要能够帮助项目A的其它工作,就要求他具有开发之外的其它能力,比如测试。

在这样一个时代背景下,银行IT的敏捷转型,实际是基于以用户为中心的根本原则,加强整个组织的响应力。如果大家还在以“一个功能实现是不是更快了”来度量和牵引转型方向,那么请尽快调整到“面向市场和用户的端到端交付指标”上来。

业务与技术

懂业务是银行业人员晋升的关键因素。曾经在一次银行IT中层管理干部的培训上,我让大家举手表决是向业务方向发展,还是向技术方向发展,结果是全部都选择的业务方向。不可否认,银行业务的复杂度,要设计一套IT系统需要很强的业务理解。但数字化时代,技术成为了越来越重要的一个支柱,各银行组织如果不能快速构建技术人员的职业通道,必然很难在数字化上取得真正的收益。

我们从两个方面来看看中国银行业技术方面的挑战。

第一点是没有足够的技术封装。经常看到一个有意思的现象是,银行业务人员会看数据库,每一张数据库表就映射一张物理世界的报表。这样的设计结果往往是一张银行数据库表可能有好几百个字段。一段时间内,这样的设计是很流行的,因为沟通需求和最后验收都会相当顺畅,直接看数据库表就完成了技术和业务的交流。隐患就是,数据库根本就没有模型可言,修改任何的数据项都需要波及整个系统,所以大家就倾向于一开始就把所有的数据项全部列好,如果不确定就先留下一些空字段以备后续不时之需。

由于根本没有数据模型封装,看似业务上便于理解的设计,到后来也会因为冗余严重、耦合紧密而变得难于理解,或根本不可维护。只要是在基于如此架构上工作过的IT人员,就特别能理解,“为什么弄懂一个几千行的存储过程,需要花几天时间”。没有封装的结果,就是每个维护修改者都需要理解已有系统的所有复杂细节。这也是为什么我们在银行核心COBOL系统中,会看到大量的冗余代码——与其修改已有的程序,还不如忘记已实现的业务,为新增业务重新开发。

第二点是没有开放的技术生态。银行业经常把基于Java这样现代语言的开发称之为开放平台,与之对比的是传统基于大型机和小型机的封闭开发环境。最近还就开发效率问题和一个老牌银行技术人员进行过讨论。一个观点是,基于成熟封闭环境的开发一旦上手其实效率可以很高,对金融行业来说更加模式化,并且硬件保证了高性能和稳定性。于是我也花了不少时间,来研究这样环境下的开发模式,比如在绿色的传统命令界面上完全采用键盘操作,从代码管理到部署都是私有的平台和工具。

从我的角度来看,传统封闭开发环境有以下几个致命伤:

  • 技术设计的表现力不够,造成可维护性差。长期下来,系统修改十分困难,成本随时间爬升很快。
  • 不能够利用很多已有资源。从开源到云服务,实际上都是开放生态中的可用资源。开放技术的全球知识库早已超越了任何一家企业可以提供的技术服务。使用这些共享资源的门槛,就是需要加入到这样的开放生态中去,随着环境的发展而持续演进。
  • 难以支撑快速的市场和用户扩张,对基础资源抽象隔离不够。以云服务为例,某种意义上,云是对之前我们计算机硬件资源的封装,让其成为像日常生活中水电气一样的公用资源,它使得我们在数字世界扩张的时候可以不再受基础资源的限制。然而,在银行IT中,这样的基础资源和服务抽象很少。

很多银行已经意识到了上述的问题,在科技发展方向上,决定逐步将系统应用向开发技术平台迁移。但还存在很严重地照搬过去架构设计的倾向,如前述数据库设计问题仍然存在于新系统中。在敏捷转型过程中,会发现即使在开放平台上也很难实现端到端的业务价值交付,其中核心症结之一仍然在技术架构上。去年,我花了比较大的精力在领域驱动设计(DDD)的推广上,也是希望通过这个方法让银行IT组织认识到正确的架构设计思想。

未来的银行数字化部门应该在应用设计上达成业务和技术的架构绑定,而在人员任职上形成业务和技术的双通道。

文档与人

曾经一句玩笑话“人走文档留”,引起了我对银行IT人才观的深入思考。从较长一个时期看,IT人才观的转变可能是中国银行业的最大挑战。在前沿程序设计会议上,当我倾听一家外行科技VP讲函数式编程,看到两家美国银行收购硅谷技术公司的业界新闻的时候,就深刻地意识到,把“文档”当成IT资产的观念,将会严重阻碍中国银行的科技发展。

也许,在国家鼓励下的BATJ合作,可能给咱们的银行IT业带来深层次的冲击。从去年开始,这个冲击已经超越了我们经典意义上的敏捷转型,而是银行组织级的变革。在这个过程中,我认为我们要解决三个组织级的定位问题。

  • IT合作伙伴的战略定位——从现在的人员外包模式,到面向价值共享的战略合作模式。现行包人头的方式,是敏捷转型的障碍,在银行数字化转型过程中必须重视并解决。当IT和数字化成为银行业未来业务的重要支柱,合作伙伴的定位及合作方式就必须相应改变。
  • IT人员的能力定位——从现行的流程执行模式,到面向业务和技术创新的持续学习模式。随着智能技术在未来几十年的持续渗透,追求效率的金融领域会逐步用机器替代掉重复性工作中的人。这对IT的影响是更深远的,很快我们就会有机器来代替基础的程序员和测试人员,也不再需要管理这些基础人员的IT自有组织。但更为紧缺的是,具备持续学习能力、能够快速响应市场需求变化的数字化人才。
  • 数字化平台的支撑——从过去组织统一流程、检查规范模式,到平台化快速支撑模式。针对未来的不确定性,做细管理流程、强化检查节点的帮助其实是有限的,而提供快速的试验支撑,能够灵活快速地启动小规模多点尝试,则是成功的关键。

人才这个话题上,有一点是确定的:整个组织需要构建数字化人才的能力模型及持续培养体系。去年在国内,我也很欣喜地看到,若干家银行的高管们,开始过问大数据人才的招聘和留用问题,关心在现有体系下如何开辟新的渠道来灵活留用人才。

数字化未来

前面谈了目前银行业IT转型的挑战,最后让我们展望一下未来可能的方向。在前文中我已经多次提到了“数字化”。一个可以预见的未来就是数字化银行,其实《银行3.0》中已经描述了这样的现实,作者也已经开始讲“银行4.0”了。

应该澄清的一点是,数字化不等于IT系统,数字化能力不等于写计算机程序。IT系统仅仅是数字化的一个基础,数字化包含了以用户为中心的实时战略方法和高响应力的敏捷组织,在这样的组织里对技术卓越及创新生机文化的追求是大家的共同目标。

(图:数字化转型模型)

银行业IT的敏捷转型,显然必须服务于这个数字化未来。通过敏捷转型,我们需要把现行的IT部门变成未来数字化银行业务的支撑平台之一。而IT的敏捷转型最终目标应该明确为:

  • 提升端到端的市场响应能力,从而能够为科技引领创新提供能力支撑。
  • 探索科技和业务融合的新模式,从而能够为数字化业务提供模式支撑。

中国银行业的转型才刚刚拉开帷幕,敏捷转型的模式还需要更多的实践者出来分享和交流,谨以此文作为和大家交流的起点。


更多精彩商业洞见,请关注微信公众号:ThoughtWorks商业洞见

Share

数字化转型之路:打造竞合平台

在前一篇《数字化转型之路:织建顾客网络》中我们提出了一个问题:在数字时代,一个企业或组织与外界的核心关系是什么?回答这个问题,可以从两个角度来拆解这个问题:

  • 一是企业创造出来的服务和产品面对的是谁,也就是顾客是谁?
  • 二是企业为了服务第一类群体和其它组织的关系,也就是合作伙伴,竞争对手是谁?

今天我们就来看看组织和组织之间的关系。

对比模拟时代和数字时代的组织,我们会发现数字时代的顶级组织,采用了平台模式。究竟什么是平台模式,平台模式的关键核心点是什么?如何构建或转型为平台模式?在不同阶段,平台需要具备什么特点?实施路径是什么?

1. 从冷战到战国时代

过去,竞争往往产生于相似的竞争性业务之间,或说界定清晰并且有稳定边界的行业内部。组织借助于供应商、销售渠道的合作关系,来创造价值。所以那个时候的竞争关系更像是冷战时期的美苏阵营,双方边界清晰相互对峙。竞争的结果只能是零和博弈,一方的领先必然意味着另一方的落后。一个组织相对于另外一个组织要么是朋友,要么就是敌人,很少存在中间状态。

进入数字化时代之后,随着信息的高效传播,一个组织进入一个新行业的门槛逐渐降低,导致企业更倾向于多元化发展。这导致行业的边界逐渐模糊,很难再用非敌即友的原则来确定组织之间的关系了。于是组织和组织之间的关系就好像战国时代一样,今天我们还是盟友,明天可能就要兵戎相见了。而且,在这个战场上,新组织不断涌现,成长速度也越来越快——前几个月还是角落里的一个小不点,转眼之间可能就进入了独角兽俱乐部。所以,采用何种生存方式成了每个组织面临的首要问题。

我们先看看最近这些年的一个现象,就是有些公司呈现出了脉冲式的增长。脉冲式增长的意思是,公司的增长不仅仅是一次指数级爆发增长,然后增长回落,而是在一个指数增长之后经历了一段时间的能量储备,会有第二次的指数式增长。中国的典型案例有腾讯、阿里,美国的典型案例有Apple、Google、Amazon。之所以有这样的增长现象,是因为在数字化时代,这些经济组织的核心形态已经从公司变为平台。公司的典型特征是通过管理降低成本和扩大规模,实现稳定的线性增长。数字时代,平台通过网络效应和规模经济,实现爆炸性的非线性增长。

2.平台模式的兴起

这些年随着互联网的发展,大家肯定听过很多“这个是平台模式”、“想做一个平台”之类的各种新闻。那么平台模式这个理论是怎么提出来的,平台模式究竟又是在说什么呢?

其实我们现在耳熟能详的平台模式全称应该是“多边平台模式”,这个概念的提出者是哈佛商学院的Andrei Hagiu和Julian Wright, 他们在2015年发表了一篇论文《Multi-Sided Platforms》。其中,多边平台这个概念来源于多边市场理论,多边市场其实也称为双边市场,关于双边市场这个概念可以看看诺贝尔经济学奖得主Jean Tirole在2005年的论文《Two-Sided Market:A Progress Report》,双边市场理论发现市场的两边时常表现出不一样的价格敏感性,而且在有效市场中,一边时常会对另一边补偿,比如商家给银行支付手续费而形成对信用卡持有者的补偿。

经济学用“多边平台”描述居于多边市场中心的商业模式,慢慢演变成用平台这个概念来代指多边平台商业模式。如果为平台定一个明确的定义,就是:

通过帮助两种或多种不同类型的接入者实现直接交易来创造价值的商业形态。

常见的八种平台模式:

  • 交易服务的平台。如Uber、airbnb
  • 交易产品的平台。如淘宝、亚马逊
  • 支付平台。如支付宝、微信支付
  • 投资平台。如陆金所、LendingClub
  • 社交网络平台。如facebook、Linkedin、微博
  • 通信平台。如whatsapp、微信
  • 开发平台:
    • 闭源开发平台。如saleforce
    • 受控开发平台。如iOS
    • 开源开发平台。如Linux
  • 内容平台。如kindle、youtube

3.透视平台模式

首先,我们来看看平台模式究竟是如何工作的。

以Airbnb为例,来看看平台模式的关键要素。

  • 首先,是需要吸引谁到平台中。对Airbnb来说可以吸引的玩家有房主,租客,摄影师,保险公司
  • 其次,平台给这些角色提供了什么价值。这些参与者需要为平台贡献什么?平台能为这些参与者提供什么?Airbnb的例子中,
    • 房主给平台贡献房源,平台吸引房主获得租金
    • 租客给平台贡献租金,居住评价;平台吸引租客获得更便宜更好的旅行居住
    • 摄影师给平台贡献精美的房屋照片,平台吸引摄影师获得报酬
    • 保险公司给平台贡献安全的信任保障,平台吸引保险公司获得保费
  • 接着,平台的关键用户是谁?每个角色会带来哪些接入方,哪类角色带来的接入方最多?最多的即是关键用户。在Airbnb案例中,房主吸引来租客,摄影师,保险公司,所以房主是平台关键用户。
  • 下一步,明确谁是为平台贡献主要收入的付费者。在Airbnb的案例中,租客是贡献主要收入的付费者。
  • 最后,谁是平台的协作者?即平台的“甜味剂”——没有贡献收入,但是帮助平台吸引关键用户的角色。Airbnb中,“甜味剂”是保险公司,它会让房主更加放心。

4.搭建平台模式

通过透视平台模式,我们明白了这些成功的平台企业究竟是如何运转的。那么,如何结合我们自己的业务场景,搭建自己的平台呢?

搭建平台模式的“三板斧”:

  • 第一步,定位平台用户,也就是找到可能使用你平台的多边群体。然后分析针对各个群体的平台价值。
  • 第二步,找到关键用户,激发网络效应。这一步的要点是能够吸引关键用户,为了达成这个目标,适当的采用战略性手段比如补贴,免费等方法也是必要的。
  • 第三步,灵活平衡平台上的付费者和“甜味剂”。如果某个玩家更有可能多地栖息,那么就应该考虑采用适合对应群体的手段来增加使用平台意愿,并通过游戏化的激励手段把意愿培养成习惯。

下面让我们用一个实际的案例看看我们是如何帮助某银行客户搭建平台的。

该银行客户的原始诉求是希望让更多的客户进行黄金交易。我们首先和银行业务专家一起分析和定位了平台玩家,找到的平台玩家是有购买过黄金的客户,能够影响客户进行决策的内容提供商。在平台战略思维模式下,我们发现原来可能是竞争对手的线下金店也可以成为平台的一个玩家:在平台上已经购买黄金的买家可以通过出借的方式把黄金借给金店,金店使用借来的黄金进行加工生产成各种首饰、黄金金制品,然后金店在完成销售后再用回收的现金购买黄金还给平台的黄金买家,并支付一定的资产收益给黄金买家,这样黄金买家在保证自己持有黄金数量的基础上还有额外的资产收益。

分析完了平台玩家以后,第二步我们看看谁是关键用户。在这个平台模式中很明显黄金买家能够吸引来内容提供者、线下金店,所以黄金买家是关键玩家。明确了关键玩家,就可以制定吸引关键玩家的战略,比如降低黄金买家的交易手续费,通过前一篇《构建顾客网络》中五种数字化顾客的行为模式来提供能够满足黄金买家各种诉求的数字化功能。

为了能够更好的吸引关键玩家,内容提供者是“甜味剂”。黄金买家可以通过平台获取黄金相关的新闻,还可以学习到一些黄金相关的金融知识。为了能够给黄金买家提供优质的内容,我们还给银行建议能够在平台对内容提供者进行效果评估,通过竞争的方式来保证内容的质量,同时也允许内容提供者对优质内容进行收费,从而保证整个平台的良性反馈。

5.平台模式的实施路径

构建一个平台后就需要不断演化和发展。一是要让平台对用户越来越有吸引力,另外一个是可以吸引越来越多的用户进入平台。

一般来说,平台模式的演进有三个阶段:

  • 阶段一:用户交易平台,比如滴滴、Airbnb。他们主要针对平台商业模式中的主要用户构建可以进行直接交易的平台,吸引主要用户参与,并帮助他们更高效地推进交易。
  • 阶段二:交易数字化平台,比如微信企业号、聚合数据。随着更多类型的玩家加入平台,平台需要提供针对各类用户更高效地交互方式,交易数字化平台允许接入方通过公开的API来使用平台的功能,还允许用户把自己的资源通过满足规范的API集成到平台上,负责API的全生命周期。
  • 阶段三:资源服务化平台,比如amazon、京东。随着平台的进一步壮大和发展,组织为了最初促进平台交易的能力和资源可以进行服务化,资源服务化平台帮助组织管理服务化以后的内外部资源,服务化的资源暴露成API由交易数字化平台进行管理。

写在最后

随着亚马逊、苹果、阿里、腾讯这些公司的市值越来越高,平台战略变成了席卷全球的商业趋势之一。要实现爆发性增长,实施平台战略是利器。

值得提醒的是,一旦行业出现了赢家平台, 必然会出现赢家通吃的现象。赢家平台,会像黑洞一样, 把市场上其它资源都吸过来。还记得网约车鼻祖”易到”吗, 创始人周航就是在网约车行业的关键时刻没有抓住成为赢家的机会, 在网约车平台补贴战争的一年, 易到平台没有参与补贴战争,最后在竞争中败下阵来。同时,原来的平台玩家也被Uber和滴滴抢夺。

因此,对于每一个想打造平台模式的企业来说,我们不但需要知道如何构建或转型为平台模式,还要随市场变化不断演化自己的平台,才能够避免被其他赢家吃掉的结局。


更多精彩商业洞见,请关注微信公众号:ThoughtWorks商业洞见

Share

智能银行(中)

上篇文章中我们提到,人工智能和机器学习等新兴技术是银行业变革的催化剂,会让传统银行以一个全新的运营模式实现新的可持续增长,成为“智能银行”。本篇文章,我们谈谈“智能银行”的实施路径。

组织增长的三种策略

组织能否实现指数级增长,有三种策略。

1. 流程驱动

  • 提升价值链的每个独立环节的效率
  • 通过增强人力资源展开大规模运营
  • 强调专业化、按照专业技能形成职责分明的职能部门
  • 在部门层面定义成功标准
  • IT的角色是协助每一个职能部门变得更高效
  • IT的度量主要依据是否按范围、预定时间、在预算内交付

2. 数字化驱动

  • 通过自动化核心流程实现效率最大化
  • 消除组织和技术的阻力,进入新市场
  • 引入设计思维,践行以客户为中心的理念
  • 围绕核心业务能力,引入产品思维和跨职能团队
  • 通过实验学习,培育更强的创新能力
  • 构建微服务减少相互依赖,建立更敏捷的平台,促进无缝化集成
  • 通过DevOps实践,激发更深层次的协作和自动化,缩短产品的发布周期

3. 智能驱动

  • 构建自动化能力,以服务更广泛的客户群体或满足更深层次的客户需求
  • 通过实时访问整个企业的数据资产,推进算法智能,释放数字驱动服务的潜能
  • 利用企业和生态系统的数据实现动态监控,自动化、精细化决策
  • 从更广泛的生态系统中集成功能和数据,为客户提供整合的解决方案
  • 基于客户需求和可以承受的风险,提供个性化产品和灵活的定价
  • 减少组织和技术层面的摩擦,形成飞轮效应

需要明确的是,数字转型是非常有必要的重要一环。但实现了数字转型并不是就万事大吉了。注重成长性的银行必须不断去解决问题,发现新机遇。不仅要把自己已经熟悉的事情做好,还要有更高的目标、尝试不同的事情。

智能企业的战略核心:平台思维

成功转型智能企业的公司并不仅是使用技术“赋能”当前业务流程。他们的重心是把客户关系、业务线、核心能力和运营转化到软件端,成为一个数据驱动的组织。这就是智能企业的战略核心。籍此,实现指数级增长,并不满足于增量增长。

增长要么来源于新客户收入,要么来源于存量客户更多的收入贡献。这就需要企业对客户市场更为细分,或提供更贴合的服务,或切入一个细分市场,或创建一个新的细分市场。

高效增长战略的核心要义恒古不变——成功的公司并不仰仗他们的“产品组合 ”。他们关注的是客户“亟待解决的问题”,通过帮助客户解决问题来创造价值。在高效增长战略中,产品和服务完全可以针对个体客户的问题来定制,甚至是与生态伙伴的服务打包在一起,为客户提供更有吸引力的解决方案。

既然以客户为中心是高效增长的核心,那实施路径只能是通过平台思维,来实现规模化增长。原因何在?大部分金融机构创新时,面临的挑战多是成本和复杂性的问题,而平台思维就是解决之道。

平台思维是什么?

平台思维将技术与解决客户“亟待解决的问题”所需的敏捷性联系起来。ThoughtWorks数字平台战略展示了建立一个这种数字化基石的蓝图。

智能银行需要在自己的数字平台上,打造三个核心业务能力,以为实现指数级增长创造条件。

  • 全方位的客户洞察,即了解客户使用服务和产品的环境。例如综合了市场营销、风险管理和运营管理等内部数据,以及地域、设备、渠道和交互方式等外部数据的统一客户视图。这样才能对客户真实的需求形成更深刻的洞察,了解客户真正面对的风险是什么,进而形成一个清晰、风险加权的客户价值定位。
  • 企业数据的充分共享。在法律允许的范围内,能够帮助银行内部所有业务线和职能部门实现数据近乎实时的流动。目的是更好地理解业务,发现有用的模式和洞察,创造更多的机会,在运营的各个环节提升决策的自动化程度。例如,在综合考虑风险、合规和市场数据后,零售银行业务可能会发现针对某个细分市场中提供按揭首付的市场营销活动存在着极大潜力。
  • 敏捷的生态系统。生态系统敏捷度是优化客户解决方案的战略侧重点,需要外部合作伙伴提供数据和服务,以API为实现方式。这种方法与传统合作伙伴关系不同的一点是银行此时谋求向客户提供全面集成的解决方案,该方案既包括银行自己的产品组合(例如,贷款产品),也包括外部供应商提供的产品组合(例如,Zillow提供的住房市场趋势)。

初创企业如何利用平台思维推动公司快速发展?

Stripe一直坚持自我创新,秉承以客户需求为导向的原则。他们的核心业务是为数字企业提供银行业务的技术基础设施,保证互联网付款的安全性。Stripe意识到企业家在建立电子商务企业时会面临各种困难。公司不断扩展其套件功能,如欺诈保护、合规及核算等,帮助客户化繁为简。公司的新产品Atlas继续延伸这一理念,不仅仅局限于电子商务平台,而是让成立一家企业所需的所有服务都可以通过Atlas实现,如注册、银行开户和虚拟主机托管等。Stripe敏锐地意识到“客户面临的难题”后,对自己的业务模式再次洗牌,从数字支付基础设施供应商变成了一个电子商务平台提供商。

根据客户面临的难题重新对组织定位绝非易事。客户希望其合作伙伴能够简化复杂的运营流程,便于使用。这就需要组织重新架构整个业务领域,识别影响行业发展的难点和资源限制,并提供解决方案。

再举个例子,客户出门在外旅行,晚上需要有个睡觉的地方,他们甚至可能想寻求一些别样的体验,或体会融入社区的自在感。万豪和希尔顿的解决之道是与那些买了地盖了酒店的投资者合作,Airbnb(爱彼迎)则另辟蹊径使用平台思维把每一幢房子或者每一间公寓变成潜在的酒店客房。资源限制(土地)困难没有了,采用平台策略后,客户的选项大大增加。借由平台,Airbnb可以提供新产品组合“Experiences”(体验之旅),满足客户体验和融入社区的需求,例如房东可以提供诸多向导体验,在东京创作街头艺术,组织私人音乐会、采摘松露,或者规划一次酒窖之旅。

科技驱动的企业,平台思维是其核心能力。这些企业可以在平台基础上不断自我进化 ,实现持续创新。平台作为企业构建数字业务能力的基石,可以随企业发展不断更新和演进。比如,Uber对自己平台功能进行了不断革新,通过UberEATS提供送餐服务。与此同时,Youtube也利用自己的基础设施进行自我革新,通过DVR和流媒体功能向客户提供数字电视服务。建立平台减少了基础设施上技术改进的难度和限制,有利于实现快速部署、数据驱动的客户分析和全渠道体验。

平台吸引的内容和消费者越多,其价值就越大。苹果的iPhone能够成功,很大程度上要归功于应用程序开发人员营建的生态系统以及iOS平台上的App。如果要创建网络效应,平台必须调动内容创造人员和消费者进行公平交易的积极性,同时也能随平台价值而获益。

金融组织如何应用平台思维?

这种逻辑在金融服务行业怎么运用?下面是一些应用样例:

平台类公司比传统架构的公司能够更快发布新产品、服务和客户体验的主要原因是公司技术基础的逻辑不同。从本质上来讲,平台类公司就是一个服务库和业务功能库,并以API形式为彼此提供服务。这就是他们无需复杂磨合就能够实现增长的秘诀。做新产品的成本并不意味着一定要承担改变现有产品的成本。新功能应该像是在产品上新搭的一块乐高积木,而不是一大碗意大利面中的又一根面条。

把组织架构为一组自治的、由软件界定的业务能力的集合,对企业来说至关重要,能够帮助企业解除组织复杂性的障碍,提升组织响应速度,真正实现以客户为中心,发挥组织创新潜力。平台思维是智能银行的基石——着手打造智能银行赖以发展的数字平台吧!

点击这里深入了解ThoughtWorks数字平台战略。下篇我们将探讨如何把智能技术嵌入到银行的平台思维中,形成飞轮效应。


文/Aneesh Lele, ThoughtWorks 金融科技 规划主管 、Prashant Gandhi 金融科技 总监咨询师

译/亢江妹 ThoughtWorks 首席咨询师

Share

数字化平台中的客户触点技术

什么是客户触点技术

图1 企业的线上线下多样化触点

随着科技的发展,客户与企业的互动过程中产生了线上线下非常多样化的触点。图1展示了一个啤酒企业在客户生命周期的获知、考虑、购买、留存、传播不同阶段的线上线下触点。不仅仅是啤酒,家电、汽车企业,甚至金融也都类似。全渠道成为新常态,企业需要通过多样化的触点技术向顾客提供随时随地、连贯一致的用户体验。

以亚马逊书店为例,线下也能提供与线上一致的体验,如“一进门的推荐货架”,“每本实体书配有评论卡(Review Card),可以看到读者评论”,“相似图书的推荐(If you like…, you’ll Love)”,“以及与线上的同一价格”。而做到线上线下书店拥有几乎完全一致体验的前提是整个企业需要:

  • 建立对其顾客和目标顾客的唯一、连贯、准确、整体的视图,从而更好地了解和服务顾客;
  • 结合顾客的特征和不同数字渠道的特征建立连贯的内容策略;
  • 在多种渠道之间引导顾客的消费旅程,与顾客产生正确时间、正确地点、正确方式的交互;
  • 基于从各种渠道获得的顾客本人及其行为的数据分析,向顾客提供定制化的内容、服务和产品推荐;
  • 作为必要的技术保障,所有数字渠道的软件应用(尤其是原生的Android和iOS应用)都应该实践持续交付,提供全渠道地快速响应。

客户触点技术解读

单一客户视图和个性化营销

单一客户视图(SCV)是组织对其顾客和目标顾客绘制的唯一、连贯、准确、整体的视图。客户在不同的生命周期中,在不同触点产生不同类型、不同结构的各类数据:人口/家庭特征及联系数据、社交媒体数据、市场活动互动数据、交易数据、用户行为数据,以及其他非结构化的各种数据,如社交媒体上的评价,各类服务请求等。只有当这些异源异构的数据有机的组合在一起,形成“单一客户视图”,才能准确衡量客户的客户终身价值(CLV)、在各个渠道上提供一致的用户体验、更有效地进行交叉销售(Cross-sell)和追加销售(upsell),进而留存客户。

图2 异源异构的客户数据有机组装成“单一客户视图”

一个典型的建立单一客户视图并实现个性化营销的方案,包括:

  • 采用数据流如Kafka、Flume、Flink技术来采集数据进入数据湖;
  • 利用Spark Streaming进行实时数据分析;
  • 数据的清洗、过滤、整合、身份关联,建立单一客户视图;
  • 同时,将相关的产品、销售、订单、渠道触点等信息也通过数据集市展示出来;
  • BI及Analytics分析系统建立智能分析模型如“客户终身价值”、“下一步最佳行动”等;
  • 营销活动系统发起“客户留存”、“交叉销售”、“追加销售”、“最佳渠道”、“潜力客户转化(Most Look Alike)”等营销活动行程进行智能个性化营销。

图3 基于数据湖的单一客户视图和个性化营销的架构方案

内容策略

当多样化的触点形成以后,内容的推送和服务也要相应地在正确的时间、在正确的渠道、推送给准确的目标群体。图4展示了这个逻辑流程:

图4 基于单一客户视图,建立细分客户群体,设计不同内容,在合适的渠道进行推送

比如一个在线购物平台,针对孕妈妈做内容策略:数据显示82%的孕妈妈每周做一次线上咨询,内容类型是可以互 动的、图文结合展示不同孕期内的信息资讯,通过电脑、手机、售货亭、社交网站推送;有67%的孕妈妈则是订阅每周的邮件,内容则是针对性的最新孕期知识;78%的孕妈妈们会经常浏览孕期及产前产后的博客,推送的内容则是不同年龄段孕妈妈写的各种博客。基于单一客户视图,对客户群的细分管理可以采用Adobe Audience Manager;在内容端用Adobe Experience Manager来管理;用Adobe Target和数字化营销系统完成内容定向推送。

跨渠道引流

全渠道时代,用户可以在任一环节便利地切换到最舒服的渠道和触点来继续服务。用户在整个服务过程中得到的信息是透明的、一致的。

图5 一个零售服装企业的跨渠道引流、决策、购买、交付、留存和传播

图6 一个汽车企业的跨渠道引流、决策、购买、交付、留存和传播

在图6展示的汽车企业的例子中,通过移动端营销活动和展示,用户可以继续在移动端、经销商、直营店对钟爱的车型,通过VR看车对车进行深入了解,然后在4S店预约试驾,完成购买。其中,二维码扫描、拍照购物(图片搜索)、虚拟现实/混合现实、在线个性定制等技术是跨渠道引流的支点。

移动应用持续交付

移动应用仍是当前全渠道中的一个核心触点。如果移动应用不能加快交付周期,与Web端做到同步持续交付,就会导致用户在Web端和移动端体验不一致,进而导致客户流失。

事实上,现在应用商店的审核速度已经有了非常大的提升。作为开发者,移动应用可以通过持续集成和自动化测试加快提交审核的速度;当然,我们也有一些技术能够绕过应用商店,直接更新,但是这样有app被下架的风险。

相关的技术方案有:

  • Fastlane是常用的iOS及Android自动构建工具集,功能覆盖了移动应用从创建、证书管理、构建、运行测试、打包到发布整个流程,配置简单、功能完善;
  • 单元测试框架成熟;
  • 使用截图测试来保证我们的UI正确性;
  • 用Appium / Calabash编写运行移动验收测试;

小结

全渠道已是新常态。获取便利舒服的体验、个性化的服务,是消费者的一贯需求。然而现实中所谓的“个性化推送”往往变成了“垃圾信息轰炸”。麦肯锡报告显示,98%的受访社交媒体用户都在社交媒体上收到过广告,但只有18%的人认为收到的推荐“投其所好”。对于线下购物体验,只有10%的消费者表示在店铺得到了个性化的服务或建议。究其原因,重点还是在于客户数据的完整性、连贯性、准确性和统一性。在英国,只有16%的企业拥有有效的单一客户视图。扎实做好单一客户视图这个数据基础,应用合适的内容策略,通过创新的服务设计支持用户在不同触点之间便利流转,移动端持续交付提供透明一致的信息和服务,才能把触点技术发挥到极致,塑造真正的数字化平台消费者体验。

了解更多关于数字平台战略的信息,可下载《数字平台战略》白皮书。


更多精彩商业洞见,请关注微信公众号:ThoughtWorks商业洞见

Share

数字化企业的数据自服务

什么是数据自服务

数据在企业中的处理过程,能清晰地映射出康威定律对IT系统的影响。在各个部门分别建设IT系统、组织内部大量存在信息筒仓(silo)的年代,数据的操作由OLTP应用系统的开发团队同步开发,那时几乎每个政府信息化、企业信息化系统都会有一块“报表需求”。随后众多组织认识到筒仓系统导致信息在组织内不能拉通,不能产生对整体业务流程的洞察,于是开始建设以数据仓库为代表的OLAP系统。

这些系统在支撑更高级、更复杂的数据分析的同时,也对应地在组织中造就了一支专业的“数据团队”。这些人使用非常专业的技术和工具对数据进行提取、转换、装载、建立数据立方、多维钻取、生成报表。这些专业的技术和工具,普通的软件开发人员并没有掌握,因此对数据处理、分析和呈现的变更都必须归集到这个数据团队来完成。结果是,数据团队的backlog里累积了来自各个部门的需求,需求的响应能力下降,IT系统从上线到获得市场洞察的周期变长。

微服务架构鼓励小型的、全功能的团队拥有一个完整的服务(及其对应的业务)。这样的全功能团队不光要开发和运维IT系统,还要能从数据中获得洞察——而且要快,不然就会跟不上市场变化,甚至使一些重要的业务场景无法得到支撑。因此他们不能坐等一支集中式的、缓慢的数据团队来响应他们的需求,他们需要数据自服务能力。 要赋能数据自服务,企业的数字化平台要考虑“两个披萨团队”的下列诉求:

  • 需要定义数据流水线,使数据能够顺畅地流过收集、转换、存储、探索/预测、可视化等阶段,产生业务价值。
  • 需要用实时的架构和API在短时间内处理大量、非结构化的数据,从中获得洞见,并实时影响决策。
  • 为了提高应变能力,系统中的数据不做ETL预处理,而是以“生数据”的形式首先存入数据湖,等有了具体的问题要回答时,再去组织和筛选数据,从中找出答案。
  • 更进一步把数据包装成能供外人使用的数据产品,让第三方从数据中获得新的洞见与价值。
  • 为了支持数据产品的运营,需要实现细粒度授权,针对不同的用户身份,授权访问不同范围的数据。

数据自服务解读

下面是ThoughtWorks的数字平台战略第三个支柱“数据自服务”中所蕴涵的具体内容。

数据流水线设计

所谓流水线,是指用大数据创造价值的整个数据流。流水线从数据采集开始,随后是数据的清洗或过滤,再然后是将数据结构化到存储仓库中以便访问和查询,这之后就可以通过探索或预测的方式从数据中找到业务问题的答案,并可视化呈现出来。

(图片来自:tuplejump Inc.)

一条运转良好的数据流水线,能有效处理移动/物联网等新技术制造出的极其大量的数据,缩短数据从获取到产生洞见的反馈周期,并以开发者友好的方式完成数据各个环节的处理,赋能一体化团队。

数据流水线的实现有两种可能的方式。一种方式是在各个环节采用各种特定的工具,例如前面介绍的数据流水线,各个环节都可以用开源的工具来实现。当然,选择这种方式也并非没有挑战:组织必须自己编写和维护“胶水代码”,把各种专用工具组合成一个内聚的整体。对组织的技术能力有较高的要求。

(图片来自:tuplejump Inc.)

除了基于开源软件实现自己的数据流水线,也可以考虑采用云上的数据流水线PaaS服务,例如DatabricksAWS Data PipelineAzure Data Factory等。这个方式的优点是对技术能力要求较低,缺点则是造成对特定云平台/PaaS提供商的依赖。

实时架构和API

实时的数据架构和API支持短时间内处理大量、非结构化的数据,从中获得洞见,并“实时”影响决策。正如Mike Barlow所说:“这是关于在正确时间做出更好决定并采取行动的能力,例如在顾客刷卡的时候识别信用卡欺诈,或者当顾客在排队结账的时候给个优惠,或者当用户在阅读某篇文章的时候推送某个广告。”

Cloudera的一篇文章中介绍了实时数据处理的4个架构模式,整个流水线架构在Flume/Kafka基础上:

  • 数据流吸收:低延迟将事件持久化到HDFS、HBase、Solr等存储机制
  • 近实时(100毫秒以下)的事件处理:数据到达时立即采取警告、标记、转换、过滤等初步行动
  • 近实时的事件分片处理:与前一个模式类似,但是先对数据分片
  • 复杂而灵活的聚合或机器学习拓扑,使用Spark

数据湖设计

数据湖概念最初提出是在2014年Forbes的一篇文章中。它的概念是:不对数据做提前的“优化”处理,而是直接把生数据存储在容易获得的、便宜的存储环境中;等有了具体的问题要回答时,再去组织和筛选数据,从中找出答案。按照ThoughtWorks技术雷达的定义,数据湖中的数据应该是不可修改(immutable)的。

数据湖试图解决数据仓库几方面的问题:

  • 预先的ETL处理终归会损失信息,如果事后才发现需要生数据中的某些信息、但是这些信息又没有通过ETL进入数据仓库,那么信息就无法寻回了。
  • ETL的编写相当麻烦。数据仓库的schema发生改变,ETL也要跟着改变;应用程序的schema发生改变,ETL也要跟着改变。因此数据仓库通常由一个单独的团队负责,于是形成一个功能团队,响应速度慢。
  • 数据仓库的分析需要专门的技能,大部分应用程序开发者不掌握,再度强化了数据仓库专门团队;而数据仓库团队其实离业务很远,并不能快速准确地响应业务对数据分析的需求。

在数据湖概念背后是康威法则的体现:数据能力与业务需求对齐。它要解决的核心问题是专门的数据仓库团队成为响应力瓶颈。当IT能力与业务需求组合形成一体化团队以后,数据的产生方不再假设未来要解决什么问题,因此也不对数据做预处理,只是直接存储生数据;数据的使用方以通用编程语言(例如Java或Python)来操作数据,从而无需依赖专门的、集中式的数据团队。

数据湖实施的第一步是把生数据存储在廉价的存储介质(可能是HDFS,也可能是S3,或者FTP等)。对于每份生数据,应该有一份元数据描述其来源、用途、和哪些数据相关等等。元数据允许整个组织查看和搜索,让每个一体化团队能够自助式寻找自己需要的数据。任何团队都可以在生数据的基础上开发自己的微服务,微服务处理之后的数据可以作为另一份生数据回到数据湖。维护数据湖的团队只做很少的基础设施工作,生数据的输入和使用都由与业务强关联的开发团队来进行。传统数据仓库的多维分析、报表等功能同样可以作为一个服务接入数据湖。

在实施数据湖的时候,有一种常见的反模式:企业有了一个名义上的数据湖(例如一个非常大的HDFS),但是数据只进不出,成了“数据泥沼”(或数据墓地)。在这种情况下,尽管数据湖的存储做得很棒,但是组织并没有很好地消化这些数据(可能是因为数据科学家不具备分析生数据的技术能力,而是更习惯于传统的、基于数据仓库的分析方式),从而不能很好地兑现数据湖的价值。

数据即产品

数据产品是指将企业已经拥有或能够采集的数据资产,转变成能帮助用户解决具体问题的产品。Forbes列举了几类值得关注的数据产品

  • 用于benchmark的数据
  • 用于推荐系统的数据
  • 用于预测的数据

数据产品是数据资产变现的快速途径。因为数据产品有几个优势:开发快,不需要开发出完整的模型,只要做好数据整理就可以对外提供;顾客面宽,一份数据可以产生多种用途;数据可以再度加工。数据产品给企业创造的收益既可以是直接的(用户想要访问数据或分析时收费)也可以是间接的(提升顾客忠诚度、节省成本、或增加渠道转化率)。

在实现数据产品的时候,不仅要把数据打包,更重要的是提供数据之间的关联。数据产品的供应者需要提出洞见、指导用户做决策,而不仅仅是提供数据点。数据产品需要考虑用户的场景和体验,并在使用过程中不断演进。

细粒度授权

当数据以产品或服务的形式对外提供,企业可能需要针对不同的用户身份,授权访问不同范围的数据,对应不同的服务水平和不同的安全级别。一些典型的细粒度授权的场景可能包括:企业内部和外部用户能够访问的数据范围不同;供应链上不同环节的合作伙伴能够访问的数据范围不同;付费与免费的用户能够访问的数据范围不同;不同会员级别能够访问的数据范围不同等等。

允许访问的数据范围属于数据产品/服务自身的业务规则。《微服务设计》的第9章建议,“[服务]网关可以提供相当有效的粗粒度的身份验证……不过,比允许(或禁止)的特定资源或端点更细粒度的访问控制,可以留给微服务本身来处理”。

小结

为了加速“构建-度量-学习”的精益创业循环,业务与IT共同组成的一体化团队不能依赖于集中式的数据团队来获得对业务的洞察。他们需要规划适宜自己的数据流水线,在必要时引入实时数据架构和API,用数据湖来支撑自服务的数据操作,从而更快、更准确地从数据中获得洞察,影响业务决策。更进一步,数据本身也可以作为产品对内部用户乃至外部用户提供服务,并通过细粒度授权体现服务的差异化和安全性需求。通过建设“数据自服务”这个支柱,企业将真正能够盘活数据资产,使其在创新的数字化业务中发挥更大的价值,这是企业数字化旅程的第三步。

了解更多关于数字平台战略的信息,可下载《数字平台战略》白皮书。


更多精彩商业洞见,请关注微信公众号:ThoughtWorks商业洞见

Share