When customers ask Tom Kennedy, founder and CTO of BackOffice Associates, LLC, what one of the biggest challenges during a data migration project is, he consistently answers: the data mapping process. This process, which is often poorly defined and misunderstood, tends to confuse IT teams and delay projects. In this article, Kennedy shares his observations and advice for how companies can get their data migration projects off to a good start by mapping data quickly and carefully.
The data mapping process begins early in an IT project and is often immediately troublesome. The process is typically assigned to a group of people — on both the customer side and the systems integrator (SI) side — who are new to SAP technology. The customer has not yet been trained to use the new technology, while the SI often assigns a junior consultant (a newbie) to help the customer perform the mapping functions. This combination creates a time-consuming mapping process with a high probability of errors. To help remedy this situation, place experienced people on the mapping team; mapping is design work. Here are five recommendations for how to complete the mapping process.
Recommendation #1: Don’t Let Mapping Documents Become Useless Deliverables
I find that there are two key problems in the mapping process that can lead to the end product — the mapping document — becoming completely useless:
- The business holds on to the mapping document for too long, refusing to sign off on it. This happens because business people tend not to understand a transaction code like MATNR or the importance of the MRP Controller, and holding on to the documents gives them time to learn more. It also prevents the mapping team from having more time to make changes. The business knows that it will likely be blamed for any erroneous changes to the mapping document; therefore, the people who need to sign off on it tend to hold on to it for longer than necessary.
- The mapping team is mapping to a moving target. Any difficult mapping decision cannot be made until the design is completed; however, the mapping is due when the design is complete (I discuss this problem in more detail later).
When you begin mapping, start by asking a simple set of questions. For example:
- Are you going to use your old customer numbers or assign new ones?
- Who is managing the customer hierarchy, and can we talk to that person when the design is done?
To understand why such questions are important, look at a typical mapping document sequence (below).
A mapping document like this is useless because every project maps the simple fields the same way and the complex fields differently. It provides no new information for an experienced SAP resource. You can throw this document away.
Instead, asking those two earlier questions gets to the root of exactly what you need in your data mapping scenario.
Recommendation #2: Account for All Levels of the Mapping Process
The mapping process spans four levels, beginning at a high level and increasing in complexity as the levels progress.
- System-to-system mapping is determined by the scope of the project and addresses questions like: Which operating units and plants are involved? Which computer systems contain the data? What type of software houses the data?
- Object-to-object mapping, which is fairly easy, is determined by which tables in your legacy system contain the data you are looking for. This level is specified mostly by your IT organization since it knows the table names.
- Field-to-field mapping is more difficult; the IT organization does not typically understand the actual uses of the fields and is unfamiliar with the field values. For example, while the business knows that the field value “DNS” means “do not ship,” IT probably doesn’t understand this right away — so the business must take responsibility for this mapping level. Field-to-field mapping typically generates around 1,500 mapping opportunities.
- Value-to-value mapping is the most overlooked mapping process — for any configured SAP field you map to, each legacy value must map to a valid SAP value. For example, “Old Chart of Account” must map to “New Chart of Account,” and “Old Payment Terms” must map to “New Payment Terms.” Value-to-value mapping can generate over 10,000 opportunities.
Typically, these mappings are done in a spreadsheet and then converted into technical and functional specifications for converting your data. Creating these spreadsheets is time-consuming and hard to manage. Instead, we recommend that mapping teams consider using an application that helps them to gather mapping information for an SAP implementation, define the scope, document the rules, and track changes during the mapping process. A web-enabled application, such as BackOffice Associates’ EZMap solution, provides an auditable, repeatable process that helps manage the mapping rules between legacy data and SAP target data more efficiently.
Recommendation #3: Focus on the Portion of the SAP Application You Are Going to Use
Overall, SAP ERP applications contain close to 74,000 tables and over 800,000 fields. However, our experience has shown that typical projects involve mapping to only about 175 tables and 1,500 fields — and that only around 65 fields need to be documented. (BackOffice Associates can provide more details on this list of tables and fields and which ones need to be documented.)
Do not waste time debating the use of a field that is never mapped to. For example, you most likely won’t need to map to the “Train Stop” field in an SAP customer table, and there will be other fields that you will simply be unable to update. Save time and money by only mapping to fields you will use.
Recommendation #4: Start Mapping Early in the Project — and Keep Going to the End
There is one question that lingers: Are the mapping documents ever really “done” or “complete”? Mapping is hard to “complete” early in the project because the customer does not yet know the SAP technology, and the design won’t be “done” until after integration testing. So the mapping can still be changed throughout the project.
However, the mapping process is part of the design phase, so when that phase is done, people will expect the mapping to be done too.
Too many people decide the mapping process is “done” once it exists — a laughable concept, if you think about it. We’ve seen mapping documents in which there is no content, and we’ve seen templates list all the fields in a particular table with no mapping information. While some might consider this mapping document “done,” it is totally useless.
What needs to happen here is a change in expectations. Teams must start mapping needs early in the project — but they also need to realize this process will likely not be complete until the very end of the project.
Realizing that the mapping process will extend across a project gives you the flexibility to accommodate any changes the mapping needs. You can expect the most complex mappings to change the most!
Recommendation #5: Read Through the Mapping Documents Carefully
As you would with any important document, read the mapping documents carefully before you sign off on them. Treat the signing of a mapping document as you would the signing of a purchase order. Take caution with phrases like “to be determined” or “design is not completed.”
When it comes to data mapping, most companies have trouble getting off to a good start. Follow these five recommendations for a fast, efficient mapping process, and your business will thank you for it.