Shop Floor Execution in D365: Production Floor Execution and Job Feedback Discipline
I closed the production scheduling article with a promise: shop floor execution, the production floor execution interface, and what good job feedback discipline does for both scheduling accuracy and costing. Here it is, and the one-sentence thesis up front: everything I wrote about scheduling percentages and standard cost variances assumes the feedback coming off the floor is true, and the floor only gives you true feedback if you make truth the easiest thing to register.
WHAT PRODUCTION FLOOR EXECUTION ACTUALLY IS
Production floor execution (PFE) is the touch-first interface D365 Supply Chain Management gives shop floor workers, the successor to the old job card terminal and job card device. Workers sign in with a badge ID or credentials on a shared terminal, see the jobs queued for their resource or resource group, and act: start a job, report progress quantity, register material consumption, report as finished, declare downtime or indirect time. The interface is deliberately configurable per terminal: a machining cell terminal can expose start/stop and quantity only, while a packaging line terminal also shows material registration and quality controls. Configure each terminal for the cell that uses it; a screen full of irrelevant buttons is how bad feedback starts.
A few setup notes worth knowing: terminals are defined as devices with their own action layout and resource filter, sign-in options support badge plus PIN, and one worker can be active on multiple jobs (bundling) when one operator genuinely runs several machines at once. If you remember the load percentage discussion from the scheduling article, bundling is its execution-side twin.
THE TWO LOOPS THAT FEEDBACK FEEDS
Every registration on the floor flows into two loops:
• The scheduling loop: started and finished jobs report actual setup and run times against the route's theoretical times. That stream of actuals is the only honest source for the resource efficiency percentages I discussed in the scheduling article. If actuals are fiction, your efficiencies are fiction, and the schedule the floor complains about is fiction of their own making.
• The costing loop: time and quantity registrations post through production journals (route card or job card) onto the production order, becoming the actual labor and machine cost that ending the order compares against the standard from the cost roll-up. Sloppy feedback lands directly in production variances that the controller then spends month-end explaining.
One stream of button presses, two financial and operational consequences. That is why feedback discipline is worth a daily article and not a footnote.
WHAT BAD FEEDBACK LOOKS LIKE (YOU HAVE SEEN ALL OF THESE)
• Shift-end batching: workers start and finish all their jobs in the last ten minutes of the shift. Quantities are right; every duration is garbage. Scheduling actuals become useless and labor cost smears across the wrong jobs.
• Ghost jobs: a job started Monday and never finished, still "running" on Thursday. WIP looks enormous, the resource looks occupied, and job scheduling keeps planning around a phantom.
• Quantity dumps: reporting the whole order quantity on the last operation only, skipping intermediate operations. Operation-level visibility disappears and scrap hides inside the dump.
• The universal indirect code: one downtime/indirect activity called "other" that absorbs forty percent of attendance time. Nothing can be improved because nothing is named.
None of these are system faults. All of them are configuration and habit faults, which is good news, because both are fixable.
CONFIGURATION THAT MAKES TRUTH EASY
• Match registration points to physical reality. If material is consumed at the start of an operation, flush it on start; if at report-as-finished, flush it there. D365's flushing principles on the BOM line (start, finish, available at location) exist exactly so consumption posts itself at the moment it actually happens, with no extra button for the worker.
• Automate what can be derived. Auto-start the next job on finish of the previous where flow is linear; let time registration come from the start/finish pair rather than asking anyone to type minutes.
• Report quantity where quantity changes. Require operation-level quantity only at operations where yield or scrap genuinely occurs (cutting, forming, inspection); pass-through operations can inherit.
• Name the downtime reasons you actually want to manage: changeover, material wait, breakdown, meeting. Five named reasons beat twenty nobody picks and one "other" everyone picks.
• Decide the attendance question deliberately: PFE can feed time and attendance for payroll, or production only. Mixing payroll into the rollout doubles its political weight; if you do not need it on day one, stage it.
THE DAILY AND WEEKLY DISCIPLINE
The configuration gets you the possibility of good data; the routine gets you the data. The pattern I recommend: a supervisor view of open jobs at every shift end, so ghost jobs die the day they are born; a weekly review of actual-versus-route times by resource, feeding corrections either to route times (if the standard is wrong) or to coaching (if the registration is wrong); and a monthly look at variance by work cell together with the controller, closing the loop with the costing article's expectations. When workers see route times corrected because of their registrations, feedback quality jumps; nothing motivates honest data like evidence that someone reads it.
TAKEAWAYS
Production floor execution is not a data entry tool; it is the sensor layer for scheduling and costing. Configure each terminal to its cell, let flushing principles and auto-start register what can be derived, demand quantities only where they change, and name your downtime. Then run the daily open-jobs check and the weekly actuals review, because discipline, not software, is what makes the numbers true. Good feedback makes the schedule believable and the variances explainable; bad feedback quietly poisons both.
Next time I will look at quality management in production: quality orders, where to trigger them in the flow, and what to do with the material they catch.
In this series: previous article Production Scheduling in D365: Finite Capacity, Resource Groups, and Scheduling Percentages
I closed the production scheduling article with a promise: shop floor execution, the production floor execution interface, and what good job feedback discipline does for both scheduling accuracy and costing. Here it is, and the one-sentence thesis up front: everything I wrote about scheduling percentages and standard cost variances assumes the feedback coming off the floor is true, and the floor only gives you true feedback if you make truth the easiest thing to register.
WHAT PRODUCTION FLOOR EXECUTION ACTUALLY IS
Production floor execution (PFE) is the touch-first interface D365 Supply Chain Management gives shop floor workers, the successor to the old job card terminal and job card device. Workers sign in with a badge ID or credentials on a shared terminal, see the jobs queued for their resource or resource group, and act: start a job, report progress quantity, register material consumption, report as finished, declare downtime or indirect time. The interface is deliberately configurable per terminal: a machining cell terminal can expose start/stop and quantity only, while a packaging line terminal also shows material registration and quality controls. Configure each terminal for the cell that uses it; a screen full of irrelevant buttons is how bad feedback starts.
A few setup notes worth knowing: terminals are defined as devices with their own action layout and resource filter, sign-in options support badge plus PIN, and one worker can be active on multiple jobs (bundling) when one operator genuinely runs several machines at once. If you remember the load percentage discussion from the scheduling article, bundling is its execution-side twin.
THE TWO LOOPS THAT FEEDBACK FEEDS
Every registration on the floor flows into two loops:
• The scheduling loop: started and finished jobs report actual setup and run times against the route's theoretical times. That stream of actuals is the only honest source for the resource efficiency percentages I discussed in the scheduling article. If actuals are fiction, your efficiencies are fiction, and the schedule the floor complains about is fiction of their own making.
• The costing loop: time and quantity registrations post through production journals (route card or job card) onto the production order, becoming the actual labor and machine cost that ending the order compares against the standard from the cost roll-up. Sloppy feedback lands directly in production variances that the controller then spends month-end explaining.
One stream of button presses, two financial and operational consequences. That is why feedback discipline is worth a daily article and not a footnote.
WHAT BAD FEEDBACK LOOKS LIKE (YOU HAVE SEEN ALL OF THESE)
• Shift-end batching: workers start and finish all their jobs in the last ten minutes of the shift. Quantities are right; every duration is garbage. Scheduling actuals become useless and labor cost smears across the wrong jobs.
• Ghost jobs: a job started Monday and never finished, still "running" on Thursday. WIP looks enormous, the resource looks occupied, and job scheduling keeps planning around a phantom.
• Quantity dumps: reporting the whole order quantity on the last operation only, skipping intermediate operations. Operation-level visibility disappears and scrap hides inside the dump.
• The universal indirect code: one downtime/indirect activity called "other" that absorbs forty percent of attendance time. Nothing can be improved because nothing is named.
None of these are system faults. All of them are configuration and habit faults, which is good news, because both are fixable.
CONFIGURATION THAT MAKES TRUTH EASY
• Match registration points to physical reality. If material is consumed at the start of an operation, flush it on start; if at report-as-finished, flush it there. D365's flushing principles on the BOM line (start, finish, available at location) exist exactly so consumption posts itself at the moment it actually happens, with no extra button for the worker.
• Automate what can be derived. Auto-start the next job on finish of the previous where flow is linear; let time registration come from the start/finish pair rather than asking anyone to type minutes.
• Report quantity where quantity changes. Require operation-level quantity only at operations where yield or scrap genuinely occurs (cutting, forming, inspection); pass-through operations can inherit.
• Name the downtime reasons you actually want to manage: changeover, material wait, breakdown, meeting. Five named reasons beat twenty nobody picks and one "other" everyone picks.
• Decide the attendance question deliberately: PFE can feed time and attendance for payroll, or production only. Mixing payroll into the rollout doubles its political weight; if you do not need it on day one, stage it.
THE DAILY AND WEEKLY DISCIPLINE
The configuration gets you the possibility of good data; the routine gets you the data. The pattern I recommend: a supervisor view of open jobs at every shift end, so ghost jobs die the day they are born; a weekly review of actual-versus-route times by resource, feeding corrections either to route times (if the standard is wrong) or to coaching (if the registration is wrong); and a monthly look at variance by work cell together with the controller, closing the loop with the costing article's expectations. When workers see route times corrected because of their registrations, feedback quality jumps; nothing motivates honest data like evidence that someone reads it.
TAKEAWAYS
Production floor execution is not a data entry tool; it is the sensor layer for scheduling and costing. Configure each terminal to its cell, let flushing principles and auto-start register what can be derived, demand quantities only where they change, and name your downtime. Then run the daily open-jobs check and the weekly actuals review, because discipline, not software, is what makes the numbers true. Good feedback makes the schedule believable and the variances explainable; bad feedback quietly poisons both.
Next time I will look at quality management in production: quality orders, where to trigger them in the flow, and what to do with the material they catch.
In this series: previous article Production Scheduling in D365: Finite Capacity, Resource Groups, and Scheduling Percentages
No replies yet. Be the first to respond!