Connect981 – Content Dev

FAQ Tag: brownfield integration

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

  • What integration questions should be in an aerospace MES RFP?

    An aerospace MES RFP should include integration questions that force the vendor to describe how the MES will coexist with existing ERP, PLM, QMS, inspection, maintenance, identity, and reporting systems. The goal is not to get a generic “yes, we integrate” answer. The goal is to expose data ownership, interface limits, validation effort, failure handling, cybersecurity constraints, and the operational impact of connecting the MES into a brownfield aerospace environment.

    Full replacement of surrounding systems is usually unrealistic in aerospace manufacturing. ERP, PLM, quality, and maintenance platforms often carry years of validated process logic, customer-specific data, traceability history, and integration debt. An MES RFP should therefore assume coexistence unless the program has already funded the qualification burden, downtime risk, migration effort, and change control required for broader replacement.

    Core system integration questions

    Start by asking which enterprise and shop-floor systems the MES is expected to connect to, and what the vendor has actually integrated before in similar regulated environments.

    • Which ERP, PLM, QMS, document control, metrology, maintenance, warehouse, identity, and reporting systems are in scope?
    • Which integrations are standard product capabilities, which require configuration, and which require custom development?
    • What integration patterns are supported: API, event streaming, file exchange, middleware, database views, message queues, or manual import?
    • Which interfaces are real time, near real time, scheduled, or manual?
    • What are the known constraints for high-mix, low-volume, serialized, or engineer-to-order production?
    • What assumptions does the vendor make about network availability, shop-floor devices, identity management, and master data quality?

    These questions matter because many MES failures are not caused by screen design. They are caused by brittle interfaces, unclear source-of-truth decisions, and underestimated data cleanup.

    ERP integration questions

    ERP integration should be treated as a controlled boundary, not a vague promise of synchronization.

    • Which data objects flow from ERP to MES: work orders, operations, routings, materials, inventory, labor codes, cost centers, serial numbers, lots, purchase orders, or demand signals?
    • Which data flows back to ERP: completions, labor, scrap, rework, material consumption, WIP status, inventory movements, nonconformance signals, or shipment readiness?
    • Where is the system of record for work order status, inventory status, serial genealogy, and labor reporting?
    • How are partial completions, split lots, rework loops, substitutions, shortages, and reversals handled?
    • How are ERP changes controlled after a work order has already been released to the shop floor?
    • What happens when ERP is unavailable during production?

    Aerospace operations often need controlled execution even when planning data changes. The RFP should require the vendor to explain how the MES prevents uncontrolled drift between the released plan and actual execution.

    PLM and engineering data questions

    PLM integration is especially sensitive because released engineering data, manufacturing planning, and work instructions must remain aligned.

    • How does the MES consume part masters, bills of material, manufacturing bills of material, process plans, effectivity, configuration rules, and engineering change notices?
    • How are engineering revisions tied to work instructions, inspection requirements, tooling, programs, and acceptance criteria?
    • Can the MES preserve the exact revision used for a completed operation or unit?
    • How are effectivity dates, serial effectivity, block changes, alternate parts, and customer-specific configurations handled?
    • What controls prevent operators from using obsolete instructions or inspection criteria?
    • How are changes routed through approval and validation before release to production?

    The vendor should not imply that PLM integration automatically creates a complete digital thread. That depends on data structure, revision discipline, configuration management, and the quality of the integration design.

    QMS, nonconformance, and audit evidence questions

    The RFP should define how quality events move between MES and QMS. In many aerospace sites, the QMS remains the system of record for nonconformance, CAPA, MRB, deviations, concessions, and customer-facing quality records.

    • Where are nonconformances initiated, dispositioned, approved, and closed?
    • Can the MES stop work, route rework, or require quality approval based on a nonconformance state?
    • How are MRB decisions, deviations, concessions, and corrective actions linked back to units, operations, serial numbers, lots, and operators?
    • How are inspection results, attachments, signatures, and approval timestamps transferred or referenced?
    • Can the MES produce a complete audit trail for changes to instructions, results, dispositions, and approvals?
    • How are electronic signatures implemented, and what validation evidence is available?

    No vendor can guarantee audit outcomes through integration alone. The RFP should ask for traceability, audit trail, and validation support, but the site remains responsible for process definition, procedural controls, data governance, and evidence review.

    Inspection, test, and equipment integration questions

    Shop-floor and lab integrations are often more variable than enterprise integrations. Aerospace plants may have older gauges, CMMs, test stands, machine controllers, and calibration systems that were not designed for modern APIs.

    • Which inspection and test equipment can be integrated directly, and which require files, middleware, manual entry, or operator verification?
    • How are measurement results linked to part number, serial number, operation, characteristic, drawing revision, equipment ID, and operator?
    • How does the MES handle failed measurements, retests, overrides, and missing data?
    • Can the MES enforce equipment calibration status before use?
    • How are machine programs, test scripts, and setup parameters version-controlled?
    • What controls exist to prevent transcription errors where manual entry remains necessary?

    The RFP should avoid assuming that all machines can be integrated economically. Some legacy equipment will require manual controls or staged modernization.

    Master data and ownership questions

    Integration quality depends heavily on master data readiness. The RFP should require a clear data ownership model.

    • Who owns part masters, routings, work centers, tools, skills, inspection characteristics, defect codes, reason codes, equipment records, and user roles?
    • How are duplicate, incomplete, or conflicting master data records handled before go-live?
    • What data mapping templates does the vendor provide?
    • How are units of measure, naming conventions, revision formats, and status codes normalized?
    • What data must be migrated from paper travelers, legacy MES, spreadsheets, or local databases?
    • What data quality level is required for a controlled pilot?

    If master data is weak, the integration may technically work while producing unreliable execution records. The RFP should make data remediation visible as project work, not hide it under implementation assumptions.

    Failure handling and operational continuity questions

    An MES RFP should ask what happens when interfaces fail. This is where vague integration answers become operational risk.

    • How are failed messages detected, queued, retried, reconciled, and escalated?
    • Can production continue if ERP, PLM, QMS, identity services, or network connectivity are unavailable?
    • What offline or degraded-mode capabilities exist, and what controls apply when systems reconnect?
    • How are duplicate transactions, late transactions, and conflicting updates prevented or resolved?
    • What monitoring dashboards, alerts, logs, and support procedures are included?
    • Who is responsible for interface support after go-live: vendor, internal IT, system integrator, or application owner?

    These answers should be reviewed by operations, quality, IT, and engineering together. A technically acceptable interface can still be unacceptable if it creates uncontrolled production workarounds.

    Security, export control, and validation questions

    For aerospace and defense programs, integration questions should also cover controlled technical data, identity, access, and validation evidence.

    • How does the MES enforce role-based access across integrated systems?
    • How are ITAR, export-controlled, customer-restricted, or program-restricted data segregated?
    • What data is stored, transmitted, cached, logged, or exposed through APIs?
    • How are service accounts, certificates, secrets, and interface credentials managed?
    • What documentation supports validation, including interface specifications, test scripts, traceability matrices, and change impact assessment?
    • How are patches, upgrades, interface changes, and configuration changes controlled after validation?

    The required controls depend on the site, contracts, data classification, architecture, and regulatory context. The RFP should require evidence and implementation detail, not broad claims about being compliant.

    What to require in vendor responses

    Ask vendors to provide integration architecture diagrams, sample interface specifications, example data maps, validation deliverables, failure-mode descriptions, and a responsibility matrix. Also ask them to identify what is out of scope.

    A credible response will state prerequisites and limits. It will explain where manual controls may still be needed, which integrations depend on third-party systems, and what project work is required before production use. A weak response will rely on generic connector language without addressing data ownership, change control, exception handling, and long-term support.

  • What criteria should drive a scrap decision for aerospace structural parts?

    A scrap decision for aerospace structural parts should be driven first by approved technical requirements and objective evidence, not by part value, schedule pressure, or whether the defect “looks minor.” In practice, the core question is simple: can the part still be shown, with traceable records, to conform to drawing, material, process, and customer or program requirements after any permitted rework or repair? If the answer is no, or cannot be demonstrated credibly, scrap is usually the right decision.

    What should drive the decision

    The decision normally starts with product definition and disposition authority, not shop-floor opinion. For structural parts, the most important criteria are these:

    • Type and severity of nonconformance: dimensional out-of-tolerance, wrong material, heat-treat issue, surface damage, blend-out condition, hole quality problem, coating issue, process excursion, or traceability gap do not carry the same risk.
    • Location and structural criticality: the same defect may be acceptable in a non-critical area and unacceptable in a high-stress, fatigue-critical, bearing, sealing, or mating feature.
    • Engineering allowables and drawing requirements: if approved limits, repair schemes, or rework paths exist, they govern. If they do not, the part is not automatically recoverable.
    • Material and process pedigree: unknown or broken traceability, suspect lot control, or missing process records can force scrap even when the geometry appears recoverable.
    • Effect of rework or repair: additional machining, blending, sleeving, bushing, cold work, weld repair, or other recovery steps may consume life margin, alter fit, or trigger requalification requirements.
    • Inspection evidence quality: the decision depends on reliable measurement, calibrated equipment, valid methods, and a clear understanding of actual versus suspected defect extent.
    • Contractual and customer constraints: some programs restrict repair methods, concession use, or repeated rework more tightly than internal practice would suggest.
    • Disposition authority: MRB, engineering, quality, and sometimes customer approval are required depending on the condition and the contract. Operators and supervisors should not be making final structural accept/scrap calls informally.

    What should not drive it

    Cost matters, but it is not the primary criterion. A high-cost part is not more repairable just because it is expensive to replace. Likewise, delivery pressure is not a technical basis for use-as-is, repair, or rework. In regulated aerospace environments, forcing borderline parts through because capacity is tight usually creates a larger problem later in audit trail review, customer escape analysis, or service risk assessment.

    When scrap is often the right answer

    Scrap is commonly the right outcome when one of these is true:

    • The nonconformance violates a requirement with no approved rework or repair path.
    • The defect affects a critical feature and engineering cannot justify residual strength, fatigue performance, fit, or function.
    • Required traceability is missing or compromised for material, processing, or serialized identity.
    • The proposed recovery would push the part outside other limits, including minimum wall, edge distance, coating thickness, residual stress expectations, or dimensional stack-up.
    • The process excursion is broad enough that the true impact cannot be bounded credibly.
    • The record set needed to support acceptance, concession, or repair cannot be completed with confidence.

    Where MRB and engineering matter

    For aerospace structural hardware, scrap decisions are usually part of a formal nonconformance process. MRB may coordinate the disposition, but engineering rationale is often decisive where structural performance is affected. The exact split of authority depends on company procedures, delegated authority, customer flowdowns, and part criticality.

    This is where many plants get into trouble. They treat scrap as a production loss decision when it is really a controlled disposition decision. If the nonconformance workflow in MES, QMS, and ERP is weak, teams may argue from incomplete data, outdated drawings, or disconnected inspection records. In brownfield environments, that failure mode is common.

    Data and system dependencies

    A good scrap decision depends on having the right records linked together:

    • Current drawing and revision from PLM or document control
    • Traveler or routing history from MES or paper traveler records
    • Material certs, lot genealogy, and serialized traceability
    • Special process records
    • Inspection results, including CMM or manual measurement evidence
    • Prior rework, prior NCRs, or repeated escapes on the same feature
    • Customer-specific disposition restrictions where applicable

    If those records are fragmented across MES, ERP, QMS, and shared drives, the practical risk is not just delay. It is an incorrect disposition based on partial evidence. Full system replacement is usually not the answer here. In regulated aerospace environments, replacing core execution and quality systems wholesale often fails because of validation cost, qualification burden, downtime risk, and integration complexity. More often, plants improve the decision process by tightening record linkage, authority rules, and evidence capture across existing systems.

    A practical decision frame

    A defensible scrap decision for a structural part usually asks these questions in order:

    1. What exact requirement was violated?
    2. Is the feature structurally or functionally critical in this location?
    3. Is there an approved rework or repair path for this condition?
    4. Will that recovery path preserve all other requirements and margins?
    5. Do we have complete, trustworthy evidence and traceability to support the disposition?
    6. Do the required authorities agree and document the rationale?

    If any of those answers is unclear, the part should stay in formal nonconformance control until clarified. In many cases, that uncertainty ends in scrap, and that is sometimes the least risky outcome.

    Bottom line

    The right criteria are technical conformity, structural intent, traceability, and approved disposition authority. Scrap should be decided by whether the part can still be demonstrated to meet requirements after an allowed recovery path, not by replacement cost or urgency. Where evidence is weak, traceability is broken, or structural margin cannot be justified, scrap is usually the defensible decision.

  • What is the difference between ISMS and ISO 27001?

    ISMS and ISO 27001 are related but not the same thing. One is the management system you run, the other is the standard that defines requirements for that system.

    What is an ISMS?

    An Information Security Management System (ISMS) is the set of policies, procedures, controls, roles, and records that you put in place to manage information security risks. It is the operational system that governs how you protect information across people, processes, and technology.

    In a regulated industrial environment, an ISMS typically covers:

    • Risk assessment and treatment for production, engineering, and quality data
    • Access control across MES, ERP, QMS, PLM, historians, and OT networks
    • Change control for configurations, patches, and security-relevant updates
    • Incident detection, response, and post-incident review
    • Supplier and third-party access to manufacturing and technical data
    • Backup, recovery, and business continuity for critical systems and records

    The ISMS exists regardless of whether you reference a particular standard. It is the practical way you manage security in daily operations.

    What is ISO 27001?

    ISO/IEC 27001 is an international standard that specifies requirements for establishing, implementing, maintaining, and continually improving an ISMS. It provides a structured set of requirements and a catalogue of controls (through Annex A and related standards) that organizations can adopt and be audited against.

    Key points for ISO 27001 in industrial and manufacturing contexts:

    • It defines what an ISMS must cover at a minimum, not every detail of how you implement it.
    • It can be used purely as guidance, or as the basis for a formal, third-party certification program.
    • It touches both IT and OT, but the actual scope you define (systems, plants, data types) is up to your organization.
    • It interacts with existing requirements (for example, quality or safety standards) but does not replace them.

    ISO 27001 itself does not guarantee compliance with regulations or industry-specific requirements; it is a framework for managing information security risk in a systematic way.

    Key differences between ISMS and ISO 27001

    • Nature: An ISMS is the actual management system you operate. ISO 27001 is the standard that defines requirements for such a system.
    • Existence: You can have an ISMS without following ISO 27001, and you can use ISO 27001 as guidance without seeking certification.
    • Certification: Organizations are certified to ISO 27001; the ISMS is what is being assessed. The ISMS itself is not a standard.
    • Scope: Your ISMS scope is defined by your organization (for example, specific plants, systems, or data types). ISO 27001 provides the requirements your scoped ISMS must meet.
    • Content: The ISMS includes concrete processes, system configurations, records, and behaviors. ISO 2701 describes requirements such as performing risk assessments, maintaining an asset inventory, or managing incidents.

    Implications for regulated manufacturing and brownfield environments

    In most industrial operations, the ISMS must be designed to coexist with a complex, brownfield landscape: legacy MES, ERP, QMS, PLM, on-prem historians, paper batch records, and long-lived production equipment. ISO 27001 does not assume a greenfield replacement of these systems.

    Some practical implications:

    • System coexistence: The ISMS must span multiple vendors and generations of equipment. Many controls (for example, access management, logging, patching) are implemented via compensating measures when older systems cannot support modern capabilities directly.
    • Change control and validation: Tight change control and validation needs mean that retrofitting controls to MES, PLCs, or data historians can take significant time and testing. ISO 27001 requires managed change, but does not dictate specific validation methods.
    • Scope definition: To manage risk and cost, plants often start with a narrower ISMS scope (for example, engineering data and production records for specific product families) rather than trying to cover every asset and site at once.
    • Integration complexity: Centralized logging, identity management, and network segmentation across OT and IT usually require staged, multi-year work. ISO 27001 is compatible with this phased approach as long as risk is documented and treated.

    Trying to fully replace existing manufacturing systems solely to align with ISO 27001 is rarely practical. The more realistic strategy is to design an ISMS that layers additional controls, monitoring, and processes on top of current systems, and to improve coverage over time under structured change control.

    Summary

    • An ISMS is the operational framework and set of controls you run to manage information security.
    • ISO 27001 is the standard that defines requirements for an ISMS and may be used for certification.
    • In regulated, long-lifecycle manufacturing, the ISMS must work across existing, heterogeneous systems and be implemented gradually, with clear traceability, validation, and change control.

  • How can digital workflows simplify AS9100 audit preparation?

    Digital workflows can simplify AS9100 audit preparation by making required evidence easier to find, more consistent, and inherently traceable. The impact depends heavily on how well the workflows are designed, integrated, and governed in your existing QMS/MES/ERP landscape.

    1. Structuring evidence around AS9100 processes

    AS9100 audits are organized around processes (e.g. contract review, configuration management, FAI, nonconformance, corrective action). Digital workflows help by:

    • Aligning each workflow to a defined AS9100 process, so records naturally map to clauses.
    • Capturing mandatory fields (who, what, when, where, why, references) instead of relying on free-form notes.
    • Embedding required approvals and segregation of duties into the process steps.

    This reduces the manual mapping effort before an audit, because the structure of the workflow already reflects your process description and procedure set.

    2. Making records searchable and retrievable

    One of the most time-consuming parts of audit prep is locating specific records across paper files, network drives, and point systems. Digital workflows can simplify this by:

    • Centralizing key process records (e.g. NCRs, CARs, concessions, FAI reports, risk assessments) in a system of record.
    • Providing search using part numbers, serials, batches, program, customer, work order, date range, and clause-related tags.
    • Linking related records, such as connecting a nonconformance to its root cause, corrective action, and verification of effectiveness.

    The practical benefit is faster response when an auditor asks for, for example, “all nonconformances on this part family in the past 12 months and associated corrective actions.”

    3. Building traceability into day-to-day work

    AS9100 places strong emphasis on traceability, risk-based thinking, and configuration management. With well-designed digital workflows:

    • Lot/serial trace links can be captured automatically from MES or at the point of issue/inspection.
    • Configuration baselines and revision states are attached to the workflow record instead of inferred later.
    • Changes (to processes, documents, tooling, inspection plans) are connected to the affected parts, work orders, and quality records.

    This reduces the pre-audit effort needed to reconstruct traceability chains, as the links are created when work happens rather than during audit crunch time.

    4. Improving document control and version visibility

    Misaligned revisions and uncontrolled documents are common AS9100 findings. Digital workflows can help if they are integrated with document control:

    • Workflows reference controlled documents by ID and revision, not by description alone.
    • Obsolete versions are blocked or flagged when users try to select them.
    • Changes to procedures, work instructions, or inspection plans trigger linked change workflows with impact assessment, approvals, and effective dates.

    During an audit, you can show both the current version and the historical context of when changes went live and where they were applied, rather than relying on tribal knowledge.

    5. Standardizing nonconformance and CAPA handling

    AS9100 auditors look closely at how you manage nonconformities and corrective actions. Digital workflows can simplify preparation by:

    • Standardizing data captured in NCRs (defect type, location, detection point, disposition, containment actions).
    • Enforcing steps in your root cause analysis and CAPA process, including risk evaluation and verification of effectiveness.
    • Providing dashboards that summarize trends by part, process, supplier, or cause code.

    Instead of assembling ad hoc spreadsheets before the audit, you can generate reports directly from the workflow data, provided the system has been consistently used and validated.

    6. Providing audit trails and change history

    Digital workflows typically generate time-stamped audit trails for each action. This can reduce friction during audits by allowing you to show:

    • Who performed each step and when (e.g. review, approval, disposition, verification).
    • What data was changed and why, with comments or reason codes.
    • How records moved through the process, including escalations and rework loops.

    These trails are most credible when the system is access-controlled, validated, and governed under change control, and when users are not routinely working outside the system.

    7. Enabling proactive audit readiness

    When workflows and data are consistent, you can move from last-minute audit prep to continuous readiness by:

    • Setting up periodic internal reviews or layered process audits that pull directly from digital records.
    • Monitoring key indicators that AS9100 auditors care about (e.g. overdue corrective actions, open NCRs without containment, training gaps for process owners).
    • Preparing audit “playbooks” that link specific AS9100 clauses to the corresponding workflows, records, and reports.

    This does not remove the need for internal audits, but it makes them more data-driven and reduces manual compilation.

    8. Coexisting with legacy QMS, MES, and ERP

    In most aerospace and defense environments, digital workflows will coexist with existing QMS, MES, and ERP systems instead of replacing them. This has direct implications for audit simplification:

    • If workflows sit on top of multiple systems, you need clear rules for which system is the system of record for each type of evidence.
    • Interfaces should be designed to avoid double data entry and conflicting truth sources (for example, deviations raised in MES but analyzed and closed in a QMS workflow).
    • Integration and configuration changes must go through formal change control, with revalidation where needed, to maintain confidence in electronic records.

    Full replacement of core systems purely for audit convenience is rarely justified in AS9100 environments, due to qualification burden, downtime risk, and the effort to re-establish traceability and validation. Layered digital workflows that integrate with existing platforms are usually more practical.

    9. Constraints, risks, and dependencies

    Digital workflows do not automatically make AS9100 audits easier. Several conditions must be met:

    • Process design quality: Poorly designed or overly complex workflows can add work and ambiguities, increasing audit exposure.
    • Data discipline: If users bypass workflows, use workarounds, or enter incomplete data, the resulting records will not satisfy auditors.
    • Validation and change control: In regulated environments, significant workflow or integration changes should be validated and documented, or their records may be challenged.
    • Role clarity and training: Without clear ownership and training, workflows can drift from the documented QMS, creating discrepancies auditors will notice.
    • Scope boundaries: Some evidence will remain outside the workflow platform (e.g. certain test rigs, legacy machines, supplier systems), requiring hybrid preparation.

    Digital workflows are most effective for audit preparation when they are treated as part of the formal QMS and supported by realistic governance, not as informal tools or side systems.

    10. Practical first steps

    For organizations early in their digital journey, a pragmatic approach is to:

    • Identify the 2 or 3 AS9100 processes that cause the most audit pain (e.g. CAPA, configuration management, supplier control).
    • Digitize and standardize those workflows first, with explicit mapping to AS9100 clauses.
    • Ensure integration with existing document control and basic traceability data (part, lot, serial, work order).
    • Run at least one internal audit cycle relying primarily on digital records before your next external audit, to uncover gaps.

    Used this way, digital workflows can materially reduce the manual effort and risk in AS9100 audit preparation, while respecting the constraints of brownfield, long-lifecycle environments.

  • How early should audit preparation start for major certifications?

    For most major certifications, audit preparation should start months in advance, not weeks. A reasonable planning window is often 6 to 12 months before the audit, with longer lead time if you have significant process changes, new software, weak document control, site expansion, high turnover, or known gaps from prior audits.

    If the organization is already disciplined, records are current, and internal audits are working, the timeline can be shorter. If evidence is fragmented across paper, spreadsheets, MES, ERP, PLM, QMS, and email, preparation usually takes longer because the real issue is not the audit date. It is whether the underlying system is consistently operating and traceable.

    What should happen early

    • Confirm scope, sites, products, processes, and applicable requirements.

    • Review prior findings, overdue CAPA, repeat issues, and open risk items.

    • Run internal audits early enough to correct root causes, not just clean up records.

    • Check training, approvals, revision control, equipment status, and record retention.

    • Test whether evidence can be retrieved quickly and consistently across systems.

    • Stabilize major process or system changes before the audit where possible.

    What usually drives a longer timeline

    • Recent ERP, MES, PLM, QMS, or document management changes

    • Brownfield integrations with weak data mapping or inconsistent master data

    • Paper-to-digital transitions that are not fully adopted on the floor

    • Poor closure discipline for deviations, NCRs, CAPA, or training records

    • Multi-site operations with local workarounds and inconsistent procedures

    • High personnel turnover or reliance on tribal knowledge

    In regulated and long-lifecycle environments, late preparation is risky because many gaps cannot be solved quickly without creating new problems. Rewriting procedures, changing workflows, or replacing systems close to an audit can introduce validation burden, retraining needs, new failure modes, and questions about whether the process is mature or merely staged for the audit.

    This is also why full replacement strategies often fail as an audit-readiness tactic. In brownfield plants, ripping out legacy MES, ERP, PLM, or QMS platforms before a major audit usually increases risk due to integration complexity, downtime constraints, qualification effort, and the need to preserve traceability and change control across long equipment lifecycles. Coexistence and targeted remediation are often more realistic than wholesale replacement.

    The practical goal is not to “prepare for the audit” as a short-term event. It is to make sure the operating system, records, and evidence trail can withstand normal scrutiny. If preparation only starts when the auditor is scheduled, the organization is usually too late for meaningful corrective action and left with superficial fixes.

    So the short answer is: start as soon as the audit becomes likely, and ideally treat audit readiness as a continuous discipline. For a major certification, 6 to 12 months is common. More time may be necessary if your processes, systems, or evidence trail are not stable.