What Is a Well-Defined Process?
The simplest and best definition of a procedure is “a documented process”. But that just begs the question of what is a process. A well-defined process is one where the supplier, the inputs, the ordered steps, the outputs, the customer, the objective and the review cadence are all written down and agreed, so that anyone competent can run it and get the same result. When we build processes we want them to be clear so people can understand and follow them. We need them to be well-defined.
Two simple modeling tools get you there: the SIPOC diagram, which fixes the boundaries of the work, and the process model, which turns those boundaries into a repeating cycle. Both are covered below, along with a worked example, a scorecard you can run against your own procedures, and a short set of answers to the questions this topic usually raises. If you want the wider mapping picture first, read about process maps.
What Is a Well-Defined Process?
Think of any business process. Of what does that process consist? A number of ordered steps. Are those steps followed from start to finish and they’re done? Not exactly. Your processes aren’t “one and done”, are they? Of course not. Those are events, not processes. We need to document events, but not for the sake of repeatability. See Why Have Procedures for the wider case.
Processes are events or tasks we want to repeat an unknown number of times; we’d like some processes repeated indefinitely. If we want our business processes to be consistent, to yield predictable, consistently good results, we need to document them.
We document processes (i.e., write procedures) to ensure consistency and quality of the results. We also document processes so we can train (and retrain) employees. No matter who is performing or supervising the process, no matter when or where they’re taking part, we want quality and consistency. If you are starting from nothing, begin with Standard Operating Procedures.
This is also how the quality standards frame it. ISO describes the process approach as the systematic determination and management of processes and their interactions so that the intended results are achieved. You can read the public introduction to the standard on the ISO Online Browsing Platform, though the normative clauses require purchase.
To develop what we call a “well-defined process”, we use a couple of simple, effective process modeling tools: the SIPOC Diagram and the Process Model.
The SIPOC Diagram
This tool gets its name from its five components:
- S – Supplier;
- I – Input;
- P – Process;
- O – Output; and
- C – Customer.
Because it’s visually oriented, the SIPOC diagram is very effective communicating, breaking down language, and other barriers. It helps people understand the purpose for the process and, when linked with similar diagrams of other processes, explains its relationship to other business activities.
ASQ defines a SIPOC diagram as a data collection tool used to gather information about the suppliers, inputs, processes, outputs and customers of a process. That definition is set out in the ASQ quality glossary, which also notes the expanded SIPOC plus constraints and measures variant used in Six Sigma work. Draw it before you write anything, particularly where the work crosses departments. For the wider taxonomy see Types of Process Maps and Process Mapping Best Practices.
A Worked SIPOC Example
SIPOC is easy to nod along to and hard to fill in. Here it is completed for a new vendor setup, a process almost every company runs and almost nobody documents. The entries below are an illustrative example, not data from a specific company.
| Supplier | Input | Process | Output | Customer |
|---|---|---|---|---|
| Requesting department manager | Vendor request with scope and estimated annual spend | Validate the request against the approved budget | Approved or rejected request, with the reason recorded | Requesting department manager |
| Prospective vendor | Tax form, bank details, insurance certificate, signed terms | Verify the documents and check the vendor against the sanctions list | Complete, verified vendor file | Accounts payable |
| Accounts payable | Verified vendor file | Create the vendor record and set payment terms | Active vendor record with a unique vendor number | Accounts payable and the requesting department |
| Procurement | Active vendor record | Issue the purchase order and file the agreement | Issued purchase order, agreement in the contract register | Prospective vendor, now an active vendor |
Notice what the table forces you to decide. Who actually supplies each input. What “complete” means for the vendor file. Which single role owns the output. Those are the decisions a vague process leaves open, and they are the ones that produce rework.
The Process Model
Like we said, a one-time event is not a process, just like a one-time repair is not a corrective action. A true process is a cycle, the Deming PDCA Cycle to be exact.
This ISO process model does an excellent job of illustrating a typical process. A well-defined process should answer your questions about the process methods for Plan, Do, Check, Act:
- You PLAN the process, establish process objectives (what the result should be), state the various requirements (customer, regulatory, standards-based, internal, etc.), and describe how you will get from point A to point B and back again;
- You DO, performing the process and collect process data; the data element is critical for providing feedback to determine if the process is in control;
- You CHECK on the process, reviewing the data you’ve collected and analyzing process performance (not just according to stated objectives, but also for variability, consistency, and trends); and
- You ACT on your review findings, either continuing with the process unchanged or modifying the process to make it work better and implementing the process with those revisions.
One point of accuracy is worth having right, because the naming trips people up. The W. Edwards Deming Institute records that the cycle was introduced to Deming by Walter Shewhart and that Deming emphasized Plan, Do, Study, Act rather than Plan, Do, Check, Act. The Deming Institute PDSA page sets out that history. ISO uses the PDCA wording, so both labels describe the same loop.
Score Your Own Process
“Well-defined” is not a feeling. It is a set of things that are either written down or they are not. Run a procedure against the eight criteria below and count. Eight out of eight is well-defined; anything less tells you exactly where to work next.
| Criterion | The evidence that proves it |
|---|---|
| Named owner | One role, not a committee, accountable for the result |
| Suppliers and inputs identified | The S and I columns of a completed SIPOC |
| Steps in order, with decision points | A map or numbered procedure a new starter can follow |
| Defined output and acceptance criteria | A written statement of what “done and correct” means |
| Named customer | The C column, internal or external, named by role |
| Stated objective | The target set during PLAN, expressed as a number or a condition |
| Data collected while the work runs | The record produced during DO, with where it is kept |
| Review and revision cadence | The CHECK and ACT schedule, plus the triggers for an off-cycle review |
The first four criteria come straight out of the SIPOC diagram. The last four come out of the process model. That is the point of using both tools rather than one.
Ensure You Have a Well-Defined Process
The PDCA Cycle is the ideal framework for developing business procedures. That’s why at Bizmanualz, we use the process model as the basis for our procedure templates. The process model works for any procedure, whether it’s in Accounting, Human Resources, Sales/Marketing, or any of your other departments.
You’ll find that when you use these simple and effective tools to guide your procedure development, your processes will be well-defined processes and you’ll reach more of your objectives. When the ACT step tells you the process itself has to change, that work is covered in Process Improvement Initiatives.
What about you? Have you used these tools recently? Did you find that they were extremely helpful, or not at all? What tools do you use to develop your procedures? Have you used Bizmanualz policy and procedure templates? What did you think of them?
Frequently Asked Questions
What is the difference between a process and a procedure?
A process is the repeatable sequence of activities that turns inputs into outputs. A procedure is that process written down, with responsibilities, sequence and records specified. The process exists whether or not anyone documents it; the procedure is what makes it teachable and auditable.
How do you know when a process is defined well enough to stop?
Stop when a competent person who has not done the work before can complete it from the document without asking questions, and when you can point to the data you collect to tell whether the result met the objective. If either test fails, the definition is incomplete.
Do you need both a SIPOC diagram and a process model for every process?
No. Use SIPOC to agree scope and boundaries before you write anything, particularly where handoffs cross departments. Use the process model to structure the written procedure itself. For a single-team routine task, SIPOC can be a few lines rather than a diagram.
Who should own a well-defined process?
One named role, not a committee and not a job title that no longer exists. The owner is accountable for the objective, for the data collected during DO, and for deciding at ACT whether the process changes. Shared ownership is the most common reason a documented process quietly stops being followed.
How often should a well-defined process be reviewed?
Review on a fixed cadence and on trigger. A yearly review is the usual floor. The triggers are a customer complaint, an audit finding, a regulation change, a system change, or a run of results outside expected variation. The ACT step is where that decision is recorded.
