Since the introduction of software tools in the 1990's that enabled the desktop production of business diagrams, literally billions has been spent producing countless numbers of flowcharts, process maps and flow diagrams. But to what measure do they demonstrate a successful process improvement model?
Across the planet, there are millions of these diagrams stored on file servers, web pages, local hard disks and in hard copy format. Why?
What purpose do they serve? In what sense can the production of these diagrams be considered a successful investment of time and money?
Non-sense; because if they aren't being used, they end up being a waste of time and effort.
So what's the problem? You are of course and your team; but you're also the solution.
What Happened to Your Much Hyped Business Process Improvement Project?
I'll bet this has never happened in an organisation where you have worked....
Languishing in the second drawer of the FD's desk sits the Process Handbook; a 200 page bound hard copy of the major processes and sub-processes performed by the organisation. It was produced three years ago and presented to all senior managers with a fanfare. "This is how we do things" was the claim. "This is the new approach to management that will save us time and help us become more efficient!"
The FD started to look at the report during a coffee break, and couldn't really get to grips with understanding some of the financial processes, let alone the other processes in the business. While the topic was hot though, she asked a few questions to try to get on-board. After a week or so, the Process Handbook moved off the desk and into the drawer to "be looked at when I have a bit more time". And there it stayed...
...and three years later, a new FD arrives, and stumbles across the Process Handbook. "This looks interesting" he thinks to himself. "It is a little out of date now, but if I could get this brought up to date it might prove very useful." The new FD decides to get the report updated.
Two years later, the Marketing Director receives the "relaunched Process Handbook", a 300 page guide to 'How we do things around here.' It looks really interesting, but from a first glance the processes don't seem very accurate and the terminology isn't quite in line with the terms the staff in the marketing team use. For a week or so it receives a bit of attention, but then it moves into the shelf of reports that sit in the marketing office labelled "Reference Materials". And there it stays....
Image sourced from: s-media-cache-ak0.pinimg.com
... but it happens in a lot of other places
You will know from your own experience how much relevance this story has to the reality of what is taking place every day in organisations across the world. I know it happens, I have seen it and I even have by my desk a Process Handbook from a large organisation that did it (and for all I know still does).
That this is not a successful outcome is plain to see. A Process Handbook, however fabulous in and of itself, and irrespective of how much work went into its production, cannot be considered a success if it becomes "drawer ware". Its whole purpose is to convey information; how can it do this if it is never referenced? Well...it can't.
Success equates to take-up. Virtually all benefits of producing a process improvement model spring from the usage of the model. It is like the Mona Lisa. If the Mona Lisa is stored in a locked room and nobody is ever allowed to look at it, what purpose does it serve? It may be one of the most extraordinary works of art ever created, but if nobody ever looks at it then it serves no purpose.
Image sourced from: twistedsifter.files.wordpress.com
Any organisation that is investing resources in the production of a process improvement model, for whatever reason, really needs to ask itself three questions:
- Who is the intended audience of the model?
- What obstacles will prevent them using the model?
- Are we really invested in making this improvement a reality?
If you take pride in the work you do, and you want your customers, staff, auditors, managers and stakeholders to value your work, then don't make more drawer ware. It kills trees and wastes time and money. Think about who your customers are (in the sense of the people that you hope will use the model), and make sure you figure out what they need in order to be able to use the work you produce.
Secondly, don't waste your time, your employees time and your company's money chasing the next business opportunity that will increase revenue or efficiency. Streamline your efforts, quantify your business values, find a direction based on analysis and budget considerations that will be a good fit for your organisation and then stick to it.
If you are going to implement any type of Process Improvement Model, see it through to the end. The problem often lays with departments that sit stagnant and claim that their Process Improvement Model is to blame when really, they ended up putting their 'shiny new toy' on the shelf.
It won't do what it was designed to do if it isn't used how it was designed to be used.
Creating Your Own Process Improvement Model: Let's Get Technical
Up until now, I've taken a more holistic view of creating a successful process improvement model, however, I have also written a more in-depth, technical and complex evaluation of Business Process Modelling here:
As such, you may consider the article your currently reading as being the entree and the article above to be the main course.
I would also suggest, if you take one thing away from this blog it would be to download this . The report has already helped many organisations get process mapping right on their first try and will provide the information needed to model your processes easily, effectively and get results.
Inside the report you will find:
- How process mapping opens a pathway to successful business improvement in a real, measurable way
- How process mapping creates simplicity, accuracy and accessibility in an organisation
- An easy to understand process mapping methodology; and
- Tips for a successful process capture and mapping implementation