The internet (or that part of it which follows BPM) was alive with discussion last week about the announcement from Salesforce.com that they have created a tool which will allow their users to design and run their own processes.Now before we go out and start wailing 'the end of the world is nigh' let's get a little perspective on this.
As Theo Priestley quite rightly said in his post on the subject
What a palava this is causing on the net newswires. Saleforce.com comes up with a process workflow tool and it's suddenly a BPM solution provider that threatens the world. Calm down. There are already solutions which offer the same simplicity, Casewise Synergy is one that springs to mind I saw last year. Fair enough it's not a Cloud solution (yet) but it offers the same web modelling capability by a business user to automate workflow simply using form based methods. Ask Alcatel who have been using it extensively for a year. It was built in conjunction with PNMSoft btw...
Matthieu Hug from runmyprocess.com also weighed in on the subject saying:
It's a fact that most BPM products are way too complicated, thus dooming a lot of BPM projects. It doesn't mean that BPM approach is doomed in general. Only that BPM is not an objective, just a mean to reach IT agility (the real goal). So there room for innovation, and as usual it cannot come from incumbent players.
For that reason BPM market will expand, but driven by pure SaaS players, not by traditional BPM vendors. Cloud and SaaS are deeply transforming IT, and the BPM market will be no exception.But the underlying issue - and the one that I keep coming back to when I read things like this is "Should we be letting the users define their own processes?"
Well, there are two schools of thought on this.
The first school says "Of course we should. The users know their processes better than anyone else. Keeping IT out of the picture will keep costs down and it will make us more reactive and efficient"
The second school of though says "Letting inexperienced and unqualified people define, create and manage processes is a recipe for disaster"
I subscribe to the second school. Here's why:
"The users know their processes better than anyone else" I would maintain that this is an urban myth. The users do not know their processes. They know what they do on a day to day basis. That's different. It may not be the right way of doing things. It may not be the most efficient way of doing things. All it is is the current way of doing things. With a lot of users if you gave them the ability to automate their process they would end up creating an automated version of an inefficient process. If you think I am saying this as a business process consultant who fears for his livelihood then think again. For the last 20 years or so the user base has been merrily creating applications of its own using tools such as Lotus 123 and Microsoft Excel. There has been no control over these applications, no management of the spread of them, minimal - if any - quality control over them and no general overview to stop duplication, replication and proliferation. As a result there is a large amount of overhead hidden within the user base in managing and maintaining these. Consider that every time Microsoft updates their software the 'business' should go through a validation process with the new version. And have you ever stopped to think how many similar Excel applications there are running across different departments when, in reality, they should be running across one?
I run process facilitation exercises for large companies wishing to define and manage their processes. As part of this I like to get the users in a room and ask them how they do their work. It is always amazing - and sometimes frightening - to hear users in the same department describing two or three different ways they perform a task - much to the surprise of their co-workers who always thought it was done the same way everywhere. How can a process like this be automated by a user if there isn't even agreement and consistency about how things are being done?
Finally there is the old chestnut of 'automating what we do now' rather than 'automating what we should be doing'. Most users - if given the choice of automating their current system or redesigning this system and automating the result - will, I believe, opt to keep the status quo. Reason? - Change. People don't like change. I've written about this before too .
Now, on the side of balance I must also look at this from the contrary point of view. Should IT be the only people who can run process projects? No. Of course not. I think it is ill-advised to believe that a business change project which is run by IT will be successful 100% of the time. It is, however, advisable to ensure that your process project is staffed with people who have a grounding in, and experience of, process management. I've said before on these pages that it is important to implement the capability of process change within your organisation. And this doesn't always have to be in the IT function. It is perfectly acceptable, in my opinion, to have a process management capability which is located within the business rather than IT, but which is cognisant of both IT and business issues. Indeed this is probably the only way to have a good process management capability within your organisation.
Summary
The next time some well meaning individual (or company) tries to tell you that the users should be in charge of their own processes remind them that the weight of evidence and history indicates this is a bad idea. The optimal solution is to have business process management integrated as a core capability in the organisation. Using accepted methods and standards the ideal processes can be defined and implemented and - more importantly - controlled. Whether this is done as an IT function or by the users themselves is immaterial.
Reminder: 'The Perfect Process Project Second Edition' is now available. Don't miss the chance to get this valuable insight into how to make business processes work for you.
Click this link and follow the instructions to get this book.
All information is Copyright (C) G Comerford
See related info below
