仙津 SRM · 系统内测与验收方案
本方案面向仙津采购部及仓库、品控、财务相关同事，用于本次为期五天的系统内测。内测在不接入 ERP、不打通飞书的条件下进行，目标是用仙津自己的物料、供应商和实际业务场景，验证系统是否满足日常使用要求，并形成书面验收结论。
安排上分为三个阶段：前三天集中体验并记录问题（采购主线两天，仓库、品控、财务一天），第四天由我方集中修复，第五天对照问题清单逐条复验。这样最终得到的结论不仅是"流程是否走得通"，还包括"提出的问题响应之后是否够用"。
下表对应仙津提出的 18 项业务场景（第 2–19 号），逐项说明本期内测可以验证到什么程度。「可完整验证」指该场景不依赖外部系统，本期具备验证条件；系统是否好用，正是这五天需要各位给出结论的。
其中 9 项场景为「可部分验证」——系统内部流程本期可以走通，仅外部接口部分需要留待第二期。这类场景不整体延后，本期先验证已具备的部分，接口部分单独归入第二期规划。
| 业务场景 | 系统已具备 | 本期内测 | 安排 |
|---|---|---|---|
| 2 供应商准入与线上申请 | 准入申请单与状态流转、准入分流策略、表单字段自定义配置、公司名称工商核验 | 可部分验证 工商信息自动带出目前接入的是多彩征信与贵州诚数两个数据源，可用查询次数有限，建议现场演示两至三次即可。天眼查、企查查的接入列入第二期 | Day 1 |
| 3 供应商资质与风险审查 | 风险数据源管理、风险巡检、风控矩阵、供应商舆情采集 | 本期暂不纳入 该场景依赖天眼查或企查查的司法数据，目前尚未接入；同时「合同纠纷 / 劳务纠纷」的案件分类能力仍在规划中。本期以演示现有风险模块为主，并请仙津确认数据源选型 | 第二期 B+D |
| 4 供应商绩效考核与实时预警 | 考核体系与权重自定义、实时监控、最小样本量控制、预警与月度自动定版 | 可完整验证 系统已可对全部在册供应商完成实时测算并产生预警。实时得分与正式月度得分在界面上是分开的 | Day 3 |
| 5 采购申请、询比价与招投标 | 寻源单、招标文件、澄清答疑、组合定标、中标通知书、询价行字段配置 | 可部分验证 Excel 导入需求、供应商在线报价、比价、生成中标通知书均可验证。从 ERP 直接拉取物料需求列入第二期，本期通过 Excel 导入完成 | Day 1 |
| 6 寻源公告与供应商门户首页 | 公告发布与富文本编辑、附件上传、报名台账、门户首页看板、物料选取 | 可完整验证 内测期间公告仅对本次指定的测试供应商可见，不会发送至其他供应商 | Day 2 |
| 7 历史价格查询与趋势分析 | 价格分析、图表配置、多维度筛选 | 可完整验证 功能本身可完整验证。目前系统内为示例数据，如需查询仙津自身历史价格，需先导入历史采购与询价数据，该项列入第二期数据准备 | Day 1 |
| 8 行情数据与 AI 分析 | 行情数据导入批次管理、AI 分析报告、采集端注册与任务派发 | 可部分验证 通过 Excel 或 CSV 导入行情数据、生成趋势图、AI 输出分析建议均可验证。卓创账号与政府网站自动抓取列入第二期 | Day 3 选验 |
| 9 合同模板、在线磋商与电子签 | 合同模板库、条款锁定与红线规则、磋商留痕、版本对比、归档 | 可部分验证 模板套用、条款锁定、磋商留痕、修改历史均可验证。签署环节本期采用「供应商线下盖章后上传 PDF」，与仙津反馈的供应商实际习惯一致；电子签平台对接列入第二期 | Day 2 |
| 10 到货计划、智能拆单与供应商协同 | 交付看板与日历视图、到货时段、配额协议、产能档案、供应商确认回写 | 可部分验证 看板、上午／下午时段、手动调整供应商与数量、供应商确认均可验证。ERP 物料运算结果导入与飞书群通知列入第二期，本期通知通过供应商门户送达 | Day 2 |
| 11 送货单、箱标、二维码与扫码收货 | 送货单与车辆信息、生产日期与保质期、箱标二维码、重复扫描校验、手机端收货 | 可完整验证 扫码直达收货页所需配置已完成，本期可完整走通 | Day 3 |
| 12 质检、入库与退货联动 | 来料检验、四种判定（含让步接收与复检）、检验模板、入库办理、退货冲减 | 可部分验证 检验、判定、入库、退货均可完整验证。与 ERP 的状态同步列入第二期，界面上会显示「未同步」，属本期预期状态 | Day 3 |
| 13 质量异常、整改、索赔与闭环 | 异常工作台、整改前后照片、8D 与 SCAR、升级台账、索赔关联订单与扣款 | 可完整验证 含「扣款自动进入对账扣减项」这一关键环节 | Day 3 |
| 14 对账单、盖章回传与结算 | 对账单、盖章件上传与审核驳回、发票、请款 | 可部分验证 对账单生成、供应商盖章回传、审核与驳回重传均可验证。从 ERP 获取对账单列入第二期，本期使用系统自行汇总的对账数据 | Day 3 |
| 15 汇联易费控付款与回传 | 请款单已具备；与汇联易的对接尚在规划中 | 本期暂不纳入 本期可验证至请款单生成。付款申请推送与付款结果回传需要汇联易的接口文档与测试环境，列入第二期 | 第二期 D |
| 16 库存风险与采购需求校验 | 库存风险中心、净需求测算、超采预警 | 可部分验证 净需求测算与超采提示的判断逻辑可完整验证（需求 10／库存 10／再采 10 应提示，需求 20 时不应提示）。库存数据的 ERP 实时同步列入第二期，本期使用手工录入的库存快照 | Day 2 |
| 17 品控原始记录 OCR 与质量前置分析 | 检验记录 OCR 识别与字段映射、识别失败的降级处理、检验单附件 | 可完整验证 拍照上传、自动识别、人工校正、指标趋势分析均已具备。仙津此前提出「若品控不接受该方式可暂缓」，本次安排品控同事现场试用后再决定是否纳入正式使用 | Day 3 |
| 18 品控异常沟通系统化 | 异常工作台与统计看板、外发台账 | 可部分验证 异常在系统内沉淀，以及按供应商、物料、状态的统计看板均可验证。飞书群消息卡片需待飞书打通后启用，列入第二期 | Day 3 |
| 19 项目管理与跨部门节点推动 | 采购项目、节点计划与负责人、超期提醒、项目档案归档、预算控制 | 可完整验证 功能已完整。该场景的主要使用方为需求部门与验收部门，建议另行安排半天时间邀请相关同事参与 | Day 3 选验 |
关于三天内覆盖 18 项场景的说明。按每天 8 小时计算，平均每项场景约 1.3 小时，而准入、询比价、到货协同等场景本身需要一至两小时，因此安排上有所侧重：
「可完整验证」的场景与采购日常主干流程优先安排；「可部分验证」的场景本期验证系统内部分，外部接口部分现场记录为对接需求；第 3、15 号场景本期以演示和需求确认为主，不计入缺陷统计——在数据源与接口就位之前进行测试，难以得到有效结论。
以下事项建议在 Day 1 开始前完成。前两天是采购同事集中体验的时间，如果用于建账号、导数据，采购主线的有效时间会明显缩短，而这部分反馈对本次验收最为关键。
前三天集中体验并记录问题，期间不做修改——边体验边调整会使最终难以判断某个问题是否已经解决，而这正是第五天需要回答的。采购为主线，安排前两天；仓库、品控、财务安排在第三天连贯进行。
仙津将该环节定位为 SRM 的首要入口，因此安排在第一项。
仙津反馈采购申请与下单在 ERP 中已基本可以完成，而询比价与招标尚无线上流程，因此本日时间主要安排在这一环节。
需要提前说明：系统内目前为示例历史数据。本日可以验证功能是否完整，但「查询结果是否准确反映仙津的历史采购情况」需要在导入历史数据之后才能判断。该项已列入第二期的数据准备。
一家供应商从准入申请完成到通过准入，其间经过一次退回并按问题项补充成功。
一张询价单从 Excel 导入至生成中标通知书，供应商完成在线报价，截止后无法修改。
记录单据编号：准入申请号、询价单号、中标通知号。后续三天将沿用这条业务链。
库存数据正常由 ERP 提供，本期先手工录入一份库存快照，验证判断逻辑：
以下三项需在本日完成，否则 Day 3 上午将用于补做前置，影响三个岗位的体验时间。
公告可在门户首页显示摘要并进入详情，供应商可完成报名或参与报价。
合同可基于模板生成，供应商无法修改锁定条款，磋商过程全程留痕。
超采提示两个方向均正确：应提示的已提示，不应提示的未误报。
送货单与箱标已打印完毕，Day 3 的前置条件齐备。
本日安排较为紧凑，六项场景连贯进行，使用的均为 Day 2 准备的同一批货物。建议三个岗位当日不分开——收货完成后直接交由品控，品控判定后直接交由仓库入库，中间不跨日，以便观察各环节之间的交接是否顺畅。
仙津此前提出，若品控同事不接受拍照识别的方式可以暂缓。该功能目前已具备，因此本次安排品控同事现场实际试用，再由品控判断是否纳入正式使用。
当日产生的收货、检验、异常与退货数据正好可用于绩效测算，因此安排在最后。
扫码收货、自动生成待检任务、检验判定、合格入库这一链路可一次走通，无需中间补录。
各项校验均按预期生效：不合格批次无法入库、重复箱标无法扫描、截止后报价无法修改。
异常扣款自动出现在对账扣减项中。
时间紧张时建议优先保证：扫码收货、四种判定、入库校验、扣款进入对账。绩效与 OCR 可调整至 Day 5 上午。
这一步建议留出约 40 分钟。三天累积的问题需要当场定级并确定修复范围，否则第四天容易演变为「优先处理容易修改的部分」，而第五天复验时清单上多数问题仍维持原状。
一天之内完成全部问题的修复通常并不现实。明确说明哪些暂不处理、原因及后续安排，比在有限时间内勉强完成更有助于双方判断。
圈定范围内的每一项均有明确状态：已修复并自测通过 / 已处理但未解决 / 评估后暂不处理。
系统运行正常，前三天产生的业务数据完整保留。
上午建议按清单逐条进行。新发现的问题记录在单独的表格中，不并入原清单——两者混合后将难以统计本轮的解决情况，而这正是安排第五天的目的。新问题纳入下一轮排期，不影响本次验收结论。
原清单中每一条均有明确结论。
全流程回归通过，各环节金额相互吻合。
形成书面验收结论与后续整改排期。
如仅有四天：可将 Day 2 下午的门户与看板巡览合并至 Day 1 收工前，Day 3 保持不变。修复与复验各占一天，建议不予压缩——省去修复日将回到边体验边调整的状态，省去复验日则无法确认修复效果，本次安排的意义也随之减弱。
建议每天收工前留出约 20 分钟，将当日问题当场定级。集中到最后一天再统一处理，容易遗漏，且现场细节的记忆也会淡化。
| 级别 | 判定标准 | 处理时限 |
|---|---|---|
| P0 阻断 | 流程无法继续，或金额计算有误。例如不合格批次可以入库、对账金额不符、审批人未收到单据。 | 当日给出结论，上线前必须完成 |
| P1 影响验收 | 流程可以走通，但方式不符合实际操作习惯，或缺少仙津业务必需的字段。例如检验项需每次手工填写、到货时段未能传递至仓库。 | 上线前完成，或提供明确的替代方案 |
| P2 体验优化 | 操作步骤偏多、文案表述、页面呈现等，不影响业务成立。 | 纳入排期，不阻塞上线 |
| 边界外 | 与 ERP、飞书、电子签、发票查验等外部系统相关的未联通项，属本期既定边界。 | 不计入缺陷，单独汇总为第二期对接需求 |
建议每条问题记录以下信息，其中单号与截图对后续复现与复验较为关键：
| 时间 | 岗位 | 页面 | 操作 | 预期结果 | 实际结果 | 单号 / 截图 |
|---|---|---|---|---|---|---|
| Day 3 10:20 | 收货员 | 手机端 · 扫码收货 | 扫描第 3 箱箱标 | 数量累计至 3 | 提示「已扫描」，数量仍为 2 | GR-2608-0117 截图 3 张 |
复验表在问题记录表的基础上增加两列，行数保持一致，以便统计本轮的解决情况：
| 编号 | 问题描述 | 级别 | Day 4 处理 | Day 5 复验结论 | 复验人 |
|---|---|---|---|---|---|
| #07 | 扫描第 3 箱提示「已扫描」，数量未累计 | P0 | 已修复 | 已修复 | 仓库 |
| #12 | 检验项需每次手工填写，未能带出上下限 | P1 | 本次不处理 需先确定检验标准 |
本次不处理 | 品控 |
一、流程完整。从请购到请款的单据链完整走通，中间无需依赖线下沟通、Excel 或口头传递补位。
二、校验有效。各项校验按预期生效——不合格批次无法入库、未经审批的单据无法下达、重复箱标无法扫描。相比「流程能否走通」，这一项更能反映系统是否具备实际管控能力。
三、响应及时。前三天提出的 P0 问题在第四天完成修复，并于第五天由提出问题的同事复验通过。这一项反映的是后续合作中的响应速度。
四、贴合实际。四个岗位的同事各自能够说明日常的操作路径，并认为相比现有方式更为便捷。这一项没有量化指标，但对系统能否真正投入使用最为关键。
以下为本期暂不纳入的部分。需要说明的是，其中多数并非整个场景延后——18 项场景中有 9 项为「可部分验证」，本期先验证系统内已具备的部分，仅将外部接口部分列入第二期。
分组依据为各项的前置条件：同一前置条件影响多个场景时，建议作为一项整体推进。
前置条件：ERP 接口文档、测试环境及对接联系人
这五项依赖同一套接口通道，建议作为一个整体一次性完成，可避免连接、鉴权、重试等基础工作重复投入。
前置条件：确定数据源选型、账号归属与费用，并取得接口凭据
关于场景 9：仙津此前反馈多数供应商不倾向使用电子签。建议在本期验证线下盖章回传的方式后，再评估电子签平台是否需要接入。
前置条件：协议签署及飞书应用授权
该组的前置条件为商务层面而非技术层面，协议签署并完成授权后即可启用。
前置条件：无外部依赖，但需要相应的开发周期
这两项是第二期中需要投入开发周期的部分。即使 B 组的数据源与汇联易接口文档较早到位，相应的开发工作仍需时间，建议第二期的整体排期以此为基准测算。
前置条件：仙津提供相应的历史数据导出
该组无需开发投入，建议在本期内测结束后即可启动，不必等待第二期整体开始。
前置条件：协调需求部门与验收部门的同事参与
该项无需开发或接口对接，安排半天时间进行专项走查即可。若本次在仙津的时间允许，也可一并安排。
关于第二期的推进顺序，建议按各组的前置条件难易安排：
E 组数据准备与 F 组专项走查可随时启动；C 组待协议签署后即可启用；A 组与 B 组取决于外部配合进度；D 组需要投入开发周期，是第二期整体工期的主要影响因素。
本次在仙津期间，除完成内测外，也希望能就 A 组的接口对接方式、B 组的数据源选型与账号安排、D 组的功能细节与各位进一步沟通，以便第二期能给出更准确的排期。