Informational ISO9001:2015 Process Interactions

[chetws]

I am glad you are open to constructive feedback.

In my opinion, these high level process maps are utterly useless. They don't add any value whatsoever because they are overly simplistic, don't really recognize all the interfaces between processes and are easily glossed over. They seem to exist solely to appease misguided external auditors who "like" to see something like this to tick a mental box they have.

I agree with you 1000% on this.

If you want to do something that really adds value, forget creating a process map such as this. Try to describe in TEXTUAL form the processes and their interfaces in the system. Obviously, you can not put all the details there, but the primary and secondary interfaces. For example one thing that your process map does not contemplate. Customer wants to URGENTLY change the delivery method and address for an order. Your process does not have a DIRECT interface between order management and shipping. Guess what? In an URGENT change order scenario, that interface needs to exist, at the risk of creating customer dissatisfaction. A description of such processes interfaces would help educating the workforce about the quality system of the organization.

Good luck.

It's funny you mention this. Our sister company basically does what you're saying graphically. They have a cross function flow chart for each process showing the inputs and outputs for that process. By looking at the inputs and outputs, you can see the interactions of that process with the other processes. It shows more interaction than the simple diagram that I showed. I've contemplated going that direction, but you've convinced me that it's the way to go.

Thanks a lot Sid

 

[Jim Wynne]

I agree with you 1000% on this.




It's funny you mention this. Our sister company basically does what you're saying graphically. They have a cross function flow chart for each process showing the inputs and outputs for that process. By looking at the inputs and outputs, you can see the interactions of that process with the other processes. It shows more interaction than the simple diagram that I showed. I've contemplated going that direction, but you've convinced me that it's the way to go.

Thanks a lot Sid

I'm with Sidney. The intersections of processes are where things often go wrong. The idea is to avoid creating silos where things are thrown over the wall to the next process, and to control what happens at the intersections. You can't do this effectively with a diagram alone.

 

[John Broomfield]

Chet,

Now you can involve the leaders of your organization in naming the person best able to own each of these processes. You then work with each process owner to document the objective of their process and to capture it as it actually works and interacts with other processes within your organization working as a system and with customers, suppliers and other interested parties.

After each session ask the process owner to engage the process team members in a review to mark up the deployment flowchart* to improve its accuracy.

*Deployment or swimlane flowcharts show who does what and their interactions. You may choose to upgrade your highest level flowchart to this format.

Best wishes,

John

 

[chetws]

Thank you very much John, Jim, and Sidney. I do plan on using a swimlane flowchart and scrapping my original diagram. I'm definitely taking your advice, John, and will get with the process owners. I've done that a bit, and it's like pulling teeth. But necessary to do

I really appreciate all the advice here. I was just flapping in the wind by myself, so it's nice to hear the thought from those who have done this longer than I have

 

[Jen Kirley]

I had a client that did it textually. It was jolting to see such a different display, but when reading it I got a fast appreciation of the document's usefulness. It could be given to a new manager to help describe the organization's activities on a high level.

It may be possible to do same if you had that map (remember the words "process" and "map" don't appear next to each other in any of the standards) on an Excel spreadsheet, you could embed comments that include the text. In this way, the visual thinkers could still get the detail that would actually add some utility to the document. The map by itself seems like just a chore to put together for auditors.

 

[chetws]

I had a client that did it textually. It was jolting to see such a different display, but when reading it I got a fast appreciation of the document's usefulness. It could be given to a new manager to help describe the organization's activities on a high level.

It may be possible to do same if you had that map (remember the words "process" and "map" don't appear next to each other in any of the standards) on an Excel spreadsheet, you could embed comments that include the text. In this way, the visual thinkers could still get the detail that would actually add some utility to the document. The map by itself seems like just a chore to put together for auditors.

I find the suggestion that you and Sidney gave of using a textual, rather than a graphical, process interaction interesting. You both give solid reasons for it. I believe all of the process interaction examples on this thread are some sort of graphical. I'm more of a visual person myself, so I'm having trouble visualizing (no pun intended) what a textual process interaction would look like (how it's organized, etc). Do you have an example of one off the top of your head?

 

[cferrer]

This thread is very enjoyable. I would also be very much interested in how some of you implement a textual form of the IOP.

 

[aeroservinc]

I am looking for assistance with Clause 4.4.1. It asks for a process definition document. Is this what everyone is talking about with their graphs and such? It asks for:

• applicable inputs and outputs
• process owner(s)
• applicable responsibilities and authorities
• applicable risks and opportunities
• critical and supporting resources
• criteria and methods employed to ensure the effectiveness of the process
• quality objectives related to that process

And what I am gathering is this is all on those graphs and tables everyone makes. Is this right?

 

[chetws]

I am glad you are open to constructive feedback.

In my opinion, these high level process maps are utterly useless. They don't add any value whatsoever because they are overly simplistic, don't really recognize all the interfaces between processes and are easily glossed over. They seem to exist solely to appease misguided external auditors who "like" to see something like this to tick a mental box they have.

If you want to do something that really adds value, forget creating a process map such as this. Try to describe in TEXTUAL form the processes and their interfaces in the system. Obviously, you can not put all the details there, but the primary and secondary interfaces. For example one thing that your process map does not contemplate. Customer wants to URGENTLY change the delivery method and address for an order. Your process does not have a DIRECT interface between order management and shipping. Guess what? In an URGENT change order scenario, that interface needs to exist, at the risk of creating customer dissatisfaction. A description of such processes interfaces would help educating the workforce about the quality system of the organization.

Good luck.

Here's my first draft at a text-based interaction entry for the Planning Process:


Planning Process

Inputs
Process – Order Management
Document – Tank Farm Inventory
Document – Critical Vendor List

Objectives
What product is produced and how much
Select and acquire needed raw materials for production
Select and arrange transport of finished product to the customer
Arrange maintenance projects during plant downtime

Outputs
Process – Manufacturing (Amines)
Process – I & E
Process – Shipping / Receiving
Process – Quality Assurance
Process – Order Management
Department - Purchasing


Is this more or less on track? Process maps don't typically have objectives, but I didn't see any harm putting them here even though I'll put them in the process definitions.

Of course, I'm going to make one for each of the other nine processes in my company. After making just one entry, I can see why some of you prefer a textual interaction. For one thing, this is really easy to make changes to. Making changes to a complex diagram can be painful.

 

[Tagin]

I am looking for assistance with Clause 4.4.1. It asks for a process definition document. Is this what everyone is talking about with their graphs and such? It asks for:

• applicable inputs and outputs
• process owner(s)
• applicable responsibilities and authorities
• applicable risks and opportunities
• critical and supporting resources
• criteria and methods employed to ensure the effectiveness of the process
• quality objectives related to that process

And what I am gathering is this is all on those graphs and tables everyone makes. Is this right?

4.4.1 is not asking for a 'process definition document'. In a-g it uses the words 'determine','assign','address','evaluate'. It is telling you at a high level that you have to do these activities as part of creating and maintaining your QMS. You can do those activities and then include/document them elsewhere. For example, at the start of your document for the Receiving Process, you could have a section entitled "Authorities and Responsibilities" and document there the relevant auth/resp for receiving. Addressing risk/opps might be handled in a risk register (if you use one). And so on.