ERP: The Business Process Reengineering 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 a larger Business Process Reengineering 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 Business Process Reengineering 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. This business process design exercise should take place in advance of ERP software selection, and should inform the scope and functional requirements for the selection project. In many cases the initial business process design work will be at a high level and detailed process reengineering will occur during the ERP implementation. For other, more generic, processes they will use any best practice processes or pre-configured templates provided as part of the ERP solution (as long as they’re suitable, naturally). This approach helps reduce the overall BPR effort while taking advantage of any standard practices and process templates supported by the ERP solution.
Conclusion:
Clearly there are many more possible scenarios that the three outlined here, but in general it’s best to conduct a Business Process Reengineering exercise in advance of ERP selection with the outputs 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 business process design 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 check out our Business Process Improvement service or send an e-mail to John Donagher.
