In my last couple of blogs I focused on the topic of process governance and the added value that this concept can bring. However, before you can start thinking about governance, it would be rather useful to first implement BPM as a management philosophy and we know from experience (in my case first hand experience) that this is all but straight-forward and obvious. That’s why I am dedicating my blogs in February to the topic of implementing BPM.

First, a disclaimer, these blogs will have nothing to do with the technical side of BPM, instead they will focus on the organizational side of BPM. The reason for this is quite simple, BPM is a management philosophy (usually supported by a BPM platform) and not just a technology stack. It is also often confused with BPMS, which are technology solutions focused on workflow management, basically a small sub-part of the wider BPM concept. Now that we’ve got that out of the way, let’s get to the good stuff.

As mentioned BPM is a management philosophy and the picture above describe the core essence of this philosophy. Processes are assets, just like people, plants, applications and so and so forth, and subsequently need to be treated like assets. This means, proper funding, organizational support, ownership and documentation. The challenges often begin at the moment that an organization wants to start implementing BPM and asks itself: where do I start?

The answer, as you might suspect, is not always the same, but one topic should always be very high on the list: scoping! One of the pitfalls with implementing BPM is that you can go as narrow and as wide or broad as you want. Go too narrow and the benefits will hardly outpace the efforts, go too broad and you’ll drown in your self-made swamp of work. The scoping (and the subsequent planning of the rest) depends largely on the answer to the question where the BPM implementation will start within the organization.

In case the BPM implementation starts from the very top (and your BPM champion is part of this very top), then logically the scope will tend to be quite broad and planning becomes paramount to success. In the more common case where the BPM implementation starts within a domain or business unit of the organization, scoping comes first and planning second. The idea behind this second case (the local BPM implementation) is that you need to make sure that your first BPM roll out is successful, so you can use it to showcase around and broaden your scope. In order to increase the likelihood of this happening, you need to find the most enthusiastic group with respect to BPM and start there. In other words, you are grooming your ambassadors for future referential use within the organization (and say: look at what we accomplished thru BPM!). You basically only get one shot to get it right.

When you have a top-down, executive backed BPM implementation you want that first shot to be right as well, but you simply have a little bit of leeway in case the first attempt goes wrong.

Now, from a content perspective you can also look at the topic of scoping. The question to ask is:

What process would bring me the most added value when I apply BPM to it?

This does not need to be one of the four or five usual suspects: procurement, HR, IT, Finance or Keyser Soze (I hope you get the movie-ref I tried to spin here). If, for example, the plant maintenance process is sufffering from uncontrollable changes, unclear procedures or ambiguous leadership, then this process might very well be your first candidate to focus your BPM efforts on. I do keep as a rule of thumb that you will need to have at least one or two believers on management level for the process you are attempting to incorporate in your BPM practice.

Finally, of course the usual suspect processes are very often done in one of the first waves, simply because they are often organized in a shared services mode and this relies heavily on standardized processes and work instructions. So, naturally, the benefits of applying the BPM philosophy here is very big, but it doesn’t mean automatically that they should come first. Be creative and pragmatic!

Have a great weekend.

Ciao, Caspar