Extract from the Gate Methodology article ... "Everyone has heard the horror stories of cost overruns on SAP programmes. While there are a few factors which are outside the control of the programme managers (e.g. business change, funding withdrawn) the majority of the responsibility lies at their door. From the programme managers viewpoint it is essential to get early warning that things are starting to slip. One of the quickest way to lose your job is to surprise your board 4 weeks from go-live with the message that the programme is 6 months late."

This article is intended as a follow-up to the Gate Methodology article. In this one, we take a closer look at data and how it needs to be closely managed during a typical SAP implementation using the ASAP methodology. Why data? Simply because in our experience it is almost always jumps up and bites you towards the sharp end of the programme.

Briefly, we are concerned here with the transferring of legacy data into the new SAP system. The primary activities and the ASAP phase that this occurs in are shown in the table below:

Identify and Locate

Right from the start of the project you need to decide what data will be required in the new system. Initially this is at a high level (e.g. customers, accounts) but it also needs to identify data which will not be required in the new system (e.g. assets). Typically this would be done as part of the overall scoping activity. In addition to this list of data to be included, and data not required, a good data section of the scope document would include the following for each required data element:

• Source system(s) for this data - This needs to be specific. It is not unusual for customers for a single company entity to be stored in more than one legacy system.
• Initial estimates of the volumes - Again be specific e.g. 10,000 customers.
• Whether an automated conversion is necessary - Typically required for high volume data, however an automated routine might already be available.
• To repeat: this needs to occur right upfront, and certainly before the Blueprint can rightfully begin.

SAP Design and Map

During the Blueprint phase, the functional analysts will determine where the data will go in the SAP system, and how it will be used within the processes. Giant spreadsheets will emerge which ought to include - for each data element required - at least the following:

• All SAP data fields within the element will be used - And this means all. It's quite simple ... if the field is not on the spreadsheet, it will not show up in SAP once the system is live. That usually helps focus the effort.
• Then, for each field identified, document the field business rules (for example define what a Plant will be in SAP -  is it a factory, a part of a factory, a truck etc) and also the field technical rules (for example 10 characters alphanumeric).

The same needs to be completed for the data as it is found in the legacy system(s) so that the real fun activity - mapping - can begin. Mapping is the seemingly simple task of associating a single field in SAP with one or more fields in the legacy systems. Sometimes it will not be a perfect fit in which case you will need to transform the legacy data to get it to fit. Add a few more columns to your spreadsheet and capture:

• Legacy field it maps to
• Legacy field business and technical rules
• Any transformation required

Once you have completed this, and still within the Blueprint phase, you need to:

• Get it signed off - this is a very big step as data is at the heart of the SAP system
• Confirm the exact number and type of automated conversion programmes required
• Write high level functional specs for each of these programmes

Transform, Build and Test

If any of the above remains un-decided or (even worse) contested, it is better to delay the start of the Realisation phase as changes are much easier (and cheaper) to make at this stage. Some programmes avoid the nasty details ... and end up paying dearly for it later. Ignore this at your peril.

So, assuming you have identified the data you want, located in legacy and mapped it to SAP, then you are ready to:

• Transform the data as required - This includes creating non-existent data from scratch, and also altering the legacy data to make it fit into SAP.
• Cleanse the data as required. We will only say one thing here. Start this very early. 12 months from go-live is not too early. Cleansing means, for example, get the customer phone number field to contain customer phone numbers, get the stock counts right, eliminate duplication so that one vendor or supplier only appears once.
• Build and unit test the data conversion routines.
• Build up your tests so that by the end of Realisation you are in effect testing the entire data conversion routine (which might include hundreds of steps). Take note that the data load routines will be inter-connected so that you have to load vendors before you can load open purchase orders, for example.

A word on testing. Even if you get your entire data load suite running perfectly, you will be in for a very nasty surprise unless you integrate it with the functional process testing that should also be occurring towards the end of the Realisation phase. The following is a recommend test checklist:

• Have the data conversion programmes been built and unit tested
• Have the required manual data related steps been documented, and tested (e.g. data creation)
• Have the manual and the automated steps been integrated, and run as a full data conversion suite

Remember - you need to integrate the above with the functional process testing, so assuming the functional process testing been completed (and you are 8 weeks from go-live, or more):

• Create a new client
• Run your full data conversion suite into it
• Then get the functional teams to re-execute their test scenarios using the newly converted data. This is the true test
• Repeat until it works

Load

If all the testing has been successfully completed, you have a minor miracle on your hands and you can face the go-live with confidence. A few last minute reminders would be:

• Keep on top of all changes made (or better yet, veto them)
• Make sure it is someone's job to execute the data load successfully
• Set up a 24 hour control room to stand watch over a 24 hour data load process
• Dust off your contingency plan (oops)
• Have sufficient functional support people around for 4 weeks post go-live (at least)
• Push the button! 

As you can see from the above, there are very many things that can go wrong in the data stream of a programme. We have not touched on organisational, skill sets or other people aspects of this. That will be the subject of a future article.

While proper management of the data activities cannot by itself guarantee a successful implementation, at least you will be neutralising one of the greatest dangers to your programme ... and one of the most costly to fix.

Continue the 'manager' Article Tour (4 of 5)