How to run an APS shadow scheduling pilot

Separate a shadow pilot from production deployment

In this guide, shadow scheduling means fixing a data cutoff, generating a candidate from one set of orders, routings, resource calendars, materials, and operating rules, and comparing it order by order with the schedule the plant actually used. The candidate stays in a parallel review environment and does not become the production schedule merely because it exists.

The NIST AI Risk Management Framework calls for a documented intended scope and evaluation under conditions similar to expected use. SAP documents simulation versions that can be saved without changing the planning version, while Oracle separates schedule analysis from an explicit Release. These sources support a controlled validation method, but they do not define shadow scheduling as a universal certification or fixed algorithm.

Kavop currently reads ERP exports, spreadsheets, SQL data, existing schedules, and operating rules to generate comparable scheduling options and explain late orders, bottlenecks, and rush-order impact. The first round uses read-only inputs, and planners adjust and confirm the result. Kavop does not approve a production plan for the business or assume real-time bidirectional ERP or MES integration.

Fix the order scope, horizon, and data cutoff

The sample should be small enough for order-level review and close enough to the real problem to be informative. It can cover one work area, one planning period, or a group of orders competing for the same resources. Include routine work and relevant late orders, bottlenecks, changeovers, shortages, rush requests, or started operations, and record what the run does not cover.

There is no universal order-count threshold. Routing complexity, horizon, resource scope, and data quality determine how large one order set can be. A sample made only of clean, easy, on-time work says little about the difficult part of the plant. Passing one sample supports further validation only within that scope.

Every run also needs an extraction timestamp, time zone, source system, and file version. Order changes, receipts, downtime, or execution updates after the cutoff should be recorded as later events. If a candidate silently uses newer information and is compared with an older baseline, the team cannot tell whether the difference came from the data or the scheduling method.

Prepare six groups of minimum input data

These six groups are not a universal template. A field is required only when its corresponding constraint is part of the current review. Mark missing information as out of scope, pending, or assumed instead of silently filling it with zero. Keep the source, version, and reconciliation result for every field.

Orders, routings, resources, materials, and operating rules need to resolve to the same data cutoff. Microsoft documentation on routings and finite capacity, and Oracle documentation on material constraints and file intake, show how these objects affect scheduling in their products. They do not establish equivalent Kavop implementation.

Scope, version, and time

Record the plant or work area, sample dates, historical replay or prospective shadow mode, data cutoff and time zone, scheduling and freeze horizons, input batch, file version, exporter, and checksum.

Orders and demand

Keep pseudonymous order and line IDs, item or variant, quantity and unit, required milestone and date, the basis for priority, split rule, order and work-order status, and any committed or protected flag.

Routings and relationships

Provide the applicable routing and version, operation precedence, setup, run, cleanup, and wait times, batch or minimum transfer quantity, and any approved alternate routings, resources, subcontracting, and lead times.

Resources, capacity, and calendars

List resources or groups, capacity and eligibility, shifts, breaks, holidays, capacity units, downtime and maintenance, and existing scheduled load. State which resources use finite capacity and which constraints are relaxed for this run.

Materials and supply

When materials are in scope, provide the applicable BOM and version, usage and scrap factors, on-hand, reserved, and blocked inventory, purchase, transfer, and work-in-process supply, expected receipt and availability dates, and known shortages. Otherwise mark materials out of scope.

Rules, baseline, and actuals

Preserve sequencing and rush rules, freeze zones, authority for overtime, alternate resources, and subcontracting, the baseline schedule version and time it was issued, manual adjustments, and starts, finishes, and exceptions known at the cutoff. If changeovers are in scope, include the rules or matrix the plant actually uses. Store later actuals and shop-floor notes separately for retrospective review without backfilling the original inputs.

Reconcile the data before debating the algorithm

A first run can start with ERP exports, spreadsheets, CSV files, or other existing data. Oracle also documents loading planning data from legacy systems and third-party applications. A successful load only proves that the format passed. The team must still reconcile row counts, unique keys, order-operation links, units, date semantics, nulls, duplicates, statuses, and unmapped records.

Manual fills and default rules belong in an assumption log with a source, owner, and scope. Whether a machine time came from system master data, planner judgment, or a temporary estimate changes how the result should be interpreted. Preserve old assumptions when the next run changes them so that earlier candidates remain reviewable.

Receive only the fields needed for scheduling. Remove, replace, or isolate unnecessary customer names, contacts, prices, and free text, while stable surrogate IDs preserve order, item, and operation relationships. NIST guidance explains that de-identification can reduce risk without guaranteeing that every record is impossible to re-identify. Access, retention, and deletion responsibilities still need separate agreement.

Preserve the schedule the plant actually used

The baseline is the spreadsheet or system version the plant actually used at the data cutoff, not an ideal schedule reconstructed after seeing the candidate. Preserve its export time, version, owner, released or started work orders, and the manual changes planners had already made.

SAP documents saving a simulation without changing the planning version, and Microsoft supports different master plans for strategy simulation. Their technical objects differ, but the control principle is useful here. Baseline and candidate must remain available together so that the team can trace when an order moved, who made a decision, and where a later change began.

A baseline can contain problems and is not automatically optimal. Its purpose is to preserve the current decision and comparison point. If the shop floor changes a work order, calendar, or priority after the candidate is generated, retain the new version and reason rather than overwriting the original or leaking later information into a historical snapshot.

Compare candidates order by order on the same snapshot

Start with hard conflicts. Check operation precedence, whether concurrent load on the same finite resource exceeds its available capacity at that time, work placed outside an active calendar, material consumed before availability, and silent movement of released or started work. A constraint can count in this review only if it was represented in the pilot scope.

Then compare changes in order completion or lateness, bottlenecks, changeover time, utilization, and schedule movement. Oracle documents late work orders, late demands, changeover time, and resource utilization as analytics, and supports reviewing and adjusting operations in the Gantt chart. Bottlenecks and schedule-movement measures still need definitions for this pilot. Higher utilization is not always better, and fewer changeovers can come at the cost of delivery or stability. The business should define metrics, weights, and tolerances before seeing the result.

If the team runs a second candidate, state which strategy changed, such as rush priority, an alternate resource, or authorized overtime. Do not change the data, rules, and horizon together and attribute every difference to the algorithm. A candidate is one reviewable option, not evidence that the system found a unique global optimum.

Let planners validate the differences and evidence

The order-level difference list should explain completion or lateness changes, affected operations and resources, critical materials, movement of existing work, rules applied, and unresolved constraints. A planner can accept, reject, request more data, or revise a rule and record the reason. One aggregate score cannot replace those operating decisions.

The evidence pack should preserve scope and responsibility, data receipt and de-identification, field mapping, reconciliation, assumptions, the baseline, candidate run records, metric definitions, order-level differences, exceptions, causes, and the review decision. A later reviewer should be able to reproduce what the run knew and where human judgment entered.

A historical replay can compare a candidate with later actuals, but its inputs must include only facts available at the original cutoff. A prospective shadow run does not execute the candidate. It can test whether the data reconcile, known constraints are represented, risks are explainable, and planners can review the result, but later production outcomes cannot be attributed to an unexecuted schedule.

Decide whether to fix, repeat, expand, or stop

A first run commonly leads to one of four decisions. Fix mappings when the data do not reconcile, add inputs or narrow the claim when a critical constraint is missing, revise rules when differences cannot be explained, or expand the sample when the current scope is reviewable. Stopping is also a valid result and does not need to be presented as a customer success story.

Passing one sample does not prove a plant-wide deployment or guarantee future on-time delivery, capacity, profit, or planning-time gains. Before a controlled next stage, refresh the production state and define permissions, approval, rollback, and release. Oracle documents that Release updates execution objects, so a read-only boundary must mean no write credentials, no Release, no work-order updates, and every candidate marked pending review.

When the input scope is suitable, Kavop targets a first reviewable schedule in 7 to 10 working days. This is a target, not an unconditional SLA. The first version remains read-only and makes no automatic production write-back. Planners review the result before the business decides whether to integrate, expand the pilot, or retain its current process.