2. SAP Master Data.
Ideally your master data processing should begin early in the process. Identification of legacy data sources, and even raw legacy data extracts should begin during the Blueprint phase. Experienced implementation consultants should be able to ensure that the key data requirements or data settings are also captured during the blueprint process.
It won’t be perfect, but initial scope should have already been determined 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 can not demonstrate very clear understanding of the details of the SAP master data requirement then you should be very suspicious. By the end of Blueprint legacy system master data requirements (extracts and layouts) won’t be complete but should be well underway.
It is optimal to plan for Integration Testing to be done with converted data, even if the data is not perfect and not completely ready for prime time
Even though you may have to add a little more time to your initial project plan, it is optimal to plan for Integration Testing to be done with converted data, even if the data is not perfect and not completely ready for prime time. By doing integration testing with converted data you will discover data gaps, process gaps, and other problems that can be addressed before you convert to a live SAP production system. “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 SAP can be very involved and difficult because of the integrated nature of the system.
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 pre-formatted 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) A hybrid that does some conversion outside of SAP and legacy and some at the time of conversion inside SAP;
4) Or do 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). There are mountains of data transformation tools available. USE THEM! I personally prefer MS Access, but that is for one time data conversion and one time “throwaway” transformation rules. Over the years I have seen that the more cleanup and transformation on the data that is performed outside of SAP and legacy, in an automated and repeatable process, the shorter the development time. Using that approach my experience is that is easier / less risky it is to resolve and mitigate data conversion problems. The other side benefit of that approach is that it begins to press legacy employees to move away from the legacy app and begin learning more about the new system.
My personal method is to take unmodified, raw legacy file extracts, use MS Access to do 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’ve learned that I do NOT want any legacy data changes made at extract time. It causes too many problems, and frequently it then leads to managing multiple, sometimes conflicting, transformation rules. Often times a single change in an extract data set, before an intermediate or final transformation into SAP can completely compromise a data load. And sadly, those “extract changes” rarely get reported so they are discovered by trial and error at load time.
A good MS Access power user can do huge amounts of data transformation and file layouts to match SAP input requirements. Done correctly, this then becomes an easily and quickly repeatable process. MS Access is a quite capable data transformation tool, on a decent workstation it can manipulate hundreds of thousands, or even a couple million records “relatively” quickly for the lightweight desktop tool it is. From there, SAP’s LSMW tool is quite powerful and has the ability to 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 and capturing 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, make sure you do 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 and check every interface and batch job, both before the go-live and then within 24 hours of the first time they are run at go-live.
5) Make sure to correct and clean up any master data issues immediately at go-live. Each time that master data is referenced by a transaction without being corrected compounds the cleanup effort and the problem needing to be corrected.
Four Part Series on SAP Project Planning for a Smooth SAP Go-Live:
Planning For a Smooth SAP Go-Live: Part 1
(introduction, security and authorizations)
Planning For a Smooth SAP Go-Live: Part 2
(master data, data transformation methods)
Planning For a Smooth SAP Go-Live: Part 3
(process issues, blueprinting, testing, and change management)
Planning For a Smooth SAP Go-Live: Part 4
(custom development, costs and consequences of inexperienced developers)
Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.
- sap transaction data during go live