Connect981 – Content Dev

FAQ Tag: change control

  • How do supplier scorecards relate to the approved supplier list in AS9100?

    They are related, but they are not the same thing.

    In an AS9100 quality management system, the approved supplier list (ASL) is the controlled record of suppliers your organization has determined are acceptable for specified scopes of supply or services. Supplier scorecards are one way to monitor and evaluate ongoing supplier performance. In other words, the scorecard is typically an input to supplier approval and re-evaluation, while the ASL is the formal output of that process.

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

    A supplier can be on the ASL without having a sophisticated scorecard, especially in smaller organizations or lower-volume categories, if the organization has another documented and effective method for evaluation and re-evaluation. Likewise, a supplier can have scorecard data and still remain only conditionally approved, limited by commodity, limited by program, or subject to additional controls. AS9100 does not require a specific scorecard format, threshold, or software tool.

    How they usually connect

    • Initial approval: Qualification evidence, risk review, certifications where relevant, capability assessments, trial orders, or first article results may be used before a supplier is placed on the ASL.

    • Ongoing monitoring: Scorecards often track on-time delivery, quality performance, escapes, responsiveness, corrective action closure, and other metrics defined by the organization.

    • Periodic re-evaluation: The organization reviews the evidence, including scorecard trends, and decides whether the supplier remains approved, becomes conditional, requires development, or should be removed for a given scope.

    • Controls and actions: Poor scorecard performance should trigger defined actions such as increased inspection, source inspection, CAPA, limited approval status, or sourcing restrictions, if that is what your procedure requires.

    The key point is traceability between the data you collect and the supplier status you assign. If scorecards exist but do not drive any documented review or decision-making, they add little control value.

    What AS9100 generally expects

    AS9100 is concerned with externally provided processes, products, and services being controlled using defined criteria. That usually means your organization should be able to show:

    • how suppliers are approved

    • how performance is monitored

    • how often re-evaluation occurs or what event triggers it

    • what thresholds or risk factors matter

    • who can change supplier status on the ASL

    • what records are retained as objective evidence

    A scorecard can support all of that, but it does not replace the need for a controlled supplier approval process.

    Common failure modes

    • No defined decision rule: Teams collect metrics, but no one knows what score requires escalation, conditional approval, or removal from the ASL.

    • Poor master data: Supplier names, sites, legal entities, and commodity scopes do not match across ERP, QMS, receiving, and procurement systems, so scorecard results are unreliable.

    • Scope ambiguity: A supplier may be acceptable for one process or part family but not another. A single yes or no ASL status can hide this.

    • Manual lag: Quality issues are known in NCR or receiving records, but the ASL is updated late, so buyers continue placing orders.

    • Metric distortion: A supplier meets delivery metrics by shipping partial quantities or low-risk work first, while quality performance deteriorates.

    • No change control: Supplier status changes happen by email or spreadsheet without review history, approval traceability, or effective dates.

    These problems are common in brownfield environments because supplier data and performance signals often live across ERP, QMS, supplier portals, spreadsheets, and email. If those systems are not aligned, scorecards can look precise while the ASL process remains weak.

    Brownfield system reality

    In many regulated plants, the ASL is maintained in one system, purchasing transacts in ERP, supplier NCRs sit in QMS, and delivery performance is calculated from receiving or planning data. That coexistence can work, but only if ownership, data mapping, and update timing are explicit.

    Trying to replace all supplier, quality, and ERP workflows at once is often a bad strategy in long-lifecycle regulated environments. The qualification burden, validation cost, downtime risk, and integration complexity are usually high, and the result can be weaker traceability during transition. A more practical approach is often to preserve the system of record for the ASL, connect scorecard inputs from adjacent systems, and put formal review and change control around status decisions.

    So the practical answer is: supplier scorecards should inform the approved supplier list, but your documented process must define exactly how. If that linkage is vague, manual, or inconsistent across systems, you should not assume the scorecard by itself demonstrates effective supplier control.

  • How many KPIs should be global versus local?

    There is no universal number, but the usual answer is: keep the global set small and the local set purposeful.

    For most regulated manufacturing environments, a practical pattern is 5 to 12 global KPIs that are defined consistently across sites, plus a larger set of local KPIs owned by plants, lines, cells, or functions. The exact split depends on process similarity, data quality, governance discipline, and whether sites are actually comparable.

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

    What should be global

    Global KPIs should be limited to measures that meet all of these tests:

    • Leadership needs them for cross-site decisions, not just reporting.
    • The definition can be controlled consistently across plants.
    • The underlying data is available with acceptable quality and timing.
    • The metric can survive normal differences in routing, product mix, batch size, maintenance strategy, and quality workflows.

    Typical candidates include a small set around delivery, quality, schedule adherence, inventory, capacity, or cost of poor quality, but only if the calculation logic is actually harmonized. If one site books rework inside standard routing and another books it as a separate event, the same KPI can mean different things.

    What should stay local

    Local KPIs should capture what operators, supervisors, engineering, and quality teams can actually act on day to day. These often include bottleneck-specific losses, queue time between process steps, first-pass behavior by product family, inspection backlog, tooling availability, training coverage, or specific sources of scrap and rework.

    These measures are often more useful operationally than enterprise dashboards because they reflect local constraints. A site building stable repeat assemblies does not need the same local metrics as a high-mix repair operation or a tightly constrained outside-processing flow.

    Why not standardize everything

    Because full standardization usually breaks on operating reality.

    In brownfield environments, plants often run mixed MES, ERP, QMS, historian, spreadsheet, and manual log processes. They may also differ in work definitions, shift calendars, routing granularity, labor booking, and nonconformance handling. Forcing one enterprise KPI model across all sites without fixing those differences usually creates three problems:

    • Metrics look comparable when they are not.
    • Sites spend time arguing definitions instead of improving performance.
    • Teams create shadow reporting outside controlled systems.

    That is why a layered model is usually safer than an all-global model.

    A practical operating model

    A common structure is:

    • Tier 1 global: a small enterprise scorecard used for portfolio decisions and executive review.
    • Tier 2 functional/global-local hybrid: common categories with limited local parameterization, such as quality loss, schedule attainment, or material availability.
    • Tier 3 local: plant, line, cell, or program KPIs tied to actual constraints and daily management.

    This approach preserves comparability where it matters while allowing sites to manage the process they actually run.

    What ratio is reasonable

    If you need a rule of thumb, many organizations are better off with roughly 20 to 30 percent global and 70 to 80 percent local by count. But do not treat that as a target. Some networks need fewer global KPIs because products and processes vary too much. Others can support more global KPIs if they have strong master data, common routing logic, disciplined change control, and validated system integration.

    The real question is not the count. It is whether each KPI has a clear owner, stable definition, trusted source, and a decision that depends on it.

    Common failure modes

    • Too many global KPIs, which turns review meetings into dashboard maintenance.
    • Global KPIs defined centrally but calculated differently in each plant.
    • Local KPIs with no link to business outcomes, which creates optimization in the wrong direction.
    • Metrics introduced before data readiness, causing manual workarounds and low trust.
    • Replacing existing reporting too aggressively, which is risky in validated or heavily controlled environments.

    That last point matters. Full replacement strategies often fail when legacy reporting is tied into qualified processes, audit evidence, or long-established operational routines. Coexistence is usually more realistic: stabilize a small canonical KPI layer first, map source systems carefully, validate calculations where required, and retire old reports gradually under change control.

    Bottom line

    Use as few global KPIs as you can govern well, and as many local KPIs as teams need to run the process responsibly. If a KPI cannot be defined consistently across sites, it should probably not be global.

  • Who should be on a manufacturing KPI governance council?

    A manufacturing KPI governance council should include the people who own the process, the people who generate or steward the data, and the people who will be held accountable for acting on the metric. If one of those groups is missing, KPI definitions usually drift, reporting becomes political, and local workarounds take over.

    In most plants, the council should include:

    In practice, this connects to ISO 22400 KPI governance when teams need to turn the answer into repeatable execution habits.

    • Operations leadership, because they own throughput, schedule adherence, labor utilization, and day-to-day response.
    • Quality leadership, because many KPIs depend on how scrap, rework, defects, holds, deviations, and escapes are classified.
    • Manufacturing engineering or industrial engineering, because routing structure, cycle assumptions, standard work, and process changes affect KPI meaning.
    • IT and data/integration owners, because KPI reliability depends on source-system logic, interfaces, master data, timestamp quality, and reporting architecture.
    • Finance, if the council governs cost, variance, inventory, or cost-of-poor-quality metrics.
    • Planning or supply chain, if KPIs include schedule attainment, shortage impact, WIP aging, supplier performance, or queue behavior.
    • Site or business-unit leadership, to resolve cross-functional conflicts and approve standards that local teams may resist.
    • System owners for MES, ERP, QMS, historians, or data platforms that feed the governed KPIs.

    If the council is enterprise-wide, add representation from each major plant type or value stream. A single centralized team often misses real differences between discrete assembly, machining, batch processing, test, and repair operations. At the same time, letting every site define KPIs independently usually destroys comparability. The council has to manage that tradeoff directly.

    Who should not be the whole council

    No single function should dominate the group. A KPI council made up only of executives tends to approve metrics that look clean in slides but are weak operationally. A council made up only of analysts or IT teams often produces technically consistent numbers that do not match how the floor actually runs. A council made up only of site operators may optimize for local practicality while losing enterprise consistency.

    It is also a mistake to confuse stakeholders with decision-makers. Not everyone who consumes dashboards needs a vote on metric definitions. Keep the voting group limited, then bring in subject matter experts as needed for specific metrics.

    Typical roles and responsibilities

    The council works best when membership is paired with explicit responsibility:

    • Chair or sponsor to set priorities and break deadlocks.
    • KPI owners for each governed metric, usually from the business function accountable for outcomes.
    • Data owners or stewards for source-system definitions, transformations, and lineage.
    • Validation or quality representatives where reporting changes affect controlled processes, evidence, or decision support in a regulated environment.
    • Change control participants to review proposed definition changes, effective dates, impact analysis, and communication plans.

    Without named ownership, councils often discuss KPI problems repeatedly without fixing the underlying data, workflow, or definition issue.

    How big should it be?

    Usually 6 to 10 core members is enough. Larger groups become review forums instead of governance bodies. If you need broad input, create a smaller decision council and a wider working group underneath it.

    The right size depends on scope. A single-site KPI council can be leaner. A multi-site council with MES, ERP, QMS, and PLM dependencies usually needs more structured representation because changes in one system can alter reporting logic elsewhere.

    Brownfield reality

    In a brownfield environment, council membership should reflect the systems that actually exist, not the architecture leadership wishes it had. If KPI data comes from a mix of legacy ERP, partial MES coverage, spreadsheets, machine data, and QMS records, the council needs members who understand those boundaries. Otherwise, it will approve definitions that cannot be implemented consistently.

    This is also why full replacement is rarely the first answer. Replacing every execution and reporting system to standardize KPIs sounds clean, but in regulated and long-lifecycle operations it often fails under qualification burden, validation effort, integration complexity, downtime risk, and the need to preserve traceability across old and new records. In practice, the council usually has to govern KPI semantics across coexistence, not assume a reset.

    What the council should decide

    A KPI governance council is not just a dashboard review committee. It should decide:

    • which KPIs are official and which are local working metrics
    • the precise business definition for each KPI
    • source systems of record and fallback rules
    • calculation logic, inclusion and exclusion criteria, and effective dates
    • how changes are approved, tested, documented, and communicated
    • where site variation is allowed and where it is not
    • how exceptions, data quality issues, and disputed numbers are escalated

    If the council is not empowered to make those decisions, membership matters less because governance is not actually happening.

    Practical rule of thumb

    If a function can change the meaning of the metric, the availability of the data, or the action taken based on the result, it should be represented directly or through a named owner. If it only consumes the report, it does not necessarily need a seat.

    So the short answer is: include business owners, data owners, system owners, and decision-makers. Keep the group cross-functional, accountable, and small enough to govern definitions under change control. The exact roster depends on your KPI scope, plant diversity, and system landscape.

  • How can we reduce inspector-to-inspector variation in repair limit calls?

    You reduce inspector-to-inspector variation by making the decision process more explicit, more observable, and more traceable. In practice, that means standardizing the repair criteria, the evidence used to make the call, and the escalation path for borderline conditions.

    If repair limit calls depend heavily on personal interpretation, tribal knowledge, or image quality from uncontrolled references, variation will persist even with experienced inspectors.

    In practice, this connects to non-conformance management when teams need to turn the answer into repeatable execution habits.

    What usually works

    • Tighten the decision standard. Use controlled acceptance and repair criteria with unambiguous thresholds, defect classes, and location-specific rules where needed. If the criteria allow broad interpretation, inspector variation is a predictable outcome.

    • Use approved visual exemplars. Boundary images, annotated defect libraries, and side-by-side examples of acceptable, repairable, and reject conditions help far more than text alone. These references need version control and change control, especially when engineering dispositions evolve.

    • Standardize measurement method. Variation is often a metrology problem disguised as a people problem. Define the exact inspection method, lighting, magnification, fixture, measurement points, and rounding rules. If different inspectors measure differently, they will call differently.

    • Run periodic calibration on judgments. Use blind comparison sets, adjudicated review sessions, and attribute agreement analysis or MSA approaches where applicable. The goal is to identify where interpretation diverges, then correct the standard or training, not just the inspector.

    • Create a formal escalation path for gray zones. Borderline calls should route to a defined authority such as engineering, MRB, or a designated senior reviewer based on your process. Without this, inspectors either overcall defects to stay safe or undercall to protect flow.

    • Capture rationale and evidence. Record the observed condition, measurements, images if allowed by process, applied criterion, and final decision. That traceability lets quality and engineering see patterns, retrain where needed, and update standards based on recurring ambiguity.

    • Close the loop with NCR, MRB, and repair outcome data. If repaired parts later fail downstream review, or if escalations repeatedly resolve the same way, that is evidence the decision rule needs refinement.

    Where variation usually comes from

    • Ambiguous repair limits or overlapping document sources

    • Different revisions in use across shifts, sites, or suppliers

    • Inconsistent lighting, magnification, fixturing, or measurement tools

    • Weak training transfer from experienced inspectors to newer staff

    • Local workarounds that never made it into controlled instructions

    • Pressure to protect throughput, avoid scrap, or avoid engineering review

    Digital support can help, but it does not remove the hard part

    Digital work instructions, defect libraries, guided inspection steps, and embedded escalation workflows can reduce variation materially. They are especially useful when repair calls require pulling information from multiple systems or documents.

    But the software only helps if the underlying criteria are already governed. Digitizing contradictory standards or poor images will just make inconsistency faster and easier to repeat. In regulated and long-lifecycle environments, validation effort, document control, and change control matter as much as user interface quality.

    Brownfield reality

    Most plants cannot replace inspection, QMS, MES, and engineering systems just to improve repair decisions. Full replacement is often a poor fit because of validation cost, downtime risk, integration complexity, qualification burden, and the need to preserve traceability across long asset lifecycles.

    A more realistic approach is to improve decision consistency within the existing stack: controlled criteria from engineering or PLM, execution guidance in MES or digital work instructions, nonconformance and disposition capture in QMS, and evidence retention tied back to the part or serial record. That approach is slower than a greenfield reset, but usually more credible and lower risk.

    Tradeoffs to expect

    • More precision can slow decisions. Tighter criteria and mandatory evidence capture often increase inspection time at first.

    • Escalation improves consistency but can create queues. You may need service levels or triage rules for engineering and MRB support.

    • Visual standards help, but they require upkeep. If exemplars are not refreshed as products, materials, coatings, or repair methods change, they become another source of error.

    • Analytics can find patterns, but only if data is structured. Free-text dispositions and inconsistent defect codes limit what you can learn.

    If you want a practical sequence, start with the highest-disagreement repair calls, define one controlled decision tree for those cases, standardize the measurement method, and review agreement rates before scaling further. That usually delivers more than broad retraining alone.

  • How do low-code workflow tools fit into existing aerospace IT landscapes?

    They fit best as a constrained layer for workflow orchestration, approvals, task routing, exception handling, and user-facing forms around existing systems. In most aerospace environments, low-code tools are more practical as a complement to MES, ERP, PLM, QMS, and document control platforms than as a replacement for them.

    For example, a low-code tool may be useful for routing nonconformance reviews, coordinating cross-functional approvals, collecting supplemental manufacturing or quality data, managing supplier interaction steps, or exposing a simpler interface to users while the system of record remains elsewhere.

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

    No, they are not usually a realistic path to replacing the core aerospace stack end to end. Full replacement strategies often fail in regulated, long lifecycle environments because the qualification burden is high, validation scope expands quickly, downtime risk is unacceptable, integrations are deeply embedded, and traceability and change control requirements do not disappear just because the front end is easier to configure.

    Where they usually fit well

    • Workflow coordination across systems that do not integrate cleanly today

    • Approval chains for NCR, MRB support steps, deviations, concessions, engineering review, or document-controlled process changes

    • Operator, supervisor, or supplier portals that simplify data entry without becoming the master record

    • Exception handling where ERP or MES covers the standard path but not the real-world edge cases

    • Temporary or transitional processes during phased modernization, provided ownership and retirement plans are clear

    Where they are a poor fit

    • Hard real-time machine control or safety-critical functions

    • Deep manufacturing execution logic with complex routing, genealogy, labor, materials, and equipment constraints

    • Authoritative product definition, configuration management, or long-term records without strong governance

    • Any use case where the tool becomes an uncontrolled shadow MES, shadow QMS, or shadow document system

    Main constraints

    The answer depends heavily on plant architecture, integration quality, data readiness, validation expectations, and security boundaries. A low-code platform may look fast in a demo and still create long-term risk if it sits on weak master data, duplicates records across systems, or bypasses established approval and release controls.

    Common failure modes include:

    • Workflow logic embedded in one app builder’s configuration with poor documentation

    • Duplicate part, routing, supplier, or quality data created outside governed systems

    • Broken evidence trails when approvals, attachments, and final records are split across multiple tools

    • Version drift between forms, work instructions, and ERP or PLM data

    • Citizen-developed apps that are difficult to validate, test, secure, or support over time

    • Integration debt when APIs, middleware, identity controls, and event handling are immature

    What good coexistence looks like

    In a brownfield aerospace landscape, the safer pattern is usually coexistence with clear system roles:

    • ERP remains the source for planning, purchasing, inventory, and financial transactions

    • MES remains the source for execution, routing, labor, materials, and production status where deployed

    • PLM remains the source for product definition and controlled engineering content

    • QMS remains the source for governed quality records and formal quality processes

    • The low-code layer handles orchestration, notifications, role-based work queues, and guided data collection

    That separation is not automatic. It has to be designed, documented, and enforced. If ownership boundaries are vague, the low-code layer tends to accumulate business logic and recordkeeping responsibilities that are hard to validate and harder to unwind later.

    Tradeoffs leadership should expect

    The tradeoff is speed versus control. Low-code tools can reduce cycle time for administrative workflows and make fragmented processes more usable. But the faster teams can build, the easier it is to create inconsistent workflows, weak auditability, and local apps that do not scale across plants or programs.

    There is also a tradeoff between flexibility and lifecycle stability. Aerospace programs often outlive software roadmaps, implementation teams, and even vendors. A workflow that is easy to configure today still needs test discipline, change control, role security, backup and recovery planning, and a support model that can survive personnel turnover.

    Practical evaluation criteria

    If you are assessing fit, focus less on how quickly forms can be built and more on whether the platform can support:

    • Traceable approvals and immutable evidence where required by process

    • Controlled releases, testing, and change management

    • Strong identity, access control, and segregation of duties

    • Reliable integration with ERP, MES, PLM, QMS, and document systems

    • Data ownership rules and master data discipline

    • Export control, cybersecurity, and hosting constraints where applicable

    • Long-term maintainability across programs, sites, and personnel changes

    So the practical answer is yes, low-code workflow tools can fit into aerospace IT landscapes, but usually as governed orchestration and user experience layers around existing systems of record. They add value when they reduce manual handoffs without weakening traceability, validation discipline, or system boundaries. They create risk when used to sidestep those controls.