Let me just start this post by confessing that I am passionate about business process management (BPM) and its potential for positive change. I'm going to try to keep this post relatively brief because it would be very easy for me to go "the other way."
The ultimate challenge with BPM tends to start with definitions. What is BPM? Ask five experts and you could easily get five different answers. Chances are, they would all have some things in common. Let's start with those.
- Business process management begins with using flowcharts (usually using Business Process Mapping Notation, or BPMN, diagrams) to document "as-is" processes
- The goal of BPM is process improvement
- BPM attempts to understand the connections between different business processes
- BPM requires ongoing involvement from key process stakeholders and works best when there is a continually engaged process owner for each process
After this, lots of other ideas start to come and go from the discussion. There is also confusion around even the items above. For example, some people think that if you map processes, you are automatically doing BPM. I disagree.
As I mentioned in Part #1, like lean, BPM is both a philosophy and a toolkit. BPMN is part of the BPM toolkit. Business process management systems (BPMS) software is also part of the BPM toolkit. The BPMS software vendors have clouded the field by attempting to imply that their solutions ARE BPM. Poppycock!
BPM is first and foremost a philosophy. The philosophy suggests that when the people involved in an organization each know which processes they participate in and the goals of each process, they are better equipped to identify activities that either don't contribute to or take them further away from those goals.
We are all expected to look at our work with a critical eye towards improvement. BPM gives people a common language for evaluating work and communicating about what they see with others. If you are familiar with domain driven design (DDD), then you have heard of "ubiquitous language." The idea is to have a common set of terms that have come to have common meaning among participants. This creates a degree of transparency about what everyone is doing and why they are doing it which is hard to recreate any other way.
Optimizing processes is an effort requiring both art and science. It also requires lots of stakeholder engagement. Once a process is properly diagrammed, there will often be some "low-hanging fruit" or obvious changes that will improve the process. The diagram enclosed was provided by Accenture and does a good job of illustrating some of the trade-off pairs process designers must make.
It is often the case that substantial gains require some automation. I always encourage stakeholders to start by using the tools they know (like spreadsheets and word processing software) to "simulate" as best they can the type of electronic solution they think they will ultimately need.
Starting out with a low tech approach provides invaluable learning about the new way of doing things that will assist in finding the best permanent solution. The key point here is that BPM is not an initiative that starts and ends. It may have a beginning, but it should be an endless journey. The environment in which we work is ever-changing and we must learn to adapt. As we do this, we need a methodology to systematically reevaluate how we meet the goals of each process. BPM is a great way to do this.
More about how lean and BPM make good bedfellows in the fourth and final installment of...THE WINDS OF CHANGE!
0 comments :
Post a Comment