定制化VS标准化，RPA的出路在哪儿？

走标准化产品模式，还是做高度定制化解决方案？

这是RPA乃至所有To B科技公司面临的战略选择。关乎估值，关乎增长。

过去五年，无数抱有做标准化平台愿景的AI公司，在趟过数不尽的坑后，业内才终于达成共识：越重的定制化，越有机会活下去。

而随着AI与RPA等技术的应用愈发成熟，不少传统企业的IT基础建设也逐步完善，“标准化”再次浮出水面。

为此，雷锋网AI金融评论策划了「RPA标准化」的系列选题，借同一个话题，对不同背景的受访者、产品和客群各异的企业们进行采访，期望在不同的商业认知下捕捉观点碰撞的火花。

本系列选题的第一篇文章，由文因互联CEO、联合创始人鲍捷讲述他眼中的RPA标准化命题。

同时，「RPA+AI系列公开课」也在进行当中。在本篇中接受采访的鲍捷，将会在今晚8点（4月11日）做客雷锋网公开课，更加深入地分享RPA从1.0到4.0时代的关键路径。

以下为鲍捷的所感所想：

RPA的完全标准化是伪命题

根据多年的切身体会，我认为面向企业服务的RPA厂商，整个业务流程是很难标准化的。

如果它能标准化，To B服务早就SaaS化了。标准化服务不是RPA这种承载形式能够提供的。

同时，在某些局部流程上又是可以标准化的，但要遵循一些特点。

• 第一，这个流程操作相对简单，而且在企业里处于边缘地位。如果一个业务的流程在企业内部处于核心地位，比如银行的风控，是绝对不可能将它标准化的。

• 第二，它是国家强制性要求的、本身就比较规范的流程，比如财务报表。正因为国家有一个合规和强制的要求，使得目前的一些流程得以标准化。

否则，对于To B的RPA厂商来说，无论是需求理解环节、内部流程的构造环节、内部系统的接口环节，还是数据打通之后、生成新数据的环节，这些传统的流程都不太可能被标准化。

我在金融领域做的业务比较多。在银行，客户经理要做一笔贷款，我们会将财务报表进行分析，生成财务报告，这个流程是有可能标准化的。但是如何生成财务报告，每家银行其实不完全一样。

定制化和标准化之间会有一个过程，在垂直行业里，需要积累很多年，通常来说你要服务几十上百家客户。而这个阶段，你看起来非常像一个外包公司。

RPA的标准化，只有两条出路。

一种就是做“前端”的东西，比如专门做火车票、做差旅报销、做身份证识别、做上市公司财务报表的识别，只做一个点。公司不要把摊子铺得太大，聚焦在一个细分领域，每年收入可能不多，不会快速地增长到很大。但是这样能够让毛利率和净利率变得很健康，变成一个小而美的企业。Uipath一开始就是小而美，头十几年没怎么融资，也活下来了。国内其实也有不少这样的公司。

另外一种最底层的知识库管理系统也是可能标准化的。RPA也叫机器人流程自动化，所说的流程其实就是知识，是大量的业务规则，大量规则的管理就是知识库管理系统KBMS。这个上面会出现未来的Oracle和SAP，提供标准化的底层知识计算平台。

至于在中间的比如编辑器之类的，很难摆脱咨询的命运，也就很难标准化了。

我之前看到有统计说，90%以上的RPA项目都失败了。这是因为客户的预期和RPA实际能做到的，这中间有一个巨大的Gap。客户可能读了很多宣传以后，会认为上一套系统，流程立马就可以自动化了。而实际情况并非如此。

RPA需要长时间的行业积累，才有可能逐渐的从零件化到配置化，再到标准化，它是一个渐进的过程，很难一步到位。

RPA不能标准化的原因，有哲学层面的、有系统层面的、还有实操层面的，是多方面的原因。

从哲学层面来讲，最深层次的问题，RPA是一种流程自动化，是一种企业IT服务，它并不新颖，很早就有，只是在不同的时候叫不同的名字。

比如在20年前，我读博士的时候，那时候管它叫企业数据集成，和现在RPA处理的是一样的问题。那时候其实大家也开发了各种各样的小工具来做，但为什么这个事情它始终就做不大？因为企业流程本身其实是一种世界观，没有两个企业的世界观是一样的，同样，没有两个企业的流程是一样的。

在一个组织内，能够走得通流程的方法，在另一个组织内就是走不通。比如你去比较一下钉钉、飞书这两种同样是做办公软件的团队，你会发现他们的汇报流程、工作模式是完全不同的。

再比如说每一个企业它都有内账外账。

当企业做财会的流程自动化时，首先你得搞清楚，你是帮这个企业做外账的流程自动化还是内帐的流程自动化。

如果是外账的流程自动化，是可能做到标准化的程度的。因为国家要求企业每年到税务局必须报这些科目，但是内帐的标准化就不可能做到，因为每个企业的内部情况都不一样。

第二，是系统层面的原因，RPA要解决的，实际上是系统之间数据打通的问题。

一家公司内部，有的系统十年前就有，有的系统去年刚建成，有的系统即将完工，这些系统之间都没有合适的接口连接，我们需要把这些系统之间的数据打通。但没有两个企业的IT系统一模一样，系统都是由不同厂商在不同IT平台上、不同操作系统上实现的。

所以RPA服务商要去跟不同的windows版本进行抗争。在不同的机器上面有不同的配置，有的机器上装杀毒软件，它们都会给RPA的运行制造困难，然后你就会陷入bug的汪洋大海里去，和不兼容性做斗争，RPA厂商得做非常多的补丁，才能解决这些问题。

如果是做企业RPA服务的话，那么它的核心问题其实是一个概念建模的问题，绝大多数的企业客户自己的IT人员不具备这种建模的能力，所以你提供RPA商城也好，提供给它可视化编辑页面也好，其实它是用不起来的。

归根结底是因为大多数客户没有相应的建模能力，而不是一个界面本身好不好用的问题，还得看他这个RPA商城到底能不能把产品和服务销售出去。客户本来就没有义务有概念建模的能力，这个是RPA服务商应该提供的服务。

我认为面对To C用户的RPA商城倒是有可能成功的，比如IFTTT 之类。如果产品做到可以让客户不懂编程也能使用，不涉及流程编辑，而且整个流程也不涉及底层系统的对接，这样的商城是有可能成功的。

RPA的四个阶段

当前的RPA大致可以分成两代：1.0版本是对于手的自动化，可以类比为“游戏外挂”，例如按键精灵；2.0版本是对眼睛和耳朵的自动化，例如目前这种搬运非结构化数据，并且自动化数据提取流程的类型。

从RPA1.0到2.0，就是自动化体力劳动，向自动化脑力劳动的转变。

未来RPA还可能会演化到3.0版本，它将成为一个以知识库为基础的企业内流程化自动化管理系统。

目前行业大致在RPA2.0~3.0阶段。

RPA2.0是去年年底时开始兴起的，它在RPA1.0的基础上，加上了OCR和NLP这两种技术。

RPA1.0时代，RPA只能解决结构化数据的问题，但RPA2.0可以解决非结构化数据在应用之间转移的问题。然而它们两者本身还都是在做数据的转移。

虽然RPA2.0时代，因为加上了OCR等技术，和AI进行了融合，但它的本质并没有变。本质上RPA都是在提供一些标准件。

再往前可能还有RPA的4.0，解决企业之间的资源调度自动化，如开放银行、供应链自动化等等。

今晚的分享，我主要和大家聊聊这部分，RPA 如何从1.0 演化到4.0，过程中涉及的核心技术以及实现的效果如何。

RPA本质上是咨询

业务咨询和RPA技术的结合，我认为这件事情肯定是成立的，而且在我看来这是一种新的商业模式。

其实我之前也一直在思考，为什么SaaS不能落地？为什么中国的To B的企业都像外包公司？

后来我想明白了，我认为在中国其实需要一种新的商业模式，我把它称为CAAS（consulting as a service），它是在中国环境下被逼出来的一种模式。我认为国外应该还是没有这种商业模式的，SaaS已经被接受，没有必要让每家服务商也具有咨询能力，同时也存在了大量垂直的服务商可以因为自己的专业服务而收费，它可以越过这个阶段。

而在中国，实施能力和咨询能力的分离造成了一个两极分化，咨询和外包是两个极端。

以前的咨询公司只能把咨询的结果转化成一大堆报告，而现在的CAAS服务公司可以把咨询的结果变成一个IT系统。

所以从这个角度来说，RPA公司和咨询公司的合作从逻辑上是成立的，而且未来的咨询公司一定会加强自己的RPA能力，而RPA公司一定会加强自己的咨询能力，两方最后甚至可能出现合并。

按照这样的一个趋势，两个行业都可能产生一种颠覆性的结果。从这个角度来说我认为RPA的前途是非常美好的。

从我们当前业务流程来看，首先客户提供资料并且跟我们说要在这些资料上面做什么样的事情，然后我们的业务经理会跟他们一起坐下来分析具体的需求，想要实现什么效果，什么可以做到，什么无法做到，实施的效果如何等等。

这其实就是一个典型的咨询过程，RPA服务商要懂客户的业务并且要多一个前沿技术视角，比客户更明白他能实现什么并且帮他做到。

雷锋网(公众号：雷锋网)（公众号：AI金融评论）

雷锋网原创文章，未经授权禁止转载。详情见转载须知。