Earlier today Last week I got into this twitter conversation (couldn't publish earlier from inside China):
It’s a condensed conversation deserves some elaboration. When the term BPM is used, always bear in mind that there are 2 sides to that coin: A management discipline and a type of software system.
Here’s the basic context of BPM as a management discipline so that everyone is on the same page: At first, some desired result must be achieved. A manager typically breaks down the tasks to be done and delegates them to employees. That’s essentially a business process.
When people repeat those tasks, they learn and start to optimize locally. For example, they experience that they get faster response from that particular colleague, or they find easier ways to get to the same result. The participants in a process optimize their tasks. After a while, the overview can get lost on how the result actually is achieved. Then, inefficiencies can creep into the overall process.
So being a manager, it’s useful after a while to get an overview of how work gets done to achieve results. Analyzing and documenting these processes typically shows a number of obvious inefficiencies.
Now take that idea and apply it to the executive management of large corporations. For them to know the details of how things get done is a big challenge to say the least. That basically requires interviewing people on how they do things. And at the same time, these people have their own way of dealing with their part of the process. So they often see this as intrusion and unnecessary overhead. It even gets more difficult for them when they are asked to change they way they do their work.
Originally, BPM systems have been developed to support the line of thinking sketched above. In a BPM initiative that is overseen by executive management, processes are documented and analyzed with diagrams in a BPM system. After these models are documented and approved, the BPM system drives the implementation of the software system to support those processes. That’s the stage when IT gets involved. IT has a head start, because the BPM system can already execute the diagrams and contains a task list for the tasks that people have to do. The only thing IT has to do is add the integration with the existing systems. But still, it’s easy to see that this whole waterfall approach leads to relatively long implementation cycles.
If I understand Derek correctly, that is the context behind “most of the complexity of #BPM comes from the program and politics – not the tech” I totally agree with Derek on that part.
But this could be read as: Compared to the management aspect, the BPM system software is almost irrelevant. And as we’re about to change the nature of that game, I obviously feel the necessity to clarify to those that interpreted it that way ;-)
The traditional to-down approach is great, but only one part of what can be achieved. I’ve spent the last 10 years in open source development building communities. And that has thought me a very important lesson: Many people don’t need to be told what to do. They are very capable to make their own decisions. Without instructions on how to do things, they often surprised me and came with the brightest ideas.
A similar trend is happening in enterprises today. The IT revolution has created tremendous opportunity for literally all people in the company to get informed and stay up to date. More people then ever in the organization are totally capable of adding great insights to which processes should be created and how they should be improved.
In the same spirit, sufficient social features often (definitely not always!) remove the need for tight authorization control. Employees want to build a reputation and so they will not want to mess up things.
This means that the tight command and control patterns applied before need to be enriched with social tools that empower the enterprise community. Employees want to move the company forward and get those results. The new, responsible knowledge worker will look beyond his own responsibilities and be open to input from above and below.
Think about this: There are many people like this in each organization. Together, they have a ton of ideas to improve the business. Many of those ideas will turn out to be giant leaps for the company. And as a side effect, the employees will see more of the knowledge they gained being translated into improvements for the company. The new social fabric in enterprise solutions will give them due credit. That is a serious motivator, even if not all of their ideas will be realized.
Imagine the scale of all those people spread over all those layers in the organization thinking and improving simultaneous. And compare this to one top-down BPM initiative.
The cloud has even accelerated the options for people to become informed, collaborate and show responsibility. Of course, the higher in the hierarchy, the more power people have. So changes coming from the executive level still have the biggest potential impact. This applies both in the positive and negative sense.
The other cloud factor is simplified user experience. Cloud services target viral adoption. Therefore, they need to be simple. Making the scope of the service smaller makes it easier to be simpler. Dropbox is a good example of that. Cloud technologies have made it cheaper then ever to build a software company. In Silicon Valley and in tech hubs around the globe a massive amount of startups is trying every thinkable combination. That leads to incredible pace of innovation.
On the one hand, BPM systems will have to reinvent themselves to capture that full potential of the responsible, informed knowledge workers. On the other hand, there is the huge amount of inspiration coming from all the cloud startups with unprecedented simplicity. So now is a great time to leverage the inspiration build the next generation BPM systems.
With this context I‘ld like to add that the relevance of next generation BPM systems will be crucial to bring out those otherwise hidden innovations that are not subject to program and politics.
