Connect981 – Content Dev

FAQ Tag: brownfield integration

  • Do I need new software to comply with ISO 22400?

    ISO 22400, as it exists today, does not mandate any specific software or technology. It defines standardized manufacturing KPIs (e.g., OEE-related measures) and how they should be calculated and interpreted. Whether you need new software depends on how well your current systems can support those definitions in a traceable, repeatable way.

    What ISO 22400 actually expects

    In practical terms, ISO 22400 expects that you can:

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

    • Use standardized KPI definitions and terminology (e.g., availability, performance, quality rate) consistently across the plant or network.
    • Calculate those KPIs using the formulas and data groupings defined by the standard.
    • Show where the underlying data comes from (machines, MES, ERP, manual logs) and how it is transformed.
    • Maintain stability and governance around KPI definitions over time so that reports are comparable and auditable.

    None of this inherently requires a specific vendor or a new platform. It does require that your data and processes are coherent and controlled.

    When existing systems are usually enough

    In many regulated, brownfield environments, you can align to ISO 22400 using your current stack, assuming:

    • MES / SCADA / historian already capture machine states, production counts, scrap, and downtime with timestamps.
    • ERP holds order, schedule, and shift information that can be joined to shop-floor data.
    • Reporting / BI tools (or MES reports) can implement ISO 22400 formulas and clearly document them.
    • Governance exists to control changes to KPI definitions, queries, and calculations under formal change control.

    If you can configure your existing MES or analytics tools to implement ISO 22400 KPI logic and preserve an audit trail, you do not need new software purely for ISO 22400 alignment.

    When gaps in current tools become a problem

    New software becomes relevant when current systems have structural gaps that you cannot close safely or cost-effectively, for example:

    • Incomplete or unreliable data: No consistent recording of downtime categories, scrap reasons, or machine state transitions; manual spreadsheets with poor controls.
    • No clear data lineage: KPIs built from opaque Excel logic or one-off scripts that no one can fully explain or validate.
    • Inflexible legacy MES/SCADA: KPI logic is effectively hard-coded, and modifying it risks breaking validated production or requires vendor customizations you cannot maintain.
    • Lack of traceability: You cannot show who changed KPI definitions, when, and why, which undermines trust and auditability.
    • Fragmentation across plants: Each site uses different definitions and tools, and existing systems cannot be harmonized without major rework.

    In these cases, adding a focused layer (for example, a standard KPI calculation and visualization layer on top of MES/ERP/historian) can be more realistic than trying to retrofit everything into each legacy system.

    Brownfield reality: replacement vs coexistence

    Completely replacing MES, ERP, or SCADA just to support ISO 22400 KPIs is rarely justified in aerospace-grade, regulated environments. Full replacements often fail or stall because of:

    • Qualification and validation burden: New core systems must be validated and requalified across equipment, products, and regulatory contexts.
    • Downtime risk: Cutover windows are constrained, and failures can impact deliveries or flight-critical programs.
    • Integration complexity: Existing interfaces to QMS, PLM, SPC, and test systems are costly to rebuild and revalidate.
    • Long asset lifecycles: OT equipment and legacy controllers may not integrate cleanly with new platforms without additional gateways.

    As a result, ISO 22400 is more often implemented through coexistence:

    • Keep core MES/ERP in place.
    • Add or configure a metrics layer (MES module, historian, or BI platform) to implement ISO 22400 KPI logic.
    • Standardize data mapping and definitions across sites, using documented calculation rules and change control.

    Key questions to decide if you need new software

    To determine whether you truly need additional tools, ask:

    • Can we implement ISO 22400 KPI formulas in our existing MES/BI, with clear documentation and validation?
    • Do we have reliable, time-aligned event and count data to feed those formulas without excessive manual entry?
    • Can we trace each KPI back to raw data sources and logic, and subject changes to change control?
    • Can we apply the same definitions across lines/plants without each site inventing its own logic?

    If the answer to most of these is yes, new software is likely optional. If the answer is no and the gaps cannot be closed by configuration, you may need either:

    • A dedicated performance metrics / OEE layer integrated to existing systems, or
    • Targeted upgrades to specific legacy components that cannot deliver required data or traceability.

    Constraints and tradeoffs

    Regardless of whether you use existing or new tools, ISO 22400 alignment depends on:

    • Data quality: Poorly classified downtime, inaccurate counts, and inconsistent scrap recording will undermine any KPI standard.
    • Process maturity: Operators and supervisors must actually follow the event coding and reporting processes the KPIs rely on.
    • Validation and governance: KPI logic and interfaces should be validated at a level consistent with your QMS and regulatory expectations, with documented ownership and change control.
    • Integration quality: KPI calculations that join MES, ERP, and historian data must handle clock drift, missing data, and order boundary issues explicitly.

    Software alone does not create ISO 22400 compliance. It is an enabler, but the substance is in how you define, calculate, and govern KPIs using the tools you have.

  • What can manufacturers do now to prepare for advanced digital FAI capabilities?

    Manufacturers can make meaningful progress toward advanced digital FAI without buying or replacing major systems yet. The priority is to get your data, processes, and constraints ready so any digital FAI solution can plug into your real environment and withstand audits.

    1. Stabilize your current AS9102 / FAI process

    Digital tools will not fix an unstable or highly variable FAI process. Before investing, make the paper or semi-digital process coherent and repeatable.

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

    • Standardize FAI triggers: Document when a full vs partial FAI is required (new part, design change, process change, new supplier, new tooling, break in production, etc.). Align quality, engineering, and supply chain on these rules.
    • Define ownership and handoffs: Map who is responsible for ballooning, measurement plans, data collection, review, approval, submission, and archiving. Capture real-world workarounds, not just the procedure.
    • Lock down FAI templates: Decide which AS9102 revision and formats you use (including any customer-specific variants). Minimize local variants that will be hard to automate later.
    • Measure current performance: Track rejections, rework on FAIs, cycle time, and where they stall (engineering, supplier, MRB, customer review). These metrics will anchor realistic expectations for digital gains.

    2. Clean up drawing, ballooning, and characteristic data

    Advanced digital FAI depends on structured, reliable characteristic data. In brownfield environments this is usually the biggest barrier.

    • Enforce drawing source of truth: Clarify whether PLM, a drawing vault, or another system is the master for released design. Reduce use of uncontrolled PDFs on shared drives or email.
    • Standardize ballooning conventions: Align on rules for characteristic numbering, grouping, and how you treat notes, flag notes, key characteristics, and reference dimensions. Inconsistent ballooning makes automation brittle.
    • Start building a digital characteristic library: Even in spreadsheets, begin capturing balloon number, specification, tolerance, feature type, key characteristic flags, and inspection method. Start with your highest-risk or highest-volume part families.
    • Clarify revision and supersession rules: Document how drawing revisions propagate to characteristics, old FAIs, and partial FAIs. Digital FAI will need to mirror these rules to be audit-safe.

    3. Tighten master data, part genealogy, and revision control

    Digital FAI requires consistent identifiers across PLM, ERP, MES, and QMS. Many failures trace back to mismatched part or revision data.

    • Harden part numbering and revisions: Ensure part numbers and revs are consistent across systems and that rules for new part vs new revision are understood and enforced.
    • Link FAIs to part / rev and routing: Ensure every FAI is traceable to a specific part number, revision, and process/route. Where this is not true, document gaps explicitly.
    • Inventory and lot genealogy: For parts requiring FAI, confirm you can trace which lots or serials were produced under which revision and process. Partial FAIs rely on this clarity.
    • Define where the “official” FAI record lives: Many plants scatter FAI artifacts across SharePoint, QMS, Net-Inspect, and email. Pick a system of record and start migrating new FAIs there, even if it is still manual.

    4. Map your system landscape and FAI touchpoints

    Advanced digital FAI must coexist with your current MES, ERP, PLM, QMS, and customer portals. Assuming a complete replacement usually fails in regulated aerospace due to validation burden, downtime, and integration risk.

    • Document where FAI data is created and consumed: For example: PLM (design), ERP (part and routing), MES (actual execution and inspection), QMS (NCR/MRB), customer portals (AS9102 submission), and supplier portals.
    • Identify data owners and integration choke points: Note manual rekeying, spreadsheets, and custom scripts that currently bridge systems. These are high-value integration targets for any digital FAI deployment.
    • Clarify IT/security constraints: Especially for cloud solutions, understand ITAR/DFARS, data residency, VPN and identity management requirements, and how third-party tools are approved.
    • Capture validation expectations: For aerospace-grade plants, note how new software must be qualified or validated, and what evidence QA/regulatory expect.

    5. Improve measurement system readiness

    Digital FAI is only as strong as your inspection capability and data integrity.

    • Assess inspection equipment connectivity: Document which CMMs, vision systems, gages, and test rigs can export data in usable formats, and which are locked into proprietary or manual outputs.
    • Standardize measurement formats: Aim for common CSV or similar structures where possible, with clear column naming and units. This reduces custom mapping later.
    • Strengthen MSA / Gage R&R practices: Ensure critical characteristics have stable and capable measurement systems; digital aggregation will expose poor gage performance quickly.
    • Define who can change inspection plans: For traceability, make sure modifications to inspection sequences and sampling are controlled and logged, regardless of digital tooling.

    6. Codify change control and re-FAI rules

    Re-FAI and partial FAI logic is often tribal knowledge. Advanced digital FAI needs these rules explicit and machine-readable.

    • Write clear re-FAI criteria: For design, process, tooling, supplier, and location changes, define what triggers full vs partial FAI. Include customer- and program-specific nuances.
    • Align with customers and primes where needed: For major customers, validate your interpretation of AS9102 and contract requirements to avoid automating an incorrect rule set.
    • Tie FAI logic into ECO/ECR workflows: Ensure engineering change processes explicitly call out whether FAI is required and how impacted characteristics are identified.
    • Preserve historical traceability: When you update FAIs, ensure earlier versions remain accessible with clear lineage; digital systems will need to mirror this behavior.

    7. Start with contained digital FAI pilots, not big-bang replacement

    In regulated, long-lifecycle environments, attempts to fully replace MES, PLM, or QMS to “solve” FAI usually stall under validation cost, downtime risk, and integration complexity.

    • Pick a focused part family or cell: Choose a scope with meaningful volume or risk, but limited system complexity. Avoid the most exotic legacy assets in the first pilot.
    • Digitize the end-to-end FAI flow locally: Even using off-the-shelf tools or controlled spreadsheets, structure balloons, characteristics, inspection results, approvals, and archival in a single coherent flow.
    • Test coexistence: Ensure the pilot can exchange data with existing PLM, ERP, and customer portals via exports/imports rather than deep integrations at first.
    • Collect evidence and lessons learned: Capture what broke (data gaps, role confusion, integration friction). Use this to set realistic requirements for any future digital FAI platform.

    8. Prepare people, governance, and audit readiness

    Advanced digital FAI increases visibility and auditability, which can be a cultural shift.

    • Clarify roles and training needs: Decide who will own digital ballooning, FAI planning, and review. Identify skill gaps in GD&T, data handling, and basic digital tools.
    • Define electronic record expectations: Work with quality and internal audit to agree what constitutes an acceptable electronic FAI record, including e-signatures, timestamps, and change history.
    • Establish retention and access rules: Decide how long electronic FAIs must be retained, who can view or change them, and how you will demonstrate this during AS9100/AS9102-related audits.
    • Document your current-state risk posture: Know where today’s FAI process is weakest so you can prioritize controls and evidence in any digital implementation.

    9. Define realistic objectives and selection criteria

    Before engaging vendors or building in-house solutions, be clear about what “advanced digital FAI” should achieve in your environment.

    • Prioritize by constraint: Decide whether your main pain is engineering time on ballooning, inspection throughput, customer rejections, supplier FAIs, or audit preparation. Different tools optimize different bottlenecks.
    • Set non-negotiables: Examples include traceability to drawing rev, export to customer portals, ITAR-safe data handling, and demonstrable audit trails.
    • Expect coexistence, not replacement: Assume the digital FAI solution must sit alongside existing PLM, ERP, MES, and QMS for many years. Demand clear integration paths instead of assuming those systems will be swapped out soon.
    • Plan for validation and change control: Budget time and resources for software qualification, procedural updates, and training. Treat digital FAI as a controlled change, not a simple IT “tool drop.”

    By focusing on process stability, data cleanliness, clear rules, and realistic integration expectations, manufacturers can make themselves ready for advanced digital FAI and reduce the risk that new tools simply surface old problems in a more visible way.

  • How do I prevent AI from surfacing misleading or coincidental patterns?

    You do not prevent this completely. You manage it by designing AI use so that spurious correlations, data leakage, and unstable patterns are less likely to drive action.

    In industrial and regulated environments, the practical goal is not to let AI “discover truth” on its own. The goal is to limit where it can look, define what evidence counts, and require validation before its outputs affect scheduling, process changes, inspection decisions, maintenance actions, or release-related workflows.

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

    What actually reduces misleading patterns

    • Start with a tightly defined use case. Broad pattern hunting across many variables often finds coincidences. Models perform better when the target is narrow, measurable, and tied to a real operational decision.

    • Use governed, context-rich data. Poor tag mapping, missing timestamps, inconsistent units, backfilled records, manual overrides, and untracked master-data changes can all create false signals. Data lineage matters as much as model choice.

    • Separate training data from outcome leakage. If the model can indirectly see the answer through downstream fields, rework codes, disposition data, or operator-entered notes added after the event, it may appear accurate while learning nothing useful.

    • Validate against process reality, not just statistics. A strong retrospective score is not enough. Check whether the pattern is physically plausible, repeatable across shifts, products, tools, and time periods, and consistent with known process constraints.

    • Test on drift and edge cases. Product mix changes, tooling wear, supplier changes, engineering revisions, maintenance events, and calibration issues can break patterns that looked stable in historical data.

    • Keep humans in the approval path for consequential decisions. AI can prioritize review, flag anomalies, or suggest likely drivers. It should not silently change recipes, dispositions, routes, or quality status without controls appropriate to the risk.

    • Use thresholds and abstention. A useful system should be allowed to say “insufficient confidence” rather than forcing a prediction on weak evidence.

    • Monitor for false positives and action cost. A model that catches some real issues but floods teams with noise can still damage operations by consuming engineering and quality capacity.

    Controls that matter in practice

    The most effective controls are usually operational, not algorithmic:

    • Version control for models, features, prompts, and reference data

    • Traceable links from output back to source records and transformations

    • Change control for model updates, thresholds, and workflow integration

    • Validation protocols aligned to intended use and risk level

    • Periodic requalification when data sources, process conditions, or product configurations change materially

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

    If those controls are weak, even a technically sound model can become misleading in production.

    Correlation is not decision authority

    Many AI systems are good at finding associations. That does not mean the association is causal, stable, or safe to operationalize. In manufacturing, coincidental patterns often come from hidden scheduling effects, operator assignment, lot clustering, maintenance timing, or ERP and MES transaction artifacts rather than true process drivers.

    That is why AI outputs should usually be treated as decision support unless and until the organization has validated the use case, the data, and the workflow impact. The higher the consequence, the stronger the evidence and controls should be.

    Brownfield reality

    In mixed MES, ERP, PLM, QMS, historian, and spreadsheet environments, misleading patterns are often caused by integration debt rather than model failure alone. Timestamp misalignment, duplicate identifiers, incomplete genealogy, inconsistent revision handling, and manual workarounds can produce impressive but false patterns.

    For that reason, full rip-and-replace is rarely the safest answer. In long lifecycle, regulated operations, replacement programs often fail because of qualification burden, validation cost, downtime risk, and the complexity of re-establishing traceability across connected systems. A more realistic approach is to improve data contracts, lineage, and validation around the systems you already have, then introduce AI in bounded workflows.

    Practical rule of thumb

    If you cannot explain where the signal came from, what data created it, how it was validated, when it may fail, and who reviews exceptions, then you should not rely on it for consequential operational or quality decisions.

  • How often should inventory accuracy KPIs be reviewed?

    Short answer: tie review cadence to risk, volatility, and system maturity

    In regulated manufacturing, there is no single correct review frequency for inventory accuracy KPIs that fits all plants. The cadence should depend on material criticality, transaction volume, history of discrepancies, and the maturity of your ERP/MES/warehouse processes. A common pattern is daily operational checks in active areas, weekly trend reviews for supervisors, and monthly formal reviews for management. Highly critical or unstable areas may need near-real-time dashboards, while stable, low-risk areas may tolerate less frequent review. Whatever cadence is chosen must fit within existing SOPs, governance forums, and data validation practices.

    Operational cadence: what to check daily or near real time

    Daily or shift-based review is typically appropriate for high-velocity or high-risk inventory zones, such as line-side stores, quarantine areas, and controlled materials with expiry. At this level, teams usually look at simple, leading indicators like cycle count discrepancies raised, blocked/held inventory, and number of manual adjustments. These checks are often performed by material handlers, supervisors, or planners during tier meetings, not by senior management. The purpose is to catch issues before they propagate into order delays, scrap, or batch record deviations. In brownfield environments with mixed systems, some of this review may be manual or spreadsheet-based, and you should be explicit about which data is trusted and which is provisional.

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

    Weekly reviews: trends, hotspots, and process adherence

    Weekly reviews are typically used to assess trends in inventory accuracy rather than single-point failures. Supervisors and value-stream leaders might review metrics such as percentage of locations counted with no variance, total stock adjustments by value, and recurrent issues by material or work center. This cadence is usually enough to identify hotspots (e.g., a specific warehouse zone or kitting process) without overwhelming teams with noise from daily fluctuations. In regulated settings, the weekly review is a good place to confirm adherence to cycle count plans and segregation rules, and to decide which discrepancies warrant formal investigation. Because legacy and new systems often coexist, weekly reviews should explicitly consider data gaps, system lag, and integration errors when interpreting trends.

    Monthly and quarterly reviews: governance, risk, and systemic issues

    Monthly or quarterly reviews are typically the right level for management and cross-functional governance bodies. At this cadence, the focus shifts from specific variances to systemic drivers: process design issues, training gaps, integration defects, or chronic master data problems. Metrics reviewed may include overall inventory record accuracy by count and by value, cycle count completion vs. plan, and the impact of inaccuracies on schedule adherence, deviations, or customer service. In aerospace-grade or similar regulated environments, this review is also where management confirms that the inventory control process remains within validated parameters and that any proposed system changes go through formal change control. Longer-term trend analysis at this level often exposes why simplistic “just tighten controls” actions fail when underlying system or integration issues are not addressed.

    When to increase or decrease KPI review frequency

    The review cadence should not be static; it should respond to actual performance and risk changes. When plants experience repeated stock-outs, mis-picks, or deviations tied to material control, more frequent KPI reviews and shorter feedback loops are usually warranted until the system stabilizes. Conversely, in areas that have demonstrated stable performance over time, with robust cycle counting and minimal discrepancies, it can be reasonable to reduce the intensity of review while maintaining a baseline monthly governance check. Introducing new systems or integrations, changing warehouse layouts, or modifying BOM/route structures are all triggers for temporarily increasing review frequency due to higher error risk. Any changes to cadence in regulated environments should themselves go through appropriate approval and documentation processes to maintain traceability.

    Coexistence with legacy systems and fragmented data

    In brownfield environments with mixed ERP, legacy WMS, and manual records, the frequency of KPI review is constrained by data availability and reconciliation effort. Daily or near-real-time review is only meaningful if the data is timely and reliably synchronized; otherwise, operators may chase false issues caused by latency or interface failures. Where integration is weak, some plants adopt a hybrid approach: high-frequency checks on local operational indicators (e.g., discrepancies at the point of use) and lower-frequency, carefully reconciled KPI reviews for the global inventory picture. Attempts to replace all legacy systems just to achieve higher-frequency KPIs often fail under the weight of validation, qualification, and downtime risks. A more realistic approach is to define clearly which system is the record of truth for each metric and adjust review cadence to match that system’s reliability and update cycle.

    Why reviewing more often is not automatically better

    Reviewing inventory accuracy KPIs too frequently without sufficient root cause capacity can overwhelm teams and dilute focus. In complex regulated environments, every significant discrepancy may trigger investigation, documentation, and sometimes regulatory impact assessment, which can quickly consume resources. Overly aggressive review cadences can also drive workarounds and informal practices if staff feel they are being measured on noise rather than meaningful trends. The goal is not to look at numbers as often as possible but to review them at a cadence where the organization can analyze, act, and verify effectiveness of changes. Aligning review frequency with problem-solving capacity, deviation management processes, and change control throughput is critical to avoid a backlog of unaddressed findings.

  • How can organizations transition from paper-based traceability to digital records without disrupting production?

    Transitioning from paper-based traceability to digital records without disrupting production is possible, but only if you treat it as a controlled change to your execution system, not a tooling swap. The safest approaches are incremental, parallel, and tightly governed.

    Start with scope and risk, not software features

    Before introducing any digital tool on the floor:

    In practice, this connects to part genealogy and traceability when teams need to turn the answer into repeatable execution habits.

    • Define the minimum scope for the first step: a product family, a single line/cell, or one traceability object (e.g., serials and key process parameters only).
    • Clarify regulatory and customer expectations: retention time, required data fields, signature/attribution rules, and audit expectations for electronic records.
    • List failure modes that you must avoid: lost traceability, incomplete records, ambiguous lot/serial linkage, or unvalidated electronic signatures.

    Design a digital traceability model first

    Paper forms often hide design issues that become painful when digitized. Before deployment:

    • Standardize the data model: part/serial/lot identifiers, operation numbers, machine IDs, operator IDs, defect codes, and rework flows.
    • Define genealogy rules: how lots split/merge, how subassemblies relate to top-level assemblies, and how rework/repair records attach to the original build.
    • Agree on master data ownership: which system is the system of record for parts, routings, revisions, and BOMs (often ERP/PLM), and how the digital traceability solution references them.
    • Specify when a record is “complete”: required fields, checks, and approvals before a unit can move to the next operation.

    In brownfield environments, expect to adjust this model several times as you find edge cases. Build that iteration into your plan and change-control process.

    Use a pilot and run paper and digital in parallel

    The lowest-risk approach is to avoid a big-bang cutover:

    • Select a pilot area with contained volume, representative complexity, and cooperative supervision.
    • Introduce digital traceability while keeping paper travelers/forms as the official record during the pilot.
    • Have operators record in both systems initially, then compare for completeness, timing, and error types.
    • Measure specific gaps: missing scans, incorrect lot links, time stamps out of order, or steps that operators routinely skip.

    This dual-record phase is inefficient, but it is often necessary to prove the digital process, tune the UI, and collect evidence that the electronic records are reliable before you rely on them for audits or investigations.

    Integrate carefully with existing MES, ERP, PLM, and QMS

    In most regulated plants, traceability touches multiple systems. Replacing them outright is rarely practical given validation costs and disruption risk. Instead:

    • Decide the system of record for each object: part master in ERP/PLM, work orders in ERP/MES, quality events in QMS, as-built genealogy in MES/traceability tool.
    • Use stable identifiers (work-order numbers, serials, batch IDs) so digital records can be joined to legacy systems without brittle custom logic.
    • Limit early integrations to what is essential to avoid double keying: e.g., one-way import of work orders and routings into the digital traveler, or export of completed as-built records to QMS.
    • Plan for outages and fallbacks: what happens if the network or MES is down mid-shift. Define when you revert to paper and how you later reconcile records.

    Complex, full replacement of MES/ERP traceability modules often fails in aerospace-grade environments because of qualification burden, the need to revalidate many downstream reports and interfaces, and the risk of extended downtime. A coexistence strategy, where a new digital layer gradually assumes more execution and traceability responsibility, typically carries less operational risk.

    Focus on operator experience and shop-floor practicality

    Digital traceability fails quickly if it slows operators or conflicts with how work is actually done.

    • Map the real workflow (not just the documented one): staging, inspections, rework, handoffs between cells, and informal workarounds.
    • Minimize added clicks and data entry: use barcodes/QRs, NFC, or simple picklists wherever possible instead of free-text typing.
    • Co-locate terminals or tablets where the work happens. Avoid long walks to a single shared station that becomes a bottleneck.
    • Train operators with real parts and real work orders, not only classroom demos. Validate that they can complete a typical job without external coaching.
    • Provide clear support paths on shift (supervision, engineering, IT) to resolve issues without stopping production.

    Use staged cutovers by product, cell, or shift

    Once the pilot proves that digital records are complete and reliable, move away from paper in controlled steps rather than across the entire plant at once:

    • Cut over by product family or value stream so that each team only has to manage one primary method (paper or digital) for a given job.
    • Lock down paper travelers in the cutover area: no new jobs start on paper after the agreed date, but existing paper jobs are allowed to finish.
    • Document and approve the change via your existing change-control and validation processes, including risk analysis and, where necessary, protocol-based testing.
    • Monitor the first weeks closely for missing scans, delays, or operator confusion and correct quickly.

    Validation, audit trails, and change control

    In regulated and aerospace environments, a digital traceability system must be treated as a validated, controlled system, not an informal tool.

    • Document requirements and risks for traceability: data integrity, time stamping, user attribution, and change logs.
    • Test and record evidence that the system behaves as intended for typical and edge-case workflows (rework, scrap, partial completions).
    • Ensure audit trails are accessible and can be linked back to work orders, serials, and quality records during audits or investigations.
    • Establish change-control for workflows, fields, and integrations so that future edits do not quietly invalidate validation evidence or break downstream reports.

    Measure and correct, rather than assume success

    To confirm that production is not being disrupted and that traceability is actually improving:

    • Track basic performance metrics before and after: first-pass yield, scrap, rework rate, WIP aging, and time to retrieve records during audits or investigations.
    • Monitor exception rates: missing scans, incomplete records, manual overrides, or late data entry.
    • Act on feedback from operators, supervisors, and quality engineers; many issues only appear at real production volumes.
    • Iterate in small releases rather than large redesigns, each governed by the same change-control discipline.

    With this incremental, risk-aware approach, organizations can move from paper travelers and binders to digital, queryable traceability without a single big-bang event, while maintaining production flow and audit readiness.

  • What is the IEC 62443 in a nutshell?

    IEC 62443 is a family of international standards for cybersecurity of industrial automation and control systems (IACS). It provides a common reference for how asset owners, system integrators, and product suppliers should define, design, implement, and maintain cybersecurity for operational technology (OT).

    Core idea in one sentence

    IEC 62443 breaks OT cybersecurity into roles, zones/conduits, and security levels, then defines requirements for each role and level across the system lifecycle, from product development through integration and plant operation.

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

    What IEC 62443 covers

    The standard is organized as a series of parts. In practice, organizations use them as a framework for requirements, design, and assessment, not as a checklist that guarantees security.

    • Foundations and concepts (e.g. IEC 62443-1-x): terminology, risk concepts, and the idea of security zones and conduits.
    • Policies and procedures for asset owners (e.g. IEC 62443-2-x): how to manage cybersecurity programs, incident response, patching, and lifecycle management at the site or enterprise level.
    • System-level requirements (e.g. IEC 62443-3-x): how to architect and engineer secure control systems, including network segmentation, access control, and monitoring.
    • Component and product requirements (e.g. IEC 62443-4-x): secure product development practices and technical requirements for devices and applications.

    Key concepts relevant to regulated manufacturing

    • Security levels (SL 1 to 4): describe protection against increasingly capable threat actors. They help you specify and justify how much protection a given zone needs, instead of treating all assets the same.
    • Zones and conduits: group assets with similar risk and trust requirements into zones, and define controlled conduits between them. This fits brownfield plants where you cannot redesign everything, but can segment and harden critical paths.
    • Role-based responsibilities: separates expectations for asset owners, system integrators, and product suppliers. In mixed-vendor environments, this is important for contract language and integration planning.
    • Lifecycle focus: emphasizes secure design, deployment, operation, maintenance, and decommissioning. This aligns with long equipment lifecycles and change control realities common in regulated plants.

    How it fits into brownfield, regulated environments

    Most plants already run legacy DCS/PLC/MES/ERP stacks, often with limited downtime windows and complex validation or qualification burdens. IEC 62443 is usually applied incrementally rather than via a full system replacement.

    • Incremental hardening: segment legacy networks into zones, restrict remote access, and improve account management using IEC 62443 concepts without replacing all hardware.
    • Procurement and integration criteria: use IEC 62443 parts and security levels in RFQs and integration specs so new equipment and software are more secure and easier to integrate with existing stacks.
    • Change control and validation: map cybersecurity changes (patching, configuration baselines, new appliances) to formal change-control workflows and, where applicable, validation or qualification activities.
    • Coexistence with IT frameworks: IEC 62443 can sit alongside ISO 27001, NIST CSF, or corporate IT policies. Typically, corporate IT sets enterprise policies, while IEC 62443 provides OT-specific requirements and design patterns.

    What IEC 62443 does not guarantee

    IEC 62443 is a guidance and requirements framework, not a security guarantee. In particular:

    • Conformance to parts of IEC 62443 does not ensure regulatory compliance, safe operation, or specific audit outcomes.
    • Security posture still depends heavily on site-specific design, vendor implementations, integration quality, and ongoing maintenance.
    • In long-lifecycle plants, many legacy components will never fully meet current technical requirements; risk must be managed with compensating controls.

    For most industrial organizations, “using IEC 62443” means aligning policies, architectures, and procurement with its concepts, then applying it pragmatically given brownfield constraints, rather than attempting a wholesale rebuild of control systems.

  • What is the app that creates work instructions?

    There is no single universal “app” that creates work instructions across all plants or systems. In most regulated, brownfield environments, work instructions are created and maintained in one or more of the following:

    • MES work instruction modules: Many MES platforms include native electronic work instruction (EWI) or operator guidance modules. These are often used when you need tight linkage to routing, data collection, and e-signatures. The constraint is that format, layout, and reuse across sites or other systems can be limited, and changes must go through MES change control and revalidation.
    • PLM or engineering authoring tools: Some organizations create manufacturing work instructions inside PLM (or linked CAD/ECAD/MBOM tools) as part of the manufacturing process plan. This is strong for traceability to design and configuration, but can be harder to consume on the shop floor without a separate viewer, MES integration, or a published derivative (PDF, HTML, etc.).
    • DMS/QMS (document management / quality systems): In many regulated plants, the formal, controlled version of a work instruction is a document in a DMS or QMS (e.g., as a SOP, WI, or controlled form). Operators may see a PDF or printed copy, sometimes embedded or linked from MES. This supports document control and audit trails, but is weaker for in-process guidance, rich media, and conditional logic.
    • Specialized digital work instruction tools: There are point solutions focused solely on interactive digital work instructions (images, 3D, video, step-by-step guidance, error-proofing). These can be powerful but only work well if they are integrated with your MES/ERP/PLM/QMS and validated appropriately. Without that, they become another silo and can create version control and traceability risks.
    • Legacy office tools (Word, PowerPoint, Excel, PDF): In many brownfield environments, authoring still happens in office tools. These files are then stored in a shared drive, DMS, or QMS and referenced by MES or printed to paper. This approach is simple to deploy but increases the risk of inconsistent versions, limited structure, and weaker integration with as-built data.

    How to identify “the app” in your environment

    In a specific plant, the “app that creates work instructions” is usually whichever system is treated as the authoritative source of the content, not necessarily the system that displays it on the line.

    In practice, this connects to digital work instructions and training when teams need to turn the answer into repeatable execution habits.

    To determine this in your environment:

    • Check where change-controlled edits happen (where engineering or manufacturing actually edits steps, images, and sequence).
    • Check where approvals, versions, and effective dates are managed (often in a DMS/QMS or PLM, even if the operator UI is in MES).
    • Ask which system is considered the “system of record” for work instructions in your quality system and procedures.
    • Review which system is validated for GxP or regulated use and how changes are documented.

    In many cases, there is a split:

    • Authoring and approval in PLM or QMS/DMS.
    • Execution and display in MES or a digital work instruction viewer.

    Key constraints and tradeoffs

    When choosing or standardizing on an app for work instruction creation, you need to weigh:

    • Traceability: Can you link each step to design data, BOMs, routings, risk analyses, and training records?
    • Version control and governance: Does it support formal review/approval, effective dating, and change history aligned with your QMS?
    • Integration with existing systems: Can it coexist with current MES/ERP/PLM/QMS, or will it duplicate data? In brownfield sites, full replacement of MES or PLM is rarely feasible due to validation burden, downtime risk, and integration complexity.
    • Validation and change control: How expensive is it to validate the app and maintain it under change control across long equipment lifecycles?
    • Usability on the shop floor: Can operators actually follow it under real production constraints (small screens, gloves, intermittent connectivity, language variants)?

    Replacing an existing MES or QMS just to change how work instructions are authored is usually high risk and high cost in regulated environments. A more common approach is to:

    • Keep the current system of record (often PLM or QMS/DMS).
    • Improve templates, structure, and media in that system.
    • Integrate or layer a digital work instruction viewer or MES module on top, with careful mapping of versions and change control.

    How this coexists with legacy systems

    In brownfield plants, multiple generations of systems often coexist:

    • Legacy lines may still use printed PDF work instructions sourced from QMS.
    • Newer cells may use MES-driven electronic work instructions, with core content still authored in PLM or QMS.
    • Some high-variance or prototype areas might use a specialized EWI tool integrated loosely (or manually) with existing systems.

    This hybrid reality is normal. The critical point is to make clear in your procedures which system is the authoritative app for creation and change control and how other systems consume that content, so you avoid conflicting versions in front of operators.

  • How does ISO 22400 define equipment availability and utilization?

    ISO 22400 treats equipment availability and utilization as distinct but related manufacturing KPIs. It does not prescribe specific targets, but provides standardized definitions and formulas so different plants and systems can calculate these metrics consistently.

    Equipment availability in ISO 22400

    In ISO 22400, availability is a time-based indicator that compares the time equipment is actually capable of producing to the time it is planned to be available.

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

    At a simplified level, for a given period:

    • Planned time: Time the equipment is scheduled to be available for production (excluding planned long shutdowns such as major holidays or extended overhauls, depending on your site convention).
    • Operating time: Time the equipment is in a state where it can produce (often called “available” or “up” in many MES/SCADA models). This typically includes running and short stops that do not put the equipment in a down state.

    A commonly used ISO 22400-style form is:

    Availability = Operating time / Planned time

    ISO 22400 distinguishes between different equipment states (e.g., planned shutdown, unplanned downtime, setup, minor stops). How each state is included or excluded from “operating” and “planned” must be configured in your system and aligned with your site’s interpretation of the standard.

    In many implementations, this aligns with the “availability” component of OEE, but ISO 22400 formalizes the underlying time categories and KPIs, rather than only the OEE composite.

    Equipment utilization in ISO 22400

    ISO 22400 defines utilization as a capacity-related indicator. It expresses how much of the equipment’s available capacity is actually used for productive operation during a period.

    There are two common patterns depending on the specific ISO 22400 KPI variant you implement:

    • Time-based utilization: Effective production time compared with some larger time base.
      Typical form: Utilization = Effective production time / Calendar time or / Planned time, depending on configuration.
    • Capacity-based utilization: Actual output compared to theoretical maximum capacity for the period.
      Typical form: Utilization = Actual output / Theoretical maximum output.

    ISO 22400 provides definitions for these KPIs and the underlying concepts (e.g., calendar time, operating time, net operating time, capacity), but it does not enforce one single utilization formula for all plants. Your organization must choose and document which ISO 22400 utilization KPI is being used, and how it maps to equipment states and order data.

    Key differences: availability vs utilization

    • What they measure:
      • Availability measures time readiness: How much of the planned time was the equipment able to run.
      • Utilization measures capacity usage: How much of the time or capacity base was actually used to produce.
    • Primary inputs:
      • Availability is driven by equipment states and downtime categorization.
      • Utilization also depends on production schedules, order loading, and rated capacity or theoretical maximum rates.
    • Typical interpretation:
      • Low availability usually indicates maintenance, reliability, or changeover issues.
      • Low utilization with good availability usually indicates scheduling, loading, mix, or demand issues.

    Dependencies and implementation caveats

    The standard definitions only become meaningful if they are implemented consistently across your systems and sites. In regulated and long-lifecycle environments, several realities affect how ISO 22400 availability and utilization behave in practice:

    • State modeling and integration: SCADA/PLC, MES, and CMMS often use different equipment state models. How a state like “setup” or “warmup” is mapped into ISO 22400 categories (operating vs planned shutdown vs unplanned downtime) is site-specific and must be explicitly configured and validated.
    • Brownfield coexistence: Many plants already have OEE logic embedded in legacy MES or custom reports. A strict ISO 22400 implementation often changes the numbers people are used to seeing. Running both side-by-side for a period, with clear mapping, is usually necessary to avoid confusion and claims that the data is “wrong”.
    • Capacity definitions: Utilization requires credible definitions of rated speed and theoretical maximum output. In high-mix, low-volume operations, or with manual and semi-automated stations, these values are often approximate. You may need product-family or routing-step level capacities rather than a single number per machine.
    • Regulatory constraints: Any change in KPI calculation logic that drives maintenance intervals, staffing, or qualification decisions may need documented change control, impact assessment, and potentially revalidation of associated reports and automated rules.
    • Time-base alignment: Calendar time, shift time, and planned production time are not the same. ISO 22400 allows different KPI variants; if you mix them (for example, comparing one line on calendar-based utilization and another on shift-based utilization) you can easily misinterpret relative performance.

    Relation to OEE and existing MES/ERP metrics

    ISO 22400 does not require you to replace OEE or your current KPIs. It provides a standardized KPI framework that can sit under or alongside existing OEE implementations.

    • OEE availability vs ISO 22400 availability: They are similar but not guaranteed to be identical. Many legacy OEE implementations treat some planned stops differently than ISO 22400. If you migrate to ISO 22400 definitions without careful mapping, historical comparisons will be distorted.
    • Use as a reference model: A practical approach in brownfield environments is to:
      • Map current MES/SCADA state codes and KPIs to ISO 22400 categories.
      • Document any deliberate deviations from the standard (e.g., including certain planned micro-stops in availability).
      • Gradually converge toward ISO 22400-compliant logic as systems are upgraded, rather than trying a big-bang replacement of all KPI logic.

    What this means in a regulated, long-lifecycle plant

    In aerospace, defense, and similar regulated environments, adopting ISO 22400 definitions for availability and utilization is less about installing a new KPI and more about establishing a traceable and auditable calculation method:

    • You need clear documentation of definitions, formulas, and state mappings used at each asset and line.
    • Changes to those definitions should go through change control, with impact analysis on any KPIs that feed maintenance planning, capacity commitments, or customer-facing performance reporting.
    • Full replacement of existing KPI engines in MES, historians, and reporting tools is rarely feasible in one step due to validation burden, integration complexity, and downtime risk. A phased coexistence model, with ISO 22400 as the reference, is usually safer.

    Used in this way, ISO 22400 provides a common language for availability and utilization across sites and vendors, while still allowing for local configuration where justified and documented.

  • Why is IT important to MES?

    IT is important to MES because manufacturing execution systems are not standalone tools. They depend on enterprise infrastructure, data, and governance that are typically owned or coordinated by IT. In regulated, brownfield environments, this dependency is even stronger because MES must coexist with legacy systems and stringent validation expectations.

    1. Infrastructure and performance

    MES relies on IT to provide and manage:

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

    • Servers or cloud environments sized for peak production loads
    • Network reliability between shop floor, data centers, and remote sites
    • Database platforms, backup, and restore capabilities
    • Disaster recovery and business continuity plans tested against MES use cases

    Without robust IT support, MES performance and availability become a production risk. In regulated contexts, unplanned downtime can also create documentation gaps and deviation investigations.

    2. Security and access control

    MES touches production data, quality records, and sometimes regulated product genealogy. IT usually owns:

    • Identity and access management (e.g., SSO, MFA, directory services)
    • Network segmentation between OT and IT zones
    • Patch management and vulnerability handling for servers and endpoints
    • Security monitoring and incident response processes

    Weak coordination with IT can leave MES exposed to security risks or force emergency changes that are hard to reconcile with validation and change control requirements.

    3. Integration with ERP, QMS, PLM, and historians

    MES is typically one system in a larger landscape. IT is usually responsible for, or deeply involved in:

    • Defining and operating integration patterns (APIs, message queues, file drops)
    • Managing data mappings and master data synchronization (items, routes, resources)
    • Coordinating changes across ERP, QMS, PLM, LIMS, and data historians
    • Monitoring interfaces to detect and resolve failures early

    In brownfield environments, these integrations are often fragile and partially undocumented. MES projects that bypass IT commonly underestimate this risk, leading to interface failures, data inconsistencies, or loss of traceability when one system is updated without proper coordination.

    4. Validation, change control, and traceability

    In regulated settings, MES changes are tightly controlled. IT typically contributes to:

    • Environment strategy (development, test, validation, production)
    • Configuration and release management tools and processes
    • Evidence capture for validation (logs, approvals, deployment records)
    • Audit trails and system logs needed for investigations and inspections

    MES cannot realistically maintain a compliant lifecycle without IT alignment on how software is deployed, versioned, and documented. Poor coordination often surfaces during audits, when evidence of who changed what and when is required.

    5. Long-term lifecycle and cost control

    MES deployments in industrial environments often remain in place for a decade or more. Over that time, IT has to manage:

    • Technology obsolescence (OS, database, middleware end-of-support)
    • Hardware refresh and capacity planning
    • Vendor upgrades and compatibility with existing integrations
    • License management and cost control

    Attempting to bypass IT usually leads to “orphan” MES instances that are hard to upgrade or move, increasing technical debt and validation effort. Full replacement strategies that ignore these lifecycle realities often fail because the qualification burden, downtime risk, and integration complexity are underestimated.

    6. OT/IT coexistence in brownfield plants

    On the shop floor, MES must coexist with control systems, SCADA, and equipment from multiple vendors and eras. IT is important to MES here because it can:

    • Help design secure, reliable connectivity from PLCs and machines to MES
    • Support edge or gateway solutions where direct integration is not feasible
    • Coordinate with operations and engineering to schedule changes around limited downtime windows
    • Standardize logging, monitoring, and support arrangements across heterogeneous assets

    In many plants, a pragmatic coexistence approach is more realistic than a clean-slate architecture. IT is a key partner in making incremental MES improvements work alongside legacy controls, rather than forcing risky wholesale replacement.

    7. Governance and ownership clarity

    Finally, MES sits at the intersection of operations, quality, and IT. Clear roles are important:

    • Operations and quality typically own process design, content, and usage
    • IT typically owns infrastructure, security, and core integration services
    • Shared governance is needed for change control, prioritization, and incident handling

    When IT is engaged early and treated as a strategic partner, MES is more likely to be supportable, secure, and auditable over its lifecycle. When IT is bypassed, MES may work in the short term but becomes a fragile, high-risk dependency as the surrounding systems evolve.

  • How are access and changes to digital work instructions audited?

    Access and changes to digital work instructions are typically audited through a combination of role-based access control, system-generated audit trails, and formal change control workflows. How robust this is in practice depends on your WI platform, its integration with identity and QMS/PLM systems, and how tightly you configure and validate it.

    What should be auditable for digital work instructions

    In a mature setup, you should be able to produce evidence for at least the following:

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

    • Who can see which instructions: role, group, or individual-based access rights and when those rights were granted/changed.
    • Who edited content: every change to text, media, parameters, or logic, with user ID, timestamp, and rationale or change request reference.
    • Version history: complete lineage of revisions, including what changed between versions and who approved each release.
    • Publication & effective use: when a version was issued, which work centers/lines it applied to, and when it was superseded or retired.
    • Operator access and execution: which users viewed or executed a given instruction, when, and on which order/serial/lot (where integrated with MES or travelers).

    Access control and identity integration

    Access auditing starts with identity and authorization:

    • Central identity: Integration with Active Directory/Entra ID or similar allows the system to record a unique, managed identity for each action instead of generic logins.
    • Role-based access control (RBAC): Permissions are typically defined by role (operator, manufacturing engineer, quality engineer, approver, document control), then refined by cell, program, product line, or site.
    • Least privilege: Only designated roles can author, edit, or approve; operators typically have view-only access to released versions.
    • Access-change logs: Changes to roles, groups, and user privileges should themselves generate audit events (who changed which permission, when, and why).

    In brownfield environments, WI tools often coexist with legacy MES/PLM. If you maintain separate role models in each system, auditing access becomes fragmented. Where possible, align WI access with existing MES or PLM role structures and central identity to avoid gaps.

    Change control and version governance

    For regulated operations, WI changes should follow the same discipline as any controlled document:

    • Draft & edit logs: Each save event records user, timestamp, fields changed, and (ideally) a link to a change request, deviation, or CAPA record.
    • Approval workflows: Promotion from draft to released state requires defined approvers. The system should capture who approved, their role, timestamps, and any comments.
    • Immutable versions: Once released, content and metadata for that version should be read-only. Corrections create a new version, not a silent edit.
    • Effective date and scope: The system records when a version becomes effective, which products/operations/lines it applies to, and when it is withdrawn.
    • Redline/compare capability: Ability to show a redline between versions for audits and investigations, even if this is generated on-demand from the audit trail.

    Where WIs are authored in a point solution but governed by a corporate PLM or document control system, you will need clear ownership: which system is the “record of truth” for versions and approvals, and how references or copies are synchronized.

    Audit trails and evidence for regulators and customers

    A well-configured WI platform should generate machine-readable audit logs for at least:

    • Authentication events: logons/logouts, failed login attempts, account lockouts.
    • Authorization events: changes to roles, groups, and entitlements.
    • Configuration changes: modifications to workflow settings, approval rules, or integration endpoints.
    • Document lifecycle events: create, edit, submit for approval, approve, reject, release, supersede, retire, and restore.
    • Operational usage: which WI version was presented to which user, for which work order/lot/serial, and at what time.

    For audits or investigations, you should be able to:

    • Show that only authorized personnel could edit or approve instructions.
    • Prove which WI version was in effect for a given job, serial, or lot.
    • Trace a particular change back to a request, deviation, or CAPA when applicable.

    Whether this is achievable without heavy manual work depends on integration quality between your WI system, MES, PLM, and QMS. In many plants, this evidence is still reconstructed from a mix of electronic logs, PDFs, and email; moving to digital WIs does not automatically solve this unless the process is deliberately designed.

    Coexistence with MES, PLM, and QMS

    In brownfield, long-lifecycle environments, work instructions often span multiple systems:

    • PLM or PDM may own the engineering source of the instruction or reference documents.
    • WI platform or MES may host the operator-facing version integrated into travelers or work centers.
    • QMS may host change control, deviation, and training records tied to WI updates.

    Full replacement of these systems just to centralize auditing is rarely realistic because of validation burden, requalification risk, and downtime. A more practical pattern is:

    • Define a single system of record for WI versions and approvals.
    • Use interfaces or controlled exports so other systems reference the correct version.
    • Ensure each system exposes its own audit trail and that key identifiers (document ID, revision, change request number) are consistent across systems.

    This approach adds integration and governance work but limits disruption to validated systems and established workflows.

    Common gaps and failure modes

    Even with digital WIs, several gaps show up frequently in audits:

    • Shared or generic accounts: Operators logging in under a shared user, making it impossible to attribute actions to individuals.
    • Partial audit coverage: Viewing and editing are logged, but access-rights changes or configuration changes are not.
    • Uncontrolled offline copies: Printed or exported WIs are used on the floor without clear controls or re-certification when the master changes.
    • Shadow workflows: Engineers bypass formal change control by using ad-hoc “temporary” instructions that are not traceable.
    • Broken cross-system traceability: MES shows WI rev B, the WI tool shows rev C, and the QMS record points to an obsolete change request.

    Addressing these requires both technical controls (access control, logging, integration) and procedural controls (training, governance, periodic internal audits).

    Practical steps to strengthen WI auditing

    To improve how access and changes are audited in your environment:

    1. Inventory WI touchpoints: Identify where WIs live and where they are referenced (PLM, dedicated WI tools, MES, ERP, QMS).
    2. Map roles and access: Define which roles can view, edit, approve, and administer WIs, and ensure this is enforced consistently across systems.
    3. Enable and validate audit logging: Confirm that each key event is logged, logs are protected from tampering, and retention aligns with regulatory and customer requirements.
    4. Link WIs to orders and product history: Where possible, capture the WI version against the work order/lot/serial to support traceability and investigations.
    5. Test with internal audits: Periodically run scenarios (e.g., “show me who changed this WI and which version was used on this lot”) to confirm the evidence trail is complete and practical to assemble.

    Ultimately, how access and changes are audited is less about a single tool and more about disciplined configuration, integration, and governance across the systems you already have in place.