The process approach is a way of thinking about work: modeling it, improving it, and correcting errors. The reason everyone uses it is that it works. Describing your work as a process makes you more effective in many contexts.
What is the process approach?
Michael Mills | isoTracker Solutions Ltd
The day you start working in Quality, you hear about “the process approach.” It runs all through management system standards like ISO 9001, and pretty much everywhere else too. Even the simplest jobs use a process.
So what is it, and how did it get this way?
Why use processes?
The process approach is a way of thinking about work: modeling it, improving it, and correcting errors. The reason everyone uses it is that it works. Describing your work as a process makes you more effective in many contexts, such as:
- When you have to do things in a certain order. (To bake a cake, mix up the batter before putting it in the oven!)
- When you have to meet a list of requirements. (If you need five pieces of documentation to get a city permit, a process will make you collect all five.)
- When you work with a machine. (If the machine doesn’t get the right inputs every time, it breaks. And when it does run, it always gives you the same outputs.)
- When you train others. (If they are brand-new on the job, give them a checklist.)
There’s one more, and it’s a big one. When you have different roles (or departments) working together on a big job, you need a process. The reason is that nobody knows what anyone else is doing. So whenever a work-package has to be handed off from one station to the next, proceduralize it so that it is always the same. That way the next person knows what to do.
And the process approach helps you improve performance. Once you define and measure processes you can calculate how well you are doing. Then analyze each process in detail to find opportunities to make it better.
How do you implement processes?
When you decide to introduce processes into your work, you can make the change easy or hard. The basic rule is to introduce only as much proceduralization as you need: no less, but also no more. If you are building cars or airplanes or power plants, where the complexity and the dangers are both very high, you need a lot of procedures. If you are setting up a hamburger stand, you need fewer.
With that caution in mind, take the following sketch and adapt it to your situation.
Figure out the big picture
Start with your purpose. Why are you in business? Who are your customers, and who are your other “interested parties”—that means, the people who want something from you, and who can affect whether you succeed or fail? Maybe these answers are obvious, but make a list because they can change over time.
What are you trying to achieve? Your processes have to support your aspirations, so you need to know what those are.
What are the main activities in your organization, and how do they fit together? These are probably your processes. Remember that people who work together—the designers, the production staff, the service desk—are usually part of the same process. Also, a process takes inputs and turns them into outputs. So when you line up the processes in your organization, they likely feed each other.
Here's a simple example, for a traditional manufacturing company:
- Marketing collects customer opinions from outside the company, and turns them into product requirements.
- Engineering takes product requirements from Marketing, and turns them into product designs.
- Manufacturing takes product designs from Engineering—puts them together with raw materials supplied by Purchasing—and produces finished products.
- Logistics takes the finished products from Manufacturing, packs them in boxes, and ships them out to customers.
And so on. Then there’s Customer Support, Human Resources, and other processes as well. List them all, identify their inputs and outputs, and see how they fit together.
Naturally you may do a different kind of work, and so you may need different processes!
Plan each process individually
Now you’ve got a list of processes, but so what? What does each of these processes really do?
Great question. That comes next.
Take each process, one at a time, and look at it closely. For each one, answer the following questions:
- Where do you start? In other words, what are your inputs?
- What do you do with those inputs? What are the steps?
- What’s the result of your work? What are the outputs that you hand to the next team?
- Who does the work? What special responsibility or authority do they have to have, to get the job done?
- What equipment do you need? How about training?
- How can you tell if you are succeeding or failing? Are there metrics you have to meet, or do you use some other indicator? Who is responsible for tracking this indicator, and sounding the alarm if it starts trending in a bad way?
It might take a little while to work this out for all your processes, but that’s fine. Start where you see the biggest risks.
How’s it going?
All this work defines a system. And once the system is defined, enforce it. Right away you will see things you got wrong. That’s fine. Just check why it went wrong:
- If you are doing the work right, but you wrote it wrong in the procedure, that’s easy. Rewrite the procedure.
- If the procedure is right but somehow you’ve been doing the work wrong all this time, that’s harder. Maybe your people need new training. Maybe you post warning signs. Maybe you restructure the work. But make sure the real work aligns with what you’ve written.
Once you’re past the immediate hurdles, keep watching over time. Is your system giving you what you want? Are your metrics reporting adequate results? If yes, great. If no, you might need longer term corrective actions.
Corrective actions
Besides everything I’ve said so far, the process approach includes two analytical tools to improve performance: the Plan-Do-Check-Act (PDCA) cycle for corrective actions, and Risk-Based Thinking for preventive actions.
The PDCA cycle has been called an application of the scientific method in business. For a single failure it works like this:
- PLAN: Something goes wrong. (Maybe this is a customer complaint, or a failure in production.) Collect the data, and determine what you think is the root cause of the problem.
- DO: Fix the root cause so that it can’t happen again.
- CHECK: Check to see if the problem went away.
- ACT: If it did, you’re done. If it didn’t, you didn’t find the real root cause; so in that case it’s back to step 1 until you find another (proposed) root cause.
The cycle continues until you make the problem go away permanently.
But this approach works for your business system too.
- PLAN: On a larger scale, your whole implementation of the process approach (described above) is one huge Plan phase.
- DO: This includes all your normal work for the next three, or six, or twelve months, until you review how you are doing.
- CHECK: Collect information on how your processes are running. Do the metrics show acceptable values? Have you seen improvements or degradation in your performance as a whole? Are there problems or inconsistencies you need to address? Make a decision on each question.
- ACT: Implement whatever corrections you decided on. They should improve your performance and your system. This step also starts the cycle over.
Preventive actions
The last piece of the process approach is risk-based thinking. At the most basic level, risk-based thinking means understanding that things can go wrong, and putting measures in place to protect against failures. Traditionally these steps have been called “preventive actions.” It’s a simple idea, but a powerful one. The more errors you can prevent through foresight and planning, the fewer defects there are in your products and services.
Michael Mills, who writes for isoTracker QMS software, has managed quality systems in large and small companies for close to thirty years. He is a member of ASQ and ISO TC 76 and has audited to ISO 9001 since 1996. He blogs regularly at https://pragmatic-quality.blogspot.com/.
The content & opinions in this article are the author’s and do not necessarily represent the views of ManufacturingTomorrow
Comments (0)
This post does not have any comments. Be the first to leave a comment below.
Featured Product
