Connect981 – Content Dev

FAQ Tag: brownfield integration

  • How do multi-tier collaboration systems support supply chain risk management?

    They support supply chain risk management by making upstream dependencies, supplier commitments, disruptions, and quality signals more visible and actionable across multiple tiers of the supply base.

    In practice, a multi-tier collaboration system helps an organization move beyond direct supplier status and see where risk is forming deeper in the network. That can include lower-tier shortages, outsourced processing delays, part-specific quality issues, capacity constraints, document gaps, and changes that may affect delivery, traceability, or compliance evidence.

    In practice, this connects to supplier and supply chain coordination when teams need to turn the answer into repeatable execution habits.

    What they typically improve

    • Earlier detection of shortages and delays through milestone tracking, supplier acknowledgments, and exception alerts.

    • Better identification of single-source and lower-tier dependency risk, especially where a prime or Tier 1 has limited visibility into Tier 2 and Tier 3 constraints.

    • Faster response to supplier quality events by linking NCRs, concessions, corrective actions, and affected orders or lots.

    • More reliable escalation workflows when dates slip, capacity changes, certifications expire, or required documents are missing.

    • Improved coordination around outside processing, subcontract work, and serialized or lot-controlled material flows.

    • Stronger traceability of who committed to what, when the status changed, and what evidence was provided.

    What they do not do on their own

    They do not create supply resilience by themselves. If suppliers do not participate consistently, if part master data is weak, or if integrations are incomplete, the system can become another layer of status reporting with limited predictive value.

    They also do not replace core planning, execution, or quality systems. In most brownfield environments, the collaboration layer has to coexist with ERP for purchasing and planning, MES for execution status, PLM for product definition, and QMS for supplier quality workflows. If those handoffs are poorly mapped, risk signals become late, duplicated, or contradictory.

    How they help manage risk operationally

    The main contribution is not just visibility. It is controlled workflow around exceptions.

    • When a supplier misses a milestone, the system can trigger review, reschedule analysis, or alternate sourcing checks.

    • When a lower-tier processor reports a delay, planners can assess impact before the top-tier shipment fails.

    • When a document, cert, or inspection record is missing, the issue can be routed before receipt or release is blocked.

    • When a quality event affects a lot, the system can help identify exposed orders, WIP, or downstream assemblies.

    That said, the effectiveness of these workflows depends on governance. Alert overload, unclear ownership, and inconsistent supplier onboarding are common failure modes.

    Key dependencies and tradeoffs

    • Supplier adoption: Multi-tier visibility is only as good as participation from suppliers and processors. Many lower-tier firms have limited digital maturity.

    • Data readiness: Part numbers, revisions, supplier identifiers, order references, and event definitions need enough consistency to support reliable matching.

    • Integration quality: The collaboration system must exchange data cleanly with ERP, MES, PLM, QMS, and sometimes logistics systems.

    • Change control: In regulated environments, workflow changes, evidence requirements, and status definitions often need validation and disciplined rollout.

    • Depth versus adoption: Very detailed workflows may improve control, but they can also reduce supplier participation if the process becomes burdensome.

    • Speed versus assurance: Rapid updates are useful, but if data is not governed, faster reporting can simply spread bad information sooner.

    Why replacement is usually the wrong approach

    For most regulated manufacturers, a multi-tier collaboration system should be treated as an interoperability and orchestration layer, not a reason to rip out existing enterprise systems. Full replacement strategies often fail because qualification burden, validation cost, downtime risk, long equipment lifecycles, and integration complexity are too high. The safer path is usually phased coexistence with clear system-of-record boundaries and traceable workflow handoffs.

    So the short answer is yes, these systems can materially improve supply chain risk management, but only when they are connected to real operational workflows, supported by usable supplier participation, and integrated into the existing system landscape with strong data discipline.

  • How long must we retain digital work instruction records in aerospace MRO?

    There is no single, universal retention period for digital work instruction records in aerospace MRO. The required retention time depends on a mix of contract, regulatory, customer, and local legal requirements, and on what exactly you mean by “digital work instruction records.”

    Separate two things: the instruction vs. the execution record

    In aerospace MRO, you typically have at least two distinct digital artifacts:

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

    • The work instruction content: the controlled document or task card itself (e.g., OEM/AMM task, operator instructions, digital task card definition).
    • The execution / maintenance record: evidence that the work was performed, by whom, when, and using which revision of the instruction (sign-offs, e-signatures, timestamps, observations, NCR links, etc.).

    Retention obligations are usually driven by the execution / maintenance record and related configuration/traceability data, not by the work instruction content alone. However, you often need to retain the linked work instruction revision or be able to reconstruct it for traceability.

    Typical retention drivers in aerospace MRO

    Actual retention periods result from combining multiple drivers:

    • Contractual & OEM requirements
      Many OEMs and prime contractors specify record retention periods in contracts, repair station agreements, or quality clauses. It is common to see requirements such as “life of the aircraft/part plus X years,” “10 years minimum,” or specific durations for safety-critical components.
    • Regulatory requirements
      Civil aviation authorities (e.g., FAA, EASA, Transport Canada, CAA) require approved organizations (repair stations, Part 145, Part 21, CAMO, etc.) to retain maintenance and release-to-service records for specified minimum periods. These rules typically focus on maintenance records and airworthiness release records, not explicitly on internal work instruction content, but in practice you need enough information to demonstrate how the work was performed.
    • Customer & operator policies
      Airlines, defense operators, and lessors often impose stricter retention than regulators, driven by fleet life, leasing horizons, and potential incident investigations. For military work, additional defense and security requirements may apply.
    • Local law & liability
      Company law, product liability law, and limitation periods for civil claims vary by jurisdiction. Legal counsel may require retention long enough to defend against potential claims over the aircraft or component life.
    • Internal quality policy
      Your QMS (e.g., under AS9100) will include a documented policy for record retention. That policy must reflect the above drivers and be applied consistently, with clear justification.

    What most aerospace MROs actually do

    Practices vary, but in regulated aerospace maintenance you rarely see short retention periods. Common patterns include:

    • Maintenance / execution records (task completions, sign-offs, inspection results, deviations, concessions, etc.): retained for the life of the aircraft or component plus a defined margin (often 2–10 years), or a fixed minimum (often 10–30 years) when life is hard to define.
    • Work instruction revisions (internal task cards, digital work instructions, local work aids):
      • All superseded revisions that were ever used on released work are retained or reconstructable, to prove which instructions were in force when the work was done.
      • Retention duration is usually aligned with the associated maintenance records they support, not treated as a much shorter lifecycle.

    For long-lived platforms (commercial widebody, military, rotorcraft), multi-decade retention of critical maintenance records is common. Some organizations treat anything tied to airworthiness or configuration as effectively “indefinite” retention for practical purposes.

    Digital work instructions: specific considerations

    For digital work instructions and records, regulators and customers typically care about evidence rather than the specific technology. Key points:

    • Version control & traceability: You must be able to show which work instruction revision applied to a given job, and that it was approved. That normally means maintaining a historical archive or audit trail of revisions, not just the current version.
    • Linkage to maintenance records: Your MRO system, MES, or digital work instruction platform should capture the relationship between the work order / task and the instruction revision (e.g., a revision ID in the traveler or e-sign record).
    • Data integrity over decades: Retaining records for 10–30+ years requires planning for media obsolescence, database migrations, format readability, cybersecurity, and user access controls over technology generations.
    • Validation & audit trails: In a regulated environment, the system managing digital work instructions and e-signatures typically needs to be validated for intended use, with robust logs so you can demonstrate that instructions were controlled, not altered after the fact.

    Brownfield and coexistence with legacy systems

    In most aerospace MRO operations, digital work instructions coexist with legacy systems such as paper task cards, older MRO/MES systems, and multiple ERPs/QMS tools. Common realities:

    • Multiple record repositories: Some historical work may exist only in legacy systems or paper archives, while new work is executed digitally. Retention policy needs to cover all repositories consistently.
    • System replacement risk: Fully replacing legacy MRO or MES systems just to “clean up” retention often fails due to validation cost, downtime risk, data migration challenges, and qualification/approval impacts. Many organizations instead implement archive strategies that maintain access to legacy data while new work moves into modern platforms.
    • Controlled migrations: If you migrate digital work instructions or maintenance records, you must manage change control, data validation, and evidence that no records were lost or altered inappropriately.

    How to determine the right retention period for your site

    You should not rely on generic numbers without checking your specific context. A defensible approach usually includes:

    1. Map applicable requirements:
      • Regulatory rules for your approvals (e.g., FAA/EASA/other authority repair station or Part 145 requirements).
      • Contractual terms, OEM agreements, prime contractor quality clauses.
      • Customer/operator policies, especially for safety-critical or life-limited parts.
      • Local legal and liability considerations (with your legal team).
    2. Classify your records:
      • Differentiate maintenance execution records, configuration/traceability records, QMS records (NCR, CAPA, audits), and controlled document history (work instructions, procedures).
      • Assign retention rules per record class, with documented rationale.
    3. Align digital WI retention with maintenance records:
      • Ensure that the historical versions of digital work instructions remain available (or reconstructable) for as long as related maintenance records must be retained.
      • Document how you will maintain readability and integrity across system upgrades or replacements.
    4. Implement in systems & change control:
      • Configure retention and archival rules in your MRO/MES/EDMS/QMS systems.
      • Control any purge/archive processes through change control and periodic review.

    Bottom line

    There is no single mandated number that applies to all aerospace MRO organizations or jurisdictions. Many operators effectively retain digital work instruction history for as long as they retain the associated maintenance records, which often means 10–30+ years or life-of-aircraft/part plus a margin. The correct answer for your site must come from a documented retention policy based on your approvals, contracts, customers, and legal advice, and implemented consistently across both legacy and new digital systems.

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