To BPR, or not to BPR, that is the question

The timing of Business Process Reengineering (BPR) efforts in the context of selecting and implementing ERP is a dilemma for many organisations. Many companies recognise the benefits of taking a new look at the way they do things when implementing ERP but baulk at the thought of the costs involved. Surely there’s a way to get better value out of ERP by improving the way your processes work but without going through a full scale BPR exercise?

Say you’ve done all the right things in your ERP selection process – you’ve surveyed the market, documented your requirements, had the vendors demo their systems and done your due diligence with reference checks – and you’ve done the deal with your preferred vendor. The implementation looms large, and very soon your team will be sitting in a room with implementation consultants who will ask “how do you want this to work?” What happens next has a huge bearing on the success of your project.

If the team knows exactly what you want then rapid progress can be made towards the design of a system configuration to support your processes. If the team don’t know what they want then you could well be in trouble. ERP vendors factor very little time into their consulting services estimates to help you figure out what the process should be. They expect the client to come to the table with a reasonably coherent view of what the solution should look like; this gives them a starting point for configuring the system which will be fine-tuned as the project progresses.

Clearly in some parts of a business it’s perfectly normal and advisable to keep things as they are: in essence the new system must replicate what the old system did. However some level of preparatory work is going to be hugely beneficial for all of the processes and functional areas in scope: 

• In areas that differentiate your business you may be reasonably happy with the process but want to take the opportunity to look again at how things are done and make minor improvements; at a minimum you should know what your key objectives are for these areas.
• Areas outside the scope of existing systems or where you rely heavily on spreadsheets are likely to change substantially: you will need to know what you’re trying to achieve.
• Some areas may need a complete rethink.

A good approach here is to review all your processes and take follow-up action based on the level of change envisaged:

• Low level of change: Identify high-level objectives and benefits that should be borne in mind during the design process.
• Medium level of change: Draft high-level to-be process maps as well as identifying high-level objectives and benefits that should be borne in mind during the design process.
• High level of change: If a radical overhaul is required then you probably need to conduct a full BPR exercise.

The point is that you only undertake a full BPR exercise where it’s required and has value. Don’t forget that the objective has to be to have a clear vision of what you want when you sit down with the implementation consultants: you probably don’t need to agonise in detail over every process to get to the point where you’re confident that you know what you’re aiming for.

All of this brings me back to the question I asked at the beginning of my previous blog, The Business Process Reengineering Dilemma  should you look at reengineering business processes before selecting a new system, before implementation, or during implementation? My view is that, in general, it’s best to conduct a BPR exercise in advance of ERP selection with the outputs from the BPR exercise driving the ERP selection project. This can be a tough argument to win in many companies, but the selection process often brings a realisation of the scale of the project ahead and the lack of preparedness for the task. Taking the approach I’ve outlined above is a sensible option designed to minimise cost, reduce risk and maximise the long-term benefits of investment in ERP.

Check out John's other related blog ERP: The Business Process Re-engineering Dilemma

This blog was written by John Donagher, Principal Consultant at Lumenia. If you would like further information on ERP Business Process Reengineering please send an e-mail to John Donagher.