研发行管部门不是“研发监察部”，也不是各 BG 的流程秘书。CEO 真正关心的是：它能否把公司级研发能力变成经营结果，能否让重大客户项目更稳、毛利更健康、质量风险更早暴露、平台复用更强、组织能力可复制。
如果我是 CEO，我不会把研发行管部门定位为“流程合规部门”，而会把它定位为公司级研发经营能力的建设者。它的价值不在于管住研发，而在于让研发更可预测、更可复用、更能支撑利润和战略客户。
CEO 看研发行管，首先看它是否服务公司经营，而不是服务部门存在感。六个关注点分别对应增长、利润、质量、效率、平台和组织韧性。
重大客户项目是否有清晰风险雷达，能不能在节点失控前把客户输入、技术风险、供应链、产线、验证资源的问题暴露出来。
研发是否在方案早期参与目标成本、BOM、复用、工艺和良率设计，而不是量产前被动降本。
设计评审、FMEA、验证计划是否真正把高风险问题挡在 EVT/DVT/PVT 和量产之前。
项目卡在哪里，阻塞来自客户、研发、测试、供应链还是产线，哪些阻塞需要公司级协调。
相似技术、物料、测试方法和失效经验能否复用，避免每个 BG、每个项目重复开发和重复踩坑。
公司是否有足够项目经理、系统工程师、技术评审专家和质量前移能力，支撑复杂产品组合增长。
CEO 看板不应超过 12 个指标。指标要能触发管理动作，且必须避免把客户、供应链、产线等不可控因素简单归责给研发。
| 经营主题 | CEO 指标 | 看什么 | 统计口径 | CEO 管理动作 |
|---|---|---|---|---|
| 重大项目 | 红灯项目数与 Top 风险 | 哪些项目会影响客户承诺、收入确认、量产爬坡或战略关系 | 只统计战略客户、重大收入、重大技术风险项目；按客户/研发/供应链/产线/验证归因 | 决定是否升级客户沟通、资源调配或高层 sponsor 介入 |
| 项目可控性 | 阶段偏差归因率 | 延期是否被说清楚，是否知道真因 | 已完成归因的阶段偏差数 / 阶段偏差总数 | 要求研发行管推动统一原因码和复盘机制 |
| 研发责任 | 研发可控延期率 | 延期中真正由研发可控问题造成的比例和趋势 | 研发可控延期数 / 已归因延期数；剥离客户、供应链、产线等外部因素 | 针对研发可控 Top 原因设专项，而不是泛泛要求“提效率” |
| 质量前移 | 重大问题前移率 | 重大问题是在设计评审和验证前期发现，还是逃到试产/量产 | 前端发现的 A/B 类问题 / 全生命周期 A/B 类问题 | 强化设计评审、FMEA、验证计划和专家评审 |
| 质量损失 | 逃逸缺陷率与重复问题率 | 质量防线是否有效，同类问题是否重复发生 | 后阶段发现且归因前阶段的问题 / 后阶段问题总数；重复问题 / 问题总数 | 推动失效模式库、设计规范、评审清单更新 |
| 成本利润 | 目标成本达成率 | 研发方案是否从前端满足目标成本和毛利要求 | 达到目标 BOM 成本的项目数 / 应达成项目数；目标成本在 RFQ/立项早期锁定 | 要求研发、采购、制造、财务共同做 Design-to-Cost |
| 成本真实性 | Should Cost 偏差率 | BOM 或关键物料是否明显偏离合理成本 | (当前成本 - Should Cost) / Should Cost；覆盖 Top 成本物料和关键模块 | 防止初期高 BOM、高报价，再通过降本邀功 |
| 利润贡献 | BOM 毛利贡献率 | 设计优化、复用和规格优化是否转化为项目毛利 | BOM 成本改善额 / 项目销售收入；需通过质量和量产验证 | 把研发降本和经营结果挂钩，而不是只看降本故事 |
| 平台复用 | 高价值模块/物料复用率 | 公司级技术资产是否被跨 BG 使用 | 复用成熟模块、优选物料、测试方案的项目占比；按产品族统计 | 决定平台技术、物料标准化和专家资源投入 |
| 组织能力 | 重大项目复盘闭环率 | 踩过的坑是否变成公司资产 | 完成复盘并更新流程/清单/知识库的问题数 / 应复盘问题数 | 把经验沉淀纳入平台部门和 BG 共同责任 |
| 数据可信 | 核心指标数据覆盖率 | 看板是不是靠人工汇报，还是来自系统和统一口径 | 有系统数据支撑的核心指标数 / 核心指标总数 | 给 IT 和流程统一授权，降低汇报成本 |
| 组织协同 | 公司级阻塞事件闭环率 | 跨 BG、跨部门的问题是否有人推动到底 | 关闭的红灯阻塞事件 / 红灯阻塞事件总数；按责任域统计 | 协调供应链、制造、品质、客户接口和研发资源 |
CEO 指标不能由研发行管部门单独“要数”。正确做法是建立指标 Owner、数据 Owner、业务解释 Owner 三权分离：平台部门定义口径和做看板，BG 对业务事实负责，财务/成本/采购/IT 对敏感数据和系统字段负责。
| 指标组 | 主责 Owner | 关键资源投入 | 数据来源 | 平台部门可见口径 | 准确性保障 |
|---|---|---|---|---|---|
| 红灯项目与阶段偏差 | BG 项目负责人 / BG 研发负责人 | BG PMO、客户接口、供应链、制造、测试负责人参加周度风险会 | NPI/项目计划、周例会红黄灯、客户节点、试产计划 | 项目代号、风险等级、责任域、影响节点、需协调事项；不必看客户商业细节 | 月度抽查红灯项目，阶段偏差必须有单选原因码和关闭动作 |
| 研发可控延期 | BG 研发管理接口人 | 系统工程、专业负责人、测试、质量共同参与归因 | 阶段复盘、评审结论、验证报告、问题系统 | 研发可控原因类别、趋势和 Top 问题；不看个人责任排名 | 研发行管主持复盘模板，BG 确认归因，重大争议提交治理委员会 |
| 质量前移、逃逸、重复问题 | 质量平台 / BG 质量负责人 | 研发专家、测试实验室、质量工程、制造工程共建问题分类 | 问题系统、8D、试产问题库、客诉、可靠性测试报告 | 问题等级、发现阶段、逃逸阶段、问题族、闭环状态；客户敏感问题可脱敏 | 统一严重度、阶段、问题族字典；每月抽样复核 A/B 类问题 |
| 目标成本与 BOM 成本 | 财务经营 / 成本工程 | 采购、研发、制造工程、供应链、报价团队参与目标成本评审 | 目标成本表、BOM、采购报价、历史项目成本、报价模型 | 指数化或区间化指标：达成/未达成、偏差率区间、Top 成本风险；不默认看完整金额 | 目标成本在 RFQ/立项早期冻结，变更需留痕；财务背书口径 |
| NRE 与开发投入 | 财务经营 / BG 经营管理 | 项目管理、研发资源管理、设备/工装/测试资源管理共同提供投入 | NRE 预算、实际发生、工装设备投入、外协开发、测试费用 | 预算达成率、偏差原因、分摊规则、项目级风险等级；明细金额按授权查看 | 预算版本锁定，变更审批；NRE 与客户收费、内部投入分开统计 |
| 复用率与平台资产 | 研发行管 / 技术平台 | BG 专家、采购、测试、IT 共建模块库、优选物料库和失效模式库 | PLM、模块库、优选物料库、测试方案库、BOM 复用标记 | 复用项目数、复用资产类型、收益区间、质量结果 | 复用必须过质量、供应、成本护栏；避免为了指标强行复用 |
| 数据覆盖率与可信度 | IT / 数据治理 | PLM、NPI、QMS、ERP、报价系统、问题系统建立最小字段接口 | 系统字段、数据字典、权限日志、月度数据质量报告 | 字段覆盖率、及时率、异常率、人工补录比例 | 系统取数优先，人工补录需标识；指标发布前由数据 Owner 确认 |
研发行管部门不需要、也不应该默认拿到所有商业明细。它需要的是能判断研发治理效果的“经营化、脱敏化、分层授权”的指标。敏感数据由财务和成本工程背书，平台部门看趋势、偏差和风险。
平台部门优先看达成率、偏差率、区间、指数、风险等级和 Top 原因，不默认查看客户价格、项目绝对利润、供应商详细报价。
日常看板用脱敏口径；专项复盘看受限明细；只有 CEO 授权的重大项目或审计场景查看完整明细。
凡涉及利润、BOM、NRE 的指标，平台部门不自行计算最终口径，而由财务经营或成本工程确认后发布。
| 数据类型 | 敏感等级 | 平台部门日常可见 | 专项可见 | 明细 Owner |
|---|---|---|---|---|
| 项目收入、客户报价、毛利率 | 极高 | 收入/毛利影响等级、毛利健康区间、达成/未达成 | 经授权可看项目级区间和偏差原因 | 财务经营 / BG 总经理 |
| BOM 明细成本与供应商价格 | 极高 | Top 成本风险、目标成本达成状态、Should Cost 偏差区间 | 经授权可看 Top 物料成本结构，不看完整供应商商业条款 | 成本工程 / 采购 |
| NRE 预算与实际发生 | 高 | NRE 预算偏差率、风险等级、偏差原因 | 可看费用类别：人力、工装、测试、外协、设备 | 财务经营 / BG 经营管理 |
| 研发资源投入 | 中 | 资源负荷、关键专家瓶颈、项目投入等级 | 可看项目级人月区间和专业结构 | BG 研发 / HR / PMO |
| 质量问题与客户问题 | 中高 | 问题等级、问题族、发现阶段、闭环状态 | 重大问题复盘可看根因和措施，客户名称按需脱敏 | 质量平台 / BG 质量 |
Should Cost 不是采购拍脑袋压价，也不是研发事后证明自己降本的工具。它应该是成本工程、采购、研发、制造和财务共同维护的“合理成本模型”，用于约束初始方案、识别过度设计和支撑目标成本。
| 对象 | 建模字段 | 谁提供 | 谁确认 | 平台部门看什么 |
|---|---|---|---|---|
| 关键电子料/芯片/传感器 | 规格、供应商、历史价格、替代料、MOQ、交期、汇率风险 | 采购 / 研发 | 成本工程 / BG | 偏差区间、替代机会、单一供应风险 |
| 结构件/声学件/光学件 | 材料、重量、制程、模具摊销、良率、表面处理、精度等级 | 研发 / 制造工程 | 成本工程 / 制造 | 过度设计风险、工艺成本风险、复用机会 |
| 模组/系统方案 | 模块边界、复用状态、测试覆盖、供应策略、NRE 摊销 | 技术平台 / BG 研发 | 成本工程 / 财务 | 模块复用收益、目标成本达成状态 |
| 测试/工装/治具 | 设备利用率、测试时间、治具寿命、并行度、维护成本 | 测试 / 制造工程 | 制造 / 财务 | 测试成本瓶颈、复用机会、NRE 风险等级 |
CEO 看板要少、硬、能决策。建议每月一页，分成经营风险、能力改善、成本利润和需 CEO 决策四块。
这些问题比单纯看指标更重要。指标负责报警，问题负责逼近经营真相。
影响什么客户、什么节点、什么收入或战略机会，需要谁出手。
客户、供应链、产线、测试资源的问题要透明，不要让研发背锅，也不要让问题失主。
如果是方案成熟度、评审准备、验证计划、资源安排问题，就要设专项改善。
如果问题仍集中在 PVT 或量产暴露，说明设计评审和验证体系没有守住防线。
重复问题是组织学习失败，不只是项目执行问题。
如果量产前才降本，说明目标成本、复用、工艺和采购协同晚了。
有没有相对 Should Cost 和目标成本校准，有没有初始 BOM 虚高。
不是建了库，而是关键项目用了成熟模块、优选物料、测试方法和历史失效经验。
我要看系统性改善，不看会议数量和制度数量。
如果关键专家长期被项目抢占，公司需要机制化配置专家资源。
如果指标导致少报问题、虚高初始成本、拒绝难项目，就必须改口径。
没有决策请求的汇报，不应该占用 CEO 月会时间。
研发行管部门很容易滑向“检查型、报表型、运动型”。CEO 要保护它的正确方向，也要防止它制造组织负担。
| 红线 | 表现 | CEO 判断 | 纠偏动作 |
|---|---|---|---|
| 把流程合规当价值 | 制度多、表格多、会议多，但重大风险仍然后知后觉 | 平台部门没有创造经营价值 | 砍掉低价值检查，聚焦重大项目风险和共性专项 |
| 把外部问题算研发绩效 | 客户输入、供应链、产线延期都压给研发 | 指标失真，会导致研发抵触 | 强制归因，区分研发可控与不可控因素 |
| 用降本额制造贡献 | 初始 BOM 偏高，后续降本看起来很大 | 这是坏激励，甚至会影响报价竞争力 | 用目标成本和 Should Cost 做基准，项目丢失不计正贡献 |
| 只看结果指标 | 只看 DI、FPY、Reopen，问题已经发生才知道 | 管理滞后 | 加入问题前移率、失效预防覆盖率、重大风险暴露率 |
| 平台不被 BG 接受 | BG 认为平台部门不懂客户、不懂项目，只会管控 | 影响力不足 | 用试点证明、BG 共创和专家机制建立信任 |
没有公司级授权，平台部门只能做建议；授权过度，又会变成越权管理。CEO 应给它明确边界内的强授权。
本报告基于前两份 Goertek 研发行管规划和指标体系报告，并结合研发治理、系统工程、APQP、CMMI、DORA、SPACE、目标成本和 Design-to-Cost 思路整理。