Process Maps vs. Activity Network Diagrams - Differences

[CATERAF]

Hi,

Another question due to my inexperience in the area of QA -bear with me!

I have been trying to define all the processes in the company. So far I've got 2 "top-level" maps. I.e., I have one very broad map which shows the major company divisions and then the next one goes into a bit more depth for each of the company divisions. I'm currently breaking the processes down into procedures (but they're process map procedures).

My problem however, is that the software guys think an 'activity diagram' is a good way to show the processes, or activities. Perhaps because they are 'activities'? At the same time though, they are processes!
I don't know which way is better? I'm very much leaning towards process maps because that seems to be the norm and also what auditors are probably used to. I also think that because the top level diagrams really are processes, then perhaps I should be consistent throughout?

I guess i'm wondering then, why do you use process maps? What makes them so good versus activity diagrams etc?
(And what should I be using?)

Thanks!

Background of the company: We have many divisions - software development, manufacturing, support services, etc.
It's an electronic engineering company concerned with rail maintenance.

[JaneB]

Software guys always think that activity diagrams work, because that's what they're used to, how they think and what is used in their field. They're almost always drawn up, intended for and used just in software application design/programming, and thus often ignore anything that doesn't involve interaction with a computer. All that 'human' stuff being hard to pin down, you see

I'm not sure why, if you're working on processes why your first map would show ' major company divisions'. One is focussed on a range of events or activities that normally go beyond organisational lines, while the other is an organisational diagram. Unless you're using some kind of swim lane diagram (which shows when activities go to a different role or part of the organisation).

So I would go back to basics:
- who are our customers
- what do we deliver to them? (outputs)
- what do we need in order to create/make/whatever we do (inputs)
- OK, now, how do we do that (at the high level)

Sticking to org divisions is often a sure fire way of missing the end-to-end processes.

Focus on process maps that all/most of your people can understand and read and agree 'yes, that shows how it happens' (not just software guys). From what you say, software development is part of the company, but not all of it.

[CATERAF]

Hmm.. perhaps that wasn't clear enough.

The top level process map shows what happens from customer to customer. As in, the customer contacts and deals with marketing and sales, which then goes to the product realisation of idea development, engineering and production and then product is then given to the customer. That's the very basic top level.

Then the next one (level 2 map) is basically swimlanes with the company divisions and shows that, for example, idea development involves customer communication from which we identify customer requirements, come up with the concept, do a broad plan of the concept, and then pass that on to engineering.

For each company discipline we have the inputs (generally customer orientated) and then outputs (i.e., which division we send the product/design/order to).
I feel like I've answered the questions you posed?

Unfortunately I'm sticking to org divisions because my boss wants a QA that is heavily modelled on the business management system. Also, (and i agree with him) he believes it makes it more functional for the company - we're using a wiki system.

So far, everyone (including software guys) have seen the process maps (level 1 and 2) and have said "yup, that's what we're doing".

Thanks for your feedback about software guys only using that. I didn't realise it was a software-only kind of thing. Do you know of anyone who has used activity diagrams?

[JaneB]

In Reply to Parent Post by CATERAF

I feel like I've answered the questions you posed?

Yup - much clearer with the added information, and sounds good.

In Reply to Parent Post by CATERAF

So far, everyone (including software guys) have seen the process maps (level 1 and 2) and have said "yup, that's what we're doing".

That's good.

In Reply to Parent Post by CATERAF

Thanks for your feedback about software guys only using that. I didn't realise it was a software-only kind of thing. Do you know of anyone who has used activity diagrams?

Not in my experience, although I am aware of organisations that have adopted the BPMN notation, which has the advantage of keeping it standard, but the disadvantage of requiring effort to learn and not being readily accessible to the non-initiated.

Depends really on what the 'activity diagrams' they're advocating look like and how accessible they are. I can see there might be an argument for using them IF they meet other criteria within the organisation. I'd focus on getting some kind of definition of the key criteria for the process maps (or whatever) and then comparing alternatives against those criteria. Because if the activity diagrams don't meet 'em, even software guys might tend to accept that decision since it would have logic behind it. Which they surely do like.

[CATERAF]

Great advice, thank you!

I'll have a chat to my boss about the requirements for our maps/diagrams and clear it with him.

Thanks for the speedy replies as well (nothing like being in a similar timezone!).

[Peter Fraser]

A couple of questions (my reasons for asking given below):
1 what exactly do you mean by a "process map"?

2 <my boss wants a QA that is heavily modelled on the business management system> why would you do anything different?(!)

1 some people call what you have described as your top level diagram a process map (I tend to think of it as a "system map", and use the term "process map" to describe a map of a specific process). So an activity diagram is just one way to map a process (I agree with Jane that it tends to be a software thing, where you are trying to cover all the possible combinations of circumstances - and also that BPMN is not the best way to communicate the details of a process to "normal" users). Which raises another question - what is the objective in producing the diagrams? (It sounds as though the top level "maps" were confirming what your users knew already - do you reckon that they were adding value?)

2 If you already have your BMS description in place, how much detail do you already have defined? Can you not refine what you already have?

But I would confirm the benefits of "seeing" work in terms of processes, since there are lots of benefits, not least if you use swimlanes for describing individual processes.

[CATERAF]

In Reply to Parent Post by Peter Fraser

A couple of questions (my reasons for asking given below):
1 what exactly do you mean by a "process map"?

2 <my boss wants a QA that is heavily modelled on the business management system> why would you do anything different?(!)

1 some people call what you have described as your top level diagram a process map (I tend to think of it as a "system map", and use the term "process map" to describe a map of a specific process). So an activity diagram is just one way to map a process (I agree with Jane that it tends to be a software thing, where you are trying to cover all the possible combinations of circumstances - and also that BPMN is not the best way to communicate the details of a process to "normal" users). Which raises another question - what is the objective in producing the diagrams? (It sounds as though the top level "maps" were confirming what your users knew already - do you reckon that they were adding value?)

2 If you already have your BMS description in place, how much detail do you already have defined? Can you not refine what you already have?

But I would confirm the benefits of "seeing" work in terms of processes, since there are lots of benefits, not least if you use swimlanes for describing individual processes.

Thanks for replying Peter.

1. By process map, I mean, a flowchart of some kind that steps you through the different processes and activities that the company does. It's also to fulfill the ISO 9001 requirement of showing the interaction between processes.

2. My understanding of the ISO 9001 was that you could use the standard and then map to that or you could use your own business style and then incorporate the ISO 9001 into that. Obviously you're going to be continuing to do the same work regardless of which way you choose - but it's more for the functionality of the manual, etc. I.e., follow the order of the clauses, or do a cross-matrix to map the company to the ISO. (I've never done QA before so please bear with my lack of knowledge!)

Also, you're correct in that the maps are confirming what the people know. However, the point of them was not to tell those particular people what they don't know - they are managers of a small company (albeit with a tonne of processes) so they know already. It was to show the interaction of processes.
Also, we wanted a document that is useful for both clients and new employees too. We've actually sent out our 'system map' to some clients already.

In terms of refining what we have, that's sort of what we're doing for some parts of the company that have been defined. We are a small company so we have a lot of different roles and tasks being covered by each person. Some things are documented, but a lot is just things that they've come to do on a day-to-day basis. For the things that are already in place, I've taken what they've done and just reworked it slightly to incorporate things like identification and traceability etc. because they weren't included in the steps before. There are also lots of things missing like forms, document control, etc.

I think there are many benefits for process maps, however I want to make sure I'm using the most useful type of mapping. By the sounds of it, activity diagrams tend to be for software developers so I think that answers that part of my question. Thanks!

[Peter Fraser]

1 Ha - so you mean a system map?(!) Bear in mind that the usual "map" that folk produce for that purpose does not show anything like all the sequence and interactions - you would almost need a multi-dimensional picture to do that. But don't worry - certification bodies don't really look for that, and I have seen many maps which apparently are acceptable but do not really show all the sequence and interactions. If it gives staff an overall picture of your system that is probably the most useful benefit.

What is acceptable is a system structure as above which shows a logical grouping of processes, and then for each process to define where it interfaces with other processes (which you can do easily in a process flowchart).

2 ISO9001 is an assessment standard, not a design standard, so I would avoid designing your system around the sections of the standard (or designing your map based on the "model of a process-based management system"). Focus on your processes, ie how you do the work. And don't get hung up on "a manual" - your system description can be "the manual". It does not need to be a separate document.

http://www.promanade.co.uk/resources may be useful as a checklist...