Do You Like Your Workflow or BPM Software?

Dukhat asks: "I am really interested in firsthand experiences with these kinds of products and in unbiased reviews, since Google primarily gives me marketing information and vague overviews of how BPM is good for business. I have already looked at an earlier article on work-flow patterns, which gave me a few products to look at. I am trying to compile a short list of work-flow and BPM software to evaluate, but I am having a hard time determining which products are even worth evaluating. The situation is worsened by the fact that work-flow tools are often bundled with CRM or Business Intelligence packages. I am not dead set on using a big package, but I need to know more about their real world pros and cons before I can decide whether to build it myself instead. I am looking at both BPM and work-flow software, since some BPM software can also do work-flow, but it may be more worthwhile to just use a rules engine for automated processes and use a specialized work-flow tool." Dukhat has a fairly long list of software choices that he needs to whittle down. What packages would you recommend and why? "Here are some of the goals we have that we are trying to solve with work-flow/ BPM software:

• To be able to understand the path of a process without perusing in and out of a lot of functions.
• To be able to report on how long each step in each process takes.
• To be able to see exactly where in the process software errors occur and be able to skip over failed steps so that we can come back and fix them later.
• To be able to integrate with our issue tracking system, billing system, and CRM software. We definitely will have to write some webservices here.
• To be able to give process managers in different departments the ability to tweak certain processes without giving them full access to all processes.

We started off looking at rules engines, but it looks like a rules engine would only be useful for choosing actions at each step in the process, but we would have to glue together each step in the process ourselves. A lot of BPM software includes business rules software or is designed to integrate easily with specific packages.

Here is a list of packages that I have assembled so far:

• JBoss jBPM & Rules
• ILOG JViews & JRules
• webMethods & Blaze Advisor
• Oracle BPEL Process Manager
• COSA
• FLOWer
• Microsoft BizTalk
• Lotus Workflow
• Global360 BPM
• Bizflow
• WebSphere MQ Workflow
• Tibco BPM
• Fujitsu Interstage
• FileNet BPM
• Savvion
• Pegasystems
• BEA AquaLogic with Fuego

Please help me narrow these down. Thanks!"

Comments

Opaquely transparent agenda

[strangedays]

These questions appear to be mal-formed and the sub-text obvious. The interesting thing is why do this on Slashdot? I'm guessing the preparation of a future appeal to perceived authority, potentially coupled with a rush to judgement?

There may be no such thing as a dumb question, but be real careful... there is such a thing as an inquisitive idiot, so lets be sure that doesn't apply here...

* To be able to understand the path of a process without perusing in and out of a lot of functions. Huh? Whatever do you mean? Its a process. A process is not necessarily instantiated in software. Or to put it another way, if your a real business guy, you do what it takes, not what you prefer to peruse.

* To be able to report on how long each step in each process takes. This is trivially simple, whats the issue? Do you really need a consultant to hold your watch and tell you the time?

* To be able to see exactly where in the process software errors occur and be able to skip over failed steps so that we can come back and fix them later.

Why do you expect software errors, before you have even selected a package? If a business process has a genuine fault, and is broken, continuing the process and hoping to fix it somehow later sounds like a dumb business move to me. "yeah Boss we sent out the wrong orders, to the wrong addresses, I figured we'd fix the software issue later... ok?"

* To be able to integrate with our issue tracking system, billing system, and CRM software. We definitely will have to write some webservices here.

Aha! Isn't this what you really want to do? Come on, admit it... Your itching to find a reason to develop cool web-services and some fancy infrastructure. Ok, who cares!, but it is a side issue to the described problem. Webservices, are just protocols, methods, used to access a real service, that someone may "write". They are not important, nor do they inherently solve anything.

* To be able to give process managers in different departments the ability to tweak certain processes without giving them full access to all processes. Well Duh. This must be obvious and trivial, RTFM.

Picking a package selection list, then trying to boiled it down using some simplistic check-box style assessment, coupled with an appeal to Slashdots perceived authority... That not a good idea.

Don't go there. Use some real business and systems expertise and analysis of the processes, with each item mapped onto a compelling business case and ROI. Yep, that's real work, it costs money and takes time, is it worth it... you bet. It's much better than screwing around with your business processes, using some checkbox selected packages, which will surely cost a lot more.

As another poster has already said, hire some business and systems analysis expertise.

Mostly flawed

[RubberBaron]

I did my Masters on workflows and workflow verification. In defining a workflow you are essentially designing a system that, in the 'old' days, was programmed. The program could be tested, for example, for both syntactic and semantic correctness with compilers, unit and functional testing.

On the other hand, every (commercial and other) w/flow system that I looked at, except for one or two academic systems, had (usually) the same set of major flaws, mostly in terms of verifying the workflow. There could often be logical inconsistencies, they would, for example, easily allow deadlocks and livelocks and, as for defining business rules, there are holes everywhere. Holes which (through robust procedures, training etc.) are minimised in the programming world but which are put into (business) critical systems by people who can barely spell 'progremn'.

Would you, for example, alter the flow based on data output by an activity/action/state (or whatever your BPM system calls the 'blobs' that do most of the work)? If so, what happens when you have a SPLIT object somewhere (the flows split into more than one flow)? Is the data copied across the SPLIT to the multiple output flows? Is it a deep or a shallow copy? Deep or shallow copies can have ramifications to actions/activities/states downstream of the flow.

I came to the conclusion that good, verifiable workflows had to be as simple as possible. No business rules, for example, only simple 'decision points', quite strict restrictions on data and control flows especially through control nodes. No commercial system seemed to follow my conclusions, they seemed more intent on producing pretty graphics and I would be wary of using any of them, especially given the prices they charge...

One Slice of the problem

[jafiwam]

So.

What's your problem?

Seriously, you want to buy software.

Why?

That's probably one of the most important bits of information you'll need to decide what package you need. And you left it out. I see a bulleted list of goals. But what made you decide to get going buying BPM?

Say, if it's a regulatory body saying you need something, make sure what you get will help satisfy them. Etc.

Also, though I work in a very small company, all the process analysis in the world means dick if you don't have someone going around and beating the crap out of the processees to do things differently. Expect to meet up with little fifedoms, power hungry people, people who won't change and will throw up roadblocks because they are lazy, or think you will process them out of a job. Make sure you got upper management who is clueful and will do that stuff for you or just drop the project as failed already. Some guy that needs to write to AskSlashdot probably doesn't have the juice. So get the juice first or you are already fucked.

(Note, I did process analysis for the "Baldridge" crap a couple years ago, and used nothing more than pen and paper for most of it. Finished product used one sheet and an overall flythrough flowchart. But then the process was simple enough that I could sit with someone and get the data I needed. If your problem consists of a large company wondering why processing rebates takes to long something that integrates is a good idea.)

Conversely, widening the list...

[mengel]

We've started a project using AlphaFlow in Plone from our Oracle database; we've had to do some work to define things like who has what role related to what object; but of course you have to do that no matter what package you use.

And the costs are similar to other Open Source packages -- paying your own people to read the source, rather than paying some other big company to do it for you.