But the best differentiator pitch that I?ve heard being used is the ?business user oriented? vs ?programmer oriented?.
The claim is that business users can use the tool. I think it?s a great differentiator.? Although it usually doesn?t have much truth to it ? it?s still a great market positioning pitch.
You see.. (and I?m trying to hide my sarcasm here..) BPM tools that use programming are bad for you.
If you need to open Visual Studio to build a workflow ? it means you need skilled programmers, which means high salaries, and they need to write code, which means you need a tester, a team leader and a project manager (more salaries).
Every time the customer wants to change the business process you need the programmers to recode, recompile, retest (long deployment, or no changes ? you can pick). Sophisticated code means that you need to rely on the IT team which means that you are tied in with that programmer/team. If the programmer leaves ? no one will dare to change their code (who wants to be responsible for code that someone else wrote.)
"If you need to open Visual Studio to build a workflow" - then you're doing it wrong.? A good bpm tool doesn't require you to build your workflow in C++/C# or the like.
Of course if you're opening visual studio to do an integration - have at it.? To build something custom that will plug into your BPM solution - have at it.? BPM should make certain things easier than traditional development tools (and a "workflow" sounds like one of those things to me).? It doesn't mean that you won't still need traditional development tools for a BPM deployment, but you shouldn't have to write your process flow in assembly language any more than you should have to write it in C++.
Incidentally, I don't agree that "business can do everything" is a good pitch, though I do agree with Adam that it is horribly oversold.? The business and IT have to work together to make BPM successful (or, arguably, nearly any long-term IT or business investment).? Vendors oversell this all the time, which accounts for Adam's sarcasm.? But, conversely, companies purchase tools that bring too much complexity to the simple stuff, or tools that start simple but don't scale with complexity.? What do I mean?? I mean that as you add more process intelligence to your tooling, complexity should increase at a linear (or less) rate.? If you experience complexity increasing at a greater than linear rate, you'll hit a point where the system can't be maintained - the interconnectedness and interdependency of the system is too complex for someone to properly understand, modify, and maintain.
That's why it is important for the "workflow" to be simple.? Because it can be.