How can the high failure rates of ERP systems (up to 70% according to industry analysts) be reduced? Some suggest that often age-old processes (e.g., process insurance claims) need to be ‘re-engineered) to industry best-practices. If not, expensive workarounds will be need to get rid of inefficient practices.
Others say that BPR before ERP sounds is good in theory, but not always practical. They say “let’s implement the system first, make sure everything works and then re-engineer processes. This can reduce risks of systems not working.
Any highly regulated industry should definitely have its processes in order and standardized before attempting to implement an ERP. They could be subject to legal troubles, if they do not design in traceability and connections to information where necessary.
BPR should always proceed an ERP implementation, despite the frustrations that this may cause on the part of both parties. Allowing ERP to precede BPR seems it would be a good idea in some places, allowing the natural agility of an engineering team to outpace the bureaucracy of a front-office. However, unchecked implementation can lead to scope-creep from just about any project, resulting in a system that does more than it needs to and wastes resources unnecessarily. The seeming minutia of BPR allows for the filtering of good ideas to the essence of the necessary. Without these steps, an organization would bloat beyond its capacity and collapse. Moreover, it ensures that projects are properly prioritized, as those in charge of building systems aren’t necessarily protecting and organization so much as they are protecting their team.
PR should always precede ERP implementation!
BPR has been touted by many as dramatic improvements become necessary for organizations to improve competitiveness and remain strong participants in economic development .
That is due to its basic principle of re engineering. If a company rushes to install an enterprise system such as ERP without first having a clear understanding of the business implications, the dream of integration can quickly turn into a nightmare . These are not technology problems. These are process problems—problems that result from a failure to recognize that process excellence or systematic thinking is necessary to make enterprise systems succeed. Consequently, BPR is supposed be done as a required precedent step for the implementation of ERP.(Eric Y. June 14-18, 2006, pp. 201-213.)
I strongly argue that BPR should proceed ERP!!