243 lines
8.1 KiB
Markdown
243 lines
8.1 KiB
Markdown
# 采购主链 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 执行工具保持可替换。”
|