7 Steps to Enterprise Resource Planning (ERP) Systems Implementation Success

There are many ways an Enterprise Resource Planning (ERP) implementation process can be troublesome, costly and frustrating, but by trying to adhere to some ground rules the whole process can be pushed in the general direction of success.

The following steps have been the product of years of learning by different customer approaches and implementation methodologies and should be considered before, during and after any ERP implementation.

These steps do not purport to be a definitive list or the exact recipe for success, but by reading and acting on only a few of the suggestions here will ensure your implementation goes smoother than it otherwise would have done.

1. Understand your incumbent system
The decision to purchase a new ERP system has been made, but why? There are many reasons a new ERP system will be sourced, but it is important to understand that the implementation of a new ERP system will not simply create a return on investment or solve the issues of the business. These come from the process improvements; the ERP system is a tool and improving the way a business uses the tool can reap benefits.

The process of implementation does not start with the initial inviting of suppliers to fill invitations to tender, it is when the company define the goals that the new ERP system will set out to achieve. It is the goals that are critical, and should be referred back to during and after the implementation process to ensure focus is retained. If there is no clear goal, the process of selecting a product and vendor will be a futile process, whilst the overall situation may have improved this will bear no resemblance to the investment of time and money made, and in many cases the business would have been better off not changing.

Setting and defining these goals can be driven by the current system. The business may have outgrown the system, or the system may be non-compliant or non-supported, but whatever the reasons the system and the processes inside and outside of the system must be understood. Many businesses want to see X% improvement in Production efficiency, Y% reduction in stock holding or a Z% customer service level, but without understanding the processes behind the current figures there is little benefit in moving forward with these targets because the new system will be implemented using the old processes and produce the same end results.

“The focus of this Magic Quadrant is on ERP systems that support a single-instance strategy for multientity midmarket and upper midmarket companies. User-centric improvements focused on usability and deeper integration of analytical capabilities is at the core of leading systems.”

Without understanding what is causing the current figures, improvements cannot be made. Additionally these figures need to be recorded over a period of time in the old system and then compared to a similar timescale in the new system after a period of stabilisation to try and prove any improvements; many businesses never record these figures and can never go back and justify an actual improvement even if one exists.

The success of your future implementation lies in the process and data of your current system. Study your current system at length and learn from it to take forward the elements you do well, change the ones you do not do well and enable you to statistically prove the success of the new system compared to the old one.

2. Homework & Collaboration
Once a business has come up with clear defined goals that the new ERP system must achieve and defined some tangible metrics to judge success then the next step is to find the right product and the right vendor.

There may be industry verticals supplying specific software to meet the needs of your business, or a tailorable ERP system may meet the needs of the business, but the key is to investigate, find out what your competitors, vendors and customers are using. Many businesses send out invitation to tenders listing hundreds of questions filled in by potential vendors based upon an assumed set of answers to open questions. Whilst these may assist in narrowing the choice down, the choice of software alone cannot be based upon these.

It maybe that the software choice can be narrowed down, if it cannot get businesses in to present the benefits of the software they supply. Once you can decide on the software to meet the needs of the business you need to choose the correct vendor, not simply the vendor who helped you define the software choice.

Does the vendor have the ability to transform the business to help achieve the set goals? If they cannot the likelihood is they are not the correct vendor. However there are other methods that can be employed to judge the suitability of the vendor. References must be taken, preferably with site visits and face to face contact. Can the customers acting on behalf of the vendor stand in front of you and tell you why you should choose the product and the vendor?

This endorsement will show how the vendor and customer act in a relationship, and this is a key concept to understand if you wish to purchase from the vendor, because if you do you will soon be in the same position as the reference extolling the virtues of the supplier. Ask about the implementation methodologies; what standards are used and are these industry recognised, proven and successful in the field delivering tangible results?

Any vendor seeking to develop a long standing successful relationship with you as a customer must be able to assist you in reaching your aims, and will be able to prove they have done this in the past and have the tools and resources in place to deliver a successful project.

If you cannot trust or work with the vendor then the project is very unlikely to be successful. Therefore choose the vendor very carefully.

3. Budget Control
To be able to control a budget you need as a business to identify the real costs of ERP. These costs can include hardware, training, organisational change management, developments, staff cover for project members and the software. The identification of a clearly defined budget scope is critical and difficult. The ERP supplier can provide a scope of services and a software and hardware budget, but this is not the entire budget. The first question to clarify is what is “not” included in the budget. This can traditionally be data migration, modification work and attendance contingency. These elements will be unknown at the start of the project, but should be estimated because they are critical to avoid significant budget creep.

The non-budgeted elements are difficult to define because the breath of these areas vary greatly project to project and business to business. However it can be said that almost all projects involve data migration and every project requires modification even if it is to the output documentation.

Additionally there can be third party software costs, or non-related ERP software costs, or freelance consultant costs. All of these need to be estimated and entered into the control Budget Document.

The Budget Document is an evolving document as the project progresses and the estimates are known in greater detail. Once the business has a budget, it needs to control it.

This requires constant monitoring and change control where additional work is required. It is critical to establish Project milestones, key sign off points and compare the budget at each stage and more frequently if possible, to control the budget. Active management of the budget is the only way to manage and control overruns and alterations to the project. This will include the auditing of budget expenditure from the software vendor to verify vendor invoices to consultants’ timesheets – one of the more costly elements of the project.

There are many methods to constructing a budget, but it is only as good as the information the business inputs into it, and the subsequent management and tracking of the budget. Ensuring tight control of the budget can be the difference between a successful implementation and one that whilst goes live successfully, does so at a massive overrun in costs.

4. Resources and Team
Implementing an ERP project requires an internal project manager and team. Whilst the majority of businesses try to achieve this by assigning these roles to key members of the business and making them continue to do the day-to-day work that has made them key, it is ultimately a struggle and causes issues with the project and the business.

The most successful implementation projects have at least a 100% dedicated internal project manager to ensure the project is kept on track, on budget and moving in the right direction.

The key members of the team need to take ownership for the project and to cascade this responsibility down through departments. The ownership is achieved through involvement and ensuring all areas of the business contribute to, and feel a part of the project.

The key members are critical. They have to adopt a positive attitude towards the ERP change, resistance is amplified further down the responsibility chain, and if the ERP “Champions” do not believe it will work, why should anyone else?

The key members must be influential, be able to win over resistance and promote the project within the business. To enable this they must be respected or in areas of responsibility. Whilst having the knowledge to understand the daily issues and processes they must also be considered enough to make decisions that are based upon the overall good of the business now and in the future.

The key members and the peripheral members of the team form the departmental spearheads for the ERP project and will drive the success of the project. Without the commitment of this team the project has a much higher failure rate.

All staff involved in the ERP project are a resource the business has direct control over. Priorities can be set and goals and milestones achieved. However without the backing at management and board level the project will drift and the team will concentrate on the daily workload and general work responsibilities rather than the requirements of the project.

The software partner will also provide consultants to guide the business through the implementation. This is one of the largest costs of the project and these also should be considered resources and part of the team.

The consultants can be limited to a single project, but this is expensive, and if instead there are consultants planned to be part of the project it is likely that they are assigned to multiple projects, and it cannot be assumed that they will be available at short notice, these requirements must be planned and controlled.

The consultant is also the initial knowledge holder and making them a part of the team to deliver a successful implementation is critical. The consultants should not be treated as an external isolated resource, they should be considered part of the deliverable team and if the buy-in of the consultants to the success of the project can be established along with the buy-in of the staff then the success of the project as a whole is more likely.

5. Training and Understanding – User Acceptance
There are many philosophies on how best to train staff, but the simple rule to follow is to actually train the staff.

During implementations there are many methods of training, but before any of this can really commence the software must be understood by the business, and the business must be understood by the ERP partner.

This is not simply how the incumbent software is used, but the business processes, requirements and the reasons behind why transactions and processes are undertaken. This understanding will lead to further questioning and mapping of processes to the new software to see how the software can be leveraged to full potential to meet the needs of the business.

Redundant system based processes adopted for historical or system restrictive reasons should be questioned, clarified and where possible integrated into a new method, or if possible dropped altogether.

With the harmonising of business and software understanding the processes can be mapped into the software and a training plan developed. This may include initial training sessions with the key members of the project team, in a train the trainer format. It may also include scheduled classroom sessions for departmental members, or entire departments. It is critical when training end-users that the processes are agreed with the key team members beforehand to ensure the sessions delivered meet the needs of the business.

The training itself can take many forms, but generally the most productive form is hands on sessions where the users have individual access to a test system and are given scenarios to create or follow.

The training of the users however is not the end of this process.

Once trained the users need to process train. Training in isolation may help the user gain an initial understanding of how the software works, but undertaking this in process loops is an essential step. By undertaking this the business gets to see how each department impacts on the other and how the decisions made upstream affect what the downstream departments “have” to do. Additional to this, and perhaps more critically, holes between the departments begin to appear from a software perspective. If discovered and understood at this stage provision can be made, but if this is not undertaken these issues can only be uncovered at go-live.

The acceptance of the users in totality is critical. Once the business understands how the business process flows through the software the business can assess the suitability of the processes, and whether they are really needed, or with the implementation of the new software whether other alternatives are now present from the software itself.

The entire processing cycle must be undertaken, and not simply once, different scenarios, different issues and different users should be used. All users generally bring a different perspective and a different set of questions and issues to the table. By collating all of these requirements the business has the best possible chance of going live smoothly. Undertaking this will mean all of the processes are understood, and the users understand how to use the software to meet the needs of the business.

If a business chooses to be trained and then go live without letting the users undertake static and process testing then all of the process gaps and issues will be discovered at go-live. The incumbent system will have been bent and abused to hide and conceal these gaps. The current system is as yet unaware of these issues and needs to be warned. It should not be expected that the new system will solve all of the issues of the old system, primarily because these are generally not software issues, they are process issues, but secondly because no one in the process of training has discovered they exist.

6. Data Migration
The common response to the question “What data from your current system do you want migrating to your new system?” is “Everything”. Whilst this is possible, it would probably cost more and take more time than the current ERP project being undertaken.

There are many pitfalls in the sub-project of data migration, but the underlying starting point is to be realistic. It should also be noted from the budgeting section that this area is not generally in the budget at the outset and therefore the business needs to consider what adding a multitude of days development would do to the budget at this stage.

The first question regards the areas of the business requiring data migration. This can generally be assessed on a volume basis. If there are 100,000 item records then they will be migrated, if there are 10 they will be keyed. Between these levels of volume assessments there is a grey line where a decision is made; and this line moves in volume depending upon the area of the records being migrated and the complexity. Another possible solution is the manual keying of data. This in itself acts as further training, and if the volumes permit can be used on open purchase and sales orders to dismiss the complexity of dynamic data migration.

Once the automated areas have been decided the next issue is the data itself. There are generally several issues with the data; the structure of the tables will be different, concepts in one system not being present in another, the data itself will be of poor quality, a common example of this is address records stored in completely separate text fields with different county references and no way of mapping these to the new and different address format, and the new system can be used in a manner that the existing data is not set up to handle.

One common requirement or request is for sales history to be migrated. To migrate into posted ledger tables and mark transactions as fully paid, with all of the reporting requirements of the new system catered for is a very lengthy and costly process that generally would never make a return on investment. Far more productive is to push the legacy data into a separate referenced SQL database or cube for cross analysis with the new system, or to simply leave the data where it is for user reference. Converting any form of historical data should be considered carefully with regards to benefit, timescales with the impact on the project, and cost.

Where the new system requires different settings and categorisations that do not exist in the current system the first issue is the transformation. The best method of this is to create these settings during the export routine of the legacy data if possible. The last option is to key these into the exported data ready for import – human errors will cause issues.

This project can run parallel to the ERP implementation project, and if possible the user acceptance training can be undertaken on the initial passes of migrated data.

The methods and processes for extracting, transforming and importing the data vary between systems, but one common factor is that the internal IT staff will be part of the process. It should be remembered that the IT staff are focused generally on the migration of data, that is to say the focus is on getting data from one field into another, and not that the end result meets processing requirements.

The final data routines should be finalised months in advance of a go live. Whilst initially testing will be undertaken on subsets of data it is imperative prior to live that at least one full import run is undertaken to ensure all of the possible issues from a full import are understood and potentially resolved in advance of the live date.

Once data exists and is present in a test system the end users responsible for the data must test this thoroughly. Responsibility for the acceptance of the resulting data in the end system resides with the end users and not the IT staff responsible for the transformation. This means to ensure the best possible results from the data migration project the routines must be run in full in advance of the live date and the end users must test, test and then test again.

7. Go Live perpetually
At the end of months and months, or even years and years, the business and the team will finally manage to drag themselves across the finish line. The business has made it, at last! That is it, the project is completed, there is relief all around as people can now concentrate on their day jobs. Simply put the answer to this is “NO”.

Going live is simply the start of the next phase of the project. There will have been requirements, issues, modifications and suggestions that were not on the business critical path, or were even purposely moved off the business critical path, and now these must be addressed. The original goals set out during the purchasing process should be reviewed for relevancy and achievement.

Whilst there is a period of settling in to the new system to gain the full leverage of the software and the change, the original reasons for change and the strengths of the new software and possibilities must be brought to the fore. Implementing a whole new system and getting back to where the business started with a new front end and a new way of processing the business through software is not success, it is a costly way of standing still.

Even if the business has implemented a system and there was very little in the second phase and they have made massive leaps forward throughout the business this is still not the time to do nothing. The go live process is perpetual. Standing still after go live will see the business begin to slip backwards from an ERP perspective.

The system needs to be constantly reviewed, processes and applications should be assessed for suitability and purpose, and where gain can be extracted from a change it should be made.

If at this stage the business stops the process of going live on the new software it is a distinct possibility that in the next five to ten years they will be undertaking a new implementation project to install a new system because the incumbent system does not meet the needs of the business. It does not meet the needs of the business because the business does not understand one of the costliest most powerful tools they possess and they never developed it to its full potential. This in turn brings us full circle, knowing your incumbent system – without it the business will not be going live perpetually, they will be implementing ERP perpetually.

There is generally no quick and easy solution to implementing an ERP system in a business of any size. This is gauged on the size of the business, you can implement an accounts system in a small business relatively quickly and cost effectively – but would you want the same timescales implementing in a multi-site, multi-million pound, 1000 employee business?

As a business the need to be realistic at the outset is paramount. The process, if done correctly, takes time, costs money and requires great internal resource commitment. All of these can be compromised to some extent, but there is always a balance in the end, and this will come in the system that the business ends up going live with. Compromise on the project and you are compromising the end solution, and potentially the growth and future of the business.

Implementing an ERP system is not straightforward, but remembering some of these simple suggestions will help the project have a greater chance of success than ignoring them.

Source: Columbus Blog on “7 Steps to ERP System Implementation Heaven: Part 1 of 2”

Related Article: Making the Supply Chain Software Business Case