格致GEZHI · GZ
3F · 工作室工作室

只放完全自己做出来的东西:平台级项目、飞书技能包、技术点拆解,外加一篇平台白皮书。

工作室UNIT S16 · CBB 货架:共享率 80%,卡住重复开发的那条红线

STUDIO · SPEC SHEET · UNIT S16

CBB 货架:共享率 80%,卡住重复开发的那条红线

品类管理方法设计 胡安更新于 2026-09

角色机制设计参与者
场景CBB 货架 / 立项管控
技术栈共享率算法 · 多方案选择 · 生命周期管理
成果共享率接进立项审批,多方案报告一键生成
封面:CBB 货架,共享率 80% 的立项红线
图 · S16 · CBB 货架
细腰型架构:上端市场牵引、下端技术支撑,产品和平台居中收敛
图 · 细腰型架构:多个产品系列共用一个产品平台,多个平台沉淀核心技术

为什么复用喊了多年落不了地:开发和开发没有分开

每个制造企业都喊复用,多数企业复用不起来的原因很简单:组织里只有"产品开发"这一种开发。客户要什么就开发什么,每颗物料、每块板卡都为单个产品而生,项目一结束就开始下一轮重复劳动。

业界引入 IPD 模式的头部公司给出过一组被反复引用的数据:把产品开发和技术开发分离、大量使用共享平台之后,平均开发周期缩短 40%,产品故障率从 17% 降到 1.3%。数字未必能直接搬到每个行业,但逻辑是通的:技术开发的任务是构建技术平台、形成技术储备和货架技术,主动引导产品开发;产品开发的任务是用成熟的技术和平台快速、低成本地满足客户需求。两条线分开跑,共享才有载体。

结构上这就是所谓的细腰型架构:上端是市场牵引,客户需求汇聚成产品系列;下端是技术支撑,核心技术沉淀成产品平台;中间的"腰"就是产品平台——收得越细,两端越活。

五个名词讲清货架体系

货架七层:系统、子系统、整机、单机、组件、单元、器件,平台是 CBB 的集合
图 · 货架七层结构:整机面向客户,整机以下面向内部共享

聊机制之前先把五个名词说清楚,一套体系能不能落地,往往就卡在大家说的不是同一件事。

BB(构建模块)是系统中实现特定功能、具备接口要素和规格的实体单元;CBB(公共构建模块)是可以在两个或两个以上产品中直接应用的 BB——注意"两个以上"这条线,只在一个产品里用的东西不叫 CBB。合格的 CBB 要满足五条:共用性、可集成,界面清晰,功能和性能指标明确,可维护、可测试,有完善的资料手册。

货架是把公司所有产品和技术按层级结构统一管理起来,产品开发时先参考货架、最大程度共享,减少重复开发;平台是一系列 CBB 在各层级上的集合;产品树则是按照系统、子系统、整机、单机、组件、单元、元器件七个层次自上而下分解出的产品结构——以电视为例,整机(面向细分客户群)往下是单机(模组屏、主板、电源板、遥控器),再往下是组件(背光组件、WIFI 模块)、单元(LED 灯条单元、功放单元)、器件(电阻电容),整机以下的部分全部面向内部共享。

共享率:给复用装上仪表盘

共享率算法:按产品树逐层计算,货架有成熟 CBB 记为共享
图 · 共享率算法:每个层次各模块权重相等,逐层汇总成整机共享率

有了货架和产品树,共享就能被度算了。规则不复杂:按产品树分解,每个层次各模块权重相等,货架上有成熟 CBB 的记为共享,否则不共享;逐层汇总算出硬件共享率,整机共享率取硬件和软件共享率的平均。一个实际项目的算例:第一层共享率 3/6,第二层综合 79.4%——每个数字都能追溯到具体模块。

度算本身不是目的,共享率的用处是那道立项红线:不满足 80%(阈值依企业实际定制),不允许产品立项,必须先导入 CBB 开发计划。复用从"提倡"变成"门槛",行为才开始改变。我们踩过的坑恰恰在这里:货架建好之后一度没人主动用,直到把共享率接进立项审批——产品包需求评审的流程里增加了一道审核,共享率不满足要求不予审批,货架的使用率才真正起来。

报告是另一件武器。每个新品在策划阶段生成多方案选择报告,逐模块列出选型、CBB 编号和共享率;没有填写或无 CBB 可用的类别自动标红,必须补充完整并注明技术路径和未共享原因。一份典型报告里,主板、遥控器、电源、模组屏的模块共享率都是 100%,硬件套件 60%、外观结构套件 80%,整机共享率合计 88.57%;摄像头、远场语音板、底座三处标红"无成熟 CBB 需新开发",分别注明了新开成本上限和替代材质计划。

多方案选择报告:整机共享率 88.57%,未共享模块标红注明原因
图 · 一份 88.57% 的多方案选择报告:标红处就是下一批 CBB 开发计划

一颗 CBB 的一生

CBB 开发流程:四个来源、三个阶段、一个业务决策点加三个技术评审点
图 · CBB 的一生:四个来源进池,三个阶段开发,上架后进入生命周期管理

CBB 从哪来?四个来源:产品开发中识别的价值模块、技术规划输出的预研成果、外购成熟件,以及成熟产品的后向梳理。四条线汇进 CBB 资源池,经过成熟度评估后上架。

CBB 怎么开发?三个阶段:策划阶段完成需求输入审批、需求分析和开发任务书编制,出口是立项决策评审——这是整个流程唯一的业务决策点;计划阶段完成方案设计,出口是概要设计评审;开发阶段完成 CBB 开发和验证,先后通过样机及验证应用评审、CBB 上架评审。一个业务决策点加三个技术评审点,一颗 CBB 才算长成。

上架不是终点。CBB 的交付成熟度有明确清单:设计资料(原理图、软件代码)、模块和样机测试报告、产品验证项目上的验证报告、使用说明书和工艺技术文件;公研与产品线的交付界面也提前写清——公研负责开发、测试和上架管理,产品线负责在策划阶段做需求分析、接收 CBB 做接口适配和参数调试、监控使用并反馈问题。最硬的一条是上架门槛:CBB 要通过两个产品项目的验证后才能正式上架发布——第一个项目验证功能,第二个项目验证可复制性。

组织跟上,规则才不空转

制度设计得再细,没有组织承接就是空转。我们的做法是设 CBB 管理部,职能覆盖货架全部板块:策划阶段整合需求、识别共性技术、起草开发任务书;计划与开发阶段组织技术评审、识别成熟度、协调资源保障进度;生命周期阶段管理上架、变更、下架并评估使用情况——对 CBB 交付的质量、成本、进度整体负责。开发侧则按货架板块设置科室,主板、电源、遥控器、音响各有人负责,货架上的每一格都有主人。

落地过程里最典型的一场硬仗是扬声器:功率档位从低端到高端分了好几档,各平台内部空间又不统一,结构尺寸五花八门。对策是三步——功率分段合并,8W 档并入 10W、15W 档并入 18W;每个档次做结构标准化设计,输出《扬声器标准化设计规范》;再跟产品规划对齐,把各市场的性能需求统一。五个产品线的扬声器需求,最终用一个新开发的 18W 模块覆盖掉三个系列。

回过头看,货架体系就是把复用从文化变成机制:共享不是美德,是数学;货架不是仓库,是菜单;共享率不是考核指标,是立项门槛。

金句卡:共享率不是考核指标,是立项门槛
图 · 把复用写进立项条件,货架才会真正被用起来