Just Do It: Part 2: The Triumph
Last time, I noted that the history of business process automation has been plagued with complexity, cost overruns, and outright failures. I promised that my next post would explain how BPM moves us beyond the bad old days, and why that means we can abandon the “fix it before you automate it” mentality.
1. Rapid deployment
Early BPM products (and, unfortunately, some current ones) assumed that process deployment would continue to be in the domain of programmers, and therefore were built with programmers in mind. Happily, many solutions today enable creation of complex workflows, eforms, and reports by anybody with a reasonable facility with technology (and a strong understanding of the underlying process). Thus, not only is it less expensive to deploy each process, there is also a greater percentage of the staff who may be trained in doing so. Result? Faster deployments, faster changes. BPM is the sword that has at last cleft the snaking queue of IT projects.
2. Delegation
When all change requests have to go through a single window, there’s going to be a wait, and that wait translates into additional cost. BPM, however, enables us to delegate different parts of the problem to different individuals. Don’t like where that request gets routed? The workflow person will change it. Think that the approval levels need tweaking? The business rule person will take a look. The expertise required is around the process itself, and not the obscure language in which that process is expressed. Delegation results in faster, easier, and less risky process changes.
3. Real time and historical data
Under the old model, a process that goes off the rails might stay there, burning cash, for a very long time before being fixed. The risk is open-ended. Using BPM, however, there is a constant flow of real time and historical information available about each process instance, and the process experience as a whole. The implication here is that I not only don’t have to fix my process before deploying into BPM; I actually don’t want to. A full-featured BPM solution will help me find and fix that problem faster than I can do it otherwise.
That last bit bears repeating, because it illustrates my whole problem with the “fix it first” school of thought. Why wouldn’t I want to use a tool as valuable as BPM to surface and repair flaws in my process? Am I more likely to find the issue, and design around it, by filling out dozens of swim lane and RACI charts in the course of interviewing mobs of process actors?
I don’t think so. So take a deep breath and jump right into the BPM pool. The water’s great.
Leave a Comment
You must be logged in to post a comment.
