Mainstream PDM/PLM solutions on the market (e.g., Enovia, Teamcenter, Windchill) typically follow a “CAD-driven EBOM” approach. In that model, the EBOM is created only after the design data matures, and the EBOM’s structure and organization closely mirror the CAD assembly structure. Although this simplifies design-related work, it brings three major pain points:
1. Redundant BOM structure makes changes difficult: Complex hierarchical structures cause “change bubbling” and “change queuing”, producing a large number of downstream-upstream changes that are meaningless to stakeholders and significantly slow BOM release efficiency.
2. Late BOM creation impacts upstream business activities: Because the BOM is generated after the digital model is ready, it appears too late to satisfy earlier-stage business needs for BOM data — affecting cost estimation, early supplier selection, and other pre-development activities.
3. Disconnection between EBOM and MBOM: EBOMs rarely address material-level manufacturing requirements. MBOMs required by ERP/MES differ substantially from EBOMs, leading to separate MBOM creation and poor continuity across product development stages.The best practice is collaborative management across platforms: PDM/PLM working together with an independent enterprise-level BOM system:
• BOM system: let EarlyBOM naturally mature into EBOM, then publish EBOM to directly generate MBOM, SBOM, etc.
• PDM/PLM: focus on CAD/model and drawing management, engineering definitions, DMU applications, and the like.
• Collaboration mechanism: highly integrated via interfaces — the EBOM structure established in the BOM system drives the CAD structure creation in the PDM/PLM to ensure data continuity and consistency between design and manufacturing.

iBOM targets complex manufacturing industries. Typical sectors include automotive (complete vehicles and components), energy, semiconductor equipment, construction/engineering machinery, and other complex equipment manufacturers. Currently, the majority of OEMs and vehicle manufacturers use iBOM as their enterprise-level BOM platform, covering passenger cars, trucks, buses, etc. There are also representative cases in complex equipment manufacturing such as Goldwind, NAURA.

As a professional enterprise-level BOM management system, iBOM integrates product configuration, BOM, and change management into a single platform. The enterprise-level BOM system is the authoritative construction-and-release platform for these data: it centrally manages and controls the masterline product data to ensure consistency and accuracy. Other business applications become consumers/applications of this masterline data.

Through the masterline built and managed in iBOM is intended to enable enterprise-wide business integration. Therefore, almost all key business application systems integrate with iBOM, including:
• R&D domain: PDM/PLM systems.
• Cost / Procurement: Cost management and procurement/production purchasing systems.
• Process/Manufacturing Engineering: CAPP or other vendors’ 3D process platforms.
• Production: ERP, MES.
• Sales: CRM, ordering systems.
• After-sales: EPC/after-sales systems.

iBOM is feature-rich and can be summarized along three primary threads:
1. Full lifecycle configuration management: product family (model line) management, global configuration characteristic library management, engineering configuration management, production configuration management, and sales configuration management.
2. Integrated BOM management: part master, EarlyBOM management, pilot-run/tryout BOM, EBOM, MBOM, KDBOM, SBOM, and software BOM management. For highly customized industries there are dedicated Order BOM or Project BOM modules.
3. End-to-end change management: change request management; engineering change management (configuration changes, BOM changes, part changes, etc.); manufacturing change management; after-sales change management; overseas change management; breakpoint/hold-point management. For project-driven/customization-heavy organizations there are also dedicated order/project change modules.

Yes. We recommend centrally managing the product family/model-line in iBOM — defining relationships and key characteristics across different product hierarchy levels. This provides the enterprise with a unified, strictly controlled product information source and serves as the product framework for building configuration tables and a SuperBOM.

The planning configuration table (Planning Config Table) is produced by the product planning organization and serves as the origin. The engineering configuration table is built from the planning table. Production and sales configuration tables are generally derived from the engineering configuration table. A single engineering configuration can generate multiple production configuration tables for different factories. Likewise, multiple sales configuration tables may be created from the same engineering configuration to support different market or sales strategies.

All configuration tables draw their features from a unified enterprise-level global configuration characteristic library. iBOM establishes underlying data relationships among the planning, engineering, production, and sales configuration tables. When a change occurs, these internal data links ensure the change is propagated automatically across relevant configuration tables. For example, an engineering configuration change is issued via a configuration change order and the system pushes that change to production and sales configurations — ensuring no omissions and preserving consistency.

Yes. iBOM treats configuration data as critical master data spanning the full value chain, and managing its effective status is a core capability. Configuration data is released and activated through formal release documents/orders in the platform; effective dates are recorded and reflected automatically in the configuration tables. Subsequent changes are controlled by change workflows — every change order must be released and activated to drive the effective data.

The key to BOM consistency and accuracy is maintaining a consistent underlying data architecture as BOM data flows from R&D to downstream business domains. The enterprise-level BOM concept consolidates all BOM types and shapes into a single platform for construction and publishing. This means different BOM forms share a common underlying design and are not fragmented by differing commercial software packages.
Because design changes occur continuously, different BOM variants must support efficient flow and consistent change propagation. Therefore, change processes are tightly coupled with BOM data at the architecture level so that change workflows directly drive data changes — avoiding a two-layer situation where process and data are disconnected.

No. While BOM flattening is a best practice in manufacturing — improving organization efficiency, data flow, and BOM quality. Therefore, we strongly advocate that manufacturing enterprises adopt a flat organizational structure when building their BOM. But it is a business approach rather than a system limitation. Gant Software’s iBOM supports both flattened BOM and deeply hierarchical BOM structures.

iBOM supports both SuperBOM (configurable/platform BOM) and single-product BOM modes. Within the same enterprise, different BOM forms may coexist: platform products on the platform/SuperBOM while highly customized orders or project deliveries use single-product BOM.

In principle, the enterprise-level BOM manages the masterline product definition data and its role is governance rather than direct application. Application-specific BOM is tightly linked to their respective business systems.
Management-form BOM — those that are not specific to a single application domain but have cross-domain coordination value — should be constructed and published in the enterprise-level BOM system. Examples include EarlyBOM, EBOM, MBOM, SBOM, and KDBOM; for highly customized firms this also includes Order BOM or Project BOM.
Application-form BOM originate from these management-form BOM and are used within application systems. Typically, application systems receive designated BOM variants and statuses from the enterprise BOM and then apply further business-specific settings. Typical application-form BOM include Planning BOM for material forecasting, Cost BOM for cost planning, and Procurement BOM for early purchasing of special parts.

iiBOM implements patented high-performance BOM parsing algorithms and leads the industry with breakthrough parsing speed. The front end is built with React, enabling sub-second BOM rendering and smooth editing in a web browser. Representative performance metrics:
• With 1,500+ configuration features and 200+ configuration rules, producing over 400 million vehicle part numbers takes only around 5 seconds.
• For a SuperBOM with 19,000+ line items, selecting 1,000 part numbers and parsing that SuperBOM (from clicking search to page rendering) takes about 45 seconds.
• BOM page queries can return within 1 second. A BOM containing 120,000 lines can be queried and rendered in roughly 1 second, and the UI supports smooth browsing and editing of such large tables.

Yes. iBOM supports defining part replacement relationships as well as set/complementary (kit) relationships.

Yes. New part creation requests can be handled within iBOM, and parts can be coded according to configurable rules.

Yes. iBOM includes a workflow engine that supports user-defined workflows and can integrate with external OA systems.

Typical change types managed in iBOM include product configuration changes, general engineering changes (BOM/part changes), manufacturing changes, and after-sales changes. In project- or order-driven organizations, project-type changes (distinct from product-type changes) are also supported.

No. Throughout the change lifecycle, business functions often need to handle additional data and many offline activities beyond the product configuration and BOM data managed in iBOM — including 3D/2D CAD data, process documents, trial installation activities, and breakpoint/hold-point coordination.
Bringing change into the enterprise BOM platform emphasizes the change’s direct, data-driving role; it does not mean all related activities must be managed online in iBOM. Typically, 3D/2D data and technical documentation are published in PDM, and process documents are managed in process systems. As the overall control platform, the enterprise BOM should ideally be the originating point for change requests and then distribute them via integrations to PDM and process platforms. Trial installation and breakpoint/hold-point coordination should not be managed within the enterprise BOM system to avoid turning it into a specialized project or operational system.

Yes. iBOM supports access control at page, button, and even data-field levels.