先给结论
- 产品化不是一次决定，是四次决定。每上一级都有自己的触发信号，信号没到就动，等于白付改造代价。
- 触发信号是可数的，不是感觉。同一个需求被几个客户提过、并行分支有几个、配置项要不要专人维护——都是可以查出来的。
- 每一级改造期毛利率都会先降后升。降多久、降到什么程度算正常，有一个可以对照的区间。
- 三处不该跳档。跳档会把改造变成一次没有回报的重写，比不做更伤。
前两篇解决了「我在哪一档」的问题。这一篇解决下一个问题：什么时候该往上走一格。
之所以要把这件事拆开说，是因为「我们决定做产品化了」这句话，通常会演变成一次大而全的重构——推倒重来、重新设计、招一批人。这种做法的失败率很高，原因不在决心，在于把四次决定合并成了一次。
一、四级台阶与各自的触发信号
五档刻度对应四级台阶。每一级的触发信号都是可以数出来的，不是判断出来的。
| 台阶 | 触发信号（可数） | 这一级的动作 | 代价与常见失误 |
|---|---|---|---|
| 一档 → 二档 把重复的功能收到主干 | 同一个功能被三个以上客户分别提过，且每次都是重新做一遍 | 把重复实现的功能提到主干上做成共用模块，客户差异改用分支或开关 | 短期会占用研发人力，接单节奏要放慢一点；第一个被抽出来的模块往往需要重写，不能直接把某一客户的代码原样提上来 |
| 二档 → 三档 把补丁收成配置项 | 改一处公共逻辑要评估的分支超过三个；分支回归测试的工时开始超过新功能开发 | 把高频的客户差异改造成配置项，写实施手册，交付人员按手册操作 | 改造期交付人力不会立刻减少，反而要先增人把手册写出来；配置项本身需要治理，放任会变成另一种形式的代码 |
| 三档 → 四档 把配置收成版本 | 配置项多到需要专人维护，或客户开始问「你们多久出一次版」 | 建立版本节奏：需求池、发布计划、兼容规则、升级窗口，一次发布覆盖全部客户 | 必须有人对版本负责，这个人不能同时被项目占用；旧版本的维护承诺要先谈清楚，否则会背上一批无法退出的老版本 |
| 四档 → 五档 把版本开放成平台 | 客户或第三方提出要基于你的产品做二次开发，且这种要求反复出现 | 开放接口与组件，提供文档、沙箱与权限体系，把定制权交给对方 | 接口一旦对外开放就是承诺，兼容责任长期存在；开放过度会让核心能力被别人绕过，边界要先划清楚 |
二、信号没到就往上走，会发生什么
四级台阶里，最容易被提前启动的是第二级和第三级。
第二级提前启动表现为：只接过两三个客户，就开始做配置化改造，把每个客户的差异都设计成配置项。结果是配置项为不存在的需求提前留了口子，真正接单时反而不够用，最后仍然要改代码——代价付了，档位没动。
第三级提前启动表现为：客户只有五六个，就开始建版本节奏、排发布计划。结果是版本发布变成空转，每一次发布的内容都不足以支撑一次升级，客户也不愿意为升级停业务。
一句话的判定方法：往上走的动作，应该由「已经开始出现的成本」推动，而不是由「看起来更先进」推动。分支回归的工时、配置项的维护人数、客户催版本频次——这些是成本，成本到量了才叫信号。
三、改造期毛利率先降后升，这是正常的
把改造放回账上看，会看到一条比较固定的走向：毛利率先降，再升，而且中间那段净利润会比改造前更难看。
降的原因有两处：一是改造期间研发人力被抽去重构，同时还要维持正常交付，人力被摊成两份；二是被新建出来的配置项、版本流程在上线初期都需要维护，而这部分维护还没有换来客户数的增长。
判断这段「难看」是否正常，看两个点就够了：第一，交付侧的指标有没有在动——新客户实施人天、升级所需人天、并行分支数量，这三项里至少有一项应该在改造后半年内改善；第二，改造是否在一年内看到毛利回升的拐点。如果交付侧三项指标全无变化，说明改造做在了不影响交付的位置——那笔钱花在了看起来更整齐的代码上，而不是更低的交付成本上。
一句算账的话：把「并行分支数 × 每次改动的回归人天」乘出来，就是分支维护成本。当它超过新开发同等功能的成本时，收配置或收版本就不再是一个选择，而是必须做的止损。
四、三处不该跳档
一是信号没到就动。上一节已经讲过，提前启动不会加速，只会把代价提前付掉。
二是只动研发、不动交付流程。产品化改造经常被当成技术项目，交给研发团队推进。但这四级台阶里，每一级的收益都落在交付侧——实施手册、配置清单、升级窗口，全部由交付人员执行。研发改完了、交付流程没改，档位不会动。
三是改造期同时扩大销售投入。改造期交付能力最脆弱，这时候铺渠道会带来一批接不住的新客户，既拖慢改造，又消耗现金。合理的顺序是先让交付侧指标改善，再考虑放量。
五、三个常被当成「一步到位」的词，各自对应哪一级
行业里有两个词经常被当成产品化的终极答案，其实它们各自只对应某一级。
组件化对应的是第一级到第二级的动作：把重复的功能从各客户的分支里抽出来，提到主干上变成可复用的部分。它解决的是「同一件事做了很多遍」。
行业模板对应的是第二级到第三级的动作：把某一个行业的客户差异预先做成一套配置组合，新客户选模板即可交付。它解决的是「差异每次都要现改」。
中台对应的是第三级到第四级的过渡：当配置项多到需要专人维护、多个产品线开始共用同一批能力时，才需要把能力单独抽出来统一供数。在只有两三个客户的时候建中台，得到的会是一层额外的抽象和一批没人用的接口。
产品化到什么程度才适合对外按产品卖、需要哪些登记与证明材料，可参考苏州软件产品评估的实操口径；产品该怎么分层拆开、哪些算独立产品，见产品关系与使用场景；而改造期的研发投入该怎么立项、怎么写进辅助账，见高企研发费用归集实操指南。
台阶讲完了，还剩最后一件事：有些公司以为自己已经在第三、第四级，其实一格都没有动——下一篇讲四种伪产品化。档位怎么数出来，见产品化程度自测表；刻度的五档口径，见产品化程度的五档刻度。
本文为申报方法论梳理，属实务建议层。文中四级台阶、触发信号与改造期毛利率走向，是本文按实务经验整理的观察工具，不是官方划分，也不对应任何认定标准中的分类；涉及软件产品评估、研发费用归集与研发项目立项的判定，以《高新技术企业认定管理工作指引》（国科发火〔2016〕195号）及当年度申报通知为准。本文不构成对任何具体企业财务判断或申报结果的预期。
