去搜搜
头像
如何避免企业数字化转型的6个坑
2020-09-08 16:42

如何避免企业数字化转型的6个坑

文章所属专栏 活动实录

虎嗅Pro注:在2015年,阿里提出数据中台的概念。不过到去年下半年,各大互联网巨头才纷纷跟进,开始建设数据中台。很多传统企业也寄希望于中台能够帮助自己顺利完成数字化转型,但是很多人可能至今也说不清楚中台究竟是什么,以至于鲜有成功的案例。这是因为传统企业与互联网企业之间一直存在着一条鸿沟——“互联网思维”。

 

虎跑大咖说,每周一个Know-How,8月17日,我们有幸邀请到奇点云副总裁、数字化转型战略专家何夕来做一个关于数据中台的分享,帮助大家更深入地了解企业的数字化转型,直播内容呈现于下文。

 

何夕:各位虎嗅的朋友们晚上好,我是奇点云的何夕。这次我分享的主题叫做数据驱动的企业数字化转型。接下来,我会拆解模块,讲解实际项目案例中,我们解决了什么问题,然后一步一步展开帮助大家理解数字化转型,理解中台的意义。

 

数字化转型中的难题

 

在我们与企业高层交流时,大家都会提到两个难题:

 

第一个是每个部门每个人对数字化转型都有着自己的定义。比如,从财务总的角度出发的数字化转型与从业务总的角度出发的就不一样。财务总更多的是讲他的底线,他希望有一个数仓或者数据平台能把所有的业务数据集中过来,然后就能拿收入数据、财务数据和业务数据一起来提供分析能力。而业务总更想知道的是数字化转型能不能帮助他做好运营管理、提升业务。所以第一步就是在数据中台整个的建设过程中,我们首先要去看大家对于数字化转型、对于数据中台、对于信息技术、对于信息商业、对于社会是否有一个统一性的认知。



在过去的十年中,整个技术底座发生了很大的变迁。原来很多时候还是从硬件软件、系统、流程这些角度去描述技术底座,但是今天我们回头看过去的10年,会发现它真正的底座就是云计算、大数据和人工智能,然后在这个基础上形成了算力、算法和数据,并逐渐成为信息技术的一个核心驱动力量。可以看这张图,就是在过去10年最大的一个变化就是算力替代了体力和脑力成为最大的驱动力量。

 

数字化转型的未来清晰地指向人工智能的发展,那么什么是人工智能?人工智能就是让人做人该做的事情,让机器做机器该做的事情,然后人类和机器脑力协同。人类应该做就是思考决策和创新,其他所有高频的、重复的和机械式的劳动都交给机器来完成,这就是机器代替人,算法代替经验公式。

 

第二个是缺少大环境性的认知。就像富足这本书里讲的:当人类社会的生产资料从供不应求到供过于求的时候,会给我们的社会和商业逻辑带来巨大的变化。那么如果数据从供不应求到了供过于求会是什么样的状态?其实这个事情才发生不到5年,最标志性就是2015年一年产生的数据量是人类过去历史上产生数据量的总和,并且15年以后每年的数据量都是以40%—50%的速度增长,换句话说大概每18个月就可以翻一番,你甚至可以把它称为一个数据的摩尔定律。而这种指数级的增长给当时阿里带来了一个核心的矛盾,就是日益增长的数据存储费用和仍然稀缺的数据应用之间的矛盾。简单的说就是花了很多的钱去做存储和计算,但是并没有从数据增长中获得利益。

 

阿里巴巴如何跨越数据指数级增长奇点

 


2007年的时候,阿里下了一个战略决心就是要建成电子商务生态,要成为数据公司。

 

2009年以前,阿里典型的特征主要还是用数据来处理事务问题,就是如何高效率的连接买家和卖家,更多的还是在做OLTP(联机事务处理)。小二成立到05年的时候,已经有很多小二提出了一些需求:希望是能通过数据看见这个过程里面发生了什么事情,什么样的用户通过什么渠道到淘宝上来购买了什么东西,他的爱好是什么,一口气会买多少东西,购买频率是多少......类似这种事后追溯型的一些分析需求。所以在2005年阿里建立了第一个数仓,也就是奇点云创始人行在(张金银)建立的。在2012年之前,需求属于逐渐集中的状态,整个BI对存储和计算的消耗都很大,它典型的一个指标是2012年阿里有50%的服务器是用于处理数据,而不是处理业务。在此之前的整个阶段我们都称为看见的阶段,意思是能用数据看见发生了什么、怎么发生的。阿里因此进入了一个数据的快速上升通道,这是与数据平台部成立密不可分的。

 

在2012年时数据平台部成立,并且诞生了一个叫TCIF淘宝消费者信息工厂项目,它第一次拉通了阿里所有的消费者数据,形成了One-ID。One-ID是用来做什么的呢?2012年以前做投放最有效的方式是全渠道通投,比如说我是做母婴的,如果把Top20的母婴网站全部都投一遍,一定能覆盖到我的目标用户。但是有了One-ID以后,就能知道这20个网站背后可能有1个人有20个账号。假设他每个网站都有账号,共20个账号。这20个账号背后就1个人,这个人上午去a网站,下午去b网站,晚上去c网站,那么我只需要一天投这三个网站就可以了。这就是人群定向。

 

在这个基础上,TCIF还做了3000个底层标签,再把这些标签贴回到人身上。然后我们发现消费者并不仅仅只有一种属性。我们可以知道他听什么音乐、看什么电视等等喜好,所以阿里就具备了用数据去预测未来的能力,因为知道了用户的喜好,我们甚至可以对他所在的群体去进行一些价值观的还原,从而预测他接下来的购买动作。这个时候最典型的一个指标就是人群定向对于存储和计算消耗超过了BI。

 

到了2015年,阿里做了千人千面的推荐算法。今天每个人打开手机淘宝看到的页面都是不一样的,在点击或者进行了一系列的浏览以后,看到的结果也不一样的。这个就是今天被广泛使用的推荐算法。包括美团还有很多公司的商业模式都建立在推荐算法之上,但这个时间点上,阿里最重要的能力之一是从人指挥机器到机器指挥人,比如流量分配、主会场的设置等在2015年以后就彻底交给了机器。

 

2019年至今,阿里有70%以上的GMV都是由机器来运营的。当时在用数据去分析运营小二的时候,我们发现其中50%的报表都是固定的,所以就考虑用机器来处理这些高频、重复的工作。在这个基础下就催生出了我们的算法,进一步地解放了人。

 

这些就是阿里整个的跨越过程,可以看出它从一开始处理事务性的工作,到现在用数据来预测未来,最后实现用机器赋能整个商业,从而解放人去做思考决策和创新。

 

是否上中台?你得考虑这些

 


你是否真的有数据中台的需求?有很多文章讲一些关于数据中台的项目失败,那是因为这些项目很大程度上只是为了上数据中台,但是在上面并没有产生任何的应用,所以一定要搞清楚自身是否有数据中台的需求。可以从以下几个因素去考量:

 

第一是生产方式有没有发生大的变化。传统的生产方式是先生产后消费,茅台就是这样,先研发出来再去生产,之后就直接用铺货、渠道的方式去消费给客户。然而进入到信息社会后,用户和制造的关系发生了巨大的变化,用户被前置了。现在的预售,都是先去跟用户产生了相应的沟通了解,包括今天可以通过数据去洞察用户、分析用户,都是把用户前置了。举个例子,阿里最早起来的一个买手店“天使之城”,老板就去全世界游荡拍摄下他认为好看的衣服,并且把这些照片丢到会员群里让会员选择喜欢的衣服,被选择最多的就会拿到工厂进行调查式的生产,之后便快速上架、发货。这就是一个很典型的先进行信息处理,再进行物质处理的变化,如果说你的公司并没有发生这样大的变化,也就是并没有把用户前置、但仍然有很不错的盈利就是没有数据动态需求的。

 

第二是两头碎片化,即需求碎片化与供给端碎片化。关于需求碎片化,因为像SNS、电子商务,包括移动兴起,消费者都是可以一对一地与品牌沟通和随时随地发起交流的需求。这种个性化、多样化的消费需求海量涌现,光一个微信就可能使品牌与消费者达成几十到上百个触点,我们将这种碎片化需求称为海量个性化,这是传统的信息管理和服务架构没办法满足的。再来说说供给端的碎片化,过去我们买麦片只有大中小微4种包装,但是麦片会去做节庆营销、事件营销、跨界营销或者新包装的开发就会有各种各样的包装。那么在碎片化的供给和碎片化的需求之间,就产生了大规模精细化匹配和连接的需求,这并不是人能解决的,而是需要通过算法匹配引擎来处理。

 

如果说某家公司在供给端或需求端出现了这种大规模精细化匹配和连接的需求,那么这家公司就是有实际的数据状态需求,我们就会把它整个信息系统的升级过程称为新四化,即云化、服务化、数据化和智能化。还有一类公司一直以来都是用人来处理不确定性,就是凭借的头脑、经验去进行运行规律化、规律模型化和手工建模。但是今天我们会看到很多的公司因为数据采集手段变得丰富,数据分析维度也会急剧上升。一般来说,一个人能分析的数据维度不会超过20个,但在消费者运营端、客户分析端需要分析的数据是几十上百个的,这个时候就需要用算法代替个人需要把这些模型算法化。比如,过去做数据分析全部采用人工的方式来做:数据采集、数据清洗、手工打标、透视分析以及做可视化,最后才去向领导汇报,但这其中真正需要人的头脑去参与的只有一个环节——透视和分析。

 

所以我们可以认为算力就是新生产力,算法是新生产关系,数据是新的生产资料。

 

不同视角下的数字化实践路径

 

下面进入到数据中台实际实施之前,我们通常会先帮企业去做一些判定。如果之前企业已经做了很多数字化转型的工作,但是并没有满足在战略目标上的需求,那么这中间一定是存在差距的,我们需要去厘清这个差距,清晰地定位自己,才能找到接下来的策略和路径。

 

今天凡是进行过数字化转型的公司面临的其实都是数据问题,它们算法底下采集到的数据可能有一半是空值,这种算法是无用的。还有很多公司上了很多AIoT的设备,做了很多行为数据采集,但是他们并不知道这些数据该拿来干什么。这是经常会碰到的数据不通、数据不可用的问题。

 

出现这些问题很可能因为忽视了数据在这个过程中真正产生的作用。所以我们与企业老板交流时会问:人力资产跟数据资产是不是同等重要?答案是同等重要。人力资产有团队、工具、系统、咨询公司、方法论和问卷调研,但数据资产什么都没有。这个是如今大量企业转型所面临的现状,包括数据相关的一些问题,比如有没有数字化相关的KPI;能否衡量数据的投入产出比;是否具备相关的数据战略等等。所以要做好数据中台,首先就需要把数据重要性提升到战略高度来看待。

 

数据中台包含了两层意思,第一层意思是它是一个中间的平台,它能对业务和技术重合的部分进行能力的沉淀,并且不断复用。它在后台与中前台之间作为一个中间的平台,这就是它的功能。第二层意思是它是一个中立的平台,它解决的是数据的可信度问题。可以把数据中台理解成一个大型的这种数据的生产工厂,它把数据采集和处理的过程拆分成一个个流水线,在流程中通过建立一个内部第三方的角色让大家来信任我的数据。所以在做数据中台之前一定要去思考自身业务问题、组织问题和认知问题。

 

因此我们会先帮来咨询的公司理清这个问题,才会提出相应的对策。

 


目前来看,有三种不同的实践路径。第一种路径叫业务先行,小步快跑,这是95%的企业都会选择的一个路径。他们可能知道上数据中台很重要,也知道要去做很多相关工作,却不能很好地向领导去证明这件事情是有成果的,所以在立项上是有困难的。这95%的企业所使用的方式,其实是叫明星项目驱动。举个例子,对于大多数的集团公司而言,管理驾驶舱就是一个非常实战的明星项目,他需要给领导看数据成果。但是需要提前半个月来处理上半年的数据,接下来半个月产生的新数据只能通过手工的方式补进来。所以当领导看到这份报表的时候,已经是半个月以后了,不仅时间上不够及时,并且因为手工添加的原因会存在一定的准确性问题。在这个基础上,如果你能给领导提供一个T+1的管理驾驶舱,在领导每天上班之前,就将已经处理好的前一天数据放在他桌上,那么领导就会对这个数据对于业务的作用有了极强的认知,便会批准推动业务的数据运用,进而去解决后面的整个技术架构、技术基础设施的建设问题和未来机器智能的问题。

 

第二种路径叫技术先行,少数公司会采用这种路径。这些公司知道数据中台很重要,所以会先去推动数据中台项目的立项和进行数据中台的建设,希望能用数据生态来实现一个快速的发展。但是有的企业会出现这样的问题,仅仅是为了上中台而上中台,业务并不会买账。我们曾经接触到的一家公司在IT方面非常有能力,在底下去做了1万个关于客户的融合标签,但是在业务端使用的不超过4个标签。原因是IT和业务在理解数据应用方面有巨大的差距。所以我们推荐在你的数据中台上一定要有真正能帮业务解决问题的应用,能用数据去分析洞察,再产生相应的决策,这样业务自然会反过来支持技术往前走。

 

还有一种实践路径非常少见叫组织先行的路径,目前为止只有阿里和华为在做,这种路径是在所有的业务技术推进之前,会先去解组织的问题。举个例子,当时马云提出新零售以后,最先动起来的是阿里整个hr的组织。一周之后,在整个阿里的hr体系里面就出现了一条叫hr新零售线,先进行了组织的调整,才进行了相应业务的调整。从数据化实践的角度来看,这恰恰是长期投入成本最低的方式。

 

量化工具与案例分享

 

首先介绍一下量化工具。所有的企业家或者管理层都想知道自己和一流企业有多大差距,还有数据情况。这个时候我们需要一个温度计,比如说我们自己所使用是“360度数据管家”,一套成熟度评估体系。经过这个体系评估后,阿里大概是在90-95分,大部分传统企业在20-30分,这个是和一流之间有差距。如果他的同行在40-50分的水平,而自己只有20-30分,这个就叫和同行有差距。在这个过程中我们需要去量化和解决的一些问题。在做资产盘点时,也需要去看总量、整个数据的分布和数据的增量,才能更好地做出数据决策。

 

包括像现在我们提供的“端到端”的咨询服务,不仅要向公司去提供策略和路径,方法论是什么,而且还能帮他识别其中最需要解决的技术问题和业务场景是什么,告诉他差距在哪儿,而且能帮他实现。其实我们希望所有公司都应该具备这样的能力:有相关的人员帮助自己去做相应的技术和业务场景需求的提炼和识别问题。

 

下面这个是我们在某公司案例里所使用的一个工具,叫数据门户。

 

很多公司其实还是存在有想法的员工或者有才能的员工,但是这些员工会面临两个困境。第一个困境是他在提报一些创新项目时,会面临一个非常冗长的决策流程和决策周期。比如有的公司一年只决策12次,而且所有的创新项目大部分都是需要上会的,因为它可能是跨部门的项目。一旦上会后,多长时间能够再拍下来就不确定了。第二个是一些员工想用数据去做客户洞察、行为洞察,但是他不知道怎么获得这些数据、能拿到什么颗粒度的数据以及是否有权限使用这些数据。一般这种情况,我们就建议他去做一个数据门户,这个数据门户就好像一个黄页,要求各个部门和IT一起整理手上的数据资源,然后再用文字描述的方式把这些数据罗列到这个黄页上就可以了。比如说我是做物联网的,我手上可能有行为数据、物联网数据、传感器收集数据等等,将这些数据罗列上去之后,就可以指定这一个数据找谁要,并附上联系方式,这样有需要的人使用起来也比较方便,之后数据的使用流程和数据管理制度就逐渐建立起来了,这就为公司进一步的数据治理做了准备。

 

现在,还是得返回到一件事情——什么是大数据?一个人使用的数据,不是大数据;所有人使用数据,才叫大数据。所以我们提出了另外一个定义,大数据是被大规模使用的数据。如果说每一个一线的员工、每一个经营层以及经理都可以用数据进行自我决策,那么这家公司就会被认为是一家数据公司。   

 

数据中台解的是把数据管起来的能力,狭义上的数据是数据动态,广义上是数据终端,包括数据资产管理体系,也就是把数据用起来的能力。那么怎么使用呢?

 

首先在采集端需要采集到更多的数据。现在大部分公司碰到的问题不是数据怎么使用,而是有没有数据的问题。有了数据以后并不能马上使用,因为所有这些数据其实都只是原油,经过精炼加工后才能使用,然后需要建立统一的数据指标,再建立相关的数据标签,这样才能真正向专业团队去提供汽油,让他们能把汽车跑起来,驱动运营、分析和决策,进一步地开拓市场。

 

消费者数据的建立

 

从端到端的角度,一定要解的问题有:数据源是什么?数据从哪里来?有了数据以后,怎么处理?此外还需要有实际的应用场景。在整个建立了端到端的数据能力以后,才能真正地提升业务。

 

这里面给大家说个案例,是我们之前给某个客户做的关于传统门店的一套解决方案。传统门店一定是按照最高需求来配置人员的,比如说做促销配8个人,但实际一年用到这8个人的天数到底有多少无法估计,不过一定不会很多,但是它不敢减少店员人数。并且,传统门店在排班上纯粹靠店长的经验来进行相应的判断。因此,第一步我们去采集相关数据,把数据分析维度丰富到100多个维度,帮助它做智能排班,然后每天上下午根据实际的数据情况再做相应的排班动作。仅此一项,一年时间就帮这家公司削减了1300人,人员开支整体节约了超7800万元,一年大概节约的人员开支可以超过9000万元。这个案例就是当我们准确识别了客户需求后,从数据采集到数据治理,然后再到整个数据智能应用去解决客户需求的一个很好的案例。

 

IT和业务的协同

 

我们认为DR三支柱模型与HR三支柱模型是类似的,它需要具备三个中心。第一个是共享服务中心,它更关注通用能力的建设,负责交付通用的方案。通用的方案一般是由ITBP来发现需求,很多公司可能是数据需求分析师。因为提出通用方案需要既懂业务又懂技术,要能站在业务的立场上关注IT问题和数据问题,并且在这个过程中能发现一些实际的业务需求,然后再把业务需求传达给CEO,也就是第二个中心——专家中心。

 

专家中心是由数据架构师或者业务架构师构成的,数据架构师包括产品经理需要把这些需求抽象成业务的解决方案,并且把这个解决方案传导给共享服务中心,由共享服务中心来进行通用能力的建设,真正实现:一个企业从IT工具解决业务问题到数据解决业务问题的转变。

 

所以如同我们之前提的一个观点:像经营人力资产一样经营数据资产。组织是在数据中台建设中很容易被忽略和的一个问题。如果没有好的组织保障,招了数据科学家,但是留不住,不能培养出很好的数据人才。

 


举一个例子,ITBP是怎么跟业务合作?常常看到,IT不正确地承担了过多业务的KPI,比如说IT要做BI的数据运维、报表开发等等,但是从IT和业务核心的能力来说,IT应该关注通用能力的建设,然后交给业务方进行相关场景的实践,这个是需要有一定组织和流程上的设计的。经过实践,我们推荐大家先坐下来拉通认知,确定改善的指标,再基于目前的数据现状做初步评估,并给出一个大概的结果,然后再做总体的目标设计。比如说做手工建模,IT要去做相关数据的治理、应用性提升,当业务告诉IT需要哪些数据时,IT必须要有自动化的能力去收集相关数据,在利用算法工具和建模工具来实现算法建模上云。我们运用机器的方式来进行算法迭代和机器学习,反过来通过机器学习来进行自我迭代,其中业务和IT分别扮演什么角色,需要一起在这个过程中不断磨合,最后完成整个业务的方案以及通过业务验证和实施策略优化自身指标,这样就形成了一个完整的数据闭环。所有小数据闭环都是大数据闭环的开始,我们推荐,首先一定要去看自己有没有一个可以产生数据闭环的业务或者某个场景是可以让数据去闭环迭代优化的。

 

对大部分公司来说,数据决策还是一个很遥远的事情,因为数据决策很大程度上要依托于一方数据,而一方数据的质量还要依赖于机器的算力,需要用AI算法来辅助决策。因此,这些公司先要解决手头数据的质量问题。从整个规划的角度,商业设计和组织设计也必须要考量一件事情:你的技术规范是什么?你是否具备技术能力、数据能力?要怎么去做顶层设计?这个时候有两件最重要的事情。第一件事情是自上而下的顶层设计;第二件是自下而上的明星需求的推动。作为IT方或者基层的推动者一定要考虑自己能不能快速地用数据产生业务结果。只有这两方基于一些能启动的项目、明星需求站起来,那么整个数据驱动才能变为现实。

 

如今,我们说数据能力是长出来的,而不是通过项目制的方式就能建起来的。长出来的意思是需要有自己的PD、PM、BA、BI,并且需要具备相应的组织和角色来辅助更好地去使用数据,还得需要有相应的开发团队实现相关的技术能力。从实践的角度来看,今天所有的企业需要具备两个团队,一个是数据的团队,包括数据架构师和业务架构师;另一个是运营的团队需要有使用数据去运营和迭代业务的能力。具备这两个团队之后,才能更好地改进你的业务流程,真正把数据能力建立起来,支撑项目从开发到持续运营,形成一个闭环,就可以持续地进行相应的业务产出。在这些基础上,IT才能真正从一个被动响应的部门变成一个主动响应的部门。

 

问答:

 

数据中台是否适用于国企?


今年,很多国企都来咨询数据中台。因为国企这两年在做一个非常重要的事情,叫人、财、物大集中。过去可能底下几家集团公司各用各的系统,但是这两年集团公司开始做整体的战略管控。有一些通用技术公司会一套HR系统布局到底,把所有数据都收归,一旦出现了人、财、物大集中,就会产生很强烈的数据中台需求。这是因为大集中之后会出现数据统计口径不一致、收入透明度等等的问题。

 

数据中台如何有效赋能销售?


这个事情对很多公司来说还是比较难的。现在大量的销售人员整体水平相对是比较落后的,特别是在零售,哪怕是汽车这样的行业销售水平都不高。所以只能以简单直接的形式把结果、决策告诉他,让他去做一些规定性的动作,而这个决策是要依托于智能算法的。


从零售的角度来说,如果能对客户进行识别,拥有针对客户个体提供相应的推荐能力,这样的销售才能真正实现有效的决策。但是这件事情不是一蹴而就的。


一方面要做低成本在线,把相关的销售数据、需要的分析数据全部上线。然后依托一个专业团队帮助你分析数据,这样就能够看见自己的销售是怎么达成业绩的,以及销售业绩的好坏。


另一方面是高水平重复,销售里面可能有的人是90分,有的只有60分,让90分的销售经过一段时间的高水平重复以后,分析出他们能做好的原因,然后把他的经验沉淀下来,赋能给其他的销售,这样整体上得到了提升。到最后一步才能算是真正做到智能化的算法预测,从我们经验来说,一般初步建立数据能力大概需要三年的时间。

 

企业建设数据中台后的价值一般从哪些方面评估?


企业建设数据中台的价值只有一个,就是业务价值。我们推荐从业务的角度往回看的评估方式,到底解决了什么样的业务问题。有了实实在在的业务价值,数据中台的价值才能得到真正体现。

 

数据中台维护成本怎么样?


数据中台维护成本不高。不过,数据一旦上了数据中台以后,数据存储和计算的费用乘倍数地增加。这笔费用才是真正考量企业的一个地方,可能会出现数据增长很快,但是缺乏从数据增长中获取收入的能力,那么这笔投入就会变得越来越不划算。

 

企业搭建数据中台需要做出业务转变是什么?


我们建议不要一上来就探讨业务转变,而是应该先盘点自己的业务需求。在没有看到数据真正带来的成果之前,转变所带来的成本增加反而会导致这件事情夭折的可能性增加。最好的方式应该是把自己的业务需求和数据的能力相匹配,找到其中的差距,然后我们去挖掘出明星需求,让数据能给业务带来价值,通过业务价值才能真正带来业务的转变。


比如,有很多公司已经用手工建模的方式去解了燃眉之急,但是这种手工建模是怎么解的呢?是1个人在建模,还有5个人在做手工的数据导入和导出,但是建模的人一般只能做4~5个,那么我们就给他做算法建模上云。上云后,就可以削减掉那5个人了。当进入到机器的自我净化、自我迭代这个过程后,建模的人可以建40个模型,这就是真正的降本增效。

 

中台与各个事业部如何配合?


还是得考虑:中台到底能带来什么价值?能解哪些事业部的什么需求?业务问题的话,还是以推荐的方式,先去对业务需求进行盘点,再去看它的通用性需求,提炼出那些需求最大的、明星效应最强的需求解决掉。解决了以后,事业部看到数据中台真正带来的价值后,那么管理层、经营层或是执行层都会来配合做下一步的动作。这是一个互相促进的过程,也就是中台这边要有自上而下的整个顶层设计,业务这边也要有自下而上业务场景的推动。

 

上数据中台以后为什么费用激增?


最主要增加的是两块费用。第一块是数据存储和计算增加的费用。过去很多数据只能存十天半个月,删除掉后,历史数据都是没有备份没有存储的。上了数据中台以后,为了更好地做出数据预测,需要存储更多的历史数据,而且因为数据生态大部分是建立在云上的,不管是公有云、私有云还是混合云,都需要做灾备(容灾备份),所以还要在这个基础上再乘以3,那么数据存储和计算费用当然很快会增加了。

 

第二块是组织和角色费用。业务架构师或是数据架构师都需要对他们投入相关的培训费用,还有组织调整费用、招聘费用包括整个团队的建设费用等等。但这笔费用不怎么会以激增的方式,它更多的是以试错的方式,所以支付的激增费用大部分来自于试错。


(如果觉得文章还不错,欢迎点击下方分享按钮,前20位好友可免费读。也欢迎在评论区与我交流,留下你的见解与看法。)

本内容未经允许禁止转载,如需授权请微信联系妙投小虎哥:miaotou515
如对本稿件有异议或投诉,请联系tougao@huxiu.com
评论
0/500 妙投用户社区交流公约
最新评论
这里空空如也,期待你的发声