A production progress tracking template: orders, operations and exceptions
A progress tracking template earns its place not by the number of fields but by whether it answers three questions in ten minutes: which order will be late, which operation is holding it up, and who acts today. If it cannot, the sheet is a log. The four-block layout below turns the log into a scheduling tool.
Decide which level you track
Progress can be tracked by order, by operation or by workstation. The uses differ: orders show delivery risk, operations show bottlenecks, workstations show load on people and machines. The common failure in smaller plants is not a lack of tracking but a mismatch between the level tracked and the question asked — totals by order only, with the bottleneck discovered at month end.
The sound arrangement is two levels together: orders as the main rows, operations expanded beneath. Order level serves customer commitments, operation level serves internal scheduling. Fields must reconcile across the two — same order number, same quantity — or the roll-up needs manual checking again.
The four blocks
Order header. Order number, customer (a code is fine), product code, total quantity, promised date. This block sets priority, and the promised date is the one field that cannot be missing.
Operation rows. Operation name, planned start and finish, actual start and finish, completed quantity, work in progress. An actual start time is what lets you say "two days late"; a completion figure alone only says how much remains.
Exception column. Days late, cause category, owning role, action taken, expected recovery date. Use fixed categories — material shortage, equipment, quality, staffing, process change, customer change. Six covers most cases.
Today's actions. Three at most, each stating who does what and when the result is due. This block is the exit of the whole sheet; without it the data above is only a ledger.
Fields and the questions they answer
| Block | Key fields | Question answered |
|---|---|---|
| Order header | Order number, product code, quantity, promised date | Where does priority come from; how bad is a late delivery |
| Operation rows | Operation, planned and actual start and finish, completed, WIP | Where it stuck; lateness in days rather than "a bit slow" |
| Exception column | Days late, cause category, owning role, expected recovery | Who owns it, why, and when it can be recovered |
| Today's actions | Action, owner, due time | Whether anything moved today |
Two details make it work. Cause categories stay fixed, and the owner is written as a role rather than a name: names break the record when people move, roles transfer responsibility at hand-over. Fixed categories also make questions like "what caused most of this month's delays" answerable at all.
Update rhythm
Plan and completion update once a day, before the morning meeting. Exceptions update immediately: whoever finds one logs it. Mix the two rhythms and exceptions get filled in at night, so the morning meeting discusses yesterday's problems.
To keep immediate entry from becoming a burden, the exception form can carry four fields only: order number, operation, cause category, expected recovery. Detail is filled in at the weekly review. The lower the threshold, the more likely it is actually done.
Three common failures
- Tracking totals instead of operations. Every order shows a progress percentage, and then the percentage collapses in the final days once one operation jams. Operation-level data is the only way to see it early.
- Plans without actual start times. Everyone has a planned finish, nobody records the actual start. Without it you cannot distinguish "not started" from "started and stuck", and those need opposite responses.
- Exceptions that never close. A cause is recorded without an owning role or a deadline, so the same exception sits on the sheet for two weeks. Closure has one test: every exception has a next review date.
When to move beyond a template
Three signals that a spreadsheet is no longer enough: more than thirty or forty live orders and rows start getting missed; five or more people editing, and versions diverge; a need to see trends by operation over time, which a sheet cannot show.
The 14th Five-Year Plan for Intelligent Manufacturing Development, issued by eight departments on 28 December 2021, set the goal that by 2025 seventy percent of manufacturing enterprises above designated size would have achieved basic digital and networked operations, with more than five hundred demonstration smart factories built. Transparent progress is the earliest and most frequently skipped step on that path — it needs no new equipment, only plans, actuals and exceptions recorded on one sheet.
If your progress sheet is filled diligently and you still chase status by phone, send it to us (contact) and we will tell you whether the gap is operations granularity, exception closure or update rhythm. To see orders, operations and exceptions on one screen, look at the T001 manufacturing AI service centre.
In one line: make the sheet answer which order, which operation and who acts today before changing software.
FAQ
- Which fields belong in a progress tracking template?
- Four blocks: an order header (order number, customer, due date, total quantity), operation rows (operation, planned start and finish, actual start and finish, completed quantity), an exception column (days late, cause, owning role, action taken) and today's actions (the three things that must move today). Trim fields if you like, but drop a block and the sheet becomes a log.
- Should the sheet be ordered by order or by operation?
- Depends on the question. Which order will be late is an order question; where the bottleneck sits is an operation question. Most plants keep one dataset with two views: orders as the main rows with operations expanded beneath, and a weekly roll-up by operation.
- How often should it be updated?
- Plan and completion daily, exceptions immediately. The test is simple: if a delay only shows up the next day, the sheet can review the past but cannot schedule the present. The person who spots an exception should log it on the spot, not a statistician at night.
- We use a template and still deliver late. Why?
- Usually not the template. Three gaps: tracking totals but not operations, so the sticking point is invisible; recording plans without actual start times, so no deviation can be computed; logging exceptions without an owning role and a deadline, so they are noted but never closed. Fix the three before changing tools.