First things first – make sure that there is both a mandate, and funding, for the work you are doing. If you require the support from within your company to get started with BPM, you should concentrate on building a business case for your BPM initiative first.
Even when the process is being automated without major changes to the way work flows through the company, the users themselves will experience a disruption. BPM always represents a new way of doing things. Therefore, both business managers and end users need to recognize the problems with the existing process and have a desire to fix them.
With that out of the way and a business sponsor firmly in place, a good cross functional team should be formed to guide technology selection. This should include business process owners, managers within the line of business, business analysts, and developers. The business people will represent the end users and may want to involve a real live end user or two in the selection process.
Once technology is chosen – covered above – the planning begins. There are several important tenets of BPM planning:
- Be iterative. BPM software is designed to accept a lot of change during the development process. Allow this to happen as requirements change; make sure to show prototypes to users often and gather their feedback.
- Don’t forget user testing. When Microsoft rolls out a new version of Office, changing the way millions of people work every day, they do extensive user testing. Rolling out a newly automated process has just as much – or more – impact on your users.
- Gather requirements up front. This may sound like the opposite of being iterative, but the best time to get end users involved is at the very beginning. BPM tools come with process modellers that, when used properly, should speed requirements-gathering and act as an excellent tool for business/IT collaboration on the definition of the process.
- Involve end users. This doesn’t mean the managers of end users – managers usually don’t know the details of the process definition (though they sometimes think they do). The existing process documentation is almost guaranteed to be out of date, updated by hundreds of memos over the years that are now embedded in the end-users’ heads. The best way to catch an incorrect process definition is when a user spots a missing form field or gets work at the wrong step in the process.
While we’ve listed a number of best practices in getting started with BPM, the key is to get started. Many companies bog down in planning or become too risk averse, but the reality is that every month you continue to have inefficient people and processes result in serious opportunity cost.
I hope you can take some useful information away. As always we would like hear your thoughts on this.