产品化程度

看四组数的组合形态：毛利率、研发费用率、销售费用率、直接人工占主营业务成本的比重。前三项偏高、第四项偏低，指向产品化程度高；反过来，毛利率低、直接人工占比高、研发与销售费用率都低，指向项目化。这四组数里，毛利率与直接人工占比是同一件事的两面——一个是结果，一个是原因。判断时不要单看某一项，要看四项组合起来指向哪一端，以及它在往哪一端移动。

不能单独看。毛利率高通常意味着可复用程度高、多做一份的增量成本很小，但它也可能是别的原因造成的：定价权来自技术领先或品牌，或者当期成本被压得很低。要确认是不是产品化带来的，还要看另一组数——直接人工占主营业务成本的比重。如果毛利高、人工占比也低，说明利润是从复用里出来的；如果毛利高但人工占比仍然很高，更可能是靠定价或项目选择挣来的，产品化程度未必高。

因为收入是结果，成本费用才是过程。一家公司开发通用产品按套卖给大量客户，交付的是软件加授权或账号，成本以服务器、带宽和少量实施为主，毛利高，利润空间在毛利里就已经形成，后面的研发费用和销售费用决定它还剩多少；另一家为每个客户单独开发，成本以开发与技术服务人员薪酬为主，毛利薄，利润要在成本里抠出来。两家公司的净利润来自两个完全不同的抽屉，所以净利润相同不代表经营形态相同。

三处。第一，前提是会计核算规范——如果交付人员的薪酬被整块归进研发费用，研发费用率会被抬高、主营业务成本被压低，结论会整体偏向产品化。第二，中间态才是大多数，真实企业常是「一套通用底座加每个客户少量定制」，四项数会呈混合形态，只能看趋势，不能贴标签。第三，实施与维护会长期占用人力，软件类公司的直接人工占比很少降到很低，看到人工占比可观不必立刻否定，那可能只是实施环节的正常成本。

因为问题不在人数，在工作的组织方式。项目制会稳定地产生三处缺陷：一是不能复用，交付即移交，成果按合同交给客户，下一单要回到起点；二是难概括共性功能，共性是从多个项目的差异里对出来的，客户数量少、单笔金额大时样本不足以支撑归纳；三是客户群不同，通用产品的买家是能被触达的人，不是原来那批认识你的人。三处都不是再多招几个人能解决的，要动的是组织方式。

最直接的原因是交付即移交：需求由客户定义、成果按合同交出去，做完这一单团队回到起点，下一单的客户不同、流程不同、接口不同，上一个项目能用上的部分往往很有限。带来的后果是做得越多边际上并不会越省力——第十个项目和第一个项目投入的人力大致相同。而产品化程度高的公司，新一份交付的成本远低于第一份，因为资产在累积，每一次交付都在往同一个底座上加东西。

模块复用率指的是新项目里有多少比例是直接沿用既有模块，而不是重新写一遍。不需要算得很精确，估一个区间就够用：低于三成，说明技术资产基本没有累积，每一次交付都是从头开始；超过一半，说明产品底座已经成形。它同时是经营指标和申报凭证——经营上决定毛利率的走向，申报上用来证明研发活动确实形成了可重复利用的技术资产，而不只是完成了若干次一次性服务。

要分两件事看。技术工作在发生，这一点通常是成立的，团队确实在解决新问题；但「研发能力」在申报与投资语境里指的是形成可重复利用的技术资产的能力，这两件事不是一回事。判断的关键是问一句：这些人做的东西能不能被第二次卖。如果每一单都要重新投入等量人力、成果无法归并成独立科技成果，那么即使人员名单、社保和工资表都能对上，形成资产的那部分仍然是缺的。

因为客户群跟着产品一起换了。定制时代的客户是通过关系、口碑、行业圈子找到你的，数量不多、单价高、决策链短，销售工作主要是维护关系；通用产品的客户数量多、分布散、大多不认识你、单价低、要试用要对比要售后，销售工作变成了建立触达。这两种客户不在同一个池子里，采购逻辑也不同，原来的销售团队往往接不上——不是能力问题，是两件事本来就不一样。

通常不是。这个阶段会同时发生两件事：毛利率改善，同时新增的销售费用把改善吃掉。如果只看净利润，会得出产品化不划算的结论；把两组数分开看则完全不同——毛利改善是经营质量的变化，属于长期；销售费用上升是商业模式的切换成本，在体系建成之后会摊薄。判断有没有见效要看另一组数：单个客户的获取成本有没有随规模下降，老客户复购与转介绍的比例有没有起来。

看两个数：单个客户的获取成本有没有随着规模下降，以及老客户复购与转介绍的比例有没有上升。这两条同时成立，说明买的是体系——体系会随规模摊薄，越做越省；如果获客成本居高不下、客户来一次就不再来，那说明买的不是体系，是流量，要继续加投放只会加大亏损，此时该回头检查产品本身，而不是加大销售投入。

三种情况。一是订单仍主要来自老客户的关系链、且关系链还很牢，这时铺渠道的钱大概率浪费；二是产品还没被验证到可以脱离现场，每个新客户都要你派人到现场才用得起来，那么触达再多也接不住，问题在交付不在销售；三是资金只够支撑一次投入，销售体系重建是前置大额投入，中途停下等于白花，此时不如把资源先投在交付标准化上——那笔投入即使没做完也会留在能力里。

要看这段时间实际在做什么。研发费用归集的原则是按实际发生的活动归，不按想达到的比例归。如果这批人一部分时间在做新项目的开发、另一部分时间在完成已签合同里的交付与实施，那么交付与实施对应的薪酬应当进入主营业务成本，而不是研发费用。把交付人力整块归进研发费用是常见的归集风险：核查时一旦要求提供工时记录、立项书与验收材料，对不上的部分会被剔除，严重时影响整套材料的可信度。

因为达标只是一层，更关键的是这百分之十的人能不能在核查时说明白自己在做什么。认定口径看的是从事研发和相关技术创新活动的人员，判断依据通常是岗位职责、参与的项目以及可佐证的工时或工作记录。产品化程度低的公司会遇到一个结构性问题：人数够，但记录难做——被统计为研发人员的那批人，实际工作被交付任务切成了碎片。所以达标的路径不是把人算进去，而是让研发活动本身变得可分、可记。

不取决于它是不是定制的，取决于它背后有没有可被认定为高新技术产品的技术支撑，以及这笔收入能不能与该项技术对应上。定制交付本身不构成障碍，但如果每个项目都是一次性开发、彼此之间没有共通的技术底座，那么收入与技术之间的对应关系就很难建立——你无法说清这笔收入对应的是哪一项技术成果。产品化程度高时这个对应是自然的：产品版本对应一套技术、技术对应一组知识产权、收入按产品线归集。

不能。计数规则看的是科技成果本身的同一性：同一科技成果转化为多个产品的，只计为一项。所以看的是成果，不是登记次数、产品个数或项目个数。产品化程度低的公司在这里真正的问题不是数量不够，而是成果多而散——二十个项目里能被归纳成一项独立科技成果的可能只有两三组，其余部分彼此重合，重复提交会落进同一项里，反而不显示增量；而且一旦被问「这几项之间的技术区别是什么」，材料很难解释。