BPMS Challenge
Wednesday, June 14th 2006 | Ismael Ghalimi
Last week, I challenged my friend and industry analyst Bruce Silver to point me to a BPM vendor that could identify three customers who successfully managed to use its product to build a complex business process that would leverge a Service Oriented Architecture, and managed to do it without writing code and with no technical support from the vendor. If you read the comments that followed Bruce’s post on the challenge, it looks like not all BPM vendors like the idea. I’ll be honest with you, this did not really come as a surprise.
The IT|Redux BPMS Challenge defines the following rules:
- Significant-enough project (the process map has more than 100 steps)
- Integration with transactional systems through WSDL
- Human workflow through web-based interfaces
- Process design done by pure business analysts using BPMN
- Implementation done by IT people without writing code
- No technical support from the BPM vendor
And let’s clarify our definition of a business analyst: the candidate cannot explain the difference between DO-WHILE, WHILE-DO, and FOR-EACH loops, even when promised a free trip to Hawaii with friends and family.
The prize is a similar trip to Hawaii, courtesy of Intalio. And I promise you that you won’t have to attend any timesharing event if you’re the lucky winner. Problem is, there is so much bullshitake about BPM these days that many vendors just cannot live with such rules. They’ll try to make you believe that WSDL has nothing to do with SOA, or that JavaScript is not really code. Yeah, right… I’ll leave it to you to be the judge. And in the meantime, I’ll try to convince my team at Intalio that we should run for the challenge ourselves.
Entry filed under: BPM 2.0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[…] From IT|Redux […]
Interesting challenge. I would venture that no one can meet these criteria now, but it is just a matter of time. I was wondering about the rationale for the fact that more than 100 steps equaled a significant enough project? Do you know of any statistics on typical project size?
Jason,
Not really, just personal experience of working on real-world BPM projects.
Ismael,
What is your point? Is it that the path you are promoting is so hard that only 3 customers have been able to walk through it?!?!
Edwin,
Not really, this would be pointless. The point is to show that there is a massive disconnect between marketing stories hyped by BPM vendors and reality as experienced by customers.
It also goes back to my previous post regarding lack of customer interest for BPM, which I believe is due to the fact that vendors do not really let their customers use their products directly. I think this is slowing adoption down. Now, I fully expect a couple of vendors to qualify, with a lot more than 3 customers each.
Now, here is a tricky question for you: why do you believe so few vendors would actually qualify? From the list of six requirements enunciated above, which one would you say makes the challenge so unrealistic?
I think that there are two adoption patterns for BPM in the enterprise today (and expect the addition of a third one very soon).
Some vendors (Vendor A) are focusing on business process improvement and business analyst empowerment. What they call a business process is not necessarely executable. They sell to business users the power of having visibility into KPI and being able to perform simulation. Lombardi Software would be a good example of vendors in this category.
Some vendors (Vendor B) are focusing on standardizing the software infrastructure to allow for more modular and customizable business processes. They sell to IT the power of standards and benefits of being able to adapt to change. This is the strategy that Oracle has been following for the last 3 years.
A third category is/will be emerging aroung BPM as an embedded technology in next generation enterprise applications. Given the choice, customers would rather buy a process than the tool to build the process from scratch — especially if the process is customizable and extensible.
The challenge for the vendors of type A is that they need to find solutions to bridge their “abstract” solutions with the complexity of the enterprise infrastructure.
The challenge for the vendors of type B is that there is a need to elevate the abstraction to levels where business analysts can contribute to the definition of non-abstract business processes without import/export.
The next 4-6 years are going to be interesting because with the XML backbone of the internet becoming more mature, the need for assembly and orchestration of services will become even more mainstream (free, open, and good quality solutions will also play the role of catalysts) and I am hopeful that the vendors of Type B will have by then cracked the nut of higher-level/business-friendly views for both requirement gathering, documentation, analytics and simulation.
-Edwin
Edwin,
You are correct about Lombardi focusing on the business value, the “business” and “management” pieces of BPM. But to correct the record (and since you’ve never seen Lombardi’s product, it’s not surprising that you might have this misconception), Lombardi does execute real-world business processes. The value prop is not in “simulation” — that is the primary value domain of BPA vendors.
Lombardi excels at enterprise-wide process execution and choreography — witness 3 examples in my comments on Bruce Silver’s blog — but then also taking it a step further to “round-trip” the run-time information, in real-time, back to the business users so they can better understand, manage and improve their processes. This often leads, for example, to the discovery of non-obvious business rules which are then implemented in the Lombardi-based process, pushed out, and on and on.
This is the “third way” you describe above, and it exists today. But I disagree that there are three ways. There is a single destination, and we’ve all chosen different ways to achieve that goal, which I think we can all probably pretty much agree on — that technology and business are, together, moving into a new management style that attempts to put capabilities — processes — as the most important lever with which they need to manage and improve themselves.
As a software vendor space, Business Process Management is about the technology required to facilitate that changing management technique, and therefore BPM software must respond to both hard-core business people throughout the organization AND hard-core IT people throughout the organization in the same way that ERP has to serve these diverse audiences. Because this is a recent shift, vendors have chosen different points on which to initially focus, while each of us also is working on all the elements required for this shift.
I doubt if you would agree, for example, that Oracle doesn’t worry about the business user. That wouldn’t be true, even if I were to assert it. But’s it’s true that Oracle’s BPEL Process Manager is primarily targeted at a technical user. In the same way, a huge part of Lombardi’s work has been in the areas of how, in the context of an executing process, can less technical people interact with the run-time artifacts generated by that execution. Our patents, for example, are in those areas.
This common goal — roughly depicted in the #3 option in your comment, above, is the new way. It offers tremendous business and IT value, and is moving the enterprise to a more scalable view of not only how they manage and deploy processes… but also how they manage and deploy technology. And as for Lombardi, we have dozens of examples of companies beginning that journey for real.
It’s too easy to say “vendor X is in this bucket.” It’s exactly the same problem with Ismael’s and Bruce’s rules for their bet. It’s paternalistic to lay down rules for how customers become process-centric. Customers will determine the path they want to take. My experience is that if the customer is presented with the array of alternatives they generally pick the one that’s right for them (which is why I say to any customer organization reading this: check out _all_ the leading vendors, we have chosen very different ways to begin solving this problem).
So let’s simply agree that technology and business are, together, moving into a new management style that attempts to put capabilities — processes — as the most important lever with which they need to manage and improve themselves.
This journey will be long and, hopefully, fruitful, for all BPM customers. Our BPM industry will see the market grow from customers who will choose their vendor-partners based on where _they_ want to start _their_ journey. To your point, Lombardi has chosen to start with the business problem of business process management. Other vendors have chosen to start with the technical problems. All vendors have the same goal, and all paths lead to the same place, although the initial focus will define a vendor’s journey as surely as the sun rises in the East.
It’s all about the customer. That’s the problem with Ismael’s “rules” — those are all about a vendor’s viewpoint. It’s also the problem with saying there are “two types” of BPM vendors. There are many vendors, and each of our initial focus has defined the path we’ll have to take to solve the larger problem. This is a journey here, and it leads to more empowerment of people inside the line of business.
Edwin,
Awesome post! I could not agree more with the classification.
Phil,
Nice to see you here! I love the writing, and you sure have a passion for what you’re doing, which is a very respectable thing.
Yet, I just don’t get what your problem is with the rules enunciated for the challenge, beside the fact that they came from a another vendor. Which one can’t you live with, and why?
Also, with all due respect, I don’t think that you can reasonably claim your spot in Edwin’s third category of vendors. I should let Edwin answer for himself, but it strikes me that most large application vendors — Oracle and SAP being the most influential there — have settled on using BPEL as the core technology for their embedded process engine. Did you convert to the BPEL school of thought recently? If so, welcome on board!
Anyway, good to see you here again.
Now Ismael, there you go again… confusing implementation with benefit.
And that takes me to what is “wrong” with the challenge… it doesn’t _have_ to be WSDL-based (any more than the process _has_ to be BPEL-based or Oracle-based or Lombardi-based). The goal is about the customer’s business, not about the technologist’s bits. Why can’t IT be involved? Isn’t the _point_ to embed technology (and therefore, technologists) further into the business?
It’s the false buckets that you choose to segment “acceptable” process management into that I have a problem with. Very few companies — on either the business or the IT sides of the house — think about technology for technology’s sake. If they ever did, they sure don’t now… The stakes are too huge and the competition is too fierce.
The questions we grapple with — and that our customers grapple with — are: how can you make me more cost-efficient? How can you make my customer’s experiences better?
The answers to these questions lie, in my opinion, in changing the organization’s ability to run their core processes for the better, and to constantly have the ability to improve them. Over and over and over, again.
And there are many ways to _implement_ that ability. So if someone uses a BPM system to do that, and achieves significant advantage (say, a $250 million decrease in working capital required), why does it matter that they didn’t integrate with WSDL, or code up a bunch of BPEL? JDBC and SQL are, what, not good enough anymore? Why are your standards better than those standards? I am reminded of the old tent revivals in the 40’s and 50’s and some promoters would put certain religious denominations on one side of the tent and other denominations on the other side. And then one time one of the people who’d been hired to work on one side of the tent liked the singing from the other side better and lost his head and started running around the tent yelling “their god is better than your god. Their god is better than your god.” And he almost got killed by the one side… (For more on this, check out Tom Russell’s CD “Hotwalker”, and his interviews with Little Jack Horton).
When you get too dogmatic about implementation you often lose sight of the goal, which in this case is business value.
With Lombardi, you _could_ implement in the way you describe. And we also give you the ability to implement in other ways. In any case, the lowest cost, highest value path should be able to be chosen by the customer, not the vendor.
As to who is “most influential” in this area I’ll just have to disagree with you. SAP and Oracle don’t own this problem… and in many cases are a barrier to its resolution if you hear many of our customers talk. This is a new journey, like the relational database journies that began in the late ‘70’s, and the ERP journies that began in the late ‘80’s. Old alliances are being disintermediated as we speak. It’s surprising to hear you kow-tow to them…
In summary: business enablement is the key, not the technical implementation.
-Phil
Phil,
I agree on the common goal (and I think that Ismael point is that this is more a goal at this point than a reality).
I know Lombardi has some execution capabilities, but to me you can not be a long-term execution player if you are not invested in the standards that are used to build the XML backbone of the enterprise and the Internet. But I am sure that you are looking at addressing that the same way you are correct in that we are working very hard on understanding how business analysts can/should be better integrated into our solutions — an area where you have invested more energy and are ahead of the game.
Regarding the third category, I was talking about application vendors: SAP, Oracle and the thousands of other ISVs who are redesigning their software architecture to take advantage of SOA and at the same time make processes more explicit, easier-to-customize, easier-to-change.
-Edwin
Edwin,
Yes agree with your last point… It is a community of thousands of vendors and hundreds of thousands of customers who are working together… and it’s not owned by any one implementation mechanism. Rather, it’s the architecture that defines SOA, not a specific implementation at a specific point in time. I mean, how deep do you want to go? Are we going to define it as which WSDL was accessed by which set of Axis libraries?
Standards assist in the rapid adoption and evolution of SOA (XML being core, and WSDL, SOAP and others driving access to the XML) and Lombardi, like Oracle, is exceedingly standards-based. It is one of the reasons we’re even able to deliver the business value we all strive for, because the “lower” levels of access are being worked out. But most SOA architects will tell you (much like six-sigma folks in the process world): don’t start with the technology (or the tool)… Start with the problem, and then work back. And most important: project success comes from whether the business results desired were, in fact, achieved.
That’s my point. Success as a vendor should be defined by whether customers are achieving the business benefits they expect from BPM, rather than whether the implementation fits one or two vendors’ perspectives on the how… I’ve visited with many of your peers, so I know our companies agree on this… I just wanted to make it an explicit part of this thread.
Anyway, I am off on holiday…
This is a good thread… Thanks to Ismael for hosting it…
Cheers,
Phil
Phil,
Reading your posts, I am struggling with several apparent contradictions. One of them regarding standards, BPEL being first among them. Either you support BPEL, or you don’t. And if you don’t, I’m sorry but you cannot reasonably claim that you’re supporting industry standards much like Intalio or Oracle would. Much like a relational database that would not support SQL today would not be considered as supporting industry standards. And by the way, you’re the one who brought this analogy today, not me.
This being said, if you read the set of rules I defined for the BPMS challenge, they do not mention BPEL. So why are you creating confusion where none exists? They do mention WSDL, because if you remove WSDL from SOA, you could remove XML as well and go back to the golden age of EDI and ASCII. I’m sorry, but I do not miss this time, and I must believe that many of your customers do not miss it either.
So, yes, to me, as well as to anyone I talk to, WSDL matters. If you do not care for WSDL, much like you do not care for BPEL, then say it so, and acknowledge the fact that your product is built on proprietary technologies. For many customers, there is nothing wrong with that, and in many instances, it’s actually a better way to deliver a working product early on. It brings vendor locking issues down the road, but some customers are willing to go for this type of trade-off if it brings a working solution to their business needs. Is that what you’re advocating?
So let me ask the question again: what’s wrong with the rules? Could I have a clear answer on this, that goes beyond saying that you’re trying to solve a business problem? Because guess what: we all are, and saying that technology does not matter when solving business problems is naive at best. I want to believe that you can do better.
So what’s wrong with the rules?
I’m going to chime in, as Ismael pointed me here. I think its about time we accept that the rules as written are open to interpretation, but the aim should be the same -– to see if BPM tools (vendor specific or not) can live up to a promise of providing real business benefits to complex business processes.
To see if the rules are a useful judge of capabilities I would suggest that we look at two different classes of real world business processes:
1. A credit card company managing a dispute of statement items
2. A car company managing the concept-to-production process for a new car
Here is my experience:
CLASS 1
I don’t think I have experienced a BPM-implemented process providing true business benefits that exceeds more than 30 human steps. A level of granularity below that in my opinion is unrealistic for this class of process.
Firstly, it would involve a rip-and-replace of any legacy systems, since they typically handle the process granularity in code (COBOL probably!).
Secondly, it does not allow knowledge workers who interact with customers to make meaningful decisions based on the context of a case they are working on. In fact the person running steps at this granularity is probably not someone you want to actually have contact with your customers at all.
So I have failed Ismael’s challenge in this case.
CLASS 2
If I was looking at implementing a 100 step and up system spanning significant amounts of time, I would be questioning if a BPMS was the right tool. Why?
Well in this example process, real organizations view these things as projects. It’s the sort of thing they love to track with a GANTT chart, and manage the process based on dependencies, rather than a flow chart. I know the two can be interchanged, but skilled project managers are used to modeling these lengthy processes in Microsoft Project (despite its inadequacies), and unskilled department managers quite capably model their processes by representing tasks as colored blobs in Excel.
So I would suggest that unless there are workflowor BPM tools that consume GANTT-defined project plans, and coordinate them through the process (I have seen one, I just want to see if the owner claims it!), while allowing some of the necessary intelligence afforded by a professional project manager, few people would claim to beat the challenge on this second class of process. I would not attempt to build a car, house or software project based on a BPM-modeled process.
It seems I can’t contribute anything towards the challenge for the mainstream tools I have used (those vendors may or may not be upset!).
Maybe there is another class of process problems that can meaningfully be defined and be expected to be beneficial to coordinate with BPM that meets the scale of Ismael’s challenge. If so, let’s see if anyone wants to name it — then we can see if anyone can claim to have done it!
Ismael,
Just re-read the rules today. I don’t see any real issues with the rules until you get to the last two.
Yes, I would agree with the comments of others about the number of steps, but you have said “map”, not diagram, so I would assume that end-to-end you could have 100 steps or more, though you might have several processes or process fragments to achieve that.
What raised the bar substantially for me is the implementation by IT people without writing code. You have two problems here: not many organisations seem to have a proper, extensive SOA, and technical people love to get technical and go off and create something that they believe is missing.
The last point too makes it very difficult to achieve. I’ve been in a support role and I’ve had many inquiries that were simply a question of not reading the manual, or a lack of training. Very few seemed to involve real issues with the products.
Personally, if my business analyst could not explain the difference between the loops (even if they did not need the knowledge to create their diagrams), I’d probably reach for my humane killer…
Bob,
Regarding the question of support, a solution would consist in relying on the user community for support, and it would be acceptable for the vendor to provide the infrastructure for it, but it should be done in an open and transparent manner, at no cost for the user. All I’m trying to ensure here is that consultants provided by the vendor are not being used to do the hard work, and that real users are involved in the process as much as possible, in multiple capacities.
[…] You may recall my dinner bet with Ismael last month. […]
Bruce,
I think I hear some serious gloating! I’m looking forward to Ismael’s response…
Phil,
See my answer on Bruce’s blog.
[…] Are we there yet? Maybe, maybe not. […]
[…] Intalio is currently considering a participation to the BPMS Challenge that was launched by IT|Redux and picked up by leading BPM analyst Bruce Silver. Even though we have several customer projects that would most likely satisfy the rules for the challenge, we would like to properly document and certify our participation. Therefore, we invite customers and partners who would like to participate to join us in the challenge. If you have a process that has more than 100 steps and could be modeled by a business analyst using Intalio|Designer, let us know! We won’t be able to provide technical support during the development and deployment phases, but we will gladly provide free licenses for our product’s upcoming Enterprise Edition. […]
[…] When asked this very question, some promoters of the human-centric way use the tired 80-20 rule, claiming that 80% of the processes out there could be implemented with human-centric BPM tools used by business people. Unfortunately, the same folks were nowhere to be found when challenged to substantiate their claims. It gets even better when they use a 98-2 rule. How about 99.8-0.2? Would that work better? No matter how ambitious you are, if you’re selling human-centric BPM tools, all you’re doing is selling eye-candy user interfaces slapped on top of a lot of code written by your professional services group. Your customer might never notice, but I doubt it will experience the kind of Return on Investment that BPM can legitimately promise. […]
Trackback this post | Subscribe to the comments via RSS Feed
Leave a Comment