Connect981 – Content Dev

FAQ Tag: canonical data model

  • What is the best way to collect KPI data from smaller suppliers?

    The best way is usually to use a tiered collection model: define a small, controlled KPI set centrally, allow simpler submission methods for smaller suppliers, and automate only where the supplier and data quality are mature enough.

    In practice, that means starting with a limited scorecard such as on-time delivery, quality escapes, response time, lead time adherence, and open corrective action aging, then documenting exactly how each KPI is calculated, what period it covers, what source data is expected, and who is accountable for submission and review.

    For smaller suppliers, a lightweight approach is often more reliable than forcing direct system integration too early. Many do not have modern MES, stable ERP master data, or staff available to maintain EDI, API, or portal workflows. If you push a high-friction model onto them, you often get late submissions, manual workarounds, inconsistent definitions, and numbers that cannot be traced back to source records.

    What usually works best

    • Use a standard template first. A controlled spreadsheet, secure web form, or supplier portal form is often the practical starting point.

    • Keep the KPI set narrow. Fewer metrics with consistent definitions are better than a large scorecard with weak comparability.

    • Require source references. Ask suppliers to provide shipment IDs, PO numbers, lot numbers, NCR references, or reporting period details so the KPI can be checked.

    • Separate reported KPIs from derived KPIs. If you can calculate a metric from your own receiving, quality, or scheduling data, do that rather than asking the supplier to report it independently.

    • Tier suppliers by capability. High-volume or strategic suppliers may justify API, EDI, or portal integration. Smaller suppliers may stay on governed manual submission for a long time.

    • Establish review and exception handling. A KPI process without data challenge, correction, and change control quickly loses credibility.

    Best collection methods by supplier maturity

    • Lowest maturity: controlled spreadsheet submission with locked fields, fixed definitions, due dates, and buyer review.

    • Medium maturity: supplier portal or web form with validation rules, required fields, and document attachment support.

    • Higher maturity: automated exchange from ERP, QMS, ASN, shipping, or quality systems through API, EDI, SFTP, or managed integration.

    There is no single best method across all suppliers. The right choice depends on supplier size, transaction volume, cybersecurity requirements, data quality, contract structure, and how much validation effort your team can sustain.

    What to avoid

    • Do not start with too many KPIs.

    • Do not assume the supplier calculates metrics the same way you do.

    • Do not treat portal entry as data integrity. A portal can still collect inconsistent or untraceable data.

    • Do not rely only on monthly summary numbers without supporting transaction references.

    • Do not launch full replacement expectations such as requiring small suppliers to adopt your preferred stack. In regulated, long-lifecycle environments, this often fails due to qualification burden, validation cost, integration complexity, and the downtime risk of changing established systems.

    Tradeoffs to expect

    Manual collection is faster to launch and easier for smaller suppliers, but it creates review overhead and weaker timeliness. Automated integration improves scale and consistency, but only if master data, event definitions, system mapping, and support ownership are already stable. A supplier portal can help with governance, but it does not remove the need for master data alignment, calculation rules, and exception handling.

    You also need to decide whether the goal is supplier reporting or supplier performance management. Those are not the same. Reporting collects numbers. Performance management requires common definitions, traceability to transactions, periodic reviews, and a way to challenge, correct, and version the data when disputes arise.

    Practical recommendation

    For most organizations, the best path is:

    1. Define 5 to 8 KPIs with strict calculation rules and reporting cadence.

    2. Map which KPIs can be calculated internally from ERP, receiving, quality, or scheduling data.

    3. Use a controlled manual template or portal form for the remaining supplier-provided metrics.

    4. Require traceable references for every reported value.

    5. Tier suppliers and automate only where volume, stability, and business risk justify it.

    6. Put the KPI definitions and submission process under change control.

    If the question is whether you should force all smaller suppliers into direct integration, the answer is usually no. A governed hybrid model is usually more durable in brownfield supply chains.

  • How do you normalize KPI data across ERP, MES, QMS, and supplier systems?

    You do not normalize KPI data by averaging reports from different systems or forcing one application to become the source of truth for everything. In most plants, normalization means creating a controlled KPI layer with explicit metric definitions, source mappings, transformation rules, and data quality checks across ERP, MES, QMS, and supplier systems.

    The practical approach is usually:

    1. Define each KPI unambiguously at the business level. Specify numerator, denominator, time basis, inclusion and exclusion rules, unit of measure, status logic, and system of record for each input.

    2. Create a canonical data model or semantic layer for shared entities such as part, work order, operation, lot, serial, supplier, nonconformance, receipt, and shipment.

    3. Map each source system into that model. ERP, MES, QMS, and supplier portals often represent the same event differently, at different times, and with different granularity.

    4. Standardize time and state logic. This includes timezone handling, shift calendars, late-arriving transactions, rework loops, partial completions, and supplier acknowledgements versus physical receipts.

    5. Resolve master data mismatches. Part numbers, revision rules, site codes, supplier IDs, routing steps, defect codes, and reason codes usually drift over time unless actively governed.

    6. Apply data quality controls and reconciliation checks. If ERP says a receipt posted, MES shows no consumption, and QMS has an open hold, the KPI layer should surface that conflict instead of hiding it.

    7. Version the KPI definitions and mappings under change control. In regulated environments, changing how a metric is calculated without traceability creates audit and management risk.

    What usually has to be normalized

    • Entity identity: part, supplier, work order, batch, lot, serial, operation, facility, line, and customer program identifiers

    • Event timing: planned date, actual completion, posting date, inspection date, supplier ship date, receipt date, and hold release date

    • Status models: released, in process, complete, on hold, rejected, reworked, scrapped, accepted with deviation

    • Units and quantity logic: each, lot, weight, standard hours, earned hours, yield basis, and conversion rules

    • Defect and quality coding: NCR categories, defect families, disposition codes, supplier fault attribution, and CAPA linkage

    • Context dimensions: product family, program, cell, shift, supplier tier, process step, and revision level

    Why this is difficult

    The main problem is not technical connectivity alone. It is semantic mismatch. Two systems can both expose an API and still disagree on what completed, late, first pass yield, on-time delivery, or cost of poor quality actually mean.

    For example, ERP may record supplier on-time delivery based on promised receipt date, while receiving logs the actual dock date, QMS excludes receipts placed on quality hold, and the supplier portal measures against acknowledged ship date. All four views may be internally consistent and still produce incompatible KPIs.

    Normalization also gets harder in brownfield environments because legacy MES, older ERP customizations, spreadsheet side systems, and supplier-specific data formats often carry years of local process exceptions. Replacing everything to standardize metrics is usually not realistic in regulated, long-lifecycle operations. The qualification burden, validation effort, downtime risk, integration complexity, and traceability impact are often too high. A governed coexistence model is usually safer.

    What architecture tends to work

    In practice, most organizations use a layered approach rather than trying to make one transactional system do all KPI logic:

    • Transactional systems continue to run execution: ERP, MES, QMS, supplier portal, sometimes PLM or EDI middleware.

    • An integration layer captures events and master data changes.

    • A canonical model or semantic layer standardizes business meaning.

    • A KPI calculation layer applies approved formulas and exception handling.

    • Dashboards consume governed outputs, not raw source fields.

    This preserves existing validated processes where needed while improving comparability across plants and functions. It also makes it easier to test changes to KPI logic before broad rollout.

    Key tradeoffs

    • Speed versus rigor: a quick dashboard can be built fast, but without governed definitions it will not stay trusted.

    • Central standardization versus local reality: one global definition may ignore plant-specific routing, outsource steps, or quality gates. Too much local variation, however, destroys comparability.

    • Real-time versus stable: near-real-time KPIs are useful operationally, but regulated reporting often needs cutoffs, reconciliations, and restatement rules.

    • Single source of truth versus federated truth: some data should remain mastered in source systems. Forcing central ownership of all fields often creates more drift, not less.

    • Completeness versus maintainability: trying to normalize every field from every system usually stalls the program. Start with a narrow KPI set tied to decisions.

    What to do first

    Start with a limited set of high-impact KPIs and document them in detail. Good candidates are metrics that already drive escalation, supplier management, quality review, or production recovery. Then:

    • assign a business owner for each KPI

    • document source systems and system-of-record rules

    • define reconciliation rules and acceptable variance thresholds

    • align master data stewardship across operations, quality, supply chain, and IT

    • test historical backfills against known plant events

    • put KPI definition changes under formal change control

    If the organization cannot agree on business definitions, the integration work will not solve the problem. It will only automate disagreement faster.

    No, there is not a universal normalization template that works unchanged across all plants, vendors, and supplier networks. The right model depends on process maturity, data readiness, code standardization, supplier integration depth, and how much local variation has accumulated over time.

  • Do we need formal governance processes to adopt ISO 22400 KPIs?

    Yes. In most cases, you need formal governance processes if you want ISO 22400 KPIs to be used consistently across shifts, lines, plants, and systems.

    The level of formality does not have to be heavy, but it does need to be explicit. ISO 22400 can help standardize KPI definitions and relationships, but it does not remove the need to govern how your organization maps those definitions to actual equipment signals, MES events, ERP transactions, manual entries, and reporting logic.

    Without governance, teams usually end up with the same KPI name producing different results in different places. That is especially common in brownfield environments where data comes from mixed vendors, legacy historians, MES, ERP, PLM, QMS, and spreadsheets.

    What governance is usually needed

    • Clear KPI ownership across operations, engineering, quality, and IT

    • Approved business definitions and calculation rules

    • Source-system mapping and data lineage

    • Version control for formulas, thresholds, and classifications

    • Change control for updates to equipment states, event models, integrations, and reports

    • Exception handling for missing data, late data, manual overrides, and reclassification

    • Validation of calculations before the KPI is used for management decisions or formal reporting

    In regulated environments, this matters because traceability of the metric definition is often as important as the metric value itself. If a KPI changes because of a software update, integration fix, machine retrofit, or revised event model, that change should be controlled and documented.

    What happens if you skip governance

    The main risk is not that the KPI dashboard fails technically. The bigger risk is that people stop trusting the numbers, or worse, act on numbers that are inconsistent or poorly defined.

    • Plants compare performance using different calculation logic

    • Local workarounds become the real KPI definition

    • Manual data corrections are not visible or auditable

    • MES and ERP timestamps do not align, creating false losses or false gains

    • Trend breaks appear after upgrades or integration changes

    • Quality and production teams optimize against different interpretations of the same KPI

    That does not mean you need a large governance committee before you start. It does mean you should not treat ISO 22400 adoption as only a reporting exercise.

    How formal is formal enough?

    That depends on your operational complexity, data maturity, and how the KPIs will be used.

    If the KPIs are used only for internal improvement on one line, governance can be fairly lightweight. If they will be used across plants, tied to performance reviews, escalations, customer reporting, or quality decisions, the governance model needs to be more formal.

    A practical minimum is usually:

    • A controlled KPI dictionary

    • Named owners for each KPI

    • Documented source-system mappings

    • A defined approval path for KPI changes

    • Periodic review when equipment, routing, integrations, or reporting logic changes

    If your data is incomplete, manually curated, or inconsistently timestamped, governance alone will not fix that. It only makes the limitations visible and manageable. KPI quality still depends on instrumentation, event modeling, integration quality, and disciplined operational use.

    Brownfield reality

    In brownfield plants, formal governance is usually more necessary, not less. Legacy systems often encode different assumptions about states, downtime, production counts, scrap, rework, and completion events. ISO 22400 can provide a useful reference model, but you still have to decide which system is authoritative for each data element and how conflicts are resolved.

    This is also why full replacement strategies often fail. Replacing MES, ERP, historians, or shop-floor interfaces just to standardize KPIs can create major qualification burden, validation cost, downtime risk, retraining effort, and integration rework. In long lifecycle regulated environments, coexistence with existing systems is usually the practical path, with governance acting as the control layer that keeps KPI meaning stable across that mixed landscape.

    Bottom line

    Yes, you should have formal governance processes to adopt ISO 22400 KPIs if you want the results to be reliable, comparable, and maintainable. The governance can be lightweight at first, but it should cover ownership, definitions, lineage, validation, and change control. Without that, ISO 22400 adoption often produces standardized KPI names without standardized KPI meaning.

  • Can we support both real-time and historical KPI views from the same calculation layer?

    Yes, in many cases you can support both real-time and historical KPI views from the same calculation layer, but not by treating them as identical workloads.

    The practical answer is that you need one governed KPI logic layer, with different execution patterns for live and historical use. Real-time views usually need low-latency calculations over incomplete, still-changing data. Historical views usually need stable, reconciled calculations over closed periods, corrected events, and approved master data. If you force both into a single processing pattern, accuracy or responsiveness usually suffers.

    What has to be true

    • The KPI definition has to be version-controlled and unambiguous.

    • You need clear handling for late-arriving events, duplicated events, missing tags, unit conversions, and timestamp quality.

    • You need rules for when a number is considered provisional versus finalized.

    • You need traceability back to source events, transactions, or production records.

    • You need a process for recalculation when routing, product structure, reason codes, or other master data changes.

    Without those controls, a shared calculation layer often produces one of the most common failure modes in manufacturing analytics: the live dashboard says one thing, month-end reporting says another, and no one trusts either.

    Why this is harder than it sounds

    Real-time KPI calculation and historical KPI calculation solve different problems.

    • Real-time views prioritize speed, operational usefulness, and tolerance for data that is not yet complete.

    • Historical views prioritize consistency, auditability, period closure, and reproducibility.

    That means the same KPI formula may be shared, while the surrounding logic is not. For example, a real-time OEE-style calculation may use current machine states and in-process counts, while the historical version may need reconciled production declarations, approved scrap dispositions, downtime reason normalization, and shift-close corrections.

    So the right pattern is usually a shared semantic layer or rules layer, not necessarily one identical runtime path or one physical data store.

    Common architecture pattern

    In practice, mature implementations often use:

    • One governed KPI definition layer

    • One streaming or near-real-time processing path for operational visibility

    • One batch or incremental reconciliation path for historical reporting

    • One traceable data model that preserves source lineage and calculation version

    That still counts as the same calculation layer if the business logic is centrally governed and consistently applied. It does not require one database, one refresh cadence, or one tool.

    Brownfield reality

    In brownfield environments, the answer depends heavily on integration quality. MES, SCADA, historians, ERP, QMS, manual production logs, and maintenance systems often disagree on timestamps, event granularity, asset hierarchies, and reason codes. A single KPI layer can sit above them, but only if you invest in mapping, normalization, and data quality controls.

    If those systems are poorly aligned, trying to replace them all just to get one KPI model is usually a high-risk strategy. Full replacement often fails in regulated, long-lifecycle environments because qualification effort, validation cost, downtime risk, interface rewiring, and traceability obligations are much larger than expected. A coexistence approach is usually more realistic: keep source systems in place, standardize KPI logic centrally, and phase improvements over time.

    Key tradeoffs

    • Speed versus stability: faster numbers are usually less final.

    • Uniformity versus source fidelity: heavy normalization improves comparability but can hide source-specific nuance.

    • Recalculation flexibility versus auditability: if historical KPIs can be recomputed freely, you need strict versioning and change control.

    • Centralization versus local plant reality: a global KPI model helps standardization, but local equipment models and workflows still matter.

    What to validate before committing

    • Whether the KPI can be computed from event data alone or requires contextual business data from ERP, MES, QMS, or maintenance systems

    • Whether source timestamps are trustworthy enough for real-time and historical alignment

    • Whether backfilled and corrected records trigger controlled recalculation

    • Whether users can see the calculation version, data freshness, and source lineage

    • Whether closed-period reporting is protected from uncontrolled logic changes

    So yes, you can support both from the same calculation layer, but only if that layer is governed as a controlled KPI logic service, not just a dashboard formula library. In regulated operations, the difference matters because trust depends less on visualization and more on traceability, reconciliation rules, and change discipline.

  • Where should KPI formulas live: ERP, MES, data warehouse, or another platform?

    Usually, not in just one place.

    In most regulated manufacturing environments, KPI formulas should be split by purpose rather than forced into ERP, MES, or a data warehouse by default. A practical pattern is:

    • System of record keeps the source facts, such as orders in ERP, execution events in MES, and quality events in QMS.
    • Operational calculations live close to the process when people need them during execution, for example shift performance, queue aging, downtime response, or first-pass yield at a work center.
    • Enterprise KPI definitions are governed centrally in a semantic layer, analytics platform, or well-controlled data model so finance, operations, and quality are not all reporting different versions of the same metric.

    So the short answer is: put KPI formulas where they can be executed reliably and governed consistently, which is often a combination of MES plus a governed analytics layer, not ERP alone.

    How to decide where a formula belongs

    A KPI formula usually belongs in the platform that best matches these constraints:

    • Decision timing: If the metric drives action during the shift, calculation often belongs in MES, SCADA, historian, or an operations intelligence layer close to the line.
    • Data ownership: If the required facts are authored in ERP, such as standard cost, booked labor, or customer delivery promise, ERP may own part of the calculation or at least the source inputs.
    • Cross-system logic: If the KPI combines ERP, MES, QMS, maintenance, and manual data, a data warehouse or semantic layer is usually the safer place for the official enterprise version.
    • Traceability and change control: If the formula affects regulated reporting, management review, or quality decision-making, you need version control, approval, test evidence, and clear lineage from source data to reported result.
    • Latency tolerance: If next-day reporting is acceptable, a warehouse or lakehouse is often enough. If operators need the value in seconds or minutes, batch analytics is too late.

    What each platform is good at

    ERP is usually best for commercial and planning-oriented metrics tied to orders, inventory valuation, purchasing, financials, and promised dates. It is usually a poor place for high-frequency shop floor calculations because ERP data is often delayed, aggregated, or not granular enough.

    MES is usually best for execution KPIs that depend on real production events, routing status, labor booking, machine states, genealogy, or in-process quality checks. MES can support immediate action, but it often becomes a problem if every site builds local KPI logic differently and no one governs definitions across plants.

    Data warehouse, lakehouse, or semantic layer is usually best for enterprise reporting, cross-functional reconciliation, and a governed “official” KPI definition. This works well for board reporting, plant comparisons, and trend analysis. The tradeoff is that it depends heavily on integration quality, timestamp alignment, master data consistency, and stable mappings across ERP, MES, QMS, and other systems.

    Another platform, such as a historian, industrial analytics tool, or event-processing layer, may be the right place for machine-derived KPIs, condition-based metrics, or near-real-time operational alerts. But these tools still need alignment with enterprise definitions if the same KPI appears in management reports.

    What usually goes wrong

    • Different systems calculate the same KPI differently, often because of different filters, calendars, routing assumptions, or treatment of rework and scrap.
    • ERP becomes the reporting source for metrics it does not actually observe at the needed level of detail.
    • MES dashboards become site-specific and cannot be compared across plants without manual interpretation.
    • The warehouse becomes the “truth” layer before source data is stable, so teams spend more time reconciling data than improving performance.
    • Formula changes are made informally, without approval, regression testing, or documentation of effective dates.

    In regulated and long-lifecycle environments, these failures matter because once a KPI is used for quality escalation, release decisions, supplier management, or executive review, undocumented formula drift creates avoidable audit and trust problems even if no regulation explicitly prescribes that KPI.

    A practical operating model

    For most brownfield environments, a layered approach is more realistic than choosing a single system:

    1. Define KPI semantics once with clear numerator, denominator, exclusions, time basis, data sources, and effective dates.
    2. Keep source events in the originating systems and avoid copying business logic into every downstream tool if you can avoid it.
    3. Allow local operational calculations close to execution where latency matters.
    4. Publish one governed enterprise definition in the analytics layer for cross-site and cross-functional reporting.
    5. Put formula changes under change control with documented rationale, validation, and backward-compatibility decisions.

    This is not as simple as centralizing everything in one stack, but full replacement strategies often fail in brownfield aerospace and similarly regulated environments. The qualification burden, downtime risk, integration complexity, validation effort, and long asset lifecycles usually make wholesale KPI standardization inside a single replacement platform slower and riskier than teams expect.

    Bottom line

    If you need one rule: ERP should rarely be the only home for KPI formulas, MES should not be the uncontrolled home for enterprise definitions, and the data warehouse should not invent metrics without disciplined source-system lineage.

    The most robust answer is usually:

    • MES or operations systems for real-time, action-driving KPIs
    • ERP for financial and planning context
    • A governed analytics or semantic layer for the official cross-functional KPI definition

    That approach is less elegant than a single-system answer, but in mixed-vendor plants it is usually more maintainable and more credible.

  • How do we align supplier quality systems with our AS9100 expectations?

    Start by treating supplier alignment as a controlled operating model, not a one-time audit or a blanket requirement that every supplier mirror your internal system. AS9100 expectations can be flowed down, but how well that works depends on supplier criticality, process capability, documentation discipline, data quality, and how much variation exists across your supply base.

    In practice, alignment usually means defining what suppliers must do, what evidence they must provide, how changes are controlled, and how exceptions are handled. It does not mean every supplier must run the same software, forms, or workflows that you use internally.

    What usually needs to be aligned

    • Supplier qualification and approval criteria, including risk-based segmentation by part criticality, special processes, and performance history.

    • Contract review and requirement flow-down so purchase orders, drawings, specifications, revision levels, key characteristics, and quality clauses are unambiguous.

    • Document control and revision governance, especially for drawings, work instructions, specifications, and customer-specific requirements.

    • Traceability expectations for materials, lots, serialized items, and processing history where required.

    • Inspection and acceptance evidence, including certificates, FAI-related records where applicable, test results, and nonconformance documentation.

    • Change control for product, process, source, tooling, software, inspection method, and sub-tier supplier changes.

    • Nonconformance, containment, corrective action, and escalation rules, including who can disposition what and when buyer approval is required.

    • Performance monitoring using meaningful measures such as quality, delivery, escape history, responsiveness, and repeat findings.

    How to do it without creating avoidable friction

    1. Segment suppliers by risk. Apply tighter controls to suppliers affecting airworthiness, special processes, critical characteristics, or chronic quality issues. A low-risk indirect supplier should not be managed like a critical machining or processing source.

    2. Define a supplier quality requirements matrix. Map supplier type to required controls, records, approvals, and review frequency. This reduces inconsistency across buyers, quality engineers, and programs.

    3. Flow down requirements in operational terms. Do not rely on a general statement that the supplier must comply with your quality expectations. State the exact records, approvals, traceability, revision control, notification timing, and packaging or labeling requirements expected for each category of work.

    4. Standardize evidence, not necessarily systems. Many suppliers will not be on your ERP, MES, PLM, or QMS stack. Requiring identical systems often fails. It is usually more practical to standardize submission formats, metadata, approval gates, and record retention expectations.

    5. Verify before digitizing aggressively. If supplier master data, part revisions, approved source lists, and quality clauses are inconsistent across ERP, PLM, QMS, and purchasing documents, a portal or integration layer will expose those problems, not solve them.

    6. Audit and monitor based on risk and performance. Use audits, scorecards, incoming quality trends, escape analysis, and corrective action closure quality to verify that the supplier system is functioning as expected.

    7. Control changes formally. Alignment breaks down quickly when engineering changes, supplier process changes, or sub-tier substitutions are communicated late or informally.

    What not to assume

    Do not assume that a supplier certificate by itself means your requirements are understood, implemented consistently, or evidenced in the way your customers or internal auditors expect. Certification status can inform risk, but it does not replace requirement flow-down, process verification, or record review.

    Do not assume a supplier portal will fix governance problems. If your approved supplier list, part master, revision release process, and NCR workflow are not well controlled, digital collaboration can increase confusion by moving bad data faster.

    Do not assume full replacement of supplier-facing systems is realistic. In regulated, long-lifecycle aerospace environments, replacing ERP, QMS, PLM, or supplier workflows across a multi-tier supply base often fails because of qualification burden, validation cost, downtime risk, integration complexity, and the simple reality that many suppliers operate on heterogeneous legacy systems.

    Brownfield reality

    Most organizations end up with a coexistence model. Internal quality, purchasing, ERP, PLM, and supplier management tools continue to operate alongside email, portals, EDI, shared templates, and manual review steps. That is normal. The goal is not perfect uniformity. The goal is controlled traceability, clear ownership, and enough interoperability that requirements, records, and approvals can be trusted.

    If you are integrating systems, focus first on the minimum data that must stay synchronized:

    • supplier identity and status

    • approved capabilities and process scope

    • part numbers and revision levels

    • quality clauses and flowed-down requirements

    • nonconformance and corrective action references

    • certificate and record linkage

    Anything beyond that can be useful, but only if the upstream data is governed and change-controlled.

    How to tell if alignment is actually working

    Look for operational evidence, not just completed forms. Useful indicators include fewer requirement escapes at receiving, better revision accuracy, faster and better-contained supplier NCR response, fewer repeat findings, stronger traceability completeness, and fewer manual clarifications between buyer, supplier quality, and receiving inspection.

    If those outcomes do not improve, you may have created administrative burden rather than real alignment.

    Bottom line

    Aligning supplier quality systems with your AS9100 expectations is possible, but it is mostly a governance and execution problem. The practical path is to define risk-based requirements, flow them down clearly, standardize evidence, verify performance, and build interoperability around existing systems rather than assuming every supplier can or should adopt your stack. The result depends heavily on supplier maturity, internal master data quality, change control discipline, and the quality of integration between purchasing, engineering, and quality processes.