An Expert Witnesses View of ERP failure

An Expert Witnesses View of ERP failure

We are asked by many law firms to analyse failed ERP systems and provide an opinion as to why they have failed.

Typically organisations resort to other means including legal action to get some form of satisfaction when their ERP project ends in some form of miserable failure. Failure in this context can take many forms; massive cost overruns, lack of system performance against expectations, complaints about inexperienced integrators, misleading and fraudulent representation and so the list goes on.

Our approach, as expert witnesses, is to look at the totality of the ERP project and the role of all of the interested parties. This includes the ERP software sales people, the system integrators and the implementing client company.

The term used to describe the relationship between the parties is called “The Devils Triangle.” The ERP sales people create an expectation via their sales pitch, web sites and glossy brochures, the integrators who attempt to implement the system to meet the expectations of the client and the client who struggles to implement the system and come to terms with the changes required to ensure a successful outcome.

Within each of the players in the devils triangle there are a myriad of issues that need to be identified and assessed. Our role as expert witnesses is to sort through these issues and provide an opinion in an unbiased way as an aid to the court.

The areas we focus on in our analysis are:

  •   What was required
  •   What was offered, in writing and verbal
  •   The reference sites
  •   The contract for supply and services
  •   The implementation project management and control
  •   The company role in carrying out the work
  •   The integrators roles in advising and assisting
  •   The identification of critical project issues
  •   The communication and escalation of critical project issues
  •   The expertise of the integrators
  •   The ultimate outcome

There is no doubt each of the different parties share a degree responsibility for ERP failures, but a key question to be answered is “Who carries the greater burden for the failure?”

Part of the problem in determining responsibility is that each party can legitimately point to the other parties and show failure to perform. The arguable point is always “Who were the experts guiding and advising on the overall ERP process?” These are the ultimate points that will be argued by the respective legal parties to try to apportion the blame and responsibility.

The reality is it is really in no one’s interest to engage in expensive legal battles unless it is absolutely necessary. Mediation should always take precedence over litigation to try to find amicable solutions.

Our expert witness analysis applied in a court of law always demonstrates the interaction of the parties in the devils triangle but also puts the spotlight on the “expert parties” who have the experience and expertise as key roles in ERP failures

Experience Worth Listening to!

Ray Atkinson

Atko Global

for more information goto http://www.atkoglobal.net.au

Effective ERP is about Change Management

Effective ERP is about Change Management

Enterprise Resource Planning (ERP) is now a well, established technology albeit a technology with a history of poor outcomes for organisations in terms of achieving expected business benefits.

Many organisations struggle to effectively manage all of the issues in the business that enables the technology to integrate and provide the information for the smooth planning and control over operations and as a result too many compromises are made reducing the effectiveness of the technology.

Change management is a critical part of any ERP project. Simply duplicating what the company today using a computer, whilst generating some efficiency in time and data accuracy, does not provide the platform for getting the maximum efficiency and benefit from the technology. The change management that is required revolves around reengineering not only the business processes but the reengineering of the management decision making process using the ERP technology to provide information.

The problem in change management is the perceived challenge to the entrenched managements control over different parts of the business. Managers will resist the changes if they believe their own authority is being diminished as part of the implementation. Operational individuals will also resist the changes if they feel they are being impacted in a way that affects their jobs.

Top executives tend to put changes that are resisted by their own management team as too difficult and put off making tough decisions without realising the lack of decision will impact the overall ERP effectiveness.

Surveys on ERP are all showing that a significant barrier to successful ERP implementation is in the area of change management. The surprising thing is this is not new! We have known for many years that change management is a major barrier to effective ERP implementation. There are many publications on the need for effective change management in effective ERP acquisition and implementation. Despite the information available we do not seem to learn the lessons or the actual “what does change management mean” hasn’t been defined in a way that top management can understand and practically engage in.

Experience Worth Listening to!

Ray Atkinson

Atko Global

For further information goto http://www.atkoglobal.net.au

ERP Project Failure is the Standard!

ERP Project Failure is the Standard!

Constant surveys on ERP continually show ongoing problems with adoption of the technology! After many years of ERP experience you would think that we would be getting better at implementing the technology successfully. Not so! Panorama’s recent survey is still showing ERP takes longer, costs more and does not deliver expected tangible results. No surprise here! The approach being taken has not materially changed to way the technology is being adopted since the 1990s.

The model of customer producing a list of requirements, sometimes with consultants help, is followed by a response from potential vendors, highlighting the positives in their package and downplaying the negatives, supported by claims of “Proven Paths” implementation methods and claimed expertise, suspect as best, and customers paying large sums of money for implementation still produces the same disappointing results.

The reality is ERP is not simple, requires the collaboration of different players with different agendas and that does not include the change difficulties of internal company politics.

The term “Devils Triangle” refers to the key players with their different agendas; The ERP software vendor who is trying to sell their product and may stretch the truth or downplay issues with the software against the requirement in order to get the sale and at the same time creating an expectation with the client. The software integrators who are expected to implement the expectations sold by the sales people which may not be achievable. The company who has not really understood the real need, underspecify the software at the front end resulting in downstream implementation problems, restrict resources, take shortcuts and lack effective management involvement all contribute to the disappointing end result.

In theory each of these players should come together to achieve a satisfactory outcome but in reality they rarely do as the drivers for each part of the “devils triangle” are working on different priorities.

We have constantly seen disputes where each party blames the other for the problems and in some cases these disputes end up being fought out in the courts where a confusing range of evidence is submitted, all of which relate back to the “devils triangle” and taken in isolation, depending on where each party sits in the scheme of things, has validity.

Our prediction is ERP will continue to cause major problems of delays, unacceptable cost blow-outs and little tangible benefit until the approach to acquisition and implementation of the technology undergoes a fundamental change.

It is too late when the project has come apart during the implementation. The delays, costs and end result can only be reduced and not avoided even when timely intervention is made to change the course of the implementation.

The overreliance on software vendor integrator’s to implement ERP systems has to change and a fundamental realisation by organisations that just paying someone large amounts of money is not the answer. The answer is for the party most impacted by success or failure to take a different approach and accept the responsibility for all aspects of the project. That party is the buying client as they will be left with whatever legacy is left behind at the end.

Is there a real solution to this? We have been working with ERP and the forerunner MRPII for the past 35 years and our mediation and expert witness work with organisations in dispute has resulted in significant analysis across a broad range of industries and common themes have emerged that relate to the devils triangle and the failures of the different parties.

We have put together a series of steps that must be taken to systematically ensure each stage of the project, beginning with the acquisition strategy, to ensure the company is in control at each step of the way and can successfully direct the outcome and not leave it to chance.

The outline of the steps following is supported by a free self-assessment which is available to compare what you are doing against the assessment criteria. Organisations that have used this free assessment have invariably changed course and report positive outcomes. To access this free ERP implementation self-assessment goto http://www.atkoglobal.net.au

The Steps:

  1. 1.      ERP Risk Assessment
  2. 2.      ERP Cost Justification & Budget
  3. 3.      Request For Proposal (RFP)
  4. 4.      Software Selection Criteria
  5. 5.      The ERP Contract
  6. 6.      Project Plan
  7. 7.      Go Live Date/s
  8. 8.      ERP Education
  9. 9.      ERP Training
  10. 10.   Implementation Responsibility
  11. 11.   Project Management
  12. 12.   Executive Involvement
  13. 13.   Software House Expertise
  14. 14.   Software Imp Team Expertise
  15. 15.   Process Change
  16. 16.   Data Clean-up
  17. 17.   Data Conversion
  18. 18.   Issues Identification
  19. 19.   Scope Change
  20. 20.   Software Changes
  21. 21.   Management Action to Issues
  22. 22.   Go-Live Readiness Reviews
  23. 23.   Live Running Cut-over
  24. 24.   Post ERP Cut-over

This approach is holistic and provides a clear path for the implementing client to take control of the project and ensure success the first time.

Experience worth listening to!

Ray Atkinson

Atko Global

For more information on blogs and articles goto http://www.atkoglobal.net.au

ERP and Waste Elimination

ERP and Waste Elimination

Many organisations believe that an ERP project will reduce waste and make the company more efficient. ERP is primarily an information tool that enables the company to plan and control their activities by integrating all of the elements of the business from an information perspective.

Ninety per cent of ERP projects fail to deliver tangible business improvements or reductions in cost adding activities. To get the most from the ERP project, business process reengineering, lean principles and six sigma techniques need to be applied, at some point, as well as the implementation of the software. Process reengineering lean and six sigma techniques are based around reducing non-value adding activities and strive to for a zero defects environment.

For most organisations attempting to combine the four into a one stop project will end up in confusion and complicate an ERP project that most likely will become beset with significant issues of project delays, software fit problems and budgetary blow-outs.

There are different schools of thought on the application of these technologies! Some believe that process reengineering, lean applications and six sigma should be implemented before ERP. Others argue that ERP is an enabling technology that provides the platform for process reengineering, lean and six sigma. To take it a step further there are those who advocate replacing ERP with lean and six sigma.

Can lean or six sigma manage the entire supply chain without ERP? I don’t believe so. ERP

is required for all of the up-front processing of information such as forecasting, sales order processing, production and materials planning, accounts payable, accounts receivable, product costing and many other vital functions of the business

There are certainly opportunities for the application of lean, six sigma and process reengineering to streamline activities and reduce cost-adding activities such as activity based costing, vendor managed inventories, factory and vendor pull systems (kanban). In all of these ERP is a still a vital aspect of operating a business. An understanding of how these technologies can be applied should be looked at before embarking on any business improvement program to determine the optimum application to benefit the organisation. How the ERP system is implemented can facilitate or block the application of the other technologies.

 

Ray Atkinson

 

Experience worth listening to!

 

 

 

For further information and blogs goto http://www.atkoglobal.com

ERP Software Specification & Selection

ERP Software Specification & Selection

Our continued ERP project analysis over the last 35 years has consistently shown organisations experience significant problems with software not fitting the organisations needs. This is despite significant in-house investigations and involvement with internal users on what they want with the ERP software.

ERP projects tend to run into problems during the implementation stage of the project for a host of reasons, but up on the top of the list is the need to carry out significant software customisation, modification or purchase of additional software in order to achieve the functionality required.

The confusion and frustration from senior management, as to why this situation occurs, given the amount of effort that has gone into the original specification, is understandable. The message on software functionality and fit in many cases has been taken on board by organisations embarking on ERP projects but despite the knowledge that this is a problem area and steps taken to address the issue, the in-project problems still persist.

So why do organisations continue to have these problems despite putting together comprehensive software specifications and software demonstrations designed to eliminate packages that don’t fit the requirements? The answer to this is never straight forward or simple! There are a number of issues that impact the acquisition and implementation of ERP software;

Budgetary constraints: For many companies determining the budget for an ERP project includes an amount for the software as part of an overall ERP project. Often a number will be determined for the software component based on the amount of money available and may not be a realistic figure to cover all of the software and any customisation or modification that may be required. The assumption is the amount allocated will be sufficient for the software to meet the operating needs. Software vendors will size the software to the money available but in the end may leave significant shortcomings in functionality.

Software shortcomings: The shortcomings in the software become evident at the implementation stage of the project and in many cases can be a show-stopper unless addressed. The budgetary constraints employed in selecting and purchasing ERP software are typically reflected in additional costs incurred during the implementation stage, but are greater as the disruption to the project schedule with additional costs of consultants and making the changes are far greater than paying for the right software up-front.

Misleading Information: ERP software vendors are in the business of selling you the product. They are rarely going to highlight the shortcomings in the software they are selling you and risking the sale. The software houses will size the product offering to meet the budget constraints as this is what you have asked for. They also know that you will need to address the software shortcomings during the implementation stage but rest on the fact that they have given you what you asked for. They will also make additional revenue from the changes you then request during the implementation stage of the project.

Lack of top management involvement or oversight: Too many senior managers tend to view ERP as a technology project that is to be left with the computer people and the users and as a consequence they tend to limit their involvement to receiving weekly or monthly reports. The setting of budgets without a true understanding of the implications simply sets the ongoing implementation of the technology on a path of problems.

The problems in selecting the right ERP software hasn’t changed from the days the technology was called MRPII. Writing down a set of requirements and sending them to software houses to comment on and having demonstrated different elements of the software before purchasing it has proven to be inadequate for a successful outcome.  What needs to be done is take those requirements from the users and construct a model to simulate the software through. Construct a macro model of how the software is to flow and then on each area of the model specify what you want in terms of process and output.

By simulating the software through the model you can quickly identify what areas of the software are not compatible with your operating requirements and either; reject the software or negotiate on whatever customisation or modifications are required up-front and, not discover the shortcomings in the software when you are trying to implement it.

Experience worth listening to!

Ray Atkinson

Atko Global