Flow charts - Show Me Yours! Systems Approach - Process Mapping

[Marc]

The other night I was going back through some of my VERY OLD Mac files circa 1986 thru 1988. One of the things I remembered was that I learned flow charting in a business systems environment back in the mid- to late 1980's. I took it to heart back then and have been a serious proponent of flow charts since that time. This is probably because in college in the early 1970's we did similar 'flow charts' to define biological systems inter-relationships. Simply, if this happens, the result / path is this...

Since then I've seen the simplest to the most complex one could imagine. From integrated (live links, for example, to related procedures and forms) to individual 'Extreme Basic' flow charts.

I am asking you folks to share examples of your flow charts - simple or complex. Screen shot or pict, jpg, png or gif attachments would be fine (some folks may not have, for example, .vsd software to open the attachments.

Tell us what you have and why it is designed as it is. How did/do you determine the level of detail necessary?

Commentary appreciated! What are your experiences?

[gerrybean]

Attached is a copy of our non-conforming product procedure. We are not currently certified but are aiming for TS16949 before the end of the year.
This is typical of our procedures but is probably one of the more complex flow charts.

Any comments??

[RCBeyette]

We are currently in the process of modifying how we present our flow charts. In the past it was simply that...a flow chart...shapes included termination, decision, process, goto...and that was really.

It has been communicated to us to conform to the company standard of flowcharts, which we are planning on slowly transitioning to over the next year or so (not a top priority to us), without losing key data.

The new flow charting methodology for us is to look at our process from a PDCA side. Not to just document what we we do, but also how we try to improve it. It does, I admit, make the flow charts more complicated-looking, but after a while, we get used to them.

Flow charts at the WI level, however, will be in a slightly different format, yet to be formalized.

So, the flow charts for the main processes (all 16 of them), will still include:

• Purpose
• Scope
• Responsibilties
• Defintions
• Process Map (see attachment)
• Inputs
  • Raw Materials
  • Utilities
  • Key Paperwork
• Outputs
  • Finished Product
  • Process Data
  • Key Records
• Resource Idenfication
  • Personnel
  • Equipment
  • Methods
• Work Environment
• Measurements/Metrics
• Process Implementation, Verification and Validation Plan

[Mike S.]

Originally Posted by RCBeyette

We are currently in the process of modifying how we present our flow charts. In the past it was simply that...a flow chart...shapes included termination, decision, process, goto...and that was really.

It has been communicated to us to conform to the company standard of flowcharts, which we are planning on slowly transitioning to over the next year or so (not a top priority to us), without losing key data.

Do you find any value-added in this process (revamping your flowcharts to conform to a company standard)?

At least at first glance, that chart looks so complex as to lose one of the beauties of flowcharts (IMO) -- simplicity and ease of use.

[Tom W]

This is something I am working on improving right now. Attached is a draft of the layout I am looking to use. The chart is in Visio and the spreadsheet is Excel.

The other one (Global) is just a flow of the whole thing.

Comments / suggestions / ridicule are all welcome.

[RCBeyette]

Originally Posted by Mike S.

Do you find any value-added in this process (revamping your flowcharts to conform to a company standard)?

Not much of a choice. All of the North American mills will eventually be using the same documentation style and format and language....so that we can go from location to location and still understand what is what. But, as I said, it is not a priority for us so we'll get to it when we get to it.

Originally Posted by Mike S.

At least at first glance, that chart looks so complex as to lose one of the beauties of flowcharts (IMO) -- simplicity and ease of use.

And at first glance, you are right...but think of this as a true process map...not just a flow chart. A process can involve people outside of the parameters of the department that "owns" the process. This style shows who is involved, how they're involved and when they are required to be involved. When I first saw the map, I was intimidated by its style...I'm slowly getting used to it and beginning to see some benefits to using it.

[Douglas E. Purdy]

MARC,

I have submitted this flow before when I was working on My First 2000 System (Process-Based Approach). I am on my Second System and using the same flow charting method. The amount of detail has proven to be of benefit, especially if one is not generating procedural documents to correspond with the flow. I am utlizing Guideline Blocks to provide that procedural information and try to place them near where the activity is occuring.

Doug

[Peter Fraser]

Originally Posted by Marc

I am asking you folks to share examples of your flow charts - simple or complex. Screen shot or pict, jpg, png or gif attachments would be fine (some folks may not have, for example, .vsd software to open the attachments.

Tell us what you have and why it is designed as it is. How did/do you determine the level of detail necessary?

Commentary appreciated! What are your experiences?

We use a deployment flowchart format with the words separate from the symbols (we find that it is restrictive to put all the text inside a box, or to have separate boxes somewhere on the flowchart to accommodate extra narrative). And we use RACI (Responsible / Accountable (or Assists) / Consulted / Informed) to define people’s involvement (commonly used in the North Sea oil & gas industry).

The published (HTML) system has hyperlinks to the referenced documents and sub-processes. We find that the format can act both as a map of the process flow, and also as a “procedure” with sufficient text to be readable as an alternative to straight narrative. As a rule of thumb, we always define the “normal” process flow first, and then go through it again to specify the “alternative” conditions (which we can often build into the task wording without needing decision boxes).

All the elements of all the process details are in one dataset, and the software draws the flowcharts for you – so that you don’t need to drag & drop, or handle pagination manually, or amend all related flowcharts if you change eg a job title.

We can also display alternative “views” of a process, where we define and display eg business risks / competency requirements on the right hand column in place of the task description. We reckon that this helps us to go beyond “process mapping” towards “process management (and therefore improvement?)”.