I received an email from Ishmael the CEO of Intalio annoucing the release of their Zero Code Open Source BPMS solution. And though I don't know all that much about this particular product it is I think very illustrative of a couple of things.
Firstly, just how far workflow and business process solutions have come over the past 10 years. For when I joined Ovum my role was to cover Document Management & Workflow - the two things were seen as entwined then, yet even at that time workflow promised much and delivered short. The rename (for I still believe that is what it is) of workflow to BPM in some ways did a disservice to the technology.
(Workflow states very clearly that you follow a series of finite tasks to produce something. Business Process is much more nebulous and over arching as a term.)
Nevertheless the software has moved on and to look at what Intalio does in OpenSource is impressive viewing indeed. This kind of technology was available to those with only the deepest pockets just a few years ago.
The other thing that I thought about is how little has changed (seems to be a theme of this blog) - despite the BPMI's development of BPMN - business analysts still prefer to use Visio. I was personally an adherent of the Scheer toolset when I did business analysis, and wonder at times if the Aris Toolset was OS'd if it wouldn't dominate the business analysis world? But it isn't...so its and academic question.
The biggest problem with workflow and BPM is knowing how to understand and design an effective process. Its a skillset that is seldom taught properly, and the tools to help support the same are yet to be fully developed......
So BPM (or good old workflow) remains the bridesmaid and never the bride - I have never doubted that this is the area of technology that really needs a breakthrough, a (P word coming up) paradigm shift for it to really suceed.
I wish Intalio luck, I think its great that such Open Source products are available - (and put this in the same impressive category as Nuxeo and Alfresco).
7 comments:
Alan,
I wonder if you have a view on the Case Management products that fill the void between BPM/workflow and collaboration tools, as the paradigm shift you are looking for.
For example, the products provided by Vignette (which I understand intimately) and Global 360 (which I have seen in passing) which attempt to approach process improvement through 'paving the cowpath'. That is, starting with the process everyone understands and putting a veneer of automation around it, then gradually refining. This provides an approach that is easily represented, since the tools offer a great deal of functionality at every 'workflow step' that would traditionally have to be modeled in great detail (see my post for more details).
Using these tools you can approach process modeling through a simple iterative process:
0) Where does the workflow start?
1) Who gets the work case?
2) What do they have to do with it?
3) Name all the people they pass it to next
4) Talk to these people and get them to name and describe the tasks they perform when they receive work from the previous person
5) repeat
This leads to a decent result that most business people can look at, remove the fluff, and plug into a configuration tool.
At the first deployment, providing human-based processes based on a repeatable templated workflow steps, we avoid lots of the hard to explain modeling concepts that may be needed (like, what is the difference between orchestration and choreography).
I'd be interested in your thoughts.
Phil
Hi Alan,
Another intriguing article, thanks!
I struggled for a long time with the "workflow aka BPM" anomaly, and I totally agree that the vendor community managed to confuse everyone by overlaying the two definitions. What was a workflow product 3 years ago is now a BPM product!
Having said that, I don't think that the two are actually synonymous. I see workflow as the tools required to execute, enforce and monitor a business process. BPM is more about tools for managing the lifecycle of the process definition itself.
It's very difficult to have a clear dividing line between the two, but I usually take the analogy of an electric drill to explain it: If the drill is the business process, Workflow is there to ensure that you are using the drill correctly to make clean accurate holes in the wall - consistently and efficiently. BPM is about designing, manufacturing, testing and deploying a better drill.
In other words, Workflow will take a claims process and make sure that the steps are followed in the right order, the deadlines are met or escalated, interactions with other systems are followed, decisions are taken appropriately and there is an audit trail at the end to show for it. BPM on the other hand, allows you to model the claims process before putting it into workflow, simulate it and refine it before deploying a new version into production and allowing you to monitor its performance in order to go through the loop to optimise it again.
I’m sure that not everyone in our industry would subscribe to this definition, but it works for me! :-)
Regards
George
Hi Alan,
Another intriguing article, thanks!
I struggled for a long time with the "workflow aka BPM" anomaly, and I totally agree that the vendor community managed to confuse everyone by overlaying the two definitions. What was a workflow product 3 years ago is now a BPM product!
Having said that, I don't think that the two are actually synonymous. I see workflow as the tools required to execute, enforce and monitor a business process. BPM is more about tools for managing the lifecycle of the process definition itself.
It's very difficult to have a clear dividing line between the two, but I usually take the analogy of an electric drill to explain it: If the drill is the business process, Workflow is there to ensure that you are using the drill correctly to make clean accurate holes in the wall - consistently and efficiently. BPM is about designing, manufacturing, testing and deploying a better drill.
In other words, Workflow will take a claims process and make sure that the steps are followed in the right order, the deadlines are met or escalated, interactions with other systems are followed, decisions are taken appropriately and there is an audit trail at the end to show for it. BPM on the other hand, allows you to model the claims process before putting it into workflow, simulate it and refine it before deploying a new version into production and allowing you to monitor its performance in order to go through the loop to optimise it again.
I’m sure that not everyone in our industry would subscribe to this definition, but it works for me! :-)
Hi Phil - I have always seen Case Management as one of the user scenarios for much of DM. And this deserves a much better response and discussion than i am about to attempt here, but......
The value of the Case approach is that there is typically a defined begining and end, with very defined roles etc.
This is in fact not the reality for a great many workflows, and is the cause of so many failing, or becoming unmanageable. As in reality (ex Business Analyst talking here) most workflows in the real world are circular in nature - in that their end triggers a new start...
I will try and write this up in English at some point!
George - before BPM we had workflow - but even then we had two camps. Forms based and Production, BPM has emerged to some extent out of the Production camp (Staffware etc) and your definitions are spot on. However many clients (most?) have no idea and tend to use the wrong things in the wrong place - combined with the chronic under budgeting for analysis work before implementing either, their success rate can make ECM look effective :-)
I was first exposed to the term BPM several years back when I worked for an EAI tools vendor. Neat looking stuff but clients as well as the pro serve folks were hard pressed to understand how to leverage it to make things better. As a vendor in that space you had to have it as part of your suite though.
Certainly the 2 terms BPM and Workflow have overlapping elements but I would concur with George that in the purest sense BPM provides a mechanism for designing and simulating a template of a process and exercising it prior to putting the instantiation (i.e.; workflow)of it into production.
In another past life I remember much debate in the manufacturing community about "its not workflow unless you provide for non-human driven events to occur". So a number of the DM vendors such as Documentum which was trying to sell into the auto manufacturing market during this time scurried to add this functionality.
To Alan's point the mortal sin has been the purchase of workflow/BPM tools to support process efficiencies with not enough investment in the analysis and process definition. All to often the upfront thought around what is the process, who owns it, is it properly designed today, what about its capabilities to handle tomorrow's needs, etc. always gets minimal consideration in the rush to buy a product. I still think today the client who truly understands their core processes and has taken them out of the minds and thoughts of a small number of individuals and treats this knowledge as valuable is truly unique.
This is a bit of a can of worms. Many people renamed workflow to BPM for primarily marketing reasons. Now many vendors use the term BPM as a more wholistic form of workflow. Most clients dont really know the difference or if they do think of it as BPM = workflow 2.0.
This is a bit of a can of worms. Many people renamed workflow to BPM for primarily marketing reasons. Now many vendors use the term BPM as a more wholistic form of workflow. Most clients dont really know the difference or if they do think of it as BPM = workflow 2.0.
Post a Comment