RPA跟传统自动化技术相比，关键的标识性特征之一在于模拟鼠标和键盘的操作对界面上的特定对象进行交互。其实不过是对GUI相关的Windows底层API进行Hook而已。这门技术已经诞生很多年了，早已衍生出很多相关软件产品。所以说，其实要从零开发一款RPA产品出来，并不困难。至少，已经有很多先例可供参考。我相信GitHub上已经有许多源码可以直接抄。
因此，近来国内有很多人都觉得自己可以独立做出一款RPA产品来。这让我想起当初Windows刚刚发家的时候，不止是中国，在世界范围内都有无数的人在想“就这？我也能做出来！”然而这么多年过去了，现在市面上有名有姓的操作系统还有哪些，大家都心里有数了。
我们要看到，即便大家都基于同一门底层技术开发RPA产品，各厂商之间仍然表现出有高有低的市占率。我掌握的数据表明，世界范围内，第一名的RPA厂商市占率远远大于第二名和第三名之和。这说明，尽管开发一款RPA产品很容易，但决定一款RPA产品成功与否，不仅仅取决于“能否开发出一款RPA产品”。我们需要更多地综合考虑其它方面。
以下我就不提具体产品名称，以个人观点点评一二。大家自行对号入座，看看我说的有没有道理。
先说国外的产品。
某厂商在RPA领域市占率是No.1，但是产品架构方面有点幻想主义。一方面，把RPA宣传得好像“居委会大妈都会用”的工具，另一方面，产品架构上又比较陈旧，许多自动化效果需要用户通过一定的设计技巧来实现。这就有点自相矛盾。可能厂商后来也意识到这一点，花了不少精力搞了个简易版产品，方便“居委会大妈”类型的用户进行傻瓜式开发。我就想问，你知道微软有个数据库产品叫SQL Server吗？你知道SQL Server有个组件叫SQL Server Reporting Services吗？你知道SQL Server Reporting Services有个号称“方便业务人员开发报表”的工具叫Report Builder吗？然后微软推出了Power BI，Report Builder就死了。。。所以微软替大家踩过的坑，大家一定要自己再踩一遍？设计产品的时候，不要天真地以为客户会买单好吗。开发过程看起来好像是简便了，但是用户必要的功能也少了很多。拳头产品的架构对一些常见的设计模式不去想办法尽快封装起来，整天搞这些玩具！不过No.1的缺点同时也是它的优点，虽然用了微软的过时框架，但建立在.Net上就导致，.Net的开发人员很容易转变成No.1的用户（学习门槛低），而且.Net社区的扩展什么的也很容易安装进来用，在扩展性方面表现非常好。
某厂商在RPA领域市占率是No.2。No.2本来是No.3的，近两年才慢慢爬到No.2的位置上。No.2跟No.1的产品设计思路完全相反。No.1是不做很大的封装，让大家有一定的*度去发挥，结果开发相对有点繁琐，只能实现“低代码开发”。而No.2则是希望大家省力，把常见的自动化任务模式化，封装成一个个组件去拖拖拽拽就行，号称“零代码开发”。No.2的尴尬处境充分反映了过度封装对市占率的影响。用户实际会遇到什么样的自动化场景，你厂商怎么可能事先就完全兼顾？这就造成，No.2的用户经常需要写VBA，写Python，写Java，然后由他家的产品来调用。所以说，所谓的“零代码开发”，其实是他家的产品没有提供“用代码开发”的功能，但是在实际项目中需要用的功能，用户都得自己动手用别的工具开发。。。我觉得吧，封装起来让用户方便一些，这个大方向是对的，但是封装过头。。。反正市占率摆在这里了，你让我怎么说？除了技术方面，No.2的起步价太高，一套至少16万人民币起步。国内许多RPA用户刚上来只是想试试水体验一下，你一开口就16万？人家No.1的起步价就几万块，甚至还有国内厂商倒贴人天卖产品的，你怎么打得过？No.2的尴尬是多方面且显而易见的（特别是在国内）。但我也不是在嘲讽它，人家毕竟做到了市占No.2，我觉得有需求才能活得下去，可能有些用户就是喜欢这样子同时开着多个IDEs，一会儿写Java一会儿写Python一会儿写VBA，最后声称他们在用“零代码开发”的RPA工具吧。。。另外我做过测算，“有人值守机器人”，“无人值守机器人”，以及“机器人调度器”在特定数量组合的时候，No.2确实会比No.1优惠很多，可能在一定的部署数量时经济优势才会体现出来。
所以说，常用的技术逻辑如何“封装”成一个功能模块到RPA产品中，对一款RPA产品能否成功影响非常大。要求RPA产品设计师有非常深厚的功底，既要方便用户开发，又要保留一定的*度，需要慎之又慎，把握好平衡。总之目前数据看来No.1还是No.1，只要他不瞎搞，在未来五年内都不太可能会突然改变No.1的地位（第一名第二名之间实在差距非常大）。
国外No.3的产品我用得不多，不多说。我只知道它的License起步价也高，但是授权模式比较友好，适合企业大批量部署（换句话说就是不适合。。。）。不过中文的学习资料什么的比较少，目前战略上不做改变的话在国内基本做不起来。主要是没有人，没有社区。国内的RPA开发人员可能10个里面有8个用的是No.1，1个用No.2，剩下的1个用别的。企业需要用No.3的时候，市面上很难找到会用No.3的人，那么企业就不会轻易采用No.3。而企业不用No.3，又会导致愿意自主学习掌握No.3的开发人员不足，就业机会少的技术，谁学嘛？这形成一个恶性循环。总之国外的No.3，放在中国可能No.10都排不上。。。这一点对于国内的厂商来说也一样。
国外的其它产品在国内市占率低到可以忽略不计。
国内的产品呢？
知名度比较高的就是那家以Python语言为基础的厂商了。那家厂商的产品，说得粗俗一点就是“喜欢脱裤子放屁的用户”才会去买。Python本身已经可以实现自动化操作，网上教程一搜一大把，人家会Python的人为什么要特地买你家产品来“方便开发”？这不就跟“脱裤子放屁”一样多此一举么？很多时候，Python与RPA工具的存在是互斥的，用Python解决的问题，一般没人会用RPA工具再去解决一次，反之亦然。整天靠国内的招投标赚钱。在没有招投标的地方，你还能不能赚到钱？人家No.1发家的时候，是靠着招投标一步一步走向全世界的吗？而且用了你家的工具，是不是真的“方便开发”，我还要打一个问号，毕竟实际的代码量也不少了。另外，近期有IT新闻说国外一位大一学生开发了一款基于Python的“低代码开发工具”，界面看起来居然跟你家的极期相似。。。对此我要打另一个问号了。以前招投标的时候与这家厂商碰巧遭遇过一回，商业上略有了解。我只能说同样是RPA产品，有的产品是面向开发者，有的产品是面向某某主任科长局长行长院长。。。但凡招标说明里面要求RPA工具“支持Linux”的，一定有这家公司来投标。你们公司的Office平常都跑在Linux上吗？那您可真牛逼！优势是会Python的人市面上一抓一大把，倒是不缺人手，至于人手的质量怎么样，就见仁见智了。
另一家知名度比较高的厂商我是蛮看好的，有过长期运营软件产品的经验。他们的问题在于不是利用现有的主流编程语言，而是自创了一门语言。这导致RPA从业人员在做学习规划的时候会有所犹豫，通常大家更愿意学习就业机会多的技术，而不会选择钻研这种“某一家企业独有”的技术。不过好在这家厂商老产品的用户正在逐渐接受他们的新RPA产品，社区在逐渐壮大。另外，产品设计上，感觉与许多软件的集成还有很大的改进空间，竞争对手的产品三两下操作就能搞定的事情，到这里操作就要繁琐一些。产品界面我也是一直在诟病，感觉上好像是哪个程序员兼职的UI设计师随便做出来的，什么抽奖啊广告啊商业软件不该有的它反倒全都有了。另外，它的社区版本开放得也比较晚，社区版调度器也没有开放让用户*注册，我觉得会明显妨碍社区的培养。另外，这家厂商以前是长期运营ToC软件出身，战略思维上对ToB软件的一些做法还没啥概念，总觉得“我资源有限所以这没法做那没法做”。然而ToB的东西本来就要求厂商有很多的前期投入，毕竟企业客户通常都不喜欢当小白鼠。这种另起山头自研产品的公司挺不容易的，优势是产品不会受那么多限制，功能上相对比较贴合用户需求（自己家的代码自己好改），而且确实是可以说“自主可控”。这家公司尴尬的地方在于，使用他家产品的开发者非常多，但是采购他家产口的企业相对少一些，说明要取得B端客户的信赖还有很长的路要走。
国内比较值得说的也就这两家。目前国内的客户招标，要么是国外No.1和No.2打来打去，要么就是国内的这两家打来打去，总之客户一般在招标前就会有所倾向，一开始就会设定好条件排除这个或者排除那个了。
其它的国内厂商呢？要么是PPT产品，宣传说得很大声，产品在哪完全见不到。要么是整天都在招人，而且招的职位还非常高，各种职位，让人心生疑虑“你家的前总监/前总经理/前架构师/前。。。哪里去了？”被甲方祭天了还是跳楼了总要有个交代吧？还有一些厂商据说确实有产品，确实有客户在长期使用，但就是不敢放出来让社区用户看看，连帮助文档都得是客户才能看到，你说你这样搞，需要人的时候上哪找人去？还有一些，别家产品的优点呢，不好好借鉴研究学人所长，总想着跟人不一样，结果反倒兼俱各家之短。或者跟别家同质化严重。。不提也罢。
欢迎扫描下方二维码加入UiPath精英群