几乎所有制造企业，都会在某个阶段遇到同一道题：研发和生产，要不要合并？
合并的理由听起来无懈可击。客户投诉样品到量产总是走形；研发说生产做不出来，生产说研发不懂工艺；两个部门开会，从技术问题吵到态度问题。老板一拍板：让一个人管，省得扯皮。
头三个月，效果确实明显。沟通快了，扯皮少了，样品转量产顺了。
但往往到第三年，会冒出另一批问题：新品越来越像老产品的改款；研发骨干一个个离开；留下来的工程师，慢慢变成了产线救火队。
这不是哪个人的能力问题。这是结构的问题。
01 合并解决的是沟通，动的是判断
先说清楚，合并到底改变了什么。
它本质上做了一件事：消灭一个界面。
研发和生产之间，原本横着一道墙。墙很贵：图纸要转换，工艺要确认，样品要交接，出了问题要开会定责。合并把这道墙拆了，交接成本确实降下来。
但墙拆掉的同时，也拆掉了另一样东西——两种不同的判断，原本可以在同一个层级上被摆到桌面上。
原来研发负责人和生产负责人是平级的。平级意味着，一件事做不做、什么时候做、投多少资源，双方各有一票。冲突不会被藏起来，只会往上走到老板那里，摆明着解决。
合并以后，冲突不见了。因为只剩一个人，他不需要和谁争，只需要在自己脑子里排个序。
排序这件事，恰恰是最危险的。它不出现在任何会议纪要里，也不产生任何争论，但它每天都在发生。
02 这两件事的考核表，本来就写不成一张
很多人把研发和生产的矛盾，理解成性格矛盾、立场矛盾，甚至是部门利益。其实不是。
它们是两套目标函数。
维度 |
生产 |
研发 |
核心指标 |
交付、良率、成本、人均产出 |
新品节点、技术指标、变更质量 |
时间尺度 |
今天、本月、本季度 |
六个月到一年半 |
对波动的态度 |
消灭波动 |
制造可控的波动 |
成功的定义 |
把已经跑通的事重复一万次 |
把没跑通的事跑通一次 |
决策依据 |
已经验证的工艺 |
尚未验证的假设 |
请注意最后两行。
生产的成功，是把已经跑通的事重复一万次；研发的成功，是把没跑通的事跑通一次。一个要消灭波动，一个要制造可控的波动。
它们不是上下游关系，是两种时间尺度、两套风险偏好。
把这两张表压到一个人身上，不是不可能，但那个人每天都要做一次取舍。而取舍的结果，几乎总是可以预测的。
03 被挤掉的，永远是周期长的那件事
目标函数一旦合并，具体会发生四件事。这四件事，顺序几乎都一样。
第一，资源被排产挤走。
试制线在物理上往往只有一条，人和设备是共用的。订单压过来时，试制品排在量产品后面，是最自然的选择——量产品晚一天，客户会罚；试制品晚一周，没人会知道。
于是研发的时间被切成碎片：原定连续三天的验证，变成每天下午两小时。
第二，变更被无限期推迟。
一个设计变更，从提出问题到落地，中间要过评审。评审席上坐着的是同一位领导，而他手里还压着本月的交付目标。变更意味着停线、返工、重新验证，意味着这个月的数字难看。
很多变更不是被否决的，是被“再观察一批”拖死的。半年之后，问题还在，只是已经没人提了。
第三，人才结构悄悄反转。
这是最容易被忽略、也最难逆转的一条。研发团队里通常有两类人：一类擅长解决现场问题，一类擅长长期技术积累。合并之后，前一类人天天被表扬，后一类人天天被追问“这个东西什么时候能用到生产上”。
三年下来，留下来的都是能顶产线的，走掉的都是愿意死磕的。等到企业真正需要做一次技术跨越，才发现手里没有那批人了。
第四，质量归因被内部消化。
设计和制程出问题时，正常流程是两边互相举证，最后形成一个明确的归因。合并之后，两边归同一个人管，归因就变成了“内部协调”。
内部协调的结果，通常是先保证出货。问题被压进“下一批再说”，而不是被压进“设计要改”。这是最贵的一种省钱。
04 真正起作用的，不是态度，而是信息到达的顺序
很多老板会说：我选的这个人能扛事，格局够大，不会有问题。
问题不在于他格局够不够大，而在于他每天收到的信号，本来就不对称。
交期延误，客户当天就会打电话，销售当天就会找上门。技术指标落后，要等到半年后的样机测试，甚至等到客户流失才会被看见。谁先喊疼，谁就先拿到资源。
这不是价值观问题，是信息结构问题。
所以你会看到一个很典型的场面：研发年度计划年初做得漂漂亮亮，到二季度，试制线已经去支援量产了，验证工时砍了一半。没有人反对，也没有人犯错。
每一次让步，单看都合理。加总起来，就是把研发做成了“生产的技术科”。
05 三个常见的自我安慰
误区一：我们沟通很好，不会出现这个问题。
沟通解决不了优先级。会议桌上你让一步，往往不是因为你被说服了，而是因为对方手里握着你的资源。只要资源分配权在一个人手上，沟通再顺，也只是让让步的过程更体面一些。
误区二：我们规模不大，一个人管效率更高。
规模小确实需要兼。但兼的应该是事务，不能兼裁判。哪怕只保留一个独立的评审接口，让变更和技术投入的争议有一条能摆到台面上的通道，也比全压在一个人脑子里强。
误区三：找一个强势的研发负责人来管就行。
强势的人能顶一阵，顶不过考核表。他可以在会上拍桌子，但排产单上的顺序遵循的是另一套逻辑。更何况，人一换，结构立刻回到原样。
06 不合并，不等于不协同：四道接口
说到这儿，容易被误解成“研发和生产要分开、各干各的”。完全不是。研发和生产当然要靠近，问题是怎么靠近。
更稳妥的做法，是把合并省下来的那点沟通成本，换成四个明确的接口。
考核表分开。研发考新品节点、技术指标、变更质量；生产考交付、良率、成本。两张表各自独立，不设一张“综合分”去平衡，因为综合分最终一定会偏向当月的数字。
变更走独立通道。设计变更要有明确的评审时限和升级路径，不能由生产方以“影响交付”单方面否决；超过时限未裁决，必须升级处理。
研发资源独立预算。试制线档期、验证工时、样品优先级，年初锁定，不参与日常排产的竞价。这一条最实在，也最难做。
共同的项目治理机制。以新产品导入为主线，研发和生产是项目里的两个角色，各有交付物，共同对上市节点负责，而不是上下级关系。
这四件事的本质，是一句话：协同靠接口，不靠汇报关系。
汇报关系解决的是“谁听谁的”，接口解决的是“什么情况下按什么规则办”。前者依赖人，后者依赖结构。人一走，前者归零；结构搭好，后者还在。
07 什么情况下，确实可以合并
这个判断不是绝对的。有三种情况，合并反而是合理的：
产品结构单一，技术已经高度成熟，研发的实质工作是工艺维护和现场改善；
企业规模小到一年只做一两个小改款，独立设研发部门本身就是浪费；
技术来源在外部，客户给图纸、集团给方案，内部研发只做本地化落地。
但只要出现下面任何一个信号，合并就要谨慎：产品线多于三条；每年有实质性新产品上市；核心技术需要自己积累；客户对技术指标有持续升级的要求。
在这些企业里，合并几乎一定会把研发变成“生产的技术科”。它不会立刻出问题，甚至会先带来两年的效率提升。代价在第三年才结算，而那时候，往往已经分不清是市场变差了，还是自己变钝了。
结语
研发和生产当然要靠近，但不能变成同一个人的两张脸。
组织如果只有一个声音，短期看是效率，长期看是失声。
所以判断要不要合并，不必先问这两个人合不合得来。先问一句：这两件事的考核表，能不能写成一张？
如果写不成，就不该由一个人来签。