研发管理平台部门三年规划
Goertek 研发行管体系建设报告
面向消费电子制造业复杂客户、复杂产品、复杂研发模式的公司级研发治理方案。核心不是替代 BG 管理研发，而是以方法、数据、平台、专家和专项，持续提高研发效率、研发品质和跨 BG 复用能力。
研发行管部门的价值，不是把各 BG 的研发流程统一成一种样子，而是把公司级可复用的“共性能力”做厚：把问题识别出来，把方法跑通，把工具和数据建起来，把最佳实践推广出去。
定位
公司级研发治理中枢
对 BG 研发不做替代管理，不越过业务责任链条；通过制度框架、专项机制、专家网络、数据看板和平台资产，形成跨 BG 的协同牵引。
抓手
从共性痛点切入
聚焦需求变更、样机迭代、设计评审、DFx、试产问题、经验复用、工具链、项目风险等高频痛点，用 3 到 5 个试点专项打出可信样板。
结果
形成研发操作系统
三年内沉淀公司级流程资产、知识资产、复用资产、指标资产和专家资产，使研发管理从“靠人盯”走向“机制化、数据化、平台化”。
1009.54 亿
2024 年营业收入，来源：Goertek 2024 年报
45.69 亿
2024 年研发投入，研发投入占营收 4.53%
12,568 人
2024 年研发人员，占员工总数 15.36%
3 大业务
精密零组件、智能声学整机、智能硬件
说明：以上为公开披露数据的管理解读。报告中涉及内部目标、基线和 BG 差异的数据，均以“建议内部补充”或“建议区间”呈现，需由公司内部经营与研发数据校准。
Context
Goertek 业务与研发治理挑战
Goertek 的研发不是单一产品研发，而是面向全球头部客户、多个产品族、复杂制造转化和多种合作模式的系统工程。研发平台部门要管理的是共性规律，而不是消灭差异。
公开资料呈现的业务特征
- 产品覆盖声学、光学、微电子、结构件等精密零组件，以及 VR/MR/AR、AI 智能眼镜、智能耳机、智能穿戴、游戏及智能家居等智能硬件。
- 业务模式包含 ODM、JDM 等，与全球领先科技及消费电子客户深度协同。
- 公司强调“精密零组件 + 智能硬件”战略，以及垂直整合、系统集成、自动化、精密制造和全球研发网络。
- 2026 年官网新闻显示，Rongcheng Goertek 获得 CMMM L4 认证，GPS 正向研发、生产、供应链全链条智能制造生态延伸。
研发治理的四个天然难点
- 客户牵引强：美系、日韩、国内客户在需求冻结、评审方式、变更节奏、保密规则和里程碑上差异很大。
- 业务模式差异大：OEM 更强调客户输入与制造交付，ODM 更强调方案与设计责任，JDM 更强调联合定义与共同迭代。
- 软硬件耦合增强：AI、声学算法、传感器、光学、结构、制造工艺和测试验证同步演进，传统串行流程不够用。
- 平台部门无直线管辖：不能靠命令推动，必须通过公司授权、试点成效、数据透明、BG 共创和专家影响力推进。
问题诊断框架：从项目表现追到系统原因
效率
周期与节奏
样机轮次多、评审等待长、需求反复、跨专业协同慢、关键问题后移到 EVT/DVT/PVT 或量产。
品质
设计成熟度
DFMEA、设计评审、仿真验证、测试覆盖、失效复盘与前端质量策划不足，导致问题在试产和量产暴露。
复用
知识和模块
跨 BG 问题相似但知识分散，模块、物料、测试方法、工艺经验和客户经验未充分资产化。
经营
数据和决策
研发成本、资源负荷、项目风险、质量问题、复用收益缺少统一口径，导致管理层难以看见研发治理贡献。
消费电子研发治理应借鉴多个体系，但不能机械套用。正确做法是把成熟方法拆成可执行的管理原则，再结合 ODM/OEM/JDM 和客户差异做裁剪。
ISO 56002
创新管理体系
适合指导公司建立创新方向、组合管理、资源保障、知识管理和持续改进机制。对 Goertek 的启示是：研发治理不能只管项目交付，还要管理创新能力的系统性。
ISO/IEC/IEEE 15288
系统生命周期过程
适合构建统一的需求、架构、设计、集成、验证、确认、风险、配置、度量和质量保证过程。对复杂智能硬件尤其重要。
APQP / DFMEA / PPAP
前端质量策划
适合把质量问题前移到设计和过程策划阶段。消费电子可以借鉴“特殊特性、失效预防、验证计划、过程能力、量产批准”的思想。
CMMI
过程成熟度
适合把研发管理从依赖个人经验推进到可定义、可度量、可优化。重点不是认证，而是用成熟度评估识别 BG 间差距和改进路径。
Stage-Gate / NPI
里程碑治理
适合建立跨专业决策点，但必须避免形式化。Gate 要有“进入条件、退出条件、风险清单、例外机制和决策权”。
Digital Engineering
数字工程和知识资产
适合把需求、BOM、仿真、测试、问题、变更、制造数据打通，形成可追溯的研发数据链和可复用的知识库。
行业经验转化为 Goertek 的 6 条原则
最小统一：统一过程框架、术语、度量口径和关键交付物，细节允许 BG 裁剪。
客户适配：按客户风格、业务模式、产品复杂度、项目风险定义流程裁剪包。
问题前移：把质量策划、失效预防、验证充分性和制造可行性放到前端决策。
数据牵引：用同口径数据看趋势、看异常、看对标，不以填表数量评价研发。
试点证明：先在高痛点项目上做出改善，再用数据和案例推广。
资产沉淀：每个专项都必须沉淀为模板、清单、案例库、模块库或平台能力。
Mission & Boundary
使命、边界与组织机制
平台部门的组织设计要回答一个关键问题：没有直线管辖权，如何产生真实影响力。答案是建立“公司授权、BG 共创、专家共治、数据公开、专项闭环”的矩阵机制。
研发行管部：方法、数据、平台、专家、专项的公司级中枢
研发治理与流程架构
研发效率提升
研发品质提升
共性能力平台
研发数据经营
应该做什么
- 定义公司级研发管理框架、关键流程、核心指标和评审机制。
- 牵头共性问题诊断，组织跨 BG 专项，沉淀最佳实践。
- 建设研发知识库、失效模式库、模块复用库、评审清单和方法工具。
- 组织专家委员会，对高风险项目、重大技术决策和共性质量问题提供评审支持。
- 向经营层呈现研发效率、研发品质、复用收益和风险趋势。
不应该做什么
- 不替代 BG 项目经理、研发负责人和业务负责人承担交付责任。
- 不把所有 BG 流程强制统一成单一版本，避免伤害客户适配能力。
- 不以检查、排名和表格作为主要价值，避免被视为行政负担。
- 不越过业务链条直接干预客户承诺、商业取舍和资源优先级。
- 不追求短期制度堆叠，而要追求问题解决和资产复用。
建议组织机制
| 机制 |
参与方 |
主要职责 |
运行节奏 |
| 公司研发治理委员会 |
公司高层、平台部门、BG 研发/质量/制造/运营负责人 |
批准研发治理框架、年度专项、指标口径、重大争议和资源协同事项 |
季度 |
| BG 研发联络人机制 |
各 BG 指定研发管理接口人 |
共创流程裁剪、提供数据、组织试点、反馈执行问题 |
双周或月度 |
| 公司级专家委员会 |
声学、光学、电子、结构、软件、测试、工艺、质量专家 |
重大技术评审、失效复盘、方法共创、人才培养 |
按项目节点 + 月度专题 |
| 专项战队 |
平台部门牵头，BG、品质、制造、采购、IT 参与 |
围绕高痛点问题开展 8 到 12 周攻坚，形成可复制方案 |
项目制 |
三年规划的节奏应是“先诊断和试点，再固化和推广，最后平台化和经营化”。短期要让高层看见价值，中期要让 BG 愿意采用，长期要让体系自运行。
0-12 个月｜建立基线与试点证明
短期：从看见问题到跑通样板
- 完成主要 BG 研发流程、项目类型、客户差异、问题清单和数据现状诊断。
- 定义公司级研发指标字典和最小统一流程框架。
- 选择 3 到 5 个高痛点专项试点，优先覆盖需求变更、设计评审、试产问题、复用库和项目风险。
- 建立月度研发经营看板雏形，形成首批可复用模板和案例。
阶段成果：一套基线、一批试点、一个看板、一组模板、一份高层季度报告。
12-24 个月｜制度固化与规模推广
中期：从试点改善到组织能力
- 把试点经验固化为流程裁剪包、评审清单、质量策划模板和专家评审机制。
- 在主要 BG 推广，建立 BG 研发成熟度年度评估。
- 打通研发问题库、变更库、测试库、模块库和项目看板的关键数据。
- 形成公司级研发专家网络和专题训练营，提升中基层研发管理能力。
阶段成果：制度化工具包、BG 对标机制、专家网络、数据平台一期。
24-36 个月｜平台化与持续优化
长期：形成研发操作系统
- 建立公司级研发操作系统：流程资产、知识资产、复用资产、指标资产、人才资产。
- 形成跨 BG 研发资源与技术平台协同机制，支持战略客户和新产品方向。
- 将研发质量、效率、复用和风险数据纳入经营管理闭环。
- 对高成熟 BG 推行预测性风险预警、数字孪生验证和 AI 辅助工程知识检索。
阶段成果：研发管理平台化、经营指标闭环、最佳实践持续复制。
专项不是“活动”，而是平台部门创造结果的基本单元。每个专项都必须有业务痛点、试点项目、明确产出、量化指标和推广路径。
建立公司级 NPI/研发阶段、关键 Gate、交付物、评审角色和例外处理规则，同时发布 OEM/ODM/JDM 裁剪包。
牵头：平台部门 + BG 研发管理接口人
BG 协同：选取代表性项目验证裁剪包
产出：流程地图、Gate 清单、RACI、裁剪指南
指标：Gate 一次通过率、流程例外闭环率
对客户需求、内部需求、规格变更和工程变更建立分级管理，减少后期返工与跨专业扯皮。
牵头：平台部门 + 项目管理 + 客户接口团队
BG 协同：提供典型客户变更案例
产出：需求冻结规则、变更影响评估模板
指标：后期变更占比、变更响应周期、返工工时
把设计评审从“会议确认”升级为“证据评审”，明确每阶段需求、架构、结构、电声、光学、软件、测试、制造可行性成熟度。
牵头：平台部门 + 专家委员会
BG 协同：参加跨 BG 同行评审
产出：DR checklist、成熟度评分卡、评审缺陷库
指标：评审发现率、问题前移率、试产重大问题数
质量前移
DFMEA / PFMEA / 控制计划贯通
04
借鉴 APQP 思想，把产品失效、过程失效、特殊特性、测试验证和量产控制计划连成闭环。
牵头：平台部门 + 品质 + 制造工程
BG 协同：选高风险产品做样板
产出：FMEA 标准模板、特殊特性清单、控制计划
指标：失效预防覆盖率、量产导入问题 PPM、8D 重复发生率
围绕声学、光学、传感器、SiP、结构、算法、测试夹具和验证方法，建立可查询、可评价、可复用的资产库。
牵头：平台部门 + 技术平台 + 采购
BG 协同：贡献成熟模块和禁用经验
产出：模块库、优选物料库、测试方法库、复用规则
指标：复用率、非标物料比例、验证周期缩短
建立高风险项目预警模型，覆盖需求稳定性、技术新颖度、资源负荷、供应链成熟度、客户节点压力和历史问题相似度。
牵头：平台部门 + PMO + IT
BG 协同：维护项目状态和风险项
产出：风险评分卡、红黄灯看板、升级机制
指标：风险提前识别率、重大延期项目占比
试产转化
EVT/DVT/PVT 问题闭环专项
07
把试产问题按设计、工艺、物料、测试、供应商、客户输入分类，推动问题前移和重复问题治理。
牵头：平台部门 + 制造 + 品质
BG 协同：提供试产问题和量产导入数据
产出：问题分类字典、复盘模板、经验库
指标：PVT 遗留问题数、重复问题率、量产爬坡达成率
统一研发项目、需求、问题、变更、评审、测试、成本、资源和复用指标口径，搭建月度经营看板。
牵头：平台部门 + IT + 财务经营
BG 协同：确认口径并接入数据源
产出：指标字典、数据责任人、看板原型
指标：数据覆盖率、数据及时率、管理动作闭环率
面向项目经理、技术负责人、专业经理和新任研发管理者，建立研发治理方法、系统工程、风险管理和质量前移训练体系。
牵头：平台部门 + HR + 专家委员会
BG 协同：推荐学员和内部讲师
产出：课程地图、案例库、认证机制
指标：认证人数、项目应用率、学员项目改善案例数
建立“发现、验证、包装、推广、复盘”的最佳实践机制，让优秀 BG 的经验能被其他 BG 低成本采用。
牵头：平台部门 + BG 联络人
BG 协同：提供案例并接受复制辅导
产出：案例手册、复制清单、现场辅导机制
指标：复制项目数、复制收益、采用满意度
研发指标要少而硬。建议采用“结果指标 + 过程指标 + 能力指标”的三层结构，并坚持同口径、趋势化、可行动，避免把研发团队拖入低价值填报。
| 维度 |
核心指标 |
管理含义 |
第一年建议目标 |
| 研发效率 |
项目周期达成率、关键 Gate 通过率、变更响应周期、评审等待周期、样机轮次 |
看研发节奏和跨专业协同效率 |
先建立基线；试点项目相对基线改善 10% 到 20% |
| 研发品质 |
设计评审问题前移率、EVT/DVT/PVT 重大问题数、重复问题率、量产导入遗留问题 |
看质量是否从试产和量产后移到设计前端 |
试点项目重复问题下降 20%；重大问题前移率提升 |
| 复用能力 |
模块复用率、优选物料使用率、测试方法复用率、知识库命中率、非标设计占比 |
看跨 BG 资产能否转化为速度和质量 |
建立资产库；选择 2 到 3 类高价值模块形成复用样板 |
| 项目经营 |
研发资源负荷、研发成本偏差、风险红灯项目占比、重大风险提前识别率 |
看研发是否纳入经营节奏，而不是只在延期后补救 |
形成月度看板；高风险项目 100% 有闭环措施 |
| 体系成熟度 |
流程裁剪符合率、数据覆盖率、专家评审覆盖率、专项闭环率、BG 成熟度评级 |
看平台部门建设的是能力体系，不是一次性运动 |
完成主要 BG 基线评估；形成成熟度雷达图 |
高层驾驶舱
季度呈现趋势、异常、专项收益、BG 对标和需高层协调事项。关注“公司研发能力是否变强”。
BG 管理看板
月度呈现项目风险、效率瓶颈、问题闭环、复用机会和跨部门协同事项。关注“BG 怎样更快更稳交付”。
专项作战看板
周度呈现试点项目、问题清单、行动负责人、收益假设和验证数据。关注“专项是否产生真实改善”。
研发治理转型最容易失败在两个地方：第一，平台部门被视为增加负担；第二，制度写得完整但项目现场不用。解决办法是小步快跑、试点证明、结果换授权。
年度推进节奏
- 1 月：确认年度研发治理主题、专项清单、试点 BG 和高层 sponsor。
- 每月：研发经营看板例会，跟踪指标异常、专项进展和跨部门阻塞。
- 每季度：治理委员会评审阶段成果，批准推广范围和资源协同。
- 每半年：BG 研发成熟度评估和最佳实践发布。
- 年底：形成研发治理白皮书，沉淀制度、工具、案例和下一年度路线图。
资源配置建议
- 平台部门应设置流程架构、数据分析、质量前移、项目治理、知识平台和专项 PM 六类角色。
- 每个 BG 配置固定联络人，纳入 BG 研发负责人绩效或年度目标协同项。
- 专家委员会成员采用兼职机制，但对重点评审和专项贡献设置可见激励。
- IT 资源不宜一次性大平台化，第一年优先做轻量数据看板和知识库原型。
主要风险与应对
| 风险 |
表现 |
应对策略 |
| BG 抵触 |
认为平台部门不了解客户和项目现场，只会增加流程负担 |
以试点改善换信任，先解决 BG 最痛的问题；制度共创，避免单向发布 |
| 指标失真 |
指标口径不统一，团队为指标优化而非为结果优化 |
先建指标字典和数据责任人；只选少量高价值指标；强调趋势和行动 |
| 专家不可用 |
专家忙于项目交付，评审和复盘无法持续 |
把专家评审纳入公司级机制，明确时间窗口、贡献记录和激励方式 |
| 系统大而慢 |
一开始追求完整数字化平台，迟迟无法落地 |
先用轻量看板和知识库承载试点，第二年再逐步系统集成 |
| 客户差异被忽略 |
统一流程无法适配不同客户保密、评审、变更和交付模式 |
发布客户和业务模式裁剪包，把“允许差异”写进治理框架 |
本报告基于公开资料与行业方法论形成规划建议。涉及 Goertek 内部组织、客户、项目和指标的数据，需由内部数据进一步校准。
关键术语
- OEM：Original Equipment Manufacturing，通常客户定义产品和规格，供应商承担制造或部分工程支持。
- ODM：Original Design and Manufacturing，供应商承担更多设计方案和工程实现责任。
- JDM：Joint Design and Manufacturing，客户与供应商联合定义和设计，协作边界更复杂。
- EVT/DVT/PVT：工程验证、设计验证、生产验证，是智能硬件 NPI 中常见的阶段划分。
- DFx：Design for X，包括可制造性、可测试性、可靠性、成本、装配、供应等设计约束。
内部建议补充数据
- 各 BG 研发项目数量、项目类型、客户结构和阶段分布。
- 研发人员专业结构、资源负荷和关键专家瓶颈。
- EVT/DVT/PVT 问题、量产导入问题、客诉和重复问题数据。
- 需求变更、工程变更、试产返工、物料非标和复用率数据。
- 现有 PLM、ALM、MES、QMS、ERP、知识库等系统边界和数据质量。