Damaging your business with a failed ERP system

Damaging your business with a failed ERP system

For many organisations the decision to embark on an ERP venture is driven by wishing to improve the business and benefit from the potential the technology has to offer.

Too often the level of understanding on what is involved is not adequately understood from the people who make the decision to proceed!

It is a simple matter to see an ERP project as a technology project and apart from making decisions on approving expenditure and a basic oversight of the project, management rarely get involved in driving ERP projects and prefer to delegate the project to middle level management who they believe have the technical skills in computers.

It is easy to see how the implementing company can get swayed by statements from vendors such as proven paths, world class experience over hundreds of implementations, and a host of other comforting terms that are more of a sales pitch to sell the product rather than real expertise.

The reality is 75% of ERP implementations can be put into the category of failure. The definition of failure depends on what the expectations were in the first place. Whilst there are organisations that abandon ERP altogether the majority of organisations implement parts of the system, namely, finance, inventory, order entry, purchasing and some works order type activity. Whilst these functions offer some degree of process capability it does not utilise the full integration of the technology in terms of planning and control and does not reap the benefits that ERP offers.

The failure of an ERP system is not just confined to areas that are not utilised or that don’t work well. Expecting to fully integrate the functions of the business utilising ERP and turning the system to live running and then finding out post-live running that the system isn’t working because issues such as resources, process reengineering, internal conflicts, management involvement were not resolved or data wasn’t sufficiently structured or cleaned-up during the implementation stage of the project can lead to operational disaster and in worse case scenarios bankruptcy.

The damage to a business through the lack of accurate information or systems problems not resolved during implementation can manifest in failure to ship and invoice product, failure in order entry, build-up of unnecessary inventory, factory shortages, late deliveries, lack of accurate financial information and significant brand damage.

Whilst these failures are the norm and not exceptions, they are unnecessary. The key to successful ERP adoption is all in the approach taken by senior executives at the beginning of the ERP planning and acquisition strategy.

We have analysed hundreds of MRPII and ERP projects for the past 35 years and have identified 26 key areas that contribute to implementation failure. You can assess your ERP project approach or identify issues you need to address by going to www.atkoglobal.net.au and downloading a free copy of our ERP self-assessment. We feel sure this will provide you with the tools to proceed with ERP and be one of the successful ERP sites.

Experience Worth Listening to.

Ray Atkinson

Atko Global

Will Cloud Make ERP Implementation Easier?

Will Cloud Make ERP Implementation Easier?

We are seeing many articles pushing the concept of computing in the cloud. There are also people (salespeople) pushing cloud solutions over in-house hosted. Statements like traditional ERP is dead are becoming commonplace and also statements that ERP will be easier to implement in the cloud.

ERP is a system used to integrate all of the different areas of a business to provide information and in some organisations (manufacturing/distribution) for the planning and control over the entire supply chain from order entry to planning of materials, purchasing, factory planning and control, inventory control, costing, capacity planning and the despatch of goods to financial management. These systems are designed to provide accurate information in real time for decisions to be made on managing the business.

The issue of whether or not the system will be in house hosted or otherwise comes down to a number of issues relating to economics, support skills and other business factors unique to each organisation.

The implementation of ERP is another matter. It doesn’t matter where the system is hosted from! Issues of software fit, data integrity, education, training, reengineering, data migration, management involvement and user engagement will all be the same whether the system is in-house or externally hosted.

Global surveys are showing that the problems in managing successful ERP projects revolve around the failure in some or all of the issues raised here and little or no mention at all about where the system is hosted as being barriers to success.

The claims that cloud hosting of ERP is easier and better than in-house hosted ERP, apart from any financial cost benefits,  are undoubtedly exaggerated, and in my view, seem more in line with a marketing strategy to differentiate products from the many ERP vendors who are constantly coming up with claims and strategies to differentiate their products from their competitors.

Make no mistake the issues of implementation are challenging to the best of organised companies and caution should be exercised when faced with various claims from those who have a major vested interest in pushing their products.

The surveys are consistently showing that ERP continues to be a problem for companies trying to implement the technology whether it is cloud hosted or otherwise!

Ray Atkinson

Experience Worth Listening To.

Atko Global

for further information go to http://www.atkoglobal.net.au

How to kill your ERP Project

How to kill your ERP Project

A 2014 global survey on Enterprise Resource Planning (ERP) has quite clearly shown that software customisation has the potential for totally derailing an ERP project. Asking for software to be customised during implementation is a major source of project delay and budget blow-outs. Software houses are more than obliging to undertake the customisation, at a cost!

The lack of an effective internal system for logging customisation requests, post purchase, and determining “what is essential” as opposed to “wouldn’t it be nice” can very quickly lead to massive changes to the software far beyond the original scope of software requirements.

Surveys are showing 60% of ERP projects are undertaking significant customisation or purchasing additional software as it is perceived they cannot do without it. I am not referring to simple configuration of the software but changes that impact functionality or process.

With all of these changes going on and the negative impact the changes have on ERP projects the question is “Why”?

The great majority of companies we speak to go to great lengths to define their ERP requirements by engaging users and all stakeholders to ensure they cover all of the business requirements. These requirements are documented and put into a request for quote that is sent to potential vendors for their response.

Given the effort that goes into defining the requirements and the fact that 60% of ERP projects undergo significant software customisation/modification and or require additional software, the process for defining requirements must be floored.

It has long been known that the best way to implement ERP software is to define clearly, up front, what the requirements are and implement the software with minimum or no changes. The key here is to get it right at the software requirements stage and ensure it is very clear what the requirement is and tested against the software prior to purchase. Any shortcomings in software should be identified in the pre-purchase demonstration stage of the project and negotiations made to correct the shortcomings or look for an alternate package that better fits the requirements.

The changes that organisations are making to ERP software during the implementation stage of the ERP project causes significant cost and schedule blow-outs to the project. In many cases the costs far exceed the budget for the project resulting in shortcuts being made to the project, affecting the systems performance during live running or causing the project to be abandoned.

The method of defining ERP software requirements needs to be closely examined to ensure the ongoing disasters in ERP failures is not due to poor definition of software requirements.

Ray Atkinson

Experience Worth Listening to!

Atko Global

For further information on ERP go to http://www.atkoglobal.net.au

ERP Failure Starts Long Before Software Implementation

ERP Failure Starts Long Before Software Implementation
An analysis of many failed or non performing ERP projects highlight the failure of organisation’s top management to get their heads around the full implications of taking on a project as large and intrusive on business operations as ERP!
Issues of under-resourcing, lack of budget, poor software fit and internal conflict have their genesis long before the actual software implementation project commences.
ERP implementation is really about good project management and this includes getting the detail of project, scope and control right at the very front end of the project!
Embarking on an ERP project without understanding the full scope of work so the resources can be put into place can only lead to downstream issues during the actual work phase of implementation.
Setting budgets based on a figure of money available without understanding the scope of work, associated software and integrator costs results in budget blow-outs and financial stress for the implementing organisation.
Software shortcomings requiring modifications, customisation or additional software should have been resolved at the up-front negotiation stage by constructing a model and testing the software against the model to determine what the shortcomings were and negotiating the changes as part of the contract and not finding out later resulting in significant problems with the project.
Having worked on major projects throughout the world the up-front definition of the project and scope forms the basis for budgets, time schedules and detailed scope of works. I fail to understand why ERP projects are not approached in the same way given the huge amount of damage, operationally and financially, that can be caused by lack of attention at the formulation stage of the project.
There is no doubt there is a high degree of confusion on what the ingredients are for successful implementation of ERP into organisations! Claims of best practice, proven path, easy to implement, best in class and a host of other descriptors are all used by selling companies to try to gain some form of marketing/sales hedge over their oppositions.
Buying companies are faced with a mountain of information attempt to navigate their way through the maze of data to determine which software they want and which organisation they want to deal with to give them the best chance of success.
The lack of a proper strategic approach coupled with the details of what the buying organisation actually neesds, in detail, leaves organisations vulnerable to an overblown sales pitch and more than likely projects that run into problems resulting in the project taking longer, costing more and providing little or no tangible business results.
Our analysis over 35 years has produced a set of guidelines that addresses all of the up-front issues and is available as an “ ERP Project Self Assessment” free of charge to anyone who wants to assess their own project approach before they commence or as an in-project exercise. Accessing and using this assessment will make the difference between success or failure of their projects. To access this “ERP Project Self Assessment” goto http://www.atkoglobal.net.au there is no cost or obligation for accessing this information.
Ray Atkinson
Experience Worth Listening to:
Atko Global