​ 5 Must-Know Tips for BPM Excellence

/

One day at work, a request came in to deliver a presentation on BPM to 10 employees from another department. On one hand, I was excited at the opportunity to discuss a topic I was passionate about. On the other hand, I felt some agitation. How was I to deliver timeless BPM pointers that would add value to them in just an hour? If I had time to say only 5 things about BPM, what would they be?

I did some extensive research and shortlisted 5 BPM Tips (Nuggets) I wanted them to go away with, even if they left with nothing else.

Nugget 1: Don’t launch BPM Projects based on perceived problems; BPM projects should be based on facts - Gartner Research

It's extremely important to conduct extensive research into the basis of the proposed BPM project before you start. Yes, people “seem” to have issues. The idea is to verify those issues before starting the project. You need to first figure out exactly what the business problem is. Is the project being launched as a result of customer complaints? Is operational cost a business pain? The problems facing the organization, the opportunities that need to be exploited as well as the business goals of the organization, should always drive the solution adopted, and not the other way round. 

Remember, it is possible to make a bad situation worse, and it is all too easy to improve the wrong things.

Nugget 2: BPM is not about technology... It’s more about change - Gartner Research

The idea is to change (improve) how people work. Yes, technology makes life easier. Yes, there are lots of technical solutions out there. Yes, technology is an enabler. Despite all the convenience that technology brings, process improvements can be achieved without technology. Simply automating a process does not improve it. For example, reducing the time wasted moving around by altering the seating arrangement of process participants can increase the pace of work significantly. Also, a simple measure like identifying areas of work duplication can free up valuable resources to focus on other aspects of the process and save time. Lastly, there’s no point automating a bad process because no amount of technology can correct a bad process.

Nugget 3: Don’t focus on mapping processes but on improving them  - Gartner Research

Mapping processes continuously, can lead to what is known as Analysis Paralysis (See Managing Analysis Paralysis). This happens when a person over-thinks or over-analyzes a situation to the extent that it becomes almost impossible to make a decision on what improvements should be made. It is all too easy to lose yourself in the complexity of modelling - know when to stop because BPM goes beyond merely creating process repositories for reference.

Nugget 4: Look at enhancing and evolving processes versus replacing them

This reminds me of the popular saying, “If it ain't broken, don’t fix it”. If a process will only need minor tweaks here and there to make it better, why reinvent the wheel? This is reminiscent of the streamlining Vs process re-engineering debate: should you streamline to fix existing processes by making them more efficient and effective or should you re-engineer to fundamentally change existing processes? Well, as always: It depends. If you are planning to change your entire business direction, if all the stakeholders agree that the process is completely useless, or you are looking at reinventing your business structure, re-engineering may be your best bet. if you are just looking to improve the process by reducing complexity and unnecessary delays, streamlining is your best option.

Nugget 5: View processes from end-to-end

If you are going to improve a process, it is important to map the complete process, end-to-end. There is no point improving a portion of a process and leaving the rest out. This would defeat the purpose of BPM which is about process, data and system integration. Take the Quote-to-cash process, for example - it is not end-to-end until you have considered delivery to the client.

Gartner also recommends that BPM projects start small. Starting small should, however, be about selecting a small and complete process until the necessary capabilities for handling bigger processes are available.