Connect981 – Content Dev

FAQ Category: cross-plant standardization

  • 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.

  • 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.

  • What is the best way to manage daylight savings time in KPI reporting?

    The best practice is to use UTC as the system time of record for events, keep the plant or asset local timezone as metadata, and apply timezone conversion only at the reporting layer under controlled rules.

    That is usually the least risky approach for KPI reporting because daylight saving time creates two known problems in local time:

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

    • In the spring, one local hour does not exist.

    • In the fall, one local hour occurs twice.

    If your KPIs are calculated directly from local timestamps without explicit handling for those cases, hourly trends, shift totals, downtime buckets, utilization, OEE, and SLA-style metrics can be wrong. The error may be small for some dashboards and material for others.

    What to do in practice

    • Store raw event time in UTC. This should apply to machine events, transactions, alarms, operator actions, historian records, and integration messages where possible.

    • Store timezone context separately. Keep the site timezone, and if relevant, the production line or asset timezone. Do not assume all plants operate in the same zone.

    • Define reporting rules for local-period KPIs. If management wants reporting by local shift, local day, or local hour, document exactly how DST transition periods are handled.

    • Use timezone-aware libraries and databases. Hard-coded DST offsets and manual calendar logic tend to fail over time.

    • Test both DST transition dates. Validate spring-forward and fall-back behavior in calculations, dashboards, exports, and interfaces.

    • Version-control the KPI definition. If a report changes from local-time aggregation to UTC-first aggregation, treat that as a governed metric change, not a cosmetic edit.

    How to report hourly and shift KPIs

    There is no single universal answer because the right method depends on how the KPI is used.

    • For cross-site comparison: UTC-based aggregation is usually more consistent.

    • For plant operations review: local-time presentation is often necessary, but the aggregation logic still needs to account for missing or repeated hours.

    • For shift-based accountability: tie the KPI to the scheduled shift definition, not just a clock hour. A shift on a DST transition day may be shorter or longer than nominal.

    For example, a night shift during the fall transition may contain 9 clock hours in local time, while the spring transition may contain 7. If your reporting system forces every shift to 8 hours without exception, some metrics will be distorted. Whether that is acceptable depends on the business rule, but it should be intentional and documented.

    What to avoid

    • Do not let each dashboard author handle DST differently.

    • Do not rely on spreadsheet adjustments as the main control.

    • Do not overwrite original timestamps after conversion.

    • Do not assume ERP, MES, SCADA, historians, and BI tools all interpret timezone data the same way.

    • Do not hide the issue by summarizing only daily values if hourly and shift-level decisions matter.

    Brownfield reality

    In many plants, you will not be able to standardize this instantly. Older MES, historians, PLC-connected systems, custom integrations, and ERP extracts may already store local time differently, or with incomplete timezone metadata. Some systems can be changed easily; others cannot without validation effort, downtime risk, or downstream reporting impact.

    In that environment, the practical approach is usually coexistence:

    • leave source systems unchanged if changing them would create unnecessary operational risk,

    • normalize timestamps in the integration or data platform layer,

    • add a governed semantic rule for KPI aggregation, and

    • document system-by-system exceptions.

    A full replacement just to solve DST handling is rarely justified in regulated, long-lifecycle operations. The qualification burden, integration complexity, downtime risk, and report revalidation effort are often larger than the timing issue itself.

    Bottom line

    The best way is not to “manage DST” manually in KPI reports. It is to design time handling so DST becomes a controlled reporting rule rather than a recurring data-quality defect: UTC for system record, local timezone retained as context, explicit aggregation rules for local operational KPIs, and validation of edge cases before the numbers are trusted.

  • How long does a typical Connect 981 rollout take for one aerospace site?

    A typical Connect 981 rollout for one aerospace site is usually measured in months, not weeks. For a constrained first phase, many sites should expect roughly 8 to 16 weeks. A broader site rollout that covers multiple process areas, more integrations, and stricter validation activity can extend to 4 to 9 months or longer.

    That range is wide because the timeline is rarely driven by software configuration alone. In aerospace environments, rollout speed usually depends more on process clarity, master data quality, approval cycles, integration debt, and how much evidence the organization requires before putting the system into routine use.

    In practice, this connects to implementation and adoption playbooks when teams need to turn the answer into repeatable execution habits.

    What most affects the timeline

    • Scope of the first phase: One line, one cell, or one workflow is much faster than a site-wide deployment.

    • Existing system landscape: If Connect 981 must coexist with ERP, MES, PLM, QMS, document control, or inspection systems, integration and testing can add substantial time.

    • Data readiness: Part masters, routings, work instructions, user roles, and revision-controlled documents often need cleanup before rollout.

    • Validation expectations: In regulated operations, configuration review, test evidence, traceability, and change control commonly lengthen the schedule.

    • Operational availability: Plants with limited downtime windows, overloaded SMEs, or active customer programs usually move more slowly.

    • Adoption model: Operator training, supervisor buy-in, and phased cutover planning can be the pacing item, especially in brownfield sites.

    What a realistic rollout pattern looks like

    A practical pattern is to start with a limited, high-value use case, prove data flows and operator adoption, then expand. That first phase may cover a single workstream such as digital work instructions, traveler execution, traceability capture, or a targeted quality workflow. Expansion after that is usually faster, but only if the initial interfaces, governance, and support model were designed well.

    No, a full site replacement of existing systems is usually not the fastest path in aerospace. In long-lifecycle, regulated environments, rip-and-replace programs often stall because of qualification burden, validation cost, downtime risk, interface complexity, and the need to preserve traceability across legacy processes. Coexistence is usually more realistic than full replacement.

    What can delay a rollout

    • Unclear ownership of process decisions

    • Poorly controlled document revisions

    • ERP or PLM interface changes outside the original scope

    • Late cybersecurity or infrastructure reviews

    • Unexpected exceptions in real production workflows

    • Need to support both paper and digital processes during transition

    If you need a planning number, use 2 to 4 months for a disciplined pilot or initial site phase, and 4 to 9 months for a broader production rollout at one aerospace site. If the site has heavy legacy dependencies, weak data governance, or extensive validation requirements, the timeline can exceed that.

    The most accurate answer depends on the specific scope, integration points, validation approach, and readiness of the site team.

  • What is the primary purpose of ISA-95?

    The primary purpose of ISA-95 is to provide a standardized model and common language for integrating business systems (such as ERP and planning) with manufacturing operations and control systems (such as MES, SCADA, DCS, and equipment controllers). It focuses on what information needs to be exchanged between levels of the manufacturing stack, and how to structure that information consistently, so that interfaces can be designed, implemented, and maintained more reliably over long equipment lifecycles.

    What ISA-95 is trying to solve

    In most plants, especially brownfield environments, business and shop-floor systems come from different vendors, generations, and integration styles. Each tends to use its own naming, data models, and message formats. ISA-95 addresses this by:

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

    • Defining clear functional boundaries between enterprise planning, manufacturing operations, and control systems.
    • Standardizing core information objects (such as material, equipment, personnel, production schedule, production performance, and quality information).
    • Providing consistent models for manufacturing operations management (production, maintenance, quality, inventory) to reduce ambiguity in integration specifications.

    The intent is not to replace your ERP, MES, or control systems, but to make their interactions more predictable, traceable, and easier to maintain under change control.

    What ISA-95 is not

    • It is not a turnkey integration or a software product. It is a set of models and standards that must be interpreted and implemented.
    • It does not guarantee compliance, audit success, or data integrity by itself. Those outcomes depend on system configuration, validation, and procedures.
    • It does not define every detail of message formats for all vendors. Many implementations still require mapping and compromises.

    Why it matters in regulated, long-lifecycle environments

    In regulated manufacturing, integration changes are expensive to validate and risky to deploy. ISA-95 helps by:

    • Providing a stable reference model that can be reused across lines, plants, and vendors, reducing one-off integration designs.
    • Improving traceability of what data is exchanged and why, which supports change impact assessment and documentation.
    • Reducing the tendency to do full system replacement just to fix integration problems, which often fails due to qualification burden, downtime risk, and integration complexity.

    However, actual benefits depend heavily on how consistently the standard is applied across projects and suppliers, and on the maturity of your integration governance.

    Coexistence with existing systems

    Most plants use ISA-95 selectively rather than as a complete, pure implementation. Common patterns include:

    • Using ISA-95 models to design new ERP-to-MES or MES-to-L2 interfaces while leaving legacy point-to-point integrations in place.
    • Adopting ISA-95 terminology and object structures in integration specifications, even when underlying systems keep their native data models.
    • Incrementally refactoring existing interfaces toward ISA-95-aligned objects (for example, standardizing how production orders and equipment states are represented) instead of a big-bang rearchitecture.

    This incremental approach is usually more realistic in regulated environments, where any interface change can trigger revalidation, documentation updates, and retraining.

    Key takeaway

    The primary purpose of ISA-95 is to provide a common, structured framework for integrating enterprise and manufacturing systems. It reduces ambiguity and integration risk by standardizing how manufacturing information is modeled and exchanged, but it does not remove the need for careful design, mapping, validation, and long-term change control in real plants.

  • What are realistic AI use cases for AS9102 data today?

    AI can add practical value around AS9102 today, but mostly as an assistive layer on top of existing FAIs, not as an autonomous decision-maker. What is realistic depends heavily on how your AS9102 data is captured (PDF vs structured fields), how consistent ballooning and characteristic IDs are, and how integrated your PLM/MES/QMS landscape is.

    1. Searchable, normalized access to historical FAIs

    The most achievable use case is treating AI as an interface to your AS9102 history, especially where records are scattered across Net-Inspect, MES, QMS, shared drives, and ERP.

    In practice, this connects to digital AS9102 FAI when teams need to turn the answer into repeatable execution habits.

    • Indexing AS9102 forms, ballooned drawings, and related inspection reports to make them text-searchable.
    • Normalizing basic metadata (part number, revision, supplier, work center, program, date, disposition) so you can filter and query consistently across systems.
    • Using AI-assisted search (natural language queries) to quickly find similar parts, prior FAIs on the same feature set, or previous dispositions for a given characteristic.

    This is usually the first step because it does not change the underlying quality process; it just reduces time spent hunting through legacy data.

    2. Characteristic and ballooning assistance

    With reasonably clean drawing and FAI data, AI can help with some of the heavy lifting around characteristics.

    • Draft ballooning support: Proposing initial characteristic lists from 2D drawings or 3D models, which a quality engineer then reviews and finalizes.
    • Characteristic mapping: Suggesting mappings between drawing characteristics and AS9102 Form 3 entries, helping catch omissions or mismatches.
    • Cross-part characteristic reuse: Identifying when a new FAI is effectively a variant of an older part with similar features, so prior balloons and inspection plans can be reused or adapted.

    These uses still require human review and formal approval. In regulated environments, AI outputs should be treated as draft artifacts that enter normal document control and signoff workflows.

    3. Pattern analysis on nonconformances and key characteristics

    If AS9102 results are tied to NCRs, CAPA, or yield data, AI can help surface patterns that are hard to see in spreadsheets.

    • Identifying characteristics that drive a disproportionate share of FAIs that fail or require concessions.
    • Highlighting suppliers, machines, tools, or work centers that correlate with repeated FAI findings on specific features.
    • Spotting revision-change effects, such as a design update that increases the likelihood of FAI issues for certain dimensions or materials.

    This is realistic when your AS9102 data includes structured links to part numbers, revisions, NC records, and supplier or routing information. Without that linkage, you are limited to more superficial text mining.

    4. AI-assisted FAI preparation and review workflows

    Another concrete use case is making FAI preparation and review faster, not changing criteria.

    • Pre-populating forms: Pulling part, BOM, routing, and drawing metadata from PLM/ERP into AS9102 forms to reduce manual data entry.
    • Consistency checks: Flagging obvious issues such as missing mandatory fields, mismatched revisions, or inconsistent units of measure before formal review.
    • Cross-document comparison: Comparing current and prior FAIs to ensure that planned characteristics, methods, and gages are consistent with similar parts when they should be, and highlighting unexplained deviations.

    Most of this can be implemented with a mix of rules and AI models. In all cases, human approvers retain accountability and must explicitly sign off within your existing QMS processes.

    5. Natural-language reporting and audit support

    AS9102 data often becomes critical evidence in AS9100 audits and customer reviews. AI can help produce more coherent views without changing underlying records.

    • Generating narrative summaries of FAI status for a program, cell, or supplier based on existing structured and unstructured records.
    • Answering audit-style questions such as “Show FAIs for part X across revisions and summarize major findings and concessions” using indexed data.
    • Preparing draft responses to customer FAI inquiries, referencing the correct forms, revisions, and linked nonconformances for a quality lead to review and finalize.

    This relies on robust access control, especially if data is ITAR- or export-controlled, and should be deployed with clear boundaries on which repositories the AI layer can see.

    6. Supplier FAI support and comparative analysis

    Where you collect AS9102 packages from multiple suppliers, AI can help with incoming FAI triage and trend monitoring.

    • Normalizing supplier AS9102 submissions into a common structure (units, naming, basic characteristic groupings) to enable comparison.
    • Highlighting which suppliers struggle with particular feature types (e.g. tight bores, complex GD&T, special processes) during FAI.
    • Assistive checks on supplier-submitted data such as missing signatures, mismatched part numbers, or obvious misalignments between drawings and Form 3 content.

    This does not replace supplier qualification, source inspection, or traditional scorecards; it simply gives quality and supply chain teams faster visibility into FAI-related risk.

    7. What is not realistic today

    There are several AI ideas that are attractive on paper but usually unrealistic or unsafe in current aerospace environments:

    • Autonomous acceptance of FAIs: Having AI approve or reject FAIs without human review is generally misaligned with AS9100 expectations, customer requirements, and internal quality policies.
    • Automated tolerance or criteria changes: AI proposing or implementing tolerance changes directly from FAI data without formal engineering, MRB, and change-control involvement is not acceptable.
    • Replacing inspection planning: AI can suggest, but cannot replace, qualified quality engineers for decisions on sampling plans, gages, or inspection strategies.
    • “Plug-and-play” AI across all plants: Given site-to-site differences in data structure, system landscape, and process maturity, there is no universal AS9102 AI solution that works out of the box at scale.

    Dependencies and data prerequisites

    Realistic AI use depends on several practical factors:

    • Data structure: If AS9102 lives only as scanned PDFs with inconsistent naming, the first step is OCR and basic structuring. Expect significant data preparation effort.
    • System integration: Linking AS9102 records to PLM, MES, QMS, and ERP (part, revision, route, supplier, NC) is critical for meaningful analysis.
    • Validation and change control: Any AI-assisted workflow that touches production or quality decisions must be validated, documented, and managed under formal change control, particularly where customers or regulators could rely on its outputs.
    • Security and export controls: If AS9102 data includes controlled technical information, AI deployment must respect ITAR/export rules, data residency, and vendor security posture.

    Coexistence with brownfield systems

    In most aerospace environments, AS9102 data is spread across Net-Inspect or similar portals, legacy MES, QMS, shared drives, and email. Replacing these systems outright is rarely practical due to qualification burden, integration complexity, and downtime risk.

    Realistic AI strategies usually look like:

    • Adding an AI-enabled indexing and analytics layer on top of existing FAI repositories.
    • Integrating at the data and API level rather than trying to replace validated MES/QMS platforms.
    • Focusing first on read-only, assistive capabilities (search, summarization, pattern detection), then carefully piloting AI-assisted authoring or checks in narrow, well-controlled areas.

    This approach respects long equipment lifecycles and avoids triggering full revalidation of core systems wherever possible.