草庐IT

专访实在智能孙林君:颠覆传统RPA的实在IPA模式如何做到真正人人可用?

王吉伟频道 2023-03-28 原文

 

 

王吉伟对话实在智能孙林君:颠覆传统引领RPA行业的实在IPA模式是如何炼成的?

王吉伟对话实在智能孙林君:为什么第一款颠覆行业的RPA诞生在实在智能?

专访实在智能孙林君:打造出真正人人可用的实在IPA模式,背后都做了什么?

实在智能孙林君:IPA模式的实在RPA,向真正人人可用迈出了重要一步


文/王吉伟

 

“RPA人人可用”这个愿景,在一线大厂提出后立即得到广大厂商的认同与推崇,之后它几乎成了所有厂商的“口头禅”。

如果RPA能够消除使用门槛实现真正人人可用,意味着每个组织都能通过引入RPA快速通过流程自动化快速实现增效降本。这是广大受困于数字化转型的组织梦寐以求的,也是提供技术服务的RPA厂商的终极愿景。

然而事实上,虽然RPA能够让没有编程基础的业务人员能够参与开发,却没有让开发变得更加简单与高效。RPA工具的功能越多,RPA开发的时间反而越长,效率也会越低。往往用RPA需要几十步的动作拖拽编排与适配,专业开发者只需几句编程就能完成。

很多业务人员在元素和变量的困扰中难以自拔,遇到问题不得不去找忙得不可开交的技术人员,再次被列入技术工单。

 

自RPA工具诞生至今二十多年的时间里,“拖拽式”的动作编排未曾改变过。难以理解的元素、拾取与变量,也让业务人员不得不通过各种培训,变成介于开发者与业务人员之间的“过渡行者”。

只是这些“过渡行者”所开发的自动化应用程序,很少能够逾越专业开发者的门槛,在稍微复杂一点的业务流程面前就会无能为力。

如果RPA不能让非技术人员快速上手与高效开发,RPA又有什么存在意义?所以,相当一部分人认为“RPA人人可用”仅是个噱头,不可能实现。

想要真正实现RPA人人可用,现有的RPA产品形态很难实现。除非换个产品逻辑,能够从架构上革新RPA的产品形态,彻底改变固有开发模式。

一边是RPA厂商们的热烈追求的“人人可用”,一边是各领域看客们时而质疑的“无法实现”。在不同的声音里,更多人也加入了质疑者队伍。

RPA人人可用,是否只是厂商们的“情怀”牌?他们真的能做到吗?又需要多长时间?

本以为出现颠覆式创新产品的周期会很长,但最近实在智能发布的实在IPA模式RPA新品,真的颠覆了已有RPA开发模式,大大提升了RPA易用性,让“RPA人人可用”进一步成为现实。

 

这款震撼行业的由实在智能全球独创的实在IPA模式RPA,到底是一款怎样的产品?为什么实在智能率先推出了这样的产品?新产品将会为行业带来哪些影响?

带着这些疑问,发布会后,王吉伟频道第一时间采访了实在智能创始人兼CEO孙林君,让他亲自为我们揭开实在IPA模式的神秘面纱。

关于产品

王吉伟频道:实在智能IPA模式新品有哪些特点?它与AI+RPA以及IA(智能自动化)有什么不同?

孙林君:实在智能这次发布的IPA模式新产品,最大的特点是向真正的人人可用迈出了重要的一步,这一步是通过智能化算法和全新的产品理念实现的。

以往的所有RPA产品都是以组件式的“拖拉拽”为主来构建流程,包括市面上的少儿编程产品也是建立在这个理念上。绝大多数人觉得这就是低代码类产品的终极形态了,都在这个基础上宣传人人可用。

其实这是不正确的,它要通过培训先把人变成专家,才能使用拖拉拽,距离人人可用还很遥远。

实在智能IPA模式新产品,突破了这个固有思维,抛弃了“拖拉拽”为主的流程构建,采用了“所见即所得”的直观操作构建流程。流程构建直观易懂,效率高很多,这在业界(包括海外)是首创的。

这种IPA的流程构建方式,对用户来说是沉浸式的、所见即所得的、全新的交互设计,底层大量的依赖大数据和人工智能相关的算法。

完全替代掉“拖拉拽”模式的所见即所得的IPA模式,建立在大量算法的基础上。它不是靠第三方提供能力的方式,而是基于实在智能自主创新重构RPA构建模式的底层逻辑,远不是AI+RPA那么简单。

AI+RPA和IA更强调的是业务应用层面的构建能力,IPA指的是AI和RPA从底层融合的化学反应。

实在智能的产品矩阵是围绕超自动化愿景,结合自身的特点构建的。它以RPA为底座,包含IDP、chatbot、云脑、BI、智能外呼等,实在智能产品矩阵整体都在向前演进。

比如围绕信创的RPA,我们支持几乎所有的国产芯片、信创操作系统及数据库,已在浙江省一百多个统计相关的单位落地应用。同时RPA与各个产品之间的衔接更加无缝,支持CoE、流程记录及IDP产品,在SaaS化和支持场景上都有比较大的扩展。

 

王吉伟频道:为什么要发布实在IPA这样一款产品?出于哪些思考?

孙林君:RPA人人可用,是一个巨大的市场空间。但我们做过很多调研发现,很多不管使用哪家厂商的RPA,因为各种原因放弃的非常多。

究其原因,归根到底还是因为RPA的使用门槛,没有降低到真正人人可用的程度。在实在IPA之前,海内外所有RPA产品,都是先通过培训把人培养成专家,学会使用几百个组件和很多难懂晦涩的概念比如拾取、元素、变量等。

这些概念,对小白用户来说还是太难搞明白了。也有人由此断言过:RPA做不到人人可用。

这也引发了我们的深度思考。

我们觉得RPA行业需要通过创新来变革,必须颠覆掉原有的专家模式,抛弃以“拖拉拽”为主的流程构建方式。我们通过智能化这条道路来思考这个问题的,而且想要解决这个问题现阶段也只能靠AI技术。

经过长时间的探索与不断迭代优化,我们推出了全新的RPA流程构建新模式:用户每一个点击和每一个动作,都由算法来理解和辅助完成。

从行业本质来看,RPA的兴起是因为它的使用便捷性、低成本和近几年智能化技术兴起。RPA和AI在这方面找到了结合点:一方面,人们认为这将是一种人人可用的普惠技术或者产品;另一方面,人机协同是未来的工作模式的大趋势。所以,人人可用和智能化的工作助理是刚需。

但是传统RPA自身的一些能力瓶颈也非常明显,比如过于依赖操作系统和应用,以及稳定性和交付成本对于RPA厂商规模化的制约等。所以,实在智能提出了“要突破行业天花板,才能实现RPA真正赋能千行百业”的愿景。

但要实现这个愿景依赖技术创新,需要升维思考。因此我们找到了“智能融合拾取解决底层拾取”的解决方案,通过智能屏幕语义理解技术,解决“像人一样理解要操作的对象”的问题。基于此,向下突破人人可用的壁垒,向上突破数字员工大规模可靠应用的壁垒。

RPA机器人或者数字员工是一种非常好的商业模式,也是未来我们长期看好的市场。但是这些都需要构建在坚实的底层基础之上,否则就是陷入高度同质化竞争,无法做大规模。

 

王吉伟频道:为什么说实在IPA模式颠覆了RPA的传统模式?这对行业及用户有什么意义和影响?

孙林君:我们认为这次的产品创新,是具有颠覆性的。原来整个行业的所有产品,都是围绕“拖拉拽”构造流程来打造产品的。大家的思维被局限了,都在这个基础上搞人人可用的产品。

我们也在思考,为什么客户面对“拖拉拽”的产品形态,依然有畏难情绪。大家的RPA产品功能越来越丰富,距离“人人可用”却越来越远。经过大量的调研与摸索,最终才发现之所以会出现这种情况,是因为大家的产品底层逻辑就有问题。

要打破现有的思维框架,必须跳出来,颠覆掉它,要翻越用户必须了解的”拾取、组件、变量“的三座大山,于是就有了从“拖拉拽”到“点选用”的产品构思。

相信这是RPA行业面向“人人可用”迈进的一大步,这个产品在打磨过程中,有大量的小白用户试用过实在RPA新的IPA模式,评价基本都是能迅速上手,用起来有非常舒爽的感觉,真的能非常容易的用起来。

新产品出来之前,用户为了很好的应用RPA,需要相对比较资深的业务专家或者IT人员来构造流程。应用在组织内部,是“少数人构建,多数人应用”的模式。

有了新的IPA模式以后,普通的业务人员能够轻松上手构建业务流程了,那么RPA的普及率会上升很多,且能够把很多碎片化的自动化应用无法满足的问题解决掉。

对组织来说,可以更快速的形成”人+助手“的模式,应用超自动化的成本会降低,长远看会提高人的生产效率。

 

关于技术

王吉伟频道:要实现实在IPA这种更加简单的“点选用”编排操作,有什么技术难度?技术门槛高吗?如何应对市场竞争?

孙林君:要在技术上颠覆掉原有的产品形态,需要从底层做彻底的大量的重构,这个代价是比较大的。

我们经过长时间的摸索,不断地踩坑寻找最优解决方案和更优算法解决方案,一点一滴地实现了把复杂逻辑全部隐藏在产品内部的看起来非常简单的流程编排模式。

为了实现这种模式,我们在产品底层的通信、页面结构识别、页面元素识别、元素智能定位、推荐算法、交互逻辑重构方面都做了大量的工作。

能做到这些,得益于实在智能作为一家AI公司的AI基因。在人工智能方面,我们拥有足够深厚的技术积累和创新能力。

同时我们更愿意从行业未来发展的终局角度来思考其本质。距离问题最近的人,也就是最先解决问题的人。我们坚定的认为产品是表,技术是里,不会用取巧的方式过分强调产品和商业模式。

技术门槛肯定是有的,而且不低。实在智能花了非常多的时间进行创新和打磨,才有了今天的产品形态。虽然产品形态是可以模仿的,但我们全球首发这一模式的RPA产品,便意味着我们足够的先发优势。

在实在智能的引领之下,后面采用同样技术与模式的都是模仿者和跟随者。

实在智能创新的脚步不会停止,我们会定期通过产品发布会等方式对行业发声,不断推出更强大的新一代模式和产品,引领行业发展。我们相信从实在智能发布新品开始,IPA取代RPA已经走进现实。

实在智能是RPA行业的后来者,进入这个赛道上时一些RPA公司的融资进程已经到了B、C轮。但仅用两年多的时间,我们就完成了从跟随到超越在到引领的进程。

实在智能的专利数和软著数是行业内最多的,目前已拥有40项专利和200多项的软著。从技术到产品再到服务,实在智能已经在行业内建立了良好的口碑。

产品迭代速度、技术创新能力以及永远客户第一的服务理念,是实在智能应对激烈市场竞争的底气。

 

王吉伟频道:当代RPA的背后,都融合了很多AI技术。实在智能首发颠覆传统RPA开发模式的IPA模式,是否意味着以AI起家的厂商具备先发优势?其他厂商能否在短期内弥补这一优势?

孙林君:我们认为一定是这样的。RPA出现之后,中间有十几年的时间一直不温不火,直到最近几年才突然爆发了,这是有原因的。

进入到2018年,大家看到了RPA与AI结合的巨大空间,都在搞RPA+AI。RPA自身的局限性绝对不容忽视,比如软件控制能力、信息提取能力、使用门槛高、使用方式抽象等,这些问题不能彻底解决,就无法达到客户的预期,终究会被抛弃。

但RPA与AI的结合,绝不是简单的加法。通过实在IPA模式的RPA产品形态,相信大家已经能够理解AI和RPA是如何具体结合的,并不是把AI技术和RPA简单拼凑就能实现。

目前的实在IPA模式,是实在智能多年自研AI技术、模型及算法与全新架构RPA深度融合的产物。通过第三方提供的AI能力是无法做到的,也不可能满足各个行业应用场景深度改造的需求。这就要求厂商们必须有自身的创新能力和AI自研能力,而成为一家拥有AI基因的公司并不是那么容易。

 

关于“RPA人人可用”

王吉伟频道: 为什么要坚定不移地推动“RPA人人可用”?这款颠覆性产品的发布,是否意味着实在智能正式进入C端市场?

孙林君:我们考虑问题,还是从本源来思考的。RPA不应该是一种只有少数人才能使用的技术,应该是人人可用的。从底层能力来说,传统的RPA存在能力不足,需要用创新技术来增强。

RPA人人可用,如果还是用抽象的“拖拉拽”方式,对用户来说还是门槛过高了。这就让“RPA人人可用”更像是口号,因此必须通过创新来突破,这也是我们进入这个赛道的使命。

“RPA人人可用”意味着更大的市场,无数不能被满足的个性化需求会被激活。未来的RPA产品应该像office一样成为白领的必备工具,RPA产品算是一种B端与C端同源的产品,二者相辅相成。新的IPA模式,应该是RPA迈向C端市场的真正的开始。

 

王吉伟频道:有人说做To B业务的RPA面向C端是个伪命题,您是怎么看的?面向C端的“RPA人人可用”能不能帮助实在智能拓展市场规模?

孙林君:To B产品越来越To C,是一个大趋势。因为To B的产品也是给个人用的,用户在使用产品的时候也越来越关注用户体验,这一点在我们的众多客户身上体现得很明显。有一个庞大的基础用户群体,对于产品的演进和迭代都有很好的促进作用,对于B端客户的转化也有很大的帮助。

当然是否直接从C端用户赚钱,不同的人有不同的看法。对实在智能来说,这是一个整体性的问题,说“RPA面向C端是个伪命题”显然是看问题比较片面了。

实在智能的销售是To B为主,但我们的社群转化还是蛮高的。随着实在智能在行业内的影响力越来越大,我们已经有了相当庞大的活跃用户群体,且在快速增长中。“RPA人人可用”帮助我们拓展了市场规模,这个已经在我们获取的众多客户身上验证了。

 

后记:“RPA人人可用”不再是一句口号

翻开以前的记录,实在智能CEO孙林君曾在某采访中表示,体验好的产品并不意味着易用性好。

当时看到这句话,王吉伟频道也在思考,还有什么样的RPA产品能够做到更高的易用性呢?现在实在智能发布了这款颠覆行业的IPA模式新品,在给予大家震撼的同时,也用这款产品印证了那句话。

而之所以敢说这句话,应该在于全新的IPA模式在当时便已呼之欲出。为了推出这款“大招”级产品,实在智能已经为之准备了多年。

早在进入RPA之前,他们就已经在探索屏幕融合拾取技术所包含的系列AI技术如何更好的与RPA融合,如何重构RPA形态,如何重塑RPA开发模式,如何实现真正的“RPA人人可用”。

 

虽然“RPA人人可用”的行业愿景是由海外厂商提出的,但从不断推陈出新的产品、技术与模式来看,国产RPA在践行这个愿景的进程中却做得更好。国产RPA通过不断探索以及各种全球首创的技术与模式,让“RPA人人可用”进一步成为现实,让“RPA人人可用”不再是一句口号。

实在智能用全新形态全新模式的产品告诉业内外,“RPA人人可用”是可以做到的。可以预见,自实在智能IPA开始,“点选用”替代“拖拉拽”的IPA模式将会成为RPA产品新趋势,而实在智能则引领了这一场行业变革。

国产RPA,真正开启了全球RPA行业创新与发展的领衔主演之路。

 

【王吉伟频道,关注TMT与IoT,专注数字化转型、业务流程自动化与RPA。】

有关专访实在智能孙林君:颠覆传统RPA的实在IPA模式如何做到真正人人可用?的更多相关文章

  1. ruby-on-rails - 如何使辅助方法在 Rails 集成测试中可用? - 2

    我在app/helpers/sessions_helper.rb中有一个帮助程序文件,其中包含一个方法my_preference,它返回当前登录用户的首选项。我想在集成测试中访问该方法。例如,这样我就可以在测试中使用getuser_path(my_preference)。在其他帖子中,我读到这可以通过在测试文件中包含requiresessions_helper来实现,但我仍然收到错误NameError:undefinedlocalvariableormethod'my_preference'.我做错了什么?require'test_helper'require'sessions_hel

  2. ruby-on-rails - self 在 Rails 模型中的值(value)是什么?为什么没有明显的实例方法可用? - 2

    我的rails3.1.6应用程序中有一个自定义访问器方法,它为一个属性分配一个值,即使该值不存在。my_attr属性是一个序列化的哈希,除非为空白,否则应与给定值合并指定了值,在这种情况下,它将当前值设置为空值。(添加了检查以确保值是它们应该的值,但为简洁起见被删除,因为它们不是我的问题的一部分。)我的setter定义为:defmy_attr=(new_val)cur_val=read_attribute(:my_attr)#storecurrentvalue#makesureweareworkingwithahash,andresetvalueifablankvalueisgiven

  3. ruby - 输出液体模板中的可用对象和属性 - 2

    有没有办法在liquidtemplate中输出(用于调试/信息目的)可用对象和对象属性??也就是说,假设我正在使用jekyll站点生成工具,并且我在我的index.html模板中(据我所知,这是一个液体模板)。它可能看起来像这样{%forpostinsite.posts%}{{post.date|date_to_string}}»{{post.title}}{%endfor%}是否有任何我可以使用的模板标签会告诉我/输出名为post的变量在此模板(以及其他模板)中可用。此外,是否有任何模板标签可以告诉我post对象具有键date、title、url、摘录、永久链接等

  4. ruby-on-rails - 是否有类似 'with_indifferent_access' 的数组可用于包含? - 2

    我尝试在我的应用中只使用:symbols作为关键词。我尝试在:symbol=>logic或string=>UI/languagespecific之间做出严格的决定但我也得到了每个JSON的一些“值”(即选项等),因为JSON中没有:symbols,所以我调用的所有哈希都具有“with_indifferent_access”属性。但是:数组是否有相同的东西?像那样a=['std','elliptic',:cubic].with_indifferent_accessa.include?:std=>true?编辑:将rails添加到标签 最佳答案

  5. ruby - 编写一个 ruby​​ 命令行应用程序;最好的方法是做到这一点? - 2

    我有一个正在开发的命令行Ruby应用程序,我想允许它的用户提供将在部分过程中作为过滤器运行的代码。基本上,应用程序是这样做的:读入一些数据如果指定了过滤器,则使用它来过滤数据处理数据我希望过滤过程(第2步)尽可能灵活。我的想法是,用户可以提供一个Ruby文件,该文件设置一个已知常量以指向实现我定义的接口(interface)的对象,例如:#user'sfilterclassMyFilterdefdo_filter(array_to_filter)filtered_array=Array.new#domyfilteringonarray_to_filterfiltered_arrayen

  6. ruby - 哪些 IDE 可用于 jRuby? - 2

    我进行了一些谷歌搜索,似乎缺少用于jRuby的IDE。我读过TextMate和Sublime,但它们不提供调试或代码完成功能。有人可以提出建议吗(或者这项技术还处于起步阶段)? 最佳答案 有几个选项;我更喜欢JetBrains'IntelliJ(RubyMine).AptanahasanEclipseplugin.NetBeansusedtohaveofficialsupport,不确定currentstate是什么是。 关于ruby-哪些IDE可用于jRuby?,我们在StackOve

  7. ruby-on-rails - 如果没有可用标签,则运行标记规范或全部 - 2

    我将guard与rspec和cucumber一起使用。要连续运行选定的规范,我只需使用focus标记来确定我要处理的内容。但问题是,如果没有带有该标签的规范,我想运行所有规范。我该怎么做?注意::我知道所有RSpec选项。因此,请仅在阅读问题后回复。 最佳答案 我通过以下配置实现了您描述的行为:#torunonlyspecificspecs,add:focustothespec#describe"foo",:focusdo#OR#it"shouldfoo",:focusdoconfig.treat_symbols_as_metada

  8. ruby-on-rails - Controller 中的实例变量如何可用于 Rails 中的 View - 2

    我从事Rails已有一段时间,并且刚刚开始深入研究Ruby元编程,Rails从中获得了强大的力量。我真的想不通这个,这让我发疯。Controller中的实例变量如何提供给Rails中的View(与View共享)?我知道它背后有一些元编程魔法,但我无法弄明白。在此先感谢您的所有帮助。 最佳答案 更新:原来接受的答案是错误的我现在将它留在下面以证明我错了。在获得足够多的反对票后,我决定研究这实际上是如何工作的。我最初的回答是在我对Rails还很陌生之后写的,并且是基于我使用过的其他MVC库(特别是:CodeIgniter)的工作方式的假

  9. ruby-on-rails - 为什么 Array.count 在开发模式下可用但在生产模式下不可用? - 2

    对于最近的一个项目,我有几个View是这样的代码:这在开发模式下工作得很好......我将它推出到生产模式并且它爆炸了,说count不是Array的有效方法。我将每个实例都改为使用Array#length,它似​​乎可以正常工作。1)这种行为差异的原因是什么?2)我应该注意开发模式和生产模式之间的任何其他令人兴奋的差异吗?道德:确保您的生产托管环境使用与本地开发环境相同的Ruby版本。:)谢谢汤姆 最佳答案 count方法仅在Ruby1.9及更高版本中可用。我建议您使用与服务器相同版本的Ruby以避免此类问题-1.9中发生了很多变化

  10. Ruby 获取可用的磁盘驱动器 - 2

    谁能告诉我如何在ruby​​中获取可用磁盘驱动器的列表?我正在创建一个打开的文件对话并且需要知道!提前致谢,嗯。 最佳答案 Brian给出的文章正确地陈述了以下代码:require'win32ole'file_system=WIN32OLE.new("Scripting.FileSystemObject")drives=file_system.Drivesdrives.eachdo|drive|puts"Availablespace:#{drive.AvailableSpace}"puts"Driveletter:#{drive.D

随机推荐