一说要做产业数字平台，采购、订单、库存、配送、结算、报表，都能列出一串功能。
清单列完，还要继续回答：第一期先解决哪个问题，哪些人真正会用，一笔业务怎样走完，出了差错找谁，最后拿什么判断做到了。
我觉得，可以先选一段真实业务，把它做成一个范围清楚、能够运行、有人接管的工作系统，再往外扩。
这一期可以只覆盖一类业务、少量参与方，但从发起到交付、异常处理和对账，要能找到前后的关系。哪些已经由系统支持，哪些暂时由人处理，也要讲明白。
建设按阶段推进，系统能力与经营效果分别验收。 下面给一套可以按具体业务调整的参考安排。
一、先找业务问题，再确定第一期的范围
平台建设的起点，可以是一个反复发生的问题。
例如，供需双方使用的规格不一致，订单确认要来回打电话，交付记录与对账记录对不上。把这些情况展开，才能知道需要改动哪个环节，涉及哪些角色，以及平台能够承担什么。
问题先说具体。谁发起业务，谁确认供给，谁完成交付，谁核对结果；各环节收到什么、交出什么，中间还需要等谁的确认。
这些关系清楚以后，再确定第一期做哪些功能。
这里说的“最小范围”，是选出一段能够独立检查的完整业务。可以暂时不接入所有品类、不覆盖所有地区，也可以保留已经有效的人工处理办法。
但这段业务里，正常怎么走、变更怎么处理、谁有权确认、结果怎样核对，都应当有去处。否则，页面虽然做出来了，实际工作仍然要靠人到处补接。
范围单还要写清本期不做什么。其他需求先登记，说明以后为什么可能需要，不让每一次讨论都直接变成新增任务。
试点前留下现状记录也很有用。原来确认一笔业务要经过哪些动作，容易在哪一步出错，谁承担了额外协调，后面才有可以比较的依据。
二、让业务状态、参与角色和记录对应起来
以一条普通履约业务为例，可以先看四个环节：需求发起、供给确认、履约交付、对账确认。
每个环节都要能回答三个问题：谁来做，依据什么做，完成后留下什么。
需求提出了，并不表示供给方已经承诺；交付发生了，也还要核对签收、差异和结算条件。平台需要把这些状态分开，让使用的人知道现在进行到哪里。
相关记录可以通过业务编号建立关联。一个需求拆成几笔订单，一笔订单分批交付，几笔业务合并对账，都要保留各自的记录和对应关系。
我不建议用一个笼统的“已完成”，把这些不同事项全部盖过去。交付、对账、应收、实际收款，可以分别核对，不能只看界面上有没有一个绿色标记。
同时，要明确资料由谁维护。规格、单位、可供条件、交付时间等内容变了，谁确认新版本，哪些未完成业务受到影响，使用的人怎样知道。
信息能够传过来，还要有人负责它的含义、来源和适用范围。
图1是通用参考架构。不同单据通过业务关系关联，部分交付、变更与争议需要单独处理，不强求一笔订单对应一笔交付或回款。
三、权限、异常和核对，放进第一期一起做
一段流程能在演示中走通，还需要继续看谁在使用、会出现哪些变化。
同一个人能看资料，不一定就有权确认订单；可以录入，也不表示可以替另一方修改结果。查看、录入、确认、修改、导出这些动作，需要按实际分工分别安排。
只接入有权使用、又确实为这段业务所需的资料。数据从哪里来，什么情况下更新，发生错误怎样更正，都应当有负责人。更正后的结果和原来的依据要能分清。
异常也一起设计。需求变了、供给不足、只交付了一部分、收到的数量有差异、对账意见不一致，这些情况应该进入什么状态，由谁接手。
如果所有差错都只能由开发人员在后台改数据，一线很难知道实际发生了什么，后面的核对也会失去依据。
比较合适的做法，是给常见异常留出处理入口。先登记事实，指定负责的人，保留处理和确认记录，再回到相应业务环节。无法处理的事项保持待处理状态，不为了让流程结束而强行确认。
还可以顺手检查几种容易遗漏的情况：同一笔交付重复提交，会不会多记一次；一方撤回或更正，其他环节能不能看出变化；人员离开原岗位，旧权限有没有跟着调整。
这些事情与这段业务能否可靠运行直接有关，适合进入第一期的验收，而不是一直留到“以后完善”。
四、按四个阶段推进，每一步都有进入下一步的依据
第一阶段：把问题和验收范围定下来
先确定要解决什么、这一期做到哪里、哪些角色参与、现状怎样，以及系统和业务分别检查什么。
建设范围、必要记录、权限、主要异常、负责人和资源安排，都可以放在同一份清单里确认。
这一阶段的交付，应当让业务方和建设方能指着同一张流程图说清楚：从哪里开始，到哪里结束，哪些动作由人确认，哪些由系统处理。
第二阶段：把限定流程做完整
先在受控环境里检查正常业务和主要异常。每一步能否执行，谁能作出确认，数据有没有对应依据，错误能否发现和修正，都要实际走一遍。
发现问题后，记录具体发生了什么、影响哪一步、由谁修改，再回来核对。不能只把功能清单逐项打勾。
这一阶段允许有明确边界的人工环节，但要说明由谁接手、怎样留痕、以后是否需要调整。涉及关键业务的缺口没有解决，就先不进入相应范围的真实使用。
第三阶段：在已确认的范围内试运行
系统检查通过后，再接入限定的真实业务和参与者。
把日常支持、问题响应、资料核对和故障时的替代办法安排好。切换过程中，哪一份是主要业务记录，差异怎样处理，也要说清楚。
如果确实需要短期并行核对，就约好目的、负责的人和结束条件。不要长期要求一线把同一笔业务完整录两遍，却把增加的工作量排除在成本之外。
真实运行中，分别收集系统表现和业务变化。能记录、能确认，是一类结果；有没有减少返工、缩短等待、改善对账，是另一类结果。
如果关键权限、记录或履约问题使相关业务无法按已确认的条件处理，就先暂停相应新增操作，按约定的替代办法继续处理必要业务。把差异核清、相关场景补验，并经有权负责人确认后，再恢复。
第四阶段：稳定接管，再评审扩展
这一段业务稳定以后，要有人正式接管日常运行。
业务规则谁维护，人员和权限谁调整，问题由谁响应，费用怎样安排，资料怎样导出、保留和恢复，都应当有实际负责的人和可用说明。
交接也要试一下。接管人员能不能完成一笔业务，能不能处理主要异常；出现故障时，能不能找到替代办法；备份出来的资料是否真的能够恢复和核对。
接管清楚以后，再讨论增加品类、参与节点或区域。新范围带来的业务量、资料差异、支持成本和责任变化，需要重新评审。
图2按交付和验收条件组织阶段，不把日期到来或功能上线当作自动进入下一阶段的依据。系统通过、经营效果待观察，可以分别记录状态。
五、系统验收和经营验收，各回答自己的问题
我觉得，平台验收中最需要分清的，就是系统做到了什么，以及业务因此发生了什么。
| 验收方面 | 主要核对什么 | 可以留下什么依据 |
|---|---|---|
| 系统能力 | 流程能否执行，权限是否正确，记录能否追溯，异常和故障是否有处理办法 | 正常与异常操作记录、权限检查、核对及恢复验证记录 |
| 经营效果 | 真实业务是否有人使用，交付和对账是否改善，返工、等待、成本和负担怎样变化 | 前后业务记录、参与者反馈、投入与问题处理记录 |
两类结论不必被迫写成同一个“通过”。
系统能够支持限定流程，但观察周期还不够，经营效果就继续标为待观察。在系统与业务责任已经满足约定条件的前提下，可以保留限定范围使用，暂时不扩大。
反过来，某段时间业务看起来变好了，仍然需要处理系统中重要的权限、数据或异常问题。可能是大家额外投入了大量协调，也可能同时发生了其他变化，不能用一个好结果把这些问题带过去。
经营比较要讲清口径。看的是哪些业务、什么期间、什么情况算返工，额外的人时和费用怎样记录，前后尽量采用相同的定义。
业务量、订单难度、供货条件和价格变化，也可能影响结果。记录这些变化，是为了让判断更有依据，不是要求一次小范围使用就证明所有因果关系。
验收以后，结论可以很具体：哪一段已经能用，哪些问题仍然存在，谁来处理，什么结果还不能确认，下一次什么时候回来核对。
六、用一个工业耗材的例子，看清建设顺序
下面是专门编写的虚构情境，不对应真实企业或已经取得的建设成果。
几家生产企业希望和供应、配送伙伴一起，改善常用工业耗材的询价、交付和对账。
第一期可以先限定一类标准耗材、一组参与方和一条履约链，不急着把全部采购与管理业务一起接入。
先把需求规格、计量单位和交付条件说明白。供给方确认以后形成相应业务记录，配送和签收关联到这笔业务；部分到货、数量差异和对账意见分别保留状态。
| 阶段 | 本例可以先交付什么 | 怎样检查 |
|---|---|---|
| 明确范围 | 一条从需求到对账的流程、角色和验收说明 | 各方能否说清责任、输入输出和本期边界 |
| 完成流程 | 正常下单、供给确认、部分交付和差异处理 | 能否按角色操作，相关数量与记录能否核对 |
| 受控试运行 | 限定业务、问题支持和替代处理办法 | 谁在真实使用，是否增加重复劳动，问题怎样闭合 |
| 接管与扩展 | 日常责任、维护安排及下一范围的评审材料 | 接管者能否独立运行，新范围是否有资源和依据 |
如果发现规格确认更清楚了，但对账仍要人工重新汇总，就先追到这个具体环节。是记录没有关联，口径不一致，还是职责没有明确，再据此修改。
如果第一组参与方能够正常使用，换一组以后却需要大量额外支持，也说明原来的使用条件还需要整理。把这些差异看清，再决定继续限定范围、调整后补验，或者暂缓扩大。
这个例子里，功能建设、真实使用、日常接管和经营改善，始终是相互连接又分别检查的事情。
七、扩展之前，再把成本和责任问一遍
平台后面可以做的事情通常很多，但每增加一个范围，都可能增加资料维护、培训、支持和异常处理的工作。
因此，扩展评审里要算上持续使用的成本。软件建设费用、资料整理、岗位培训、日常支持、流程调整和后续维护，各由谁承担。涉及场地、设备和履约的投入，也要按实际用途分开，不都装进软件研发预算。
已有系统能够提供的能力，可以先核清楚；缺什么，再决定怎样补。这里不预设必须更换某套软件，也不规定所有产业都使用同一种技术方案。
同样，功能多、接入节点多、记录数量大，还需要放回真实业务中检查。它们是否帮助各方把事做得更清楚、更可靠，才关系到继续投入的依据。
正式进入下一阶段前，我建议再问五个问题：
- 这一期究竟把哪一段业务接清楚了？
- 正常和异常情况，是否都有人负责、都有记录可核对？
- 系统能力与经营效果，分别确认到了什么程度？
- 日常运行、故障处理和资料维护，谁已经接得住？
- 增加下一范围，需要补什么资源、责任和授权？
回答清楚，再往前走。还没有依据的部分，先留在待核对和待验证的位置。
平台可以一段一段建设。每一段都能交付、能使用、能接管，后面的功能和规模才有可以继续依托的基础。