BPR AND ERP: THE CHICKEN OR THE EGG

Well-known management guru, Tom Davenport, views as a key success factor to a holistic approach to ERP-related change, the need f or a simultaneous and integrated approach to strategy, organisation, process and systems change . In this paper, the key issue under discussion is the timing ofbusiness process reengineering (BPR), and the implementation of an integrated package solution (ERP) solution, i.e. should these happen simultaneously or should the one be before the other. Consequently, these three alternatives are considered together with respective associated benefits and risks. None provides a clear-cut indication ofa "best " approach towards BPR and/or ERP. Given the similar approaches to ERP and BPR, a hybrid approach is suggested with projects containing separate but integrated reengineering and system implementation components.


THE ISSUES
Davenport's [1] advice for an integrated approach might be a little late for many organisations already well underway with ERP implementations.The tough choice many organisations faced during the past years (and some of the late adopters still face this) concerns whether to reengineer processes before implementing ERP solutions; at the same time of implementing ERP; or after the implementation.In some instances they even question whether they really need any form ofprocess review.
In many instances, the Y2K threat answered this -in the end there was no time left for both reengineering and solving information architecture problems.The trusted wisdom of not automating old, inefficient processes, or "paving the cow paths", as Hammer [7], father of Business Process Reengineering puts it, is being ignored with lack of resources (especially time) as the culprit.
The days of reengineering being the solution may be over, but it is generally accepted that the need to identify, improve and manage business processes has not disappeared with the decline in popularity of reengineering.More than ever, do organisations realize the true cost and restrictions outdated processes place on them.ERP has been seen as the silver bullet to resolve Y2K issues and clean up processes at the same time.ERP software is designed to model and automate many of the basic business processes of an organisation, with the goal of integrating information across the company and eliminating complex, expensive links between legacy systems -the latter seemingly the strongest driver towards ERP.The price organisations have to pay for this automation is generally high.According to Davenport [2] the real challenge organisations face after successful ERP implementations is "to use the resulting process-oriented real-time, global information to change how the company manages and does business." The key questions to be answered when organisations consider ERP and reengineering are: • To what extent the reengineering is needed • Which processes should be reengineered • When this should be done (before, during or after the ERP project) • What the benefits and risks to be considered are.
This leads to the key focal point of this paper, i.e.where does reengineering (or process redesign or whatever a company wants to call its cleanup of existing ways of doing business) fit in with ERP.

BPR AND ERP: THE ALTERNATIVES
Following from the above, three alternatives come to mind:

Reengineer first, then automate
In the perfect world, one would like to complete rigorous reengineering, using a cleansheet approach before looking at any system solution.ERP would then be waiting; ready to automate and fulfill the company's every demand streaming from the new http://sajie.journals.ac.za processes.This is not quite true.If one takes a "blue sky" approach to reengineering, the results often do not translate into implementable solutions.SAP R/3, the leading ERP package, hardly offers a clean sheet of paper for process reengineering.The package, or any of the major ERP packages for that matter, consists of a complex array of structured processes, which will dictate change and subordinate ambitious reengineering goals to getting the system up and running.Thus, it brings its own reengineering (second generation reengineering), but with a different set of objectives Davenport , who assisted in the creation of reengineering together with Michael Hammer and James Champy, equate the "Let's reengineer from a clean sheet ofpaper and then see what ERP can do for us" to an approach like "We'd like to rewrite one of the SAP modules" (Davenport, [2]).And, according to Bancroft [3]: "You don 't want to get too far down the reengineering path without keeping R/3 in mind".

Reengineering and automate all at once
In theory, this may sound like a good approach.The reality ofERP packages like SAP, Oracle and Peoplesoft, are that they are extremely difficult to implement.The major reason for this is the way they change people and their roles in the organisation.People are dealing with levels of integration never experienced before.ERP forces every employee who touches it to understand exactly what their business is about, and how it will impact on their customers (internal and external).
In implementing SAP R/3 without prior reengineering, SAP R/3 could dictate the business process design, which could either be to the benefit or the peril of the company, depending on its specific circumstances.
Many projects start as a combined ERP and reengineering project, and end as either implementing old processes or "generic, out of the box" processes, due to budget and timeline constraints, and the complexity ofERP package implementation.

Implement ERP first; reengineer afterwards from a stable base
This has become a very alluring alternative.Organisations see ERP as the opportunity to stabilise infrastructure problems and cost, eliminating complex interfaces between legacy systems never developed to talk to each other while solving Y2K problems.The added benefit is then perceived to be the opportunity to reengineer later from a stable base.
The biggest problem with this approach, apart from the costliness (both in real and opportunity costs) resulting from automating old processes, is that organisations almost .always seem to underestimate the impact ERP would have on their organisations.This culture shock remains for months, if not years after implementation.ERP software imposes major changes to the very nature of what people do.(For example, it will transform order-entry clerks into business people, impacting on the company with every transaction they do.) Another downside of first implementing ERP, is that the software cannot address operational inefficiencies that arise due to policy or process flaws.The ERP solution works according to pre-defined policies and procedures.Operational processes need to be optimised before an ERP implementation.This is the main reason why an ERP implementation project is typically preceded by a reengineering exercise.
For the many organisations implementing ERP without prior reengineering, the approach should be to complete the implementation, stabilise the company and then perform reengineering on selected processes, hopefully with the benefit ofhindsight.
The above three alternatives are summarised in Table 1.

ERP dictates processes
Shorter time to systems benefits

ERP SOLUTIONS: THE GOOD NEWS AND THE BAD NEWS
Managers utilise scarce resources only if they take an enterprise-wide perspective.This is where ERP comes into play.ERP, utilising packaged software solutions, enable organisations to integrate major areas of their business such as finance, distribution, sales plant maintenance and production planning.
Application packages have largely become a part of the average technology architecture .It is important to understand how these packages are selected and deployed, and what will be needed to integrate the software into existing environments.
The good news about ERP packages are: • They can be faster and easier to implement than custom developed systems or a mixture of best-of-breed solutions; • Best practice business rules and workflow tend to be already implemented in the package application; • Packages come with regular upgrades and support, enabling organisations to keep up with new trends and statutory requirements e.g. the Euro dollar, and budget for maintenance as a stable cost ; • ERP packages have a positive influence on communication within a company -it forces individuals, departments and functions to communicate; • As mentioned , it helps individuals realize their role in the larger organisation.Everybody touching the software has a "customer" that will be influenced by it.
It goes without saying that there is a price to pay for the mentioned advantages.These include: • The temptation to engage in "silver bullet" thinking (thinking the application would provide the complete solution to all organisational problems).
• A loss of in-house control over features and functionality.
• The inability to meet unique business requirements , or use information systems as a competitive advantage.
• Expensive and time consuming to implement and stabilise within the organisation .
Implementing an ERP package is no easy task.Many organisations have tried and failed, and the list is growing.It will require 100% commitment from the sponsors and the project team, and continuous executive support to improve changes of success.
If ERP is correctly implemented, with clean processes driving the business, the results could be spectacular.Dell Computers, and their DIRECT MODEL (refer Figure 1) is a good example.Dell's success is partly due to the way they use information to speed up execution of every aspect of their business.True virtual integration is the next step beyond the Dell model, and requires reengineering with the complete value chain seen as one.The following diagram reflects the evolution an organisation could face by utilising the best ofERP and reengineering.
The DOMINANT MODEL a value chain with arms length transactions from one layer to the next.

Manufacturers
The DIRECT MODEL eliminates the time and cost of third-party distribution (made popular by Dell).

EVOLUTION OF A FASTER BUSINESS MODEL
This evolution above (refer Figure 1is made possible by the successful combination of ERP and business reengineering.It could be possible without the combination, but at substantially higher cost and risk offailure).
Some best practices in performing reengineering and implementing ERP systems will be discussed in the subsequent section.

Best Practices for Reengineering
In their 1995 book, Carr and Johansson [4] identify best practices that organisations adhered too to make their reengineering projects successful.These are listed below with comments added by the authors .

Maintain teams as the key vehicles for change
Quickly come to an As-Is understanding of the processes to be reengineered For most organisations even considering reengineering, there are very obvious and compelling needs to change.Out of control costs , falling profits and margins and many other reasons could drive this.
Strong leadership by the CEO is important, with buy-in from the executive level.
Understanding the need for change is the easy part .
The real challenge lies in determining how ready an organisation is for change , and adjusting the approach accordingly.
Effective communication of decisions and motivations for decisions would play an important part in preventing too much negative political activity .
Form collaborative teams to address specific issues.
The correct use of consultants is a major determinant in the final cost and success of the change.An organisation's in-house skills and readiness to break away from the past, should be considered.
This should be true for both in-house and external customers.
Very important.Given the time and cost constraint, careful selection would be needed.
Selecting the processes that really will reduce cost and affect customer service.
BEST PRACTICE

COMMENTS
Choose and use the right Depends on the processes chosen for reengineering.metrics Understand the risks and develop contingency plans Have plans for continuous improvement Source: Carr,D and Johansson,H [4]

5.2
Best Practices for ERP implementation In her guideline 1996 handbook, Bancroft et al [3] list the following critical success factors organisations have to adhere too to increase there chances of an successful implementation (refer Table 3).Comments and interpretations are those of the authors.Choose a balanced team, and give clear role definitions.
Select a good project methodology with measurements.
Train users and provide support for job changes.
Similar to the best practice for reengineering.The readiness is there, and is providing the leadership and direction needed.The political culture of the organisation should also be considered.
Similar to the best practice for reengineering on communication.
Similar to reengineering.
Powerful, experienced leadership is critical.An independent consultant might have to be incorporated on the management team to facilitate and add objective edge to the project management.
Measurements should again tie in with the business drivers for completing a successful project.Change management would be very important.

CRITICAL SUCCESS FACTORS COMMENTS
Expect problems to arise, commit to change.

Source: Bancroft, Seip and Sprengel [3J
Comparing these critical success factors with the best practices for reengineering discussed before, there are significant similarities.The software solution under discussion (and the same applies for similar solutions) are known to trigger reengineering to enable implementation.
A general guideline is that minor process adjustments could be accomplished while implementing the system, but large scale engineering should be done before implementation.It is advisable that the reengineering team should obtain some level of training on the system structure, and that at least a high-level initial design be completed of a proposed architecture within the business.Also, at least one system specialist should be included in the reengineering project team to help prevent re-work as far as possible.Reengineering after the system implementation is not advisable, as the system has a strong learning curve and some stability is advisable to give users a change to adopt.
The following factors should be kept in mind: The time needed to implement the integrated system It is a fairly time consuming process to successfully implement large integrated systems.Furthermore, it takes a substantial amount of resources to implement this.The timeline issue is generally one of the biggest influences on a decision regarding ERP and/or reengineering.The more immediate risk of having key resources focusing on anything but their most immediate responsibilities for an extended period of time is often a big concern to organisations.Add to that the rapidly changing environments many organisations operate in today, and one.

(ii)
The political minefield Change brings uncertainty.Uncertainty is a breeding ground for unwanted political activity that could further strain limited resources.Project management, change management and communication are key areas often neglected for either or both the reengineering and ERP projects.

(iii)
Unanimous executive sponsorship Different opinions regarding the value ofERP and reengineering are to be expected on every level of the organisation.Top management is no exception.To enhance chances of successful change of the magnitude ERP or reengineering dictates, the unanimous support from the executive level needs to be gained, made visible and communicated to the entire business.

Table 3 :
Critical success factors to successful implementation CRITICAL SUCCESS FACTORS COMMENTS