It’s been six months since I last blogged. This has been for a number of reasons, but the biggest is that I’ve been so consumed between work and my hobbies that time spent at home has been filled with - incredibly - relaxing!

But I’ve come to the point where I need to tease out some ideas that are tugging at my brain, see if I can build them into a coherent picture, and solicit feedback from anyone who is interested (that’s you, right?!).

For this, I want you to imagine a hypothetical organisation of considerable size. This organisation is engaged in collecting, aggregating and analysing large amounts of data, across a number of quite different subject areas.

Over the decades of its existence each subject matter area within the organisation has developed independently from the others. With the current push to reduce costs and improve productivity there is now a recognition that these differences need to be united.

This has been attempted (or begun) a couple of times to date, with the involved parties soon floundering for want of direction. It is now beginning again, and with this work tying into the periphery of the BPM programme I’m currently leading (and for which the end of my involvement is in sight) I’m taking an interest in this project being successful so that it can envelop mine, taking responsibility for the “continuous improvement” phase of the BPM endeavour.

The progress to date

A high level process architecture has been defined for the organisation in focus, with all stakeholders agreeing to the architecture. This is at the level of “Acquire data”, “Process inputs”, “Aggregate data”, “Analyse & explain”, etc. Pockets of technology have been produced to meet various business needs within each high-level process, but no common methodology exists to guide people in the implementation of this process.

The progress from here

The programme leader is convinced that a business process improvement project is needed to define lower level process maps and ... improve productivity.

This screams out to me as missing a few steps, with no clear plan for how mapping lower level processes (which will be quite different for each subject area involved) will result in improved productivity. Pointing this out had two consequences:

- A number of people were annoyed at my challenge of their plan;

- I became responsible for ensuring there was a coherent plan for identifying (realistic) process improvements.

So here’s the plan - Please leave a comment to tell me what you think!

Members of the subject matter areas work together to identify a small set of alternative processes within each part of the process architecture that encompass the as-is processes being followed throughout the organisation.

This is the initial plan. At the end of this we will have a small number of as-is process maps for “Acquire data”, and for each of the other high level processes.

At this point the way by which each subprocess is implemented will probably differ throughout the organisation, perhaps significantly.

From here, measures will be identified for each subprocess of the above process maps to measure their efficiency, effectiveness and adaptability. Metrics will be collected to identify which processes are of the poorest health, and these processes - and these only - will be standardised throughout the organisation, with common techniques and tools defined as necessary to resolve the pain.

The result of this will be  organisational business processes that are somewhat standardised - Processes that don’t cause problems will continue to work as they always have, implemented differently throughout the organisation; but processes that are points of pain will be fixed, standardised, and adopted throughout the organisation.