Purchasing and successfully implementing an ERP system is one of the costliest, labour intensive, stressful and business critical undertakings any business can embark upon. In this second part we look at the importance of data migration, ongoing development and user adoption.
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.