一、POC 与产品演示的区别：三个必须用自己数据的验证域
产品演示回答的是「这个系统能不能做某件事」，POC 回答的是「这个系统在我这里能不能做成某件事」。两者的差别看似只是数据来源，实际差在三个地方：一是数据脏不脏，真实数据里一定有重复的供应商、缺失的辅助核算项、格式不统一的部门名称；二是流程绕不绕，真实流程一定有例外分支、跨部门流转和回头修改；三是量级大不大，真实业务的数据量会把所有取巧的实现方式暴露出来。
因此 POC 的第一个动作不是发排期表，而是准备数据。至少要准备三份：一份是干净但真实的业务数据，用于跑通主流程；一份是故意做脏的数据，用于测试校验能力；一份是全量或接近全量的历史数据，用于测试性能与迁移。这三份数据都必须由买方提供，不接受厂商代为生成。
需要提醒的是，POC 数据本身也是需要脱敏管理的。真实单据里有员工姓名、证件信息、银行账号与供应商价格。数据交付前应当做打散处理，保留格式与逻辑关系但替换主体信息，同时签署保密约定并约定测试结束后的销毁方式。这件事在 POC 开始之前就要办，而不是等发现问题再补。
二、必测的十个场景
下面十个场景覆盖了财务系统在企业侧最容易出问题的环节。它们不追求功能广度，而是刻意选择那些「演示看不出来、上线必踩坑」的点。每个场景都要求现场在买方环境中操作，不接受播放录屏。
| 序号 | 测试场景 | 关键动作 | 通过判据 |
|---|---|---|---|
| 1 | 真实单据全流程 | 用买方自己的一批真实单据，从提单、审批、支付到生成凭证走完整链路 | 全链路无人工干预补齐，凭证的科目、税额、辅助核算项全部符合买方既定的映射规则 |
| 2 | 脏数据校验 | 导入含重复供应商名称、格式不统一部门名、缺失必填维度的数据 | 系统能准确指出问题行与问题字段，而不是直接入库或整体报错 |
| 3 | 批量导入与回滚 | 按实际年度单据量分批导入，中途制造一条错误数据 | 错误可定位到行与字段，支持整批回滚而不留残数据，重跑不产生重复记录 |
| 4 | 审批链路的例外分支 | 测试会签与或签、条件路由、加签、退回后重新提交、审批人离职后的单据移交 | 各分支行为与买方制度一致，退回与重提在原单上留痕而不是新建单据 |
| 5 | 权限边界 | 用普通用户、部门负责人、财务、系统管理员四类账号尝试越权访问与越权操作 | 数据可见范围与操作权限均受控，越权尝试被拦截并记录 |
| 6 | 已记账数据保护 | 尝试删除已记账凭证、插号、修改已记账凭证的金额与科目 | 系统不提供删除与插入能力，连续编号不可打断，关键要素不可修改 |
| 7 | 操作日志还原 | 抽取一笔被多次修改的单据，从日志中还原完整修改历史 | 可按操作人员、操作时间、操作内容检索，能还原每一次改动的字段与前后值 |
| 8 | 数据导出完整性 | 导出全量凭证、明细账、往来余额、附件清单与结构化的入账信息文件 | 导出内容完整可用，格式可直接被通用工具打开，不依赖厂商专用程序 |
| 9 | 性能与月结批处理 | 用接近真实的数据量做并发操作测试，并在测试环境执行一次完整的月结与报表取数 | 并发响应时间在约定范围内，月结批处理耗时满足结账窗口要求，且不影响在线操作 |
| 10 | 异常恢复 | 模拟应用进程中断、数据库连接断开、导入过程中断网 | 可从中断点继续或安全回退，数据不丢不乱，无需人工修数 |
十个场景里，第 6 项和第 7 项最容易被跳过，因为厂商通常会以「这些我们都符合规范」为由略过演示。但这两项恰恰是选型后期的争议焦点，也是合规检查的直接落点，必须在 POC 阶段拿到实际界面截图或操作记录作为证据。
三、评分表怎么设计：把主观印象变成可复核的判断
POC 之后最容易出现的场面是各家都说自己表现不错，因为评价标准是模糊的。解决办法是在 POC 开始之前就把评分表定下来，并且给每个维度规定证据要求——拿不出证据的项不得分。
| 评价维度 | 建议权重 | 评分要点 | 必须提供的证据 |
|---|---|---|---|
| 功能匹配度 | 25% | 十个必测场景的通过比例，未通过项是否有可接受的替代方案与实现时间 | 现场操作记录与截图，逐场景标注通过与不通过 |
| 数据迁移可行性 | 15% | 历史数据能否完整迁移、脏数据清洗规则是否清晰、迁移后的勾稽关系是否保持 | 用真实历史数据跑出的迁移结果与勾稽核对报告 |
| 合规与留痕 | 15% | 已记账数据保护、操作日志、导出权属、电子档案能力是否符合规范要求 | 条款逐条对照说明与实际功能界面 |
| 集成与开放性 | 15% | 接口文档完整度、是否提供测试环境、限流策略、与现有系统的对接可行性 | 接口清单与沙箱测试结果 |
| 性能与稳定性 | 10% | 并发响应、批处理耗时、异常恢复能力 | 用买方数据量执行的压测与恢复演练记录 |
| 本地部署与运维 | 10% | 部署形态、升级方式、回滚机制、原厂支持响应 | 部署方案说明书与升级回滚预案 |
| 服务与实施能力 | 10% | 实施团队是否自有、顾问的经验与稳定性、问题响应机制 | 拟投入人员的名单、资历与投入比例承诺 |
权重不必照抄，但有两个原则值得坚持。一是把「数据迁移」和「合规与留痕」的权重提上来，这两项是本地部署项目上线失败与后期返工的主要来源，而在演示阶段又几乎看不出差别。二是所有扣分项都要写明扣分理由与后续验证方式，避免出现「总体感觉一般」这种无法复核的判断。
四、三类演示陷阱与对应的设防动作
- 数据预置陷阱：演示环境里的数据是专门为演示准备好的，格式统一、无重复、无缺失，任何校验规则都显得多余。设防动作是坚持用买方提供的脏数据现场导入，观察系统报错与提示的具体程度
- 顺流程陷阱：演示只走成功路径，不展示退回、撤销、跨部门加签、审批人休假等例外。设防动作是在测试脚本里预先写死三个异常分支，要求现场逐个演示
- 环境差异陷阱：演示在厂商优化过的环境上进行，性能与真实部署环境差别很大。设防动作是要求在与最终部署形态一致的环境（含相同的部署模式与配置）中执行性能测试，并把环境配置写进会议纪要
- 能力边界模糊陷阱：对做不到的能力用「可以二次开发实现」「后续版本会支持」带过。设防动作是要求把承诺写成带时间和验收标准的书面条款，未写明的默认不计分
五、把合规条款直接变成验证用例
合规要求如果只写在需求书里，很容易变成一堆表态性文字；把它转成 POC 用例，就变成了可以在测试现场逐条打勾的清单。《会计软件基本功能和服务规范》（财会〔2024〕12 号，2025 年 1 月 1 日施行）中的若干条款，天然适合作为这类用例，因为它们描述的都是可以当场验证的系统行为。
| 规范要求（条款要点） | 对应的 POC 验证用例 | 判定标准 |
|---|---|---|
| 软件应具备结构开放性与标准数据接口（第七条） | 要求厂商提供接口清单与数据结构说明，并在测试环境用买方自研脚本读取一次业务数据 | 买方无需厂商协助即可完成数据读取，接口文档与实际行为一致 |
| 应支持网络报文传输、文件导入、手工录入等输入方式，并对输入数据进行校验（第十五条） | 分别用三种方式向系统输入同一批数据，并混入错误格式的数据 | 三种入口的行为一致，错误数据被拦截并给出可定位的提示 |
| 应实现与业务软件的一体化，业务处理直接驱动会计处理（第十六条） | 从采购或报销单据出发，验证是否自动生成对应凭证与台账，中间是否需要人工搬运 | 链路无人工搬运环节，或人工环节仅限审批与审核，不涉及数据重录 |
| 对已记账凭证不得提供删除和插入，连续编号，且不得修改日期、币种、汇率、金额、科目、操作人等要素（第二十一条） | 现场尝试删除一笔已记账凭证、在编号中间插入一张凭证、修改一张已记账凭证的金额与科目 | 三类操作均无法完成，编号连续；如需更正只能通过冲红或补充登记实现 |
| 应提供用户操作日志，可按操作人员、操作时间、操作内容进行查询（第三十二条） | 用三个条件各自检索一次，并抽取一笔单据还原完整修改链 | 三类检索均可用，修改链能还原到字段级 |
| 会计数据归用户所有，软件服务商不得拒绝用户导出数据（第四十一条） | 在 POC 结束前执行一次全量导出，并尝试在无厂商工具的机器上打开 | 导出文件完整可用，格式通用，不依赖厂商专用程序 |
把这张表打印出来带进 POC 现场，比带一份几十页的功能需求表更有效。它的好处是把讨论从「你们支不支持」变成「现在这台机器上能不能做出来」，无法含糊。
六、POC 的组织方式与结论输出
组织上有三件事决定了 POC 的有效性。第一，买方必须有人全程在线并动手操作，全过程由厂商单方面演示的 POC 等于没有做；关键操作要让买方的人员亲手完成，厂商只解释不代做。第二，每一场测试都要有记录，记录应包含操作步骤、实际结果、截图或录屏、以及双方对结果的确认，会后当天发出，避免事后各说各话。第三，参与测试的人员要覆盖财务业务、信息化和后期运维三类角色，只有财务参与的 POC 会漏掉架构与运维风险。
结论的写法上，建议不要只给一个总分排名，而是给出一份「通过项、条件通过项、未通过项」三段式清单。条件通过项要写清条件是什么、由谁在什么时间提供什么证据；未通过项要写清影响范围以及是否有替代实现路径。这样形成的结论可以直接作为合同附件的技术验收依据，也避免了上线后才发现某些 POC 承诺未被写进合同。
最后一点经验：POC 的时间不宜过短也不宜过长。三到五天往往只能跑通顺流程，两三周又容易变成免费实施。比较合适的长度是两周左右，其中数据处理与准备一周、现场测试三到五天、结论整理两到三天。真正的判断依据不是花了多少天，而是有没有用买方的脏数据、有没有覆盖异常分支、有没有留下可复核的证据。
资料来源：《会计软件基本功能和服务规范》（财会〔2024〕12 号，财政部 2024 年 7 月 29 日印发，2025 年 1 月 1 日施行）第七条、第十五条、第十六条、第二十一条、第三十二条、第四十一条；《会计信息化工作规范》（财会〔2024〕11 号，2025 年 1 月 1 日施行）。文中评分权重与测试场景为实务建议，企业应结合自身组织规模与业务复杂度调整。