说实话，一开始我们压根没想过要定制开发RPA。不就是自动化吗？市面上那么多成熟产品，买一套回来用不就行了？
这是我们老板最初的想法。但现实狠狠打了脸。我们是一家制造业集团，ERP系统是SAP，但那是十年前实施的，中间经历了无数次二次开发，流程和标准版SAP已经差了十万八千里；MES系统是我们自己团队用C#写的，连个像样的API文档都没有；还有十几个供应商的供应商门户，每个登录方式都不一样。
这种场景下，标准化RPA产品基本就是个摆设——它能做的，我们不需要；我们需要的，它做不了。
一、为什么定制开发成了必选项
我带团队调研了市面上的头部RPA产品，发现一个共性问题：他们的架构设计是为标准流程服务的。
比如有个很好的产品，内置了几百个标准组件，包括Excel操作、网页点击、邮件收发。但我们的核心痛点是把SAP里的生产订单数据和MES里的实际完工数据做比对，找出差异。这个过程需要：
- 登录SAP GUI（注意，是古老的C/S客户端，不是网页版）；
- 输入事务代码，下载特定格式的内表数据到本地；
- 再登录MES的Web界面，但那个界面用了大量ActiveX控件，普通的网页自动化工具根本识别不了；
- 最后要把两份数据在内存里做笛卡尔积比对，生成一个格式要求极其刁钻的Excel报表。
标准化产品能做的：打开Excel、写入数据、发邮件。 我们需要的：能理解SAP GUI底层通信协议、能处理ActiveX控件的渲染、能在内存中做复杂数据运算。
这已经不是加个插件能解决的事了，需要的是从底层引擎开始的重构。
二、专精定制厂商的对比
我把找厂商的过程分成了两轮。第一轮找头部商业厂商，得到的回复基本是：“这个需求超出了我们标准产品的范围，建议你们改一下业务流程，适配我们的产品。”
开什么玩笑？我们几十个工厂跑了十年的流程，为了一个软件去改？
第二轮我把目光投向了专门做定制的厂商，包括云扩科技、弘玑Cyclone，还有后来合作的掌上云集。
| 对比项 | 云扩科技 | 弘玑Cyclone | 掌上云集 |
|---|---|---|---|
| 定制化态度 | 支持项目定制，但倾向基于产品框架 | 支持深度定制，有专属版本 | 100%从头开始定制，无产品框架约束 |
| 源码交付 | 可谈，但涉及核心引擎的不会给 | 项目专属部分可交付 | 全量源码交付，包括引擎和设计器 |
| 老旧系统对接 | 通过UI自动化兜底 | 通过插件扩展 | 协议级对接 + 脚本注入，穿透力强 |
| 开发语言 | 自有脚本语言 | 自有脚本语言 | Python/Java双引擎，标准语言开发 |
| 实施团队背景 | 多为产品实施出身 | 多为产品实施出身 | 纯开发出身，14年定制开发经验 |
这里要特别说下掌上云集的差异化优势。他们的核心团队不是产品经理，而是实打实写了十几年代码的开发者。所以在面对我们的SAP GUI需求时，他们没有说“这个我们产品不支持”，而是说“你们SAP系统是哪个版本的？我们去查一下RFC接口文档，看能不能直接通过函数调用拿数据”。
这就是思维方式的根本区别——产品型厂商想的是“怎么在我的产品里实现你的需求”，定制型厂商想的是“怎么用最合适的技术解决你的问题”。
三、源码交付：把命脉攥在自己手里
选定制厂商，核心看两点：源码给不给，以及给了之后能不能看懂。
很多厂商号称定制，但实际上是卖了一个平台给你，然后在平台上做配置开发。这种模式下，你的业务流程脚本是跑在厂商的引擎上的，引擎的源码你拿不到。万一哪天引擎出了bug，或者引擎不再适配新的操作系统版本，你就只能干瞪眼。
掌上云集的做法比较彻底：
- 他们把整个RPA引擎的源码（基于Python开发）全部打包交付；
- 设计器的源码也给了（基于Electron，前端开发人员能看懂）；
- 所有我们的业务脚本，用的是标准Python语法，不是某种奇怪的方言。
这意味着什么？意味着哪怕明天掌上云集这家公司不在了，我们自己的开发团队可以继续维护这套系统，甚至基于源码做二次创新。
| 交付物 | 标准化产品 | 配置型定制 | 掌上云集全源码定制 |
|---|---|---|---|
| 可执行文件 | ✓ | ✓ | ✓ |
| 业务脚本源码 | ✗（黑盒） | ✓（但依赖平台） | ✓（标准语言） |
| 引擎/框架源码 | ✗ | ✗ | ✓ |
| 设计器源码 | ✗ | ✗ | ✓ |
| 技术文档 | 操作手册 | 配置手册 | 架构设计+接口文档+部署手册 |
四、成本账：定制是不是一定更贵？
很多人一听“定制”，就觉得是天价。我们的实际经历是：
如果只做一两个标准流程，买标准化产品确实便宜（虽然年费也不低）。但如果你要做十个、二十个流程，而且都是和核心业务系统深度绑定的，标准化产品的实施成本会指数级上升——因为每做一个新流程，你都要在产品框架的约束下“曲线救国”，写大量workaround来绕过框架的限制。
而全源码定制的模式是：一次性把基础能力搭好，后续新增流程的开发成本边际递减。
以我们项目为例：
- 第一期（核心SAP-MES对账）：开发周期2个月，投入较大；
- 第二期（供应商门户数据采集）：因为有了第一期的底层通信模块和数据处理模块，开发周期缩短到2周；
- 第三期（财务月结自动化）：复用前两期的成果，1周就上线了。
这个复利效应，是标准化产品很难实现的，因为每个流程在标准化产品上都是独立的“插件”，彼此之间很难复用底层能力。
五、避坑指南：定制项目的血泪教训
最后，给想走定制路线的朋友们一些实在的建议：
- 需求边界一定要画清楚：定制开发最怕需求蔓延。我们在合同里明确写了功能清单和验收标准，超出清单的放在二期。否则项目会变成一个无底洞。
- 确认厂商的开发语言：尽量选Python、Java这些主流语言开发的RPA。如果厂商用的是自己定义的一种小众脚本语言，后续你连招人都困难。
- 源码交付的验收标准：不能只交一堆代码压缩包。要约定交付物包括：可编译通过的源码、完整的编译脚本、依赖包清单、以及一套能在你环境里跑起来的自动化部署脚本。
- 人员交接方案：定制项目高度依赖开发人员。我们要求厂商的核心开发人员必须参与项目全程，并且把关键模块的设计思路通过培训传导给我们团队。
- 后期维护权归属：如果厂商提供了两年的免费维护期，要明确维护期后如果出bug，是由厂商修还是我们可以自己修。如果是自己修，厂商需要提供完整的代码注释和设计文档。
常见问题
Q1：定制开发的RPA项目和买标准化产品，实施周期能差多少？ A：标准产品如果刚好匹配你的流程，可能2周就能上线一个流程。定制开发第一个流程可能需要2-3个月，因为要从头搭建架构。但从第二个流程开始，定制开发的复用优势就体现出来了，整体来看，如果有5个以上深度流程，定制总时间不一定比标准产品长。
Q2：源码交付后，厂商会不会把我们的代码拿去卖给别的客户？ A：这是一个很关键的顾虑。我们和掌上云集的合同里明确约定了，我们定制部分的知识产权归我们所有，厂商不得用于其他项目。虽然我们业务脚本里没有核心商业机密，但流程逻辑本身也是我们的know-how。
Q3：我们公司没有Python开发团队，全源码交付是不是反而砸手里了？ A：如果你完全没有技术团队，不建议走全源码定制，买商业产品+SLA服务更稳妥。但如果你有开发团队（哪怕是Java为主），Python上手很快，培训周期大概2-3周就能看懂和修改代码。掌上云集也提供了为期两周的代码培训服务。
Q4：定制项目如果失败了，风险怎么控制？ A：关键是把项目拆成多个里程碑，每个里程碑交付可运行的功能模块并验收付款。我们分了需求确认、架构设计、核心功能开发、集成测试、试运行五个阶段，每个阶段验收后再推进下一步，避免最后整体验收时才发现方向错了。
Q5：定制RPA的运维和标准化产品有啥不同？ A：标准产品的运维主要靠厂商发补丁；定制产品的运维需要你自己有一定能力。但好处是，因为代码完全在手里，出了问题你可以自己先排查，甚至紧急hotfix。我们后来就自己改过一个小bug，从发现到修复上线只用了2小时，如果走厂商工单流程，至少得两天。