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