研发数字化管理学习笔记

讲座主题：研发数字化管理主讲人：陈南峰老师学习目的：理解研发数字化的全貌，看清“两张皮”问题的根源，思考如何系统性地构建研发数字化能力

• 需求不仅仅是功能，还包括质量（Q）、成本（C）、交付（D）、架构与接口等非功能性要素。

2. 研发数字化管理的核心对象讲座中用一张“宏观矩阵图”展示了研发管理的两大维度：

• 横轴：产品全生命周期（规划 → 研发 → 测试 → 上市 → 退市）

• 纵轴：研发管理要素（需求、报告、工作记录、BOM、CBB、物料标准化、状态管理等）

管理启示：任何一个管理体系（如IPD、ISO9000、AOS、MBSE）都只覆盖了其中一部分要素。企业如果只引入单一体系或单一软件，必然存在遗漏或重复，形成“管理孤岛”。

二、关键洞察：软件多、孤岛多、研发人员“伺候不过来”

1. 软件生态复杂，难以协同企业通常需要多个系统协同工作：

• PLM / PDM：产品数据管理

• 项目管理软件（PM）：项目计划与跟踪

• 需求管理软件（如DOORS）：需求追溯

• 工业设计软件（CAD等）：机械、电子、软件设计

• 实验室管理（LIMS）：测试与验证

• MBSE工具：基于模型的系统工程

2. 现状问题

• 研发人员在不同系统间反复切换、数据导入导出，体验极差

• 很多企业最终回到Excel表管理项目，系统“用不起来”

• 管理层关注的流程（如IPD）与研发人员实际执行的工作（底层设计、建模、测试）脱节，形成“两层皮”

管理启示：数字化不是“买系统”，而是打通系统、统一要素、协同流程。系统选型与集成必须基于业务本质，而不是部门需求点状发起。

三、系统架构：研发数字化的理想结构

讲座中提出一个清晰的分层协同架构：

管理启示：数字化平台不是“一个大系统”，而是分层协同、数据贯通的体系。流程管理要转化为可配置的模板、任务、交付物，而非在OA中跑审批。

四、状态与构型管理：复杂产品研发的“底线”

1. 概念理解

• 构型管理（民机术语）≈ 技术状态管理（军机术语）

• 核心思想：在产品全生命周期中，确保产品的物理特性与功能特性始终与需求、设计保持一致

2. 五大活动

1. 构型管理策划

2. 构型标识（识别构型项、命名、版本）

3. 构型更改控制（变更必须评审、受控）

4. 构型状态纪实（记录每一次变更）

5. 构型审核（验证一致性）

3. 通俗比喻

• 就像在项目关键节点“拍照片”，一旦拍下（基线确立），就不能随意改动。若要修改，必须从“照片”处重新走流程

• 适用于复杂系统（飞机、发动机、大型装备），防止“改一处、乱一片”

管理启示：对于产品复杂、变更频繁的企业，构型管理不是“高级选项”，而是质量与安全的底线。数字化平台必须支持基线、版本、变更追溯。

五、管理层行动思考

1. 判断企业所处阶段

• 是否仍在用Excel管理研发项目？

• 是否多个系统“各自为政”，研发人员抱怨？

• 是否存在“流程与执行两层皮”？

2. 推动研发数字化的关键原则

• 先梳理业务要素，再谈系统选型：不要被厂商引导“买系统”，而是先明确研发管理要素矩阵

• 以项目管理为核心：需求、任务、交付物、成本、资源统一在一个平台中管理

• 打通设计与数据：PDM是桥梁，上面接项目管理，下面接工业设计软件

• 逐步建立构型管理能力：从需求基线、BOM版本、变更控制开始，逐步推进

3. 组织与流程的配合

• 流程人员与IT人员需要共同理解业务对象与数据模型，而非简单“把流程搬到OA”

• 研发人员不是“伺候系统”，而是系统服务于研发，否则数字化必然失败

六、个人思考与后续关注

1. 本次讲座最受启发的三点

• 研发数字化不是“买软件”，而是构建要素、流程、系统协同的体系

• 很多企业“两层皮”的根本原因在于管理层关注流程，执行层关注设计，中间缺乏数据贯通

• 构型管理是复杂产品研发的质量控制核心，也是数字化深水区的关键能力

2. 后续可关注的行动方向

• 审视本企业研发管理要素的完整性与系统协同性

• 评估当前研发项目管理的实际执行方式（是否仍依赖Excel）

• 探讨是否需要在构型管理、需求追溯、变更控制等方面加强数字化支撑