POC做成产品演示会，是国企数字化项目最常见的浪费。用例设计、异常分支、评估标准，这些决定POC含金量的环节，这篇按实操顺序讲一遍。
一、定位：POC替立项决策回答风险问题
POC走过场，根子多半不在执行在定位。把它当成采购流程的必经环节来做，招标文件里有要求、不做不行，它就只会产出一场表演；把它当成决策工具来做，它才产出答案。两者的区别在于：表演的目标是顺利结束，答案是问出风险在哪。
1. POC回答的是风险，不是产品好坏
立项评审真正关心的问题很具体：这套方案在我们这个数据规模、这套遗留系统、这种组织环境下能不能落地，最可能翻车的环节是哪个。POC的设计就是把这些边界条件挖出来挨个验证。任何成熟产品在理想环境下表现都不会太差，产品之间的真实差距全部藏在边界条件里：数据量、集成复杂度、权限体系、流程的异常分支。把验证目标定成产品功能清单挨个演示，是对POC最大的浪费。
2. 三方对齐再开工
业务部门、IT部门、供应商对POC的期待经常各不相同：业务方想看界面顺不顺手，IT关心技术债务和运维成本，供应商想展示亮点功能。开工前把验证清单摆到桌面上，逐项确认这是各方共同认可的评估对象，清单之外的演示内容不作为评估依据。这一步偷懒，评审会上就是各说各话，最后拍板靠印象。定位和共识先立住，后面的设计才有意义。
二、验证目标：一次只验三件事
POC最忌大而全。三周时间列二十个验证点，等于每个点浅尝辄止，每个结论都不牢靠。验证目标宁可砍到三个，也别凑到三十个，收敛比全面更有价值。
1. 从立项风险倒推验证项
方法很简单：立项评审时最可能被挑战的风险点，就是POC的验证项。国企数字化项目里典型的三类风险：性能风险，核心表数据到千万级，查询和报表还能不能用；集成风险，和ERP、OA这些运行多年的老系统对接，接口规范谁出、联调成本怎么算、改造责任归谁；适应性风险，业务流程里那些带条件分支和特批的复杂场景，平台能不能配出来。每类挑最可能翻车的一两个点进清单，其余明确放弃。
2. 每个验证项配可度量的标准
「跑得动」不是标准，「千万级数据的列表查询三秒内返回」才是。验证项全部落成可度量的指标，POC结束时的评估才有依据，否则评审会上只剩形容词互相打架。指标定不出来的验证项，说明这个点本身没想清楚，先想清楚再进清单。
3. 写清楚不验什么
POC不覆盖的内容，界面美化、全流程打通、组织推广，提前写进方案里说清楚。不写，评审会上一定有人问「这个怎么没看到」，解释成本高，还容易被临时要求补演示，节奏全乱。验证清单的边界，和清单本身一样重要。
三、用例设计：真实数据跑真实场景
POC和演示的分水岭在数据。演示用供应商准备好的干净数据，POC必须用从生产环境抽出来的真实数据。数据一真，乱编码、空字段、超长字段、历史脏数据全冒出来，这些才是立项之后每天要面对的东西。
1. 数据准备的三条底线
量级贴近真实，别拿一千条演示数据糊弄，核心业务表按生产量级的十分之一到三分之一抽样，压测场景直接上全量；脏数据保留，专门挑几条乱编码、字段超长、主键冲突的记录进去，看系统是报错还是报对；该脱敏的脱敏，但别脱到失真，金额全脱成星号，业务校验和性能压测都失去意义。数据准备的认真程度，直接决定POC结论的含金量。
2. 场景挑业务最疼的，异常分支必测
场景不贪多，挑业务方最疼的两三个，完整走通，重点是异常分支：单据被驳回后重提、并发编辑的冲突处理、跨系统的状态同步。顺利路径谁都能跑通，异常分支才见真功夫。操作环节让业务方的一线操作员自己上手，IT不要代操作，一线员工用着别扭的系统，上线推广就是另一场更贵的POC。
3. 集成验证单独排期
和遗留系统的集成是国企项目最深的深水区：接口规范谁出、联调环境谁搭、老系统侧的改动谁做谁批，这些事没有一家供应商能独立搞定。集成验证在POC计划里单独排期单独盯，它是唯一大概率超期的部分，也是验证价值最高的部分。这块含糊过去，POC基本等于白做。
四、评估：把观感变成可比的结果
评估环节最容易滑向观感决策，谁演示得流畅谁得分高。治理办法是把眼睛看到的都变成可比较、可追溯的东西。
1. 计分表先于POC启动定稿
评估表在POC开始前定稿并给供应商确认：验证项、权重、评分标准全部写死。事后补的评估表会不自觉迁就结果，先定死的表才有约束力。这是用程序正义保结论可信。
2. 过程观察单独记录
结果分之外，过程表现单独记一本账：供应商现场响应问题的速度，说不清楚的需求追问三轮之后的态度，现场工程师人数和后台支持的比例，出现故障时的第一反应是修还是辩。这些是实施能力和售后能力的侧写，正式实施时的体验和POC期间高度一致，别只盯着最后那个总分。
3. 结论三档，条件写死
POC报告的结论分三档：通过、有条件通过、不通过。实践中最常见的问题是有条件通过被包装成通过，条件里的风险（某指标在特定场景未达标、需限期优化）被一句「总体符合预期」带过，雷就这么埋进立项文档。条件要写清到场景和数值，责任到人，期限到日，立项评审时逐条过。
五、POC到立项：交接不断层
POC结束到正式立项之间有个容易断的接缝，接的是两样东西：配置资产和踩坑记录。接不上，正式项目从零开始，POC的钱白花。
1. POC的配置资产别扔
POC里调通的流程、接口、数据映射，正式实施能继承多少，决定项目是从七十分起步还是从零起步。后来POC直接在搭贝上搭的环境，转正式时配置资产整体平移，重复劳动省掉一大块；它的价格是按用户数报价，试点期用户少，这部分投入可控。选型时把「POC环境能否转正式」当成一个评估项，比事后补救划算得多。
2. 把踩过的坑写成正式需求
POC暴露的问题，性能瓶颈、集成障碍、易用性缺陷，逐条写进正式项目的需求文档和实施计划，附上应对方案和责任人。POC的价值一半在验证通过，另一半在提前排雷：验证通过的结论说给评审会听，排掉的雷写进文档留给实施团队，两样都不能少。
常见问题
Q：POC结论和报价谈判冲突怎么办？
POC技术分最高和报价最低的不是同一家，这种情况比想象中多。处理办法在前面：采购规则里提前写清POC结论在综合评分里的权重，而不是事后纠结。技术上够用的最低标准在验证项里就应该定义清楚，别让POC替报价背锅，也别让报价替POC遮羞。
Q：多家供应商一起POC怎么组织？
一套数据、一批场景、一份计分表，环境互相隔离。场景细节分批发放，防止供应商之间串题；排期错开，不让各家互相围观。评估时同一验证项横向比，别一家一家纵向讲，差异才看得清。
Q：业务方不出人配合怎么办？
业务方出人是POC成败的一半，人不出，POC就是IT和供应商的自嗨。办法是把业务方拉进验证项定义，疼的地方他们说了算；操作环节必须业务方自己上，他们的体感就是评估数据；再要管理层给业务方投入的时间做背书，把配合写进考核而不是靠人情。
Q：POC一般做多久合适？
两到四周，超过一个月的多轮POC要警惕：供应商投入攀升，业务方配合度断崖式下跌，边际收益快速递减。用时间盒管理，到期评估，不完美就带着明确的条件进下一阶段，别用无限延期换一个完美结论，那个结论不存在。