Compare 12 leading ERP products at 1 event

ERP: The Business Process Re-engineering Dilemma

Many organisations thinking about selecting and implementing a new ERP system find themselves in a dilemma – they feel that they should look at reengineering their business processes, but should they do it before selecting the new system, before implementation, or during implementation?

Most experts agree that Business Process Reengineering (BPR) should take place in advance of system selection, as the outputs from the BPR exercise should drive the scope and functional requirements for the ERP solution.

While that may be fine in many scenarios, it’s best to take each situation on its own merits. The optimal approach to take will generally depend on a number of factors, but a useful place to start is by asking: “What’s the strategic motivation for the ERP project?” Let’s look at a few examples.

Example 1: Global Business Transformation Initiative

We sometimes work with companies undertaking a global review of the way they do business. Everything they do is up for review: the goal is to transform the organisation by designing better ways of conducting business to meet future commercial challenges. Strategic initiatives such as Shared Services might be part of the scope of an initiative like this, and this has major implications for the ERP solution. In this context, a new ERP system is simply the technology enabling the implementation of the new business processes and the ERP selection and implementation is a work stream in the larger business transformation initiative.

Example 2: Business Process Harmonisation Initiative

This is very similar to Example 1, but the motivation in this case is around standardising ways of working throughout the organisation. This type of initiative often happens in larger multi-national organisations that have grown through acquisition. Each site or business unit has their own way of working, supported by legacy systems. The objective is to implement a single ERP solution to support standard processes across the whole organisation. In a situation like this it’s obvious that a BPR exercise has to come first.

Example 3: Replacement of an end-of-life bespoke legacy system

This one isn’t as clear-cut as the previous examples. You may well be dealing with systems that have been heavily customised over a long period, and the business may be reasonably happy with the way the system works. Intense resistance to any change is very likely in such a scenario. One way to deal with this situation is to take the view that ideal ‘to be’ processes will be designed and implemented in areas where the organisation believes that some sort of competitive or commercial advantage is derived from the existing processes. For other, more generic, processes they will use the best practice processes or pre-configured templates provided as part of the ERP solution (as long as they’re suitable, naturally). This BPR exercise should take place in advance of ERP selection, and should inform the scope and functional requirements for the selection project. In many cases the initial process reengineering work will be at a high level and detailed process reengineering will occur during the ERP implementation. This approach helps reduce the overall BPR effort while taking advantage of standard practices and process templates supported by the ERP solution. 


Clearly there are many more possible scenarios that the three outlined here, but 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. BPR teams should always include members with business systems expertise, whether that’s someone from the business with the appropriate experience or business systems analysts, to provide feedback on the practicalities of supporting the proposed processes using business systems. While it’s fair to say that the ideal approach to BPR involves doing the ‘to be’ process designs in advance of ERP selection and implementation, in practice a great deal of the detail in relation to any new processes is only worked out during the design phase of the ERP implementation.

Check out John's other related blog To BPR, or not to BPR, that is the question.

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