CBB相关定义
运用产品和技术共享平台实现知识重用，可快速、高质量地满足客户需求。构建CBB应同步建立技术和产品货架，建立产品成熟度评估标准，建立鼓励平台形成和使用的机制。
CBB通过评审验证后可进入CBB资源池。CBB的数据形式为产品文档、图纸、代码等，内容涉及电子元器件、标准件、组件、单机、整机、子系统、系统等。CBB应融合PDM、软件工程化管理、项目管理等第三方应用系统，创建高效易用的信息化平台。借助CBB平台，用户可以快速形成由共享单机、整机或模块组合形成的新产品，按层次分类形成产品货架，研发模式由串行开发模式转向以CBB为核心的异步开发模式。
既然谈到CBB，自然离不开标准化和模块化的中心思想，同样绕不开流程建设的实现方式。对于大公司平台而言，有各式各样的ERP/OA系统对产品实现流程进行管束，但系统间的融合互通建设是个让人头大的工程。小公司平台不够完善或压根缺失，但胜在灵活，“船小好掉头”，CBB的实现方式可能不够规范，但更易于实施和推进。
CBB的理念对于工程设计人员而言更易于解释：硬件工程师可以打开绘制原理图的PADS/AD工具，绘制一个摄像头组件的原理图，之后将其封装成一个标准组件，供其后的各个项目调用。而调用者只需将其关注I/O接口，不必了解内部电路实现用的是哪个厂商的芯片、镜片、线缆；软件工程师更不必说，子函数/库文件的调用信手拈来，CBB的概念早已根深蒂固。
CBB平台设计
CBB平台应按照“总体规划、分步实施”的原则进行设计开发。从建立元器件、标准件和成熟部件、组件的共享共用入手，取得成功后再升级到更高应用层次。
志存高远，脚踏实地。CBB与软件工程中逐层封装的理念高度一致，再复杂再精密的机器设备都从做好每一颗螺丝钉开始，每一颗螺丝钉都需要进行反复的打磨验证。顶层规划说到底，还是标准化和模块化设计的高度统一。然而道理每个人都懂，做起来依然呵呵。CBB体系的推进，一方面需要组织架构的保证，老板充分信任，放权力挺。对其而言意味着额外的金钱、时间、精力的投入，没有花钱的不是，这玩意好归好，但短期内难见成效，花现下的钱省将来的事，人手跟钱都赌在将来了，现在的订单怎么办，赚不到钱怎么发工资，老板也得恰饭对不；另一方面，需要宣贯到位，每个环节的负责人、执行人都理解支持。光图将来省事了，手头的活还的干不是？客户电话还得接，现存BUG还得解，平白增加了一摊事，工资又不给涨，现在的996直接升格到ICU了，一家老小谁来养？
规划设计
考虑现有的成熟模块和PDM系统平台，参考行业发展趋势，并结合企业内部产品技术创新的要求进行CBB规划。首先对现用的基础数据进行必要的整理、分类和审核，进行标准化和模块化工作。根据产品路标规划和技术路标规划，归类需求，编制CBB规划框架和应用指南。在PDM平台上开发配置CBB开发流程，设置关键流程节点，设置角色，定义角色职责，制定CBB流程模板和规范。
IPD流程不是每个企业都玩的起，但不意味着没有IPD就来不了事。这年头凡事不加个智能、AI的前缀总觉得少那么些逼格。既然大家都是玩互联网的，搭建个内部服务器总不是个难事吧。但凡能开个word，再不济装个WPS，写点规章制度放上去大家围观围观也至少算走了个形式了。你说没有电脑？有了电脑也不会用？得，老干部们，发个红头文件盖个戳总可以不是？
方式方法这些细节问题解决了，下一步就是规划文本了。毕竟研好了墨架好了笔咱总得留点啥墨宝不是？
不忙下笔，先做些准备工作热热身。对产品经理们来说，产品的序列梳理合并，共有特性的提炼，特性功能块的分割必不可少；对开发攻城狮和程序猿们来说，组件/模块的标准化的做，该有的验证和测试同样得一个不落；供应链兄弟们，做好准备迎接一轮来自供应商的暴风骤雨吧；老板/总监们一样得身先士卒，为萝卜们刨好坑配好活顺带着一轮组织优化美滋滋。
基本功能
基于PDM平台进行CBB的开发设计，基本功能包括：分类属性、权限划分、查询等。
不免想起做研发时陪着测试兄弟们开发测试工具的时光，单纯的日子现在想来还是比较快乐的。工具顺不顺手用起来就知道了，工欲善其事必先利其器，现在想得周全些，总好过日后扯皮。
CBB分类与属性定义
每一类型CBB都区分关键特性，在PDM中称之为属性，将分类和属性固化到PDM中，PDM对必填属性做出约束，否则不允许创建CBB。
就算是老干部们打印红头文件，到头来也得知道往哪个铁皮柜里塞不是。
CBB信息权限划分
CBB信息分为通用信息和授权信息。通用信息对所有人开放，授权信息只有获得权限的人员才能使用。
嗯，论阶级的诞生。
CBB查询界面定制
支持按类别搜索，确定类别后自动显示与该类别相关的属性搜索框。支持模糊搜索，输入特定字符和通配符，在所有类别中检索。
找东西时还是免不了倒腾铁皮柜子。
CBB关联信息查询使用
相关设计规范、检验规范、技术文件是CBB引用不可缺少的内容，只有整体引用才能发挥应有的作用。建立CBB关联信息模型，并提供相应的检索手段。
就算是螺丝钉，也得按图纸加工。
CBB被共享查询
查询CBB被使用情况，为综合分析该CBB可用性、适用性提供佐证数据，供使用者参考选择。
螺丝钉不但得有制造图，还得有使用说明书，领用记录同样得配上。
维护开发
根据外部的技术发展变化和内部产品技术开发团队等反馈的意见，对预研、产品开发、技术开发等环节发现的CBB需求和问题记录进行汇总、分析，适时更新CBB规划与指南。
CBB维护开发的主要任务有：定义CBB需求与问题管理规范、定义CBB变更管理规范、开发配置CBB问题审批流程模板、开发配置CBB更改管理流程模板、开发CBB批量更新功能等。
话说好容易说服老板写出来CBB这么个大BUG，咱还得持续优化对吧。上帝创造世界也不是一天完成的，来事也得讲究些方法论，一次性把活都干完了等着被优化？不找点由头年底凭啥跟老板要年终奖？努力开发吧，持续不断地创造BUG搁谁来说都是本职工作。
绩效考核
将CBB的绩效指标量化，以鼓励共享和重用。根据TR规则，在产品开发的个过程和环节对执行CBB的情况进行考核，重点考核优选率和复用率。定期统计CBB绩效指标，编制CBB执行报告。
CBB的绩效考核可通过报表方式实现，主要有：
终于到了激动人心的环节了！干了这么久的活，终于可以开口向老板要钱了！
CBB 引用情况统计报表
分析CBB复用情况和被引用统计数据，评估其对设计开发的贡献度。
没说的，谁家论坛不整点积分兑换？但是不同于苏人们搞得那一套，灌水行骗那套在这里可行不通。
CBB 使用统计报表
特定产品CBB使用统计记录，以利于对产品型号通用化率和优选率指标进行度量。
和KPI考核似曾相识？
CBB上架率/下架率统计报表
每年新增CBB和下架CBB统计。
各位老板，员工们的KPI考核指标条款都想好了吗？
CBB的实现
CBB应选择适当的构建途径和激励机制，构建整体应用平台，实现集成应用的目标。
CBB的构建途径
构建CBB有两种途径
根据需求进行规划
通过产品路标规划和技术路线规划构建平台框架，在此基础上进行开发。
说实话，不太现实。初创公司想想可以，还得有大神坐镇。一般公司谁被得起这口锅？
通过总结和沉淀
这是通常的做法，步骤是：分解产品树和技术树，通过对应分析找到共享技术，进行标准化和必要的上层开发构建平台，验证开发的平台，持续进行优化完善。
善于归纳勤于总结，不写周报的小伙伴们，不重视开发文档的老板们傻眼了吗？
CBB的激励机制
CBB平台构建应由高水平的人员完成，需要在正常业务之外投入人力和时间，因此必须要通过适宜的激励机制加以推进。主要有：通过任职资格牵引，没有做过平台的人员不能进行任职资格晋级；进行内部定价，对共享和被共享行为进行奖励；销售给非竞争的客户，获取合理收入；对周期长、难度大的开发任务给与战略补贴和特殊奖励。
嗯，该怎么说呢，诸位老板量力而行。
与其他信息系统的集成
CBB建设目标是构建整体应用平台。当前企业信息化应用系统是复杂的异构系统环境，分布式数据和异构数据是CBB集成应用的挑战。集成应用的关键挑战是如何将分布在异构、异源系统中的数据进行有效采集、挖掘、加工和关联，按照知识资源体系和大数据的方法建立统一的检索库，实现企业级集成应用。
说到底，CBB不仅是协作模式由串行向并行的改变，更是工作习惯、管理思维和资源调配体系的变革。无论是被动无奈还是主动求变，能够考虑到CBB体系的建设，终归是走向伟大的积极尝试。
联系我们
Contact us
战略解码