BOM管理

BOM（物料清单）是数字工程的一个重要组成部分，它是一份制造产品所需的所有流程和材料的清单。BOM管理对有效的生产和供应链管理至关重要。

– 文章信息 –

本文作者：Zhang Nicole。由「博世制造及工程服务中心」原创首发，数字化企业经授权发布。

记得有位专家曾经提出过一个观点，说BOM是工厂混乱的根源，该专家认为，如今绝大数企业没有对BOM管理有足够的重视，这导致了规划及生产过程中的种种问题。笔者也深表赞同，因为BOM是构成一个产品的所有子项目的材料清单，它包含在研发、规划及制造等过程中出现的所有流程，工艺，物料，产线及相关实体。笔者从近几年的实践中总结了一下BOM在数字工程中的一些基本应用场景：

1.PLM（产品生命周期管理）系统可以利用BOM进行专业的流程管理，可以有效提高企业的生产规划和执行等过程中的管理水平。

2.BOM可以作为制造过程数据管理的核心，它可以帮助组织研发，规划、制造等流程，同时也可以是PDM/ERP/MRP等信息系统中最重要的基础数据。

3.BOM是一种结构化的数据格式，表达了产品的材料组成、加工顺序和其他信息，可根据不同的应用场景进行配置。

在此前的“数字工程”专栏系列中已经介绍了PLM的基本功能，今天笔者就围绕西门子Teamcenter的功能来看看行业内的领先解决方案是如何玩转BOM管理的。

在Teamcenter中，可以存放管理各种文件以及各类BOM，仅BOM文件从类别上大致分为：

● 设计BOM(Engineering BOM，EBOM)

● 工艺BOM(Process Planning BOM，PPBOM)，

● 制造BOM(Manufacturing BOM，MBOM)，

● 资源BOM（Resource BOM，BOR），

● 质量BOM(Quality BOM，QBOM)

● 成本BOM(Cost BOM)等，

这么多类型的BOM都有其使用场景和应用领域。

那么问题来了，有了这些BOM以后我们能干什么呢？

其实，它大有可为！

首先，基于BOM管理实现从物料到产品的EBOM、PPBOM、MBOM的自动转换，因为现在很多BOM转换工作还是依赖工程师手动操作将物料发布到产品BOM。简单描述一下这个发布过程中：产品主数据在PLM组建并完成发布后（设计变更的流程），EBOM是由产品设计师根据他们的知识和专长手动完成的，它可以作为创建其他BOM的参考，如PPBOM和MBOM，制造和生产工程师可以用它来计划和执行生产过程。然而使用了基于BOM管理的系统后，一旦EBOM创建完成，后续的PPBOM、MBOM及生产过程等均可通过系统中的设定的转换规律实现自动转换。当然，如果担心自动转换存在风险，可在自动转换过程中添加必要的审核节点，通过在审核节点的双重确认完成BOM的转换。

另外，实现基于BOM管理的变更流程，可简化变更流程，降低变更风向，提升变更流程中的沟通效率。怎么理解呢？无产品不变更，变更是产品在生命周期过程中最为频繁且复杂的活动之一，因此，变更过程中往往出现各部门信息不对称，沟通不顺畅，执行不到位等问题，特别是跨部门业务衔接存在“灰色地带”，因此基于BOM的变更管理会显得尤为重要，通过先进的工作流程能力，设计变更可以追溯到产品生命周期中的所有相关的依赖关系和决定。在Teamcenter中，用户可以在一个预先配置好的工作流中发起、管理、审查、确认和执行产品变更。在产品的整个生命周期中，变更历史将保持与产品的关联，支持完全的可追溯性，就如下图中所示，不同工艺过程中的数据总能互相找到对应的链接。

最后，如果把产品的设计数据(包括EBOM，PPBOM，MBOM)视为单一的产品数据源，那么各种其它BOM文件（如资源BOM、质量BOM、成本BOM…）就可以看成这个单一数据源映射在生产规划，质量部门和财务部门成本管理等功能的视图，这句话看起来比较难懂，接下来我来举个例子：利用受管理制造物料清（MBOM）和工艺清单（BOP）来实现规划过程的线平衡概念–使用MPP提供时间管理和平衡工具，包括显示操作、工位和操作员的滚动时间，以及计划中的周期时间和等待时间，并通过对增值和非增值活动的可见性支持精益规划。

制造业公司往往容易忽略BOM管理对其制造过程的相关性，制造工程师对产品设计或者规划的影响也很有限，但是利用基于BOM管理为基础的数字工程解决方案，可以使你能够在一个集成的产品生命周期环境中管理研发，规划，制造，工艺，资源和工厂等信息，使各种BOM之间实现了无缝对接，快速响应。因此，研发工程师通过CAD工具完成的装配体，可以在制造过程正确地规划及执行，可以利用线平衡工具帮助你分析增值和非增值活动，还可以生成2D/3D工作指令，将装配步骤清晰地传达给车间，通过在一个工具中显示最相关的信息，能大大增强了你的生产力。

综上所述，如果你还没有使用这类基于BOM管理工具来实现工作流程，变更管理，规划及验证等方面的功能，那么正如开头说的“缺乏对BOM的管理可能工厂混乱的根源”。

基于PLM平台的项目管理实践

概述 对于项目管理，目前市面上有不少管理平台或软件，但基于PLM平台，以制造业的产品开发或研发为视角的项目管理平台较少，而且使用PLM平台进行目管理也鲜有赢得客户口碑的案例。有鉴于此，本文以甲乙双方不同人员的视角，试图复盘某企业的项目管理实施过程，分析从业务调研，技术实施乃至项目管理过程中的得失，以期抛砖引玉，促使后续其他项目能更为健康有序的实施。 1.项目背景 本期项目是PLM的二期工程，一期已经实现了基本的产品数据管理，具体完成内容如下： 　　1.Creo与Windchill集成，实现通过MCAD数据生成EBOM。 　　2.物料及各类图纸发布和变更流程。 　　3.数据查询，可通过字段进行常规数据查询，也支持通过Solr引擎进行模糊搜索。 　　4.产品库，文件夹结构，权限管理，实现基本的数据存放及取用。 　　5.物料取号，结合物料分类（和SAP）获取物料料号。 　　6.SAP集成，实现物料基本视图及产品结构（EBOM）向下游自动准确传递。 　　项目管理的几个先决因素 　　对于项目管理的实施，而且还是基于PLM平台的项目管理，需要甲乙双方步调一致。双方至少需要明确：这是一个中高层级的项目，要站在更高的角度，宏观的来看待。对于项目管理这类项目，应该要对下述问题进行正面回答： 　　1.平台给谁用 　　项目管理平台通常涉及的部门、人员非常广泛，那么如何回答这个问题才能最符合企业当下的实际情况？项目管理平台通常是企业第一次实施，此时最需要考虑得就是企业管理层面的需要。具体来讲涉及以下几点： 　　a)项目类型定义及划分 　　在项目管理实施初期，切忌求全思想。通常企业内部的项目有如下几种：产品开发（变型设计及订单交付）、产品预研（包括市场调查、竞品分析、工业设计等）、技术预研（这部分主要为超前技术研发，例如含WIFI功能的插座面板、多插座转换器等）、精益设计/生产项目等等。 　　通常，没有经过管理咨询的企业，其项目类型的定义及划分的边界是不清晰的，所以往往在实施过程中，会经历频繁的变动，在此建议甲方，在未经过实际实施及验证的情况下，不要贸然进行类型及划分的修改，应在有使用平台的经验后再进行调整。 　　b)项目交付物及齐套性检查 　　对于订单型交付项目，需要将产品研发过程中的交付物进行统一管理。部分企业为了避免相似问题的频繁发生，会考虑进行交付物的过程管理，所以需要进行项目交付物管理。这部分实施内容包括：交付物模板管理，交付物编号/版本管理，交付物的齐套性检查（按项目阶段），交付物变更管理等。 　　c)项目进度及基线管理 　　在企业领导层的日常管理中，常需要关注项目进度。当企业制定了年度战略目标后，就会根据目标并将其拆分给每个部门，并订立KPI考核基准。所以年度目标是否能完成，就势必依靠项目计划来进行统筹。考虑到各任务的难易度不同，每个项目也会给予不同的缓冲时间。所以项目实际总周期及项目预计总周期是PM及PMO都十分关注的重要信息。 　　d)项目变更及控制管理 　　项目执行时，会因各种情况（计划内或计划外）而导致项目周期、交付物、人员、费用、范围等发生变化。此时若对项目总周期或阶段周期有较大变化时，则必须要进行项目变更管理控制。但控制到何种程度？给予PM多大的自由则需要根据企业的实际情况进行斟酌。 　　e)资源负载均衡管理 　　目前企业常面临着骨干工作量过多的现象，具体表现为：只要有新的重大项目就需要技术骨干参与，新员工或者技术较弱的员工常处于“游离”状态，结果就是技术骨干随着资历增加工作忙碌程度也日益增加，且也时而发生多项目并行而顾此失彼的现象，出错也就在所难免了。所以企业急需一套行之有效的人员状态管理工具，以便于项目执行及新项目开发时，进行资源负载平衡。 　　f)项目报表管理 　　项目报表作为项目监控的主要依据，需要体现项目的实际情况。但对于企业，必须要选择合适的数据以避免失真的数据影响PM或者PMO的判断。所以除了要求用户使用系统，并从系统获取原始数据外，还需要制定适合当下的规章制度。让所有人在同一套制度下协同办公，这才是企业项目管理能获得成功的必要条件。 　　2.平台怎么用？平台使用目的是什么？ 　　只有在确定系统主要给哪些部门或者哪些角色用之后，才可以回答使用的方式及目的。其使用方式有：全手工，手工+系统，全系统3种方式。使用目的可根据企业自身情况分为：资源合理安排及交付物管理（侧重项目安排），进度及风险管控（侧重监控）以及全流程全要素协同（侧重协同）。 　　使用方式 　　三种模式的差异，并不一定意味着哪种模式最好。而是要根据企业当前的现状，结合项目类型进行选择及剪裁。 　　a)全手工 　　适用于企业成立时间较短，尚未形成稳定且统一的项目制度，难以提供出一套适用于所有项目相关部门的执行制度。 　　也适用于技术预研或产品预研类型的项目，对于未知领域，项目的执行不能完全按照WBS，需要根据每一个任务的实际情况进行手工微调。甚至当预研出现较大变化的时候，需要及时止损并暂停项目，归档项目执行过程中的所有交付物，以便后续条件合适时再重启。当然也有可能因为外部条件变化，导致项目永久关闭。 　　b)手工+系统 　　适用于企业已具备一定的项目制度，但因种种原因导致项目执行效率并不乐观，所以除系统按WBS执行时，还需要辅佐一定的人为干预，此类情况大多为临时性的，一旦企业理顺项目类型及进度任务关系，并适当修订规章制度后则可全部转为全系统执行。另外如果因为任务涉及核心技术或者交付物中涉及战略客户，则为了保障信息不被泄密，可以将核心信息暂存他处，并沿用手工+系统执行的方式。 　　c)全系统 　　适用于企业已制定较为完备的规章制度，且项目相关人员可以在此制度下默契执行项目。此类模式主要应用于成熟产品的改型设计及订单交付，很少适用于研发性质的项目。 　　使用目的 　　通常使用目的得根据主要使用部门来定，比如项目管理部作为主要使用部门，研发、工程、物流等部门为配套部门时，多以项目进度及交付物为主要管控目的，所以此时偏重于订单合规交付以及项目进度的纠偏。 　　若以研发、工程部门为主要使用部门，则多以项目质量为重。所以综合来看：当企业初具规模时，因各条件尚不具备，所以项目经理多以资源协调及交付物管理为重。当项目管理平台使用半年后，整体项目管理模式成熟及项目经理可以通过数字化平台纵览全局后，则能提升至项目进度监控及风险管控。此时项目经理会根据各成员执行情况进行干预甚至提前协调任务优先级，并管控订单交付或研发过程中的部分质量问题，此时WBS及交付物可能出现比前期更为频繁的变更，所以此阶段的各部门磨合期会持续较长时间。从PMO管理甚至企业战略的角度来看，企业高层在此时应更多的处理好部门及角色的职能边界问题，当岗位职能及执行策略都形成具体的“方法论”后，则进入至全流程全要素协同的状态（可参考IPD）。 2.解决方案 　　2.1 创建项目计划 　　分解复杂项目和方案成可管理的组件，在一个非常大的项目或者方案中，定义一个顶层结构，接着定义一级的活动计划和任务接受者，一级任务接受者可定义二级的活动计划，三级的依次类推。 　　1.WBS在项目立项阶段，其定义过程如下（包括前后事件关系）： 　　2.项目经理根据项目类型（ODM/OEM……etc.）通过模板创建项目； 　　3.系统支持将现有项目另存为新项目。 　　4.通过项目模板创建项目，同时项目经理将OA中关于项目立项的信息填写在创建的项目属性中； 　　5.由项目经理或者财务、产品经理完善项目相关的财务、采购等信息； 　　6.项目经理维护项目团队及其主要成员，例如各职能担当； 　　7.线下通知担当，由担当将项目过程中所需要的其他成员添加至团队中； 　　8.在项目启动前项目经理与各职能担当一起完善WBS，并针对具体的活动设置必要的交付物； 　　9.当项目经理及担当都完成WBS及交付物定义后，由项目经理做最终确认，并执行“启动”操作，至此立项阶段所有工作事项完成。 　　以企业某项目实例为例：…