Connect981 – Content Dev

RSC Topic: Document Control & Version Governance

Change control, approvals, and access rights across workflows.

  • Configuration versioning

    Configuration versioning is the practice of assigning identifiable versions to a system, application, device, process, or equipment configuration as it changes over time. It commonly refers to keeping a controlled history of settings, parameters, logic, mappings, templates, and other non-code configuration items so current and prior states can be identified and compared.

    In industrial and regulated environments, configuration versioning is used to understand what configuration was active at a given time, who changed it, when it changed, and what changed between versions. This can apply to MES rules, ERP integration mappings, PLC or SCADA parameters, electronic forms, work instruction settings, quality workflows, user-role configurations, and similar controlled setup data.

    Configuration versioning does not mean any change is automatically approved or released. It is about maintaining version identity and history. Approval workflows, change control, and document control may be related, but they are separate controls.

    What it typically includes

    • Version numbers, revision IDs, or other unique identifiers for a configuration state

    • Records of additions, removals, or edits to configuration items

    • Date, time, and user attribution for changes

    • Comparison between versions

    • Rollback or restoration to a prior known configuration, where supported

    • Linkage to deployment, release, or change records in broader governance processes

    Common confusion

    Configuration versioning is often confused with document version control and source code version control. Document version control applies to files such as SOPs, specifications, or controlled forms. Source code version control applies to software code. Configuration versioning focuses on operational settings and structured system behavior that may exist outside code files or formal documents.

    It is also distinct from a full audit trail. An audit trail may record every event or field-level change. Configuration versioning usually emphasizes named, recoverable configuration states and their revision history.

    Manufacturing context

    In manufacturing systems, configuration versioning commonly appears where system behavior must remain stable and explainable across production runs, quality events, or integration updates. Examples include versioned routing parameters in MES, revised inspection plan settings, changes to label templates, or updates to ERP-to-MES field mappings. The goal is to preserve a reliable record of which configuration was in effect for a given operation or period.

  • How often should KPI definitions and catalogs be reviewed?

    A practical baseline is to review KPI definitions and the KPI catalog at least annually, with targeted reviews whenever something material changes.

    Annual review is usually the minimum, not the full answer. In most regulated manufacturing environments, you should also trigger a review when any of the following occur:

    • process changes that alter how work is executed or recorded
    • ERP, MES, PLM, QMS, historian, or data pipeline changes
    • site rollouts to new plants, lines, programs, or suppliers
    • changes in ownership, accountability, or escalation paths
    • new regulatory, customer, or internal reporting requirements
    • persistent disputes about what a metric means or how it is calculated
    • evidence that source data quality, timeliness, or completeness has shifted

    If KPI definitions are stable, data sources are controlled, and the catalog is actually being used, annual review may be sufficient. If the organization is still standardizing metrics across sites, integrating brownfield systems, or changing reporting logic frequently, quarterly governance review is often more realistic.

    What should be reviewed

    The review should cover more than the metric name and formula. At minimum, confirm the business definition, calculation logic, source systems, data lineage, refresh timing, owner, intended use, exclusions, thresholds, version history, and whether the metric is still actionable. Many KPI catalogs become unreliable not because the formula changed, but because the source system behavior, coding practices, or master data changed underneath it.

    Why cadence varies

    There is no universal interval because review frequency depends on process maturity, system stability, integration quality, and data governance discipline. A mature plant with controlled interfaces and stable reporting may need fewer changes. A multi-site operation with mixed vendors, manual workarounds, and legacy integrations usually needs more frequent checks because KPI drift is common.

    In brownfield environments, the same KPI can be calculated differently across ERP, MES, spreadsheets, BI tools, or local databases. That is a governance issue, not just an analytics issue. Reviewing the catalog on a calendar without checking source-system changes will miss the real failure mode.

    How to manage it in practice

    Put KPI definitions and catalogs under formal governance and change control. That does not mean every KPI change needs a heavy process, but it should be traceable. If a metric definition changes, you should know:

    • what changed
    • why it changed
    • who approved it
    • when it took effect
    • whether historical trend lines remain comparable
    • which dashboards, reports, alerts, and decisions are affected

    This matters in regulated operations because unmanaged KPI changes can undermine trend interpretation, audit evidence, escalation logic, and cross-site comparability. A cleaner dashboard is not the same as a controlled metric.

    Recommended review pattern

    • Annual formal review of the full KPI catalog
    • Quarterly governance check for high-impact or disputed KPIs
    • Event-driven review whenever processes, systems, mappings, or business rules change
    • Immediate review when users cannot reconcile numbers across systems

    If resources are limited, prioritize KPIs tied to quality, traceability, throughput, schedule adherence, cost of poor quality, and management escalation. Low-value vanity metrics do not need the same governance intensity.

    So the short answer is: at least annually, and more often when systems, processes, or reporting logic change. If your definitions are frequently disputed, the review cadence is already too slow.

  • How can digital work instructions and real-time revision control reduce misbuilds on the shopfloor?

    Digital work instructions with real-time revision control can materially reduce misbuilds, but only when they are tightly integrated with your change processes, systems of record, and shopfloor reality.

    Core mechanisms that reduce misbuilds

    Digital work instructions and proper revision control help in several concrete ways:

    • Single source of truth: The current released version of the instruction is stored centrally and referenced by all work centers. This reduces the risk of printed copies, screenshots, or local files drifting out of date.
    • Automatic delivery of the right revision: When integrated with MES or routing logic, the system can present the correct instruction revision based on part number, configuration, work order, effectivity date, or serial/lot. This helps avoid using the wrong variant or superseded process.
    • Real-time revision updates: Once an instruction change is released, operators see the new version at the next operation (and, where appropriate, even mid-shift). This shortens the window where old and new instructions coexist and cause confusion.
    • Obsolescence control: Obsolete versions are hidden from normal use, or clearly marked as superseded. This reduces the chance that operators refer to old printouts or bookmarked PDFs.
    • Step sequencing and checks: Digital instructions can enforce sequence and require confirmations (e.g., checkboxes, data entry, barcode scans, torque values) at critical steps. This makes it harder to skip or misinterpret key instructions.
    • Configuration-sensitive content: For configurable products, the instruction can dynamically show only the relevant steps, torque charts, or inspection criteria based on BOM/config code, reducing cognitive load and selection errors.
    • Integrated visual aids: High-quality photos, 3D models, videos, and callouts are easier to maintain and update digitally than on paper, making it more likely that operators use accurate visual guidance.

    Role of real-time revision control

    Revision control is often where misbuilds are created or prevented. Effective real-time revision control contributes through:

    • Traceable approval workflow: Changes move from draft to released state only after structured review (e.g., with quality, manufacturing, and sometimes customers). Digital instructions must mirror your existing change control, not bypass it.
    • Effectivity control: Revisions are tied to explicit effectivity rules (date, serial number, lot, work order, or configuration). Misbuilds often occur when effectivity is informal or inconsistently applied.
    • Automatic blocking of outdated content: When a new revision is effective, older revisions should be blocked for new work. If legacy builds still legitimately use old revisions, this must be clearly distinguished in the UI and routing.
    • Change awareness for operators: Real-time control can require operators to acknowledge that a new revision is in place (e.g., “rev C effective from SN 1005”), reducing reliance on informal shift briefings.
    • Immediate correction of known issues: If a misbuild pattern is discovered, a corrected instruction can be released, and the new version is presented across workstations without waiting for paper reissue.

    Dependencies and preconditions

    The impact on misbuilds depends heavily on how digital work instructions and revision control are implemented and connected to your existing landscape:

    • Integration with PLM/ERP/MES/QMS: To reliably prevent misbuilds, instructions need to be aligned with the current BOM, routing, and deviation/waiver status. If each system maintains its own disconnected view of the “truth,” misalignments can still cause wrong builds even with digital instructions.
    • Data and master-data quality: Incorrect or incomplete part/BOM/revision metadata will propagate through digital instructions. Misbuilds often shift from the operator to the data layer if master data is weak.
    • Validated and tested workflows: In regulated environments, you will typically need to validate that revision changes, effectivity logic, and system interactions behave as intended. Poorly tested integrations can introduce new failure modes (e.g., wrong rev displayed for a certain configuration).
    • Devices and network reliability: Reliance on tablets, terminals, or HMIs requires stable connectivity and adequate hardware. If systems are slow or unavailable, operators will revert to offline workarounds, which reintroduce misbuild risk.
    • Access control and audit trails: Robust user and role management is needed so only authorized roles can change or release instructions, and all changes are audit-trailed with timestamps and rationale.

    Common failure modes and tradeoffs

    Digital work instructions do not automatically remove misbuilds. In practice, some common pitfalls can offset the benefits:

    • Shadow copies: Operators printing or screenshotting instructions for convenience, then using those after a revision change. Mitigation usually requires both technical controls (watermarks, clear rev labels) and procedural discipline.
    • Conflicting sources: If PLM, MES, and document control systems are not harmonized, operators may see instructions that are inconsistent with the released design file or approved deviation.
    • Overly complex UIs: If the digital interface is slow or confusing, operators may miss critical revision indicators or configuration flags and make the same errors they did with paper.
    • Partial deployment: Using digital instructions at some stations and paper at others can create handoff mismatches, especially when a revision changes mid-build.
    • Insufficient training: Without explicit training on how revisions are surfaced and what operators must do when they see a change, staff may ignore new prompts or misinterpret them.

    Tradeoffs you will typically navigate include:

    • Control vs. flexibility: Stricter revision enforcement (e.g., hard blocks on starting work if change acknowledgments are missing) reduces misbuilds but can increase perceived friction and downtime when data is wrong.
    • Speed vs. validation: Rapid changes to instructions can fix emerging issues faster but must still go through controlled review and validation in regulated environments.
    • Standardization vs. local optimization: Centralized templates simplify governance but may feel constraining to specific cells or product lines that have unique needs.

    Coexistence with legacy systems in brownfield environments

    In most regulated, long-lifecycle environments, you will not replace existing MES/PLM/ERP/QMS systems just to deploy digital work instructions. Instead, digital instructions usually sit on top of, or alongside, existing systems:

    • PLM or document management remains the system of record: Digital work instructions often reference or synchronize from PLM but do not replace it. Changes still start in PLM or engineering change systems.
    • MES as the orchestration layer: MES commonly determines which operation and part/configuration is in progress and calls the correct instruction revision from the instruction system.
    • ERP as the order and effectivity driver: Work orders, serial ranges, and planning data from ERP influence which instruction revision is applicable at which time.
    • QMS for deviations and CAPA: Deviations, concessions, and CAPA-driven changes live in QMS but must be reflected clearly in the instructions, often via flags, additional steps, or alternate flows.

    Because full system replacement is expensive to qualify and validate, and carries high downtime and integration risk, many plants instead choose incremental integration: start by digitizing work instructions for a subset of operations, link them to existing revision control in PLM/QMS, and extend over time.

    Practical steps to achieve real misbuild reduction

    To realize actual reductions in misbuilds rather than just digitizing existing problems, many plants focus on:

    • Defining ownership: Clear roles for who authors instructions, who approves them, and who manages revisions and effectivities.
    • Harmonizing revision conventions: Aligning revision identifiers and effectivity rules across PLM, MES, and the digital instruction system.
    • Flagging critical-to-quality steps: Adding explicit confirmations, data capture, or secondary verification to steps with the highest misbuild risk.
    • Designing operator-friendly UIs: Large, clear revision labels, obvious configuration indicators, and fast navigation at the station level.
    • Monitoring and feedback loops: Using misbuild and defect data to refine instructions and detect where operators still circumvent or misinterpret them.

    When implemented with sound integration, validated logic, and disciplined change control, digital work instructions with real-time revision control can significantly reduce misbuilds by ensuring the right instruction reaches the right operator at the right time, and by making it harder to accidentally follow the wrong process. The scale of benefit depends on how well they are embedded into your existing systems and governance, not just on the tool itself.

  • What types of documents must be controlled under AS9100?

    Under AS9100, the practical answer is: any documented information your organization needs to run the quality management system, control product realization, demonstrate conformity, or provide objective evidence should be controlled.

    So no, it is not just a small set of quality manual documents. In most aerospace manufacturing environments, document control typically extends to both internally created documents and externally provided documents that affect product, process, inspection, release, or traceability.

    What is commonly controlled

    • Quality manuals or equivalent top-level QMS documentation, if your organization maintains them

    • Policies, procedures, SOPs, and process maps

    • Work instructions, standard work, setup sheets, and operator guidance

    • Engineering drawings, models, specifications, parts lists, and technical data packages when used for production or verification

    • Inspection plans, test methods, sampling instructions, and acceptance criteria

    • Forms, templates, and checklists where version matters

    • Production routers, travelers, job packets, and manufacturing planning documents

    • Training documents tied to qualified methods or controlled processes

    • Supplier quality requirements, flow-down documents, and approved external specifications

    • Customer requirements, customer-provided specifications, and contract quality clauses when they govern execution

    • Calibration, maintenance, validation, and qualification procedures where applicable

    • Risk management procedures, change control procedures, nonconformance procedures, and corrective action procedures

    • Records retention and disposition instructions

    External documents also matter

    AS9100 document control is not limited to what you author internally. If external documents are necessary for planning, operation, inspection, or compliance to customer and regulatory requirements, those documents generally need identification, current revision control, availability at point of use, and protection from unintended use of obsolete versions.

    Examples include customer drawings, industry specifications, process standards, supplier instructions, and certain regulatory or statutory references used in execution. The exact list varies by product, contract, and process risk.

    What usually must be controlled as records

    Some documents are controlled because they instruct work. Others are controlled because they provide evidence after the fact. In practice, organizations usually control retention, access, integrity, and disposition for records such as:

    • Training records and qualification records

    • Inspection and test results

    • First article and verification records

    • Material certifications and traceability records

    • Nonconformance, concession, deviation, and corrective action records

    • Internal audit results and management review outputs

    • Supplier performance and approval records

    • Configuration and change history where applicable

    The control method for a record is not always the same as for a work instruction, but both still require governance.

    What determines the real scope

    The required scope depends on your actual operating model. A small machine shop, a complex assembly site, and an MRO environment will not control exactly the same document set. The scope is usually shaped by:

    • Product complexity and criticality

    • Customer-specific requirements and flowed-down clauses

    • Special processes and validation requirements

    • How much work is paper-based versus digital

    • Whether engineering, planning, quality, and operations are integrated or fragmented across systems

    • Retention and traceability expectations

    If a document can change how work is done, how product is accepted, or how evidence is produced, assume it needs some level of control unless your process definition clearly says otherwise.

    Brownfield reality

    In many plants, controlled documents are spread across ERP, MES, PLM, QMS, file shares, network folders, email attachments, and paper binders. That is common, but it increases revision risk and makes evidence collection harder.

    A full rip-and-replace approach is often not realistic in regulated aerospace environments. It can fail because of qualification burden, validation effort, downtime risk, integration complexity, and the need to preserve traceability across long asset and program lifecycles. In practice, many organizations improve control by defining system ownership, approved sources of truth, revision synchronization rules, and change control across existing platforms rather than replacing everything at once.

    That means document control under AS9100 is partly a process question and partly a systems governance question. If your PLM holds drawings, your MES issues work instructions, and your QMS manages procedures, the control framework has to work across all three. If those handoffs are weak, compliance risk rises even if each individual system looks acceptable on its own.

    Common failure modes

    • Operators using printed or locally saved obsolete instructions

    • Drawings updated in engineering systems but not propagated to execution systems

    • Uncontrolled spreadsheet templates used for acceptance decisions

    • Customer specifications referenced in contracts but not maintained at current revision

    • Records stored in shared drives without retention, access, or change-history discipline

    • Training content changed without corresponding approval or retraining impact assessment

    Those are not edge cases. They are common in mixed-system environments.

    Bottom line

    AS9100 does not give a short universal checklist of only a few documents that must be controlled. The safer interpretation is broader: control all documented information that is necessary to run the QMS, perform and verify the work, meet customer and applicable requirements, and preserve traceable evidence. The exact inventory is site-specific and should be defined through your processes, document hierarchy, and change-control model.

  • How can we change a KPI definition without losing historical comparability?

    You generally should not overwrite a KPI definition and pretend the history still means the same thing. If the definition changes materially, the safe answer is to treat it as a new KPI version and preserve the old one for historical reporting.

    The goal is not to make unlike data look comparable. The goal is to keep historical interpretation honest, preserve traceability, and give stakeholders a controlled way to bridge old and new measures.

    What to do in practice

    • Version the KPI definition. Keep the prior formula, inclusion and exclusion rules, source systems, units, aggregation logic, and owner. Assign an effective date to the new version.

    • Do not rewrite historical values by default. If old periods were calculated under a different rule set, keep those values tied to that rule set unless you can reliably recalculate them from retained raw data.

    • Run both definitions in parallel for a period. A dual-run period is often the cleanest way to quantify the delta and show leadership what changed because of operations versus what changed because of measurement.

    • Record the reason for change. For example: corrected business logic, changed production scope, improved data source, changed denominator, or harmonization across plants.

    • Publish a comparability note with the KPI. Dashboards and reports should indicate that values before and after the effective date are not directly comparable unless explicitly normalized.

    When back-calculation is possible

    You can sometimes recalculate historical values under the new definition, but only if the necessary source data still exists at the right granularity and its lineage is trustworthy.

    Back-calculation tends to be feasible when the change is formula-based and the underlying event data, timestamps, quantities, statuses, and master data mappings have been retained. It tends to fail when the new definition depends on data that was never captured, was captured inconsistently, or changed semantics over time across MES, ERP, PLM, QMS, historian, or spreadsheet-based reporting.

    If you do back-calculate, keep both series:

    • Original reported history for auditability and management traceability

    • Restated history for trend analysis, clearly labeled as reconstructed under the new definition

    Do not collapse them into one unlabeled time series.

    What must be under change control

    A KPI definition change is usually not just a dashboard edit. In regulated and high-traceability environments, it often affects management reporting, escalation thresholds, site comparisons, and evidence used in investigations or reviews. At minimum, control:

    • definition and formula version

    • data source mapping and transformation logic

    • effective date and approval

    • owner and steward

    • affected reports, alerts, and downstream consumers

    • validation of calculations after the change

    If KPI values feed regulated records, quality decisions, or formal review processes, the validation burden may be higher. That depends on how the metric is used, not just where it is displayed.

    Brownfield system reality

    In mixed environments, historical comparability usually breaks because systems do not agree on the underlying business event. One plant may timestamp completion in MES, another in ERP, and a third may patch gaps manually. A KPI definition change can expose those differences rather than fix them.

    That is why replacing every upstream system is rarely the practical answer. Full replacement often fails because of qualification burden, downtime risk, integration complexity, change control overhead, and the reality that long-lived equipment and legacy applications cannot be swapped out cleanly. In most plants, the workable approach is coexistence:

    • define the KPI canonically

    • map local source systems to that definition

    • document plant-specific exceptions

    • version changes centrally

    • validate the reporting layer and interfaces carefully

    If the source data model is weak, no governance process will create perfect comparability after the fact.

    Tradeoffs to be explicit about

    • Strict continuity versus honest measurement. Keeping one continuous line on a dashboard is visually convenient, but it can hide a meaning change.

    • Back-calculation versus auditability. Restating history may improve analytics, but it must not erase what was originally reported.

    • Cross-site standardization versus local practicality. A single KPI definition across plants is useful, but only if source-system mappings are mature enough to support it.

    • Speed versus control. Fast KPI changes without governance create reporting drift and later disputes about performance.

    A workable policy

    A practical default policy is:

    1. Classify the change as minor or material.

    2. If material, create a new KPI version.

    3. Maintain the old series unchanged.

    4. Run both versions in parallel for an agreed period if possible.

    5. Back-calculate only when raw data completeness and lineage are adequate.

    6. Label all reports with version and effective date.

    7. Approve through normal data governance and change control.

    So the short answer is: change the KPI by versioning it, not by silently redefining history. Historical comparability can sometimes be approximated through dual-running or restatement, but it cannot be assumed.

  • How do aerospace manufacturers manage configuration control during production ramp-up?

    They manage it by treating ramp-up as a controlled change problem, not just a capacity problem.

    In practice, that means locking down the approved product and process definition, controlling when revisions become effective, and making sure the shop floor, suppliers, and quality systems all execute against the same released configuration. During ramp-up, the risk is not only engineering change volume. It is also the higher chance of mixed builds, temporary workarounds, duplicated local spreadsheets, rushed tooling updates, and inspection evidence that no longer matches the released revision.

    What usually has to be controlled

    • Product definition revisions such as drawings, models, BOMs, and characteristics.

    • Process definition revisions such as routings, work instructions, setup sheets, inspection plans, and test procedures.

    • Effectivity rules by serial number, lot, date, work order, customer contract, or aircraft program block.

    • Tooling, fixtures, NC programs, and calibrated inspection methods.

    • Material substitutions, approved deviations, concessions, and temporary dispositions.

    • Supplier-issued documentation and outside processing requirements.

    How it is typically done

    Most aerospace manufacturers use a staged release process anchored in PLM or engineering control, then propagate approved changes into ERP, MES, QMS, and document control. The exact system of record varies by plant and vendor stack, but the pattern is consistent: only released revisions should drive execution, and each downstream system needs a traceable handoff.

    Common controls include:

    • Formal engineering change and manufacturing change workflows with approval history.

    • Effectivity-based release so old and new configurations do not overlap unintentionally.

    • Digital travelers or controlled paper packets that present the correct revision at the point of use.

    • Revision checks at work order release, kitting, first operation start, inspection, and shipment.

    • As-built traceability tying serial number or lot history to the exact revision and disposition used.

    • Hold points for first runs after change, often tied to FAI, delta FAI, or heightened inspection where required by the manufacturer’s process.

    • Supplier communication and acknowledgment when changes affect procured parts, outside processing, or documentation requirements.

    Ramp-up often adds temporary capacity, second shifts, alternate lines, and new suppliers. That is where configuration control tends to break down unless the release process is simple enough to execute repeatedly and strict enough to prevent unauthorized local changes.

    What makes ramp-up harder

    Ramp-up compresses timelines while change volume rises. Engineering may still be maturing the design, manufacturing engineering may be refining routings and tooling, and quality may still be closing findings from early builds. Those realities create predictable failure modes:

    • Operators working from superseded instructions.

    • ERP and MES revision mismatches.

    • Serial numbers started under one configuration and completed under another without clear disposition.

    • Supplier parts arriving to an old revision after the plant has moved on.

    • Tooling and NC program updates lagging the released design.

    • Inspection plans not updated for revised characteristics.

    • Temporary deviations becoming de facto standard process without formal closure.

    None of those are rare in brownfield environments. They are usually symptoms of weak synchronization between systems and functions, not just weak discipline on the shop floor.

    Brownfield reality

    Very few aerospace plants solve this by replacing everything with one new platform. Full replacement often fails because qualification burden, validation cost, downtime risk, integration complexity, and long asset lifecycles are too high. More commonly, manufacturers keep the existing PLM, ERP, MES, QMS, and document systems, then harden the interfaces and governance around them.

    That approach is less elegant, but often more realistic. It can work if the plant is explicit about:

    • Which system is authoritative for each object, such as BOM, routing, work instruction, nonconformance, or training record.

    • How revisions and effectivity values map across systems.

    • What must be synchronized automatically versus checked procedurally.

    • How exceptions are logged, reviewed, and closed under change control.

    If those rules are not clear, digitizing faster can simply spread bad revision control faster.

    Tradeoffs and practical limits

    More control usually means more overhead. More flexibility usually increases risk. Aerospace manufacturers balance that by tightening control on product definition and traceability while allowing bounded operational flexibility through approved deviations, temporary instructions, or phased effectivity.

    There is no universal setup that guarantees clean execution. Results depend on system integration quality, master data discipline, document governance, workforce training, and how well the plant handles temporary states during transition. Even with good systems, weak adoption or poor data readiness can still produce configuration escapes.

    The practical goal during ramp-up is not zero change. It is controlled change with evidence: who approved it, where it applies, when it became effective, what was built under it, and how any exceptions were dispositioned.

  • How can we control external documents such as customer specifications?

    Controlling external documents like customer specifications, OEM standards, and industry codes requires treating them as part of your formal document control system, even though you do not own or author them. The core goal is to ensure that operations always use the correct, approved revision and that you can prove it.

    1. Define scope and ownership of external documents

    Start by identifying which external documents need control:

    • Customer specifications and quality requirements
    • OEM process specs, standard practices, and design standards
    • Industry standards that are contractually flowed down (e.g., EN, ISO, NAS, SAE, ASTM)
    • Customer drawings or models that are not under your configuration control

    Then assign ownership inside your organization:

    • Define a responsible function (e.g., Document Control, Quality Engineering, or Program Engineering) for each customer or program.
    • Document who can add, revise, or retire external documents in your system.

    2. Establish a controlled intake and approval process

    External documents should not reach the shop floor directly from email or a customer portal. At minimum, implement:

    • Formal intake channels: customer portals, EDI, secure file transfer, or defined email addresses monitored by Document Control or Quality.
    • Initial verification: confirm document authenticity, customer identity, and that it applies to your products or contracts.
    • Impact assessment: Engineering/Quality review for process impact, tooling changes, revalidation needs, and training impact.
    • Internal approval: defined sign-offs before the document is marked “released for use” in your system.

    Without this step, plants tend to accumulate uncontrolled PDFs and local copies, which undermines traceability and creates risk during audits or customer escapes.

    3. Use a single controlled master source, not scattered copies

    In brownfield environments, you usually cannot replace your QMS, PLM, or customer portals. Instead, you should define a single internal “master” source for each external document and then link to it:

    • Master repository: typically a QMS/DMS, PLM, or validated file repository with version control and audit trails.
    • Unique identifiers: assign internal IDs or keys and map them to the customer document number and revision.
    • Access control: define who can read, download, or update each document, especially when export controls may apply.
    • Readonly for users: shop-floor and engineering users should not be able to alter the master file or its metadata.

    Operational tools (MES, digital work instructions, ERP, MRP) should reference that master via links, IDs, or APIs rather than storing separate uncontrolled copies wherever possible. Where copies are technically necessary, they should be traceable to the master and updated under change control.

    4. Link external documents explicitly to parts, routings, and work instructions

    Control is not useful if operators cannot tell which external specs apply to which job. You need clear mapping from external documents to work content:

    • Part/BOI/BOE linkage: associate relevant customer specs to part numbers, assemblies, or part families in ERP/PLM.
    • Routing-level references: for each operation, reference specific external specs and sections (e.g., spec ABC123, section 4.2).
    • Digital work instructions integration: embed links or controlled excerpts of external specs into work instructions, with the source document and revision clearly identified.
    • Ordering rules: encode precedence logic (contract > customer spec > OEM spec > internal spec) so that conflicts are handled consistently.

    How you implement this depends heavily on your existing systems. Some MES/PLM systems can natively manage these relationships; others require custom fields or external registries. Whatever the approach, ensure traceability from the executed work order back to the specific external documents and revisions used.

    5. Control revisions and change notifications

    External documents change on the customer’s schedule, not yours. You need a way to detect changes and propagate them under change control:

    • Change detection: periodic checks of customer portals, formal email notifications, or automated monitoring where offered by the customer.
    • Revision logging: record the previous and new revision, effective date, and who performed the update.
    • Impact analysis workflow: structured review to determine affected parts, processes, tools, and validation activities.
    • Change control: integrate into your existing ECN/ECR or document change process, including approvals and implementation plans.
    • Effective dates on the floor: define when the new spec revision becomes mandatory and how to handle work-in-process and fielded product when relevant.

    In regulated environments, avoid silent or overnight switches without documented assessment. Customers and auditors will expect to see a clear chain from the revision notice to process changes, training updates, and evidence of use on specific work orders.

    6. Make external documents visible and unambiguous at point of use

    Operators and inspectors should not have to guess or hunt for the applicable external spec. At point of use:

    • Display the document number, title, and revision on work instructions, travelers, or inspection sheets.
    • Where possible, provide a direct link to the controlled copy from MES or digital work instructions for read-only viewing.
    • Highlight spec-driven characteristics and limits explicitly, rather than forcing operators to interpret long documents on the line.
    • Train operators and inspectors on how to verify that they are using the right spec and revision, especially for rework and MRB work.

    For paper-based environments, this may mean printed extracts with a clear reference back to the controlled external document and its revision in your register.

    7. Maintain traceability for audits and investigations

    For regulated and aerospace-grade environments, your document control needs to support audits and investigations:

    • Be able to show which external spec revision was in effect for any given time period, part, and work order.
    • Retain historical versions of external documents or at least their key requirements and change logs, subject to licensing constraints.
    • Ensure that nonconformance and CAPA investigations can tie back to the customer spec and any changes that may have contributed.
    • Provide evidence trails for approvals, impact analyses, and effective dates during audits.

    Be explicit about contractual and IP constraints: some customers restrict storage, duplication, or redistribution of their documents, which can limit how you implement long-term archival. Where this applies, document the limitation and your mitigations.

    8. Address coexistence with legacy systems and long equipment lifecycles

    Most plants already have a mix of ERP, MES, PLM, QMS, shared drives, and email workflows. Fully replacing these systems just to improve external document control is rarely practical due to validation cost, qualification burden, downtime risk, and integration complexity.

    Pragmatic options include:

    • Define a single system of record (often QMS or PLM) for external documents, even if references live in multiple other systems.
    • Introduce a lightweight registry or index that maps customer specs to parts, routings, and systems when your core platforms cannot be easily reconfigured.
    • Use APIs or scripted imports to synchronize metadata (document number, title, revision, effective date) rather than manually updating every system.
    • Handle paper and legacy equipment by controlling travelers and work instructions that clearly reference the current external specs and revisions.

    Whatever you choose, treat configuration and integrations as changes subject to your standard validation and change control so that evidence is available for customers and regulators.

    9. Document the approach in your QMS

    Finally, your method for controlling external documents should be documented and maintained as part of your quality management system:

    • Define what qualifies as an “external document” requiring control.
    • Describe intake, approval, change control, and obsolescence processes.
    • Specify system roles and responsibilities for each function.
    • Explain how external documents are linked to parts, processes, and records of production.
    • Include how you handle limitations such as customer portal access rules, export controls, and IP restrictions.

    This written standard helps align operations, engineering, quality, and IT, and provides a clear reference when systems or contracts change.

  • What documents are mandatory under ISO 9001:2015?

    ISO 9001:2015 uses the term “documented information” instead of a fixed list of procedures or a “quality manual.” The standard itself explicitly requires only a core set of documents and records, but many regulated plants maintain a larger QMS library to satisfy customers, regulators, and internal risk expectations.

    Core documented information explicitly required

    The following items are directly required by ISO 9001:2015. Wording and structure can vary, and they can live in multiple systems (QMS, MES, ERP, PLM), as long as they are controlled and accessible.

    • Scope of the quality management system (clause 4.3)
    • Documented information needed by the organization for the effectiveness of the QMS (clause 4.4.2) – at minimum, this includes the items below, but can be broader based on risk.
    • Quality policy (clause 5.2.2) – documented and communicated.
    • Quality objectives and planning to achieve them (clause 6.2.1 & 6.2.2).
    • Criteria and methods for operation and control of processes where needed to ensure effective operation (clause 4.4.1). In practice, this often means documented procedures, work instructions, or routings for key processes.
    • Documented information needed to support the operation of processes (clause 7.5.1b) – typically includes selected SOPs, work instructions, and specifications, particularly for special processes or regulated operations.

    Records that must be retained

    The standard calls out specific records that must be retained as evidence that processes are performed as planned. At a minimum, these include:

    • Monitoring and measurement results (clause 9.1.1) as applicable to your processes and products.
    • Evidence of fitness for purpose of monitoring and measuring resources (e.g., calibration) (clause 7.1.5.1).
    • Evidence of competence for persons doing work under your control (e.g., training records, qualifications) (clause 7.2).
    • Design and development planning, inputs, controls, verification, validation and changes, where design is in scope (clause 8.3.2 to 8.3.6).
    • Evidence that production and service provision meet requirements (clause 8.5.1).
    • Traceability records where traceability is a requirement (clause 8.5.2).
    • Records of property belonging to customers or external providers if applicable (clause 8.5.3).
    • Control of changes in production or service provision (clause 8.5.6).
    • Results of the review and verification of externally provided processes, products and services (supplier evaluations, approvals, monitoring) (clause 8.4.1 & 8.4.2).
    • Results of design and development reviews, verification and validation (clause 8.3.2 to 8.3.4).
    • Records of nonconformities and actions taken (clause 8.7.2).
    • Results of corrective actions (clause 10.2.2).
    • Results of internal audits (clause 9.2.2).
    • Results of management reviews (clause 9.3.3).

    In industrial and aerospace contexts, many of these records live in multiple systems and formats: QMS software, MES logs, ERP data, PLM change records, calibration systems, and sometimes controlled spreadsheets. ISO 9001:2015 does not mandate specific tools; it requires that these records exist, are controlled, and are retrievable.

    What is no longer strictly mandatory compared to older versions

    ISO 9001:2015 removed some explicit documentation requirements that were present in ISO 9001:2008, such as:

    • No explicit requirement for a single quality manual.
    • No explicit list of six required documented procedures (e.g., control of documents, control of records, internal audit) as standalone procedures.

    However, the underlying controls are still required. You still need defined methods for document control, records control, nonconformance management, internal audits, and corrective action. They can be embedded in broader procedures, digital workflows, or system configurations, but you must be able to demonstrate that they are defined, consistently applied, and under change control.

    Regulated and aerospace contexts: what is typically expected

    In regulated manufacturing (e.g., aerospace with AS9100, medical devices, defense), the “practical minimum” goes beyond ISO 9001:2015’s explicit list. You will typically see:

    • A structured QMS document hierarchy (policy / system procedures / process procedures / work instructions / forms) under formal document control.
    • Digitally controlled work instructions and routings in MES/ERP, often treated as QMS documents with formal review and approval workflows.
    • Integrated nonconformance, MRB and CAPA workflows with traceability to product, process, and root cause analysis records.
    • Formal configuration management and change control records for product and process changes, often managed in PLM or engineering systems.
    • Structured supplier management records (audits, scorecards, approvals) beyond what ISO 9001 alone would strictly require.

    Full replacement of legacy QMS/MES/ERP document repositories purely to “simplify” ISO 9001 documentation often fails in aerospace-grade environments because of validation costs, downtime risk, interface complexity, and long equipment and tooling lifecycles. Most organizations instead layer tighter document control and traceability on top of existing systems and phase changes in gradually under formal change control.

    Key dependencies and tradeoffs

    • Risk-based documentation level: ISO 9001:2015 expects you to determine the necessary level of documented information based on process risk, complexity, and competence levels. Highly manual, special, or safety-critical processes usually need more detailed documentation.
    • System coexistence: In brownfield environments, acceptable evidence is often distributed: an NC in the QMS, a routing in MES, calibration in a gage system, training records in an LMS. This is compatible with ISO 9001 as long as records are controlled and retrievable.
    • Traceability and auditability: The practical question in audits is less “Do you have document X?” and more “Can you show clear, controlled evidence that process Y is defined and consistently executed, and that you can trace from nonconformance or complaint back to relevant records?”

    In summary, ISO 9001:2015 mandates a focused but not exhaustive set of documents and records. Regulated manufacturers typically maintain a much richer documentation set and supporting systems to manage risk, customer expectations, and sector-specific standards, while balancing integration burden and change-control realities.