Who Needs a Complete BPMS
Monday, July 24th 2006 | Ismael Ghalimi
Recent discussions on BPMN and BPEL have created a level of activity rarely seen on these pages. The quality of interactions is outstanding, and I strongly encourage you to read through the comments of this post, and this older one contributed by Francis Ip. In the meantime, let me use the opportunity of our weekly BPM 2.0 post to shed some light on why BPMN and BPEL nicely complement each other, and who really needs a complete BPMS. Disclaimer: this post might upset some readers, especially towards the end, but I need to get some messages across, loud and clear. Consider yourself warned!
By complete BPMS, I mean at least a process design tool and a compatible process runtime. As far as I can tell, one without the other is quite useless, and can actually take you down a path that will make everything a lot harder down the road, as we shall see with the following two examples.
If you get a process runtime without a proper process design tool, you end up having to write a lot of code manually. If you like writing code, this might be the best option for you. But if you don’t, you might want to consider an alternative option that offers both the tool and the runtime. This fascinating thread on Intalio|BPMS vs JBoss jBPM is quite insightful in that respect.
If you get a process modeling tool without proper code generation capabilities and compatible runtime, you also end up creating more problems that you might solve. I recently had breakfast with a Director of Engineering working for a very large application vendor. His job is to define the development processes and tools adopted by a group of 4,000 application developers to write and test complex business applications.
In order to facilitate the development and maintenance of such applications, the vendor decided to take a process-oriented approach, and selected a process modeling tool that would be used by product managers (think business analysts) to specify the application’s core processes. Then, a group of software developers would manually translate process maps into BPEL code in order to turn pretty pictures into executable code.
The idea sounded good at first, until the technical folks realized that writing BPEL by hand is no fun. In fact, the specification is so complex that I would contend that there are no more than 100 people living on the face of the Earth today who are able to write the chunk of BPEL code that is necessary for correlating one process instance with another. If you do not believe me, show me 100 of them, or come join us for one of the engineering sessions we’re having in Redwood City, CA in order to understand the bloody BPEL specification. If you do, you’ll quickly realize that the last thing you want to do is to write BPEL code by hand. This does not make the BPEL specification a bad one, it’s just that BPEL was designed to be produced by computer software, not human beings.
What this all means is that for the BPM (2.0) methodology to work in the real world, the process design tool must generate executable code, and you must have the proper process runtime for it. You might decide to go for a proprietary execution model — in this case I would recommend that you refrain yourself from using anything else than Microsoft, for only a company the size of Microsoft can survive on the long run while ignoring industry standards, or you might do what smart folks at IBM, Oracle, PeopleSoft, SAP, and Siebel all agreed to do: use BPEL, for its the industry standard, whether workflow folks like it or not.
And if you do not care about process execution, please by all means say so, and stop calling what you do Business Process Management (BPM). There is a very good name for your discipline, it is called Business Process Reengineering (BPR), it was very popular in the 90s, still is today within certain circles, and there is absolutely nothing to be ashamed of when being one of its practitioners. Last week, I had breakfast with Dale Skeen, Vitria’s co-founder and CEO. He and I might be among the few people who can reasonably claim that they “invented” BPM, and he and I would certainly agree on at least one thing: BPM requires process execution.
A bon entendeur, salut !
Entry filed under: BPM 2.0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ismael,
I am the farthest thing from an expert on the subject, but I am a process owner responsible for its profitability. As such, I want to be able to:
1. Analyze, understand, define, and map the process workflow;
2. Generate a process map with a simple visual tool;
3. Execute the process with an application without having to write any code;
4. Simulate and optimize the process on the fly for continuous improvement.
I have done quite a bit of business process reengineering (BPR) in my career, and I noticed that without the execution part, significant process improvements can be very rapidly lost.
Just my 2 cents.
-Ryan
Ryan,
I think you’re absolutely right.
Execution is the key to success. Many improvement projects fail because of the inability to execute formulated strategies or well thought out activities. The symbols used to define processes and codes generated for execution are immaterial to a process owner. S/he is more interested in how fast s/he can innovate in terms of products, services, and processes to sustain the competitive edge!
Francis,
I’d be happy for now if I could understand and map the business processes I am responsible for. I think my industry, chemicals, is a little behind in the process approach to the value chain, as well as in the BPM area. But that’s just my read on it and I hope I am wrong.
-Ryan
Ismael,
Earlier this year, Gartner unveiled the 2006 Magic Quadrant for BPM Suites. I tried to take a peek, but I could not find a free version, and I was not $495 curious, but I was wondering, do you know which quadrant Intalio is listed in?
-Ryan
Hi, I’m writing my thesis in Berlin about Business Process Management and SOA, so there comes my interest from for these interesting articles.
I have the impression that many companies just model their processes in order to fulfill the ISO 9001:2000 quality standard, and to fill a QM book (so that they can get a quality certificate). I think they even do not think of process execution, or let their processes even be influenced by the execution part (”SAP rules our processes”).
The real benefits of BPM and IT-supported processes, the process lifecycle Ryan was referring to, are not always known, or well communicated. I think BPM could also help many governmental institutions and former state companies in reducing their costs, and not just the number of employees.
In a nutshell, that’s my idea of the whole thing. I see lots of potential, but also the need for a real process orientation within companies and the will to improve — this should be the first driver.
Best regards,
Valerio Neri
Ryan,
We are not listed on the quadrant. More on this here.
Valerio,
I think you’re right on target. The ‘M’ in BPM does not mean modeling.
The term business process reengineering might have different meanings. At least in the context of ISO 9000 and CMMI history it meant radically redesigning your business processes from scratch. In contrast to this the quality frameworks suggested something often called continuous improvement, so no radical changes, but instead fixing your processes step by step (Deming cycle).
Also in the past it was the idea of many BPM guys and vendors to automate what you model. This is nothing new. However, today we are at a point where we can at least partly derive executable models from the business process models.
From my personal experience, I learnt that just sketching your business processes also has a great value, because people start to think how they work. Of course they could achieve more by automation, but often they are already satisfied with just the new insights.
So I do not really feel well if you claim that it is BPM only if execution is part of it. From a more abstract point you are talking about implementing what you have modeled — so acting upon it. Today, this might mean to execute, but it can also mean to change how people work through good change management.
Regards,
-Sebastian
Sebastian,
I very much respect this view, and am convinced that there is value in modeling business processes without walking down the execution path, but it’s not what I call BPM, and calling this BPM will only lead to confusion in the mind of customers.
Trackback this post | Subscribe to the comments via RSS Feed
Leave a Comment