DataVisions.ai · Requirements & Scoping

Shop Floor Execution System

Scoping document — modernizing shop-floor time tracking, work-order routing, and job costing alongside the existing ERP.

Document	Scoping & Requirements — Shop Floor Execution System (SFES)
Prepared by	DataVisions.ai — Rapid Software Solutions
Prepared for	A make-to-order & batch manufacturer (representative example)
Status	SAMPLE — representative scoping document
Version / Date	v0.2 · August 2026

1.0Executive Summary

The Customer runs a job-shop manufacturing operation on a legacy ERP. The ERP remains the system of record for orders, inventory, and financials — but two of its execution modules generate daily friction on the floor: shop-floor time tracking (how labor is captured against jobs) and work activities (the routed operations a job travels through for custom orders and batch runs).

This document scopes a Shop Floor Execution System (SFES): a modern, tablet-first application that replaces those modules one at a time, co-existing with the ERP rather than replacing it. Phase 1 delivers time capture — the transaction layer every other capability reads from. Later phases grow into travelers & routing, dispatch lists, and live job costing, using the same data model from day one.

Guiding principle Model "an operation on a job" correctly from the start. Labor, materials, and machine data all hang off the operation, not the job — the job is the roll-up. Get that right and costing, scheduling, and progress reporting fall out naturally.

2.0Current Manufacturing Flow (As-Is)

Captured from initial conversations; to be validated in the discovery workshop.

A sales order is entered in the ERP — either a custom order (engineer/make-to-order) or a batch run of a standard part.
The ERP creates a work order (the job) carrying a router: numbered operations (Op 10, 20, 30…) that route the part through the shop's work centers, including outside services such as plating or heat treat.
A traveler (printed packet) follows the parts across the floor.
Operators record labor against jobs at shared terminals — the module is slow, error-prone, and resented; supervisors correct entries after the fact.
Materials are issued to jobs manually or backflushed at completion; timing gaps distort work-in-process.
Job costing (labor × rate + materials + outside services) lags the floor by hours-to-days, so estimates rarely get compared to actuals until the job is closed.

Pain points to relieve

Clunky clock-on/clock-off experience → labor data is late and dirty.
No live view of where a job sits on its router or what a work center should run next.
Costing is retrospective, so quoting doesn't learn from actuals.
Preventative maintenance for equipment is tracked outside any system.

DataVisions.ai — Sample scoping documentPage 1

3.0Concepts & Glossary

Work order (job): Authorization to produce: "Job 48213 — make 250 of part XYZ." The unit of costing and completion. Essentially a job code everything else attaches to.
Router / operations: The ordered recipe on the job: Op 10 Saw → Op 20 Mill → Op 30 Outside service → Op 40 Assembly → Op 50 Inspect. Each op names a work center, standard setup/run times, and the materials consumed at that step.
BOM (per operation): The part has one bill of materials, but every line is assigned to an operation — so each op owns its slice of materials, issued or backflushed when the op completes.
Traveler: Historically, the paper packet that follows parts through the floor. In SFES the traveler becomes a live view on each station's touchscreen — only a barcode job tag physically rides with the parts (§7.2). Paper survives solely as a print-on-demand fallback.
Work center: A station/machine group where operations execute (Saw 2, Mill 4, Assembly bench).
Dispatch list: The queue at a work center: every open job's remaining operations for that station, sorted by priority/due date — the operator's to-do list. May interleave many jobs.
Backflush: Auto-deducting an operation's material slice on completion (report 50 good parts → 50 parts' worth of material relieved), replacing manual issues.
Pegged child job: A subassembly work order created for, and linked to, a specific parent job. Costs roll up directly; full traceability.

4.0Future-State Flow (To-Be)

Fig. 1 — Future-state execution loop. Tan boxes = new SFES; cream boxes = ERP-owned today.

DataVisions.ai — Sample scoping documentPage 2

5.0Data Model

The operation is the center of gravity. Labor, material, and machine events attach to an operation on a job; the job is the roll-up for costing and completion.

Fig. 2 — Core entities. The material-line "source" field covers stocked parts, pegged subassembly jobs, and outside services with one structure.

6.0Subassembly Patterns

Both patterns must be supported; the choice is a per-part planning policy.

Fig. 3 — Subassembly supply patterns A and B.

DataVisions.ai — Sample scoping documentPage 3

7.0Functional Requirements

7.1 Time capture (Phase 1 — the wedge)

ID	Requirement	Priority
TC-001	Operators clock onto a job + operation via barcode scan, kiosk touchscreen, or tablet at the work center; clock off with quantity complete and scrap count.	MUST
TC-002	Support multiple concurrent workers on one operation and one worker splitting across operations; capture setup vs. run time separately.	MUST
TC-003	Labor rolls up by shift, job, project, work center, and department in real time.	MUST
TC-004	Supervisor correction workflow with full audit trail (who changed what, when, why).	MUST
TC-005	Indirect time codes (cleanup, meetings, maintenance) for non-job labor.	SHOULD
TC-006	Export labor to ERP/payroll on the customer's current cadence; totals reconcile to the minute.	MUST

7.2 Work orders, routers & travelers (Phase 2)

ID	Requirement	Priority
WR-001	Import work orders and routers from the ERP; jobs reference the customer's existing job and part numbering unchanged.	MUST
WR-002	Build/edit routers in SFES: sequenced operations with work center, standard times, material lines per operation (BOM slice), and outside-service steps that generate vendor POs with expected return dates.	MUST
WR-003	Station-mounted touchscreens at every work center replace the paper traveler: each shows that work center's dispatch queue and, on clock-on, the operation's instructions, drawings, specs, and photos. Completing an operation automatically surfaces the job in the next work center's queue — nothing physical is handed off.	MUST
WR-004	Backflush the operation's material slice on completion; manual issue supported as fallback.	SHOULD
WR-005	Subassemblies as pegged child jobs or through-inventory (material-line source model, Fig. 3).	SHOULD
WR-006	Job identity tags: a single-page barcode tag/label printed at job release rides with the parts between stations. Scanning it at any station pulls up the job and its current operation — the only paper that travels.	MUST
WR-007	Print-on-demand paper traveler from any browser as the fallback path — network outage, failed terminal, or Wi-Fi dead zones keep the floor moving on paper, reconciled when back online.	SHOULD

7.3 Dispatch & scheduling (Phase 3)

ID	Requirement	Priority
DS-001	Dispatch list per work center: remaining operations across all open jobs, sorted by priority and due date; operator clocks on directly from the list.	MUST
DS-002	Drag-and-drop priority overrides by supervisors; changes reflected on floor tablets immediately.	SHOULD
DS-003	Capacity view by work center (load vs. available hours); finite scheduling as a later enhancement.	COULD

7.4 Costing & reporting

ID	Requirement	Priority
CO-001	Live job cost: Σ operations (labor × rate + materials + outside services); visible while the job runs, not after close.	MUST
CO-002	Actual vs. estimate comparison at operation and job level; feeds back into quoting.	SHOULD
CO-003	Dashboards: WIP by work center, labor efficiency, on-time completion, scrap trends. Printable/exportable.	SHOULD

7.5 Platform & security

ID	Requirement	Priority
PS-001	Role-based access (operator, supervisor, scheduler, admin); operators see only their work centers by default.	MUST
PS-002	Runs on the customer's network / cloud tenant; works through brief network interruptions at floor terminals (offline queue). Print-on-demand traveler (WR-007) is the deep fallback.	SHOULD
PS-003	Full audit log on every transaction; data exportable at any time — the customer owns the data and the source code.	MUST

DataVisions.ai — Sample scoping documentPage 4

8.0ERP Co-existence & Integration

Inbound (ERP → SFES): open work orders, routers/operations, part master, BOM lines with operation assignment, work centers, employees. Nightly full sync + intraday deltas (API, file drop, or DB view — determined in discovery).
Outbound (SFES → ERP): labor entries (for payroll/GL), operation completions and quantities (for WIP), material transactions if SFES becomes the point of issue.
System of record shifts by phase: Phase 1, the ERP still owns everything and SFES pushes labor back. By Phase 3 SFES owns floor execution; the ERP keeps orders, inventory valuation, and financials.

Key discovery question Must captured labor flow back into the current ERP for payroll and GL from day one, or can costing move out with the new system? The answer sets Phase 1's integration scope.

9.0Phased Delivery

Fig. 4 — Delivery phases. Each phase ships to production and stands alone; reusable platform blueprints get each ~60% built before custom work begins.

10.0Open Questions for Discovery

How deep do assemblies nest? (Sets whether v1 needs job hierarchies or a flat model suffices.)
Is finite-capacity scheduling done in the ERP today, or on whiteboards/spreadsheets? (If the latter, the dispatch list delivers value in Phase 1.5.)
Payroll flow: which system pays operators, and on what cadence must labor reconcile?
Part/job numbering conventions to preserve; barcode standards already on travelers.
Scrap and downtime reason codes currently in use.
Outside-service vendors and how POs/receipts are handled today.
Floor hardware reality: existing terminals, Wi-Fi coverage, glove-friendly input needs.
Which reports leadership looks at weekly — those become the Phase 1 dashboard set.
Do any operations require a signed sign-off (customer quality clauses, AS9100/medical-style)? Sets whether per-operation e-signature is in Phase 2 scope.
Station hardware count: how many work centers need a mounted touchscreen vs. shared tablets, and where can label printers live for job tags?

11.0Assumptions & Out of Scope

The existing ERP remains the system of record for sales orders, purchasing, inventory valuation, and financials for all scoped phases.
Quoting/estimating and full MRP are out of scope (the router model is designed so estimating can attach later).
Machine/IoT data capture (machine events) is architected for but implemented only where sensors/SCADA access already exist.
Customer owns 100% of source code and data; system deploys to customer-controlled infrastructure.

DataVisions.ai — Sample scoping documentPage 5