简介：一份聚焦产品开发CBB（公共构建模块）管理的专业PPT课件，面向企业研发管理者与产品开发团队，以杰华公司研发管理咨询实践为基础，讲述如何通过产品开发管理确保产品的市场成功与财务成功，适合用于研发管理内训或体系导入参考。压缩包内含1个pptx文件，共31页，大小2.21MB；已有338人学习/下载。内容系统覆盖产品战略管理计划、产品开发流程管理、研发项目管理、研发绩效管理、采购物料制造产品订单交付、客户服务物流管理、供应链管理体系、项目任务书、技术开发与平台开发、技术任职资格等核心模块，并重点讲解CBB的驱动力、概念特点和应用场景，以及企业知识门户（EKP）、基于业务IT规划路标规划等支撑体系。结合杰华公司研发管理咨询的一线经验，能够帮助企业建立持续产生优秀产品的机制和土壤，提升核心竞争力。
1. CBB 公共构建模块：这份专业课件到底解决什么问题
做产品开发的人对「物料号爆炸」都不陌生：一个复杂系统动辄十几万零件，工程师为了赶进度，宁可新编号也不查旧库，结果平台之间重复造轮子。这份杰华公司的产品开发 CBB 管理 PPT 课件，正是一套把「共用」从口号变成制度的完整方法论，31 页内容从 CBB 基础概念、驱动力数据，一路讲到公共部件数据库和收益测算模型。它不是纸上谈兵，而是带着具体企业案例和量化收益公式。适合研发总监、项目管理办公室、平台架构师和负责物料精简的工程师。如果你正在被零件重用率低、供应商分散、制造成本下不去的问题困扰，这份课件值得花半小时通读，再照着里面的思路搭一套自己的 CBB 管理体系。
2. CBB 基础与驱动力：先从 54 万现役物料号的账算起
2.1 什么是 CBB，它和普通通用件不是一回事
CBB 是 Common Building Block 的缩写，公共构建模块。很多人觉得 CBB 就是「大家都能用的零件」，这个理解太浅了。课件里的定义指向更严格的东西：CBB 不是恰好被多个项目用到的零件，而是经过正式评审、被纳入优选目录、并有专门团队持续维护的共用基础模块。它和「复用」有本质区别——复用是项目层面的自发行为，CBB 是公司层面的制度化安排。
具体到操作上，CBB 有四个特征：一是定义明确，每个 CBB 必须有唯一标识和归属，谁维护、谁升级要写清楚；二是受控发布，新 CBB 进入目录要经过委员会评审，而不是设计人员私下约定；三是有退出机制，当某个 CBB 被新平台替代或技术淘汰，要走正式的注销流程，避免目录里堆满僵尸条目；四是数据打通，CBB 目录与 BOM、工程变更（EC）、物料主数据联动，不是独立在某个部门的 Excel 里。只有同时满足这四点，才能叫有效的 CBB 管理。
课件第 10～15 页在讲驱动力时也反复强调这一点：很多公司不是没有共用零件，而是共用行为没有被识别、被记录、被考核。结果是每个部门都觉得自己在用通用件，放到公司层面一看，重复造轮子的比例高得吓人。CBB 管理的第一件事，不是建立新零件库，而是把现有的「隐性共用」用制度显性化。
2.2 驱动力：一组触目惊心的数据账
课件第 12 页给了一个非常典型的复杂产品案例，数据我直接抄下来，做研发管理的看到这组数字应该会有共鸣：功能超过 12000 个，BOM 物料节点超过 103000 条，现役物料号超过 540000 个，现有产品供应商约 5000 家，其中主要供应商 1200 家，而部门间的重复利用率不足 2%。
这组数据的意义在于把「零件爆炸」量化了。54 万现役 P/N 什么概念？一个产品就算结构再复杂，真正需要差异化设计的核心器件往往不超过几千种，剩下几十万物料号里大部分是类似规格、类似功能、不同编号的「重复建设」。每一颗物料号的背后都是一连串成本：工程师选型验证要花钱，采购要谈价要管理供应商，仓库要建库位要管库存，产线要防错料要配 SOP，售后要备件要维护技术资料。
课件第 13 页继续讲了一个有意思的现象：部品间的重复利用率不足 2%。这意味着 98% 的物料号都是「一次性用品」，用完就躺在系统里成为死数据。而在另一家 IBM 的案例里，AS/400、RS/6000、S/390 这些产品线共用零件和技术模块，跨部门组织机构专门负责解决共用和重用问题，甚至共用 P/N 占比以时间轴持续上升。这说明什么？说明零件爆炸不是必然的，是可以靠组织和流程治住的。
2.3 共用基础模块流程拆解：从接口简介到 EC 管理
课件第 15 页给出了 CBB 策略的核心流程，我把关键步骤整理成一张表，方便对照自己的公司现状。
推进 CBB 的流程步骤，每一步都对应具体产出物，我整理成一张工作流清单：
| 步骤 | 关键活动 | 产出物 |
|---|---|---|
| 1 | 给开发者与供应商提供模块接口简介 | 接口规格、标准说明书 |
| 2 | 建立参考计划与联想体系 | 项目计划书、模块导航地图 |
| 3 | 构建总体管理结构/描述书 | 体系文件、组织结构图 |
| 4 | 明确开发目标并集中管理 | 项目目标、集中管理计划 |
| 5 | 软件数据解耦与选择模板 | 解耦设计、标准模板 |
| 6 | 使用风险计划表，明确例外情况 | 风险清单、例外审批记录 |
| 7 | 建立实体物料清单 BOM | 验证过的 BOM、物料台账 |
| 8 | 评审相关文档，供应用户需求 | 评审记录、需求规格说明 |
| 9 | 公共模块集中规划/管理 | 共用模块清单、维护计划 |
| 10 | 发布流程，试验与优选零件 | 试验报告、优选目录 |
| 11 | 进入数据工具管理，EC 管控 | 数据库记录、工程变更单 |
| 12 | 接收新产品需求并反馈 | 需求反馈单、新 P/N 申请记录 |
这里面最容易被忽略的是第 6 步「风险计划表」。教科书式的 CBB 会告诉你所有模块都能共用，实操里每个共用决策都有代价：共用模块可能为了兼容多个产品而增加冗余功能，单个产品的 BOM 成本会比专用零件略高。风险计划表要回答的是「这个模块一旦出问题，哪些产品会受影响，影响面多大」。没有这张表，CBB 出一次重大质量问题，管理层就会把整个策略否决掉。
第 11 步「EC 管理」是流程能持续运转的命脉。一个 CBB 的 BOM 发生变更时，所有引用它的产品都要做影响分析；反之，产品侧提出新需求时，也要先评估是否可以通过升级现有 CBB 满足，而不是新增物料号。这个双向管控做不好，CBB 目录和实际设计活动就会脱节，变成「墙壁上的制度」。
3. 公共部件数据库建设：CBB 能不能落地，就看这一步
3.1 为什么要建数据库：没有数据做支撑的 CBB 是口号
课件第 16 页开头直接点明：为了有效开展 CBB 策略，一个公共部件数据库是必须的。这句话值得琢磨。很多公司推 CBB 时先成立委员会、发红头文件，结果半年后没人当回事，原因就是缺一个能回答「这个零件是不是已有优选件」的系统。设计人员查不到，查到了也不确定数据是不是最新的，最后只能凭记忆和私人关系去问老同事。
我见过的有效做法是：先建库，再定制度。数据库不一定要上大型 PLM，先在一个能支持查询的平台上把优选件清单、部件归属、技术说明书挂上去，哪怕初期只有几百条记录。设计人员在选型时，第一步不是翻开供应商手册，而是先查优选目录；目录里没有符合条件的，才能走「新零件申请」。
课件里也给出了公共部件数据库必须包含的维度：公共特性定义、优选器件定义、供应商更新、质量、成本、供应商既有资格。注意「供应商更新」和「既有资格」这两项，很多公司的共用件清单里只有图纸号和技术规格，没有供应商状态，结果工程师选了个「优选件」，采购一查发现这家供应商已经被淘汰了，整个选型推倒重来。CBB 数据库首先是一个「活」的供应商信息源，其次才是技术规格库。
3.2 鉴别规则与公共特性：什么零件能进优选目录
课件第 16 页列了优选器件的鉴别限制：产品特性、供给、质量、成本、供应商更新。翻译成实操语言就是四条筛选规则，我一般建议客户按这个优先级判断：
第一条，功能可替代性。两个零件只要功能参数接近，就放进待选池做比对，而不是等产品线主动申报。这里需要做一次「技术特性相似度」扫描，很多 PLM 系统能做，拿不到系统支持就用 Excel 先做一轮人工比对也行。第二步，看供给。同一个零件如果有多个供应商，且都有稳定供货资格，共用风险就低很多，可以优先选入；如果只有唯一供应商，即使技术规格相同，也要谨慎共用，至少在主供应商之外储备一个备选。第三步，看质量履历。共用件最怕的是「以前没用过、一上来就大规模铺开」，风险太大。质量数据积累不足的候选件，先在小范围产品里试用，跑一两个项目周期再转正。第四步，看成本趋势。优选目录里的零件不是永久有效的，要周期性做价格复审，供应商提价超过阈值就触发重新比选。
课件还有一句很关键的话：「将公用基础模块的指标制度化，以鼓励重用与共享。」选入优选目录只是第一步，「制度化」才是让设计人员愿意用的原因。后面第 4 章我会专门讲指标和考核，这里先记住一件事：没有考核的优选目录，三个月后就会变成没人维护的死清单。
3.3 角色与权限：谁维护、谁审批、谁使用
课件里出现了两个角色：开发者（执行）和委员会/中心（指导），这是一条清晰的权责线。实际操作中我会再拆细一点，至少区分四类角色：
| 角色 | 职责 | 典型动作 |
|---|---|---|
| CBB 委员会 | 审批准入与退出 | 每月评审新候选件、处理争议 |
| 数据管理员 | 维护目录与 BOM 关系 | 更新技术状态、同步 EC |
| 设计人员 | 查询与申请 | 选型时先查目录，无果则提申请 |
| 采购/供应商管理 | 维护供货状态 | 更新价格、交期、替代供应商 |
有人会觉得委员会太官僚、拖慢节奏。我的经验是：委员会不负责日常事务，只在三个节点介入——新 CBB 转正、重大选择冲突（两个产品线抢同一个共用模块的升级方向）、CBB 退出。日常的维护和查询权限完全是开放的，谁都能查，只有修改需要权限。这个「查的开放、改的收敛」原则，比给每个人都配审批流更管用。
3.4 编码通用性与标准件：制造和服务的成本调节器
课件第 18～19 页讲了一个经常被低估的杠杆：编码的通用性和标准零件的使用，可以极大地调节下游制造和服务的成本。这里有两组数据：减少 50% 的零件数量，可以减少 3% 的基本制造成本；行业标准零件与特殊要求零件对比，减少 15% 的唯一零件，同样可以显著降低成本。
这两组数据的内部逻辑其实不复杂。零件数量减少，最直接的收益是采购端的批量采购协议——同一个零件采购量翻倍，议价能力完全不同；其次是制造运作效率提高——库存种类少了，废料率降了，防错料投入也少了。唯一零件减少，省的是定制零件的验证、制造流程、测试成本，采购效率也会跟着提升。
我见过很多公司把精力放在「减少唯一零件」上，对「行业标准件优先」反而不够重视。设计师总觉得标准件参数不满足、性能有妥协，但实际上大量非标件只是「稍微改了几下」，性能差异在系统层面根本没影响。课件强调这一点，值得每个研发管理者和设计师对照自己的 BOM 自查一遍。
4. CBB 度量指标与经济模型：收益怎么算，账要怎么记
4.1 四个关键指标：把 CBB 从口号变成可考核的事
课件第 17 页给出了四个指标，每一条都对应一个管理动作，我把它解读成可执行的 KPI：
| 指标 | 定义 | 管理动作 |
|---|---|---|
| 重用能力衡量 | 部门内零件的重复利用与其重用机会之比 | 识别「有机会用但没用」的零件，制定替换计划 |
| 有效 P/N 数量跟踪 | 当前提供的所有被使用 P/N 数量 | 每月盘点现役物料号，只减不增 |
| 优选零件百分比 | 产品中优选的零件与零件总数的关系 | 建立新产品设计评审，卡住非优选件的比例 |
| 额外费用/开发费用百分比 | 在哪些地方比竞争者花费更多，且能帮助其它部门 | 建立费用分摊机制，鼓励部门间资源共享 |
这组指标看起来简单，落地时最容易出问题的反而是第一条「重用能力衡量」。「重用机会」怎么定义？我的做法是：同一产品线内，两个以上产品用到的功能规格相近的零件，都算「有机会用」。具体由 CBB 委员会每季度跑一次数据比对，把相似零件清单打出来，交给设计团队逐条确认。一次比对会出几百条候选，比到后面会有疲劳感，所以要限定批次——每轮只处理与瓶颈零件、高价值零件相关的候选，不要追求一次性把账全算清。
4.2 经济模型 BMC：省下的每一笔钱都要落到项目里
课件第 19 页给了 BMC 的拆解模型，这是整份课件含金量最高的部分之一。BMC 收益拆成三层账：一次性的搬运节省、每年度的制造成本节省、以及库存和运营层面的间接收益。具体来说：
第一层，一次性节省。旧产品退市、旧零件淘汰时，原本要花的再设计、验证、切换成本省下来了。课件里给的案例是搬运节省超过 5000 万美元，听起来夸张，但如果你在一个多产品线的大公司待过，就知道一次平台切换涉及的工装、夹具、测试设备、SOP 更新，分分钟是千万级开销。
第二层，年度制造成本节省。来自批量采购协议谈判空间变大（同一个优选件采购量翻倍 + 供应商竞争）、制造运作效率提高（库存周转加快、废料减少）、工艺路线标准化（减少特殊工装和特殊工艺）。
第三层，库存和资金占用节省。课件里有个例子：P/N 减少 30%，结合供应链和库存管理，库存可节省超过 5000 万美元，一年+0.5 次库存周转。这还没有算「呆滞库存」和「已报废库存」的一次性清理收益。
4.3 实际案例推算：从 P/N 数量到美元收益的换算
课件第 21 页有一个具体的财务测算，我把它整理出来供参考。拿一台复杂的机电产品举例，假设：
- 总制造成本 Cogs 为 280 亿美元（注：这里应是部门或公司层面的年度总制造成本，非单产品）
- 平均库存周转次数为 5.0 次/年
- 现役 P/N 数量约 10 万个
- 通过 CBB 策略做 30% 的 P/N 数量削减
那么可以做个粗略的收益测算：
- 零件数量减少 30%，按课件「减少 50% 零件 → 减少 3% 基本制造成本」的比例，制造成本约下降 1.8%，按 Cogs 280 亿算，约 5 亿美元的年节省
- 库存周转 +0.5 次，库存资金占用对应减少，具体金额取决于库存总额，课件里给的库存节省参考是超过 5 亿美元，这个数字是含了呆滞清理的一次性效果
实际做测算时，我不建议直接照搬比例，因为不同行业的零件成本结构和制造复杂度差异太大。更靠谱的方法是：先在自己公司里选一条成熟产品线，统计出「相似功能、不同编号」的零件占比，再按单个物料号的年度持有成本（采购管理成本、仓储成本、质量成本合计）乘一下，就能得到一个管理层能理解的量级。物料号年持有成本一般可以按采购价的 10%～30% 估，具体看行业。
4.4 非 BMC 与 BMC 的成本对照
课件第 20 页有一个 Non-BMC 和 BMC 的对比，涉及人工搬运、生产控制、产品变更、验收/发票、供应商发票、紧急订单、延迟交货、存货、报废等细节。最值得关注的是「供应商发票」和「延迟交货」这两项——很多人算 CBB 收益时不看这两个科目，实际它们是隐性成本的大头。
非 BMC 模式下，采购件种类多，每一张采购订单的边际成本都高，发票对账、来料检验、问题追溯的成本是跟着物料号数量走的。BMC 模式下，优选件数量少、批量大，流程可以做成免检或抽检，发票自动匹配，处理成本大幅下降到原来的几分之一。同样的逻辑也适用于「延迟交货」：物料号越多，供应链越复杂，缺料概率越高，紧急空运成本和生产停线成本都要算进账里。做完这个全成本对比，管理层对 CBB 的收益就不会只盯着设计端那点工时节省了。
5. CBB 导入避坑与常见问题：五个高频翻车点逐一排查
5.1 数据没摊开就先选型，目录建完就是摆设
现象：CBB 委员会开完成立会，各产品线提交了一批「推荐共用件」，目录上线后实际使用率不到 10%，设计人员基本不打开。
原因：推荐清单来自各产品线自报，没有人做基于 BOM 的数据比对。自报的条目往往是「部门内部已经在用的成熟件」，而不是「跨部门真正能共用的机会点」。设计人员打开目录发现上面的零件跟自己设计的东西对不上，自然就不用。
解决：先跑数据，再造目录。用 PLM 或 ERP 导出近两年的 BOM 数据，按「物料描述相似度」和「技术参数相近」做一次全量比对，把相似零件聚成组，每组标出当前使用它的产品数量和年采购量。优先把「跨产品线、年用量大、技术状态稳定」的候选件纳入目录，而不是从部门申报开始。这一步会花 2～4 周，但比目录返工省得多。
5.2 优选目录和 EC 流程脱节，刚发布的目录就过期
现象：新件选型时，设计人员查了优选目录，选定一个 CBB 后做了方案；采购下单时发现该 CBB 的供应商已经变更，或者该件正在进行重大 EC 变更，样品还没正式定型。
原因：优选目录是静态截图，没有和工程变更（EC）管理系统打通。设计人员看到的是上个月的发布状态，而实际物料的有效性、供应商资格、版本状态每天都在变。
解决：把优选目录做成动态视图，直接对接 PLM 的 EC 主数据。设计人员查询时看到的必须是实时状态；如果有进行中的变更，系统要自动标注「变更中」并给出预计完成时间。没有 PLM 条件的小团队，至少要做到每天定时同步一次 EC 数据到 CBB 数据库，并在目录首页标注数据更新时间。这个更新频率，是目录能否被信任的底线。
5.3 指标只发统计报表，不落进项目考核
现象：每个季度 CBB 委员会发一份《共用件使用率报告》，各产品线看一眼就归档，半年过去数据没明显变化。
原因：报告里的指标只到部门层面，没有拆到项目和个人。设计人员在具体项目里选择新增专用件，没有任何成本或审批压力，报告上的数字再难看也不影响他的进度和绩效。
解决：把指标拆到项目基线。每个新项目立项时，在项目 KPI 里写清楚「优选件使用率目标」和「新增 P/N 数量上限」。项目评审时，如果新增零件超了，需要 CBB 委员会给出「是否可复用现有件」的裁决。课件里也强调：将公用基础模块的指标制度化，以鼓励重用与共享。制度化的意思就是考核，考核落到项目，行动才会变。我一般建议把「新项目优选件使用率低于 70% 的项目，需要提交专项说明」写进研发流程，这条规则比任何动员会都有效。
5.4 靠 CBB 降 BOM 成本，结果方向反了
现象：管理层期待 CBB 上线后单台 BOM 成本立刻下降，结果报表显示成本不降反升，委员会被质疑。
原因：CBB 的收益主要在「总拥有成本」，包括采购管理成本、制造成本、库存和售后成本，而不是单个零件的单价。为了兼容多产品，CBB 件的规格参数往往要满足「最大公约数」，单价可能比某个产品的专用件略高。只看 BOM 价签，很容易得出错误结论。
解决：成本看板要分两层。一层是单台 BOM 成本（用于监控），另一层是年度总成本（用于决策），包括物料数量、采购订单处理量、质量问题率、呆滞库存、工艺切换时间。导入期多给委员会一点耐心，一般 2～3 个季度后总成本曲线才会明显向下，只跑一个季度就下结论太急了。
5.5 生态链上一环没跟上，工程师选对件采购却下不了单
现象：设计人员在优选目录里选好了 CBB 件，图纸也发了，采购却反馈供应商没有维护价格协议，或者该供应商不在当前项目的合格供应商清单里。
原因：CBB 数据库管了设计端的「能不能用」，但没跟采购端的「能不能买」打通。采购主数据和优选目录是两套体系，供应商资格、价格协议、交期数据互相看不见。
解决：导入 CBB 时，采购负责人必须进项目组，且优先处理优选目录中排前 10% 的器件的供应商协议和合格状态。每周开一次「优选目录与采购主数据对齐会」，会前系统自动跑差异清单，会上只处理差异项。课件里把「供给」「供应商更新」作为优选器件的鉴别限制，就是提醒这件事：CBB 不只是设计域的工程活动，更是供应链域的采购策略。两头不打通，目录做得再精美，也只是一张挂在墙上的地图。
6. 落地进阶：把课件方法论转成内部评审清单
课件翻完，最有价值的动作是把 31 页转成一张能直接用于评审的检查清单。我按自己的习惯做了简化，你在公司里可以直接拿去改：
新产品开发项目立项时的 CBB 检查点：
- 同类功能模块是否已有优选件或 CBB 可覆盖，相关 CBB 编号是否已明确
- 若无现成 CBB，是否已提交新 CBB 申请，有没有按鉴别规则评估过共用潜力
- 新项目新增 P/N 数量是否已写入项目目标，有没有超预算预警线
- 涉及外部供应商的器件，是否已完成合格供应商确认和价格协议
- 确认共用的 CBB 当前有没有在途 EC 变更，变更是否影响本项目进度
- 方案评审时，是否已经核对过优选零件百分比，非优选件是否逐条列了理由
这份清单看起来不复杂，难在「逐条落实」。我的经验是把它嵌进现有的设计评审表单，而不是另起炉灶搞一套新流程。评审会上不发新表，就在旧的《方案评审记录》里加三个字段：CBB 编号、共用率检查结果、例外审批单号。流程变化越小，设计人员越不会抵触。
建议每个季度做一次「反向体检」：从近三个月所有新增 P/N 清单里，随机抽 30 条，一条一条追认当初为什么没有用 CBB，把原因归类（查不到、不满足、性能妥协、流程不知道）。连续做三个季度，你会非常清楚地看到自己公司的 CBB 推广到底卡在哪一环。
我从那份课件里收获最大的不是那些收益数字，而是一句话——「共用基础模块流程的目的是在不牺牲差异的情况下优化公用性和重用性」。差异化是产品的立身之本，共用是成本之基，两者不是二选一，而是靠制度设计让工程人员在做技术决策时永远先问一句「有没有现成模块可用」。从那以后，我每次给企业做导入，都强制自己把「先查目录再提新号」写进立项阶段的第一道关卡，不是作为建议，而是作为评审否决项。这个习惯帮我少谈崩了很多个项目。遇到卡壳时，别急着改流程，先问一句「设计人员第一次打开这个目录时，能不能在 30 秒内找到他要的东西」。能，就跑得起来；不能，再好的制度都要先解决这个问题。希望帮到你。
本文还有配套的精品资源，点击获取
