What IS a Process Map?

[Peter Fraser]

In Reply to Parent Post by Hondo812

Since the word "map" is used it is understood to be graphical in nature. No one confuses written directions to a destination with a map to the same location. I honestly can't see why anyone would suggest that a "process map" would amount to a procedure or other text only document.

Easy! "3.4.5 procedure = specified way to carry out an activity or a process". No mention of a "text only document" in ISO9000.

And have you never drawn a sketch of how to get somewhere by drawing lines for the roads, and added a few notes to explain that the rectangle is a supermarket, or that the junction is 200 yards past the church...?

[egarry]

I like process maps to help define the overall view of the organization. In my opinion, it makes it easy to describe the core systems of an organization using the IPO model (Inputs, Process steps, Outputs).
Once the core systems are identified, you can use the process map to help you determine what procedures you should consider documenting to define your QMS.

[Hondo812]

In Reply to Parent Post by Jim Wynne

I agree that "map" (as a noun) suggests a graphical representation, but it's possible to have written descriptions of process interactions that are not maps, per se, but are more effective than maps.

I agree that there is more than one way to effectively document a process. Most of that is dependent on what you expect to get out of it. I have used left/right hand charts/sheets to document which hand an operator is using to assemble/transport/grasp/etc. a product for a specific assembly step. This is information that does not present well on a classical flowchart format but does present very well in a 2 column list. It is not a process map however and I think that was the focus of this thread, to define what a process map is.

[Raffy]

Our process map describes the bird's eye view of the company's business. A PDCA cycle should be applied to a process map (SIPOC - Supplier-Input-Process-Output-Customer ).
Raffy

[JaneB]

Interesting - a range of viewpoints.

The poll results do seem to indicate some broad agreement on two points - if not total consensus

• A 'process map' can illustrate either a single process or multiple processes
• It is definitely not an 'all text' thing, though it usually has some text with it (eg, perhaps to explain or identify)

Beyond that... a whole range of different opinions on what it is, or what it 'should' or 'should not' be.

I do think the 'single vs multiple' point is an important one. It helps explain some of the confusion that can arise during discussions of process maps, particularly for the new or inexperienced.

After all, if 'my' mental model of a process map is firmly multiple and 'your' mental model is of a single process only, there's heaps of potential for confusion.

I also agree with Jim but only to a point. I love clear diagrams. But I dislike very busy ones, or ones that are not easy to understand, and in fact require considerable explanation!! So I'd agree that a clearly written description could be better than a poor process map. But then of course, a good process map would also be much better than a verbose and bad description!

[Bifften]

The Basics of Process Mapping by Robert Damelio was also helpful to me:

It suggests there are 3 types of "Process Map"

1) Relationship Map -
Shows supplier-customer relationships (which functions or parts of the organization receive inputs from and provide outputs to one another)

Level of detail: Least

Focus - Organisation Context

Relates pieces of the organisation to one another, answers the question: What does the organisation provide to its internal and external customers?

2) Cross functional Process Map -
Shows functions, steps, sequence of steps, inputs, and outputs for a particular work process

Level of detail: Medium

Focus - Process / People Interface

Shows supplier/ customer linkages for a single process. Answers the question, What steps does the organisation perform to provide outputs to its internal and external customers? And who performs each step?

3) Flowchart -
Shows tasks, sequence of tasks, inputs and outputs for a particular work process

Level of detail: Most

Focus - Process Detail

Shows detailed tasks that make up a process. Does not show supplier-customer linkages. Answers the question, How does the work actually get accomplished?


Personally I am working on producing Flowcharts (3) at the moment in my work, high detail, step by step work flows. In my organisation this is what is commonly refered to as Process Mapping.

[Peter Fraser]

In Reply to Parent Post by Bifften

[I][U]
3) Flowchart -
Shows tasks, sequence of tasks, inputs and outputs for a particular work process

Level of detail: Most

Focus - Process Detail

Shows detailed tasks that make up a process. Does not show supplier-customer linkages. Answers the question, How does the work actually get accomplished?

Even at the "flowchart" level it subdivides - a "process flowchart" shows what is done, and a "deployment flowchart" shows who does it and who else is involved. And you can use "RACI" (or a variation) to show the type of involvement. It helps get away from this apparent "obsession" that some folk have with finding a "supplier" and a "customer", and "inputs" and outputs", for everything that moves - or at least puts the description of how work is done into terms that the average worker can relate to!

[Intesar]

I believe

Its advantages:

Save time:
just by a quick look at it you understand it & you may be able to locate the critical steps
Easy to correct and improve:
just by editing an arrow or a box


thanks all