Connect981 – Content Dev

RSC Topic: Capability Assessment and Gap Analysis

  • What evidence do IA9101 auditors focus on when volume increases?

    How IA9101 auditors view volume increases

    When production volume rises, IA9101 auditors do not treat it as a routine change; they look for objective evidence that the QMS remains effective under higher load. They typically probe how demand changes were recognized, assessed, and translated into controlled actions, rather than accepting verbal assurances. In regulated aerospace environments, they pay particular attention to whether higher volume has driven shortcuts, undocumented workarounds, or reduced rigor in process controls. Evidence needs to show that you planned for the increase, implemented changes under control, and then verified that performance and risk remained acceptable. If volume went up suddenly or due to a customer mandate, auditors will expect you to show how you coped without losing traceability or configuration control.

    Planning, risk assessment, and change control evidence

    Auditors usually start by looking for documented planning and risk assessment related to the volume increase. That can include capacity analyses, risk registers, FMEAs, or other structured assessments identifying where higher throughput might increase defect risk, missed inspections, or schedule pressure. They will then look for evidence that identified risks led to controlled actions, like updated work instructions, additional inspection steps, automation, or revised sampling plans. Change control records are key: engineering change orders, process change requests, and approvals that explicitly mention the volume change or resulting modifications. In brownfield plants with legacy systems, auditors accept partially electronic and partially paper-based evidence, but they will scrutinize gaps and handoffs where risk can be lost between systems.

    Capacity, resourcing, and competence under higher throughput

    A common focus area is whether you have sufficient and competent resources to run at higher volume without erosion of quality. Auditors look for staffing plans, overtime policies, and evidence that staffing changes were risk-assessed rather than ad hoc reactions. Training and qualification records become more important when you add shifts, use temporary staff, or reassign experienced personnel to bottlenecks. They will examine whether competence matrices, certifications, and on-the-job training records were updated before people performed new or additional tasks. If your training and HR systems are fragmented, you should expect auditors to test traceability across them, especially for special processes, key characteristics, or inspection roles.

    Process control, inspection, and reaction plans under load

    IA9101 auditors will test that process controls still work when you are running near capacity limits. They look for updated control plans, inspection and test plans, and work instructions that reflect any changes to cycle times, batch sizes, or tooling. They may compare planned control frequencies with actual execution data in MES, LIMS, or paper records, checking for skipped or delayed inspections under schedule pressure. Evidence of defined reaction plans becomes more critical: what happens when a control point fails, and is that reaction practical at higher volume. Auditors often sample nonconformity records to see whether operators actually follow documented escalation paths when throughput and WIP are high.

    Performance trend data, KPIs, and control charts

    When volume increases, auditors expect to see not just point evidence, but trends that show you are monitoring QMS effectiveness. They will typically ask for yield, defect rate, scrap, rework, on-time delivery, and customer complaint trends across the period where volume increased. Control charts, run charts, and process capability analyses are strong evidence if they clearly show performance before and after the volume change. If metrics degraded, auditors will look for documented analysis, containment, and corrective actions, not just awareness. In brownfield environments, data may come from multiple systems; auditors will probe how you reconcile and validate these sources, especially if management dashboards are manually compiled. Inconsistent or unexplained shifts in KPIs during the ramp-up are usually explored in more depth.

    Nonconformities, escapes, and corrective action discipline

    Volume increases typically stress containment and corrective action systems, so IA9101 auditors pay close attention to nonconformance and escape history in the ramp period. They will sample internal nonconformance reports, deviation permits, customer complaints, and concession data to see whether issue rates changed with higher throughput. What matters is not zero defects, but clear, timely containment, root cause analysis, and implemented corrective actions with verified effectiveness. Auditors may check that corrective actions considered volume as a contributing factor (e.g., staffing, training, capacity, supplier performance), rather than blaming operators. In regulated aerospace environments, they will be particularly sensitive to how you manage escapes, notification to customers, and long-term corrective actions when production pressure is high.

    Configuration control, traceability, and document management

    Higher volume multiplies the consequences of weak configuration control, so auditors focus on how you maintain traceability at scale. They often test part-level and batch-level traceability for components, special processes, and key characteristics across higher WIP levels. Evidence includes DHRs, travelers, routing records, and electronic histories in MES or ERP, with attention to how rework and deviations are captured. Document control evidence—such as timely release of updated drawings, specifications, and work instructions—is critical when multiple shifts or sites are ramping simultaneously. In brownfield environments, where paper travelers coexist with digital systems, auditors usually drill into any manual transcriptions or later data entry, because high volume amplifies transcription errors and lost records.

    Supplier capacity, incoming quality, and logistics controls

    Volume increases often depend on suppliers, so IA9101 auditors will test how you assessed and controlled supplier readiness. Evidence may include supplier capacity assessments, revised quality agreements, increased incoming inspection, or additional audits at key suppliers. They will look at incoming inspection results and supplier performance metrics before and after the ramp to see whether increased demand drove more nonconformities or delays. If you changed suppliers, added alternates, or increased use of brokers to meet demand, auditors will expect documented risk assessments and approvals. Logistics evidence—such as changes in packaging, transport, and storage practices—also comes under scrutiny, particularly if cycle times or stock levels changed significantly.

    Why “volume alone” is not the main audit object

    IA9101 auditors are not auditing the fact that volume increased; they are auditing whether your QMS stayed effective while it happened. They do not certify that your ramp-up is safe or compliant; they assess whether your documented processes, controls, and records show this in a credible way. In aerospace-grade, regulated environments, volume ramps are often entangled with legacy systems, long-qualified processes, and limited windows for changes, which makes full process redesigns risky. Auditors generally expect incremental adaptations with strong change control and validation, not wholesale replacements of systems during a ramp. If you claim that nothing in your QMS changed despite a significant volume increase, that typically triggers more probing, because it suggests the risks were not realistically assessed or recorded.

  • Can MES data be used in discussions with aerospace OEM customers?

    Short answer and key constraints

    Yes, MES data can be used in discussions with aerospace OEM customers, but it must be treated as controlled, contextualized evidence rather than casual operational metrics. In regulated aerospace environments, MES is usually one piece of the manufacturing and quality record set, not the sole source of truth. OEMs will expect consistency between MES outputs and formally controlled records such as batch travelers, inspection reports, First Article Inspection (FAI) packages, and deviation / concession records. If your MES configuration, validation status, and data governance are weak, using it directly in customer discussions can create exposure. The practical approach is to define which MES data is “customer‑safe,” how it is derived, and how it traces back to your approved, audited processes.

    What OEMs typically care about vs. what MES actually holds

    Aerospace OEM customers usually care about proof of conformity, process capability, traceability, and stability over time. MES commonly holds routing execution data, work center timestamps, operator IDs, some measurement results, and nonconformance records, but the level of completeness and control varies widely by plant and vendor. Many MES deployments were originally set up for scheduling and WIP visibility, not for being a legally defensible quality record. This gap means that raw MES screens or exports, taken out of context, may not meet OEM expectations for rigor or repeatability. When MES is tightly integrated with QMS, PLM, and calibration systems and validated as part of the quality record flow, it can support OEM discussions more directly; when it is not, it should be treated as supporting evidence only.

    Using MES data as supporting evidence, not the primary record

    In most brownfield aerospace environments, MES data should support rather than replace your official quality documentation in customer interactions. You can use MES histories to explain cycle times, queue bottlenecks, or defect patterns that drive a corrective action or improvement plan. You can also use it to show trends in scrap, rework, or process adherence that are behind your CAPA response. However, when the OEM asks for proof of product conformity or for records linked to a specific serial or lot number, those should come from the authoritative system of record, which may be a QMS, ERP, or document-controlled route card rather than MES alone. Aligning MES extracts with those primary records before sharing avoids contradictions that undermine credibility.

    Data integrity, validation, and explainability concerns

    Before using MES data in OEM discussions, you need to be clear on how reliable and explainable that data actually is. If your MES was never formally validated for quality‑critical functions, you must be explicit internally that it is being used as an analytical tool, not as a certified quality record. Missing scans, backdated timestamps, operator workarounds, and legacy integration issues can all introduce gaps or anomalies that an OEM might question. If you cannot explain clearly how a given metric is calculated, what data sources feed it, and what time horizon and population it covers, you should not rely on that metric in a customer negotiation or corrective action response. Having an internal review step, where quality and manufacturing engineering check any MES‑based analysis, reduces the risk of being challenged by the OEM on data quality.

    Scope, filtering, and avoiding over‑disclosure

    Sharing MES data with OEMs requires careful scoping to avoid exposing irrelevant, misleading, or commercially sensitive information. Raw event logs, operator notes, or machine‑level diagnostics may contain noise or internal issues that are not material to the OEM’s concern but can trigger unnecessary questions. A better pattern is to extract only the data set needed to answer the specific question (for example, defect rate trends for a given feature or work center, or on‑time completion for a defined routing) and then aggregate or anonymize where appropriate. You should also avoid committing to live MES dashboards as a customer deliverable unless you are prepared to maintain that view long‑term, keep it validated, and manage the change control burden associated with any configuration updates.

    Alignment with QMS, CAPA, and formal customer responses

    When MES data informs a response to an OEM finding, audit, or escape, it needs to be tightly aligned with your QMS and CAPA records. MES can help identify root causes by correlating defects with shifts, tools, programs, or specific operations, but the conclusions must be documented in your controlled problem‑solving templates and corrective action reports. If the OEM asks for evidence of effectiveness of your corrective action, MES trends can be a powerful way to show reduction in recurrence or improved process adherence over time. However, any charts or extracts sent to the customer should be version‑controlled, traceable to a specific data pull, and reproducible later if challenged. Ad‑hoc, manually massaged spreadsheets derived from MES are particularly risky unless their derivation is documented and peer‑reviewed.

    Brownfield realities and system coexistence

    In most aerospace plants, MES coexists with older ERP, PLM, paper travelers, and standalone test and inspection systems. This coexistence means no single system cleanly represents the full product and process history for all part families. Some operations may be fully captured in MES, while others remain on legacy or manual records, leading to patchy visibility if you rely on MES alone. Integration gaps—such as incomplete mapping of serial numbers, tools, or NC programs between systems—can cause inconsistencies when you try to present a unified story to an OEM. Because full replacement of legacy systems is often impractical due to validation effort, downtime risk, and qualification impact, the pragmatic approach is to clearly define which systems are authoritative for which data types and to cross‑check MES outputs against those before discussing them with the customer.

    Practical governance for using MES data with OEMs

    If you plan to use MES data routinely in OEM discussions, it is worth defining a simple governance model. This can include a short list of approved KPIs and views that are allowed to be shared, with documented calculation logic and owners. Establish a standard internal review path (for example, manufacturing engineering plus quality) for any MES‑derived analysis that will be sent outside the company. Make sure change control procedures cover any MES configuration updates that could alter reported metrics or data structures visible to customers. Finally, train the people who speak to OEMs so they know what MES can reliably show, what its limitations are in your specific plant, and how to respond transparently when a question reaches beyond what the system can currently support.

  • What if a plant cannot yet support a required global KPI definition?

    If a plant cannot yet support a required global KPI definition, the answer is not to pretend that it can.

    A KPI should only be reported as globally comparable when the plant can produce it from the required source data, business rules, and calculation logic with enough consistency to make cross-site comparison credible. If those conditions are not met, the metric should be flagged as not yet conformant to the global definition.

    In practice, most organizations use a staged approach:

    • Document the exact gap. Is the issue missing source data, different event definitions, manual workarounds, poor timestamp quality, weak master data, or incomplete integration between MES, ERP, QMS, historian, or spreadsheets?

    • Classify the plant’s reporting status. For example: fully aligned, partially aligned, proxy only, or not reportable.

    • If the business still needs visibility, allow a controlled local proxy metric, but label it clearly as non-standard and not directly comparable to the global KPI.

    • Put the definition, mapping logic, owners, assumptions, and exceptions under change control.

    • Create a remediation plan with data, process, and system actions required to reach the global definition.

    This is usually a governance problem as much as a technical one. A plant may be operationally capable but still unable to support a KPI because event capture is inconsistent, production states are interpreted differently, scrap is booked late, rework is handled outside the system, or quality dispositions sit in separate workflows. In regulated environments, those differences matter because traceability and evidence quality matter.

    What not to do

    • Do not force local teams to backfill numbers into a global template without documenting method and limitations.

    • Do not merge proxy values with standard values and present them as one clean benchmark set.

    • Do not treat dashboard adoption as proof that the KPI is valid.

    • Do not launch a full system replacement just to satisfy one KPI unless the broader qualification, validation, downtime, and integration case is actually justified.

    That last point matters in brownfield plants. Full replacement strategies often fail because the real problem is not one application but years of local process variation, legacy interfaces, qualification constraints, and long equipment lifecycles. Replacing MES, ERP, QMS, or plant data collection to standardize one metric can create more risk than value if the plant cannot absorb the change.

    What a defensible interim state looks like

    A defensible interim state is usually possible if the organization is explicit about limitations. That typically includes:

    • a published global KPI definition and calculation rule

    • a site-by-site mapping of which inputs are available and trusted

    • a marked local proxy where the standard KPI is not yet achievable

    • metadata showing source systems, refresh timing, and manual intervention points

    • review and approval of the interim method by the responsible business and data owners

    This does not make the proxy equivalent to the global KPI. It only makes the limitation visible and controlled.

    Tradeoffs

    The tradeoff is straightforward. If you wait for perfect standardization, leadership may lack needed visibility for too long. If you standardize too aggressively on weak data, you get false comparability and bad decisions. Most organizations need a middle path: partial harmonization now, with explicit confidence levels and a roadmap to full alignment.

    Whether that works depends on process maturity, data readiness, integration quality, and the discipline to maintain a business glossary and canonical logic over time. Without that, the same KPI name can hide different operational realities across plants.

  • CSF Profile

    A CSF Profile is a structured description of how an organization implements the NIST Cybersecurity Framework (CSF) across its current or desired (target) state. In industrial and manufacturing environments, it is used to map cybersecurity practices and controls to the NIST CSF functions, categories, and subcategories for OT and IT systems.

    A CSF Profile typically aligns specific policies, technologies, and procedures to the framework, then compares the current profile to a target profile. This helps organizations identify cybersecurity gaps for production networks, MES/ERP integrations, data flows with suppliers, and other critical manufacturing systems.

    Key elements of a CSF Profile

    • Scope definition: Clarifies which assets and processes are covered, such as shop-floor OT, plant networks, remote access, and cloud-connected systems.
    • Current profile: Documents how the organization currently addresses each relevant NIST CSF subcategory (for example, access control, incident response, data protection).
    • Target profile: Describes the desired level of implementation for those same subcategories, based on risk, regulatory expectations, and business priorities.
    • Gap analysis: Compares current and target states to highlight missing or partially implemented practices.
    • Prioritized actions: Translates gaps into a sequenced list of improvements, often feeding into cybersecurity roadmaps or capital plans.

    Use in industrial and regulated manufacturing

    In regulated manufacturing, a CSF Profile is commonly used to:

    • Structure cybersecurity activities for compliance with broader requirements such as NIST SP 800-171, CMMC, or contract clauses.
    • Coordinate cybersecurity responsibilities between IT and OT teams around MES, SCADA, PLCs, and plant network segments.
    • Align cybersecurity controls with traceability, quality systems, and audit evidence for customers and regulators.
    • Communicate cybersecurity posture and planned improvements to leadership and external partners.

    Common confusion

    • CSF Profile vs. NIST CSF itself: The NIST Cybersecurity Framework is the overarching reference model. A CSF Profile is an organization-specific application of that model to describe current and target cybersecurity practices.
    • CSF Profile vs. compliance checklist: A CSF Profile structures information about cybersecurity implementation, but it is not itself proof of compliance or certification. It can, however, support evidence gathering and audit readiness.
    • CSF Profile vs. risk assessment: A risk assessment identifies threats and evaluates risk. A CSF Profile organizes how controls address those risks within the NIST CSF structure; the two are often used together.

    Operational context

    On the plant floor, the outcomes of a CSF Profile may show up as concrete actions such as segmenting OT networks, tightening access to MES terminals, standardizing secure remote maintenance, or formalizing incident response procedures that involve both IT and production teams. The profile itself serves as a high-level map linking these actions to the framework and to documented policies and controls.

  • What roles should participate in RCA for critical safety-of-flight nonconformances?

    For critical safety-of-flight nonconformances, root cause analysis should be cross-functional from the start. Quality typically facilitates, but quality alone is not enough. At minimum, you usually need the people who understand the requirement, the process that produced the condition, the evidence trail, and the authority to contain risk and approve corrective action.

    Core participants

    In most regulated aerospace and similar environments, the core RCA team should include these roles:

    In practice, this connects to data integrity, version control and audit when teams need to turn the answer into repeatable execution habits.

    • Quality engineering or quality management: owns the NCR workflow, evidence discipline, containment tracking, and linkage to CAPA or equivalent corrective action processes.
    • Responsible design or product engineering: confirms the requirement, characteristic criticality, functional impact, and whether the issue is design interpretation, tolerance stack-up, process capability, or execution failure.
    • Manufacturing or process engineering: analyzes routing, work instructions, tooling, fixtures, machine parameters, process controls, and recent changes.
    • Production supervision and the operator or inspector closest to the event: provides factual sequence-of-events detail that is often missing from formal records. Excluding frontline knowledge is a common RCA failure mode.
    • MRB authority or equivalent disposition authority: separates immediate disposition decisions from long-term corrective action and keeps the investigation grounded in product risk.
    • Program or business leadership for major events: ensures resourcing, customer communication paths, schedule impact management, and escalation discipline where the issue affects delivered or deliverable hardware.

    Roles that are often required depending on the case

    Critical safety-of-flight events usually pull in additional functions. Whether they are mandatory depends on your product, customer contract, internal procedures, and where the failure originated.

    • Supplier quality and supplier engineering if the nonconformance originated in purchased material, special processing, calibration services, or outside processing. If the supplier owns part of the cause chain, they need to participate directly, not just receive a corrective action request.
    • Special process engineering for heat treat, coating, bonding, welding, NDT, plating, composites, sterilization, or other tightly controlled processes where certification and parameter history matter.
    • Metrology, test, or labs when measurement method, fixture bias, software revision, environmental conditions, or test setup may have contributed. Many RCAs go wrong because they assume the detection method is valid without checking MSA, calibration status, or setup repeatability.
    • Configuration management or document control if there is any chance the event is tied to drawing revision mismatch, obsolete work instructions, uncontrolled local copies, or incorrect model-based definition release.
    • Maintenance, controls, or equipment engineering if machine condition, preventive maintenance gaps, alarms, overrides, sensor drift, or PLC or HMI changes may be involved.
    • PLM, MES, ERP, or QMS system owners when the event may involve bad master data, routing mismatch, serialization gaps, missing as-built records, or interface failures between systems. In brownfield plants, these are common contributors and often missed.
    • Training or competency owners when qualification, certification, or recency of training is in question.
    • Materials, planning, or receiving quality where lot mix, substitution, shelf-life, handling, storage, or traceability breaks may be causal.

    Who should lead?

    Usually, quality leads the investigation process, but the technical lead should match the dominant cause path. If the likely cause is process control, manufacturing engineering may drive the technical analysis. If the likely cause is requirement interpretation or design intent, engineering may need to lead that portion. What matters is that one role owns coordination and evidence control, while technical ownership sits with the people competent to test the actual failure theory.

    That distinction matters. A lot of weak RCAs are really documentation exercises run by whoever owns the form.

    Who should not be left out

    Three omissions are especially risky for safety-of-flight cases:

    • The person who knows the real shop-floor sequence. Formal travelers and system timestamps rarely capture workarounds, interruptions, re-clamping, tool swaps, or local decisions.
    • The requirement owner. Teams sometimes investigate process variation before confirming the requirement, characteristic classification, and functional effect.
    • The system or data owner when records conflict. If MES, ERP, PLM, QMS, calibration, and maintenance data do not agree, the RCA can be built on the wrong chronology.

    Boundaries and controls for critical cases

    For critical safety-of-flight nonconformances, the RCA team is only one part of the response. You also typically need explicit controls around containment, segregation, traceability review, shipped product impact assessment, and change control for any corrective action. If the proposed fix touches validated workflows, qualified equipment, approved process parameters, or controlled documentation, implementation will usually require formal review and may take longer than the urgency of the event would suggest.

    That is normal in regulated environments. Fast action without controlled evidence and change discipline often creates a second problem.

    Practical rule

    If a role can answer one of these questions, it probably belongs in the RCA:

    • What requirement was actually violated?
    • How could the process physically create this condition?
    • Can the detection method itself be trusted?
    • What else, by serial, lot, process window, or supplier batch, may be affected?
    • What system, document, or equipment changes happened near the event?
    • Who has authority to contain risk and approve the corrective path?

    For most critical safety-of-flight events, that means a small core team plus targeted subject-matter experts, not a giant meeting. Too few roles misses causes. Too many turns RCA into a status review.

  • Gap Assessment

    A gap assessment is a structured review used to compare the current state of processes, systems, controls, or documentation against defined requirements or target conditions. In industrial and regulated manufacturing environments, it commonly refers to evaluating operations against standards, regulations, internal policies, or reference models to identify where requirements are not fully met.

    What a gap assessment includes

    In practice, a gap assessment typically involves:

    • Clarifying the reference requirements or targets, such as regulations, standards, corporate procedures, or system specifications
    • Documenting the current state of processes, technologies, organizational roles, and records
    • Comparing current practices and controls to each requirement or expectation
    • Identifying gaps, partial compliance, and unclear or conflicting practices
    • Summarizing findings in a structured way, often with risk, impact, and priority indicators

    In manufacturing, gap assessments are often applied to areas such as:

    • Manufacturing execution systems (MES) capabilities versus ISA-95 style functional models
    • Quality management processes versus internal quality system procedures
    • Data integrity and electronic records practices versus regulatory expectations
    • Cybersecurity controls in OT environments versus a chosen security framework
    • Document control and change control practices versus policy requirements

    Operational meaning in manufacturing environments

    Operationally, a gap assessment provides a structured list of where current operations or systems do not align with required or desired practices. The output is usually:

    • A set of documented gaps, each linked to a specific requirement or expectation
    • Evidence or observations that support each identified gap
    • High-level recommendations or considerations for remediation, often used as input to a remediation plan or roadmap

    Gap assessments are descriptive rather than prescriptive. They describe where misalignments exist but do not, by themselves, implement changes or guarantee any specific compliance or certification outcome.

    What a gap assessment is not

    A gap assessment is not the same as:

    • An implementation project or remediation program. It precedes and informs those activities.
    • A full formal audit in the regulatory or certification sense, although the methods and documentation can be similar.
    • A root cause analysis. It may highlight where requirements are not met without determining the underlying causes.

    Common confusion

    Gap assessment vs. gap analysis: In many organizations the terms are used interchangeably to describe the comparison of current state to a target. Some practitioners use “assessment” to emphasize a structured, documented review and “analysis” for the deeper examination of causes and options, but this distinction is not universal.

    Gap assessment vs. risk assessment: A gap assessment focuses on alignment to defined requirements or targets. A risk assessment focuses on identifying and evaluating risks, which may include but are not limited to compliance gaps. Gap assessment results often feed into risk assessment activities.

    Use in regulated and integrated manufacturing systems

    In regulated manufacturing and integrated OT/IT environments, gap assessments frequently address:

    • MES and ERP integration practices versus defined data integrity, traceability, or interoperability requirements
    • Quality system processes (for example, CAPA, change control, batch record management) versus internal or external expectations
    • Audit readiness, especially identifying missing or incomplete evidence needed to demonstrate adherence to procedures
    • Cybersecurity controls on shop floor assets relative to a chosen security baseline for industrial control systems

    The output of these assessments is often used to prioritize system enhancements, process redesign, documentation updates, training, and governance changes.

  • Maturity assessment

    A maturity assessment is a structured evaluation of how developed, repeatable, controlled, and measurable a process, system, function, or organizational capability is. In manufacturing and regulated operations, it commonly refers to reviewing current practices against a defined set of maturity levels, criteria, or capabilities rather than checking whether a single requirement is simply met or not met.

    The term usually includes an appraisal of process definition, execution consistency, governance, data quality, roles, documentation, integration, and performance monitoring. It can be applied to areas such as quality management, MES usage, digital work instructions, cybersecurity, maintenance, supplier management, or ERP and shop floor integration.

    A maturity assessment is not the same as a certification, formal audit result, or pass/fail compliance determination. It is generally a diagnostic tool used to describe the current state and identify gaps between ad hoc practice and more standardized or optimized operation.

    How it is used in operations

    In practice, a maturity assessment often looks at whether work is informal or documented, whether execution varies by shift or site, whether records are complete and traceable, and whether systems are integrated or reliant on manual workarounds. Results are commonly summarized by capability area and maturity level, with examples of observed strengths, weaknesses, or dependencies.

    • Example: assessing whether nonconformance handling is paper-based, partially digital, or fully integrated with quality records and corrective action workflows.
    • Example: assessing whether production instructions are tribal knowledge, controlled documents, or role-based digital work instructions tied to execution data.

    Common confusion

    Maturity assessment vs. audit: An audit compares evidence against specific requirements or internal procedures. A maturity assessment compares current capability against a progression model or operating-state framework.

    Maturity assessment vs. gap assessment: A gap assessment focuses on what is missing relative to a target state or requirement set. A maturity assessment usually goes further by characterizing the degree of development across multiple levels.

    Maturity assessment vs. KPI review: KPI review looks at performance results. A maturity assessment looks at the underlying management system, practices, controls, and consistency that shape those results.

    What it typically includes and excludes

    It typically includes interviews, document review, workflow observation, scoring criteria, and comparison across functions, sites, or capability domains.

    It does not necessarily include detailed system validation, legal interpretation, or an official finding of compliance status unless those activities are separately defined.