As time goes by, technology increasingly is becoming intermeshed with all types of organizational activities. As this trend continues, I worry that we sometimes look to technology as a replacement for quality business process management (BPM) infrastructures, systems and practices.
I can't count the number of times I've had to talk someone off the "buy technology so I don't have to change my wacky process" ledge. A few years ago, during the early days of the Sarbanes-Oxley panic, I was new to a company whose entire SOX focus was on finding software that would ensure SOX compliance. Needless to say, its project was in serious trouble. We changed the focus to implementing quality, standardized processes; breezed through compliance; and only then purchased software that simplified our tasks -- not software that helped us comply.
My "fix processes before implementing technology" attitude has influenced how I view such things as BPM systems. I love the idea of business process management, but the tools to manage those processes need to be simple to implement and use. Existing BPM tools tend to be large, expensive, difficult to implement and hard to use. Even worse, existing BPM tools seem to be designed to compensate for overly complex processes and an excess of exception handling.
If we focus our efforts on streamlining and improving processes, the need for BPM might either go away or change for the better.
As an example, think about one of IT's more important processes: project management. Almost independent of whatever project management methodology you use (PMI's, Agile, critical chain and so forth), there are some common project management success factors. I have found that if my project teams have nearly immediate access to the project's stakeholders -- those persons who can make decisions about priorities, timing, functions and feature tradeoffs -- the project most likely will succeed.
In project management, I also have found that success rates increase if we break large projects into smaller, more frequent, incremental deliveries. What do these project management success factors have to do with BPM? That is exactly my point: They have nothing to do with BPM technologies. If I want to manage my project management process better, I should focus on improving access to stakeholders and incremental delivery. I am not sure that implementing BPM tools makes that job easier.
I am not saying that there is not a role for BPM. Rather, if you're considering BPM, here are some things you need to remember:
- Select BPM tools that are lightweight, simple to implement and simple to use. The last thing most of us need is a new, heavy, complex enterprise system to implement and manage.
- Clean before using. The need for BPM often is driven by an organization's need to improve how it handles myriad exceptions and system complexities. I like to start by asking what value the organization is getting from those exceptions and system complexities. Do we really need a separate employee reimbursement system? Or can we reduce system complexity (and the need for a BPM tool to manage the workflow between systems) if we treat our employees as vendors and process reimbursements through our existing accounts-payable process and system?
- Use what might exist already. Many of our existing enterprise systems include workflow management tools that can meet our BPM needs -- particularly if we first clean up our processes and minimized exception handling.
- Question the rationale. Over the years, BPM vendors who have worked their way into my office to make their BPM pitch have told me wonderful stories about the benefits of using their tools. I am sure that somewhere there really is a company that has used BPM to reduce headcount by 50% while increasing throughput by 100%. I expect, however, that this experience is the exception. I like to ask for examples of similar-sized organizations in industries similar to mine that are using BPM tools successfully: These are stories that I can relate to my situation.
Lest I sound like too much of a BPM skeptic, you should know that the SOX software we selected, installed and successfully used was a BPM tool -- but we used it to automate a tight, well-defined process. If I am considering a BPM tool to solve my processes' weaknesses, I think I am looking in the wrong place.
Niel Nickolaisen is CIO at Western Governors University in Salt Lake City. He is a frequent speaker, presenter and writer on IT's dual role enabling strategy and delivering operational excellence. Write to him at firstname.lastname@example.org.