Connect981 – Content Dev

FAQ Tag: brownfield integration

  • How do digital execution platforms support cross-factory comparability?

    They support it by making plants record work, quality events, material usage, and production status in a more consistent way. In practice, cross-factory comparability comes from shared data definitions, controlled workflows, common KPI logic, and versioned change control, not from the software alone.

    A digital execution platform can help create that consistency by:

    In practice, this connects to ISO 22400 KPI governance when teams need to turn the answer into repeatable execution habits.

    • enforcing common process steps, data fields, reason codes, and status models across sites where standardization is appropriate

    • linking execution records to approved routings, work instructions, specifications, and revision history

    • capturing time, quantity, scrap, rework, holds, inspections, and exceptions at the point of execution instead of after-the-fact spreadsheet reconstruction

    • normalizing event timestamps and transaction structures so analytics are based on comparable operational records

    • providing role-based approvals and audit trails for local deviations, site-specific variants, and process changes

    That said, the answer is not simply yes in every environment. Comparability depends on whether the sites are actually operating against a shared model. If one factory counts queue time inside cycle time, another excludes it, and a third books completions in ERP at shift end, the platform will expose the inconsistency, but it will not automatically fix it.

    What has to be standardized

    For meaningful cross-factory comparison, organizations usually need alignment on a few basics:

    • product, part, operation, resource, and location master data

    • common definitions for scrap, rework, nonconformance, downtime, yield, completion, and WIP state changes

    • shared KPI formulas and reporting cutoffs

    • revision control for work instructions, routings, and inspection requirements

    • rules for local extensions so plants can differ where they must without corrupting enterprise reporting

    Without that governance, a multi-site dashboard may look standardized while still comparing unlike data.

    Brownfield reality

    Most manufacturers do not start with a clean slate. Cross-factory comparability usually has to coexist with different ERP instances, legacy MES deployments, paper-based areas, machine interfaces of uneven quality, and local quality systems. In those environments, the platform often acts as a coordination layer rather than a full replacement.

    That is usually the more realistic path. Full replacement across all sites often fails in regulated, long-lifecycle operations because qualification effort, validation burden, downtime risk, integration complexity, and traceability obligations are too high. A staged approach is more common: standardize key execution objects and event definitions first, integrate to existing systems where necessary, and expand only after data quality is proven.

    What the platform can and cannot do

    It can make differences visible, reduce manual interpretation, and improve confidence that plants are reporting against the same controlled structures. It can also preserve traceability when a site uses an approved local variant rather than forcing hidden workarounds.

    It cannot make two factories directly comparable if they have materially different products, routing depth, automation levels, labor models, lot sizing, or regulatory constraints. In those cases, comparison may need to happen at a narrower level, such as operation family, product family, process type, or exception category, rather than at a plant headline KPI level.

    Practical tradeoffs

    • More standardization improves comparability, but can reduce local flexibility.

    • More local configurability speeds adoption, but can weaken enterprise reporting unless tightly governed.

    • Broader integration improves completeness, but increases validation effort and failure points.

    • Richer data capture helps root-cause analysis, but adds operator burden if the workflow is poorly designed.

    The strongest result is usually not one global template forced everywhere. It is a governed common core with controlled site-level variation, clear semantic rules, and traceable changes over time. That is what turns multi-plant reporting from a presentation exercise into something operations, quality, and leadership can actually trust.

  • How should aerospace manufacturers integrate supplier portals with existing ERP systems?

    Aerospace manufacturers should usually integrate supplier portals with existing ERP systems incrementally, with the ERP remaining the financial and planning system of record unless there is a strong, validated reason to do otherwise.

    In practice, that means the portal should exchange specific transactions and documents with ERP rather than bypass it. Common examples include purchase orders, acknowledgments, shipment notices, receipts, supplier quality actions, certifications, outside processing status, and limited inventory or promise-date updates.

    In practice, this connects to materials planning and erp integration when teams need to turn the answer into repeatable execution habits.

    What a practical integration approach looks like

    • Define system roles first. Decide which system owns supplier master data, item master data, approved supplier lists, purchase orders, due dates, receipts, and quality records. If ownership is ambiguous, integration becomes unreliable quickly.

    • Start with a narrow scope. A phased rollout is usually safer than a broad supplier digitization program. Many plants start with PO visibility and acknowledgment, then add ASN or shipment status, then supplier quality workflows, then outside processing or tier visibility if needed.

    • Use an integration layer where possible. Point-to-point connections between a portal and ERP can work for a small footprint, but they become fragile in brownfield environments with multiple ERP instances, MES, QMS, PLM, and EDI traffic. A controlled middleware or API management layer usually improves mapping, monitoring, retry handling, and change control.

    • Preserve traceability. Transaction history, document revisions, supplier responses, and status changes should be attributable, time-stamped, and retained according to internal requirements. This matters when portal activity affects receiving, quality decisions, or shipment release.

    • Separate collaboration from execution authority. Let suppliers collaborate through the portal, but avoid allowing uncontrolled changes to ERP commitments, approved revisions, or compliance-relevant records without defined workflow and approval gates.

    Key design decisions

    • Real-time versus batch: Real-time APIs support faster response and exception handling, but they increase dependency on uptime, interface resilience, and error recovery. Batch integration is simpler in some legacy environments, but it can create timing gaps that affect planning, receiving, and expedite decisions.

    • Portal data model versus ERP data model: Do not assume they align cleanly. Supplier part numbers, revision schemes, unit-of-measure handling, packaging hierarchies, and lot conventions often differ. A canonical mapping approach is often necessary.

    • Document exchange versus structured data exchange: Uploading PDFs and spreadsheets may be easier initially, but it limits automation and creates review burden. Structured transactions are more scalable, but require stronger data governance and testing.

    • Single portal versus federated model: A single enterprise portal can simplify governance, but may be difficult to align across business units, acquired sites, or mixed ERP estates. A federated approach may fit reality better, but increases standardization effort.

    What to integrate first

    The best first integrations are usually the ones with clear business value and low ambiguity:

    • PO release and acknowledgment status

    • Promised date updates with approval workflow

    • ASN or shipment notification

    • Receiving reconciliation

    • Certificate and required document submission

    • Supplier NCR or corrective action workflows tied back to ERP or QMS references

    More complex functions such as multi-tier visibility, supplier-managed inventory, delegated inspection, and revision-sensitive technical data exchange should usually come later. They carry more risk around data consistency, export-controlled information, and process variation between suppliers.

    Brownfield realities to plan for

    Most aerospace manufacturers are not integrating a new portal into a clean architecture. They are dealing with legacy ERP customizations, multiple plants, acquired business units, old EDI maps, manual spreadsheets, supplier-specific exceptions, and long-established receiving or quality processes.

    That is why full replacement strategies often fail. Replacing ERP or forcing all supplier interaction into a new portal can create a large qualification and validation burden, increase downtime risk, break traceability across existing MES, QMS, and PLM links, and disrupt plants that rely on long-lived equipment and mature but customized workflows. In many regulated environments, coexistence is the lower-risk path.

    Controls that matter in regulated environments

    • Change control: Interface changes, field mappings, workflow changes, and supplier onboarding rules should be versioned and formally reviewed.

    • Validation: If portal transactions affect product acceptance, traceability, required records, or quality decisions, test accordingly. The level of rigor depends on how the workflow is used and what records it creates or influences.

    • Security and access: Supplier access should be scoped to the minimum necessary data and transactions. This is especially important where technical data, controlled drawings, or defense-related information may be exposed.

    • Error handling: Plan for failed message delivery, duplicate transactions, stale status, partial acknowledgments, and mismatched revisions. These are common failure modes, not edge cases.

    • Auditability: You need a reliable way to show who submitted what, when it changed, what was accepted into ERP, and what was rejected or corrected.

    Common failure modes

    • Poor supplier and item master data causes mismatches and manual rework

    • Portal workflows are implemented without alignment to receiving, quality, and purchasing processes

    • Suppliers are asked to maintain duplicate data in email, spreadsheets, EDI, and the portal

    • Revision-sensitive documents are shared without clear release and supersession rules

    • Exceptions are handled outside the system, eroding trust in portal data

    • Internal teams assume integration is complete when only data transport is working, not the business process

    Recommended operating model

    A practical model is to let ERP remain authoritative for planning, purchasing, and financial transactions, while the supplier portal manages collaboration, document collection, status capture, and supplier-facing workflow. Use integration services to synchronize only the data that must cross systems, with explicit ownership, validation rules, and reconciliation reporting.

    If a manufacturer has strong process maturity and a well-governed integration architecture, the portal can take on more workflow responsibility over time. If not, keeping the portal focused on a limited set of high-value interactions is often the safer choice.

    So the short answer is: integrate supplier portals with ERP through controlled, phased, traceable interfaces, not by trying to replace ERP or by allowing the portal to become an unmanaged shadow system. The right design depends on data quality, supplier readiness, cybersecurity requirements, and how tightly the portal touches quality and traceability processes.

  • Why do our OEE numbers differ between plants even with the same formula?

    Because using the same OEE formula does not mean the plants are measuring the same thing.

    In most multi-plant environments, the gap is caused by differences in definitions, data capture, and operating context rather than the arithmetic itself. Two sites can both calculate Availability × Performance × Quality and still produce materially different numbers if they classify time, downtime, scrap, startup loss, rework, or planned stops differently.

    In practice, this connects to operational visibility when teams need to turn the answer into repeatable execution habits.

    What usually causes the mismatch

    • Different time bases. One plant may calculate against scheduled production time, another against staffed time, and another may exclude meetings, preventive maintenance, changeovers, or engineering holds.

    • Different stop classifications. Microstops, waiting on material, first-piece inspection, tooling changes, quality holds, and operator breaks are often treated differently by site, line, or even shift.

    • Different ideal cycle assumptions. Performance depends heavily on the standard rate or ideal cycle time. If one plant uses engineered standards and another uses historical averages, the comparison is not equivalent.

    • Different quality counting rules. Some sites count only final scrap in Quality. Others include rework, yield loss at intermediate steps, or inspection rejects at different points in the routing.

    • Different automation levels. A highly instrumented line will capture short stops and speed loss that a manual line may never record consistently.

    • Different production models. High-mix, low-volume operations, batch processes, continuous processes, and heavily regulated inspection steps do not generate losses in the same pattern. OEE can still be useful, but direct cross-plant comparison may be misleading without context.

    • Different master data and routing discipline. Inaccurate work centers, obsolete cycle times, inconsistent part-family setup rules, and weak maintenance of routings will distort OEE even if plant teams believe the metric is standardized.

    • Different exclusion rules. Plants often remove special causes from reporting after the fact, such as customer holds, trial runs, validation batches, qualification work, or ERP scheduling gaps. Those choices change the number substantially.

    • Different system integration behavior. MES, SCADA, historians, machine gateways, ERP, and manual logs may not agree on order status, start and stop timestamps, scrap posting timing, or completed quantity. The formula only reflects the data it receives.

    Brownfield reality

    In mixed-vendor environments, cross-plant OEE differences are common. Plants often run different MES versions, different machine connectivity layers, different ERP posting patterns, and different local workarounds. That means the metric definition may look standardized in a slide deck while the source events are still inconsistent at the shop floor level.

    This is also why full replacement is often not the practical answer. Replacing every execution and reporting system to force metric consistency can fail due to validation cost, qualification burden, downtime risk, integration complexity, and the fact that long-lived equipment often cannot be modernized uniformly. In regulated operations, a controlled semantic alignment effort is usually more realistic than a wholesale platform reset.

    What to standardize if you want comparable OEE

    If the goal is true cross-plant comparison, standardize the operating definitions before debating the formula:

    • The production time model and what is included or excluded

    • A canonical event taxonomy for downtime, speed loss, startup loss, and quality loss

    • Rules for microstops, changeovers, preventive maintenance, inspection, and waiting states

    • The source of ideal cycle time or standard rate

    • How rework, scrap, and first-pass yield relate to Quality

    • How manual overrides are approved and traceable

    • Version control and change control for KPI definitions, routings, and master data

    • Data reconciliation rules across MES, ERP, historians, and machine data sources

    Without that governance, cross-site OEE becomes a local reporting convention, not a reliable enterprise KPI.

    What OEE can and cannot tell you

    OEE is useful for identifying loss within a given operating context. It is much less reliable as a raw leaderboard across plants with different product mix, labor models, inspection intensity, automation maturity, and data quality. A lower OEE does not automatically mean a plant is performing worse. It may mean that site records losses more honestly, runs more complex work, or includes regulated activities another plant excludes.

    So the short answer is yes, your numbers can differ even with the same formula, and that is normal when definitions, data readiness, and process discipline are not harmonized. If executive decisions depend on plant-to-plant comparison, standardize semantics, trace the data lineage, and validate the calculation logic by site before treating the output as comparable.

  • How granular should a manufacturing KPI taxonomy be for aerospace operations?

    It should be granular enough to support root cause analysis, traceability, and operational decisions, but not so granular that every site, program, cell, or supervisor invents a different metric definition.

    For most aerospace operations, a practical answer is a layered KPI taxonomy:

    In practice, this connects to data mapping and system interoperability when teams need to turn the answer into repeatable execution habits.

    • Level 1: enterprise-standard KPI families such as delivery, quality, flow, labor, inventory, and compliance-related execution measures.
    • Level 2: controlled sub-metrics by process context, such as machining, composites, assembly, inspection, outside processing, rework, or MRB impact.
    • Level 3: local analytic cuts by program, part family, work center, shift, supplier, or routing step, but only as dimensions, not as entirely new KPI definitions.

    In other words, the taxonomy should be coarse at the definition level and fine at the analysis level. That is usually the best balance for aerospace.

    What good granularity looks like

    A KPI taxonomy is too shallow if it hides operational reality. For example, one plant-level on-time delivery number may not distinguish between shortages, traveler errors, inspection backlog, concession activity, or outside processing delays. In aerospace, that loss of context makes the metric weak for action and weak for auditability.

    A KPI taxonomy is too deep if definitions multiply faster than governance. If one site tracks yield at operation level, another at work order close, and a third includes rework recovery while a fourth excludes it, leadership gets a dashboard but not a comparable management system.

    A useful rule is this: create a new KPI definition only when the calculation logic, business meaning, or required evidence is materially different. If the difference is just plant, program, customer, part family, or shift, that usually belongs as a filter or dimension.

    Why aerospace usually needs more context than generic manufacturing

    Aerospace operations often need more segmentation than a generic factory because performance is affected by high-mix low-volume routings, long cycle times, inspection gates, nonconformance handling, serialized or lot-controlled traceability, and outsourced special processes. A single top-level KPI rarely explains performance without these dimensions.

    That said, more granularity only helps if the source data is stable. If MES, ERP, QMS, and shop floor data collection are inconsistent, a highly detailed taxonomy can create false precision. The system may look mature while the underlying timestamps, status codes, scrap reasons, labor booking, and routing states are still unreliable.

    Recommended design pattern

    • Standardize KPI names, formulas, and exclusion rules centrally.
    • Standardize dimensions and hierarchies such as site, program, value stream, cell, routing step, supplier, and disposition category.
    • Allow local drill-downs without allowing local redefinition of the core KPI.
    • Document data lineage back to system sources and transaction events.
    • Version-control definitions so metric changes follow change control, not dashboard edits.
    • Map each KPI to operational decisions, not just executive reporting.

    That last point matters. If no one can say what action should change when a KPI moves, the taxonomy is probably too detailed, too vague, or both.

    Brownfield reality

    In a brownfield aerospace environment, KPI granularity is constrained by existing systems. Legacy MES may capture operation completion differently from ERP labor postings. QMS may classify nonconformances in a way that does not align cleanly with production loss categories. Supplier portals, spreadsheets, and manual inspection logs often fill gaps. Those constraints should shape the taxonomy.

    Do not assume a clean, single-system model. In many plants, the right approach is to define a canonical KPI layer above existing systems and map local source fields into it over time. That is usually more realistic than trying to replace MES, ERP, PLM, and QMS just to make KPI definitions cleaner.

    Full replacement strategies often fail here because qualification burden, validation effort, downtime risk, integration complexity, and long equipment or process lifecycles are hard to absorb. A KPI taxonomy should therefore be designed to coexist with mixed systems and uneven data maturity.

    Tradeoffs to manage

    • More granularity improves diagnosis, but increases governance overhead.
    • Fewer KPI definitions improve comparability, but can hide process-specific failure modes.
    • Local flexibility improves adoption, but can damage cross-site consistency.
    • Highly detailed rollups look precise, but may become misleading if timestamps, reason codes, or transaction discipline are weak.

    If your organization cannot maintain definition governance, source mapping, and metric change control, reduce definition complexity before adding more detail.

    Practical benchmark

    For many aerospace organizations, a reasonable target is:

    • 10 to 20 enterprise KPIs with strict definitions
    • 2 to 5 approved sub-metric groups per KPI family
    • multiple standard dimensions for slicing rather than hundreds of bespoke KPI names

    The exact number depends on process diversity, reporting obligations, system maturity, and whether the business is production, defense, sustainment, or mixed-mode. There is no universal number that is correct across all sites.

    So the short answer is: make the taxonomy granular at the dimension and causality level, not endlessly granular at the KPI-definition level. In aerospace, that usually gives the best balance of comparability, traceability, and operational usefulness.

  • How do we manage user resistance when KPI numbers change?

    User resistance usually means people do not trust the measurement change, not that they oppose improvement in principle. If KPI numbers change, the first step is to assume the skepticism may be justified until you can show exactly what changed in the definition, data source, timing, calculation logic, and scope.

    In practice, manage it as a controlled change to the measurement system.

    In practice, this connects to data mapping and system interoperability when teams need to turn the answer into repeatable execution habits.

    What to do first

    • State the change explicitly. Document what changed, when it changed, which KPIs are affected, and whether historical numbers were restated or left as originally reported.

    • Separate performance change from measurement change. If a metric moved because of a new calculation, different source system, revised routing, cleaner downtime coding, or better scrap capture, say that plainly. Do not present it as an operational improvement or decline unless the underlying process actually changed.

    • Keep the old and new views in parallel for a period. A temporary bridge period reduces argument and helps leadership see the delta caused by the method change versus the delta caused by actual execution.

    • Show lineage. Users need to trace the KPI back to source records, timestamps, status rules, and exclusions. If they cannot reconcile the number to known events on the floor, resistance will persist.

    • Validate before broad rollout. Test the revised KPI with supervisors, quality, engineering, and finance or operations analysts who understand the process details. Many KPI disputes are really disputes about transaction timing, master data quality, and exception handling.

    What usually causes resistance

    • People are being judged, staffed, or rewarded on the number.

    • The revised KPI breaks trend continuity, so prior targets no longer mean the same thing.

    • Different systems produce different answers for the same process.

    • The new logic exposes hidden loss categories that were previously ignored or coded elsewhere.

    • Users were not involved early enough to identify edge cases.

    • There is no approved glossary, ownership model, or change control for metric definitions.

    If any of those conditions exist, resistance is predictable. It is not solved by more dashboard training alone.

    How to reduce conflict without weakening governance

    • Use formal KPI governance. Assign an owner for each KPI definition, approval path, effective date, and revision history.

    • Publish the business rules. Include inclusions, exclusions, reclassification rules, cutoff logic, and source-system precedence.

    • Require evidence for disputes. If operators or managers claim a number is wrong, route that through a defined review process tied to source data, not informal debate.

    • Reset targets carefully. If the metric basis changed materially, old targets may no longer be valid. Keeping the target unchanged can create avoidable distrust.

    • Train by role. Executives need interpretation limits, plant leaders need exception logic, and front-line users need to know what transactions or events drive the KPI.

    Brownfield reality

    In mixed MES, ERP, historian, QMS, spreadsheet, and BI environments, KPI changes often surface old integration debt rather than new insight. A number may shift because one system records completion at operation close, another at labor post, and another after quality disposition. That is not a communications issue. It is a data mapping and governance issue.

    Trying to eliminate resistance by replacing every legacy system is usually unrealistic in regulated, long-lifecycle operations. Full replacement often fails because of qualification burden, validation cost, downtime risk, integration complexity, and the need to preserve traceability and controlled change across interconnected processes. In many plants, the practical path is coexistence: define canonical KPI logic, document source precedence, validate interfaces, and phase changes in with auditability.

    What not to do

    • Do not tell users to trust the system if reconciliation is incomplete.

    • Do not relabel a definition change as a performance improvement.

    • Do not force one enterprise number if local process states are not mapped consistently.

    • Do not back-cast historical data without clearly marking what was recalculated and what assumptions were used.

    • Do not tie compensation or corrective action to a newly changed KPI until the method is stable and understood.

    The short answer is that resistance is managed through transparency, controlled change, traceability, and a temporary reconciliation period. If the revised KPI is better, users will accept it faster when they can see exactly how it was built, what its limits are, and how it coexists with the systems they already use.