值得做，而且应该在做。ERP 开发前用可点击原型把关键流程走一遍，通常能把后期返工压下来一大半。原型不用连数据库、不用写权限，只要能让人指着屏幕说"这里不对"，它的价值就已经兑现了。

为什么顺序不能反过来

ERP 项目的成本结构是这样的：改一个字段，在原型阶段是十分钟；在开发阶段是半天；在上线后是数据清洗加补丁加重新培训。越往后，同一个错误的修复成本越高。

但很多项目偏偏反过来走：先签需求、再排期开发、最后演示。等到客户第一次看到系统，已经过去几周，此时任何一句"这个流程我们不是这样的"，都要动已经写好的表结构和接口。

所以原型的作用不是"给客户看效果"，而是在便宜的地方犯错。它要准确，不要精致。

原型要验证的四件事

一、单据和字段够不够用

把每类单据的真实样张拿过来，照着填一遍。重点看三处：哪些字段是必填的、哪些字段其实没人填、哪些信息现在写在备注里。

第三种最常见。备注栏是业务人员的自救方式，里面藏着没被建模的需求。原型阶段把备注拆成字段，比上线后加字段省事得多。

二、审批链和权限边界

审批不是画一条线那么简单，要问清楚：金额分档吗？代理人是谁？驳回后回到哪一步？谁能改已提交的单据？

权限同理。同一个"仓库主管"，在入库、出库、盘点三个场景下的可见范围往往不一样。原型里用几个假账号切换一下，这些差异会立刻暴露。

三、例外分支

正常流程只占实际工作量的一小部分，例外才是 ERP 的难点：客户临时改单、批次不合格、跨月冲销、供应商开票金额对不上。

讨论时直接问一句："这个流程有没有不走寻常路的时候？"当场把例外路径画出来。问不出来也没关系，把"例外如何处理"记为待定项，比假装它不存在要好。

四、报表口径

很多 ERP 争议不在功能，在数字对不上。同样是"本月销售额"，财务按开票算，销售按发货算，仓库按出库算，三个数字都"对"，但开会时必然吵。

原型阶段就把核心报表的取数口径写在旁边，哪怕只是一行注释。这一行注释能省掉上线后的大量对账工作。

原型做到什么程度算够

判断标准很简单：业务方能独立走完三个高频场景，不需要你在旁边解释。

通常的做法是用低保真线框图或可点击的页面草图，覆盖三到五个核心流程，比如采购到入库、销售到回款、生产领料到完工。不做视觉设计，不做动效，不做移动端适配。

时间上，一个中等复杂度的 ERP，原型阶段通常按周计，取决于流程数量和决策效率，以实际评估为准。

原型确认后要留一份书面记录：每个页面旁边的批注、确认人和确认日期。它不是形式主义——开发阶段出现分歧时，这是唯一能回溯的依据。

原型验证不了的边界

必须说清楚，原型不是万能的：

  • 验证不了性能。几万条数据下的列表响应、并发提交、报表查询耗时，只有真实数据能暴露。
  • 验证不了数据质量。历史数据里的重复客户、缺失编码、单位不统一，原型阶段看不见，迁移时才炸。
  • 验证不了集成难度。跟现有财务软件、电商平台、硬件的对接，取决于对方接口的开放程度，画图看不出来。
  • 验证不了使用意愿。业务方在会议室点头，不代表仓库的师傅愿意扫码。

这四项要靠技术预研、数据抽样和试点来覆盖，原型只负责流程逻辑这一层。所以合理的节奏是：原型定流程，预研定风险，然后才进入正式开发。

把原型变成开发任务

原型确认后，别急着开工。先做一次拆解：把每个确认过的页面转成数据表、接口和页面三类任务，标出依赖关系，再估工作量。

这一步做扎实，排期才有依据。整体开发流程和模块划分可参考 ERP 系统开发；如果流程里有大量移动端操作，比如外勤、巡检、扫码，那部分通常要单独设计，可看 APP 开发 的思路。如果还在犹豫该用现成产品还是定制，AI 能不能直接生成 ERP 讲了自动化的实际边界，可以对照判断。

常见问题

原型要用什么工具做

不限。纸笔、线框图工具、甚至直接在表格里画页面都可以。选型标准只有一个：改起来够快。

原型要不要给业务人员试用

要，并且给他们"挑错"的任务，而不是"看看行不行"。人对开放式问题容易客气，对具体任务会较真。

原型确认后还能改吗

能，但要区分两类：补充细节可以随时进行；改动主流程要走变更评估，因为主流程一动，表结构和接口往往要跟着动。把这条规则提前讲清楚，比事后争执好。

原型阶段要不要报价和排期

可以给区间，不宜给精确数字。原型没确认前需求边界还在变，精确报价对双方都不负责任。常见做法是先做原型，再基于确认范围出方案。

---

如果你正在准备 ERP 项目，不确定自己的流程该拆成几个模块、原型要做到哪一步，可以加微信 nsail543 聊聊，把现在的流程说一遍，通常能判断出哪些地方值得先验证。