ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

RPA选型指南:影刀、来也UiBot等5家厂商场景与成本对比

RPA选型指南:影刀、来也UiBot等5家厂商场景与成本对比 上个月一个做电商的朋友找我喝酒开口第一句话就是公司想上RPA销售给他推了三家报价差了三倍他完全不知道该信谁。这事儿我一点都不意外。RPA这个赛道从2019年火到现在国内叫得上名字的厂商两只手数不过来每家的PPT都写着低代码AI加持全场景覆盖可真到落地的时候差别大得离谱。有的工具新人两天就能拖出一个能跑的流程有的工具光环境配置就能卡你一周有的按机器人数量收费有的按调用次数收费算下来成本能差出一个人的工资。这篇东西我打算把国内头部5家RPA厂商掰开揉碎讲一遍影刀、来也科技UiBot、艺赛旗、实在智能、金智维。不讲虚的就说各家适合什么场景、组件体系长什么样、Excel数据处理和网页自动化这类高频需求谁做得顺手、什么样的团队容易踩坑。如果你正在做RPA选型或者刚入行想搞清楚这个行业的地图又或者你是个想用RPA把自己的重复工作干掉的一线业务人员这篇应该能帮你省下不少试错时间。我说话比较直可能会得罪人但选型这事儿听好话是要付学费的。1. 选型之前先想清楚你拿RPA干什么1.1 三个真实需求场景决定了选型方向我见过太多团队在选型阶段就开始比功能清单把厂商的功能表打印出来逐条打勾最后选了个功能最全的结果上线三个月没人用。问题不在工具在于一开始就没想清楚自己到底要解决什么问题。RPA能干的活儿其实可以粗暴地分成三类这三类对应的厂商能力模型完全不同。第一类是电商与运营类的高频重复操作。典型的就是商品批量上架、订单抓取、评价回复、库存对账。这类流程的特点是页面结构经常变、业务规则变得快、对开发速度要求极高一个运营人员最好当天提需求当天就能跑起来。这类场景拼的是可视化编辑器的易用性和社区组件的丰富度对底层架构的要求反而不高。第二类是财务、人事、行政的表格与系统录入。发票验真、银行流水下载、报销单录入、社保数据核对这类流程的核心是Excel数据处理能力和对老旧系统没有API、只有客户端界面的操控能力。它不需要多炫的AI但要求极强的稳定性——一张对不上的表就可能引发审计问题。第三类是金融、政务、大型制造的后台批量作业。信贷审批的资料归集、理赔资料调取、生产排程数据同步这类场景的特点是流程长、并发高、对审计日志和权限管控要求苛刻一年的机器人运行时长可能顶前面两类加起来。这类场景选型价格和易用性都得往后放先看稳定性和合规能力。我自己总结的一个判断标准是如果一年内你的流程数量会超过50个且大部分是短流程选易用性优先如果你只有10个流程但每个流程每天跑几千次选稳定性优先。这个判断能帮你砍掉一半的候选厂商。1.2 我用的对比维度与打分方式为了让对比有据可查我把评估拆成五个维度每个维度给不同权重权重是根据我实际见到的项目失败原因反推的。维度权重具体看什么编辑器易用性25%拖拽逻辑是否自然、调试是否方便、新人上手时间组件与扩展能力20%内置组件数量、Excel/网页/数据库支持、能否写代码扩展稳定性与异常处理25%元素定位成功率、断点重试、日志完整度、长时间运行表现生态与支持15%文档质量、社区活跃度、厂商实施团队响应速度总体成本15%授权模式、机器人单价、并发扩容费用、隐性培训成本权重这么分是有原因的。我参与过的一个项目选了个组件特别全的工具结果元素定位在目标系统上只有七成成功率一个流程每天要人工补三次最后整个项目黄了。稳定性这一项我给到25%是因为它决定项目能不能活到验收那天。易用性同样给25%是因为很多RPA项目死在没有专职开发人员上——业务人员学不会IT部门又不愿意接工具再好也是摆设。至于成本我放在15%不是因为它不重要而是因为RPA的总成本里工具授权费其实只占一半左右另一半是实施、培训、维护和流程变更带来的人力投入。只盯着授权价选型通常会在第二年付出更多。2. 国内头部5家RPA厂商逐个拆解2.1 影刀RPA电商运营场景里跑得最快的那一个影刀这几年在电商圈的存在感非常强我在好几个做店铺运营的团队里看到他们的运营人员自己在写流程。它的核心优势就俩字顺手。编辑器是那种你打开就知道怎么用的类型左侧组件树、中间画布、右侧属性面板拖一个打开网页再拖一个点击元素五分钟就能跑出第一个能用的流程。对没有编程背景的运营人员来说这个门槛低得有点不讲道理。它的组件体系明显是围绕电商和网页自动化长的。网页相关的组件颗粒度做得很细抓取列表、翻页、处理弹窗、上传文件、等待元素出现这些高频动作都有现成的封装。Excel数据处理这块也不弱读写单元格、按条件筛选、循环行、写入新表都是可视化配置不需要写一行代码。我见过一个运营妹子用它把每天两小时的评价回复压缩到十五分钟她就是照着实操教程一步步拖出来的。但要说清楚它的边界。影刀在超长流程、复杂条件分支、高并发调度这些场景上跟金智维这类偏后台的产品比是有差距的。如果你的流程涉及十几个系统交叉调用、每天要跑几万次、还需要完整的审计追溯那在影刀上做会越做越别扭。另外它的社区组件质量参差不齐有些第三方封装的组件看着方便实际上没有处理异常跑起来在关键时刻掉链子。我个人的建议是如果你是电商、内容运营、市场营销这类节奏快的团队流程数量多但单个流程不长影刀大概率是性价比最高的选择。它的学习曲线平缓到你可以让业务人员自己维护流程这一点在长期运营中的价值被很多人低估了。提示电商场景下网页元素变化极其频繁选任何工具都要养成元素定位加多重兜底的习惯不要只靠一种定位方式否则平台改一次版你就得返工一次。2.2 来也科技UiBot开发者社区最厚的一家来也科技的产品线比较长UiBot是它的RPA产品线另外还有对话机器人和文档处理相关的产品。如果只看RPA本身UiBot最大的特点就是开发者友好。它的编辑器支持可视化拖拽同时也留了很完整的代码扩展入口你可以用Python或者内置脚本语言写自定义逻辑组件的封装规范也比较清晰会写代码的人可以把自己的常用逻辑封装成组件复用。它的社区生态在国内RPA厂商里算是投入比较早的。教程、案例、问答的量级都还可以新人遇到问题在网上搜到的概率比较高。这一点看着不起眼实际上很关键——RPA落地过程中大量时间花在这个报错是什么意思上面社区里能搜到答案等于直接省下技术支持的成本。组件能力方面Excel、网页、数据库、邮件、文件系统这些基础能力覆盖得比较全OCR和文档解析这类跟AI结合的能力也有集成。它在流程编排上支持比较复杂的逻辑条件分支、循环嵌套、子流程调用都做得规整适合那种流程逻辑本身就比较复杂的场景。它的问题在哪我觉得是东西太多。产品线拉得长导致新人在文档里要花时间才能找到自己需要的那一块。另外它的稳定性在极端场景下的表现我听到的反馈不如金智维那么一致当然这可能跟客户群体有关——来也的客户结构比金智维分散遇到的系统环境更杂乱。适合谁有IT支持、流程逻辑中等偏复杂、希望产品能顺手扩展到文档处理和智能对话场景的团队。如果你的团队里有会写代码的人UiBot的上限会比纯可视化工具高不少。2.3 艺赛旗iS-RPA老牌选手金融与制造的落地经验厚艺赛旗在国内RPA圈算是起步很早的一批做企业级流程自动化有年头了在金融、制造、运营商这些行业积累的案例比较多。它的产品特点用一个词形容就是规矩。权限体系、流程版本管理、机器人调度、运行日志这些企业级的能力做得比较完整符合大型组织对IT系统的管理预期。它的组件库广度不错除了常规的网页、Excel、数据库操作在图像识别、验证码处理、跨系统数据搬运这些硬骨头上有一些积累。制造业场景里经常遇到的客户端软件操作没有网页结构、只能靠图像和控件识别艺赛旗的经验相对更多。编辑器方面我个人的感受是它比影刀要重一些功能入口更多、配置项更细新人上手需要花的时间更长。这不是缺点只是定位不同——它面向的是需要严格管控的规模化管理场景不是给业务人员随手写小工具的。一个流程要经过开发、测试、上线、版本迭代的完整生命周期这套东西就显出价值了。要说需要注意的地方艺赛旗的产品在电商这类轻快场景上的灵活性不如影刀如果你只是想做几个网页抓取的小流程用它有点杀鸡用牛刀而且学习成本不划算。另外它的社区活跃度在国内几家里算中等很多问题还是靠厂商支持解决。适合谁金融、制造、能源、运营商这类对流程管控和审计有硬要求的中大型组织尤其是流程里涉及大量客户端软件操作的场景。2.4 实在智能把AI能力往RPA里塞得最猛的一家实在智能的产品路线很清晰就是把AI能力当作核心卖点。文档理解、票据识别、自然语言处理、界面元素智能识别这些能力在它的产品里被包装成开箱即用的组件。你不需要自己去接OCR接口直接拖一个组件配置一下就能用这对于要处理大量非结构化文档的场景确实省事。我实际见过的典型用法是财务共享中心的票据处理扫描件进来用文档理解组件提取关键字段再跟系统里的数据做比对最后自动填单。这类流程传统做法要接第三方OCR再做复杂的后处理用实在的产品确实能省下一些集成工作量。它在元素智能识别上也有投入页面结构变化时的自愈能力比纯规则定位要强一些。但要提醒一句AI组件不是银弹。识别准确率再高也总有识别错的时候关键是看它有没有给出置信度和人工复核的入口。如果一个流程识别错了还继续往下跑把错误数据写进业务系统那问题比不做自动化还严重。我在实际项目里的做法是凡是AI识别的结果都设一个置信度阈值低于阈值的走人工复核分支不要图省事全自动。编辑器和整体体验上实在智能属于中上水平可视化做得比较清爽上手不算难。它在某些垂直行业比如财务、政务的方案包装做得比较成熟如果你是这些行业且对文档处理需求很大值得重点看看。适合谁有大量非结构化文档处理需求、愿意接受AI人工复核混合流程的组织尤其是财务共享、政务审批、保险理赔这类场景。2.5 金智维K-RPA金融后台的稳定派金智维在金融行业的份额不用我多说尤其是银行、证券、保险的后台运营场景见到它的概率很高。它的产品气质跟前面几家明显不同不追求编辑器多花哨追求机器人跑一年不出事。稳定性、并发调度、运行监控、审计日志这些是它的立身之本。技术上它支持很高的并发密度一个调度中心管几百上千个机器人是常规操作任务的排队、优先级、失败重试、超时控制这些机制做得比较成熟。日志的完整度也高出了问题能追溯到具体是哪个元素、哪一步、哪个数据出的错。对金融行业来说这些能力不是加分项是及格线。编辑器方面它的学习曲线是这几家里偏陡的配置项多、概念多新人上手需要的时间更长。这也是必然的——管理能力强的产品复杂度通常藏不住。它的组件库覆盖常规场景没问题但在电商、新媒体这类偏消费互联网的场景上组件的丰富度和更新速度不如影刀。价格上金智维的定位偏企业级整体投入会比影刀这类产品高一个档。如果你的流程量不大用它确实不划算。但反过来说如果你有几十个流程需要7×24小时无人值守运行且出错成本很高那份钱花得值。适合谁银行、证券、保险、大型国企的后台批量作业场景对稳定性、并发和审计有硬要求的组织。3. 五家横向对比一张表看清差距3.1 综合对比表下面这张表是我结合公开信息、实际使用体验和同行反馈整理的主观成分有但基本盘是真实的。评分是相对值不是说分低的那家不行而是说在特定维度上的相对位置。对比维度影刀RPA来也UiBot艺赛旗实在智能金智维编辑器易用性高中高中中高中组件丰富度电商强全面企业级全文档AI强常规全稳定性与并发中高中高高中高高社区与文档活跃活跃中等中等偏内部电商场景适配强中弱中弱金融后台适配中中高高中高强文档AI处理中中高中高强中上手时间新人1到3天3到7天1到2周3到7天2周以上成本量级中中中高中高看这张表的时候有个坑要注意上手时间短不等于总投入低。一个上手很快的工具如果稳定性不够后期补漏的人力成本会远远超过前期省下的培训时间。反过来上手慢的工具如果流程本身很少那点学习成本摊薄下来也不算什么。所以别只看一列要结合自己的流程数量和变更频率一起看。3.2 按业务场景的选型路径我把常见的选型困惑整理成几条路径你可以直接对号入座。路径一电商运营团队人数不多需求杂且变化快。优先看影刀重点验证它的网页自动化和Excel处理在你的目标平台上跑得稳不稳。验证方法很简单拿一个你最头疼的流程让厂商或者你自己用试用版做一遍跑一周看失败率。路径二企业IT部门主导要统一管理多个部门的流程。优先看艺赛旗或金智维重点看权限体系、流程版本管理、调度中心的能力。这里的关键问题是多个部门共用一个平台时权限怎么隔离、流程怎么上线审批、机器人资源怎么分配。这些问题在选型阶段不搞清楚上线后一定会吵架。路径三财务、政务文档处理占比大。优先看实在智能但要重点测试识别准确率和置信度机制别被演示效果迷惑。测试方法是用你自己的真实票据跑一百张看错了多少张错的那些有没有被拦下来。路径四团队里有开发人员流程逻辑复杂。优先看来也UiBot重点看代码扩展能力和子流程编排。有开发能力意味着你可以把RPA当成一个半自定义的自动化平台来用上限会高很多。3.3 混合选型的现实做法我见过不少团队纠结只能选一家吗。答案是没必要只选一家尤其是中大型组织。比较务实的做法是分层选型面向业务部门的轻量流程用易用性强的工具让业务人员自己维护面向核心系统的重流程用稳定性强的工具由IT部门统一管控。两套工具之间通过文件、数据库或者接口传递数据。这么做的好处是各取所长坏处是维护两套平台会增加管理成本。我的建议是当你的流程数量超过100个、且明显分成轻和重两拨时再考虑混合方案否则一套工具吃下来更省心。4. 动手实战Excel数据处理与网页自动化的核心写法这部分讲的写法是跨厂商通用的思路具体组件名称各家不同但逻辑一通百通。我尽量把能直接抄的部分写清楚。4.1 环境准备与流程骨架不管用哪家工具RPA项目的起手式都差不多我把它拆成四步。第一步是明确输入输出。写流程之前先在纸上或者在文档里写清楚输入是什么一个Excel文件一个文件夹一个网页链接输出是什么写回Excel发邮件写进系统中间要经过哪些系统。这一步看着基础但跳过它的项目十有八九会返工。第二步是确认运行环境。机器人要跑在哪台机器上那台机器的分辨率、浏览器版本、Office版本、目标系统的登录状态都要提前确认。我踩过的最蠢的坑是开发机分辨率1920生产机1280图像识别的坐标全偏了。建议开发和生产的运行环境保持完全一致包括缩放比例。第三步是搭流程骨架。先用日志组件把主流程的分支结构打出来每个环节先不写具体逻辑只写日志跑一遍看流程走向对不对。这个习惯能帮你在写细节之前就发现逻辑漏洞。第四步才是填具体逻辑并且每填一段就单独跑一次不要全部写完再跑。RPA调试的难点在于错误会互相掩盖一次填太多出了问题你都不知道是哪个环节。4.2 Excel数据处理读写、循环、匹配的常见套路Excel数据处理是RPA里出现频率最高的需求我把几个典型套路讲透。套路一读取整表按行循环处理。大多数工具都有读取区域到数据表这类组件一次把整个Sheet读进内存变成二维数据结构然后循环每一行。这比逐个单元格读取快得多——逐个读单元格一千行可能要几十秒整表读取通常一秒内完成。这是个很容易被忽略的性能点。套路二多表匹配。典型场景是订单表和库存表对账。常见做法是把两张表都读进内存用订单号建一个字典Key是订单号Value是库存数量然后遍历订单表去查字典。这个写法比双重循环快一个数量级。如果工具支持脚本扩展用脚本实现哈希匹配是最优解如果只能可视化拖拽那就先对两张表按订单号排序再用双指针扫描。套路三写入结果的两种选择。一种是把结果写回原表的新增列另一种是输出到新文件。我强烈建议输出到新文件原文件保留不动。原因很简单RPA出错的时候如果它把错误数据写回了原表你连原始数据都没了。保留原文件等于给自己留了一条退路。套路四处理日期和数字格式。这是坑最多的地方。Excel里的日期本质是数字读出来可能是序列号金额可能是文本格式直接参与计算会报错。稳妥做法是读取后统一做一次类型转换和清洗把空值、异常值单独挑出来记日志不要静默跳过。注意处理金额、税率、数量这类关键数据时不要用浮点数直接比较相等浮点精度会让你在对账时出现一分钱的差异改用具两位小数的定点比较。4.3 网页自动化元素定位的三种方式与稳定性取舍网页自动化是RPA的看家本领也是最容易翻车的部分。元素定位方式主要有三类各有取舍。第一类是DOM选择器定位比如用元素的id、class、XPath或者CSS路径去定位。这是首选方式因为它不依赖坐标、受页面缩放影响小、执行速度快。缺点是页面结构一变就失效。写XPath的时候有个技巧尽量用相对路径加属性匹配不要用绝对路径。绝对路径像/html/body/div[3]/div[2]/table/tbody/tr[5]/td[2]页面加一个公告栏就全废了相对路径像//input[nameorderId]抗变化能力强得多。第二类是文本定位通过页面上显示的文字去找元素。这种方式直观、好维护适合按钮文字稳定的场景。缺点是遇到多语言、动态文字比如提交(3)就不好使。第三类是图像识别定位截取元素的样子去匹配。这是最后的手段用在无法获取DOM的场景比如某些客户端软件、特殊渲染的页面。它的缺点是受分辨率、主题、缩放影响大速度也慢。我的建议是把图像识别当兜底不要当主力。实际操作中的稳定性技巧有这么几个。一是多重定位兜底先试DOM失败再试文本再失败试图像三层下来成功率会高很多。二是显式等待替代固定延时不要用等待5秒要用等待某元素出现最多等5秒前者浪费时间且不一定够后者快且准。三是给关键操作加验证点击提交之后一定要验证页面出现了预期结果而不是点完就往下走否则后面全乱。4.4 电商批量上架这类流程的拆解思路电商商品批量上架是很多人学RPA的第一个目标流程我把它拆开讲一遍思路可以迁移到其他网页流程上。第一步准备数据源。一般是一个Excel每一行是一个商品列包括标题、价格、库存、图片路径、类目、属性。这一步的关键是数据要干净标题里不能有多余空格价格必须是数字图片路径必须真实存在。RPA不做数据校验的话上传到一半报错你会很崩溃。第二步登录并进入到上架页面。登录环节建议用人工登录一次、之后复用会话的方式不要在流程里硬编码账号密码——这不安全而且很多平台有验证码自动化处理很麻烦。第三步逐行填写表单。这里最容易出问题的是动态表单选了类目之后属性字段会变。处理办法是先把类目填写固定下来把属性字段的定位规则也固定然后在流程里做选择类目后等待属性区加载完成的判断。图片上传通常需要模拟点击系统的文件选择框这一步往往需要图像识别或者键盘输入路径的方式各家工具的处理方式不一样要提前验证。第四步提交后验证。上架成功与否一定要验证做法是回到商品列表搜索标题看能不能搜到。不要提交完就认为成功电商后台的校验失败经常是静默的。第五步写回结果。每个商品的处理结果成功、失败、失败原因写回一个新的Excel方便运营人员人工处理失败的几条。最后说一句实话电商平台对自动化操作通常有频率限制和风控机制。做批量上架一定要控制频率、遵守平台规则、避免短时间内大量提交否则账号受限得不偿失。我见过有人为了赶进度把间隔设成0.5秒结果被平台限制操作最后反而更慢。把间隔设在合理区间比如每件商品操作间隔几秒稳定比快重要。5. 踩坑实录那些文档里不会写的问题5.1 定位失效与页面加载元素定位失效是RPA第一大类故障我把它归成三种表现。第一种是偶发失效十个流程里有一两次找不到元素通常是页面加载慢导致的。解决办法是加显式等待和重试机制重试次数设两到三次每次间隔递增。第二种是批量失效某个时间点之后所有流程都找不到元素这基本可以断定是目标系统改版了需要更新定位规则。这类问题的最佳应对方式是建立元素变更的监控比如每天定时跑一个健康检查流程发现异常就报警不要等业务人员反馈。第三种是环境相关失效在某台机器上就是不行换一台就好。这种多半是浏览器版本、缩放比例、字体渲染的差异解决办法是统一环境。页面加载这块有个细节很多人不注意有些页面看起来加载完了实际上关键数据是异步加载的。你以为元素出现了其实是个占位符。稳妥做法是等真实数据出现的标志比如等某个具体的数字或者列表项出现而不是等页面骨架。5.2 授权、并发与机器人的排班流程做完了接下来是部署。这里的问题一点不比开发少。授权模式上各家差异很大。有的按机器人数量授权你买几个机器人就只能同时跑几个流程有的按流程数授权机器人数量不限有的按运行时长或者调用次数计费。选型时一定要问清楚并发怎么算钱、调度中心算不算钱、开发版和生产版是不是分开收费。我见过团队买的时候觉得便宜扩容时才发现并发扩容的价格是基础版的两倍。并发调度上核心问题是机器人资源怎么分配。举个例子你有20个流程买5个机器人那就要设计排队规则哪些流程优先级高、哪些可以等、一个流程超时了怎么处理。这些一定要在调度中心里配置好不要靠人工盯着。建议给每个流程设超时时间超时自动释放机器人资源否则一个卡死的流程会把整个队列堵住。还有一个容易被忽略的问题目标系统的承载能力。你有10个机器人同时登录同一个系统跑流程可能会把对方系统压垮或者触发它的并发限制。上线前一定跟目标系统的负责人沟通清楚并发上限不要自己闷头干。5.3 常见问题速查表现象常见原因排查动作解决方案找不到元素页面未加载完手动复现看元素何时出现换成显式等待加重试批量找不到元素目标系统改版检查页面结构是否变化更新定位规则加健康检查流程跑到一半卡住弹窗阻塞或超时未设看流程停在哪一步加弹窗处理分支设超时释放数据对不上类型转换或格式问题检查原始数据格式统一清洗转换关键字段做校验并发任务堆积机器人不足或任务超时看调度队列和超时设置增加机器人设优先级和超时只在某台机器失败环境差异比对分辨率、版本、缩放统一运行环境运行越来越慢内存未释放或日志堆积看运行时长和日志量分拆流程定期清理日志6. 成本、团队与人落地前必须算的三笔账6.1 授权模式与费用构成RPA的成本从来不是一张报价单能说清的。我把它拆成四块软件授权、实施服务、硬件与环境、人力维护。软件授权是明面上的钱但要注意计量方式。按机器人数量授权的话你要预估峰值并发数不是流程总数按运行时长计费的话要预估年度总运行小时数长流程的场景下这个数会很难看。实施服务通常按人天计费如果你有内部开发能力可以省下这块但前期摸索的时间成本也要算进去。硬件和环境上机器人跑在虚拟机里一台虚拟机跑几个机器人取决于流程的资源占用这块容易被漏算。人力维护是最容易被低估的——流程上线之后需要有人盯着报错、有人做变更、有人跟业务部门对齐需求这个人力的投入往往超过软件授权本身。我的经验是第一年的总投入里软件授权大概占三到五成剩下的都是围绕它发生的。做预算的时候把后面几块写清楚能避免后期被没想到还要花这个钱打乱节奏。6.2 RPA工程师的能力地图这两年RPA工程师这个岗位需求涨得很快我聊聊这个岗位到底需要什么能力也给正在考虑入行的人一个参照。第一层是工具熟练度。至少精通一家主流工具能独立完成网页自动化、Excel处理、文件操作、邮件发送这些常规流程。这一层通过两三个月的实操就能达到关键是别只看教程要真的做几个能跑起来的项目。第二层是业务理解能力。这是区分普通开发和优秀开发的分水岭。同一个流程理解业务的人会知道哪些环节容易出错、哪些数据需要校验、异常了应该怎么处理不理解业务的人只会照流程图拖组件一出意外就束手无策。这一层需要你深入到具体业务里去跟业务人员聊看他们平时怎么干活。第三层是工程化能力。包括流程的版本管理、异常处理框架设计、日志规范、公共组件的封装、跨流程的复用。这一层决定你能不能从做单个流程升级到维护一个流程体系。第四层是技术广度。会写脚本Python或者JavaScript、懂接口调用、了解数据库、能处理OCR、知道怎么对接大模型能力。有这一层的人能做的就不只是界面操作自动化而是真正的端到端流程自动化。我个人观察下来市场上最缺的是第二层和第三层都合格的人也就是既懂业务又能把流程做成体系的人。只会拖组件的人不少能把一个部门的流程梳理清楚并稳定运行的不多。如果你在考虑往这个方向发展建议尽早找一个真实业务场景扎进去做而不是反复刷教程。真实的业务场景会教你所有教程里不会写的东西。最后分享一个我自己用着挺顺的小习惯每做完一个流程我会额外花二十分钟写一份简短的流程说明包括它依赖哪些系统、哪些元素容易变、失败了怎么处理、找谁对接。这份说明平时看着没用等半年后流程报错、而你已经忘了当时怎么写的它就是救命的东西。RPA项目维护的痛点从来不是开发是半年后没人记得这个流程到底在干什么。
返回列表