What IS a Process Map?

qualityboi · Mar 17, 2009

JoCam said:
Process Mapping as an Improvement technique consists of a group of carefully selected employees establishing all the stages of a particular process, usually by writing, affixing post-it notes, photographs or flowchart symbols onto a wallchart. This highlights any gaps or weaknesses and raises discussions on how to improve the process. The output of such a session is corrective and preventive actions, and usually amendment of the associated procedure.

Jo

Thats funny, what you described is exactly the way we do it even down to the terminology yor are using. Sometimes we call it a process definition...the biggest problem with the mapping is that we find issues with horizontal ownership. This is also a good activity to reduce FMEA severity via a process re-design.

JaneB · Mar 18, 2009

JoCam said:
Process Mapping as an Improvement technique consists of a group of carefully selected employees establishing all the stages of a particular process, usually by writing, affixing post-it notes, photographs or flowchart symbols onto a wallchart. This highlights any gaps or weaknesses and raises discussions on how to improve the process. The output of such a session is corrective and preventive actions, and usually amendment of the associated procedure.

Jane, I agree with you that the term is a little confusing, and this is just my understanding of it. I consider it to be simply a detailed illustration of a process, leading people from the inputs to the outputs, just as a road map would lead you from A to B.

Jo

Bingo - now I pretty much agree with you. Good overview & explanation.

Sorry - I really wasn't trying to split hairs, but originally you said that the process map (itself) comprises 'a set of activities etc. ' Which I read as being akin to saying a road map comprises a set of states and roads, for example. It doesn't - it's some kind of document that represents them. If all that sounds too darned hairsplitting... forgive me.

Good point about the horizontal ownership, qualityboi. Can be difficult! Hence the importance of process-centric view vs that by procedure or department/function. (And I'm currently trying to sort out a bunch of procedures and figure out where the process is/are...)

JaneB · Mar 18, 2009

Jim Wynne said:
In general, process maps are confused masses of symbols, arrows and text that purport to explicate the interactions of processes. In most cases they do nothing of the kind and serve mainly to have something shiny and colorful to present to a CB auditor as evidence of understanding process interactions. Give me good ol' logically derived process flow diagrams any time. Or better yet, actually describe in writing how processes interact.

Jim, I was just rereading this. And after snickering through the 'confused masses' and 'shiny and colourful'... I wanted to ask something.

What is a 'logically derived process flow diagram' and how would I know if I were looking at once? (vs say a process map or anything else?)

JeffreyS · Mar 24, 2009

Jim Wynne,

That's the best truth I've heard in a while!

Jim Wynne · Mar 25, 2009

JaneB said:
Jim, I was just rereading this. And after snickering through the 'confused masses' and 'shiny and colourful'... I wanted to ask something.

What is a 'logically derived process flow diagram' and how would I know if I were looking at once? (vs say a process map or anything else?)

I missed this when it was first posted, so apologies for the tardy response.

A "process map" is anything you want it to be, but my point about a "logically derived process flow diagram" was that there is actually a standardized way of doing PFDs, and the standardization comes from computer programming, where logical flow is of the utmost importance.

For a simple example, look at this flowchart I from another post:

Note that the flowchart dictates the logic flow of the process--if the steps are followed as depicted, you have to perform the process as designed.

Contrast this with flowcharts and process maps and turtle diagrams that we're used to seeing, where there are symbols and arrows and god-knows-what-else jammed onto a sheet of paper such that it's impossible to know where to go or what to do.

If a processes are rationally and logically depicted (designed) it's possible to see the intersections and know what the requirements are for shifting the flow from one process to another, and you won't be able to get out of process "A" and into "B" without satisfying the requirements of "A" first. You also won't be able to skip over "B" and go directly to "C" from "A" if that's not intended to be allowed.

JaneB · Mar 25, 2009

Jim, yes, now I'm with you in both senses.

Do agree about logic being highly desirable in a process flow.
Although I'm often not as strict (eg, use of symbols and detail as the standard methodology dictates); those with an engineering/IT background seem fine like such diagrams, whereas many others often find them confusing - perhaps a bit like I feel about the more complex engineering drawings

But as for those confusions of colour and heaven-knows-what and 'more arrows than Custer's last stand' - not to mention confusion and illogicality, spare me.

One of the things that I have discovered through this thread is that the term 'process map' may be used by some people where I might instead use the term a 'system map' or 'system diagram'.

Thanks for clarifying.

Jim Wynne · Mar 25, 2009

JaneB said:
Do agree about logic being highly desirable in a process flow.
Although I'm often not as strict (eg, use of symbols and detail as the standard methodology dictates); those with an engineering/IT background seem fine like such diagrams, whereas many others often find them confusing - perhaps a bit like I feel about the more complex engineering drawings

If the process is logically designed and controlled, the PFD will be too, whether you like it or not.

JaneB · Mar 26, 2009

Jim Wynne said:
If the process is logically designed and controlled, the PFD will be too

This ought to be the case, I agree. Would that 'twere always so.

Yarik · Apr 18, 2009

Bifften said:
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.

With all due respect to Mr. Damelio, this "classification" of process maps is more confusing than helping. At least to me, a novice.

IMHO, this "classification" puts several VERY different things into one bowl called "process map"...

BTW, from the purely grammatical viewpoint: how come one of the types of "process map" has the word "process map" in it whereas other two types don't (and you can't even attach "process map" to them)? Whenever I see a classification that is grammatically inconsistent - it's always a big red flag to me...

Just :2cents:

Stijloor · Apr 18, 2009

Friends,

This is getting waaaaaay too complex...:mg:

OK. Here is a simple example. Assume that you have to explain to an interested person (outside of the organization) how an order is converted into cash. You must do this using simple pictures (symbols, whatever). I am sure that this person will ask a few questions for clarification. Once this person's light comes on, you are finished with your process map (or whatever you want to call this thing). :agree1:

Imagine; if road maps were produced based on the information in some of the posts in this thread....we would be lost forever....

Just venting my frustration.... :frust:

Stijloor.

What IS a Process Map?

What IS a 'process map' to you?

It illustrates MULTIPLE processes (eg, flowchart, diagram or similar)

It describes MULTIPLE processes (mainly or all text)

It shows MULTIPLE processes (combines graphics/diagram & text descriptions)

Sets out a SINGLE process only, graphically (eg, flowchart etc)

Describes a SINGLE process only, in text

It can show either MULTIPLE processes, or a SINGLE process

I don't really know

I avoid 'process maps'

There's no difference between a 'process map' and a documented 'procedure'

qualityboi

JaneB

JaneB

JeffreyS

Jim Wynne

JaneB

Jim Wynne

JaneB

Yarik

Stijloor

Similar threads