Connect981 – Content Dev

RSC Topic: Planning & MRP Alignment

Connecting ERP planning signals to real execution constraints.

  • How do design changes and configuration variants affect backlog risk profiles?

    Design changes and configuration variants typically increase backlog risk, especially in regulated, high-mix environments. They create more ways for planning, materials, and execution to get out of sync, which shows up as shortages, rework, NCRs, missed slots, and unstable lead times.

    Key ways design changes increase backlog risk

    • Configuration confusion on the floor
      If work instructions, routings, and travelers are not tightly tied to revision and configuration, operators can build to the wrong version. This often surfaces late (inspection, test, or customer) and converts into rework, scrap, and schedule slip.
    • Mixed-revision WIP
      When a design change is cut in while WIP exists at multiple stages, planners must decide what to rework, deviate, or allow to ship as-is. Poorly controlled cut-in strategies create backlogs of MRB decisions and rework queues.
    • Requalification and FAI load
      Changes can trigger new First Article Inspections or partial requalification. If FAI/qualification capacity is limited, this becomes a bottleneck that holds released orders and inflates the backlog.
    • Late or incomplete data propagation
      If PLM changes are not synchronized reliably into ERP (BOMs) and MES (routings, digital travelers, work instructions), planning may release work to obsolete data. Discovering this during build causes stops, ECO-driven rework, and order reshuffling.
    • Supplier and lead-time impact
      Design updates that change special processes, materials, or key characteristics can invalidate supplier capability or existing approvals. Backlog risk rises when supply chain constraints are discovered after orders are released.

    How configuration variants change risk profiles

    • More unique paths through the system
      Each variant can carry its own routing, inspection plan, and documentation set. High configuration diversity increases the chance that planning or MES will apply the wrong route or checklist, especially in brownfield, partially manual environments.
    • Shortage and kitting risk
      Variant-specific parts and kits are easier to mis-plan and mis-pick. When multiple close variants share similar but not identical components, picking errors create hidden defects and late rework.
    • Capacity fragmentation
      Variants that require different fixtures, tools, programs, or certifications fragment capacity. This can turn a seemingly balanced line into multiple micro-bottlenecks and make due-date performance more volatile.
    • Traceability complexity
      For regulated configurations (by tail, lot, contract, or customer option), recording and retrieving the exact as-built state for each unit becomes harder. Weak traceability increases the risk that a defect or field event forces broad containment across the backlog.
    • Forecasting error
      The more variants, the harder it is to forecast mix accurately. Mis-forecasted variants lead directly to the wrong WIP mix, stranded inventory, and unserved demand in the backlog.

    Dependencies that strongly shape the risk

    The actual backlog impact of design and configuration complexity depends heavily on:

    • PLM–ERP–MES integration quality
      If design, BOM, routing, and work instructions are not synchronized with clear revision and effectivity control, almost every change increases the chance of misbuilds and planning errors. Conversely, well-governed integrations can contain some of the risk.
    • Configuration management maturity
      Disciplines like clear configuration baselines, effectivity rules (by serial, lot, date, or order), and structured ECO/ECR processes are critical. Weak configuration management turns otherwise modest changes into systemic backlog shocks.
    • Digital traveler and work-instruction practices
      Plants still relying on paper packets, tribal knowledge, or local copies of PDFs are far more exposed. Digital travelers linked to part number, revision, and configuration, with controlled approvals, materially reduce misbuild and rework risk.
    • Change impact analysis and cut-in rules
      Plants that treat change as an engineering-only activity often underestimate operational impact. Explicit impact analysis on WIP, inventory, supplier readiness, FAI load, and capacity is needed before deciding how and when to cut in a change.
    • Validation and qualification constraints
      In regulated environments, some design changes require formal revalidation or customer approval. If those workflows are slow or opaque, orders may accumulate in a “waiting on approval” backlog state that is not obvious in standard reports.

    Practical ways to control backlog risk from changes and variants

    • Classify changes by operational risk
      Not all changes are equal. Classify ECOs by impact on routings, setups, inspection, special processes, or regulatory approvals. Use this to predict and manage backlog exposure on a per-change basis.
    • Tighten effectivity and WIP rules
      Define clear, enforced rules for when a change applies (by serial, work order, or date) and how WIP is handled (rework, deviation, or allow-as-is). Capture these in ERP/MES, not just in procedure documents.
    • Link travelers and inspection plans to configuration
      Ensure digital travelers, checklists, and inspection plans are selected automatically based on part, revision, and configuration attributes, rather than manual operator or planner choice.
    • Monitor leading indicators, not just late orders
      Track volume and age of open ECOs, MRB items, rework orders, and pending FAIs as early signals. Spikes here usually precede visible backlog deterioration.
    • Coordinate with suppliers before cut-in
      Confirm supplier readiness, qualification status, and lead-time impact before implementation, particularly for critical or unique parts. Otherwise, design change can silently convert into future material shortages.
    • Use simulation or scenario planning where possible
      In higher-maturity environments, simulate the load of a major design change or new variant on bottleneck resources and inspection capacity before committing to dates.

    Brownfield and system coexistence considerations

    In most regulated plants, full replacement of PLM, ERP, or MES simply to improve change handling is rarely feasible due to validation burdens, downtime risk, legacy integration, and long asset lifecycles. More realistic patterns include:

    • Layering a digital traveler or work-instruction system over existing ERP/PLM and using it to enforce configuration-correct documentation on the floor.
    • Incrementally tightening integration mappings and revision controls between existing systems instead of attempting a big-bang replatform.
    • Focusing first on high-risk product families or programs rather than attempting enterprise-wide change-process redesign in one step.

    Backlog risk is rarely eliminated; it is managed. The more design churn and configuration diversity you have, the more you depend on disciplined configuration management, robust integrations, and pragmatic change-cut-in rules to keep that risk within an acceptable band.

  • Demand Variability

    Core meaning

    Demand variability commonly refers to the degree and pattern of fluctuation in demand over time. In industrial and manufacturing contexts, it describes how customer orders, production requirements, or material needs change in:

    – **Volume** – total quantities ordered or scheduled
    – **Mix** – which products, SKUs, or configurations are needed
    – **Timing** – when demand occurs (e.g., intra-day, daily, weekly seasonality)
    – **Location** – where demand is required across plants, lines, or warehouses

    It is typically measured using statistical indicators such as standard deviation, coefficient of variation, or variability indices applied to historical demand data.

    Use in manufacturing operations

    In regulated and complex manufacturing environments, demand variability is used to describe and analyze:

    – **Customer order patterns** captured in ERP or order management systems
    – **Planned vs. actual demand** seen by MRP and planning modules
    – **Schedule changes** that propagate into MES and shop floor dispatch lists
    – **Material and component requirements** for procurement and inventory management

    Operations teams assess demand variability to:

    – Characterize how stable or unstable demand is over relevant horizons (days, weeks, months)
    – Understand why production plans and schedules change frequently
    – Evaluate the robustness of capacity, inventory, and staffing plans to fluctuations

    What demand variability includes and excludes

    **Includes:**

    – Fluctuations driven by customer orders, forecasts, tenders, or internal consuming processes
    – Seasonality, promotions, product introductions and retirements, and event-driven spikes
    – Changes in product mix that alter required routings, cycle times, and materials

    **Excludes (typically):**

    – Random noise in measurement systems or data collection errors
    – Variability in **process performance** (e.g., equipment downtime, quality losses), which is usually treated as *supply-side* or *process* variability, not demand variability

    However, in practice, poor data quality or late orders can be misinterpreted as demand variability. Many organizations separate **true demand variability** (customer- or usage-driven) from **apparent variability** caused by internal systems and behaviors.

    Relationship to planning and execution systems

    Demand variability interacts with key planning and execution layers:

    – **ERP/MRP:** Seen as variability in order intake and forecasts that drives changing planned orders and procurement suggestions.
    – **APS and scheduling tools:** Leads to frequent re-optimization of production sequences, changeovers, and capacity allocations.
    – **MES and shop floor control:** Appears as volatile production priorities, resequencing of work orders, and short-notice demand for certain SKUs or batches.
    – **Quality and compliance systems:** Changes in product mix and volume affect sampling plans, validation loads, and documentation volume.

    Understanding and characterizing demand variability is a prerequisite for designing appropriate planning horizons, safety stocks, capacity buffers, and production strategies, without implying any specific method.

    Common confusion and related terms

    Demand variability is often confused with or used interchangeably with several adjacent concepts:

    – **Demand volatility:** Sometimes used as a synonym; in some organizations, volatility implies more abrupt, unpredictable swings, while variability can include regular patterns like seasonality.
    – **Forecast error:** Measures how far forecasts are from actuals. Forecast error is an *outcome* of both demand variability and forecasting approach; it is not the same as variability itself.
    – **Supply variability:** Refers to fluctuations in the ability to supply (capacity, lead times, yields). Demand variability is on the *requirement* side, not the *supply* side.
    – **Production schedule variability:** The instability of the internal production plan. This is influenced by demand variability but also by planning rules, lot sizes, and constraints.

    Clear separation of these terms is useful when diagnosing the root causes of instability in manufacturing operations.

    Site context application

    Within industrial and regulated environments, demand variability is a key driver of:

    – Planning complexity across ERP, APS, and MES layers
    – Inventory and capacity decisions that must respect regulatory and quality constraints
    – The design of robust manufacturing and quality systems that can accommodate changing product mixes and volumes

    Discussions of demand variability on this site typically focus on how it interacts with manufacturing execution, quality documentation workloads, and the stability of production schedules, rather than on consumer marketing or retail-oriented perspectives.

  • Time bucket

    A time bucket is a fixed time interval used to group planning or performance data into manageable periods. In manufacturing and supply chain systems, time buckets commonly refer to units such as hours, shifts, days, weeks, or months that are used to organize demand, inventory, production, capacity, or schedule information.

    The term usually applies to planning and reporting logic rather than to the physical process itself. For example, an ERP or MES may summarize orders, labor, machine load, or output by day or by shift. The bucket defines how time-based data is collected, stored, compared, or displayed.

    Where it appears

    • Production planning: forecasted and scheduled quantities may be grouped into daily or weekly buckets.

    • MRP and supply planning: supply and demand are often netted within specific bucketed periods.

    • Capacity planning: available hours and required load may be compared by shift, day, or week.

    • Performance reporting: throughput, downtime, scrap, or labor usage may be trended by defined intervals.

    What it includes and excludes

    A time bucket includes the start and end boundaries of a reporting or planning interval and the data assigned to that interval. It does not by itself define sequencing, priority rules, or real-time event timing. A bucketed schedule is a summarized view of time, not the same thing as an exact timestamped execution record.

    In practice, smaller buckets allow more detailed planning but require more data and maintenance. Larger buckets provide a broader planning view but can hide short-term variation.

    Common confusion

    Time bucket vs. timestamp: a timestamp marks a specific moment, while a time bucket groups many events or quantities into a defined period.

    Time bucket vs. scheduling horizon: the scheduling horizon is the total future period being planned, while the time bucket is the size of each interval within that horizon.

    Time bucket vs. time fence: a time fence is a rule boundary for planning changes, not the interval used to aggregate data.

    Manufacturing example

    A planner may review weekly demand in ERP, then break the current week into daily or shift-based buckets in MES to align production capacity and work-center loading more closely to shop-floor reality.

  • MRP

    Core meaning

    MRP (Material Requirements Planning) is a planning approach and supporting system that calculates:

    – **What** materials and components are required
    – **How much** of each item is needed
    – **When** they are needed

    It uses inputs such as the master production schedule, bills of material (BOMs), current inventory balances, and lead times to generate time-phased planned orders for purchasing and production.

    MRP commonly runs as a batch or scheduled process inside an ERP or dedicated planning system. Its outputs drive purchase orders, work orders, and rescheduling messages for planners and buyers.

    How MRP works in manufacturing environments

    In industrial and regulated manufacturing, MRP typically:

    – **Explodes BOMs**: Breaks finished goods demand into demand for subassemblies, components, and raw materials.
    – **Net requirements**: Compares gross requirements to on-hand stock, safety stock, and existing orders to calculate net needs.
    – **Time-phasing**: Offsets requirements by lead times so orders are planned to arrive or complete when needed for production.
    – **Order proposals**: Suggests planned production and purchase orders (with quantities and due dates) that planners can convert into firm orders.

    In day-to-day workflows, planners and buyers use MRP-generated action lists to:

    – Release or adjust purchase orders
    – Launch or reschedule work orders
    – Identify potential shortages or excess inventory

    Boundaries and what MRP is not

    MRP is:

    – A **material and component planning method/system**, focused on availability and timing
    – Typically **run within ERP or advanced planning tools**, not on the shop floor

    MRP is not:

    – A **shop-floor execution system** (that role is usually filled by MES or other OT systems)
    – A **capacity planning method** by itself (this is more aligned with CRP or finite scheduling, although MRP can feed those processes)
    – A **forecasting tool**; it consumes demand signals (forecasts or orders) rather than generating them

    Common related terms and confusion

    – **MRP vs. ERP**: ERP is the broader enterprise system; MRP is a planning function or module within ERP (or a separate planning engine). ERP includes finance, procurement, inventory, and other domains beyond material planning.
    – **MRP vs. MES**: MRP plans *what and when* materials are needed. MES manages *how and where* materials are consumed, tracked, and executed on the shop floor.
    – **MRP I vs. MRP II**:
    – *MRP I* often refers to classic material requirements planning.
    – *MRP II* (Manufacturing Resource Planning) extends the concept to include additional resources such as labor and machine capacity, plus more integrated business planning.

    Site context: MRP in relation to MES and ERP inventory

    In contexts such as aerospace and other regulated industries:

    – **ERP with MRP** typically manages enterprise-wide inventory, formal stock records, planning, and financial valuation.
    – **MRP within ERP** uses that inventory and BOM data to generate purchase and production plans.
    – **MES and shop-floor systems** manage WIP, point-of-use material consumption, and traceability; they provide actual consumption and status data that should reconcile with the ERP/MRP view.

    Clear data ownership and controlled integration between MES (execution and traceability) and ERP/MRP (planning and financial inventory) are commonly used to avoid divergence between planned and actual material positions.

  • lead time

    Operational meaning

    In industrial and manufacturing contexts, **lead time** commonly refers to the total elapsed time between the initiation of a request and the moment that request is fulfilled. It is typically measured in calendar time (hours, days, weeks) and includes both processing time and waiting time.

    Depending on context, organizations distinguish several types of lead time, for example:

    – **Customer lead time**: From receipt of a customer order to shipment or delivery of finished goods.
    – **Production (manufacturing) lead time**: From release of a work order to the shop floor to completion of the finished product.
    – **Material or supplier lead time**: From placing a purchase order with a supplier to receipt of materials at the plant.
    – **Internal process lead time**: From the start of a defined internal process step (e.g., batch start) to its completion (e.g., batch close, QC release).

    In all cases, lead time is an end-to-end time measure, not just the time when equipment is actively running.

    Use in manufacturing workflows

    In regulated and complex manufacturing systems, lead time is used to:

    – **Plan and schedule production**: Planners use standard lead times to load finite-capacity schedules in MES and ERP systems.
    – **Set inventory and safety stock targets**: Longer and more variable lead times typically drive higher safety stocks to maintain service levels.
    – **Coordinate procurement and logistics**: Material lead times inform reorder points, order frequency, and supplier management.
    – **Assess process performance**: Operations and quality teams monitor actual vs. standard lead times to identify bottlenecks, delays in quality release, or excessive waiting between steps.
    – **Support commitment dates**: Customer service and sales use quoted lead times to provide promised ship dates based on current or modeled capacity.

    Lead time is often tracked at different levels of granularity, such as per product, per routing, per plant, or per supplier.

    Boundaries and what it is not

    Lead time:

    – **Includes**: Queue time, transport time, waiting for materials, changeovers, active processing time, inspections, and administrative delays between defined start and end points.
    – **Does not inherently include**: Cost, resource utilization, or labor effort (although these may correlate with long lead times).
    – **Is not the same as cycle time**: Cycle time often refers to the time to complete a single unit or operation once work begins, while lead time covers the entire end-to-end interval from request to completion.
    – **Is not always fixed**: Lead time can vary with load, product mix, approvals, equipment performance, and quality outcomes; standard lead times in ERP are typically estimates or planning parameters, not guarantees.

    Common confusion and related terms

    Lead time is commonly confused with:

    – **Cycle time**: Usually the time to complete one unit or operation under steady-state conditions. Lead time is broader and includes waiting and non-value-adding time.
    – **Takt time**: A pacing calculation based on customer demand (available time divided by required units). Takt time is a planning concept, not an observed elapsed time like lead time.
    – **Throughput time**: Sometimes used as a synonym for production lead time, but in some methods it may be defined differently. When used precisely, lead time should specify its start and end events.

    To avoid misinterpretation, it is good practice in documentation and system configurations to specify what triggers the start and end of the lead time being measured (for example, “from customer PO creation to goods issue in ERP”).

    Site context: lead time, MES, and safety stock

    Within manufacturing IT/OT and MES discussions, lead time most often refers to **production lead time** and **order-to-ship lead time**. MES and integrated shop-floor systems are commonly used to:

    – Capture actual lead times at operation, order, and batch levels.
    – Increase predictability of lead times by improving schedule adherence and visibility of work-in-progress (WIP) and quality status.
    – Reduce variability in lead times by standardizing workflows, enforcing routings, and improving coordination between production and quality.

    When lead times become shorter and more reliable, organizations may be able to **plan with lower safety stock levels**, because they can respond to demand changes or disruptions more quickly and with greater confidence. In regulated plants, these changes are typically incremental and depend on disciplined process control, validated integrations, and reliable master data.

  • Time Horizon

    Time horizon commonly refers to the specific future period that a plan, forecast, analysis, or commitment is intended to cover. In industrial and manufacturing environments, it defines how far ahead an organization is looking when making decisions about capacity, materials, staffing, technology, or compliance.

    Use in manufacturing and operations

    In manufacturing systems, time horizons are typically described in terms such as short, medium, and long term, each supporting different decisions and systems:

    • Short-term time horizon: Minutes, hours, or days. Used for production scheduling, dispatching work orders, reacting to equipment downtime, and shop-floor sequencing. Often managed in MES, APS, and other OT systems.
    • Medium-term time horizon: Weeks or a few months. Used for master production scheduling (MPS), material requirements planning (MRP), maintenance planning, staffing plans, and quality improvement projects.
    • Long-term time horizon: Many months to multiple years. Used for strategic capacity planning, capital investments, technology roadmaps, product portfolio planning, and long-range compliance or risk programs.

    The defined time horizon determines what data is most relevant, which uncertainties need to be considered, and which systems are involved (for example, MES and APS for short-term, ERP and planning tools for medium and long term).

    Operational considerations

    • Planning and MRP: Time horizons frame the planning buckets for demand forecasts, MRP runs, and supplier schedules. For instance, a 12-week planning horizon vs. a 24-month forecast horizon.
    • Risk and compliance: Time horizons are used when assessing operational risks, audit readiness, and lifecycle management of validated systems (for example, defining a 3-year horizon for system replacement or remediation).
    • Performance metrics: OEE, NPT, and quality indicators can be analyzed over different time horizons (shift, week, quarter, year) to separate short-term variability from structural issues.
    • Projects and roadmaps: Digital transformation, MES deployments, and process-improvement programs often define separate workstreams by time horizon (quick wins vs multiyear initiatives).

    Common confusion

    • Time horizon vs. time bucket: A time horizon is the total length of time being considered (for example, 18 months). Time buckets are the granularity within that horizon (for example, daily, weekly, or monthly periods).
    • Time horizon vs. forecast accuracy window: The time horizon is how far ahead the forecast extends; the forecast accuracy window is the period over which accuracy is evaluated. They may overlap but are not the same concept.

    Context in regulated and high-consequence environments

    In regulated manufacturing, time horizons influence how long records, validation evidence, and configuration histories need to be maintained, and over what period process stability or change control is evaluated. They also shape the planning window for remediation activities or system upgrades that must be coordinated with audits, inspections, and production commitments.

  • Forecasting

    Forecasting is the process of estimating a future condition based on available information such as historical data, current operating signals, known constraints, and expected changes. In manufacturing and industrial operations, it commonly refers to predicting demand, material requirements, production load, maintenance needs, quality trends, or capacity utilization over a defined time horizon.

    Forecasting is not the same as planning or scheduling. A forecast is an estimate of what is likely to happen. Planning uses that estimate to decide what actions to take, and scheduling turns those decisions into time-based execution.

    Where it applies in operations

    Forecasting appears across both business and plant-level workflows, including:

    • demand forecasting for sales, order volume, or customer consumption

    • materials forecasting to anticipate component and raw material needs

    • capacity forecasting for labor, equipment, tooling, and line loading

    • maintenance forecasting based on usage, condition, or failure patterns

    • quality forecasting to identify likely scrap, rework, or nonconformance trends

    • inventory forecasting to estimate stock levels, shortages, or excess

    In integrated environments, forecasting often feeds ERP, MRP, MES, APS, or analytics systems. For example, a demand forecast may drive material planning, while a capacity forecast may highlight upcoming bottlenecks on a constrained work center.

    Common methods

    Forecasts may be generated using simple averages, trend analysis, seasonality models, statistical methods, or machine learning. They may also include judgment from planners, production teams, procurement, or program managers when historical data alone does not reflect upcoming changes such as engineering revisions, customer schedule changes, or supplier disruption.

    The output can be quantitative, such as units per week or machine hours per month, or qualitative, such as expected risk level or likely shortage exposure.

    Common confusion

    Forecasting vs. planning: forecasting estimates future conditions; planning selects responses.

    Forecasting vs. scheduling: scheduling assigns work to dates, shifts, lines, or resources.

    Forecasting vs. prediction: the terms are often used interchangeably, but forecasting usually implies a structured time-based estimate for business or operational use.

    Forecasting vs. MRP: MRP is a planning calculation. It may use forecasts as one input, but it is not itself the forecast.

    Operational note

    Forecasts are usually updated on a recurring cadence because conditions change. In regulated or tightly controlled environments, the forecast itself is typically an analytical input, while the governed records remain the approved plans, orders, routings, specifications, and execution history.

  • cost center

    Core meaning

    A **cost center** is an accounting unit used to collect, attribute, and track costs for a defined part of an organization, such as a department, production line, plant, project, or program. It is primarily a financial and managerial accounting construct rather than a physical asset.

    Cost centers typically aggregate:

    – Direct labor costs
    – Material consumption and scrap
    – Overhead allocations (e.g., utilities, maintenance, support functions)
    – External services linked to that organizational unit or activity

    The purpose is to understand where costs are incurred, support budgeting and variance analysis, and enable internal reporting and management control.

    Use in manufacturing and regulated operations

    In industrial and regulated environments, cost centers commonly map to:

    – Manufacturing areas (e.g., filling line, packaging line, cleanroom suite)
    – Support functions (e.g., quality control lab, maintenance department)
    – Programs or product families (e.g., a specific drug product or device line)

    Enterprise Resource Planning (ERP) systems usually hold the master list of cost centers and record financial postings against them. Manufacturing Execution Systems (MES) and other OT/IT systems may reference cost center identifiers to:

    – Associate labor time booked on a work order with the correct cost center
    – Attribute material issues, consumption, and scrap to the appropriate area
    – Summarize production activities by cost center for periodic transfer into ERP

    In many plants, MES and ERP exchange cost-center-related data at defined intervals (e.g., end of shift or end of batch) rather than in real time, using stable cost center IDs for reconciliation and program cost tracking.

    Boundaries and exclusions

    A cost center:

    – **Is an accounting view**, not necessarily a single machine or physical asset, although it may correspond to a specific line or area.
    – **Does not by itself define profitability**; it records costs, not revenue. Profit and loss are usually analyzed at higher-level constructs such as profit centers or business units.
    – **Is not the same as a work center** in manufacturing planning terms. A work center usually represents a physical resource or group of resources used for scheduling and capacity planning. A cost center represents where costs are collected in financial records. One cost center may include multiple work centers, or vice versa, depending on the organization’s mapping.

    Common confusion and related terms

    – **Cost center vs. profit center**: A profit center tracks both costs and revenues, enabling profitability analysis. A cost center mainly tracks costs and is evaluated on cost control and efficiency, not direct profit.
    – **Cost center vs. GL account**: A general ledger (GL) account classifies the *type* of cost (e.g., labor, materials), while the cost center indicates *where* in the organization that cost is incurred.
    – **Cost center vs. project code / WBS element**: Project codes or work breakdown structure (WBS) elements track costs for a specific project or initiative. These may be used in addition to cost centers or mapped alongside them for more granular tracking.

    Site context: MES–ERP program cost tracking

    In the context of MES–ERP integration for program or product cost tracking, cost centers commonly:

    – Serve as stable identifiers shared between MES and ERP to align labor and material usage with the correct organizational unit or program
    – Provide the financial dimension against which summarized consumption, scrap, and labor data from MES are posted in ERP
    – Form part of the structure used by finance to calculate and review manufacturing cost per product, batch, or program without requiring real-time, bidirectional coupling between MES and ERP

  • bill of materials

    Core meaning

    A **bill of materials** (BOM) is a structured list that specifies all components, raw materials, subassemblies, and sometimes services required to manufacture a defined product or execute a defined batch, including their quantities and basic identifying information.

    In industrial and regulated manufacturing environments, the BOM commonly:

    – Is defined and maintained in ERP, PLM, or product definition systems
    – Includes material identifiers, descriptions, units of measure, and required quantities
    – References engineering or product revisions to tie materials to a specific version of the product
    – Serves as a reference for planning, procurement, inventory management, and production execution

    A BOM describes **what** is needed to build a product, not **how** or **when** work is performed.

    Typical structure and levels

    BOMs are often hierarchical and may include:

    – **Top-level (finished good) BOM**: Lists main subassemblies and key materials that make up the final product
    – **Subassembly BOMs**: Define components for intermediate assemblies used within the top-level product
    – **Phantom or logical BOMs**: Groupings used for planning or design that may not exist as separate stocked items

    Depending on system and practice, BOMs may also identify alternates or substitutes, packaging materials, and labeling components when they are explicitly required to produce or release the product.

    Use in manufacturing workflows

    In integrated manufacturing environments, BOMs are used to:

    – Drive **material requirements planning** (MRP) and procurement in ERP systems
    – Define expected material consumption for **costing** and financial tracking
    – Inform **MES** or other shop-floor systems of required components for an order or batch
    – Support **traceability** by providing the expected structure against which actual material lots or serials are recorded

    During production, the BOM is typically linked to:

    – A **routing** or process definition (how work is done)
    – **Work orders**, production orders, or batch records (what is executed and when)
    – **Material master** data for each item listed

    Site context: BOM in MES–ERP integration and costing

    For program or product cost tracking across MES and ERP, the BOM commonly:

    – Resides and is maintained in ERP or PLM as the **authoritative product structure**
    – Provides the expected component list and standard quantities used to calculate standard or planned costs
    – Acts as the reference against which MES reports **summarized actual consumption** (by material ID and quantity) back to ERP at defined intervals

    In this context, MES usually does not author the BOM but uses it to validate material usage and ensure that recorded consumption aligns with the qualified product definition.

    Boundaries and exclusions

    A bill of materials **includes**:

    – Physical components, raw materials, and subassemblies
    – Sometimes non-stock items when they are integral to product composition (e.g., labels, certain consumables)

    A bill of materials **does not inherently include**:

    – Detailed work instructions, sequence of operations, or cycle times (these belong to routings or manufacturing instructions)
    – Real-time production data or yield results
    – Quality tests and acceptance criteria (these are typically defined in specifications or control plans)

    Some organizations maintain separate BOM types, such as **engineering BOM (EBOM)** and **manufacturing BOM (MBOM)**, to distinguish design intent from the structure used for actual manufacturing and sourcing.

    Common confusion and related terms

    – **BOM vs. recipe/formula**: In process industries, a *recipe* or *formula* includes process parameters and instructions in addition to material quantities. The BOM portion is the structured list of materials and quantities.
    – **BOM vs. routing**: A BOM defines *what materials* are required; a routing defines *how and in what sequence* operations are performed.
    – **BOM vs. product specification**: Specifications describe properties and performance requirements; the BOM lists the materials that make up the product.

    Understanding these distinctions helps ensure that BOMs are used consistently for planning, costing, and execution across ERP, MES, and quality systems.

  • part family

    A part family is a group of parts that share common characteristics and are intentionally classified together so they can be planned, produced, and analyzed as a unit. In industrial and manufacturing environments, part families are often based on similarities in design, material, features, manufacturing processes, or the equipment and tooling used.

    Key characteristics

    Part families commonly share one or more of the following:

    • Similar geometry or design features, such as hole patterns, profile shapes, or envelope dimensions
    • Common materials or material groups, such as aluminum forgings, composite layups, or stainless steel turned parts
    • Comparable routings or process steps, such as the same sequence of machining, heat treatment, coating, or inspection
    • Use of the same work centers, cells, tools, fixtures, or programs
    • Shared performance, quality, or traceability requirements, such as the same specification family or qualification level

    Part families can be defined formally in master data (for example, in ERP, MES, or PLM) using codes or attributes, or informally in production and engineering documents. In regulated industries, formal definitions are typically favored so that reporting and evidence are consistent across systems.

    Operational use

    In day-to-day operations, part families are used to:

    • Plan capacity and scheduling by grouping similar demand on shared resources
    • Standardize routings, work instructions, and inspection plans across related parts
    • Analyze performance metrics, such as scrap, rework, cycle time, and on-time delivery, at a level more stable than individual part numbers
    • Support cost modeling, quoting, and product standardization by treating similar parts consistently
    • Structure continuous improvement work, for example by targeting a machining cell’s main part families

    Use in scrap and cost analysis

    When building scrap or cost views, part families provide an intermediate level of aggregation between individual part numbers and entire programs or product lines. For example, an aerospace manufacturer may group different brackets, ribs, or fittings into part families that share raw material, machining steps, or inspection regimes, then compare scrap rate and scrap cost by family across cells, shifts, or suppliers.

    Common confusion

    • Part family vs. part number: A part number uniquely identifies a specific item. A part family is a classification that can include many different part numbers.
    • Part family vs. product family: A product family usually groups finished products or configurations offered to customers. A part family groups components or subassemblies used inside products or programs, for manufacturing and engineering purposes.
    • Part family vs. routing family or process family: A routing or process family groups operations or process templates. A part family may be defined using routing similarities, but it is anchored to the parts themselves, not the operations.