Connect981 – Content Dev

RSC Cluster: Digital Work Instructions and Training

The Digital Work Instructions and Training cluster defines how aerospace manufacturers move from static documents to governed, executable work instructions that actually run the shop floor. It breaks down the difference between SOPs, standard work, and work instructions, then shows how digital WI systems reduce variation, training gaps, and tribal interpretation. The content focuses on approval workflows, revision control, operator signoff, and evidence capture, making work instructions part of execution rather than a compliance afterthought. Across the series, readers see how digital work instructions become the backbone for training, traceability, quality events, and continuous improvement rather than isolated PDFs living in a document system.

  • How should we treat digital work instruction systems in our zone model?

    Digital work instruction (DWI) systems usually need their own place in a zone model, rather than being hidden inside generic “MES” or “office IT” buckets. Where you place them depends on where they run, what they connect to, and how critical their content is for safety and quality.

    1. Treat DWI as a distinct application tier

    In most regulated manufacturing environments, DWI should be modeled as a separate application/service zone, not just a feature of an MES or a generic IT web app. This is because DWI often:

    • Feeds operators with step-by-step instructions that directly affect product quality and safety.
    • Integrates with MES, ERP, PLM, and QMS for routing, versioning, and training records.
    • May run on shared terminals or hardened workstations inside production areas.

    Creating a dedicated “Digital Work Instructions / Operations Apps” zone helps make data flows, trust boundaries, and validation obligations visible and easier to manage.

    2. Decide whether DWI is in OT, IT, or a DMZ-like middle tier

    Where the DWI zone sits relative to IT and OT will depend on your architecture:

    • IT-aligned zone: When DWI is a cloud or data-center web app accessed via standard browsers and does not directly control equipment, it typically belongs in an IT application zone, with tightly controlled connections into OT.
    • Intermediate / DMZ-like zone: When DWI terminals are physically in production areas and also interface with MES, historians, or equipment data, it is often safer to treat DWI as an intermediate zone between corporate IT and control-level OT.
    • OT-adjacent zone: If the DWI system is deeply coupled to MES and is used for lot/serial disposition, electronic sign-offs, or interlocks with equipment recipes, it should be modeled closer to OT and governed with OT-level change control and validation.

    The same product can appear in different zones at different plants, depending on how it has been deployed and integrated. The zone model must reflect the actual implementation, not the vendor’s marketing diagram.

    3. Model operator access separately from the backend

    Separate the user access layer from the DWI service itself:

    • Access layer: Thin clients, tablets, HMIs, shared workstations, and badge readers in production areas. These often belong to a “shopfloor client” or “operator access” zone, with stricter physical and network controls.
    • Service layer: The DWI backend (on-prem or cloud) where instructions, versions, and templates are authored, stored, and integrated.

    This separation lets you treat shopfloor devices like OT-adjacent endpoints, while still managing the DWI application as an enterprise service, subject to document control, cybersecurity, and validation requirements.

    4. Consider data sensitivity and regulatory exposure

    Placement also depends on what the DWI content and logs contain:

    • Technical data and export controls: If instructions embed controlled technical data (e.g., defense, aerospace, dual-use content), the zone should respect export control and access segregation policies.
    • GxP or aerospace traceability: If DWI is used to demonstrate compliance (e.g., versioned instructions tied to batch/serial execution, operator sign-offs), then the DWI zone must align with your validated system and record retention boundaries.
    • Personal data: If operator identifiers, training records, or biometric logins are stored, integrate privacy requirements into the zoning and logging model.

    When DWI contributes to the official manufacturing record, you should treat it as part of your regulated application landscape, not as a lightweight productivity app.

    5. Reflect brownfield coexistence, not a theoretical greenfield

    In brownfield plants, DWI often coexists with:

    • Legacy MES and paper travelers.
    • Multiple document control systems and shared drives.
    • Vendor-specific instruction tools on CNCs, PLC HMIs, or test stands.

    In the zone model, this usually results in:

    • A DWI application zone.
    • Several existing OT vendor islands (machine HMIs, proprietary instruction viewers).
    • Bridging flows between DWI and MES/QMS/PLM for versioned content and traceability.

    Do not assume you can collapse all existing instruction mechanisms into a single new DWI zone quickly. Full replacement strategies often fail in regulated environments because of validation cost, downtime risk, vendor lock-in on critical equipment, and the difficulty of requalifying processes that rely on embedded instructions.

    6. Define and document interfaces explicitly

    Once you have a distinct DWI zone, define its interfaces clearly:

    • Upstream: PLM, engineering change systems, and document control for approved instruction content and versions.
    • Lateral: MES, QMS, LIMS, and training systems for routing, sign-offs, deviations, and training status checks.
    • Downstream: OT data, equipment states, and optionally recipe IDs, so that instructions can be context-specific without allowing DWI to directly control equipment.

    Each interface should have defined data ownership, change control procedures, and validation/qualification impacts, especially where instructions and execution records are used as compliance evidence.

    7. Practical zoning patterns you can adopt

    Common, workable patterns include:

    • Pattern A: IT application with OT-facing clients
      DWI backend in an application zone next to MES and QMS; operator terminals in a shopfloor client zone bridged via a controlled network segment. Suitable when DWI is not safety-critical and has no direct equipment control.
    • Pattern B: MES-adjacent regulated application
      DWI grouped with MES in a “regulated manufacturing applications” zone, with shared validation, audit trails, and change control. Operator access devices still modeled in a separate OT-adjacent zone.
    • Pattern C: Transitional dual systems
      DWI and legacy instruction mechanisms (paper or machine-local tools) both present. The zone model shows both, with clear scoping so audits and investigations can understand which instructions and records apply to which lines and timeframes.

    Select the pattern that best matches your current deployment, and evolve it as you phase in or retire systems. Do not move a DWI system closer to OT in the model without understanding the resulting validation, cybersecurity, and change control burden.

    8. What to avoid

    • Treating DWI as “just a website” in a generic office IT zone when it is used on the shopfloor for regulated work.
    • Letting DWI become a hidden integration hub for MES, QMS, and equipment without modeling that consolidation in the zone diagram.
    • Allowing DWI to write configuration or control parameters directly to OT without putting it under OT-grade controls and validation.

    Being explicit in your zone model about where DWI sits, how operators access it, and how it connects to MES, PLM, QMS, and OT systems will make security, validation, and lifecycle management more predictable and auditable.

  • How do we capture expert tips from senior technicians into digital instructions?

    Capturing expert tips from senior technicians and embedding them in digital work instructions is more about process and governance than a specific tool. In regulated, long-lifecycle environments, you need a repeatable method that respects validation, traceability, and existing MES/PLM/QMS systems.

    1. Decide what types of “tips” you will capture

    Not every expert shortcut belongs in a standard instruction. You should define categories up front, for example:

    • Critical know-how: steps that materially affect safety, quality, or compliance and must be standardised.
    • Preferred techniques: methods that reduce rework, setup time, or tooling wear, but do not change the technical requirement.
    • Contextual hints: clarifications, photos, or notes that help new operators interpret ambiguous prints or specs.

    This hierarchy matters for change control. Critical know-how usually needs formal engineering or quality approval and may need to be reflected in PLM or controlled specifications, not just in a local work instruction.

    2. Use structured interviews, not informal conversations

    Senior technicians often cannot easily articulate what makes them effective. A structured capture process helps:

    • Trigger-based interviews: run short sessions when a new product launches, a recurring defect appears, or a handoff from a retiring technician is planned.
    • Observation-based capture: record video or annotated photos of the technician performing the task, then decompose into steps and tips.
    • Standard question set, such as:
      • “Where do new operators most often get stuck?”
      • “What do you look at or listen for to know it’s right?”
      • “What is the easiest way to do this wrong?”
      • “Which gauges, fixtures, or tools do you trust for this step and why?”
      • “What do you check before moving to the next operation?”

    In a regulated setting, avoid capturing personal workarounds that conflict with drawings, procedures, or validated methods. Those should trigger potential improvement or change requests, not be added directly as instructions.

    3. Separate raw knowledge capture from approved content

    To avoid corrupting controlled instructions, treat capture and publication as two distinct stages:

    • Capture space: a sandbox (could be within your digital WI tool, an engineering notebook in PLM, or a controlled SharePoint) where videos, notes, and sketches live as “draft” ideas.
    • Structured templates: use a standard template for converting raw tips into instruction content (step description, risk, photo/video, measurement, acceptance criteria).
    • Review workflow: engineering, quality, or process owners decide whether a tip becomes:
      • A change to a formal process spec or drawing.
      • A standard work instruction update.
      • A non-standard hint or training-only material.

    This avoids bypassing design authority or introducing undocumented process variation.

    4. Embed tips in the right place within digital instructions

    Once vetted, tips should be embedded in a way operators can actually use, without undermining standardization:

    • Step-level annotations: attach notes, images, or short clips to specific steps instead of general text blocks.
    • Conditional guidance: configure tips to appear only when certain variants, tools, or materials are used, if your platform supports it.
    • Visual cues: photos of “good” and “bad” outcomes, tool positions, or fixturing, rather than vague text like “ensure proper alignment”.
    • Checklists: convert critical tips into required confirmations (check boxes, measurements, torque values) that are recorded for traceability.

    The depth of integration depends on your WI platform and how it connects to MES and PLM. In brownfield environments, you may be limited to PDFs or HTML pages referenced from the traveler rather than deeply interactive content.

    5. Respect change control, validation, and traceability

    In aerospace and other regulated sectors, “just updating a work instruction” is rarely trivial:

    • Change requests: expert tips that affect process parameters, sequence, or tools often require formal change requests, risk assessment, and potentially re-validation.
    • Version control: ensure tips are part of the controlled WI revision, with clear effective dates and linkage to the relevant part numbers, routings, or work orders.
    • Approval routing: maintain an auditable trail showing who approved each change and the rationale (e.g., CAPA, FAI findings, scrap reduction project).
    • Training linkage: when a new tip changes how work is done, link it to training events or acknowledgments, especially for safety- and quality-critical steps.

    Be explicit with technicians: tips that change how conformance is achieved must be treated as engineering or process changes, not casual advice.

    6. Start small and prove value before scaling

    Trying to capture everything at once usually fails due to technician fatigue and limited documentation resources. Instead:

    • Prioritize 5 to 10 high-impact operations where scrap, rework, or onboarding time is painful.
    • Instrument the baseline (defect rates, cycle time, rework, help calls) before changes.
    • Capture and integrate expert tips for those operations using the structured process above.
    • Measure impact and feed results into your continuous improvement program (e.g., tie to RCCA, COPQ tracking, or Kaizen events).

    This makes the effort more credible to technicians and leadership and helps justify the time senior experts spend documenting their knowledge.

    7. Coexist with existing MES, ERP, PLM, and QMS

    In most plants, you cannot replace existing systems just to improve work instructions. Instead:

    • If you have a digital WI platform: Configure it as the source of operator-facing instructions, but maintain authoritative design and process definitions in PLM or controlled specs. Integrate via links, APIs, or controlled document IDs.
    • If WIs live in MES or ERP: Use structured templates (Word/PDF/HTML) that can be attached to operations. Build your expert-tip process around updating those templates under existing document control workflows.
    • If you are still paper-based: Start with controlled digital masters (in QMS or PLM) that generate printed travelers. Capture expert tips into the master documents and roll them out through normal revision cycles.

    Full replacement of MES or PLM solely to improve instructions is usually not viable due to validation burden, integration complexity, downtime risk, and the need to maintain historical traceability. Layering a focused WI solution or better templates on top of existing systems is typically less risky.

    8. Create incentives and make it easy for technicians

    Senior technicians are busy and skeptical. Adoption improves when you:

    • Minimize friction: allow voice notes, quick photos, or brief video capture at the station, then have engineering/process staff do the structuring.
    • Recognize contributions: track whose tips led to improved yield or reduced rework, and recognize that in performance reviews or local awards.
    • Close the loop: show technicians how their input changed the official instructions and the measured impact on defects or training time.

    If the process feels like one-way extraction with no visible results, senior technicians will disengage.

    9. Practical implementation pattern

    A pragmatic, low-risk pattern many plants use:

    1. Select a few high-variation operations with senior experts and recurring issues.
    2. Run structured shadowing sessions, capturing video and notes.
    3. Convert observations into proposed WI changes and annotations using a standard template.
    4. Route through engineering/quality for approval under existing document control.
    5. Publish updated digital WIs (or controlled PDFs) via MES/ERP/PLM links.
    6. Track before/after metrics and use results to refine the capture process.

    This respects brownfield constraints, avoids unvalidated process drift, and builds a repeatable model for capturing expert tips at scale.

  • digital work package

    A digital work package is an electronic set of work documents, instructions, forms, and related records assembled to support a specific job, work order, batch, maintenance task, or production operation. It commonly refers to a controlled package of information used by supervisors, operators, technicians, inspectors, or approvers to carry out work and capture execution data.

    In manufacturing and regulated operations, a digital work package may include routing steps, work instructions, specifications, drawings, parts lists, checklists, permits, inspection points, data collection forms, approvals, attachments, and completion records. The package is usually presented through software rather than paper, and may connect to MES, ERP, EAM, QMS, or document control systems.

    The term includes both the content needed to perform work and the record created as that work is executed. It does not mean any single document by itself. For example, a standalone PDF procedure or a single electronic form is usually only one element of a broader digital work package.

    How it is used in operations

    A digital work package typically organizes all required information for a defined task in one managed workflow. During execution, users may view current instructions, acknowledge steps, enter measurements, record material usage, attach photos, note deviations, and complete approvals. Depending on the system design, the package may also preserve timestamps, user actions, revision references, and status changes.

    Common use cases include:

    • production jobs with routing and in-process quality checks
    • maintenance activities with task cards, findings, and sign-offs
    • batch or lot execution records in regulated manufacturing
    • field service or commissioning work with evidence capture

    What it includes and excludes

    A digital work package commonly includes controlled work content, execution steps, required evidence, and completed records for a specific scope of work.

    It commonly excludes broader enterprise planning functions such as long-range scheduling, product lifecycle authoring, or standalone training content, although those systems may supply source data into the package.

    Common confusion

    Digital work package is often confused with digital work instructions or digital traveler. Digital work instructions are usually the step-by-step guidance inside the package. A digital traveler usually tracks the movement and status of a job through operations. A digital work package is broader and may contain both of those elements along with forms, approvals, specifications, and execution records.

    It can also overlap with terms like electronic batch record, electronic device history record, or maintenance task package. Those terms are usually more domain-specific, while digital work package is a broader operational term.

  • User interface (UI)

    User interface (UI) commonly refers to the visible and interactive part of a software system, device, or machine that a person uses to view information, enter data, and trigger actions. It includes screens, menus, buttons, forms, icons, labels, and other controls that shape how a user interacts with the underlying application or equipment.

    In manufacturing and regulated operations, a UI may appear in MES screens, ERP forms, electronic work instructions, quality records, HMIs, maintenance applications, dashboards, and mobile operator apps. The UI presents information from the system and captures user input, but it is not the same thing as the business logic, database, workflow engine, or system integration behind it.

    What it includes

    • Visual layout of screens and pages
    • Input fields, buttons, menus, filters, and navigation
    • Status indicators, alerts, prompts, and messages
    • Role-based views for operators, supervisors, quality staff, or maintenance teams
    • Device-specific presentation such as desktop, tablet, panel PC, or handheld screens

    What it does not mean

    UI does not usually mean the full user experience, training approach, or process design. It also does not mean the underlying application architecture or data model. In OT environments, UI can overlap with an HMI, but the terms are not always interchangeable. An HMI usually refers more specifically to the operator-facing interface for controlling or monitoring industrial equipment, while UI is the broader term for any human-facing software interface.

    Common confusion

    UI vs. UX: UI is the interface itself, while UX refers to the broader experience of using the system, including clarity, efficiency, and ease of completion.

    UI vs. HMI: HMI is typically used for machine or process interaction in industrial settings. UI can refer to HMIs, but also to enterprise and shop floor software screens that are not direct machine controls.

    UI vs. front end: Front end often refers to the technical implementation layer of the interface. UI refers to the human-facing interface as used and seen.

    How it shows up operationally

    In day-to-day workflows, the UI is where users acknowledge tasks, review work instructions, enter production data, record inspections, sign off steps, or investigate exceptions. For example, an MES UI might show routing steps, required material lots, and data entry prompts for in-process checks, while a quality UI might present nonconformance details and disposition fields.

  • task card

    A task card commonly refers to a document or digital record that defines a specific unit of work to be performed, usually by an operator, technician, inspector, or maintenance worker. It typically identifies the task, the sequence of steps, applicable parts or equipment, required tools or materials, and any data that must be recorded during execution.

    In manufacturing and regulated operations, a task card is used to communicate what work is authorized, how the work should be carried out at a practical level, and what evidence or signoff may be needed when the task is complete. It can exist on paper or within systems such as MES, MRO, EAM, or digital work instruction platforms.

    A task card is not the same thing as a high-level production order, work order, or job traveler, although it may be generated from or linked to those records. A work order usually authorizes a broader package of work, while a task card often breaks that work into a discrete, executable activity.

    What a task card usually includes

    • task identifier or reference number

    • description of the work to be performed

    • step-by-step instructions or checkpoints

    • required tools, materials, or parts

    • applicable drawings, procedures, or revisions

    • inspection, verification, or signoff fields

    • time, quantity, or completion status fields where relevant

    Operational meaning

    Operationally, task cards are used to control execution on the shop floor or in maintenance environments. They help tie planned work to actual work performed by capturing who did the work, when it was done, what instructions were followed, and what results or exceptions were recorded. In digital systems, task cards may also support routing enforcement, revision control, traceability, and electronic signatures where those features are configured.

    Common confusion

    Task card vs. work order: a work order generally covers the broader authorization and scheduling of work, while a task card covers a specific task within that scope.

    Task card vs. traveler: a traveler usually follows a part or job through multiple operations, while a task card is often focused on one defined activity or maintenance action.

    Task card vs. work instruction: a work instruction describes how to perform work. A task card may include or reference work instructions, but it also serves as the execution record for that specific task.

  • Operator guidance

    Operator guidance commonly refers to the instructions, prompts, cues, and contextual information provided to a machine operator, assembler, technician, or shop floor user while work is being performed. Its purpose is to help the person execute a task in the intended sequence, with the right parameters, materials, checks, and documentation.

    In manufacturing and regulated operations, operator guidance can appear in paper or digital form. Examples include step-by-step work instructions, visual aids, setup parameters, inspection prompts, tool selection cues, warnings about missing prerequisites, and confirmation steps in an MES, eDHR, or digital work instruction system.

    The term includes information presented at the point of use or close to the time of execution. It does not usually mean general training by itself, and it is not the same as a policy, standard operating procedure, or engineering specification, although those documents may feed into operator guidance.

    What it includes

    • Task-specific instructions for production, inspection, maintenance, or material handling

    • Visual or interactive work steps, including images, videos, or AR overlays

    • Process limits, required fields, and prompts for data capture

    • In-process quality checks and sign-off or acknowledgment steps

    • System-driven messages based on product, routing step, equipment, or user role

    What it excludes

    • Broad classroom training or onboarding not tied to a live task

    • High-level procedures without execution detail at the point of use

    • Informal tribal knowledge that is not documented or delivered in a controlled way

    Operational meaning

    Operationally, operator guidance is often embedded in execution workflows. A system may present the correct instruction revision for a specific work order, require completion of prior steps, prompt for measurements, or block progression when required information is missing. This makes the term relevant to MES, electronic records, traceability, and document-controlled production environments.

    Common confusion

    Operator guidance is often confused with work instructions. Work instructions are a major form of operator guidance, but the term operator guidance is broader. It can also include dynamic prompts, conditional logic, contextual alerts, and system-enforced checks during execution.

    It is also sometimes confused with operator training. Training builds competence over time, while operator guidance supports task execution in the moment. In practice, the two are related but not interchangeable.

  • Job Aids

    Job aids are concise reference tools that help workers perform specific tasks correctly at the point of use. They are designed to supplement, not replace, formal training by providing just enough information to complete a job step or workflow without relying on memory.

    What job aids include

    In industrial and regulated manufacturing environments, job aids commonly appear as:

    • Step-by-step task checklists
    • Quick-reference guides or cue cards
    • Decision trees or flowcharts for selecting the right action
    • Troubleshooting guides for equipment, quality issues, or alarms
    • Parameter look-up sheets, torque charts, or setup matrices
    • Visual aids such as annotated photos, diagrams, and examples of conforming vs nonconforming conditions
    • On-screen prompts or in-app guidance embedded in MES, QMS, or digital work instruction systems

    Job aids are usually focused on a narrow task or decision, are easy to scan quickly, and are kept close to where work is performed, such as at a workstation, inspection bench, or maintenance area.

    How job aids are used in operations

    On the shop floor and in support functions, job aids commonly support:

    • Executing standard work steps in assembly, machining, test, or repair
    • Performing inspections, measurement routines, and recording results
    • Setting up or changing over equipment according to defined parameters
    • Handling nonconformances, deviations, or special process conditions
    • Following safety, lockout/tagout, or contamination-control steps
    • Navigating software workflows in MES, ERP, QMS, or PLM systems

    In regulated environments, job aids often need to be controlled documents: versioned, reviewed, and approved under the organization’s document control or work instruction governance processes so that only current information is available at the point of use.

    Common confusion

    • Job aids vs work instructions: Work instructions usually define the complete, detailed method for performing an operation or process. Job aids are typically shorter, more focused references used within or alongside those instructions (for example, a torque chart used in a fastening step defined by the work instruction).
    • Job aids vs training materials: Training materials are used during learning events (classroom, e-learning, on-the-job training). Job aids are intended for use during actual work to support correct execution after training.
    • Job aids vs SOPs: Standard operating procedures (SOPs) describe policies and high-level procedures. Job aids usually translate parts of those procedures into concrete, task-level guidance for operators or technicians.

    Digital job aids

    Many plants implement job aids digitally within MES, electronic work instructions, or mobile applications. Digital job aids can appear as context-sensitive help, embedded images, links to troubleshooting guides, or pop-up reminders tied to specific product, revision, or operation data. In these cases, they are often integrated with document control and revision tracking to support traceability and audit readiness.

  • procedure

    A procedure is a defined, ordered set of steps that describes how a specific activity is carried out. In industrial and manufacturing environments, it commonly refers to a documented or system-encoded sequence that tells people or automated systems what to do, in what order, and under what conditions.

    Core meaning in manufacturing and regulated operations

    In regulated and industrial contexts, a procedure typically includes:

    • A clear objective or outcome (for example, complete a batch, start up a line, perform an inspection)
    • An ordered list of actions or steps
    • Roles or resources responsible for each step (operators, units, equipment, systems)
    • Inputs and outputs (materials, data, intermediate states)
    • Conditions, parameters, or decision points that govern the flow of steps

    Procedures may be:

    • Document-based, such as written operating procedures, SOPs, or test procedures maintained under document control.
    • System-based, such as workflows encoded in MES, batch control, or automation systems.

    Procedures in batch and ISA-88 contexts

    In batch manufacturing and standards such as ISA-88, a procedure commonly refers to a structured and hierarchical set of actions that defines how a batch is made. It is typically modeled in layers, such as:

    • Procedure: the overall sequence for the batch or process segment
    • Unit procedure: a subset of steps executed in a specific unit
    • Operation: a logical grouping of processing actions
    • Phase: the smallest, most detailed step, often linked directly to control logic

    In this setting, a procedure is not just a static document but a logical model that can be implemented in control systems, MES, or recipe management tools. It describes the process execution behavior rather than general policies or guidelines.

    Operational use

    On the shop floor and in supporting systems, procedures show up as:

    • Standard operating procedures (SOPs) linked to work centers, products, or recipes
    • Electronic work instructions that enforce step-by-step execution and data capture
    • Automated sequences in batch, process, or discrete control systems
    • Quality, cleaning, changeover, and maintenance workflows

    Procedures are often subject to version control, training, and periodic review, especially in regulated industries where traceability and consistent execution must be demonstrated.

    What a procedure is not

    To avoid confusion, it is useful to distinguish procedures from related concepts:

    • It is not the same as a high-level policy or guideline, which describes intent but not detailed steps.
    • It is not just a single document describing “how the plant runs”; many specific procedures usually exist for different operations.
    • It is not the physical equipment or control hardware, although it may be executed by or on that equipment.

    Common confusion

    • Procedure vs. process: A process is the broader transformation of inputs to outputs (for example, a production process). A procedure is the defined way in which part or all of that process is carried out, often at a more detailed level.
    • Procedure vs. work instruction: Work instructions usually give more granular, operator-facing detail for a specific task (for example, torque settings, tool selection). A procedure may reference one or more work instructions as part of its steps.
    • Procedure vs. recipe (ISA-88): In ISA-88 terms, a recipe includes parameters, formulas, and other product-specific information. The procedure is the ordered set of actions within that recipe that defines the execution sequence.

    Link back to ISA-88 usage

    In ISA-88, the term procedure is used precisely for the ordered set of actions that drives how a batch is produced within the recipe model. This meaning aligns with the general definition: a structured sequence of actions, represented in a hierarchical model and typically implemented in control systems and MES rather than only as a static document.