The ERP go-live data load

By the time that companies get to planning their ERP go-live, a lot of essential hard work will have been carried out; not the least of which will have been a comprehensive data cleansing exercise (processing inaccurate data more efficiently benefits nobody).

Now all of that data has to be loaded, accurately and completely, to the new system. There are two types of data involved: static and dynamic. Taking the inventory record as an example, things like the part number and the item description are considered to be static data because they don't generally change, but things like the stock balance are considered dynamic because they can be expected to change regularly.

As a rule of thumb, transferring static data (which also includes things like customer and supplier data and, for manufacturing companies, bills of material and manufacturing routings) electronically between systems is relatively easy but transferring transactional data, such as histories, is infinitely more difficult.

The reason is that the type of data in, for example, customer and parts files, tends not to differ wildly from system to system. In an integrated system, though, transactions can write to multiple files in complex structures. A purchase receipt may write to the purchase order file, the stock file, the stock history file, the general ledger, and possibly the accounts payable file as well.

In a relational database, these files will have automatically created indexes that would be nearly impossible to recreate manually. Even copying static data, though, is not always as simple as it seems. A new system can be expected to have data fields that the old one doesn't, and companies need to look at these to consider how best to populate them (and, indeed whether they should be populated – they are rarely advised to use data fields “just because they are there”).

Options include manual intervention during the load, entering defaults during the transfer, or doing mass updates (e.g. “if supplier code is ABC, set purchasing lead time to 10 days”). They also need to check that field lengths in both systems are compatible so, for example, a 50-character item description is not copied to a 40-character field.

Copying manufacturing bills of material and routings can be more complex because, to get the maximum benefit from the new system, in addition to populating new fields, it can be necessary, or at least useful, to restructure those bills and routings. Too many levels in bills of materials increase WIP levels, whilst too few increase raw material levels; so implementing a new ERP system is a rare opportunity to optimize them.

Dynamic data is more problematic, in part because there are different categories to consider: stock balances, financial ledger balances, and outstanding sales, purchases, and works orders. Looking at stock balances first; some companies try to save time and effort by transferring them electronically but this is rarely a good idea unless they are sure that their stock records, both in terms of quantities and locations, are at least 99.5% accurate.

Most launch their new ERP systems with a full stock check because, if the system responds to inaccurate stock data within the immediate post-go-live period by making inaccurate recommendations, users are likely to blame 'the system' rather than the data.

People who don't understand what is going on often react by saying, “We've spent all this money and we still can't get good information out of the system”. On the financial side, it can be possible to transfer many ledger balances from the old system as long as the chart of accounts structure has not been radically altered, but when it comes to loading outstanding accounts payable and accounts receivable balances, companies usually take one of three paths.

At one extreme, if the number of outstanding invoices is not great, it can be viable to simply manually enter them into the new system, whilst if the number is great, they may choose to enter summary invoices, one for each supplier and customer, with just consolidated totals.

An attractive compromise for many, especially those offering extended credit terms, is to enter these summary invoices at the month or period level so that aged debt reports can continue to be meaningful in the weeks after go-live and also, on the accounts payable side, to help ensure that invoices get paid on time and not either unnecessarily early or dangerously late.

Sales orders and purchase orders can be considered together because they are so similar. Transferring both electronically, unless the ERP supplier has bespoke routines available, can be very difficult because, even leaving the possibility of new data fields aside, both types of orders write data to multiple different files.

A sales order, for example, in addition to writing to the sales order file, usually writes to the inventory file (to increase the back order balance), the customer record (to consume outstanding credit), and maybe the MRP demand forecast file (to net of against forecast), so companies generally choose to enter them manually.

There are important advantages in doing so, beyond the incentive to properly cleanse these files before the data is transferred. One reason is that, regardless of the quantity and quality of training given, people will make mistakes until they build up knowledge and experience, and it is better that they make these mistakes before go-live, rather than after because the impact is less and available recovery time is greater.

When companies have very short delivery lead times, the workload is often not great but some companies worry unnecessarily when they do have extensive order books because of the perceived workload. But they shouldn't. Regardless of when order entry begins (and it can begin immediately after system design and configuration are completed and staff has been trained), the only orders that need to be entered are those that are due for delivery after go-live and, for most companies, that is usually a fraction of the total.

So staff have time to build up experience of the data entry routines that they will be using without being under pressure, and will be experts by the time they, and the implementation teams supporting them, are put under pressure post-go-live. Some would argue that it is not possible to identify with 100% precision those orders that will be outstanding at go-live because come the day, some will be running late and others may have been delivered early.

But this is not a valid argument because, as a percentage of the total, this will be a very small number and any last-minute adjustments will be easily coped with. Turning to works orders; the options here are heavily dependent upon the material issue methodology and the manufacturing lead time.

The two extremes are, first, companies that have very short manufacturing lead times and backflush (i.e. retrospectively issue) materials and components and, secondly, companies that have long manufacturing lead times and issue materials up-front.

Understanding their options will help companies in the middle of those two extremes to understand the options that are available to them. Taking the first category first; these companies can usually simply close the outstanding works orders on the old system and raise new ones, for the outstanding quantities, in the new ones.

At the other extreme, where manufacturing lead times are long and where materials are issued up-front, things are not that easy. One problem is that, if closing the works orders short, unconsumed materials must be returned to stock for reissuing to new orders on the new system.

Not all older systems make this easy and, if many items are involved, it can be a sizable task; even though the 'return to stock' is a paper exercise only, with the items remaining where they are, on the shop floor. For manufacturers of things such as capital equipment, where the order quantity may be one, there is an added complication.

A partial receipt of a works order, when the order quantity is one, may simply not be possible in some systems. Reversing transactions can also be difficult, or at least very time-consuming if a lot of items are involved. Some systems, though, allow miscellaneous costs to be added to works orders, using codes that point to specific general ledger accounts, and this enables costs to be added at a summary level.

Looking lastly at transaction histories; as with dynamic data, and for the same reasons, these are very difficult (i.e. prohibitively expensive) to transfer electronically. Some systems, though, offer facilities for entering data at a summary level; for example, sales history at an item/period level.

Companies will need to decide which history data is essential and may have to be manually re-keyed to the new system and which is just 'nice to have' or 'just in case'. It is frequently better just to download such data to spreadsheets for long-term storage.

The good news in all of this is that companies have ample time to make their decisions and to plan the transfer: as long as they don't leave it until the last minute.