写点什么

打破焦虑,分析师是如何研判技术趋势的?

  • 2022-06-24
  • 本文字数:5787 字

    阅读完需:约 19 分钟

打破焦虑,分析师是如何研判技术趋势的?

疫情的冲击显著提升了技术的迭代和创新速度。在易观分析年初发布的“2022 年企业数字化技术应用十大趋势”报告中,对备受关注的热点技术在行业的应用趋势进行了深入解读。


首先,RPA 和低代码技术加速落地到行业应用。易观分析认为,进入 2022 年,那些已经具备 RPA+ 低代码 +AI 组合能力的企业将会涌现一批具备业务和科技复合能力的数字员工,他们通过人机协同的方式响应更为复杂的业务需求,甚至自主发起业务创新。同时,这些数字员工高业绩的示范效应也会倒逼其他员工的复合型技能精进。这一趋势背后的逻辑是什么?


云原生技术的发展也受到业界的广泛关注,当大供应商主导完成了企业云原生第一阶段 - 基础设施云化,企业开始进入云原生第二阶段 - 业务云化,该阶段又将出现哪些问题以及如何解决呢?


此外,作为顶流概念的元宇宙,为什么被易观称作“模式创新 2.0”,背后的技术栈又是什么?


本期《极客有约》,InfoQ 邀请到了易观分析企业数字化中心助理总经理张澄宇就这些 2022 年备受关注的技术应用趋势与广大技术人一同探讨。看一下以分析师的视角是如何研判这些技术趋势的。


InfoQ:易观分析企业数字化中心平常的主要工作是什么?大概部门是怎样分类的?


张澄宇:易观分析是中国数字经济数字化领域领先的分析师机构,随着互联网化、信息化向数字化、智能化的变迁过程,易观也一直站在技术驱动创新的前沿,以第三方的视角对市场输出我们的分析和观点。


易观的企业数字化中心是去年成立的,以前我们主要关注互联网等领域,现在消费互联网赛道逐渐到了增长的瓶颈,我们也在 2018 年开始布局企业数字化相关的方向。


易观的部门没有那么复杂,企业数字化中心的分析师会有两个交叉视角:一是行业视角,二是技术视角。同时,我们还成立了数字技术研究院,研究数字化更下层的技术市场,比如某种技术的属性、版本迭代、技术产品市场、技术趋势等。


InfoQ:如何可以成为一个分析师?


张澄宇:成为分析师没有明确的标准。但是,我们认为分析师首先最重要的能力是研究归纳和总结的能力,如何把每天接收到的大量信息归纳总结,把价值传达给需要传达的人,是分析师最核心的技能之一;二是需要有相应的分析解构能力,提出有价值的判断和建议。把分析跟研究的基础能力构建起来,就具备了作为分析师的基本条件。


InfoQ:易观是如何确定对某一个技术趋势或者行业调研的?


张澄宇:我们会从几个角度来看这件事情:一是易观每年都会有大几百场同技术使用者和技术供应商的沟通,在这个过程中,我们会收到很多企业在做数字化业务过程中的问题或者挑战,我们会把这些信息收集过来加工和提炼;二是我们会有自己的分析产品-易观博阅,里面有大量易观的报告以及分析师的观点,客户可以阅读、下载、反馈、传播,包括与分析师进行交流,这些同客户交互的数据均有留存,是我们很重要的数据来源;三是我们可能在某一些行业扎的比较深,比如金融、科技,这样就能把技术趋势的颗粒度进一步细化。此外,我们还会在下半年启动面向银行、证券等行业的 CIO 调研,这些都构成了我们提出技术应用趋势的支撑素材。

“RPA+低代码+AI”武装数字员工

中国市场技术供应商正在快速推动技术民主化进程,其中 RPA+低代码+AI 满足了企业对数字化员工的渴望:RPA 实现了流程型业务的自动化,低代码开发平台为业务人员赋予应用开发和迭代的敏捷能力,而 AI 让业务分析和决策变得更加高效和可解释。


易观分析认为,进入 2022 年,那些已经具备 RPA+低代码+AI 组合能力的企业将会涌现一批具备业务和科技复合能力的数字员工,他们通过人机协同的方式响应更为复杂的业务需求,甚至自主发起业务创新。同时,这些数字员工高业绩的示范效应,也会倒逼其他员工的复合型技能精进,加速组织升级,最终成为内生性推动企业数字化转型的中坚力量。


InfoQ:请谈一谈对低代码的看法?


张澄宇:低代码技术现在很热,我们会从几个角度去看这个问题。


首先,我认为低代码本身是一种应用开发的能力属性,开发者只需要写很少的代码,或不需要写代码就能够开发。至于开发的成果是什么?一个 APP?一个 RPA 机器人?一个模型?这些取决于相应的软件产品的价值主张,因为软件产品决定了产品跟客户的业务价值如何连接起来。


其次,市面上对低代码的评价褒贬不一,但长期来说,我们认为低代码或无代码是个趋势,任何一个技术的评价应该是客户价值驱动,因为企业会比消费者更加客观理性地评价这个技术到底给企业业务带来了多大价值。


最后,低代码、无代码可能使用的场景完全不同,无代码是给业务人员用的,低代码是要给开发者使用的,无论是低代码还是无代码,并不是谁替代谁的问题,而是特定的岗位跟职能的人员需要选对应的开发工具。


InfoQ:当前 RPA 在国内的应用情况如何?


张澄宇:今天,RPA 确实非常热,在目前的经济和资本环境下,厂商侧有一些头部厂商拿到了很多钱,还在做国内甚至海外业务扩张,另外很多厂商也在讲一个故事——RPA 是驱动企业数字化转型的枢纽或者平台。客户侧很多落地情况也不错,以银行业为例,不仅大中型银行已经开始规模化落地 RPA,我们有一个排名在 100 左右的小银行客户,他们 2021 年已经落地了 50 多个 RPA 的机器人场景,涵盖客服、审批等环节。所以,我们发现这个行业呈现非常明显的向上趋势。


RPA 被广泛应用的背后有两点关键逻辑:第一,RPA 是把技术跟业务结合得非常好的一款 SaaS 产品,而不是一种难以落地的技术产品;第二,因为跟业务的强耦合,让客户更容易量化 RPA 的投资回报率,因为数据本身是可以说话的,是可以得出明确结论的。


InfoQ:RPA 的自动化会不会夺走人类的工作?


张澄宇:我觉得可以从两个角度去看,首先 RPA 有其局限性,RPA 只解决了很基础性的、标准化的工作以及流程上降本增效的问题,包括一些数据积累跟沉淀的问题。其次,在非标准化的领域,RPA 并不能很好地解决问题,还需要人为干预。所以说 RPA 更多是替代了枯燥的、标准化的、流程化问题。所以,我们更喜欢用的说法是 RPA 并非替代了人,而是解放了人的生产力,让大家能够做一些真正追求企业上限的事情。


InfoQ:从分析师的角度出发,你怎么看虚拟数字人的火热,是不是一波新的炒作?


张澄宇:首先厘清一个概念,数字员工跟元宇宙语境下的虚拟人或者数字人是两码事儿。


我们定义的数字员工是数字化的劳动力,一种是劳动力本身的数字化体现,另一种是员工的技能、认知、能效和数字技术与工具结合以后,形成一种新形式的 ROI 更高的劳动力,我们认为这两种数字化的劳动力都是数字员工。但是元宇宙语境下的数字人,我觉得更多的还是从 IP 的角度去看的虚拟人。在企业数字化过程中,虽然说很多企业已经开始尝鲜使用虚拟人用作客服等场景,甚至作为形象代言,但对于它在业务中的落地价值,我认为还处于相对边缘的创新探索阶段。


InfoQ:在元宇宙的范围中,哪些技术是需要特别关注的?


张澄宇:因为在元宇宙底下,我们会发现有很多底层技术问题要解决,比如数字卵生、区块链、人机交互,包括生物识别,以及未来甚至有脑机接口,这需要一个主题技术栈,包括很多技术以及非技术的内容,这些内容组合起来才能满足这样一个新模式从创新到落地的过程。在易观发布的 2022 年企业数字化十大趋势报告中,也将元宇宙界定为了模式创新的 2.0,它本质是一个主题技术栈创新来驱动的商业模式。


InfoQ:数字员工的发展未来会对整个行业带来什么样的影响?对开发者来说,如果想要与数字员工并存需要哪些能力,或者在工作内容上会发生什么样的变化?


张澄宇:从趋势来讲,我觉得可能也很难面面俱到,这里简单分享几个点。首先,数字员工一定是未来趋势,因为目前从中国的人口结构来说,老龄化加速,新一代的人口红利可能到 10 后这一代已经到达瓶颈,未来会持续流失劳动力或者说生产力。但是企业要做的事情反而越来越多,没有这么多人就只能用数字员工的方式解决,机器的加入让以前需要五个人做的事情现在一两个人就可以完成,同时效果更好。因此,这是企业要持续布局的方向。


其次,从开发者的角度,数字员工会不会取代开发者?开发者应该是数字员工的创造者,开发者才是造路人,开发者是真正开发一个能够替代人的工具还是开发一些能够辅助人的工具,有很多空间给到企业。当然技术本身也是迭代的,如何能够帮企业更快地做更多业务,响应更多需求,同时又更好地提供产品和服务,还要控制成本,保证业务安全性,各方面业务价值都是逐渐提升需求的。


在这个过程中,开发者能否满足企业在不同阶段持续的需求,这应该说是没有上限的,开发者需要保持自己对业务价值变化的敏锐度,再基于这样的理解,持续迭代自己对技术的理解,以及所开发的产品或者服务的价值主张是不是真正站在时代前沿。

云原生应用连通云化业务闭环

云化的趋势已被广泛共识,容器、基于 Serverless 部署的应用以及 Service Mesh 等云基建的不断推进使得企业上云渗透率持续提升。当大供应商主导完成了企业云原生第一阶段 - 基础设施云化,企业开始进入云原生第二阶段-业务云化,比如通过 API 和微服务构建可弹性扩展的云原生应用,实现应用同业务强耦合。


易观分析认为,那些在 2022 年已经完成云原生基础设施部署的企业,将很快面临云原生工具和产品同企业业务逻辑衔接带来的新挑战。对于技术供应商来说,如何使云原生解决方案在保持足够可复制性和扩张性的同时,也提供适配客户业务属性的性能和功能,并内化至 DevOps 的过程管理中,是决定云原生技术能否转化出巨大商业价值的关键。对于行业客户,也需要在搭建云原生平台的同时,推动业务流程再造,甚至组织变革管理,尽快让业务和技术实现新的耦合。


InfoQ:易观如何定义企业已经完成云原生搭建的第一个阶段,也就是基础设施的云化而过渡到第二阶段的?


张澄宇:这个话题是企业数字化十大趋势里面的第二个趋势——企业逐渐从基础设施云化走向业务云化。这个趋势的判断得到了行业里非常多客户跟厂商的认同。


之前,企业上云可能是通过购买很多云厂提供的基础设施服务来完成的。


在第二个阶段,企业面临很多挑战,比如如何打通运行在不同平台上的业务以及打通不同的系统,这些都是特别大的问题,我们认为这也是今年非常重要的趋势。当企业完成基础设施的云化,大家更关注的应该是如何把业务真正放到云上,从而产生更好的效果,在这样的趋势下,如果想抓住“牛鼻子”,最关键的是需要用原生应用实现云原生技术及业务的强耦合,比如微软、华为等大厂都在探讨该方向,包括我们与微软做过的一些联合研究,我们认为在数字化转型的过程中,开发效率排名靠前的公司显著具有数字化创新的优势,这就是云原生应用的价值。我认为只有高效、规模化地构建数字化应用,让应用承载企业多层级,包括战略层级、业务层级以及一些场景的数字化升级需求,结合基于云的基础设施,企业可以收集到海量数据,进而将更多业务云化,这是我对从基础设施云化到业务云化这个转化过程的解释,以及在这个过程中企业真正要抓住的“牛鼻子”应该是云原生应用。


InfoQ:我们现在也在市面上看到了很多种云原生的解决方案,企业在选择过程中应该重点考虑哪些因素?


张澄宇:作为技术用户,大家需要做好云原生解决方案并不能真正解决问题的思想准备。一方面,企业要明确拆解自己在数字化过程中的目标跟困境,要解决的数字化问题在哪个层面,比如架构层面、开发层面、安全层面、数据层面,基于每个层面的目标和困境,从更加细粒度的维度上找有对应能力的厂商,根据具体问题制定解决方案。


另一方面,与厂商打交道时需要看厂商是否真正愿意投入资源跟精力和客户一起成长,一起完成创新探索。投入度在选择合作伙伴的过程中非常重要,愿意投入的厂商很有助于企业缩短前期的试错成本。


InfoQ:个性化的云原生解决方案,从成本 ROI 的角度来看,对于中小企业来说会不会是一个伪命题?


张澄宇:绝对个性化的云原生解决方案,不光对中小企业来说是伪命题,对大企业也同样。因为厂商不可能帮助企业真正端到端的完成转型,企业要实现自己的业务价值,需要在云原生的平台构建起来以后,利用云原生技术产品和生态来逐渐形成自己的能力,不可能一开始就存在绝对的个性化解决方案。


此外,对中小企业来说,可能不需要云原生解决方案,但不代表就不需要云服务,现在有很多比较领先的云厂商,本身的公有云平台就非常有价值,一方面帮助厂商找到用较低成本获得云基础设施的路径;另一方面帮助中小企业获得创新的能力。基于云端的基础设施有很强的开放性,企业可以很方便地获得一些云端增值服务。企业也能够利用这种开放性,把云端的新能力放进来。这让企业在数字化时代更加敏捷、高效,赢得数字化竞争。

开发者如何打破“年龄”、“职级”等带来的焦虑?

InfoQ:对于现在的从业者而言,可能很难从一些碎片化的信息当中判断出行业的趋势,有没有一些比较好的建议?


张澄宇:行业趋势可能不会直接落到大家具体的开发运维工作中,但是对于趋势的理解确实有助于判断行业的发展路线。从这个角度来说,一方面非常推荐大家关注“易观分析”和“易观数字技术应用”公众号,可以很好地了解数字化、智能化技术应用的趋势方向;另一方面,对于一些厂商对外的新产品、新战略发布,也可以关注一下,会看到一些前沿的思考;第三个方面是与身边人沟通,与大家聊相关话题也是获取一手信息非常好的渠道,而且这个渠道在我们看来对自己的冲击会更大,可能能吸收到的东西更多。


InfoQ:开发者由于对年龄的焦虑、行业的焦虑,技术做着做着就要转管理,你对此有什么比较好的看法?


张澄宇:我给大家一个视角——挖洞到织网,这是什么意思?挖洞是指钉子越扎越深,落到技术上,比如某一个开发语言玩得滚瓜烂熟,各种技术问题都能解答,这不失为一种方向,但这个方向会有一些缺陷,因为技术逐渐进步,有可能新技术会把从前的旧技术迭代掉。


开发者也可以换个视角——去织一张网,这个网应该怎么织?比如可以把整个云原生的链条都讲清楚,如果要更高效的构建数字化应用,开发层面有哪些事情?运维有哪些事情?安全跟保障有哪些事情?跟企业敏捷、弹性、韧性的业务诉求又有什么关系?对云原生技术栈有很深的理解之后,就跳出了某个一技术,而有能力管理一个系统,天花板就打开了。


另外一个方向是与业务价值做衔接,比如云原生与企业数字化转型过程中的业务价值是什么关系?落地路径是什么?风险是什么?有哪些案例?这是所谓的业务价值的网。


做到专家甚至大神级固然很好,但未必每个人都要真正成为专家,大家也可以一专多能,理解业务系统,就可以跳出技术本身的风险,在系统层面做事情,这是我从挖洞到织网的一个建议。

2022-06-24 08:374600
用户头像
赵钰莹 极客邦科技 总编辑

发布了 883 篇内容, 共 647.5 次阅读, 收获喜欢 2679 次。

关注

评论

发布
暂无评论
发现更多内容

数据总量 40 亿+,报表分析数据 10 亿+,TiDB 在中通的落地与进化

TiDB 社区干货传送门

实践案例

涂鸦智能选型 TiKV 的心路历程

TiDB 社区干货传送门

数据库架构选型

基于TiCDC 实现的双云架构实践

TiDB 社区干货传送门

实践案例

TiDB SQL调优实战——索引问题

TiDB 社区干货传送门

性能调优 实践案例

TiDB 对大事务的简单拆分

TiDB 社区干货传送门

性能调优

带你重走 TiDB TPS 提升 1000 倍的性能优化之旅

TiDB 社区干货传送门

性能调优

PD 如何调度 Region

TiDB 社区干货传送门

TiDB 底层架构

通过 ProxySQL 在 TiDB 上实现 SQL 的规则化路由

TiDB 社区干货传送门

管理与运维

【联合方案】神州信息 - 新一代分布式网贷系统

TiDB 社区干货传送门

实践案例

TiDB 配置参数修改与系统变量修改步骤

TiDB 社区干货传送门

实践案例

tidb中的key和MVCC value解析

TiDB 社区干货传送门

管理与运维

Tidb duration 耗时异常上升案例

TiDB 社区干货传送门

故障排查/诊断

TiDB 入门运维基础教程(二)--生产环境安装

TiDB 社区干货传送门

安装 & 部署

云集财务业务 TiDB 实践

TiDB 社区干货传送门

实践案例 数据库架构选型

TiDB 监控整合方案

TiDB 社区干货传送门

实践案例

从TiDB中学习代码提交规范的重要性

TiDB 社区干货传送门

TiDB 底层架构

TiDB集群的GC不回收案例(案情二)

TiDB 社区干货传送门

故障排查/诊断

地产TiDB使用初探索

TiDB 社区干货传送门

安装 & 部署

事务前沿研究丨事务测试体系解析

TiDB 社区干货传送门

TiDB 底层架构

Chaos Mesh® 在腾讯——腾讯互娱混沌工程实践

TiDB 社区干货传送门

实践案例

Zetta:HBase 用户的新选择 —— 当知乎遇上 TiDB 生态

TiDB 社区干货传送门

实践案例

58同城大规模TiDB运维漫谈

TiDB 社区干货传送门

安装 & 部署

我们为什么放弃 MongoDB 和 MySQL,选择 TiDB

TiDB 社区干货传送门

数据库架构选型

TiDB5.0.3-ARM平台性能测试

TiDB 社区干货传送门

安装 & 部署

【TiDB 最佳实践系列】海量 Region 集群调优

TiDB 社区干货传送门

实践案例

生产环境 TiDB V5.0.3 集群部署

TiDB 社区干货传送门

实践案例

TiDB 5.0 两阶段提交

TiDB 社区干货传送门

TiDB 底层架构

TiDB 如何做到无限扩展和保证节点 id 唯一

TiDB 社区干货传送门

TiDB 底层架构

TiDB 4.0 基于 Binlog 的跨机房集群部署

TiDB 社区干货传送门

安装 & 部署

TIDB监控报警对接企业微信的简便工具推荐

TiDB 社区干货传送门

监控

TiDB SQL 自动重试调研

TiDB 社区干货传送门

TiDB 底层架构

打破焦虑,分析师是如何研判技术趋势的?_开源_赵钰莹_InfoQ精选文章