当我们做区块链时,我们在做什么?

长话短说,我们在建链。

区块链是什么

关于区块链是什么,网络上的解释多如牛毛。这里,我从通常需求的角度总结一下:在记录保存(身份存证)时,它是分布式账本(分布式数据库);在交易或支付(跨境支付)时,它是信任机器。虽然这两种分类方法并不正交,但是对于理解区块链的应用领域有很大的好处。

不论是分布式账本,还是信任机器,其底层的特性——不可篡改、透明、可追溯以及去中心化,最终导向的目的都只有一个,那就是信任。

区块链的可信度来自于人类对数学逻辑严密性的信任,数学理论和加密学实践可以确保链上数据和所有权的可靠程度。区块的确认基于共识算法、不可变的数据结构,再通过 Merkle Tree、Hash Pointer(哈希指针) 保证前向区块链的完整性,再加上经济、人心的博弈、理性经济人假设,共同构成一套完整的信任系统。

然而,企业间的联盟区块链有一些不同,它的信任更多地依赖于发起者品牌的背书。在这样的大环境下,联盟链的设计就变得相当灵活,比如最先腰斩的就是代币。

区块链的行业应用

在工信部最新发表的《2018 年中国区块链产业白皮书》中,区块链产业生态分成了产业应用(包含金融和实体领域),基础设施和平台(如公有链和BaaS),行业服务(如媒体)。而我们的关注点集中在产业应用当中。

金融领域由于本身数字化程度比较高,在证券化以及ABS交易所等方向都有落地案例。在实体产业当中,供应链溯源,身份存证等也多有应用。再加上区块链本身具有“信任穿透”的神奇功效,对于构建供应链金融征信体系,改善小微企业的融资困境也很有帮助。

总体来说,几乎各种产业场景都能应用区块链技术,因为这些场景里都有提升效率,降低成本,优化征信体系的诉求。

汽车金融区块链应用

汽车金融

汽车金融中的核心资产是汽车。汽车金融始终围绕车的生命周期发生金融活动。从零配件的生产,到主机厂制造整车,然后通过各个区域的销售公司将整车卖给各区域内的经销商。实际上在中国,经销商还可以分为不同层级的二三级经销商,最后才到顾客手中。而一旦新车完成销售,就迈入了后市场的广阔天地,以及二手车、三手车的再销售。

从汽车零配件的生产运输和组装到车卖给经销商,这些环节所涉及到的金融活动叫做供应链金融,而顾客通过金融活动来买车,不管是新车还是二手车,都属于消费金融的范畴。

汽车的生命周期和金融公司的参与环节:

它们的业务模式长这样:

通过分析现有业内的业务模式,我们发现:

财务对账成本高昂,且效率不高。这里的财务成本并非某家公司的财务成本,而是整个系统内的财务总成本。仅在中国区可能就有多家销售公司和金融公司,以及几百家经销商,即使每家公司只有两名财务和审计人员,那么财务审计人员都超过一千,更别提全球销售范围内了。

传统的对账方式是怎样的呢?

不同类型的机构进行在对账时,往往要从信息系统中导出电子表格,并用邮件发送。甚至需要打印表格、盖章后邮寄,对方收到后再与系统数据进行比对。

整个业务流程并不复杂,但是消耗了很多人力物力,且中心化的服务还由于对授权机制(多主体之间不太信任或者叫做弱信任)和信息安全等方面的考虑,而导致建设成本高昂,且制约了业务运行效率和用户体验的提升。区块链作为分布式账本,意味着任何机构之间互相发生债务往来的信息都是数据一致的,那么就可以近实时地进行对账。

而我们区块链要做的事情,一言以蔽之,汽车资产上链以及围绕汽车所发生的金融活动而产生的债务的记录。所以不难发现,分布式账本和信任机器在这个场景下都有涉及。

怎么建链

我们把这次建链过程大体总结为5个步骤:识别上链数据,智能合约设计,API设计,部署单元和网络拓扑架构。

  • 识别上链数据指的是识别将哪些交易记在链上;
  • 智能合约设计,指的是买卖车及其相关金融活动如何通过可编程的方式自动完成;
  • API设计,考虑如何对外暴露平台能力,同时限制控制主体;
  • 部署单元和网络部署架构属于实施范围,旨在解答分布式账本如何真正运行在企业当中。

整体技术架构是基于Corda这个分布式账本技术展开的,Corda准确来说不是区块链,而是一种受区块链启发的DLT,即分布式账本技术,它是由金融区块链联盟R3开发和维护的。

上链数据识别

要分析清楚的问题是车在什么时候转移,车在什么参与方之间转移,车在转移的过程中伴随了什么数据的变化。在分析这块业务的时候,我们通过事件风暴,分析了在各个法律参与实体之间发生车转移的业务事件,然后进行了事件排序,通过事件析出数据,包括交易参与方,车的详细信息,车的所有权和占有权以及债等等。这部分数据有一定的取舍,比如订单就不在我们的核心资产当中,所以不上链。

我们开始进行数据建模,在此之前,有必要介绍一下Corda的编程模型——State,因为它会直接影响我们后续的模型设计。Corda中核心概念之一就是State,State是分布式账本上的事实,它代表了交易参与方达成共识的结果。以IOU这个欠条为例,State其实就是欠条关键属性的集合,包含借款方,欠款方,金钱数量,还款截止日期。当欠款部分归还时,这个欠条的内容就会发生变化,变化的方式就是将老的欠条标记成历史的,进而生成包含新内容的欠条。

在我们应用场景中,核心的State就是车和债,因为Corda是运行在JVM上,开发首选语言是Kotlin,所以这里我们直接拿Kotlin中data class对车和债进行建模,而且统一继承了Corda内置的LinearState,LinearState拥有全局唯一ID,在数据演化的过程中不会发生改变。如果有人了解DDD相关概念的话,应该能自动映射到实体概念上。除此之外,Corda中还有一个核心State叫做Fungiable Asset,可以类比成值对象,例如:Cash。

State建模完成之后该怎么演化呢?这就不得不提一个UTXO的概念,UTXO全称 unspent transaction ouput,最开始是比特币网络引入的,它有很多好处,比如可以追溯到每一笔输出的源头,帮助验证是否存在双花现象,Corda一样继承了类似的好处。销售公司把车批发给经销商时,就会将所有权归属自己的车作为交易的输入,产生输出,输出中包含了所有权的变更以及债务的生成。而作为输入的车就会被标记成历史的。这笔交易本身也必须获取到交易双方的签名才能成立。

智能合约设计

上面我们聊到的都是链上的数据以及数据演化过程,不过这些过程都不是自动执行的。对于复杂的金融合约,往往会涉及到多种state的变化,这个时候就必须使用自动化的流程封装这些变化,封装这些变化的东西其实就是智能合约。还是以经销商批发车为例,一个可能的合约模板就是规定车转移的同时产生一笔债,以及对应的还款截止日期。这个合约强制state改变时,交易双方必须参与签名。

在进入智能合约实现之前,需要先了解一下Corda中flow和contract的概念。Flow是Corda中控制参与节点如何更新State的自动化流程,它对如何获取交易对手方的签名进行了封装。一个标准的flow流程包括获取链上数据,创建一笔交易,自签名之后发送到对手方进行交易验证,再签名,最终在双方的账本上分别提交事务。而Contract则是在交易验证环节提供验证所用的脚本。

在我们的应用场景中,智能合约长成这样,在flow中,先从链上取出原有车的数据,拷贝得到一个新的所有权发生转移的车以及对应一笔债;然后通过 txBuilder构建一笔交易,交易的输入是原车,而输出即是新车和债;最后就是验证和签名以及事务提交的过程。你可能已经注意到txBuilder中有个firstNotary的参数,这里提一下notary的概念,notary在corda中是一类特殊的节点,专门用于防止资产双花的问题。所以理论上,每笔交易都需要notary节点参与,并对交易进行签名。在交易验证环节中,我们定义的contract会被执行,这个contract非常简单,简单到只有一个叫做verify的纯函数。它的作用就是断言每一个state的更新是否符合要求。这种设计非常符合Trust But Verify的理念。

API设计

有了智能合约之后,我们就得考虑如何暴露平台的合约能力了。换句话说,从消费者的角度,我们该怎么利用平台提供的能力完成自己的业务。所以这里我们利用了REST API设计的思路,抽象出平台的能力作为资源呈现,定义以车为中心的URI,然后选择合适的HTTP动词,得出 REST api。

从数据上链识别,到智能合约设计,再到API设计,我们在不同层次利用Corda这个分布式账本技术。最底层的分布式账本记录每笔交易发生的事实,不可篡改可追溯;中间的智能合约层提供了合约抽象,甚至可以和现实中的合约一一对应;最上层的REST api以资源的方式呈现了平台的金融活动能力。

部署单元

这样一个汽车金融平台是怎么跑起来的呢?借助Docker,我们把一个物理部署单元打包成了一个镜像,底层是一个全功能的Corda节点,所有的智能合约和state都以jar包的方式部署在这个节点上;同时利用SpringBoot通过RPC的方式连接到Corda节点,调用智能合约,对外暴露REST api;而Corda节点之间则通过消息的方式互相通信。

网络拓扑

打包成docker镜像之后,就可以部署到运行环境中,形成一个分布式账本的P2P网络。这里有2个节点需要留意,最左边的 permission service 是用于对每个入网节点进行证书签发,给予每个参与实体一个身份。中间的Network map类似于微服务中的 service discovery,Corda中节点的互相发现并不是通过广播的方式发生,而是通过注册Network map获取其它节点的信息,进而找到对方。

回顾

最后,我们回顾一下上面的三层架构,用价值的视角重新评估一下整个平台。传统的平台,通过api的方式暴露服务从而获得价值输入,但是区块链平台的核心资产其实在最底层的账本中。基于这些交易事实和债务或者支付记录,我们可以很方便清算各个法律实体的数字资产,计算实时的债务信息,进行车辆的价值溯源,而且未来结合大数据分析和AI,更有可能打造出一个完整的供应链生态。


推荐阅读


更多精彩洞见,请关注微信公众号思特沃克

Share

复用的着相

着相是佛家用语,指的是执着于外相偏离了本质。

仙剑奇侠传中有一个故事。讲的是一个成精了的佛珠。想要让更多的人向佛,于是施法,让这些人失去了记忆,只想一心礼佛。使人向佛,本来是好事,但强人所难,脱离了本质,便是着了相,也可以说反而是入了魔。

这个小故事告诉我们,在认知的世界里,我们很容易被表象所欺骗,忽略了本质。为此,佛家发明了这么一个名词来专门指出这种现象。

复用也是一样。复用本来是通过消除重复的方式。得到一系列可以复用的组件。从而在未来的开发工作中,更快速的响应需求变化,也就是所谓的提升响应力。

然而很多复用的结果,会造成代码是变少了,改起来却更难了。复用是增加了,可读性却下降了。考虑到软件开发是一个团队协作的工作,而我们这个行业的离职率又能到百分之二十之多。难以学习的代码确实是难以维护的,尽管你可以抱怨接手的人无能,但总之是降低了响应力,也就违背了复用的本质。

什么情况下会出现这样的场景呢?主要是因为视角的单一,只从自己单一的视角看到了重复而不是在做全局优化。这个说法可能稍微有些抽象,那我说几个相对具体的情况。

当我们只关注功能视角的时候

需求有很多的描述视角,可以只在功能角度描述,比如“网站要有任务卡,任务卡上有文字版学习内容,视频讲解、也有作业题。”也可以加入业务视角,比如“学生要报名特训营,才能参加特训营。学生进入特训营后,就看到了任务卡列表。学生在任务卡上阅读学习资料,阅读完学习资料后做题来验证他是否学到,做完后提交交由助教审阅。”当我们只看功能视角的时候,可能会忽视业务上的不同,变的在功能角度过分抽象,最后当业务变化的时候,反而响应速度比较弱。

一个简单的后台,我们看起来所有东西长得都一样,不过是列表页面,添加页面修改页面,再加点儿删除什么的功能。说穿了都是crud,干脆我把这事弄成一一个组件好了,每个页面只需要简单配置一下,就可以出来自己的一套增删改查页面。

这种视角完全没有考虑到,不同的实体,它们其实所在的业务是不一样的,关心它们的人也是不一样的。最后,彼此的演化方向也总会出现一些不同,你把它定义成一种东西,对于我每做一个修改,都要背负着其他所有实体的特异性。于是就逐渐拖慢了我改变的速度,降低了响应能力。

无谓的自动化

有追求的程序员一定会考虑提升工作效率,通过一些自动化的手段来缩短流程,提高效率。不过有时候,这种追求也会有害。

在我们的系统里有一个面包屑功能,就是典型的“页面A / 页面B / 页面C”那种面包屑。团队成员提出,一个个页面写面包屑好烦啊,干脆做一个根据URL生成面包屑的功能吧。乍一看好像提高了效率,但实际上URL上的名词和你想显示在面包屑上的名字是可能出现不同的。

比如在我们的场景里,我们提供一个任务卡的预览功能,你的面包屑可能是“xx后台 / xx 训练营管理界面 / xx卡预览”,而学生正式使用任务卡的时候,他可能是 “ 学习中心 / xx 训练营 / xx卡 ”。而他们的url里可能都会出现’/programs/$pid/tasks/$tid’。同样的program、task翻译出来的文字完全不同。你为了支持这点不同,又要扩展一些额外功能来做这种区分,做来做去,可能还不如直接写来的方便,至多抽几个常量来简单的消除一下重复。

当我们只从代码上看重复性的时候

这个我就不举例子了,其实很多犯这个错误的人都是重构的支持者,不过学艺不太精。因为如果你仔细看的话,重构里好多怀味道都有一个跟他对立的怀味道,比如发散式变化和霰弹式修改。如果我们只看代码就会违背复用的本质——更好的响应变化。

这个跟我说的第一个场景,只关注功能视角是类似的问题,这个可能更具象一点,只关注代码。

无视上下文的时候

这个可以看作是只有功能视角的一种情况,很多功能我们觉得有重复性,提升成一个概念,然而其实根本是两个东西,他们只是刚好叫一个名字。

比如过去很多软件里,是有一个统一的用户组概念,不管你在哪个业务上下文里,你都需要扩展这个用户组的概念来管理用户的权限。这个带来的结果就是用户组变得越来越臃肿,每次修改都要改一下别的组的功能。在我们的网校数字平台里,学生学习有学习小组,老师出题有出题小组,这两个小组业务完全不一样,这个时候如果都用统一的用户组来管理的话,那就势必会造成无谓的耦合,损害响应力。

这些故事告诉我们,我们不是在真空里去做复用。我们做的软件都是有它的商业目的。我们的工程实践也都是为商业目的服务的。当我们说tech@core的时候,让我们说技术就是业务的时候。诚然,他给技术人员带来了更多的权利,然而权利越大,责任也越大。技术人员也需要跳出技术,具备更多的业务视角和体验视角。而不仅仅是沉浸在技术得自high当中。才能真正的发挥出各种实践的价值。


更多精彩洞见,请关注微信公众号:思特沃克

Share

数据安全在交付中的思考

2017年7月,Equifax用户数据泄露事件使得1亿4千300万个人信息(包括社会保障号码、出生日期、地址、驾照编号)和20万9千个用户的信用卡数据被盗。该事件直接导致1.43亿美国人的个人信息的破坏和泄露。CEO Richard Smith在数据泄露之后直接提出辞职,公司股价跌幅超过8%,市值蒸发35亿美元。

2016年9月,Yahoo宣布遭遇史上最严重的数据泄露,导致5亿用户的真实姓名、电邮地址、出生日期、电话号码的信息泄露。到了12月,新的数据泄露记录被打破,10亿账户数据被窃取,除了上述那些账户信息被盗外,连安全问题和答案也一起被盗。这两次的数据泄漏使得雅虎的售价降低了3亿5千万美元。

这些问题的原因距离我们并不遥远,Equifax将其数据泄露归咎于应用程序的安全问题,可能在于Java应用程序的开源Apache Struts框架中已知的安全漏洞,在这之前的数据泄露则很多来自SQL注入或者其他的业务逻辑漏洞。

伴随欧盟的通用数据保护条例和新的网络安全法的颁布,数据安全已经成为每个企业和IT从业者都必须要关注的一个话题。而我认为依赖于传统控制论基础上的主动防御和合规理论正在逐渐丧失其领导地位,要解决数据安全的问题,需要有一个场景化的方式,体系化的方案。接下来我们逐一解析。

重中之重的是数据安全的意识,意识是能力的基础,我们只有明确了这件事对于我们业务有价值之后,才能继续后面的方法和过程。上文中的数字已经说明,数据安全对于组织和个人来说都有价值且是必须的事情。Build Security In Our DNA, 我们需要不断增强我们在安全上的意识和理解。

在明确了意识在数据安全中的作用之后,我们需要去定义数据安全到底是什么,国际标准化组织(ISO)对计算机系统安全的定义是:为数据处理系统建立和采用的技术和管理的安全保护,保护计算机硬件、软件和数据不因偶然和恶意的原因遭到破坏、更改和泄露。由此计算机网络的安全可以理解为:通过采用各种技术和管理措施,使网络系统正常运行,从而确保网络数据的可用性、完整性和保密性。

狭义的数据安全是指直接围绕数据的防护技术,主要是指的是数据的访问控制,审计,加密,脱敏等。下面几个举措可以完善数据安全性在系统或者应用构建中的实践。在业务探索和系统设计的环节,我们需要建立以数据安全性为主的分析过程,下面几点需要重点关注一下。

首先,需要明确在当前场景下法律法规的约束和要求

本文以《网络安全法》中的数据安全要求为例。涉及到技术和管理两个方面,概括起来有如下几点:

  1. 对数据访问的日志进行审计,且日志留存时间不低于六个月。
  2. 对数据进行分类,将敏感数据和普通数据区别化处理。
  3. 对重要的数据进行备份,容灾。(第21,34条)
  4. 对重要数据进行加密(第21条,31条)
  5. 对个人信息进行脱敏(第42条)

第二,需要结合数据安全目标和构建整个交付项目的数据安全评估体系

思路如下:

  1. 了解场景,做影响性评估
  2. 数据收集和数据处理的分析
  3. 数据安全实现评估
  4. 数据安全的验证和补救

第三,安全虽然现在已经逐渐和业务紧密结合,出现像态势感知、自适应安全等新的方式,但是从总体上来说,它还是来源于体系化的控制,其核心是识别风险,做出改变。

那整体的业务风险我们需要一个框架来做诠释,这其中包括:

  1. 安全的策略和架构:数据安全在设立之初应该了解到组织对于数据安全的要求,明确哪些是敏感的,哪些是隐私数据,对待不同的数据资产,组织的态度是什么。
  2. 风险,业务连续性和合规:这是控制的方式和目标,在识别差异化之后,我们要了解一些业务上的风险,这部分可以用风险分析的方法了解到业务上的风险所产生的问题,结合与具体应用的场景,需要将风险和技术威胁结合起来。
  3. 数据安全运维:这部分需要在运维或者DevOps阶段考虑到,由于数据本身有生命周期的概念,那作为运维人员,需要考虑更多来自数据完整性上的要求,需要在DevOps和运维环节定期备份数据,需要有如下的措施,第一,在生产环境中要防止机密数据的丢失,第二,需要保护和备份敏感数据。第三,需要能够通过脱敏或者其他措施屏蔽或者加密某些字段。第四,要满足个人数据隐私保护法规的要求,对于个人数据的部分进行删除和屏蔽。
  4. 数据的获取,存储,传输和接入。这是数据生命周期中的主体,也是数据保护的难点,这部分会是我们考虑的重点。
  5. 在数据获取方面我们需要关注所要处理的一些敏感数据,这些数据包括一些敏感的生产数据,知识产权,个人身份识别或受保护的信息。我们在做Discovery和Inception的过程中要处理这些不同的数据,将其分类和定义。过程大概如下,需要对元数据进行分类解析,包括PCI,PII,PHI等等,这些数据的分类和获取,需要经过客户或者用户的同意(注意:GDPR当中已经对这部分有明确的立法)。其次作为敏感的数据以及一些合规数据和日志,这部分的存取和处理,也需格外关注。第三,管理敏感数据的访问方式,谁授予访问,修改和共享敏感数据的权限需要被关注到,这其中包括对于系统用户的验证和授权,还包括对于用户的行为提供监控和审核。这部分在系统设计的时候需要重点考虑。认证方面包括服务器和服务器之间的认证,客户端之间以及用户之间的认证。而在授权方需要对不同的阶段和用户进行响应的认证,在秘钥管理以及用户身份侧进行处理。比如,应用系统采用专用的登录控制模块,对登录用户进行身份标识和鉴别,具有用户身份唯一标识和鉴别信息复杂度检查功能,保证应用系统中不存在重复的用户身份标识,身份鉴别信息不易被冒用。应对同一个用户采用两种或两种以上组合鉴别技术实现用户身份鉴别。
  6. 在云计算环境中,安全问题的形势会变得特别严峻。数据安全和隐私保护是用户关注云技术的两个主要因素。尽管学术界和行业研究了许多关于云计算主题的技术,但数据安全和隐私保护对于政府,工业和商业中的云计算技术的未来发展变得越来越重要。数据安全和隐私保护问题与云架构中的硬件和软件相关。

最后,我想总结一下数据安全策略上的理解和认识,数据安全是通过完整性和机密性的控制来实现总体安全性上的目标,所采用的方案包括身份认证,访问授权和安全审计等措施,在用户,服务以及主机端完成的数据传输的一系列实践。


更多精彩洞见,请关注微信公众号:思特沃克

Share

赋能新零售,企业数据能力建设三部曲

【摘要】

无论是新零售还是Omni-Channel,零售业的本质没有变过,依然是成本、效率和体验,变化的只是着力点的不同。如今,消费者和渠道的协同组合带来了“无界”和“精准”的两大要求。其背后的支撑很大程度上将由企业的数据能力所决定。对于传统零售业,数据能力的建设需要从三个方面进行考量:UNI-ID,数据中台建设,应用场景规划。


新零售的兴起

“未来的十年、二十年,没有电子商务这一说,只有新零售 。”这是马云在2016年的云栖大会上提出的,也是“新零售”这个词第一次出现在人们的视野里,一时间似乎每家品牌商/零售商都在思考自身的新零售转型。

如今,新零售已成为了一个老生常谈的名词。我们也观察到:

  1. 新零售领域正在通过连通全域数据、重构整体交互的方式来实现传统人、货、场三者的关系。
  2. 传统零售模式面临着数据割裂的状态,无法实现品牌商与零售商、零售商与消费者、消费者与产品、产品与服务四个环节的联通,形成闭环。
  3. 电商巨头玩家的进入对新零售的整体架构进行了重组及再融合。

在整个新零售领域,由电商平台,互联网巨头,以及传统零售商扮演的玩家开始通过电商模式创新、线下模式创新和融合创新模式尝试新零售下的不同实践。

在这样的大环境下,新风口、新技术、新物种、新玩法不断涌现,资本、新玩家不断涌入,零售行业呈现出了多年来未见的活跃气氛。越来越多的品牌商开始强调以“消费者”为核心,他们希望了解消费者的心理并投其所好,提高经营效益。甚至连奢侈品牌也不得不放低他们高冷的姿态,开始关心起了流量,线上购买和小程序。

新零售的本质

同西方150年以来爆发的零售革命一样,中国从20世纪90年代中期开始,也爆发了一场综合性的零售革命。但无论是百货商店 、连锁商店、超级市场还是电子商务等不同形式,不同阶段的零售发展始终围绕着“成本、效率和体验”展开。

从新零售的特点上来看,我们将其归纳为:线上线下同品同质同价。其中体现了成本、效率和体验的全方位融合。为了实现这一融合,在新零售的背景下,渠道依然是核心的要素。线上企业与线下商家的全方位合作即是对渠道概念的进一步拓展,更是对渠道作用的再一次升级。

消费主权时代的到来使得需求越来越个性化和多元化。消费者的关注点从性价比、产品功能等共性特征转向美学设计、价值标签等个性特征,这对产品和零售的适配度提出了更高的要求。消费者正在扮演更加积极的角色,从被动接受和选择到主动影响和创造。这也让品牌方不得不从品牌为中心转变为以消费者为中心。如何整合碎片化的媒介渠道,提供一体化的购物体验,逐渐成为他们真正关心的内容,

零售业的本质没有变过,依然是成本、效率和体验,变化的只是着力点的不同。新零售时代,消费者和渠道的协同组合带来了“无界”和“精准”的两大要求。其背后的支撑很大程度上将由企业的数据能力所决定。

传统零售的数据困局

为了更好的理解传统零售的数据困局,让我们先来看两个例子:

家乐福

1995年进入中国的家乐福,以主打线下商超为主。2009年家乐福营业额开始下滑,但直到2016年底,家乐福才开始试水APP和线上购物等尝试。但是APP的体验反馈相当差,缺少用户数据和浏览行为跟踪,无法有效的将线下的流量吸引到线上。商品方面,品类相对固定,无法提供网红产品。物流方面,不具备自有物流的能力,所以面对新零售的体验,家乐福在消费者,商品销售和物流效率的体验上都非常的差。对市民特别是年轻人的吸引力明显不足。运营模式日渐丧失其应有的活力。

盒马鲜生

2015年成立后,利用两年多的时间打造了独有的“新零售”商业模式,在2017年底开设了25家门店。盒马鲜生的商业模式来自于线上线下的整合模式:通过实体门店实现建设品牌与引流、提升消费体验、同时还作为仓储物流中心,而线下APP则成为主要销售渠道以及搜集与分析消费者的界面。另外,盒马鲜生基于“吃”的应用场景,把超市跟餐饮结合,建立新零售业态。

根据普华永道2017年零售业的调查,约52%的中国消费者通过移动设备或智能手机购物,41%的中国消费者通过社交平台获取促销信息。相比之下,这一数字在全球仅达到14%和34%。(数据来源:pwc《中国零售业: 智慧开启未来》)随着时间成本的提升,以及大量信息来源可供选择,国内消费者碎片化购物已成为常态。

传统零售业迫切的希望跟上新零售的主航道,但当他们尝试转型的时候,却发现了渠道分散、客户体验不一、成本上升、利润空间压缩等多个困局。当提及传统零售企业面临的巨大挑战时,30%的决策者认为受限于预算,21%认为太多遗留系统需要变更,20%认为难以和现有系统集成。(数据来源:pwc《中国零售业: 智慧开启未来》)

那么是什么造成了这些困局?又是什么让传统品牌商/零售商无法有效的整合自身的渠道资源,更好的实现以消费者为中心?为什么有着互联网基因的零售企业就能打破这些困局呢?

答案或许正是传统品牌商/零售商过早的拥抱了现代化IT建设。其庞大厚重的IT基础设施无法支撑全渠道时代下,随需应变的数据能力要求。

比起有着互联网基因的零售企业,他们更早的采用了商业套件,更早的使用传统的ERP,CRM等系统,通过数据仓库来管理企业的商品数据,客户数据,企业运营等数据。这些数据之间以相对独立的方式运行了几十年,横向扩展性差,数据拉通性也不够理想,最终造成的是实体门店、电商(自建官方商城或入驻平台)、社交自媒体内容平台、CRM会员系统的数据割裂严重。为了满足新零售时代下对于消费者和渠道利用的要求,传统品牌商/零售商开始被迫的使用独立部署的方式响应业务发展带来的需求。应用烟囱一个接一个的竖起。让本身就无法实现数据拉通的IT架构雪上加霜。

对于IT部门,他们有心无力,既缺乏转型的技术能力,又得不到企业内部的有效重视。对于业务部门,缺少有力的IT能力的支持,创新的业务实践也无法快速展开,更别提拥抱新零售了。

突围困局:建立数据能力

今天,以数据智能推进品牌建设,精准运营用户,已经是全球众多品牌的“战略标配”。数据越精准,企业产品开发的风险便越小,生产成本和损耗也会变得更低。同时,企业对消费者的感知也会更精确,营销费用也比较低。而这些数据,靠传统渠道是无法获知的。

新零售体系下,要求传统品牌商/零售商以消费者运营为核心,以数据为能源,实现全链路、全媒体、全数据、全渠道的智能化运营。从上图的零售业数据应用金字塔模型中我们能看到,用户唯一ID(用户画像),数据拉通能力是企业进行业务运营(成本,效率),用户洞察与体验优化(体验)的基石。因此,对于传统零售业,数据能力的建设需要从三个方面进行考量:UNI-ID,数据中台建设,应用场景规划。

UNI-ID(统一身份识别体系)

目的

品牌商/零售商想要了解他们的顾客,必须先回答以下6个问题:

  • WHO——顾客是谁,他们到底长什么样子,有什么偏好?
  • WHEN——他们一般什么时候来,多长时间来一次,一次来多久?
  • WHERE——他们一般都会去哪些位置,这些位置之间有什么联系
  • WHAT——他们来的时候都做了一些什么事情
  • WHY——为什么要做?可不可以不做?有没有替代方案?
  • HOW ——他们是怎么做这些事情的?如何提高效率?如何实施?方法是什么?

在全渠道时代,这些问题的答案分布在不同的消费,行为,兴趣,社交等数据中。为了勾勒出真实的用户,我们就需要建立基于消费个体/群的身份识别体系。汇聚碎片化的用户信息,对应到个人/群体,才能360度地描绘出基于消费个体/群的画像,帮助企业更好地进行消费者资产管理。进而对这个虚拟的人进行全景分析,分析内容兴趣偏好、购买偏好、态度偏好等,基于这些数据,为品牌的决策提供数据支持。

做法

很多企业的管理者都已经意识到,在新零售的环境下,不仅要采集用户的线上数据,更需要采集线下的数据,这样才能让用户的行为数据从独立的信息孤岛,真正串联起来,实现由点到面的质变。

为了实现UNI-ID,可以从两种方式进行切入:

运营驱动型UNI-ID

不是每一个传统的品牌商/零售商都可以一蹴而就的实现UNI-ID的能力建设。面对割裂严重,甚至是残缺少量的用户数据,企业需要一个较长的改造过程。在这期间,回归本源,通过运营流程的设计引导用户按企业希望的方式提供关联性数据,可能是一个更加理性和有效的方式。

所谓的运营驱动型UNI-ID,是指品牌商/零售商先以可作为唯一ID的手机号码或者身份证号来标识不同的顾客;通过对现有渠道数据采集方式和内容的梳理,分析线上、线下不同用户触点间为了达到统一身份识别所存在的差异;针对这些差异,设计对应的运营流程来补全缺失的数据。如:线下表单注册,到店注册好礼,手机互动等。逐渐积累数据过渡到以数据驱动的UNI-ID的建设上来。

数据驱动型UNI-ID

数据驱动的UNI-ID属于相对高阶的玩法,需要企业已经积累了一定量的消费者数据,且在多个渠道上有不同的触点可以不断跟踪获取消费者行为的增量数据(如:Wi-Fi指纹、MEMS、蓝牙推送、NFC会员卡、3D传感+视频监控、线上埋点等)。

在建立UNI-ID体系的时候,不再需要通过手机号码或身份证号这些信息来形成用户唯一标识(当然,如果存在,效果更好),而是通过采集所有消费者账号、行为数据等重构为一个虚拟的人。通过数据分析、机器学习等技术对用户建模,将增量的用户行为数据归并到虚拟消费者身上,随着行为的越来越多,数据越来愈大,标签越来越多,这个虚拟消费者就会越来越趋近于真实世界的那个他。

数据中台

目的

无论是UNI-ID,还是智能零售应用,它们都需要依靠底层打通的数据进行支撑,这点十分考验品牌商/零售商对数据采集、整理、分析和应用的能力。所以数据中台的建设是企业避不开的环节,也是悬在企业头上的达摩克利斯之剑。

数据中台为品牌商/零售商提供了一个场所和工具,以数据-业务一体化为核心,将跟品牌,消费者相关的多维度数据,沉淀到数据中台中形成数据资产,通过数据的闭环能力进行分析、再利用和再营销,帮助实现营销和用户运营的再优化。

新零售时代,不再区隔线上和线下消费者,消费者与品牌商/零售商互动的过程,跨越了实体渠道和数字化渠道的多个触点。因此,在架构上,要求把零售主数据(包括:商品、顾客、价格)、动态数据(包括:库存、订单)集中处理,沉淀到数据中台中,作为唯一可信数据来源的数据中台在其中可以对接多样的业务前端,支持业务前端的灵活变化,将这些功能从相对死板的ERP,CRM中解放出来,解决了商业套件不适应全渠道时代的问题。

做法

数据中台的架构大同小异,相信很多传统品牌商/零售商已经听出了茧。但同时,他们又对平台,中台等词汇有着一种抵触的情绪,觉得太大了,太重了。其中牵涉到的业务环节太多了,可谓牵一发而动全身。甚至连阿里巴巴如此雄厚的技术能力,也需要花费多年,投入巨大的财力和精力才成功的完成了数据中台的转型。传统品牌商/零售商的IT能力本身就相对薄弱,所以虽然知道了概念,理解了数据中台能带来的好处,但是迟迟未曾有实际的动作。

其次,现成的一些平台套件也无法完全满足传统零售差异化的业务需求,所以势必需要企业采用完全定制化的做法。数据和智能创新所带来的不确定进一步让品牌商/零售商裹足不前。

数据资产的安全性又是另一方面的考量,不得不承认阿里中台能力的对外开放,能够帮助传统品牌商/零售商快速建立数据中台的相应能力,但如果从长远来看,企业的数据无法沉淀下来为己所用,数据安全性上的担忧势必要求企业进行取舍。

面对这样的一种业界需求,ThoughtWorks结合自身多年来在敏捷实践和微服务架构的技术能力,采用精益数据资产中台的方案,帮助企业完全定制化的快速建立数据中台的基础能力,通过后续的迭代演进,为企业实现数据资产的沉淀。

将原本横向叠加的建设方式演变为纵向切分,逐步完善。 MVP阶段就能满足基本的数据应用能力。 轻量、敏捷的部署方式让企业能够快速试错,迅速建立数据中台能力。

应用场景的数据化

目的

无论是盒马鲜生、超级物种、连咖啡,还是小米之家等,这些“新物种”无一不是基于消费者的场景化需求而出现的。电子小票、专属导购客服、客户到店数据采集也是诸多应用场景的成功实践。

定位到正确的场景,就是成功了一半。品牌商/零售商之所以要做UNI-ID,要建设数据中台,要搭建智能应用,其目的都是为了实现应用场景的下沉。所以无论数据中台搭建得多么强大,UNI-ID体系建设得多么完善,没有应用场景的支撑,数据就只是存储着的0和1而已,没有任何商业价值。

同时,有了成功的应用场景,消费者才愿意与品牌商/零售商进行互动,有效的互动过程中,才能帮助企业拿到真实的用户数据,反哺和优化现有的“人-货-场”数据资产,让其发挥更高的价值。

做法

应用场景的规划不是天马行空式的,需要符合企业的战略发展,满足未来落地的实际需求。品牌商/零售商在面对行业中不断涌现的“新玩法”,“新物种”时,总有一颗跃跃欲试的心,此时更要求决策者们冷静的思考,根据实际的需求,现状和数据能力判断投入和产出。

长期的实践让我们对于这样的规划形成了一套独有的探索-定义-验证-规划的方法。能够帮助品牌商/零售商从战略的角度出发,结合自身的业务现状进行理性的调研和分析,通过发散-收敛的循环往复,勾勒出应用场景的雏形。 对数据的探索和关联成为了数据化应用场景的关键,这一过程中涉及诸如:内部数据的勘查,外部数据的调研,数据成熟度分析,数据的场景化匹配等内容。

下图展示了一个应用场景的规划所涉及的内容(参考):

效益指数和紧迫性指数将决定着应用场景列表中有哪些场景是需要优先被测试模拟的。通过POC验证高优先级的应用场景,便于对数据需求进行调整和优化。通过创建-设计-定义-测试的闭环进行迭代后,最终形成了数据化后的应用场景。

结语

零售业是一个数据密集的行业,商品、供应链以及用户挖掘等方面有极多的数据应用。除了上文提到的UNI-ID、数据中台和应用场景,品牌商和大型零售企业还需要关注数据治理,数据安全等多个新零售时代下的难题。

在传统零售时代,从产品的规划设计到送达消费者使用的整个供应链中,我们依靠人力来做出联动和商业决策,自然会流失很多的商机。也无法整体发掘我们为消费者带来的价值。

在新零售时代,品牌商/零售商端到端的转型已迫在眉睫。在通过数字赋能优化决策和转型的过程中,数据令品牌能够快速反应,及时改进销售策略、调整产品。

数据能力决定了谁能把握新零售的机会,谁又将被历史所淘汰。


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

Share