BPM: Business Users and Programmers

“The short road to ruin is to emulate the methods of your adversary.” — Winston Churchill

I would love to be able to stir up some excitement, telling you about the fierce competition we have in the BPM industry, but alas, unfortunately there is not much to stir up about. Most of the vendors have their own niche in the market and are happy working away. Growing slowly but steadily. Acquisitions have reduced the number of vendors. Most of us get along nicely with the other competitors. There is enough food for everyone to eat… I know… a little boring…

So it’s left to the sales and marketing teams to find the differentiator.
Sales guys like to be able to present a nice “them vs us” pitch to try and win the deal.
In an industry that nearly all of the tools has the same functionality, a differentiator must be found

• Microsoft based vs Java Based
• Web-based vs Desktop based
• Commercial vs Open Source
• Local vs International office
• BPMN vs non BPMN
• Size vs Price

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.)

On the other hand.. “Business User” BPM tools are simple, easy to use. The business user can create their own workflows, change them when needed, controlled by the “business user”, empowered…

Ahem… [cough], [cough], [cough]…

So, who are these business users we all talk about?
The CFO? The department head? The EA? The Business Analyst?
Luckily (me being sarcastic again..) BPM projects never include integration or customization, so BPMS tools are therefore perfect for business users.

Sarcasm aside, BPMS tools are great when used by the vendors implementing at the customer site. If you’re lucky the customer will allocate some of their IT team to learn how to use the tool and build an internal BPM development team.
The advantage of these visual drag and drop, wizardry process designers is that they speed up development time. Projects that take months in coding environments – take weeks in the new process designers… and that’s a big save (money, time and risk)

Truth be told, business users will never build the whole workflow. If you’re lucky they will design the process skeleton.
Designing the forms and fields – IT. Integration – IT. Custom product changes – IT.
The myth of the seamless “hands over” between the business users and the technical teams… is a myth (..but a nice myth I must add)

BPM software has made process design and implementation easier, but maybe not easier enough.
Wizards, intuitive as they may be, have still not enabled business users to take end-to-end responsibility of the process.