先给结论
- 定制开发不是技术含量低，是技术被锁在单笔交付里。做出来的东西价值不低，但它只对那一个客户成立。
- 三处结构性缺陷：不能复用、难概括共性功能、客户群不同。三处分别发生在开发阶段、归纳阶段和市场阶段。
- 每一处缺陷都在账上有对应科目，也都有对应的申报后果。认得出缺陷，才谈得上补。
- 「研发人员多」要立得住，得先回答一个问题：这些人做的东西能不能被第二次卖。答不上来，说明人是在做交付，不是在造产品。
上一篇讲了怎么从成本费用结构里读出产品化程度，其中一个信号是直接人工占主营业务成本的比重偏高。这一篇接着往下问：这个比重为什么会高？高在哪里？为什么它不是「多招几个研发就能解决」的问题？
一、先把问题问对
「我们有上百人的研发队伍」，这句话在多数情况下是真的。研发人员名单、社保记录、工资表都能对上。但它能证明什么，取决于第二个问题：这些人每天在做的事情，是在造一个可以被第二次交付的东西，还是在完成某一位客户这一次的需求？
如果是后者，那么「研发人员多」与「技术能力强」之间就断开了。断开的地方不在人身上，在工作的组织方式上——项目制的组织方式，会稳定地产生下面三处缺陷。
二、缺陷一：不能复用——交付即移交
定制项目最直接的特征是交付即移交。需求由客户定义，成果按合同交给客户，做完这一单，团队回到起点等下一单。下一单的客户不同、流程不同、接口不同，上一个项目的代码、模型、方案能用上的部分往往很有限。
这带来一个反直觉的后果：做得越多，边际上并不会越省力。第十个项目和第一个项目投入的人力大致相同。而产品化程度高的公司，第二万个客户的交付成本远低于第一个——因为资产在累积，每一次交付都在往同一个底座上加东西。
要判断自己属于哪一种，有一个很少被认真算过的数：模块复用率——新项目里有多少比例是直接沿用既有模块，而不是重新写一遍。这个数不需要很精确，估一个区间就够用：低于三成，说明资产基本没有累积；超过一半，说明底座已经成形。
为什么这个数重要：它同时是经营指标和申报凭证。经营上，它决定毛利率的走向；申报上，它证明研发活动确实形成了可重复利用的技术资产，而不只是完成了若干次一次性服务。
三、缺陷二：难概括共性功能——几十套软件提不出一个底座
第二处缺陷更隐蔽：即使团队愿意沉淀，也未必沉淀得出来。
原因在于，共性功能不是从单个项目里总结出来的，是从多个项目的差异里对出来的。只做了一个客户，你无法判断哪些需求是这个客户的偏好、哪些是这一类客户的共同需要。做十个客户，才敢说某一组功能是共性的；做五十个客户、且客户之间差异足够大，共性功能才会自己浮现出来。
定制项目往往恰好落在最不利的区间：客户数量少、单笔金额大、每个客户都要求专属流程。于是每一个项目的需求都被当作「特殊情况」来满足，没有人有动力去问「这是不是大家都需要」。一年下来项目做了几十个，能被称为产品底座的却一个也没有。
这也是为什么定制的软件很难被概括出通用形态：不是团队不努力，是样本不足以支撑归纳，而且客户结构本身也不奖励归纳。
四、缺陷三：客户群不同——通用产品的买家不是原来那批
第三处缺陷常常在最后一刻才被发现，也是最容易被低估的一处。
定制时代的客户是认识你的人——通过关系、口碑、行业圈子找到你，决策链短、单价高、可以谈。而通用产品的客户是能被触达的人——数量多、单价低、需要被反复告知、需要试用、需要售后体系。这两种客户不在同一个池子里，采购逻辑也不同。
所以「先把产品做出来，客户自然就有了」这个假设通常不成立。产品做出来了，客户名单却要从头建一遍，而且建这套销售体系的投入，要在收入起来之前先花出去。这一笔账单独展开，下一篇会专门讲。
五、三处缺陷分别长在账上的哪个科目
把三处缺陷与报表和申报材料对起来看，会更清楚它们为什么不是「多招人就能解决」的问题：
| 缺陷 | 发生阶段 | 账上的表现 | 申报上的表现 |
|---|---|---|---|
| 不能复用 | 开发阶段 | 主营业务成本里直接人工占比高，毛利率被压住 | 研发投入难归集，人的成本与研发费用对不上 |
| 难概括共性功能 | 归纳阶段 | 项目数量多但单个项目金额不大，投入分散 | 研发项目多，但成果无法归并，转化数量看着多却经不起追问 |
| 客户群不同 | 市场阶段 | 销售费用结构要重建，前期费用先出、收入后到 | 收入口径与销售模式要重新描述，成长性指标短期承压 |
三处缺陷有一个共同点：它们都不是「再多招几个人」能解决的。招人能提高单笔交付的产能，但不会自动产生复用、不会自动归纳出共性功能、也不会自动带来另一批客户。要动的是组织方式，不是人数。
六、那么，定制开发的公司该怎么办
不绕弯子，实务上有三条路可选，而且它们并不互斥。
第一条是承认现状，先把交付做扎实。如果客户的定制需求本身就很值钱，那么与其硬做一个卖不动的通用产品，不如把交付标准化——固定的实施流程、可复用的模块库、可量化的交付周期。同一门生意，成本结构的形态会明显改善。
第二条是选一个切口做减法。不必把整套系统产品化，只需要挑出一到两个所有客户都会用到的环节，先把它做成标准件。切口越小越容易成功，也更容易在后续项目里被强制复用。
第三条是先补记录，再谈产品化。无论走哪条路，复用率、交付周期、缺陷率这类数从今天起就要留。它们既是产品化的起点，也是申报材料里最能说明「研发活动真的在运转」的证据。
三处缺陷里，「不能复用」这一处已经在上一篇用成本费用结构量化过，两篇可以对着看：从成本费用结构读出产品化程度。而定制阶段的人到底能不能算研发人员、按什么标准算，见高企科技人员认定标准全解；软件类企业在这个问题上的特殊处理，见软件企业申报高企的特殊要点；至于产品该怎么分层拆开、哪些算独立产品，可参考物理结构与逻辑结构：同一个产品的两种拆法。
知道自己在哪一档之后，下一个问题是「什么时候该往上走」——四级台阶各自有一句可数的触发信号，以及改造期毛利率先降后升的正常区间，见从定制到产品的四级台阶。反过来，如果已经自认产品化、毛利率却始终抬不起来，先排查四种伪产品化的情形，见一套代码卖给十个客户，也可能只是伪产品化。
本文为申报方法论梳理，属实务建议层。文中「模块复用率」等指标为实务观察口径，不是官方认定指标；涉及科技人员认定、研发费用归集与成果转化的具体判定，以《高新技术企业认定管理工作指引》（国科发火〔2016〕195号）及当年度申报通知为准。本文不构成对任何具体申报结果的预期。
