浅谈RPA工程中的POC

因为工作中最近要涉及到各种不同情况下的POC工作，所以特此做了一个总结。

POC通常发生在还没进行部署RPA工程的企业，这些企业期望根据公司的业务需求或公司未来的发展布局来部署机器人流程自动化，降本增效，期望可以大量减少人工无为的耗时，来提高工作效率，把更多的时间留给精细化管理和创新，以国企的角度来看，不仅是响应国家号召，推动智能自动化，更是赶上信息化时代的潮流，走向国际前沿。

以下是整理了一张前期做POC准备的导向图。

在说导向图之前，先说一说做POC时候可能涉及的两种形式：第一种就是客户已经认定了一种产品，那么客户会直接选择这款产品去做POC，还有一种就是做POC去进行产品比对，客户想看看哪一种产品更为优秀。他们通常会选择三四款产品去对一个他们已经挑选出来觉得很适合的场景来进行PK，但是以我个人以往经验来看，这很大程度上不是产品的一决高下，而是取决于现场实施人员的水准，客户场景通常会涉及B/S或者C/S，有网页版BI，GUI界面的SAP，ERP系统的各个情况，以及Office产品，还有核心的大数据处理等结构算法，实施人员如何在客户环境切换内外网，如何对页面元素做灵活处理，如何对大数据做高效的优化，快速汇总核算出数据模板等等，都是一个非常重要的考量，所以产品比对，对RPA软件的考量真的不大，更多的在于实施人员本身，换句话说，即使没有RPA软件，对于一个优秀的RPA实施人员来说，他也会快速做出一个高效优质的RPA工程，这其中包括网端爬虫，句柄控制，鼠标和键盘模拟，百万级数据的结构算法，以及异常情况的消息机制和流程灵活导向等。

导向图中第一步要做的就是业务流程调研收集，收集业务需求的时候会遇到以下几种情况，第一种：客户自己能很配合的根据你的要求整理出业务需求，这样就很省事。第二种：客户不知道怎么去做这样的需求整理，那么就需要你去引导或者亲自调研，理想的方式是，把业务流程重现一遍用视频录下来配上语音讲解，文档的话在客户环境先做一个简单的SOP文档，图文标配，为后期做细节准备。那么前期文档准备大概也会有两种，一种是SOP（标准化操作流程），一种是BRD（业务需求文档），这两种并不是都要而是其一，先看BRD的文档说明要求。

里面绿色是主要部分，搞清楚项目的背景和目的，以利于把控整个项目，甚至可能还会有延伸，涵盖的区域，以及流程展示和当前涉及的系统，是否因为RPA软件的缘故，在内外网不能连通。

这个是SOP的文档说明，虽然有区别，但是大同小异，这里面会有异常的特别说明，这也是做流程自动化尤为注意的地方。

文档梳理完毕，那么就需要去评估用RPA是否可行，在大多数规则固定的情况下不考虑公司内部信息安全因素，基本都是可行的，在这个前提下考虑验证性方案，那么什么情况下没有可验证性的需要，第一个就是异常情况无法全部覆盖，其他情况下你无法进行灵活导向，第二是时间的考虑，方案在白天和夜晚时间段的干扰因素会有不同，无法进行精准判断，需要人工参与决策，也会有一些其他因素无法验证。

所以鉴于种种原因，我们做POC其实是为了推行RPA，因此在起初建议我们理应挑选规则固定，不需要人工参与，又有大量重复的场景进行POC，这样客户会很快看到成果，由点及面能快速扩展开来。如果说场景中的异常情况我们无法在短时间内重现或者一些异常我们无法明确估量，建议先做异常情况的准备工作，等到灵活类可控的时候再做，那么这个流程的质量和效率就会很高。

那么在做POC的时候，是否可以远程呢，个人建议是即使有条件去做远程，最好还是在现场，可以在做的时候遇见问题及时和客户做沟通，我遇见过做RPA的时候，项目经理把实施人员撂到一边，直接和客户沟通，结果项目经理把流程在告诉实施人员的时候味变了，做出来的东西客户会承认吗，所以最好的沟通就是相关人员都在场，千万不要做一个中间人的传递者，另一点最为重要的是，你的流程图设计出来以后，不要直接就实施，你最起码得给客户讲清楚你为什么这样设计以及好处，需要得到客户的确认和认可才能进一步实施落地方案，即使后期有些问题没有考虑周到，那么客户也是认可可以再延长时间做进一步的优化。

最后一点就是RPA质量决定着业务人员对这个产品的满意度，所以遇见问题不要自以为就是这样或者那样，要说流程，那业务人员是最熟悉不过的了，和他们的及时沟通和交流是非常必要的，只不过业务人员和开发人员在思维模式上可能有所不同，你需要做的就是如何引导客户去把流程中可能隐藏的点说出来，因为RPA工程需要我们考虑全面，但是另一面说，就实施可行度又需要我们把复杂的问题简单化，方案白天不可行，那晚上是不是就可行，对复杂的流程通常情况下完全自动化并不高，用人为参与的方式去把流程分解，来提高准确度和效率也是我们需要考量的方案之一。