[This post originally appeared on Redux Online, where I am a guest blogger.]
Where I used to work (a big, now defunct, financial services firm), we automated everything. In the HR category, we had online, web-enabled processes for time reporting, employee status change, leave requests, bonus calculation, expense reimbursement, and on and on and on. On the operations side, we had similar online support for PO processing, invoice generation, ordering supplies, and so forth.
You might think that, with all this automation, we were extremely efficient. Unfortunately, exactly the opposite was true. Not only did these apps fail to save me any time: they weren't really intended to. Each had its own look and feel, its own data sets, its own supporting team of programmers and SMEs.
For example, rather than sending HR an email that said, "John X. is transferring from the IT operations group to the systems analysis group," or something like that, I had to navigate my way through one of the most non-intuitive, confusing, and clunky user interfaces ever designed. Because this same system was used for a number of HR-related tasks, over the course of my career I spent countless hours hacking my way through a jungle of a UI to complete simple administrative procedures. (Of course, delegation was rarely an option.) Worse yet, often I ended up having to work with somebody from HR anyway, as they had to jump in to either fix something I'd done wrong, or to bridge a gap in the system itself.
Think about your company's new employee on-boarding process. Is it smoothly efficient, built intuitively from easy-to-use components? Does it cover all aspects of the task, handling approvals, hand-offs, and dependencies in an elegant and transparent manner? No? How about invoice approval? How about expense reporting?
The fact of the matter is that companies are still, in the words of Nobel laureate Arno Penzias, running errands for their computers when the computers should be doing the work for them. We purpose-build systems from scratch, or acquire narrow, off-the-shelf point solutions, when we ought to be devising a general solution that can be applied to the array of processes that businesses run through each and every day. This is the promise of BPM.
It's also BPM's best-kept secret. Ask an average user what BPM is for, and they'll tell you that it's for automating manual processes. The more sophisticated among them might point out that their BPM solution provides a platform for modeling processes and connecting those processes with the data that drives them.
These are all good answers. But I suspect that, for the vast majority of corporate end users, the real benefit is more straightforward: BPM offers a consistent, understandable, and transparent mechanism that is reused over and over again to navigate a wide variety of processes. The end user can, quite simply, do her job, liberated from the training, troubleshooting, and hair-pulling associated with any large set of unrelated applications. And, in the end, getting the job done is what BPM is all about.