Planning For a Smooth SAP Go-Live: Part 2

2. SAP Master Data

Ideally, your master data processing should begin early in the process. During the blueprint phase, you should identify legacy data sources, raw legacy data extracts, and key data requirements or data settings.

Even though it won’t be perfect, you should determine an initial scope, and experienced developers should be able to point you to the type of raw data records they will need to begin working with. When you begin your SAP project, you should immediately ask for SAP master data maps, layouts, and conversion information. If the developers responsible for data conversion seem to talk around the issue but cannot demonstrate very clear understanding of the details of the SAP master data requirement, then you should be suspicious.

By the end of Blueprint, legacy system master data requirements (extracts and layouts) won’t be complete but should be well underway.

You should complete Integration Testing with converted data, even if the data is not perfect. When you use converted data for this step, you will discover data gaps, process gaps, and other problems that can be addressed before you convert to a live SAP production system. After all, “live testing” of converted data in a production system is the worst time to find out if the system will work. Not only that, data corrections in an already integrated system such as SAP can be difficult .

SAP Data Transformation or Data Conversion Methods

There are four primary methods for data transformation into SAP:

1) Do the data transformations outside of SAP and legacy systems . Then, feed preformatted data files into the system using standard input programs;

2) Extract raw legacy data and do all of the transformations in custom programs or conversion tools inside of SAP;

3) Use a hybrid system that does some conversion outside of SAP and legacy and some at the time of conversion inside SAP;

4) Complete transformations in legacy extract programs.

I personally prefer methods 1) or 3). If there is one method that I dislike the most, it is probably 4).

A multitude of data transformation tools are available. Use them! I personally prefer MS Access, but that is for one-time data conversion and one-time transformation rules. Over the years, I have seen that the more cleanup and transformation on the data you perform outside of SAP and legacy (in an automated and repeatable process), the shorter the development time. Using that approach, I have found it easier to resolve and mitigate data conversion problems. In addition, this approach presses legacy employees to move away from the legacy app and begin learning more about the new system.

Personally, I will take unmodified, raw legacy file extracts; use MS Access to complete as much data conversion, data cleanup, and data transformation as possible; and then use SAP Legacy System Migration Workbench (LSMW) tools to load the data. Over the years, I have learned that I do not want any legacy data changes made at extract time. It frequently leads to managing multiple, sometimes conflicting, transformation rules– along with a multitude of other issues. Oftentimes, a single change in an extract data set before an intermediate or final transformation into SAP can completely compromise a data load. In addition, these extract changes are rarely reported, so you may only discover them by trial and error at load time.

A good MS Access power user can transform large amounts of data and file layouts to match SAP input requirements. Done correctly, this then becomes an easily repeatable process. MS Access is a capable data transformation tool. On a decent workstation, it can manipulate hundreds of thousands, or even a couple million, records relatively quickly. From there, SAP’s LSMW tool is quite powerful and can directly code individual field level transformation rules right into the program for any final detailed requirements.

Suggestions for SAP data conversion:

1) Never leave off doing a mock conversion of data so you can capture the necessary steps and times to do the real data conversion into your production client.

2) If you are doing a rollout of a new facility into an existing SAP instance, perform some type of regression testing before you go into production.

3) Plan for and be ready to support the master data maintenance efforts after go-live.

4) Test every interface and batch job, both before the go-live and within 24 hours of the first time you run them at go-live.

5) Correct and clean up any master data issues immediately at go-live. Each time a transaction references master data without being corrected, you compound the cleanup effort and the problem.