While I was working on another blogpost, Peter Schoof put this beauty of a question online on the ebizQ forum:
“As Niel Nickolaisen says at SearchCIO, The best BPM implementations focus on keeping things simple, “My ‘fix processes before implementing technology’ attitude has influenced how I view such things as BPM systems.” So do you think processes should be fixed before implementing a BPM system?”
Here’s what I wrote in my response:
Fixing processes comes in two parts. One deals with logical errors in the sense of processes or parts of them not working, not delivering the required results or functionalities. The other aspect deals with the improvement of existing and basically usable processes.
What we tend to see is that broken or unusable processes are fixed to the extent that they can be implemented. Curiously, this usually comes under the headline of business process improvement even though you’re not really improving the business process but only making the BPMS deployable.
The downside is that (technical) BPMS restrictions either lead to a change in the minimally repaired business processes (resulting in BPMS being blamed for performing below expectations) or in perpetuating the quick-fixes.
Unfortunately [and contrary to the expectations the BPMS industry has created], we are still unable to conduct the process equivalent of open heart surgery. Once implemented, most processes have a smaller change and update rate than processes not tied to a system. This may in part be down to the BPMS but it’s also down to the mindset and methodology employed.
In practice, most still regard the ‘process’ from design to implementation as a one way street with a definite and defined ending: The release of the BPMS supported process.
Were you to regard it as a life CYCLE and continuous task instead you could probably improve/fix a lot of process aspects after an initial implementation.
But again, looking at real life what we see is that the technical aspects (need a new button, can you change the layout of the screen) are changed and tend to get confused with the business process requirements.
The long and short of it all is that the garbage-in garbage-out argument may in some cases be valid and in others less so. This unpredictable state requires a thorough assessment of the risks and consequences involved in fixing problems before or after process implementation.
While I was putting down my thoughts other replies flooded in, creating a very interesting discussion that might get you to re-think how to approach process improvement and automation projects.
As this issue is something we deal with on a daily basis, why not pop over to the Process TestLab website to find out more on how you can improve the quality of your processes prior to implementation.
