I'm working on business process improvement with a client in a way that some people would consider to be 'backwards'. I'm not starting by obsessively picking at a business process being performed and constantly refining it so that it works better. I'm actually looking at all the records of transactions generated by the company, which are filed and stored off-site, and I'm working my way backwards into the business processes that created them. For me at least, this is a great way to approach things.
So many times, in business process improvement, especially when selling or implementing BPM software, we already have been told which business process we are working on. A client contact has already made a business case to fix up a specific part of a business process, as she owns the particular department affected by that piece of the puzzle. As much as BPM'ers love to believe they think holistically with end-to-end business processes, the reality of the situation is that they really are just rubbing ointment on a sore spot to take the pain away in that area. Less pain for their primary stakeholder signifies success for the BPM solution, and everybody is happy - except for the fact that the organization as a whole is suffering.
My current backwards view of an organization is turning out to show a stunning landscape of interrelated business processes and information. At this point I'm not talking about 'enterprise architecture'. Oh no, nothing that technical yet. From looking at all the printed reports, paper forms, photocopied documents, Excel spreadsheet and printed then scanned emails, I'm seeing an amazing interconnectedness of activities that is hard to get at when you look at a process as just a series of tasks to be performed.
Now that I've convinced myself that the organization is like one living organism and Mother Nature has overtaken my client, how does that help me actually make things better? Well, there are two approaches to mapping out the way to take process improvement: I can ignore this new view and select a business process that appeals, starting to fix it up, digging in from the 'request' in my diagram; or I can follow the paper trail backwards, from the final result of all the work that is going on (the record), back through all the high-level activities that produced the result.
What I'm finding is that by working backwards, I'm getting a clearer picture of the best-practice straight-line business processes I'm hoping to nurture than working start-to-finish. By working from the absolute end result of the process, which is the records to be kept that are evidence of a successful transaction, I can track back through all the activities that were performed to get there. For a start this allows me to discard the waste output that is often filed because nobody really knows if they can throw it away. More importantly, working backwards tends to hide the rat-holes, exceptions and distractions that typically appear from working the other direction (the benefit of hindsight?), allowing me to see what I really need: what a successful, streamlined business process is supposed to look like within the context of the whole organization. I can then use that information to select the most valuable business processes to focus on fixing, while already having a great view of how they should work.
I like this approach to starting a business process improvement project, although I know I'm going to have to avoid confusing my client with what appears to them to be an ass-backwards view of the world.
A post from the Improving It blog
2 comments:
This seems to create the risk of discovering the process for an artifact that doesn't actually need to exist: how do you know that the records are valid business requirements in their own right, rather than just an artifact of an inefficient process?
Hi Sandy,
You have a good point. This is certainly a risk in organizations that have deficiencies in their records management procedures.
I'm taking the approach that if records are being created that people can justify to me as being real records of business transactions, then I have a good starting point for working backwards. There may indeed be a bunch of documents that 'common sense' approaches to records management have also told people to retain, which are in fact only artifacts of an inefficient process and/or are not real records. These documents appear to be jumping right out at me, becoming another way of identifying waste in a process, while also being an important part of cleaning up the records management system.
I'll admit though, in trying to get my holistic view of the organization, I'm ignoring a lot of the documents that appear to have no place up front. So really what I have is a 'record' representing the output of a business transaction, and I work backwards through the 'paper-trail' to get a nice clean view of what the business process really represents. Nothing more original than Value Stream Mapping (as was pointed out to me), but its a nice way for me to get started with an organization that only has ideas about what it would like to fix, rather than actually knowing what the real issues are.
By working backwards, I've also found that its sometimes easier for me to see the part of the process that starts before the person that I originally considered to be the process owner. It becomes almost natural to ask "where did this come from?" as much as "where does this go to?". I'll use any little trick that helps me produce a better end result!
I'm sure you have plenty of experiences where an alternative approach helped with one of your clients. Though feel free to tell me that there is only one right way to do this stuff!
Phil
Post a Comment