Fix Your Work Order Process
When you're processing work orders, a substantial quantity of time can be wasted in trying to figure out which one to work on. This requires reading large quantities of work to find the most important, or to find one that a specific person can do.
With good coding practices at the work order approval/induction point, you can dramatically reduce lost time by all of the work order stations.
This article is for maintenance managers and people who use work order systems.
Most maintenance teams treat work order approval as a yes/no gate: is this real work and should we do it? That's only half the job. The other half is coding the order so everyone downstream can act on it without having to read or make decisions redundantly.
There aren't a lot of people who talk about this, but planning personnel in maintenance are often very busy and they waste a lot of time trying to figure out what needs done.
So if we're looking for work to assign and plan from a list, how many times do you think each work order is read? Dozens of times?
Your objective in processing work orders should be that as an organization, reading the work order should happen as close to once as possible.
And that requires that you should mark the work order by every decision that dictates how you handle it so the rest of your process doesn't have to re-read it until they're ready to make decisions on it.
The time you win or lose in maintenance planning is decided at the approval desk, before anyone picks up a wrench. An order approved without the following 5 decisions made and encoded into the work order will consume several times as much time in planning as it should..
The standard should be: a work order is not approved until the following 5 decisions are made and entered on the work order.
Code 1: Priority Score (1–100)
How to assign it: Rate the order on a 10-by-10 matrix.
Equipment criticality (1–10): How important is this asset to the operation? (this requires that you make a "criticality list".)
Problem severity (1–10): How bad is the condition right now?
Multiply them. The result is a priority score from 1 to 100.
Why it saves time: Without a score, planners re-read the whole backlog every time they plan to figure out what matters most. With a score, they sort by a number. The judgment happens once, at approval, instead of every day.
In addition to the benefits in planning, it also gives the technicians a guide as to what work should be done first when multiple orders are assigned.
With clear prioritization like this, it becomes simple to sort any group of work orders (by machine/ run condition/ whatever) and determine which one should be worked-on first.
This coding task eliminates time wasted trying to figure out which work orders a planner should plan first (and it ensures techs know the prioritization of the work assigned to them as well).
Code 2: Downtime Code
How to assign it: Tag the order with the access window the work requires.
Do-while-running: Can be done with the equipment operating.
Single-shift-down: Needs the equipment down for one shift or less.
Extended outage: Needs a shutdown longer than a shift (typically these are rare times).
Most plants have a predictable access pattern. Maybe you can get a machine down and available once a week for a single shift, but you have an extended downtime every 6 months.
If no machines are down and available for you to work, you need work to assign that can be done while the machines are running.
If you code work for when you can do it, you can easily prioritize planning for jobs that are needed to consume all of your labor.
Most weeks, you'll need the same quantity of "do while running" or "single shift down" work because most plants run weekly schedules.
The backlog, sorted by these codes, makes possible useful metrics to let you know what the planners need to plan to make sure your tech labor is used well.
Why it saves time: Without it, planners have to re-read work orders over and over to find stuff they can assign for each shift and managers have no idea which work needs to be planned to allow efficient labor utilization.
With it, we can easily manage the backlog planning to consume the labor you have.
Code 3: Time Estimate
How to assign it: Enter a rough estimate of labor hours. This is a guess made at approval, not a planned job estimate. Close is good enough.
Why it saves time: On its own, this code looks minor. Its value is in combination with the others. It turns a count of jobs into hours of work. "Twelve electrical orders" tells a planner nothing. "Forty hours of do-while-running electrical work" tells them the value of that work order in absorbing labor.
This is important to help them produce the backlog efficiently and use the team's time gainfully.
Code 4: Capability Code
How to assign it: Identify who has to do the work.
Electrical
Mechanical
Multi-tech
Programming
Why it saves time: Planners have to keep every trade loaded. Sorting the ready-to-schedule bin by capability shows instantly whether there is enough programming work, for example, to keep the programmer busy, or whether the planner needs to plan more work for that trade.
Without this code, you could plan in priority order and never realize that an entire trade is completely out of work.
Code 5: Ready to Schedule or Needs Planning
How to assign it: Just identify whether the work can be done now or if it needs more evaluation.
Most work orders will be coded "needs planning" so the planners will read them and do planning. But all those jobs will arrive in "ready to schedule" after the planning is complete.
Some jobs don't require planning, and this just jumps those jobs to the "ready to schedule" stage so they don't consume planning time.
Why it saves time: This lets the approver bypass planning entirely for work that can be executed in its current form.
What the Codes Make Possible
Plan by pulling, not by searching
With all five codes in place, planning becomes a filter: show me the highest-priority work that fits this window and these people. The planner stops hunting through the backlog (which typically requires extended periods of scrolling and reading) and starts being able to just plan what's needed.
Enforce shutdown discipline
Shutdowns are your most constrained window. The rule: only "shutdown-only work" goes into a shutdown. Anything coded "do-while-running" or "single-shift-down" belongs somewhere else and should be done outside of shutdown even if you have to move labor to do it.
You want to keep your shutdowns as simple as possible and if work can be done during routine downtimes, it should be.
Every one of those jobs that slips into a shutdown takes time and attention away from work that can only be done in a major shutdown. The downtime code is what makes this rule enforceable.
Measure planning health
This is the biggest payoff. Once every order has a time estimate and a capability code, you can measure the "ready-to-schedule" bin against your actual crew capacity and build a sustainable backlog that feeds your entire team with the right work.
Example: If you have 2 technicians on each of 3 shifts, an electrician on day shift, and day shift has 1 of 5 machines available each day for a full shift of work... then your backlog management looks like this for a single week:
You need 16 hours of "single shift down" work for your mechanics planned for each machine, each week. (This consumes the day shift time, 80 total hours.)
You need 40 hours of electrician work (which should prioritize "single shift down", before "do while running.")
You need 160 hours of "do while running" work to gainfully use the time of your back-shifts.
Note: Response calls to the line will interrupt work. It's good practice to assign work that techs can walk away from while they're "on call." It's not good practice to let them do nothing but take unplanned calls.
Do this for every trade and every downtime type. The question, "Do we have enough planned work?" now has a numeric answer.
This allows you to easily select the most important work by type and plan it to make sure every member of the team is working on the right work.
The standard: Keep every category's "ready-to-schedule" bin at a two-week backlog, with six weeks as the goal.
(The backlog of "ready to schedule work" is how many weeks of your crew's time is ready to schedule. ie: If you have 10 techs working 40 hours a week, 800 hours of work in the "ready to schedule" code would be a 2 week backlog. The rest of the codes would help you determine whether you can actually work on all that work. Remember, planning work you cannot does not help you.)
PM time can also be auto-generated with codes to drop into the backlog as desired.
The Approval Checklist
Before a work order moves past approval, confirm:
Priority score assigned (criticality × severity). This tells you of any group of work orders which to work on first.
Downtime code assigned (run-while-running, single-shift-down, or extended outage) - This lets you only look at work that you can actually do. This is critical in building a backlog you can actually execute.
Time estimate entered in hours - This is the only way you'll ever be able to tell if you have enough work to occupy your crew.
Capability code assigned (electrical, mechanical, multi-tech, programming) - This works with the time estimate so you can tell if you have enough work for each team member.
Ready to schedule vs Needs Planning assigned. - This lets you respond to jobs faster that don't require extra planning steps and saves planner time.
Intake coding feels like paperwork. It's actually what makes work plannable, pullable, and measurable, to the point where you can see at a glance whether your team is about to run out of the right kind of work.
This is the kind of paperwork that makes everyone's job easier.
Comments