8.1 KiB
采购主链 RPA 一期需求简版说明
1. 这次要做什么
一期要做的不是单个机器人脚本，而是一套“采购主链自动执行 + 异常可协同 + 手机可处理”的小型流程系统。
覆盖范围只包含一条主链：
合同扫描件/合同系统 -> 返利中心采购协议 -> M5 采购订单 -> 收货通知单
核心目标：
- 能自动跑通的单据尽量自动跑完
- 不能确定的地方不让机器人乱猜，直接转人工
- 业务人员在手机上就能知道卡在哪、为什么卡、该怎么处理
- 每一单都能查到节点轨迹、截图、日志和责任人
2. 为什么要做
当前采购主链里，有几类工作重复度高、人工录入重、出错后又难追：
- 合同扫描件/合同信息需要人工录入
- 合同编号、承付模式、结算方式、货品等需要人工翻译到返利中心
- 返利中心录完后还要继续去 M5 做采购订单
- 遇到识别不准、模板报错、基础资料缺失时，只能靠人线下沟通和排查
一期方案要解决的，不只是“替人点页面”，更是把整条链做成：
- 业务看得见
- 异常有人接
- 手机能协同
- 后续能扩展
3. 一期怎么做
一期按下面的方式落地：
- RPA 执行平台：负责系统页面操作
- 轻量状态中心：负责流程状态、待办、日志、重试、规则和执行平台路由
- 本地 OCR：负责识别合同扫描件
- 企业微信应用：负责手机通知和处理入口
简单理解：
- RPA 执行平台像“执行手”
- 状态中心像“总控台”
- 企业微信像“手机协同入口”
这里要特别说明两层边界：
- 我们自己的能力：流程主控、规则配置、待办协同、日志证据、统一查询
- 底层工具能力：页面操作、文件上传下载、截图录屏、执行回调
也就是说，真正要沉淀在自己手里的不是某个 RPA 工具脚本，而是上层的流程和业务资产。
4. 业务流程怎么走
一期主链步骤如下：
- 采购或计划员把合同扫描件放进共享目录
- 状态中心建单并做基础判重
- OCR 识别合同字段
- 状态中心按规则做供应商、货品、结算方式、承付模式映射
- 合同系统信息补齐，并以“已审核/审核通过”为继续前提
- 机器人进入返利中心，检索采购协议并录入总单
- 机器人生成并导入返利中心细单模板
- 机器人进入 M5，创建采购订单
- 机器人完成保存并生成收货通知单
- 状态中心归档并保留完整轨迹
4.1 多 RPA 切换边界
一期方案支持“底层执行平台可替换”，但这个边界要先定清楚：
- 可切换的是底层执行平台，比如影刀、艺赛旗等
- 不可切换的是上层状态中心、企业微信协同、规则配置和验收口径
- 支持按“新单”切换平台
- 也支持按“节点配置”决定由哪个平台执行
- 不做“一个节点执行到一半临时换平台”
- 新平台接入前，必须先做 POC 验证
这么设计的目的，是避免未来被单一厂商绑定。
5. 手机端能做什么
业务人员在企业微信里至少能做这些事：
- 看当前这单跑到哪一步
- 看失败原因或待确认原因
- 看关键字段摘要和错误截图
- 补录或修正允许修改的字段
- 确认后继续
- 重试当前节点
- 转人工处理
- 终止本单
而且不是冷冰冰给一条待办，而是尽量做到：
- 让业务一眼看懂“这单卡在哪、为什么找你”
- 让业务直接看到关键字段和最近错误截图
- 让业务知道改之前是什么、改之后会变成什么
- 让业务提交后马上知道“系统已经接单了”
这里的重点不是“人人都能改所有东西”，而是：
- 计划员处理 OCR/合同编号/承付模式这类问题
- 采购处理返利中心录入和模板问题
- 质管处理基础资料维护问题
- 运维处理机器人登录、页面变化、系统异常问题
6. 一期的关键原则
-
机器人只负责执行，不负责拍脑袋判断
识别不准、映射不稳时，直接转人工，不允许“猜着填”。 -
所有状态都进状态中心
不把主状态留在某个 RPA 工具脚本里，避免后面没人知道这单停在哪。 -
手机待办按角色路由，不按个人写死
这样有人请假、换人、轮班时更好处理。 -
任何失败都要能追到证据
包括节点、错误码、错误摘要、截图、日志和责任角色。 -
成功必须以“业务结果生成”为准
不是页面点完就算成功，而是要拿到返利中心单号、M5 订单号、收货通知单号等结果。 -
上层能力归自己，下层执行器可替换
不把状态、规则、待办、留痕长在某个 RPA 平台内部。
7. 一期带来的直接价值
对业务：
- 减少重复录入和跨系统搬运
- 出问题时不用到处问人，手机上就能看到卡点和原因
- 计划员、采购、质管之间的责任更清楚
- 不需要先学很多系统术语，待办本身就能告诉你现在该做什么
- 提交后不容易反复点击、反复确认，手机端使用更安心
对管理：
- 每单可追踪
- 哪类问题最多、卡在哪个节点更容易看清
- 后续做统计和优化会更容易
- 平台更换时不影响业务使用习惯，推广阻力更小
对技术：
- 一期先做成小中台，后面二期三期可以继续接订单中心、招采子系统
- 不把流程逻辑绑死在单个机器人脚本里
- 当影刀、艺赛旗或其他平台的成本、授权、稳定性变化时，可以平滑替换底层执行器
8. 一期明确包含什么
包含：
- 共享目录入池
- OCR 识别
- 映射规则管理
- 合同系统前置确认
- 返利中心采购协议录入
- 返利中心细单模板导入
- M5 采购订单创建
- 收货通知单生成
- 企业微信通知和手机处理入口
- 待办“人话状态”“错误翻译”“修改前后对比”“即时回执”等体验设计
- 状态查询、日志、截图、待办留痕
- 多 RPA 执行平台的可切换设计
9. 一期明确不包含什么
以下内容不纳入一期：
- 订单中心分货与销售订单联动
- 招采子系统医院计划抓取
- 发货后一票/二票自动上传
- 渠道价管理与维护
- 邮件自动收件作为主入口
- 复杂 BI 看板
这些内容如果后续要做，建议单独立项，作为二期或三期推进。
10. 上线前必须先确认的前置条件
- 企业微信正式应用能申请下来
- 企业微信支持消息、H5 入口、身份识别和回调
- 共享目录位置和权限已定
- 合同扫描件的命名规范已定
- 一期主执行平台的运行环境和账号已准备
- 返利中心、M5、合同系统的测试账号已准备
- 承付模式、结算方式、供应商、货品等映射表已准备
- 合同系统“送审/审核通过”的业务规则已确认
- 选定的一期主执行平台已完成 POC 验证
11. 一期验收怎么判断
达到下面几点，就说明一期做成了：
- 业务能在手机端知道每单当前跑到哪一步
- 关键不确定项不会被机器人自动猜测
- 任何失败都能定位到具体节点、原因、截图和责任角色
- 一份合同从入池到 M5 完成的轨迹可完整追溯
- 同一合同不会因为重复上传或重复点击而形成重复业务结果
- 能明确拿到返利中心单号、M5 订单号、收货通知单号等结果
12. 建议推进方式
建议按下面顺序推进：
- 先确认一期边界和前置条件
- 再确认节点定义、角色路由和人工处理边界
- 再开始状态中心、RPA 执行平台、企业微信并行开发
- 最后做端到端联调和试运行
如果要给业务和领导一句话总结，这个项目可以这样讲：
“我们不是单做一个 RPA 机器人，而是在采购主链先搭一个轻量自动化中台，让合同到返利中心再到 M5 的流程尽量自动跑通，异常时能第一时间在企业微信手机端协同处理，并把整单过程完整留痕，同时让底层 RPA 执行工具保持可替换。”