Bring a representative product, recipe, BOM, work order and equipment sequence. Include normal production, a rejected condition and a recovery case. Evaluate the workflows your plant needs, with the people who own them.
Use an isolated evaluation environment with representative records. Record the software release, configuration, integration and reporting refresh interval so results can be reproduced.
01 / Control the process specification
Recipe management
Establish which approved process values and limits a unit was made under.
Exercise: Create and approve a recipe revision under your signature policy, release a control instance to equipment, and record values inside and outside its limits. Apply a permitted override, then compare production before and after the change.
Evidence: Approval history, the equipment’s value snapshot and revision, recorded pass/fail results, and the earlier product record with its original limits intact. Check that draft recipes cannot be instantiated for production.
02 / Build with the specified components
BOM enforcement
Compare the planned composition with what is actually consumed.
Exercise: Add a valid component, an unlisted material and an excessive quantity. Leave a required component short at its assigned process. Where dynamic BOMs apply, try both a permitted serial-number pairing and the wrong unit.
Evidence: Accepted consumption and genealogy, rejected additions, the BOM Enforcement Log, and an incomplete-BOM result at the assigned process. Verify static quantities and dynamic pairing rules separately, including strict and non-strict quantity behavior.
Map required quantities to a process when station-level completeness matters. Confirm which BOM revision is effective before changing a material used in production.
03 / Connect demand to actual production
Work orders & WIP
See what has started, what has completed and what remains in process.
Exercise: Create or import an order, release it, produce good and rejected output, and reconcile its counts. Test the configured requirements for an assigned order, matching material and allowed quantity. Compare operator and supervisor actions.
Evidence: Work-order status and quantities, linked product records and WIP by operation. Document how overproduction, rework and closing an order are handled in your configuration.
04 / Enforce at the production step
Routing & production rules
Check whether the next operation is allowed and whether its result meets the configured requirements.
Exercise: Run a valid sequence, an out-of-sequence attempt, a missing required measurement and a failed limit. Test applicable expiry and rerun rules, then demonstrate the authorized recovery path.
Evidence: Check-out/check-in decisions, reason codes and product history. Verify that the operator workflow or PLC sequence honors the returned result; a software rejection alone does not physically stop equipment.
05 / Find the affected product
Genealogy, materials & inventory
Connect finished product to the material lots and components behind it.
Exercise: Receive or create a material lot, consume it into known products, trace an assembly backward, then trace that lot forward. Include supplier context, remaining quantity, units and expiry where used.
Evidence: Expected parent/child relationships, production history and reconciled consumption. Compare the affected-product list with a known sample so missing or duplicated integration records are visible.
06 / Contain and resolve a quality issue
Audits, quarantine & disposition
Turn an investigation into a controlled decision about affected product.
Exercise: Record an audit against the applicable recipe limits, identify a suspect population, review and confirm its quarantine, then test work and shipping eligibility. Complete the permitted disposition and release steps.
Evidence: Audit measurements, quarantine scope, affected units, decisions and shipping-check results. Test Hold separately from work-blocking states: a Hold blocks shipping but does not inherently prevent work.
07 / Explain production losses
OEE, downtime & alarms
Understand the availability, performance and quality losses behind the headline number.
Exercise: Use a known production window with run time, planned and unplanned stops, ideal rate, good quantity and rejects. Compare the OEE Scorecard and Loss Analysis with your expected calculation; drill into downtime, cycle time and reject detail. Review a fault Pareto and the related alarm history.
Evidence: Reconciled Availability × Performance × Quality, equipment state timelines, downtime reasons and the records behind each loss. Confirm quantity units, ideal-cycle settings, refresh timing and any equipment excluded from scoring.
08 / Get the right person involved
Process notifications
Bring a condition to its owner without requiring someone to watch a dashboard.
Exercise: Configure a publication and its audience for a relevant condition: a hold, failed inspection, recipe approval change, SPC signal, machine alarm or extended downtime. Trigger it in the evaluation environment and test plant scope, severity, cooldown and recipient preferences.
Evidence: The originating event, intended recipients, delivery timing, repeat suppression and Delivery Log outcome. Test a delivery failure as well as success. Use the channels your site configures—in-app, email, SMS or supported Teams/Slack connections.
Choose publication types available in the installed release. Some follow reporting synchronization; external channels need your accounts and configuration. A notification does not replace a machine interlock.
09 / Make the record useful every day
Reports, SPC & dashboards
Give production and Quality a shared way to examine counts, variation and exceptions.
Exercise: Run product history, WIP, yield and process-attribute reports for a known data set. Examine an SPC chart with its recipe context, filters and sample window. Save a report run, export it and show the relevant view on a dashboard.
Evidence: Counts and measurements reconciled to source records, repeatable filters, report-history links and understood refresh timing. Distinguish recipe specification limits from statistically calculated control limits.
10 / Close the production information loop
ERP & equipment integration
Agree on which system owns each identifier, quantity and status change.
Exercise: For the supported Dynamics 365 Business Central integration, import a work order and return production, material consumption and order status. Test field mappings, an unavailable endpoint and recovery in a test system. Separately verify the equipment data and completion handshake.
Evidence: Matching order and material identifiers, quantities, the message ledger, retries and duplicate handling. Scope other ERP connections explicitly; a system listed in a selector is not proof of an implemented adapter.
11 / Make changes accountable
Access, approvals & validation
Match production authority and change control to your operating procedures.
Exercise: Compare operator, supervisor, Recipe and Quality/Audit responsibilities. Test a permitted change and a denied action, then exercise the configured approval/signature policy. Review audit history, the validation library and coverage for the functions in scope.
Evidence: Role checks, signer identity, reasons for change, audit records and assigned test coverage. Where draft validation packages are used, name who reviews, executes and approves them; generated documents do not establish compliance.
12 / Check the answer against its evidence
Optional AI assistance
Evaluate whether report-based assistance makes a real investigation easier.
Exercise: Ask a representative production or quality question, follow the cited report runs and compare the answer with a known result. Repeat with a restricted user and review provider, outbound-data and memory settings.
Evidence: Inspectable sources, observed access boundaries, permitted outbound context and a human-reviewed answer. Core production and reporting remain available without an AI provider. Review AI capabilities and release status →
These are evaluation scenarios based on documented capabilities, not pre-executed validation tests. Demonstrate the installed release, configured rules and connected systems that you intend to use.
