智能银行(中)

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

组织增长的三种策略

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

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

企业竞争力的双引擎:数字化与敏捷

[摘要]

企业的成功既需要数字化也需要敏捷化。数字化提供更好的用户体验,敏捷激发热情与创新。数字化和敏捷化是天生一对,不能只选其中一个。数字化、敏捷化如何评估?如何才能更加数字化、敏捷化?

人类的进化进入了一个新阶段。科技已成为我们日常生活中不可缺少的一部分, 大部分人离开科技就无法生活。不仅如此,我们对科技的需求还在日渐增长。你能想象一整天不用Wi-Fi、Facebook、Instagram、谷歌或智能手机吗? 对大多数人来说,这肯定难以忍受吧。 我们需要来自各种网站、应用的即时回应。亚马逊、京东等公司已用“翌日送货”乃至“一小时内送货”(只要送货地址在范围之内)这样的服务宠坏了我们。我们需要吸引眼球、容易使用的界面,想我们所想、专为我们而创造的服务。

现在每一个公司都在寻求数字化转型。图1显示了2017年1月至本文写成期间,谷歌搜索“数字化转型”的趋势。很明显,大家对这个话题的兴趣在上涨。

图 1 谷歌搜索“数字化转型”(英文)的趋势

虽然技术是数字化中必不可少的一部分,但它并不是全部。数字化也需要转换商业模式、流程、文化和思维。非技术的部分可以用一个词来总结:敏捷。要适应客户不断变化的需求,就要保持敏捷。

图2显示了2017年1月至本文写成期间,谷歌搜索“敏捷转型”的趋势。可见,“敏捷转型”和“数字化转型”的搜索趋势都是在2014年开始上升的。

图2 谷歌搜索“敏捷转型”的趋势

数字化转型和敏捷转型有很强的关联。举例来说,亚马逊是数字化企业的领头羊,它本来只是一个电子商务网站,但现已成为市值两倍于沃尔玛的巨头。亚马逊没有把利润回报给股东,而是不断投资于创新,创造更好的客户服务。它是为客户而存在的。同时,亚马逊也是敏捷方面的领头羊。杰夫·贝佐斯提出的控制团队人数,以及他著名的“两个披萨”高效团队原则,都是在谈敏捷。

企业的成功既需要数字化也需要敏捷。数字化提供更好的用户体验,敏捷激发热情与创新。数字化和敏捷是天生一对。坦白来说,根本不能只选其中一个。

“数字化”和“敏捷”是动态的、没有终点的比赛

想要数字化转型的企业往往一开始就问什么是“数字化”。虽然对它的定义众说纷纭,但在一些方面存在共识——比如,“数字化是关乎客户的”。数字化的目的是改进客户体验,让他们在达成自己的目标时投入更少。你对客户的服务越好,来找你的客户就越多,这就是真理。

但是,数字化没有一个黄金准则。有一个手机应用,不一定就是数字化公司。其他公司也有他们的数字应用,但并没有因此领先。不过如果你的数字应用很烂,那你就不能算是数字化公司。“数字化”的最低标准是有的,但没有最高标准。

企业和科技都在不断进步,数字化企业的最低标准也在不断提升。不断会有公司打破常规,抬高标准。今日的巨头很可能明日就辉煌不再,如博德斯、柯达等等。企业也是有半衰期的,平均寿命是18年。如果五年来你的公司还在同一个行业,做同样的事情,方法完全不变,就要特别小心了——你需要“颠覆自己”,不然就会被他人颠覆。

沃伦·巴菲特在2015年警告大家小心企业衰退的三要素,告诫波克夏下一任CEO必须与傲慢、官僚主义和自满作战。即使是波克夏这样一家收入超过了新西兰GDP的公司,也要小心谨慎,更不用说其他公司了。对付这致命的“三要素”的方法是公开、透明、激情,这也都是敏捷的基础价值观。

“数字化”(Digital)是个形容词,不是名词。你不能指望数字化有个标准,静态不变。这是一场动态变化的、没有终点的比赛,赛道上有很多竞争者。你需要以竞争对手为基准,来自我衡量。你能做的,只是比他们“更加数字化”。

同理,敏捷也不是个名词,没有最敏捷,只有更敏捷。在这个数字化时代,更数字化、更敏捷的企业才是赢家,也只有赢家才可以生存。

那么,到底是什么需要更数字化、更敏捷?

如果数字化和敏捷的都是形容词,它们形容的名词是什么?这个问题很重要,因为它定义了数字化转型的大框架。在这个框架下,需要找到数字化最少、最不敏捷的地方,让它们更加数字化,更敏捷。名词是你希望数字化、敏捷化的个体或组织。这个组织可以是企业也可以是政府。

图3 数字化、敏捷化的领域

那么,是什么构成了组织?组织运作的部分都是什么?它们是渠道、职能部门、外部合作伙伴、雇员、技术和领导力(见图3)。

渠道——渠道是组织与客户互动的渠道。渠道可以完全是数字化的,也可以物理与数字并存。好的渠道应该做到有用、有意义、知识丰富、无缝、统一、迅速。作为一个客户,我想与企业中那些了解组织也了解我,同时可以提供优质、迅速服务的人互动;我不想跟不同的人,还有讨厌的聊天机器人不断花时间去解释我的需求;我希望立即得到我想要的服务;我费的力气越少,我的感受就越好;不要让我费劲去想、花时间去等。

职能部门——组织中的各个职能部门齐心协力满足顾客的需要。有些可能在一线接待客户,有些可能在后台做不同的工作,有些可能负责管理与合规等等。不管怎样,他们的工作可以更加数字化、更加敏捷。他们的流程如何?采用什么步骤?可不可以省略或者自动化?有没有其他更简洁的方法达到同样效果?职能部门之间的合作能不能改进?职能部门能不能合并或重组,以精简流向客户的价值流?能不能给职能部门更大的权力去更好地服务客户?

合作伙伴——在全球化的今天,没有企业能独立生存。企业需要与伙伴或供应商合作。企业拥有的是哪种关系?是一方需要不断与另一方协商、再协商才能达成合作的关系,还是互利共赢的关系?合作伙伴能否很容易地纳入其中?信息可以顺畅地跨组织分享,还是有很多交流摩擦?沟通不畅、合作不佳,相关的职能部门就需要花时间等待,最终损害的是客户体验。

员工——有满意的员工才有满意的顾客。工作环境如何?工作环境是促进学习和分享,还是加剧孤立?员工需要每时每刻坐在桌前,还是可以在任何地方工作?举例来说,工作现在越来越移动化,员工可能不在桌前,而是用电子设备完成工作。出差和请假申请可以用电子软件批准。不过还不止于此。考虑一下能不能倾听员工的声音,提高员工参与度吧!考虑提供一个能为不同工作需要,提供不同合作空间的数字化职场吧!

技术——这点可能让人惊讶,不过技术管理及操作自身就需要数字化和敏捷。很多时候,信息技术被认为是要花钱的,我们会抱怨为什么一个系统要投入那么多人力,一个改动要花那么长时间。但是,如果我们相信科技是业务成长之源,那就在源头多投资吧:投资工具,也投资相应的人才,使用最新的技术。让你的IT系统成为“持续成长”的系统,而不是“老旧”的、衰退不能用的系统。顺便一提,英语里“老旧”一词是个多义词,它只有在形容IT系统时才作贬义词用。如果你的系统确实很“老旧”,那么,制定更新换代的计划——考虑一下DevOps(开发与运营一体化)模型,或者云端,或者微服务,或者敏捷与持续交付吧。

领导力——或许领导力改变的时候才能发生最深层次的改变。我并不仅仅指领导者,而是说人们领导组织的总体方式。它包括战略、计划、决策、预算、治理和绩效管理。领导者获得了准确的信息吗?雇员愿意提供信息吗?各层领导都愿意倾听吗?不论个人还是组织本身,都在持续学习吗?牢记沃伦·巴菲特的告诫,时刻警惕:傲慢、官僚主义和自满。

你有多数字化,多敏捷?

如上所述,数字化和敏捷是形容词。它们没有静态的定义,而是相对的概念。没有人能说一家公司满足了一组固定的条件,就是一家数字化公司。因此,不要问“我们是不是数字化”,而要问“跟竞争对手或以前相比,我们的企业数字化程度更高了吗?”。另外,数字化包含很多层面,你的企业可能在一个领域非常数字化,但另一个领域却做得不够。这种情况也不能长久。比如说,渠道十分数字化,但员工和技术的数字化成都非常低,就不明智。对于敏捷,道理也是相似的。敏捷也是一个相对的、包含多个层面的形容词。

在这里,我提出了一些衡量数字化和敏捷程度的评估方法,因为这是与时间、与对手赛跑,所以是相对评估。你可以有一些绝对的评估方法,不过即便如此,它们也是在相对场景下才合理。图4展示了这套评估方法。

图4 衡量数字化和敏捷的程度

我想强调这些评估方法只是为引出讨论而提出。当然没有适用于所有组织、所有领域(也就是前面讨论过的渠道、组织单位、合作伙伴等等)的一套标准评估方法。不同的组织和领域,侧重会有不同。因此,我提供的只供参考。

制定一套评估方法的时候,弄清楚你的目标对象非常重要。对渠道,评估对象是客户。一个企业更加数字化(或更加无缝等等),它的转化率就会更高。对职能部门,可以用订单、交货单等等作为评估对象。对员工,评估对象就是员工自己,人才招聘、员工发展才是最重要的。

另外,我的评估没有考虑“方法”,也就是说我并不关心你在使用什么技术。你如何做好顾客工作,达成效果才是最重要的。

这个数字化评估框架,原型是基于电商平台制定的。如果你有一家电商平台,而它比其他电商平台更数字化,我会期望你有更高的客户转化率,更低的客户投入,更高的交付履行速度,更高的推荐精准率,以及更高的客户推荐率。

评估敏捷化程度,我用的是同样的准则。评估的对象主要是变化:对变化的反应有多灵敏,变化后质量有多好,发货速度有多快,团队结构应对变化的速度和效率如何,以及学习速度有多快。

重申一下,我要强调这些评估方法只是为了引出讨论。你需要根据你的组织和领域进行调整。

如何更数字化、更敏捷

渠道,职能部门,外部合作伙伴,员工,科技,还有领导力等领域都可以变得更加数字化、更加敏捷化。虽然每个领域都有细微的差别和独特之处,数字化和敏捷化的方法是相似的,思维也是相似的。我总结了这些不同的方法帮助你变得更加数字化、更加敏捷化(见图五)。这是数字化者和敏捷者的职业工具。

图5 变得更加数字化、更敏捷的方法

先谈谈更加数字化的方法。当然这仅仅是个简介。

首先,利用数据。不要猜测,猜测会带来不必要的风险。你的设计和决策都必须基于相关的、无偏见的数据。设计在线或离线系统时,思考可以获取或收集数据的方法,当然不能侵犯客户隐私。思考在渠道、产品和服务中可以嵌入哪种智能来减少客户投入。

第二,设计思维是研发新产品和新功能时常用的。设计思维是与客户共情,了解需求以及反复改进可行的解决方案,永远追求客户认可。这与传统意义上“我什么都知道”的象牙塔思维的设计是不同的。不断收集数据、信息反馈,设计也持续迭代、改进。

第三,思考你怎样能利用科技民主化。不要限制顾客的操作,相反,向顾客和合作伙伴开放技术,让技术成为顾客的工具箱,顾客可以自行组合工具自助服务,满足需求。这包括开放应用程序接口,公开成果或提供其他自助服务的功能。这就是赋权,给客户赋权。

第四,反思你的价值主张。你还能向客户提供什么?你能更好地在客户和合作伙伴之间建立连接吗?你能重新包装你的产品,或者和合作伙伴的产品重新组合?这就是改变商业模式,它常常需要组织结构的变革。

最后,寻找将你的产品变成平台的机会。利用效应帮助客户放大商业生态系圈。这当然并不容易,需要清晰的价值主张、投资和市场,才能跨越引爆点。需要精心策划,才能保证生态系圈中有一个健康的网络平衡。

踏上数字化之旅,首先你需要变得更敏捷。没有敏捷就不能开始,这就是为什么我们经常看到新企业在做老企业想做却做不到的事情。老企业被官僚主义和自满绊住了。数字化在于改进商业科技的硬件和软件,但是敏捷在于改变员工和领导的心性。

敏捷之路开始于谦虚和勇气,在于承认我们不是什么都知道,而且我们愿意不断学习和适应。学习需要如饥似渴,对现有的所有智慧进行消化。学习也在于不断验证假设和猜想,不断调整,寻找可行的方法。

与敏捷很相似的是精益系统思维。分析整个价值流,去除浪费和瓶颈,或许还要重新设计价值流。精益系统思维常常和设计思维一起使用,但是前者更着重于后台合作,后者更着重于客户触点。

有了科技民主化,权力就会被下放。权力不再集中,相反,决策权会交给前线——创新最多的组织边缘。这对于很多组织来说,需要进行引导和赋权。过去,决策是由几个大人物掌握的,但是现在由很多小人物做决定,为顾客提供更好的服务。

引入颠覆性商业模式,需要改变组织和团队结构。这合乎情理,因为每一个商业模式都有相关联的组织结构。这是现实生活中的康威定律。不过商业模式在变,组织结构也在变。在企业结构方面没有万用灵药。组织结构是动态的,让自治的团队发挥才智满足客户需求,比让你的员工在循规蹈矩恪守工作流程要好得多。

如果数字化平台可以利用客户及其社交群体的网络效应,利用员工的网络效应也是一种创新。提供让不同职位的人合作的机会,这会让你的员工更好地了解公司,也能发掘更好的工作方法。这也能创造更强的归属感,而归属感正是传统企业中缺乏的。

为什么你不够数字化?

最后说一句,苹果公司推出iPhone的时候,诺基亚在研发上花的钱是苹果的九倍。钱和资源并不是关键。除了科技方面投资不善,我怀疑(并无证据)诺基亚当时有潜藏的傲慢、官僚主义和自满。如同每个个人一样,其实就是那句再普通不过的俗语:“骄傲使人落后。”

如果组织中存在某种显而易见的问题,鼓足勇气提出来吧。这个世界不需要假的数字化、纯粹的口舌之劳、或用来装饰门面的数字化。你需要有勇气,坚持,看到问题的核心。问题经常出在人心,也就是为什么敏捷需要先行于数字化,而勇气需要先行于敏捷。

所以,抛弃旧方法,系统地开启数字化的工作,在走向数字化和敏捷的进程中也要运用数字化和敏捷。有了这份勇气,你会得到丰厚回报的。

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


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

Share

数字化企业的API架构治理

前文中我们说到,传统企业在逐步建设自己的数字平台过程中,需要抓住交付基础设施、API和架构治理、数据自服务、创新实验基础设施和监控体系、用户触点技术这五个支柱。今天我们就来谈一谈API、架构治理这些听起来非常技术性的概念与企业的数字化战略之间有何关系。

企业资源服务化

从1990年代起,企业资源计划(ERP)一直是企业信息化的核心议题。植根于供应链管理,ERP通过对企业内部财务会计、制造、进销存等信息流的整合,提升企业的计划能力与控制能力。然而近年来,在互联网的冲击下,传统企业开始面临全新的挑战。尤其是在互联网的去中介化效应影响下,原本在供应链上下游各安其位的企业突然间都被压缩到了“生产-流通-消费”这个极度精简的价值链中。药品购销两票制就是这个极简价值模型的直观呈现。在这个模型中,掌握技术优势和消费者入口的互联网企业有可能形成一家独大的超级垄断,挤死传统的流通企业,把生产企业变成自己的OEM厂商,这是传统企业对来自互联网的竞争者恐惧的根源。

为了对抗互联网企业的竞争,传统企业最好的办法不是硬拼互联网上的技术和流量,而是在自己擅长的领域开战:把自己多年积累的线下资源变成线上服务,构建起本行业的线上生态系统,不仅支撑本企业的线上经营,而且为上下游周边企业提供线上经营的平台,从而把线下优势转化为线上优势,以资源优势对抗技术优势。

为了支撑企业资源的服务化,在设计在线服务的API和架构时需要考虑以下问题:

  • 平台架构和API的设计应该注重开发者体验。
  • 在API的背后,应该从业务功能的角度出发划分合理的限界上下文和服务边界,对外提供高内聚低耦合的服务。
  • 在服务边界之间,应该考虑使用异步的事件机制实现服务之间的通信,来解耦领域模型,客观地描述运行时间比较长、甚至本质上不可能立即完成的操作。
  • 为了方便使用,应该提供API网关作为所有服务使用者的单一入口,在API网关背后去处理众多内部IT系统的复杂性。
  • 整个API架构应该以微服务的风格呈现,避免典型SOA架构中普遍存在的过于复杂的ESB编排逻辑。

ERP之后是什么?

进入2010年代以来,“后ERP时代”这个说法不断被提出。在谈到ERP的发展方向时,通常都会涉及业务与技术两个角度。例如一种观点认为,ERP需要从以流程为中心转变为以客户为中心,并且需要用好云计算、社交网络、大数据和移动化等新技术。

ThoughtWorks认为,ERP在互联网时代的发展方向将是企业资源服务化(Enterprise Resource Servicification,ERS),通过数字平台的技术能力,把一家企业的资源融入一个行业的互联网生态,为企业铺下明确的数字化道路。

API和架构治理解读

下面我们来近距离看看,在“API和架构治理”这顶帽子下面,有哪些具体的问题需要被考虑到。

开发者体验

当企业资源以服务的形式对外提供,也就意味着不可能——像传统的IT系统建设那样——强迫别人使用这些服务。尤其是要把这些服务提供给第三方开发者、希望他们开发出形形色色的应用程序,那么服务的API是否易用就会很大程度上影响它能吸引到多少第三方开发者。ThoughtWorks第16期技术雷达还专门把开发者体验作为一个重要的技术主题。

在讨论开发者体验时,可以从开发工具和开发环境的安装、配置、管理、使用、维护等角度来考量。具体而言,开发环境和测试环境是否能弹性地随需获得,开发/测试基础设施和持续交付流水线是否以源代码的形式提供并完全自动化,是否提供对主流开源软件的支持,是否提供可编程的、命令行友好的(而不仅仅是图形化的)工具界面,安全、数据访问权限等企业规章是否严重影响开发者的效率和感受,这些都是影响开发者体验的要素。

服务边界

和所有的面向对象设计一样,服务的设计应该是高内聚低耦合的:与一个业务相关的修改只在一个服务内部进行,并且一个服务的修改/部署不需要影响其他服务。和一个代码库内部的对象设计不同,每个服务通常有专属的代码库,并且由专人负责维护(而不是所有人拥有所有代码),因此服务边界的改变会带来更大的变更成本。所以,服务边界的划分需要投入精力认真对待。

从设计原则上来说,服务的边界应该体现业务的边界,而不是单纯从技术角度出发划分服务边界。从业务功能的角度出发划分合理的限界上下文,以领域模型和领域事件的聚合为出发点来划分服务,更可能得出与业务边界一致的服务边界。随后再以业务目标驱动建设全功能一体化团队,就能做到业务、技术、团队三者对齐(康威定律再次起作用)。四色建模事件风暴等方法都能有效地实现领域驱动设计,从而建立起良好的领域模型及服务边界。

事件驱动架构

使用异步的事件机制实现服务之间的通信。对于运行时间比较长、甚至本质上不可能立即完成的操作(例如涉及人工操作),使用异步通信是合理的选择。即便不考虑响应的实时性,事件驱动的架构还表达了领域模型之间的松散耦合关系:跨领域的协作以事件而非方法调用的形式来表达,系统追求最终一致性而非强一致性。这一结构准确地映射了真实世界中多支相关但独立的团队之间的协作关系,避免了过度依赖其他服务的响应速度或可靠性等服务质量指标,使服务真正具有技术上的独立性。

在设计系统时,借助事件风暴方法,可以通过领域事件识别出聚合根,进而划分微服务的限界上下文。当出现跨多个聚合根的事件时,可以很自然地将其实现为异步的领域事件,从而获得与领域设计高度吻合的实现。关于如何设计和实现领域事件,可以参阅ThoughtWorks咨询师滕云的文章:《在微服务中使用领域事件》

在实现事件驱动的架构时,当然可以沿用传统的SOA架构中的消息中间件。但由于微服务架构中,业务逻辑都存在于各个服务内部,没有庞大臃肿的ESB(稍后我们还会详谈这个问题),因此消息机制也不需要强大的服务编排(orchestration)能力。RabbitMQ这样标准的消息代理当然很好,也有很多系统(例如Bahmni)采用更简单的做法:领域事件发生时,以ATOM格式发布;关心特定领域事件的其他领域模型则订阅特定的ATOM feed主题。这种基于HTTP的事件传播方式最大的好处就是简单,几乎不需要增加新的软件就可以实现。不过这个方案在处理低延迟的场景时表现不佳。

公共网关

微服务提供的API粒度与客户端的需求不同,所以客户端一个请求经常需要多个服务;服务端和客户端之间可能需要通信协议转换;不同的客户端对数据的需求不同,例如浏览器客户端需要的信息可能多于移动客户端;服务的终端信息(主机+端口)可能变化;不同数据片可能由不同的服务终端来提供——以上这些因素都指出:有必要对服务做一层门面封装,提供API网关作为所有服务使用者的单一入口点。

API网关处理请求的方式有两种:一种是直接代理/路由给合适的服务;另一种是由一个请求扇出/分发给多个服务。API网关可能针对不同客户端提供不同的API,可能包含针对客户端的适配代码。横切需求(例如安全)也可能在API网关实现。

当服务数量变多、API网关变大以后,维护一个通用的API网关会增加API网关层的复杂度,导致一个独立的“API团队”出现,协调和沟通的工作量加大。这时可以考虑引入公共网关的一个变体:为特定前端设计的后端(Backend For Frontend,BFF),即为每个前端应用提供一个单独的API网关,使对齐业务的一体化团队能够拉通前后端开发、而不必等待“API团队”完成他们的backlog。

API网关可以实现为一个独立的服务端应用,其代价则是增加一层复杂度(和出错的可能性)。为了降低这一代价,可以考虑用Zuul等工具来实现API网关。

微服务SOA拓扑

与传统的SOA架构相比,所谓“微服务”最大的特点可能就在于没有一个重量级的ESB。重量级的ESB有其历史原因。在2000年代业界刚开始采用SOA时,很多企业尽管把业务系统包装成了web服务,但IT团队的组织结构并没有发生改变,仍然是由一组人集中式地掌管整个业务流程——只不过系统集成的方式不再是直接的方法调用,而是服务编排(orchestration)。原本存在于集成代码中的复杂逻辑,现在被转移到了ESB中。而这个“ESB团队”成了IT交付的瓶颈:不论发布事件的服务还是消费事件的服务、或是编排逻辑本身的改变,与事件相关的变更都需要通过ESB团队。这个团队的backlog堆积起来,使得每个服务、每个应用都无法提供快速响应。

微服务架构更重视服务与业务的对齐。贝索斯所说的“两个pizza的团队”不仅负责一个IT系统的交付,而且要负责用这个IT系统来支撑一个业务的成功。为了做到单个服务能够独立开发、独立部署、独立运行,这支团队应该能够在很大程度上掌控自己的进度,而不依赖于一个集中式技术团队的进度。因此微服务应该通过服务注册与发现机制获得自己需要的依赖服务、自己判断是否要直接调用或订阅依赖服务的事件,每个服务包含与其业务对应的复杂度,而不是把整个系统的复杂度集中在ESB和编排逻辑上。整个系统的架构(以及团队的架构)应该呈现为若干个端到端拉通的、与业务对齐的纵切服务,而不是一个横切的大块(ESB)覆盖所有业务。

小结

为了激活企业线下资源、打造行业线上生态,IT需要一套有效的服务API和架构治理方法。首先从领域驱动设计入手,划分出合理的限界上下文和服务边界,然后用异步消息机制来描述领域事件。设计好的服务通过API网关或BFF暴露给前端应用,把依赖关系和集成逻辑约束在与业务对齐的一体化团队内部。在整个服务架构的设计中,需要保持对开发者体验的关注。顺畅地将企业资源服务化,这是企业数字化旅程的第二步。

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


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

Share