The philosophy of BPM (Or 'The 3 questions you should ask yourself')

The philosopher PlatoImage via Wikipedia

In today's modern world of tools, frameworks, standards and vendors it is often easy to forget that at its heart BPM is actually more of a philosophy surrounded by a lot of ancilliary detritus - at least that's my attitude when it comes to deciding what's important from a BPM point of view

As Dennis Parker from K2 said in a recent interview I did with him: "BPM is a completely overloaded term" and there is no clear definition of the term itself.

One of the key way's of ensuring success when it comes to process is to make sure you focus on the correct parts of the puzzle. It's too easy to get distracted with deciding what is the best tool to use or which third party systems integrator will provide the best value for your organisation. Don't get me wrong: Once you have your fundamentals in place and know what you want to achieve and why it is vitally important to have the right resources on board working in the right direction. This could be the correct tools, associated vendors, or system integrators, but fundamentally BPM comes down answering the following philosophical questions:
  • What are you trying to achieve with your change?
  • Who is responsible for making this happen?
  • How are you going to manage the change in your organisation?
The last one is a key issue which is all too often left out of the equation. Change management is key to making most projects successful and BPM projects are no different. A survey I ran last year highlighted that point dramatically.

Knowing which tools to use is something that should come at the end of your BPM journey rather than at the beginning (which my experience tells me is quite often the way things actually happen). This could be a result of a couple of things. The first is that companies tend to approach BPM tool selection from two points of view. The first is the 'I need a tool for this job so I'll get procurement onto the task'. The second is 'I have an urgent need to solve a particular problem or problems so I'll get a tool to help me'. Fundamentally nothing is wrong with either of these approaches but in essence what you are saying is that you are more focused on the tool than the solution. A solution may be possible without having to resort to any sort of tool - at least not immediately.

This is why if you come to GCP Consulting I won't try to baffle you with lots of jargon or talk about all these different tools and solutions that I can help provide you (although there are several of those that we can discuss at the appropriate time). What I will do is have a detailed, focused discussion with you about what, exactly, it is you are wanting to achieve, who in your organisation is responsibly for making this happen, and how are you going to manage the inevitable change within your organisation. I firmly believe that if you don't have these fundamental concepts in place then there is nothing more worth discussing on your project. I also believe that if you have answered all these questions - or at least given them serious thought - then I can probably add value to your project with my knowledge and experience.

I would also suggest that if your are in discussion with system integrators, vendors or consultancies and they don't seem to be bothered about these questions then your project may end up being more 'interesting' than you originally planned.

So before you go off and waste/spend a lot of time looking at tools, frameworks, vendors, SI's, approaches, solutions et al just spend a few moments thinking philosophically about your project and trying to understand exactly what you are trying to achieve. Ask yourself the three questions listed above and see if any of the answers make you re-evaluate your current thinking.

Topics such as these listed above are covered in my eBook 'The Perfect Process Project" which is available here.

Related Posts by Categories



Widget by Hoctro | Jack Book
For blog comments policy see this post
blog comments powered by Disqus