Too Cute for Words
Bruce Silver's post about process optimization garnered a comment by Fair-Isaac's James Taylor. Bruce has recently spent a lot of time with Lombardi's product (TeamWorks) and presumably with Savvion and BEA. I don't know if James has seen any of these products (I know he hasn't seen Lombardi's optimization technology). James suggests that human-based process optimization built into these products might be "light" predictive analysis and that they sound "cute." Sort of like the (probably apocryphal) old country song where the guy doesn't know whether to commit suicide or go bowling, I find myself of two minds. If we give some pretty deep insight into big problem areas for our customers, and it seems so simple, that's a good thing... but methinks James is suggesting this optimization stuff is simplistic, not simple. So I'll take exception...
It might be useful to understand what the business problem is, and then discuss the technology being delivered... if something solves a business problem, and it does it in a "light" way, I would think that would be preferable to solving the same problem in a "heavy" way, yes? We (Lombardi) take pride in the fact that normal, non-technical people can use our optimization tools and gain value... (the deep thinking is built in... making it "light" because we've done the "heavy" work that's required to make any hard problem seem simple). We think it's an example of where a platform can be more than just an engine, because it understands the context of what it's being used for, and leverages that understanding through innovative tools for the business.
The problem we saw is that in human activities, there hasn't been any scalable way to understand the behaviors inside that black box of an activity without doing all the hard work James refers to. Our customers confirm that previously, they've spent lots of money, some of it mis-spent, trying to gather the data, build the ontologies, etc. to help discover, define and implement rules to make human-based processes more efficient. And getting the data was the most time consuming bit in many cases.
With a good BPM platform, at least that part of the problem can be solved. We know the structure of the data that passes in and out of every human activity... that's a big step forward. Additionally, we understand the context of that data with respect to the process. Putting these two pieces together (strcutured data that is constant for every activity of every process authored in the BPMS) we can give new, deep insight into correlations that _seem_ to be occurring inside the process. Of curse, as James says, we don't necessarily have _all_ the conext, for example, legal regulations. Additionally, we don't know whether this is, indeed, a correlation or a coincidence. Human rigor is still required once a possible correlation is found, but now it's highly directed rigor. This doesn't make the analysis less valuable, less heavy or, even ugly. It means it solves the first part of the longer process of understanding and implementing new business rules. Indeed, we call this capability the discovery of non-obvious business rules.
The analysis can give information about correlations that are occurring (e.g.: on Fridays, when the order is from customer x and the amount is above y the outcome is <this> 98% of the time). You can apply various complexity levels, you can set various thresholds of numbers of instances required to be valid, etc.
It all seems easy because first, it's a structured system... the ontology exists, if you will and the users don't have to deal with any of that. To them, they just look at the process drawing. But inside the system, that is a rich, structured semantic that can be put to use. Second, we are limiting our understanding to what our system knows.... obviously, in the real world, people then use this new insight to focus what they then go look more deeply into. Today, without this insight, the further ("heavy"?) thinking is either mis-directed because you don't have statistical backup for what you're doing, mis-spent because you work on stuff you can instead of working on stuff you should, or in the majority of cases, simply isn't done because nobody knows where to even begin.
By the way, we don't believe the world is anywhere near ready for so-called autonomic business processes (in this human activity area) for the very reasons James talks about. There are too many unknowns (read: contexts) to make changes in real-time, on the fly. Using our optimization technology, though, you are able to kick off a process to work on the optimization(s) that are suggested once thresholds have been met.
Using the new data and the built-in context that the best BPMSs are generating to provide solutions and insight to business problems, or to make the understanding of those problems more focused is a Good Thing. You could even call it _very_ cute.
Technorati Tags: BPMS, Bruce Silver


Hi James... yes, I agree... in this technology business we seem to set expectations too high, sometimes. Process optimization is a multi-discipline, cross-functional effort. Many processes have already got the "easy optimizations" built in, as a result of process improvement efforts of the past decade (or more). We're simply advancing the state-of-the-art here... but that's progress.
The next step is building a capability to model entities that live outside the process, but in a way that the optimization engine understands (in the same way that today it now understands the process context). These entities could be organizational, document-related, regulatory, etc.
But in the final analysis, for the foreseeable future, it's still going to take good old-fashioned human ingenuity to make final sense of the optimization suggestions, and approve them. In our view, helping these business-oriented humans is the real secret sauce of human-centric BPM... It's hard work and it's not just about workflow and integration, in fact it's only barely about those things....
Posted by: Phil Gilbert | September 01, 2006 at 05:40 PM
Now I just knew that flip little comment was going to get me in trouble...
I think there is a lot of value in companies optimizing their process execution, don't get me wrong, and I am sure that Lombardi's product does a great job of this. I just worry that companies will see process optimization in this sense as a substitute for process optimization in the broadest sense. Just like agility sometimes requires changes to a process, sometimes to the way decisions are made (the rules) and sometimes to both, I think we can classify optimization similarly. Sometimes I can improve a process, optimize it if you will, simply by evaluating the execution of the process. Sometimes I must consider broader implications. If I want to optimize an orgination process, for instance, I probably need to consider what kinds of accounts end up in collections and a bunch of legal restrictions. Optimizing the process steps might help with certain things and will definitely give me some good indications of where to focus my energies, it's just not a substitute for a holistic assessment of rules and processes.
At least I don't think it is...
Posted by: James Taylor | September 01, 2006 at 01:36 PM