Connect981 – Content Dev

FAQ Tag: change control

  • Which data sources should feed an aerospace compliance dashboard?

    An aerospace compliance dashboard should be fed by the systems that create or control the underlying evidence, not just by manually maintained spreadsheets or a BI layer disconnected from the source records.

    In most plants, the right answer is a governed mix of operational, quality, and master-data sources. Which ones matter most depends on what the dashboard is supposed to prove: document control status, training currency, traceability completeness, FAI readiness, nonconformance trends, supplier risk, calibration status, or audit evidence coverage.

    Core data sources to include

    • QMS: NCRs, CAPAs, deviations, concessions, audit findings, corrective action aging, closure evidence, and change records. This is usually the backbone for compliance status.

    • MES or electronic execution systems: route completion, operator signoffs, process parameter capture, in-process inspection, serialized genealogy, rework history, and as-built records.

    • ERP: part master, revision references, lot and serial associations, purchase orders, work orders, supplier receipts, inventory status, and planning context. ERP often provides business status, but not enough compliance evidence by itself.

    • PLM or engineering systems: approved product definitions, revision status, effectivity, change orders, approved manufacturing definitions, and controlled specifications.

    • Document control systems: current SOPs, work instructions, forms, approval history, effective dates, and obsolete-document status.

    • Training and qualification records: training completion, recertification due dates, role-based qualification status, and authorization to perform controlled tasks.

    • Metrology and calibration systems: equipment calibration status, due dates, out-of-tolerance events, and links to affected inspection results where available.

    • Inspection and test systems: CMM data, SPC results, test results, acceptance status, and characteristic-level findings where relevant to FAI or release.

    • Supplier quality and external processing systems: supplier NCRs, certs, receiving inspection outcomes, outside processing traceability, and supplier corrective action status.

    • Audit and risk tracking tools: internal audits, layered process audits, risk registers, mitigation status, and overdue actions.

    • Controlled spreadsheets or legacy repositories: only when unavoidable, and only if they are governed, versioned, and assigned a clear owner. In many brownfield sites, some compliance-critical data still lives here.

    What the dashboard should not rely on

    It should not rely primarily on manually rekeyed data, isolated presentations, or a dashboard database that has become a second unofficial system of record. That setup usually weakens traceability and creates reconciliation disputes during investigations or audits.

    Source selection depends on the compliance use case

    Different compliance questions require different source priorities.

    • For audit readiness, prioritize QMS, document control, training, calibration, and audit systems.

    • For product traceability, prioritize MES, ERP, inspection, and supplier processing records.

    • For FAI readiness, prioritize PLM, ballooned characteristics data, inspection records, revision-controlled product definitions, and nonconformance history.

    • For process compliance, prioritize MES, digital work instructions, equipment status, training, and change control records.

    • For supplier compliance, prioritize ERP receiving, supplier quality, cert management, and outside processing traceability.

    Brownfield reality

    In aerospace environments, these sources usually do not sit in one clean platform. They are spread across mixed-vendor QMS, MES, ERP, PLM, lab, inspection, and document systems, often with legacy applications that cannot be replaced quickly. A full rip-and-replace approach often fails because of validation cost, qualification burden, downtime risk, integration complexity, and the long lifecycle of production and test assets.

    That means the dashboard should usually be built as a governed integration layer over existing systems, with explicit source ownership and clear rules for which system is authoritative for each metric.

    Key implementation constraints

    • Record ownership must be explicit: if ERP says a revision is current but PLM says otherwise, the dashboard needs a defined source of truth for that field.

    • Timestamps and status logic must align: open, closed, effective, approved, trained, released, and overdue often mean different things in different systems.

    • Master data quality matters: part numbers, supplier IDs, operation codes, document numbers, serial numbers, and employee identifiers must map consistently.

    • Data latency matters: some use cases can tolerate daily refresh; others, such as release holds or overdue calibration affecting production, may need near-real-time updates.

    • Validation and change control are required: if the dashboard supports regulated decision-making or audit preparation, transformations, calculations, and data mappings need review and controlled change processes.

    • Not all gaps are technical: many failures come from inconsistent process execution, missing approvals, weak document discipline, or incomplete operator adoption at the source.

    Practical rule

    If a metric may be challenged, the dashboard should link back to the controlled source record or evidence trail. If it cannot, treat that metric as directional, not definitive.

    So the short answer is: feed the dashboard from QMS, MES, ERP, PLM, document control, training, calibration, inspection, supplier quality, and audit systems, but only after defining source authority, mappings, refresh logic, and evidence traceability. More data is not automatically better. A smaller set of trusted, reconcilable sources is usually safer than a wide but inconsistent aggregation.

  • Can ISO 22400 work with cloud-based data lakes and analytics tools for aerospace production?

    Yes. ISO 22400 can work with cloud-based data lakes and analytics tools for aerospace production, but only if the plant has disciplined data mapping, event context, and governance.

    ISO 22400 is useful as a common KPI model for manufacturing operations data. A cloud data lake or analytics platform can ingest machine, MES, ERP, quality, and maintenance data, then calculate and visualize KPI definitions more consistently across lines, sites, or programs. That said, the standard does not solve the hard parts on its own.

    What has to be true for it to work

    • Source data must be usable. If machine states, production counts, labor events, scrap reasons, and order context are inconsistent or incomplete, ISO 22400 calculations in the cloud will also be inconsistent.

    • Time alignment matters. KPI calculations often fail when timestamps from PLCs, historians, MES, and ERP are not synchronized or do not represent the same production event boundaries.

    • Business rules must be governed. Plants often use different local meanings for downtime, good count, rework, or planned stop. Without semantic governance, a cloud rollout creates dashboards that look standardized but are not comparable.

    • Data lineage must be clear. In aerospace production, leaders usually need to know where a metric came from, what transformation logic was applied, and which source system remains the system of record.

    • Validation effort is real. If cloud-calculated metrics are used for operational decisions, management review, or evidence in a regulated quality context, the calculation logic, interfaces, and change process may need formal review and control.

    What cloud tools are good at

    Cloud data lakes and analytics tools are often well suited for cross-site reporting, historical trend analysis, anomaly detection, and combining production data with quality, maintenance, and supply chain data. They can also support more advanced analytics that are difficult to run inside legacy MES or historian environments.

    They are less suited to being treated as a direct replacement for execution systems. In most aerospace environments, MES, ERP, QMS, PLM, historians, and shop-floor controls remain the transactional and traceable systems of record. The cloud layer usually works best as an analytical and integration layer above those systems, not as a substitute for them.

    Brownfield reality in aerospace

    In a brownfield plant, the practical approach is coexistence. ISO 22400 metrics in the cloud typically depend on data from mixed-vendor MES, ERP, machine interfaces, manual entry workflows, and legacy databases. That creates integration debt, mapping work, and ongoing exception handling.

    Full replacement strategies often fail here for predictable reasons: qualification burden, validation cost, downtime risk, long equipment lifecycles, and the complexity of preserving traceability and change control across interconnected systems. For that reason, many teams implement ISO 22400 as a canonical KPI layer while keeping existing operational systems in place.

    Key tradeoffs

    • Standardization versus local nuance. A common KPI model improves comparability, but some local process details may be lost unless the data model is designed carefully.

    • Scalability versus trust. Cloud platforms scale well, but trust drops quickly if operators and engineers cannot trace a dashboard number back to source events.

    • Analytics speed versus change control. Cloud teams can iterate quickly, but in regulated manufacturing, KPI definitions and transformations usually need tighter review than a normal BI project.

    • Centralization versus latency. Centralized analytics are useful for enterprise visibility, but near-real-time operational decisions may still need to stay closer to MES, SCADA, or edge systems.

    Practical bottom line

    Yes, ISO 22400 can work well with cloud-based data lakes and analytics tools for aerospace production if it is used as a governed performance model, not as a shortcut around data quality, system integration, or validation discipline.

    If the goal is enterprise KPI consistency, benchmarkable reporting, and broader analytics, the combination can be effective. If the goal is to replace the need for accurate shop-floor context, reliable master data, and controlled system interfaces, the answer is no.

  • How do we decide which time grain to use for a given KPI?

    Use the coarsest time grain that still supports the decision you need to make in time.

    That is usually the right starting rule. A KPI should be sampled and reviewed at a time grain that matches:

    • how quickly the process can materially change,
    • how quickly someone can act on it,
    • how accurate and complete the timestamped data really is, and
    • how much aggregation the metric can tolerate before it hides important variation.

    If those factors are not aligned, the KPI becomes either too noisy to manage or too delayed to be useful.

    Pick the grain from the decision, not from the dashboard

    A practical way to decide is to start with the operating decision the KPI is supposed to inform.

    • Sub-minute to minute: use when operators or automated controls can intervene quickly and the source events are captured reliably at that rate.
    • 15-minute to hourly: use for shift supervision, line balance, short-interval control, response to downtime, queue growth, or bottleneck monitoring.
    • Shift or daily: use for production attainment, first pass yield trends, labor utilization, schedule adherence, and recurring quality loss review.
    • Weekly or monthly: use for management review, supplier performance, COPQ trends, capacity planning, or program-level performance.

    If no one can make a different decision every five minutes, a five-minute KPI may add cost and noise without adding control.

    What to test before locking the grain

    • Decision latency: How fast must someone detect and respond to the condition?
    • Process rhythm: Does the work happen continuously, by cycle, by lot, by batch, by route step, by shift, or by close period?
    • Signal-to-noise ratio: At finer grain, does the KPI reveal meaningful variation or just random fluctuation?
    • Data capture fidelity: Are event times synchronized, complete, and attributable to the right asset, order, lot, operation, or operator?
    • Denominator stability: At small intervals, does the denominator become too small, making percentages misleading?
    • Comparability: Will sites, lines, or vendors calculate the KPI consistently at that grain?

    These checks matter because many KPI failures are not mathematical. They are governance and context failures.

    Common tradeoffs

    Finer grain gives earlier visibility, but it also increases sensitivity to bad timestamps, missing events, clock drift, late transactions, and integration gaps. Coarser grain improves stability and comparability, but it can hide short disruptions, transient quality escapes, and handoff delays.

    For example, hourly OEE or downtime views may help a supervisor recover a shift. Monthly OEE is often too slow for execution, but useful for trend review. Conversely, daily scrap rates may be better than hourly scrap percentages if production volume is low and the hourly denominator is unstable.

    Some KPIs should exist at more than one grain, but with different purposes. That is acceptable if the calculation logic, timestamp rules, and intended audience are controlled. Without semantic governance, organizations end up arguing over whose number is right instead of acting on the signal.

    Brownfield reality

    In mixed MES, ERP, historian, SCADA, QMS, and spreadsheet environments, the available time grain is often constrained by system behavior rather than business intent.

    Examples include:

    • ERP transactions posted in batches rather than at true event time.
    • Legacy equipment without reliable state models.
    • MES timestamps based on user actions instead of machine events.
    • Quality results released after review, not when the condition actually occurred.
    • Cross-system clocks that are not synchronized.

    In that situation, forcing a very fine grain can create false precision. It may look advanced on a dashboard, but it weakens trust, complicates investigations, and makes cross-system reconciliation harder. In regulated operations, that also raises traceability and change-control concerns if people cannot explain how the KPI was derived at a given point in time.

    A practical selection method

    1. Define the business question and who acts on it.
    2. Set the maximum acceptable delay before action.
    3. Map the true event sources and their timestamp quality.
    4. Test the KPI at two or three candidate grains.
    5. Check whether each grain changes decisions, or only changes chart shape.
    6. Document the chosen grain, calculation rules, and exceptions under change control.

    If two grains are both needed, treat them as separate governed views of the same KPI, not interchangeable numbers.

    The short answer is this: choose the time grain that preserves decision usefulness and data integrity at the lowest operational cost. Not the finest grain available, and not the grain that is easiest for one system to export.

  • What real-time data should an aerospace MES surface to supervisors?

    An aerospace MES should surface the real-time conditions a supervisor can actually act on during the shift: work waiting, work blocked, quality holds, labor and equipment status, material shortages, and exceptions that threaten schedule or traceability. Not every available signal belongs on the screen. In regulated environments, more data is not automatically better. If the MES shows stale, unvalidated, or poorly integrated data, supervisors will work around it and the board becomes decoration.

    What supervisors usually need first

    For most aerospace plants, the core real-time view should answer a short set of questions:

    • What work orders or operations are due now, late now, or at immediate risk?
    • Where is work physically and logically stuck?
    • Which jobs are blocked by material, tooling, inspection, approval, or machine availability?
    • Which operators, cells, or lines are idle, overloaded, or running off plan?
    • What quality events require containment or escalation right now?
    • What happened in the last hour that changed the shift plan?

    If the MES cannot answer those questions reliably, adding more KPIs usually makes the problem worse.

    Recommended real-time data categories

    The most useful aerospace MES supervisor view typically includes these categories.

    1. Dispatch and execution status

    • Current operation status by work order, serial number, batch, or assembly
    • Queue, in-process, complete, hold, waiting inspection, waiting material, waiting approval
    • Planned versus actual start and finish at operation level
    • Jobs approaching contractual, internal, or downstream handoff deadlines
    • Route step adherence and skipped or attempted out-of-sequence steps

    This is usually the center of the screen because it shows where intervention is needed first.

    2. Constraint and blockage visibility

    • Material shortages and missing kit components
    • Tooling or gage unavailability
    • Machine downtime or loss of critical capacity
    • Pending electronic signoffs or approvals
    • Missing documents, unreleased revisions, or obsolete instruction access attempts
    • Awaiting first article, in-process inspection, source inspection, or customer hold release

    In practice, supervisors often need blockage codes that are specific enough to act on. A generic red status is not enough.

    3. Quality and traceability exceptions

    • Open nonconformances affecting active work
    • MRB or deviation dispositions that are pending and blocking flow
    • Inspection failures by operation, part family, or work center
    • SPC or process capability signals only where the process is mature enough to trust them
    • Missing genealogy, missing lot linkage, missing as-built data, or incomplete signoffs
    • Rework loops and repeated failure at the same step

    For aerospace, this matters as much as throughput. A supervisor does not just need to know that work is moving. They need to know whether it is moving with complete, defensible records.

    4. Labor and skills coverage

    • Who is clocked in, where they are assigned, and what they are currently executing
    • Certification or authorization constraints for the operation being performed
    • Unstaffed bottleneck operations
    • Labor utilization by cell or area, with care not to overinterpret noisy labor data
    • Requests for support, training, or supervisor override

    This becomes important when the plant depends on scarce certifications, tribal knowledge, or dual signoff steps.

    5. Equipment and asset status

    • Machine up/down/starved/blocked states where machine connectivity exists
    • Maintenance status for constrained assets
    • Calibration status for critical gages and tools
    • Environmental or process parameter alarms only if they are integrated and governed

    Many plants want this, but not all have the OT integration discipline to make it reliable. If connectivity is partial, state that clearly rather than implying complete real-time visibility.

    6. Short-interval performance versus plan

    • Shift attainment against plan at the area, cell, or program level
    • Throughput by constrained resource
    • Queue aging and WIP accumulation
    • First-pass yield and rework count for the current shift or day
    • Top active reasons for delay or non-productive time

    These are useful when tied to action. They are less useful when presented as a generic OEE layer in high-mix, low-volume aerospace environments where context matters more than one rolled-up number.

    What should not be the primary supervisor view

    Supervisors usually do not need a dashboard dominated by executive metrics, finance summaries, or broad monthly trends. They also do not need raw event streams with no prioritization.

    Avoid making the main MES screen a mix of:

    • ERP-style backlog reports with delayed refresh
    • PLM document libraries without operational relevance
    • QMS metrics that are important but not shift-actionable
    • Dozens of alarms with no severity logic or ownership
    • Plantwide OEE as the main control signal in a complex, high-mix environment

    Those views may belong elsewhere, but they should not crowd out immediate execution control.

    Brownfield reality: the answer depends on integration quality

    In many aerospace sites, the MES is only as real-time as the surrounding systems allow. Material status may still come from ERP transactions entered late. Revision status may depend on PLM release timing. NCR or deviation status may live in QMS. Machine state may come from separate historians, SCADA, or not at all.

    That means the right supervisor view is often a federated exception view, not a promise that the MES itself is the single source of truth for every signal. If system timestamps are inconsistent, if operators back-enter transactions, or if dispatch logic is manually overridden without traceability, the dashboard will mislead people.

    Full replacement of MES, ERP, PLM, and QMS stacks to solve this is usually unrealistic in regulated aerospace environments. Qualification burden, validation cost, downtime risk, and integration debt are usually too high. Most plants get farther by improving event quality, integration timing, and exception handling around the existing stack.

    Practical design rules

    • Show only signals with a defined owner and expected response.
    • Separate informational metrics from action-required exceptions.
    • Display data freshness and source when latency varies by system.
    • Use role-based views. A cell supervisor and a quality supervisor do not need the same screen.
    • Preserve drill-down to traveler, serial, operation, revision, hold reason, and approval status.
    • Keep audit trail access close to the operational event when traceability matters.

    If a metric cannot trigger a decision, escalation, or documented action, it probably does not belong in the primary real-time view.

    Common failure modes

    • Supervisors see too many statuses but not the actual blocker.
    • Data refresh is delayed, so teams rely on whiteboards and calls instead.
    • Quality holds are visible, but the reason, owner, or next step is not.
    • Labor assignment looks current, but certification or training status is not tied to the operation.
    • Material appears available in ERP, but not actually staged at point of use.
    • Out-of-sequence work is possible in practice, but the MES flags it too late.
    • Machine connectivity exists for some assets but is presented as if it covers the whole area.

    These failures are common because plants often implement display logic before fixing data ownership and transaction discipline.

    A practical minimum set

    If you need a short answer, start with this minimum set:

    • Late and due-now operations
    • WIP by status and queue age
    • Blocked jobs with reason codes
    • Material and tooling shortages
    • Quality holds, failed inspections, and active nonconformances
    • Labor and constrained machine status
    • Shift attainment versus plan
    • Missing traceability or signoff exceptions

    That is usually enough to run the shift without pretending the MES can solve every planning, quality, and engineering problem in real time.

  • How can document control systems support ITAR compliance?

    A document control system can support ITAR by helping an organization control, trace, and limit access to controlled technical data. It is a supporting control layer, not a substitute for export control governance, user screening, network security, training, or legal review.

    In practice, the most useful capabilities are:

    • Access control by role, program, site, and need-to-know so controlled documents are not broadly visible.
    • Document classification and labeling so ITAR-relevant content is identified consistently and handled differently from general business records.
    • Version control and effective-date management so users work from the current approved revision and older versions remain traceable.
    • Approval workflows to document review, release, change authorization, and withdrawal of obsolete content.
    • Audit trails showing who viewed, changed, approved, exported, or distributed controlled documents.
    • Controlled distribution to reduce uncontrolled copying, emailing, printing, and local storage.
    • Retention and archival controls to preserve records needed for investigations, internal review, and traceability.
    • Acknowledgment and training linkage so policy, work instruction, and access changes can be tied to affected users.

    Those capabilities matter because ITAR risk often comes from ordinary operational failures, not just malicious behavior. Common failure modes include misclassified files, excessive shared-drive permissions, uncontrolled exports from PLM or CAD, supplier packet emails, copied files on local devices, and legacy repositories that are outside current approval and logging workflows.

    A document control system helps most when it is part of a broader control model for technical data handling. That usually includes identity and access management, endpoint controls, DLP or monitoring where appropriate, supplier data exchange controls, and clear ownership for classification and release decisions.

    What it can and cannot do

    It can help enforce process discipline and provide evidence of who had access to what and when. It cannot determine by itself whether a document is ITAR-controlled, whether a recipient is authorized, or whether a specific transfer is permissible. Those depend on classification accuracy, user provisioning, business rules, and the quality of surrounding controls.

    It also does not eliminate brownfield risk. In many plants, controlled documents live across PLM, ERP, MES, QMS, shared folders, email, supplier portals, and paper packets on the floor. If the document control system governs only one repository, gaps remain. Integration quality matters, especially where released drawings, work instructions, routers, inspection plans, and supplier packages are replicated into downstream systems.

    That is why full replacement strategies often fail here. In regulated, long-lifecycle environments, replacing PLM, MES, ERP, or QMS outright can trigger large qualification and validation burdens, operational downtime risk, retraining costs, and loss of traceability across legacy records. A staged coexistence model is usually more realistic: put stronger governance around controlled documents first, then close the highest-risk handoff points between systems.

    What good implementation usually requires

    • A clear classification model for controlled technical data and related records.
    • Role design and access reviews that reflect real programs, suppliers, sites, and citizenship or authorization constraints where applicable.
    • Change control for document templates, metadata, workflows, and integration mappings.
    • Validation and testing of permissions, routing, watermarking, export restrictions, and audit logging.
    • Integration controls so downstream systems do not strip labels, expose attachments, or replicate files into less controlled repositories.
    • Exception handling for printed packets, offline access, emergency maintenance, and external collaboration.

    If those basics are weak, the system may create a false sense of control. For example, strong approvals with weak metadata discipline still leave room for misrouted technical data. Detailed audit logs are also of limited value if accounts are shared, integrations use generic service identities without context, or logs are not retained and reviewed.

    So the practical answer is yes: document control systems can materially support ITAR-related control objectives by improving restriction, traceability, revision governance, and evidence capture. But they are only effective when classification, access governance, integration design, and operational discipline are mature enough to make those controls real.

  • How are RFQ decisions documented for AS9100 and customer audits?

    RFQ decisions are usually documented through a controlled quote or contract review record that shows how requirements were evaluated, what risks or exceptions were identified, who approved the decision, and what was finally offered to the customer. For AS9100 and customer audits, the expectation is generally not just that a quote exists, but that you can show objective evidence of the review and decision path.

    In practice, an auditor will usually look for evidence that your organization reviewed applicable requirements before committing. That commonly includes technical requirements, delivery expectations, capacity, special processes, quality clauses, customer flow-downs, configuration or revision status, and any assumptions or exclusions used in the quote. If the RFQ was declined, many organizations also retain the reason for no-bid when that is part of their process discipline or risk management.

    What the documentation usually needs to show

    • The RFQ or customer request received, including revision level and date.

    • The requirements reviewed, including drawings, specifications, statements of work, quality clauses, and customer-specific terms where applicable.

    • Any identified risks, constraints, assumptions, exclusions, or open questions.

    • Cross-functional input where needed, such as sales, engineering, quality, supply chain, operations, or program management.

    • The decision outcome: bid, no-bid, conditional bid, or quote revision.

    • The approver(s), approval date, and the version of the information approved.

    • Traceability from the review to the issued quote, and later to the contract, purchase order, or order acceptance if awarded.

    If your process includes re-reviews after customer changes, that should also be documented. A common audit failure mode is having a clean initial review but weak evidence that revised requirements, changed quantities, expedited delivery dates, or updated drawings were re-evaluated before acceptance.

    What format is acceptable

    There is no single required format. Documentation may live in ERP, CRM, QMS, a quoting system, PLM-linked workflows, or controlled forms and attachments. What matters is that the record is controlled, retrievable, attributable to responsible roles, and consistent with your documented process.

    Email alone is usually not strong enough unless your organization has a controlled way to capture, retain, approve, and trace those messages as part of the official record. In many plants, email contains important context, but the auditable record is a formal contract review, quote approval workflow, or linked change-controlled form.

    What auditors typically test

    Auditors commonly sample from a released order backward. They may ask you to show:

    • How the original RFQ was reviewed before the quote was issued.

    • Whether customer and regulatory requirements were identified and flowed into planning.

    • How exceptions, assumptions, or capability gaps were handled.

    • Whether quote revisions and order changes were re-reviewed.

    • Whether the final accepted scope matches what was reviewed and approved.

    If the organization cannot link the quote decision to the accepted contract terms, manufacturing plan, or quality requirements, the issue is usually traceability, not just missing paperwork.

    Brownfield reality

    In brownfield environments, RFQ decisions are often spread across CRM, ERP, spreadsheets, email, shared drives, and tribal knowledge. That is common, but it creates audit risk. The main problem is not that you use multiple systems. The problem is weak evidence trails, inconsistent revision control, unclear ownership, and manual re-entry that breaks traceability.

    For that reason, full replacement is often not the best answer. In regulated, long-lifecycle environments, replacing quoting, ERP, QMS, or planning systems can trigger significant qualification effort, validation work, integration risk, and operational disruption. Many organizations get better results by adding a controlled review workflow and evidence model around existing systems, then improving linkage over time.

    A workable approach is often to define a minimum required RFQ review record, identify the system of record for each data element, and enforce approval, revision handling, and retention rules through change control. That is usually more realistic than trying to force a single new platform across every plant and legacy process.

    Bottom line

    RFQ decisions for AS9100 and customer audits should be documented in a controlled, traceable review record that shows requirements review, risk and exception handling, approvals, revisions, and linkage to the final commercial and operational commitment. The exact mechanism can vary, but if your evidence depends on scattered inboxes, undocumented judgment, or manual file hunting, it is unlikely to hold up consistently under audit.

  • What data quality rules should I enforce before calculating KPIs?

    Enforce data quality rules at two levels: first on the source data itself, and then on the KPI definition logic. If either layer is weak, the KPI can be numerically correct and still operationally misleading.

    The minimum rule set usually includes:

    • Definition control: Every KPI needs an approved definition for numerator, denominator, exclusions, time basis, aggregation method, and source systems. If plants or functions use different interpretations, do not combine the results.
    • Timestamp integrity: Check that event times are present, in the correct timezone, sequenced logically, and tied to the right production day or shift boundary. A large share of KPI distortion comes from bad time handling rather than bad arithmetic.
    • Completeness thresholds: Set explicit minimum completeness rules for required fields. For example, reject or flag records missing work order, part, operation, equipment, quantity, disposition, or start/stop times when those fields are required for the KPI.
    • Duplicate and replay detection: Prevent double-counting from interface retries, manual re-entry, batch reloads, or overlapping integrations. Brownfield MES, ERP, historian, and spreadsheet workflows commonly create this problem.
    • Unit and measure consistency: Validate units of measure, quantity precision, currency basis, and conversion logic before aggregation. Mixed units can quietly corrupt yield, throughput, scrap, or cost KPIs.
    • Master data alignment: Enforce valid references for part, revision, routing step, asset, work center, supplier, and reason code. If master data is stale or inconsistent across systems, the KPI may be directionally wrong even when all transactions are present.
    • Status and lifecycle rules: Only include records in valid business states. For example, decide whether cancelled orders, quarantined material, rework loops, partially closed operations, and late backflushes are included or excluded, and apply that rule consistently.
    • Range and plausibility checks: Reject or quarantine impossible values such as negative runtime, scrap greater than input, cycle time outside physical limits, or completion before release.
    • Exception handling: Define how to treat missing values, late-arriving records, manual overrides, estimated values, and sensor dropouts. Silent defaulting to zero is often the wrong choice.
    • Lineage and traceability: Preserve the source, transformation path, version of the KPI logic, and any manual adjustments. In regulated environments, this matters for internal review, investigations, and change control, even when the KPI is not itself a formal quality record.

    A practical rule is this: if you cannot explain why a record was included, excluded, corrected, or rolled up, you are not ready to use the KPI for management decisions.

    What should be blocked versus flagged

    Not every data issue should stop KPI calculation. Some should block publication, and some should publish with a visible warning. That threshold depends on process criticality, reporting purpose, and data maturity.

    • Block publication when definition conflicts exist, timestamps are unreliable, duplicates are unresolved, or required joins to master data fail at material volume.
    • Publish with warning when late data is below a defined threshold, a small number of records are quarantined, or a noncritical enrichment field is missing.
    • Allow provisional values only if they are clearly marked as preliminary and recalculation rules are documented.

    If the KPI is used for cross-plant benchmarking, capacity commitments, supplier escalation, or quality management review, the tolerance for provisional or partially qualified data should be much lower.

    Rules that are often missed

    • Shift calendar governance: OEE, downtime, and labor metrics break when shift calendars, holiday rules, or planned downtime definitions differ by site.
    • Reason code quality: Downtime, scrap, and rework KPIs are only as good as the classification discipline behind them. Free-text categories usually degrade comparability.
    • Revision effectivity: Part revision, routing version, and work instruction version can change denominator assumptions. Trend lines across revisions may not be comparable without segmentation.
    • Rework and nonconformance treatment: Decide whether rework counts as additional throughput, lost capacity, quality loss, or all three in different KPIs. This is a business rule, not a math detail.
    • Manual data provenance: If operators, supervisors, or planners can edit source records, capture who changed what, when, and why.

    Brownfield reality

    In mixed environments, you usually cannot enforce all rules inside one platform. Data may originate in ERP, MES, QMS, historian, CMMS, spreadsheets, or supplier portals, each with different timing and semantics. In that case, define a canonical KPI layer with explicit validation rules at system boundaries.

    Do not assume a full system replacement is the best fix. In regulated, long-lifecycle operations, replacement programs often fail or stall because of qualification burden, validation cost, downtime risk, integration complexity, and the need to preserve traceability across legacy processes. In many plants, a governed coexistence model is more realistic: validate source data where it originates, reconcile key entities across systems, and version-control KPI logic centrally.

    Minimum release criteria before a KPI is trusted

    1. The KPI definition is approved and version controlled.
    2. Required source fields meet documented completeness thresholds.
    3. Duplicate handling and late-arriving data rules are tested.
    4. Master data mappings are reconciled across contributing systems.
    5. Exception rates are measured and visible.
    6. Recalculation and restatement rules are documented.
    7. An owner is assigned for both the KPI definition and the data quality controls.

    If those controls are not in place, you can still calculate the KPI, but you should treat it as indicative, not authoritative.

  • Is AS9100 a QMS?

    AS9100 is not a quality management system (QMS) by itself. It is a standardized set of requirements for a QMS in the aerospace and defense supply chain.

    Your QMS is the combination of:

    • Processes and procedures (e.g., design control, production, inspection, nonconformance, CAPA)
    • Systems (e.g., ERP, MES, PLM, QMS software, document control tools)
    • Records and evidence (e.g., travelers, inspection results, calibration logs, training records)
    • Organizational roles, responsibilities, and governance

    AS9100 defines how those elements must be structured and controlled to meet aerospace expectations. A company can have:

    • A QMS that does not conform to AS9100 (e.g., ISO 9001 only, or a homegrown system).
    • A QMS that is designed and operated to conform to AS9100 requirements.

    What AS9100 provides (and what it does not)

    AS9100 provides:

    • Requirements and expectations for an aerospace QMS (e.g., configuration management, risk, special processes, product safety, counterfeit prevention).
    • A structure for audits and conformity assessments.
    • Common language for customers, suppliers, and certification bodies.

    AS9100 does not provide:

    • Actual processes or workflows tailored to your plant.
    • Software or tools to run those processes.
    • Any guarantee of audit outcomes or compliance in your facility.

    How AS9100 relates to your existing systems

    In a typical brownfield environment, your QMS spans multiple legacy and modern systems: ERP, MES, PLM, QMS, homegrown databases, and paper. Implementing an “AS9100 QMS” usually means:

    • Gap-assessing existing processes and systems against AS9100 clauses.
    • Defining or updating procedures, work instructions, and controls to close gaps.
    • Configuring existing tools (workflows, forms, fields, reports) to support AS9100 evidence and traceability.
    • Putting change control, validation (where required), and document control around those changes.

    Full “rip and replace” of QMS-related systems just to “get AS9100” is rarely practical in regulated, long-lifecycle operations due to:

    • Qualification and validation burden for new systems.
    • Downtime risk and constrained outage windows.
    • Integration complexity with existing MES/ERP/PLM stacks.
    • Traceability and configuration management impacts across historical data.

    Most organizations instead layer AS9100-aligned controls onto existing infrastructure and incrementally improve weak points, rather than assuming a new software platform will “be the QMS.”

    Practical takeaway

    • AS9100 = aerospace QMS requirements standard.
    • Your QMS = how your organization actually manages quality across people, processes, and systems.
    • Conforming to AS9100 requires designing, implementing, and maintaining your QMS so that it meets AS9100 requirements, with appropriate evidence, traceability, and change control.

  • How detailed does our risk register need to be for certification?

    There is no universal level of detail that guarantees certification. The required detail depends on your regulatory context (e.g., ISO 9001, AS9100, IATF 16949, ISO 13485, 21 CFR), your processes, and how mature your risk management practices are. Auditors primarily look for consistency, traceability, and evidence that risks are actively managed, not a specific template.

    Core expectations for risk register detail

    In most certified environments, a risk register should, at minimum, show:

    • Clear risk statements that describe a cause, an event, and a consequence, not vague items like “Supplier” or “IT”.
    • Scope and context for each risk (process, product line, site, system, or project it relates to).
    • Likelihood and impact ratings with defined scales and criteria, not just high/medium/low without explanation.
    • Risk scoring or priority based on your defined method (e.g., RPN, risk matrix), with the method documented in your procedures.
    • Existing controls (preventive and detective) that are actually in use and traceable to procedures, work instructions, or system configurations.
    • Further actions or mitigation plans where residual risk is above your defined thresholds, with owners and target dates.
    • Status and review dates showing that risks are monitored and updated, not a one-time exercise.
    • Ownership for each risk (role or name), aligned with your organization structure.

    If you cannot show these elements, the register will usually be seen as under-specified, even if the list itself is long.

    Where to stop: avoiding unmanageable detail

    Overly detailed registers can also fail in practice. Typical failure modes include:

    • Thousands of micro-risks for every task step, making it impossible to maintain or review meaningfully.
    • Inconsistent granularity across departments (e.g., IT lists technical vulnerabilities, operations lists only broad categories), which auditors interpret as weak governance.
    • Duplicate or overlapping risks that differ only slightly, obscuring priorities.
    • Static, never-closed actions because the register became a parking lot of low-level to-dos.

    Detail should be high enough to support decisions and actions, but coarse enough that the register can be kept current across the plant for years. In long-lifecycle, highly regulated environments, maintainability often matters more than initial completeness.

    Linking detail to certification and standards

    Most standards do not prescribe a specific template or number of fields, but they drive how detailed your register should be:

    • ISO 9001 / AS9100: Expect a risk-based thinking approach covering quality and delivery. Detail must be enough to link risks to processes, objectives, and controls, and to show periodic review.
    • IATF 16949: Stronger expectations around product and process risk. Your register often needs clear links to DFMEA/PFMEA, control plans, and customer-specific requirements.
    • ISO 13485 / 21 CFR (life sciences): Risk registers typically need clear traceability between hazards, risk controls, verification, and residual risk acceptance. Detail is higher, and traceability to design / process documentation is critical.
    • Cybersecurity or IEC 62443-aligned environments: Additional detail around assets, threat sources, vulnerabilities, and controls is usually required, even if summarized in the central register.

    In all cases, the detail should allow an auditor to trace from a significant risk to:

    • Which process or system it affects,
    • How it was evaluated,
    • What controls exist,
    • What residual risk remains, and
    • Who decided that residual risk is acceptable.

    Brownfield reality: multiple systems and partial registers

    In most regulated plants, risks are already tracked across several systems: ERP, MES, QMS, PLM, EHS tools, IT ticketing, spreadsheets, and program trackers. Trying to replace all of these with a single master risk tool often fails due to:

    • Qualification and validation burden if the new tool affects validated processes.
    • Integration debt to connect MES, QMS, ERP, and document control.
    • Downtime and change control risk during migration.
    • Traceability regression when historical decisions are not migrated cleanly.

    Auditors do not require a single monolithic risk register system. They require that:

    • You can show where major categories of risk are managed (product, process, supplier, cybersecurity, facilities, etc.).
    • Your central risk view is coherent: top risks and themes are captured, even if underlying detail lives in FMEAs or specialized tools.
    • There is documented linkage between high-level risks and the detailed analyses and controls in legacy systems.

    Practically, this means your central register can be less detailed on technical minutiae as long as you reference the authoritative source (e.g., “See PFMEA XYZ-123”, “See IEC 62443 zone diagram”), and those sources are controlled and auditable.

    Audit-focused sanity checks for level of detail

    A useful way to right-size detail is to ask, for each risk:

    • Can someone unfamiliar with the area understand the risk from the entry? If not, it is too vague.
    • Is there a clear, single owner and next step (if needed)? If not, it may be too fragmented or generic.
    • Can we show evidence of the stated controls? If not, the entry will raise more questions than it answers.
    • Will we realistically update this item at least annually or when changes occur? If not, the granularity is probably too fine.

    Pragmatic minimum structure

    For most certification contexts, a pragmatic minimum data set per risk in the central register is:

    • Unique ID
    • Risk title and concise description (cause, event, consequence)
    • Process / system / product scope
    • Category (e.g., product quality, compliance, supply chain, IT, safety, environment)
    • Likelihood rating plus defined scale
    • Impact rating plus defined scale (quality, delivery, financial, regulatory, or safety impact as relevant)
    • Inherent risk score (based on your method)
    • Existing controls with references to documents or systems
    • Residual risk rating or score
    • Action plan if residual risk is above threshold (with owner and due date)
    • Risk owner
    • Last review date and review frequency

    Additional fields (e.g., links to CAPA records, FMEA IDs, project IDs) are useful when you can maintain them consistently. Add detail only when you can keep it accurate under your change control and validation constraints.

    How auditors typically evaluate your risk register

    Rather than focusing on how many columns you have, auditors generally test whether:

    • Top operational and quality risks are visible and plausible given your context.
    • There is alignment between the risk register and what they see on the shop floor, in the QMS, and in management review.
    • High-risk areas (e.g., special processes, critical suppliers, bespoke software) are identified and have credible controls.
    • Risk information is used: to prioritize audits, CAPA, projects, and investments.
    • Changes to processes, systems, or equipment trigger risk review under change control.

    If those points are satisfied, minor differences in format or field count are rarely certification blockers.

    Summary

    Your risk register needs to be detailed enough to show systematic identification, evaluation, control, and review of risks, with clear traceability to processes and supporting evidence. It does not need to capture every conceivable low-level risk, and an over-detailed register can be unmaintainable in long-lifecycle, brownfield environments. Aim for consistent, reviewable entries that connect to your existing MES, ERP, QMS, and engineering documentation, and be prepared to explain and defend your chosen level of detail to auditors.

  • What data quality standards are required for aerospace KPI dashboards to be audit-ready?

    Aerospace KPI dashboards become audit-ready when the underlying data, transformations, and governance can be traced, explained, and reproduced in line with your quality system and regulatory obligations. There is no single universal data quality standard just for dashboards, but auditors will expect your KPI data to follow the same rigor as production and quality records.

    1. Governance and ownership of KPI data

    Audit-ready dashboards start with clear accountability.

    • Defined KPI owners: Each KPI has a named process owner (e.g., quality, operations, supply chain) responsible for its definition, data lineage, and interpretation.
    • Approved KPI definitions: KPI purpose, formula, units, inclusion/exclusion rules, and data sources are documented, version-controlled, and approved within your QMS or equivalent document control process.
    • Change control: Any change to KPI logic, data source, aggregation level, thresholds, or visualization passes through formal change control, with impact analysis and approvals.
    • Role-based access: Who can view, modify, or export KPI data is defined and enforced, typically via integrated identity and access management.

    2. Data integrity and traceability

    Auditors will test whether KPIs can be traced back to original, trustworthy records.

    • Source system of record: Each KPI is tied to specific systems of record (e.g., MES, ERP, QMS, PLM, LIMS) rather than ad hoc spreadsheets.
    • End-to-end lineage: You can show how raw records (e.g., nonconformances, work orders, test results, supplier lots) are transformed into the KPI, including filters and transformations.
    • Record-level drill-through: For critical KPIs (e.g., defect rates, escapes, late deliveries), users can drill down from the dashboard to underlying transactions or batches, subject to access controls.
    • Time consistency: Snapshots or historical extracts are managed so that an auditor can reproduce the KPI for a past period, not only the current state.
    • Metadata capture: Timestamps, data source identifiers, and job/ETL run IDs are retained to reconstruct what data were used, and when.

    3. Data accuracy, completeness, and consistency

    Dashboards are only as audit-ready as the data quality rules backing them.

    • Validation rules: Checks for missing values, invalid codes, out-of-range measurements, and inconsistent dates are defined, executed, and monitored. Exceptions are logged and resolved.
    • Reference data control: Code lists (e.g., defect codes, station codes, disposition codes, customer IDs) are governed and synchronized across MES/ERP/QMS and analytics layers.
    • Unit and format harmonization: Units of measure, time zones, date formats, and part numbering schemes are normalized before aggregation.
    • Reconciliation with source systems: Periodic reconciliation (e.g., record counts, key metrics) between dashboards and source systems is performed and documented.
    • Known limitations documented: Any known data gaps, exclusions, or approximations are explicitly documented on or near the dashboard and in supporting SOPs.

    4. Standardized KPI definitions and context

    Auditors and customers need to understand what the KPI actually measures.

    • Unambiguous definitions: Clearly define numerators, denominators, and population (e.g., “FPY excludes rework orders created post-delivery”, “Scrap includes material and labor costs at standard rates”).
    • Scope and boundaries: Define whether KPIs are plant-specific, program-specific, customer-specific, or enterprise-level, and how multiple sites are aggregated.
    • Clock and period definitions: Specify how dates are interpreted (e.g., order date vs. completion date vs. ship date) and how months/weeks are defined.
    • Alignment with contracts and specs: Where KPIs are tied to customer scorecards or contractual requirements, the mapping and any differences are documented.

    5. Control of ETL, integration, and analytics logic

    In brownfield aerospace environments, data flows across multiple legacy systems and integrations. The code that moves and transforms data must be controlled.

    • Documented data flows: Authoritative diagrams and descriptions of how data move from MES/ERP/QMS into the dashboard layer (e.g., interfaces, APIs, ETL jobs, message buses).
    • Version-controlled transformation logic: SQL, ETL scripts, and analytics code are stored in version control with change history and approvals, not edited ad hoc in the BI tool.
    • Configuration management of BI tools: Calculated fields, KPI definitions, and filters within the BI platform are referenced to controlled logic where practical, or their configurations are exported and stored under change control.
    • Environment segregation: Clear separation between development, test/validation, and production analytics environments, with documented promotion paths.

    6. Validation and verification of KPI dashboards

    Audit-readiness depends on demonstrating that the dashboard implementation has been tested and verified.

    • Requirements and acceptance criteria: For each KPI, requirements (data sources, filters, formulas, refresh frequency, drilldowns) and acceptance criteria are defined.
    • Test protocols and evidence: Documented test cases showing input data, expected KPI values, and actual results. Test evidence is retained and traceable to requirements.
    • Regression testing after changes: When logic or data sources change, regression tests validate that historical KPIs either remain correct or changes are clearly explained.
    • Periodic review: Scheduled reviews (e.g., annually) to confirm that KPI logic still matches current processes, systems, and customer/regulatory expectations.

    7. Alignment with aerospace and regulated data expectations

    While there is no dashboard-specific aerospace standard, audits will reference familiar regulatory and quality expectations for data and records.

    • Quality management system alignment: KPIs and their data flows are integrated into your QMS procedures and records management practices, not managed as shadow IT.
    • Record retention and retrieval: Historical KPI outputs, underlying records, and evidence of corrections are retained according to contract and regulatory retention policies, and can be retrieved in a timely way.
    • Electronic records discipline: Where applicable, analytics environments handling regulated records follow relevant controls for electronic records and signatures (e.g., authorization, audit trails, time-stamping). Exact requirements depend on your regulatory scope.
    • Supplier and customer interfaces: If KPIs incorporate supplier or customer data, clarify responsibilities for data quality and how external data is validated.

    8. Brownfield reality: coexistence with legacy MES/ERP/QMS

    Most aerospace plants run mixed-vendor, legacy stacks where full system replacement is impractical due to qualification burden, validation cost, and downtime risk. Audit-ready dashboards in this context typically rely on:

    • Federated data models: Mapping and joining data from multiple systems of record rather than forcing a single monolithic data source.
    • Layered quality controls: Basic validation in source systems, plus additional quality and reconciliation checks in integration and analytics layers.
    • Transparent gaps: Explicitly acknowledging where a legacy system cannot provide certain fields or timestamps, and documenting workarounds or exclusions.
    • Incremental improvement: Prioritizing critical KPIs and high-risk data paths for higher rigor, rather than trying to perfect every metric at once.

    9. Practical checklist to assess audit-readiness

    Before presenting dashboards to auditors or customers, many teams review at least the following:

    1. Do we have controlled, approved definitions and formulas for each KPI?
    2. Can we trace sample KPI values back to specific records in MES/ERP/QMS, including any transformations?
    3. Are data quality checks documented, executed, and monitored, with evidence of issue resolution?
    4. Is all logic in ETL/BI tools version-controlled and under change control?
    5. Do we have validation/verification evidence for the dashboards?
    6. Are data limitations and exclusions for each KPI clearly documented?
    7. Can we reproduce a KPI for a historical period using preserved data and logic versions?

    If the answer to several of these is no, the issue is usually not a missing “standard” but gaps in data governance, validation, and documentation. Addressing those gaps is typically what moves an aerospace KPI dashboard from “informative” to genuinely audit-ready.