目前市场上主流PDM/PLM（如Enovia、Teamcenter、Windchill）采用“CAD驱动EBOM”模式，EBOM的诞生完全依赖于数据设计的成熟度，并且EBOM结构形式、组织方式与CAD结构十分接近，虽简化设计，但存在三大痛点:
1. BOM结构冗余导致变更困难：层级结构复杂，容易引起“变更冒泡”和“变更排队”，产生大量对上下游没有意义的变更，同时大大降低BOM的发布效率。
2. BOM产生时点滞后影响前期业务：先有数模设计后才能有BOM，BOM产生时点晚，无法满足在更早期其他业务部门对BOM的使用需求，影响成本估算、先期定点等业务活动的开展
3. EBOM与MBOM脱节：EBOM较少考虑物料层面的管理要求，面向ERP、MES等要求的制造BOM有非常大的差异，导致MBOM另起炉灶，造成产品开发各阶段BOM之间无法有效衔接
对此，最佳解决方案是PDM/PLM与独立BOM系统异平台协同管理：
• BOM系统：由EarlyBOM自然成熟到EBOM，并由EBOM发布直接产生MBOM、SBOM等
• PDM/PLM：专注数模/图纸管理与工程定义、DMU应用等
• 协同机制：通过接口高度集成，由BOM系统建立的EBOM结构驱动PDM/PLM系统CAD结构的建立，确保设计与制造的数据贯通及一致性

iBOM主要面向复杂制造业，典型的行业包括汽车行业（整车、零部件）、能源行业、半导体设备行业、工程机械行业以及其它复杂的装备制造业。
目前绝大部分车企都是采用iBOM平台作为其企业级BOM平台，包括乘用车、卡车、客车等不同类型的车企。复杂装备制造业也有典型的案例，包括金风风机、北方华创、上海烟机等。

iBOM系统作为一个专业的企业级BOM管理系统，将产品配置、BOM、变更进行三位一体管理。企业级BOM管理系统是一个针对这些数据的构建、发布系统，所有这些数据的管理职能在企业级BOM管理系统中可以进行统一管理，以确保这条主线数据的一致性、准确性。其它应用领域的系统变成这条主线数据的应用系统。

通过iBOM系统构建、管理的这条主线，其核心目的是实现基于企业级BOM系统的业务集成。因此几乎所有的关键业务领域的应用系统都会与iBOM系统集成。主要包括：
• 研发领域的应用系统：主要是PDM/PLM系统
• 成本/采购领域的系统：成本管理系统、生产采购系统
• 工艺领域系统：CAPP或其它PDM厂商的三维工艺平台
• 生产领域系统：ERP、MES
• 销售领域系统：CRM、点单系统
• 售后领域系统：EPC系统

iBOM系统功能非常丰富，可以分以下三条主线：
1. 全生命周期配置管理：产品型谱管理、全局配置特征库管理、工程配置管理、生产配置管理、销售配置管理
2. 一体化BOM管理：零部件管、早期BOM管理、试制BOM管理、EBOM管理、MBOM管理、KDBOM管理、SBOM管理、软件BOM管理。针对定制化行业，有专门的订单BOM或项目BOM管理模块
3. 端到端变更管理：变更申请管理、工程变更管理（配置变更、BOM变更、零部件变更等）、制造变更管理、售后变更管理、海外变更管理、断点管理。针对定制化行业，有专门的订单变更或项目变更管理模块。

iBOM中管理产品层级数据，我们建议在iBOM系统中集中管理产品型谱，定义不同层级的产品之间的关系、重要特性等。这不仅仅为全企业提供了统一的、严格受控的产品信息，同时是企业构建产品配置表、超级BOM的产品框架。

iBOM中规划配置表是产品规划部门的输出，是源头。基于规划配置表构建工程配置表。生产配置表和销售配置表一般都是基于工程配置表构建。生产配置表是面向工厂的，即同一工程配置表可以面向不同工厂构建多个生产配置表。销售配置表是基于市场销售策略定义的，即同一份工程配置表可以面向不同的销售策略构建多份销售配置表。

不同阶段的配置表，其配置特征都来自统一的企业全局配置特征库。iBOM内部会建立规划配置表、工程配置表、生产配置表、销售配置表之间的底层数据关系。当变更发生时，系统内部的数据关系可以保证变更的内容通过系统直接传递到不同的配置表。如工程配置表发生变更，将通过配置变更单发布。该变更单数据将通过系统推送到生产配置和销售配置。这样，配置变更数据能够在不同的配置表被承接，而不会遗漏导致配置表的不一致。

iBOM系统的底层设计理念就是将配置数据作为一个贯穿企业全价值链的重要数据进行管理。因此，配置数据的生效性管理是配置管理的重要内容。在iBOM平台上，配置数据通过发布单发布、生效。生效日期将通过系统自动体现在配置表上。同时，后续的变更都通过变更流程进行管控。每一个变更单都需要发布、生效，从而驱动配置数据的生效。

确保BOM数据的一致性和准确性，最核心的是要确保BOM数据从研发到下游各个业务领域流转时底层数据架构是一致的。企业级BOM的核心思想就是把所有系统形态的BOM整合到一个平台完成构建与发布。这样，不同形态的BOM之间底层架构都是基于同一个系统设计，不会受到不同商业软件包的影响。
同时，企业时时刻刻在发生设计变更。不同形态的BOM要保证流转高效、变更数据一致传递、BOM数据准确，就必须考虑底层变更与BOM进行数据紧耦合设计，确保变更流程直接驱动数据变化，而不是变更与BOM“两层皮”状态。

不是的。BOM扁平化是制造业的一个非常好的实践，有利于BOM组织效率的提升、流转效率的提升以及BOM质量的提高，对于全业务链效率提升非常有价值，因此我们非常主张制造企业按照扁平化思路构建BOM。但这是一个业务方案，而不是一个系统限制，甘棠软件iBOM同时支持扁平化BOM和结构层级非常深的BOM。

不是的。iBOM同时支持超级BOM模式和单一产品BOM模式。同一个企业不同形态BOM也可能既存在超级BOM模式也存在单一产品BOM模式。如定制化特征比较强的企业，平台产品一般以超级BOM方式存在，订单或项目BOM则是单一产品BOM模式

原则上企业级BOM管理的是产品定义的主线数据，其职能重在管理，不在应用。BOM的应用场景都与不同业务领域的应用系统密切相关。
基于以上原则，管理形态的BOM都在企业级BOM系统中构建、发布。管理形态的BOM主要是指不是为某一个业务领域的具体应用场景产生的，而是具有跨业务领域协同价值的BOM，主要包括早期BOM、EBOM、
MBOM、SBOM、KDBOM。定制化较强的企业还包括订单BOM或项目BOM。
应用形态的BOM以管理形态的BOM为源头，在各自的应用系统中应用。一般的实现方式是：采取一定的方式从企业级BOM接收相应形态、状态的BOM，在应用系统中进一步设定该BOM的应用方式。典型的应用形态BOM包括：为物料预测服务的计划BOM、为成本企划服务的成本BOM、为先期采购项目管理服务的采购专用件清单等等。

iBOM系统拥有专利的高性能的BOM解析算法，具备行业断崖式领先的BOM解析速度。同时，iBOM系统前端使用React框架进行开发，可在网页实现秒级的BOM渲染及流畅编辑。具体数据如下：
• 1500多配置特征以及200多配置规则约束，最终生成4亿多整车物料号也只需5秒左右
• 某个超级BOM全展开共1万9千多行零件，选择1000个整车物料号去分别解析这份超级BOM，从点击搜索按钮到系统返回数据并渲染页面，整个过程只需45秒左右
• 对于BOM页面，我们可以做到查询1秒返回。某份总共12万行零件的BOM数据，从点击搜索按钮到染数据，最多也就1秒时间，并且对于如此海量的表格数据，我们可以平滑、流畅地浏览和编辑数据

可以。在 iBOM系统中可以定义零部件的替换关系以及成套关系。

可以。新零件的申请可以在iBOM系统中进行。可以根据一定的规则对零件进行编码。

可以。iBOM系统中有专门的工作流引擎，支持用户自定义工作流。同时也支持与外部OA系统集成。

在iBOM中通常管理的变更主要类型包括：产品配置变更、一般设计变更（BOM/零部件等的变更）、制造变更、售后变更等。iBOM中管理的变更类型通常与管理的BOM形态有关系。如在定制化比较高、项目交付型企业，还有专门的项目类变更（与产品类变更区别开来）。

不是。变更管理整个过程中，各个业务部门除了要处理产品配置数据、各阶段的BOM数据之外，还有其它数据以及很多线下的活动要开展。其它的数据包括3D/2D数据、工艺文件等。还包括变更的整个试装过程、断点的协调活动等。
将变更纳入企业级BOM平台，强调的是变更对数据的直接驱动作用，并不是强调变更相关的所有活动都需要纳入线上、在企业级BOM平台中管理。事实上，3D/2D数据、技术文件等的发布一般在PDM中进行，工艺文件变更在工艺系统中进行。但企业级BOM作为变更的总控平台，变更的发起最好在企业级BOM系统中发起，通过集成接口传送到PDM、工艺系统等平台。试装、断点的协调工作则不宜在企业级BOM系统中管理，以避免将企业级BOM系统变成某个具体业务领域的业务系统或项目管理系统。

可以。iBOM系统可以针对页面、按钮乃至数据进行权限控制。