Production Planning: What Runs, In What Order, On Which Asset
Discipline 7 of fourteen. This is where ProAlert™ holds the masters that everything else resolves against: the products and parts, the routes they travel, the stocking units they are counted in, and the shift windows and planned stops that give the schedule its shape.
The bottom line: Most of what this discipline does is invisible until something else needs it. The route step decides which work instruction an operator is shown and which materials appear on a floor request. The planned downtime record decides whether a stop counts against Availability. Planning is the layer that makes the other thirteen disciplines context-aware instead of generic.
Product, Part and Route Masters
The Schedule and the Floor View
Scheduling in ProAlert answers two questions that are easy to confuse: what is supposed to be running, and what is running.
| Capability | What it does |
|---|---|
| Shift schedule configuration | Named shift definitions with start, stop, duration and days of week, with per-asset overrides for the line that only runs Monday to Thursday. Covered in depth on shift management, because it is also what gives OEE its denominator. |
| Schedule HUD (Heads-Up Display) | A real-time visual of asset status across every configured shift. Who is running and who is not, on one floor-facing screen. This is the view that surfaces an asset scheduled to run that has not started. |
| Planned downtime scheduling | Breaks, lunches, changeovers and scheduled maintenance windows recorded as planned stops rather than discovered later as unexplained gaps. |
| Production notes | Context attached to the run itself, so the reason a shift went the way it did is on the record rather than in somebody's memory at the morning meeting. |
| Any number of shifts | Schedule entries are recorded per shift definition, for as many shifts as the plant runs. A four or five shift operation schedules all of them, the editor and the HUD draw one column per shift, and a fourth shift's normal production is no longer reported as unscheduled. |
| Shift finalization | One action turns a plan into work. Finalizing locks the die runs, releases the materials staging list, and raises the changeover work orders the adjacent die runs imply, named by the registered asset. Blocking warnings surface any unresolved discrepancy before it commits. |
| Run detail | A single production run has its own page, so "what happened on that run" is a record you can open rather than a filter you have to construct. |
| Scheduled or Kanban, per asset | Each asset runs in one of two execution modes. A scheduled asset starts the run the schedule says is next, from the tablet. A Kanban asset runs to cards instead. |
The Run Does Not Start Until It Is Ready
A production start readiness gate checks the product that will actually run next, not the last one. If a required controlled document is missing or has not been acknowledged for that asset, the run does not start and the operator is told which document is blocking rather than being left to guess. Assets carry a per-asset toggle for whether a document review is demanded before start, so the control is applied where it belongs rather than everywhere at once.
The tablet reflects the same answer: starting a scheduled run from the die-run play button either activates the run or names the blocking documents on refusal. See document control for how a document gets to that state in the first place.
Why a Planned Stop Needs a Record
A press running an eight-hour shift with two fifteen-minute breaks and a thirty-minute lunch has seven hours of planned production time. Measure it against the full clock and the asset looks 12.5% less efficient than it is. Over a month, that false baseline makes real improvement invisible.
The same distortion hits downtime analysis from the other side. When planned breaks carry no record they appear as unplanned failure events, so maintenance teams investigating root causes end up chasing "failures" that were scheduled lunches, and the failure Pareto turns into noise. Recording every planned stop fixes both at once: an honest OEE denominator, and a failure analysis made only of failures.
Kanban and Customer Records
Work in process is managed on a kanban board with a documented workflow, and cards carry the customer record the work belongs to. That last part is the one that matters in a job shop or a tiered supply relationship: when a card is late, the question is immediately "late for whom", and the answer is on the card.
The same kanban pattern runs in die-driven manufacturing for tooling work in process and in kaizen for improvement work, so a plant learns one board rather than three.
What This Is, and What It Is Not
Worth being direct about, because the category name invites an assumption. ProAlert holds the masters and the schedule that execution runs against. It is not an APS (Advanced Planning and Scheduling) engine and does not solve a finite-capacity optimization.
Plants that run a dedicated scheduler typically keep it. ProAlert's job is to execute against the plan and measure what actually happened, which is the half that usually has no system at all. Where the two need to exchange data, that runs through the REST API.
Who Uses It
| Role | What they do here |
|---|---|
| Production Planner | Shift schedules, planned downtime, kanban sequencing |
| Manufacturing Engineer | Routes and route steps, product and part masters, stocking units |
| Supervisor | The Schedule HUD, production notes, what has not started |
| Operator | Selecting the active production source at run start |
| Analyst | OEE measured against planned time rather than raw clock time |
See the schedule and the floor on the same screen.
Book a 30-minute demo... we'll put the Schedule HUD next to live asset status and show you what is scheduled but not running.
