Posted by: Adam Deane | 09/08/2011

BPM: Business Users and Programmers

Bob the builder“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.


  1. Hi Adam,

    I appreciate the balanced, albeit boring, perspective. : )

    Another differentiator I’d add, run-time adaptation vs design-time change management.


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

  3. […] Adam Deane on Business Users and Programmers: 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. […]

  4. […] BPM: Business Users and Programmers « Adam Deane […]

  5. In my opinion its tough for Business Analysts to build a solution. Most of the “BA” friendly tools available are good for Reference processes but when it comes to real processes, customization is required. If you go back to your users and say you can’t have this because it will need coding – they will probably come back and say “Do the damn coding then ….”. If a process is not solving their problem then BA or Non BA – does not matter.

    Involving IT not only speeds up the delivery but helps you get tailor made solutions. Cost part … agreed.

Leave a Reply to If You Need to Open Visual Studio to Build a Workflow… » Process for the Enterprise Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: