Skip to main content

​
What ION does for you

You own the flow. ION lets you author procedures, set up work centers and locations, build the schedule, and then watch, in something close to real time, how the plan is meeting reality on the floor. When a run blocks, when a step takes 3× expected, when an operator files a redline, you see it. That’s the signal you use to tune the process, push back upstream on bad designs, and improve cycle time. Most days you’ll bounce between three things: authoring or revising procedures, looking at run progress, and handling exceptions (parts on hold, issues that need disposition, scheduling collisions).

​
Where to start

  1. Procedures: your primary authoring surface. Steps, fields, standard steps, dependencies.
  2. Runs and Execution: how the procedures you authored play out on the floor. Run states, batches, scheduling.
  3. Locations and Work Centers: the physical map of your factory. Get this right and scheduling gets dramatically easier.

​
The handful of pages that matter most

PageWhy it matters to you
Procedure Best PracticesPatterns that scale and don’t generate floor friction
Standard StepsReuse step content across procedures so you fix things in one place
Procedure Dependency ManagerWhat changes when you change a procedure, and what’s safe to change
Run BatchesLot/batch builds and their gotchas
Runs and Step StatesThe state machine you’ll be debugging when runs stall
Redlines and DeviationsThe floor’s primary signal back to you
Issues and NCRsQuality events on parts you handle every day
  • Standard steps over copy-paste. When the same instruction appears in five procedures, make it a standard step. The day you need to change it, you’ll thank yourself.
  • Watch runs, not just procedures. A clean procedure document and a messy real run are common; the gap is your improvement opportunity.
  • Treat redlines as the symptom, not the bug. A redline means the spec didn’t match reality. Fix the spec.
  • Plan for parallel work. ION’s scheduling and run-batch features assume you’ll have multiple runs of multiple parts overlapping. Lean into that, don’t model your factory as one queue.