Try to pick a process that you use regularly. A good candidate might be to respond to a customer request or submit an order or request approval for a document. Draw a box on the left with a first step and a box on the right with a finished state. Fill in between that first step and the end with all of the steps that need to be taken for the input to become the output. Now you have the start of a process map.
Many new map makers make the mistake of describing the process in broad terms. A map of “receive request, work done, complete” misses a huge amount of where process performance can slip. It might be that steps are missing, that someone is not sure when they have done their part, or that they don’t know what the next step is. A process step might describe checking that required information is present, forwarding the request, completing the task, verifying completion, and updating the record status. Keep process steps short.
An input is an item or information that must exist before the work begins. An input could be a form, customer data, a piece of raw material, a procedure, an authorization, or a previous record. The output is the result that you expect from the process. The output might be a completed request, a filled out form, a packaged product, or a completed ticket. Knowing your process inputs and outputs prevents your process description from becoming a description of everything you do.
Pay attention to your process handoffs. Handoffs are where quality often slips. They are points where the results of one activity are passed between people, teams, tools, or systems. For each step, who does it and who does it to? What will go with the results of this activity to enable the next step? What will make the handoff fail? A handoff might fail because there is missing information or attachments in the data package. Or it fails when the status of the work is not updated, leaving another person uncertain when the work is done. A handoff could fail when an item that is delivered is incomplete, making the next person redo the work. Handoffs fail in other ways that will cause nonconformity.
Add checkpoints to your process map where it makes sense. A process step might confirm that all required fields are complete, that measured dimensions meet specification requirements, or that a signature or approval is on file. You might add more process steps than you need and make your workflow hard to follow. Conversely, you might add fewer than are needed and miss an important failure mode. Show where a result will be checked. Then, show what happens if it does not meet the criteria for acceptance.
Now test your process map. Choose a real case that has just started to the point that it is ready to be released or closed and follow it from start to finish. For each step in your process, is the input present, and is someone clear about what to do and when? Does the output of a process step move without the need to add more details or make guesses? Where you had to pause to consider or fill in details is another place to revisit your process map.