I've spent a lot of the last month or so in process facilitation sessions with different departments of a specific company.It's been a very interesting set of sessions. I've learned a lot of the particular business area (probably more than I really wanted to know), but I've also learned a lot about peoples attitude when it comes to the world of 'process'.
Let me see if this scenario rings true to any of my readers: (In the style of Adam Deane)
Me: So what I want to do is understand, at a high level, what are the main chunks of work you do from a process point of view
Attendee 1: Right, well, let's see. We produce the weekly TPM reports.
Me: OK. That's not a process, that's a deliverable. What's the process that produces that?
Attendee 1: I don't understand
Me: Producing the TPM reports is something that happens at the end of a particular process. What is that process.
Attendee 1 : It's the process to produce the TPM reports.
Me: Is that all you do?
Attendee 1: We send the TPM reports to management
Me: Prior to that?
Attendee: We run the programme to produce the TPM reports.
Me: Are those the only reports you run?
Attendee 2: Oh no. I run the quarterly QQZ report!
Me: So, what I'm hearing you say is that you have a process to 'Manage management reporting', and you both do that?
Attendee 1: Wait a minute. The TPM and the QQZ are different reports.
Me: And..?
Attendee 1: It's not the same process.
Attendee 2: Not the same process at all.
Me: Oh. So what's different?
Attendee 1: TPM reports are run off monthly.
Attendee 2: QQZ reports are run off quarterly.
Me: But other than that there are no differences?
Attendee 1: Oh yes, there are lots of differences. The TPM reports run off the transaction file and the QQZ reports run off the summary file.
Attendee 2: And I run the QQZ reports from menu 3, but the TPM reports are run from menu 1.
Me: But from a physical 'What is the process' point of view your process is basically 'Gather report data, produce reports, send to end user'?
Attendee 1: I send mine to different end users than she does.
Me: But you still send them to an end user?
Attendee 2: I send them to management
Me: But management do something with them?
Attendee 2: I don't know. I never asked..
Me: Right. So I think we defined a 'Manage management reporting' process at a high level. As we decompose that proccess we'll find differences specific to each report, but at a high level are we happy?
Attendee 1: Yes
Attendee 2: Yes
Me: So what else do you do?
Attendee 2: I update the system when somebody leaves
Me: Does that happen often?
Attendee 2: More often than you would imagine
Attendee 1: I update the system when somebody gets married. I change their marital status.
Me: Ok So I'm hearing that we have a 'Maintain employee data' process?
Attendee 2: But when they leave is different to when they get married. It's a different process.
Me: Is it?
Attendee 2: Oh yes. It uses completely different screens and different people approve it. It's completely different.
Me: So it's not a case of 'identify data to be modified. Modify data. Gain approval'?
Attendee 2: Er. Well.. yes. I suppose it is
Me: And is that what you do too?
Attendee 1: Yes. But using different scree--
Me: I understand the actual details are different, but is it fair to say you are performing the same basic process over a different set of data..?
(silence as this is digested)
Attendee 1: ...er.... Yes?
You can see where I'm going with this. People tend to get fixated at a very low level of detail when it comes to their processes. In fact, I would go as far as to say they're almost looking at procedures or work instructions in some cases.
The art of process mapping is to be able to roll that up to (or, indeed, drill down to it from) a high level. This gives the overall view of the business and helps to understand the touchpoints for other processes or functions. Sure, you can then start to drill down into the lower levels of detail and understand what and where things happen. At some point you'll decompose to the level where producing the TPM report is different to the QQZ report, or maintaining a marital status flag is different to maintaining an employment status flag. But at a higher level of detail this doesn't matter.
I think one of the reasons that a lot of process management projects tend to get bogged down is because they try to understand the 'whole level of detail' issue way too early. I sat today with one guy who had brought Visio diagrams to the meeting detailing everything he did. These diagrams had about 25 or 30 activities on each one. At the end of the sessions we had been able to simplify and condense those activities into about four boxes. For each workflow we were looking for: A trigger, A set of high level activities, any important deliverables, touchpoints to other processes and an end state. Nothing more.
At the end of the day that's all you really need.... .
Reminder: 'The Perfect Process Project Second Edition' is now available. Don't miss the chance to get this valuable insight into how to make business processes work for you. Click this link and follow the instructions to get this book.
All information is Copyright (C) G Comerford
See related info below
