Product Lifecycle Management Blogs by Members
Get insider knowledge about product lifecycle management software from SAP. Tap into insights and real-world experiences with community member blog posts.
cancel
Showing results for 
Search instead for 
Did you mean: 
christoph_bergemann
Active Contributor

Introduction


First: happy new year to all of you

Second: 2019 some additional interest have been seen in the area of "Data migration". Therefore: some update of this document seems to be needed

Coming back to the primary question as such:

In which situation you need to "migrate" data to EHS classic?

Let us first define EHS classic: more or less this is module SAP EHS-BD (EHS-SAF, EHS-DGM, Maybe you can add GLM as well (e.g. set up of Label View Data in the material master data segment)).

First you should get answers to these simple questions

  • Why do you have a need to migrate data? (e.g. because you would like to get rid of old legacy system?

  • What data is to be moved/migrated? and is this move to be done in several phases (because of your project plan)?

  • What are the options to migrate?

  • What are the challenges in migration?

  • What about the "Cleansing" part in the migration?


You should consider as well questions as: What approaches are used by "SAP" and other companies (project types; methodologies etc.)

and "Can I benefit from these approaches?"

etc.

Coming back to the "Cleansing" part... in many cases the data in the "old system" is not in a good shape (becaus of lot of reasons).

It is a good idea to check: can you improve this situation during the migration?

Honestly: in most cases you will not really focus on the cleansing part. You will be lucky to migrate something to get a new system with data and the data can be used in the subsequent process. Data, in this case, can be as well "documents" (e.g. Safety Data Sheets).

Coming back to the questions as such:

Answer: First question "In which situation you need to "migrate" data to EHS classic?"

Potential answers are:

1.) you are trying to consolidate your SAP landscape

2.) you have acquired a company and you need to migrate the data in your SAP system

3.) you would like to get rid of old legacy systems and move the existing data to SAP

4.) if we include the topic of so called "Carve Out" projects: Migration can have the meaning of "export" as well

Let us take a look now on detail:

What data is (or must be) in focus?

Looking on the SAP EHS standard data model we have to consider these data objects as part of such a migration:

- REAL_SUB

- potentially REAL_GRP data

- LIST_SUB data

- PURE_SUB data

- DG data (DG_CL_SUB and corresponding sub objects like LS_UN_SUB)

- Link MM to EHS (REAL_SUB does have a material assignment)

- phrases

- potentially legal content

But the most critical part here is:  you will only ! succeed if you have mapped as well your materials so that all of the newly generated REAL_SUB does have some link to a material. On the top: if GLM is in your focus: you must populate the LabelView; and clearly: your material must be "active" for EHS (environmental indicator in the material master data).

In many cases: a migration will/might happen to a certain extent as well in the area of Substance Volume Tracking; but the approach to use is 100% company specific.

Depending on the scenario: you should add the topic of WWI reports (and/or inbound reports) as well to be migrated.

Consolidation of SAP landscape


Here we can have many subscenarios. Typically are these scenarios:

- You are using at least two seperate SAP ERP installations

- You are using one SAP ERP installation with at least two clients

You need to check on top which SAP processes you use (in the old system) or you would like to use in the new system. E.g. sometimes you should ask this question:

  • Do you use different process per "system"? so in one system/client you use BOMBOS but not in the other etc.


Scenario 1:


The "Best practise" to be used depends on this question:

Is there an ALE data exchange between the systems?

If answer is "Yes" you can assume that customizing set up is similar. If answer is "No" you can assume that there are differences in setup which you need to consider in the "consolidation" process

Scenario 2:


Here the question is. is there a data exchange existing via ALE between the clients. Based on the answer the same challenges can be seen as in Scenario 1

But in many cases: there is no data exchange done yet between the systems. So any of the "clients" or "Systems" contains some data, which is not the same as in comparison to a different client or system. On the top: may be you use "SERC" service in one SAP client but not in the other SAP system.

What can be different? What is the difference between two SAP systems?

E.g. used phrases can be different (including the fact that the translations of phrase texts are different etc.), customizing set up (property tree, identifier set up etc.), UOMs can be different, etc.

The first step in consolidation is: you need to decide which SAP system will be used in future (new target system) and which SAP system will be stopped for use (source system of data). Luckily: you have two SAP systems to consider. Therefore: you have (HOPEFULLY !! This is an assumption you must check !!) the same basic EHS framwork.

The specific roadmap to use for data migration depends on the used modules. In most cases:

The "core" EHS sub modules are used (e.g. to support MSDS/SDS generation, dangerous goods management, SVT, GLM).

Therefore. if you would like to migrate you need to check for:

  1. Customizing differences (different identifiers, property tree etc. etc.)

  2. Phrases (are they different)

  3. WWI landscape (what need to be adapted)

  4. etc


Now what is a "good" approach to start migration? There is no easy answer.

But if you start to migrate phrases, and if you take care regarding "customizing" differences, you have done a good job.

But what will come next? What you can do easily: you can "download" the data from source system (EHS Export). But in > 80% of the cases you can not upload the data in target system without "adaption" of the data (which is called "mapping"/"Transformation" of  data). This is now 80% of the work as we do not have any kind of SAP tool to support the mapping process. Therefore: this is quite customer specific. But if you succeed: you will create e.g:

REAL_SUB

PURE_SUB

LIST_SUB

DG_CL_SUB etc.

stuff quite easily either using EHS import or the you can upload data using EHS OCC

BUT KEEP IN MIND: you need to consider "Material Topics" as well (e.g. Label View and other stuff which is maintained on Material number level). This is related to EHS; but it is on material level

So for the "material part" you need to use other SAP options/tools to load the data

On top: you need to decide: how to handle the SDS/MSDS dispatchment (as we can assume that in both systems/clients a SDS/MSDS dispatchment is used).

You need to decide by your own if you would like to migrate released WWI reports. But if you have migrated the data: you can just regenerate the relevant reports once again.

The main challenge in this data migration is: there is no "mapping" tool provided by SAP. You can "Export" and "Import" the data. But if e.g. customizing is different: there is no tool available to do that. So this "mapping" is in most case the most time consumig part; keep in mind: you will do may be a lot of "test loads" in the target system; here SAP does not provide an easy option to "delete" data from "test loads". This you need to take care by your own.

If you try to use "ALE" for data migration: the same is true. Never have seen somebody using "ALE" to move the data; but in theory: it is possible.

You can try to handle the data mapping using ABAP environment or any "tool" you can think about to map/transform data. But it is not an easy job.

Acquisition of a new company


If you acquire a company which is using SAP and using EHS: then you are in a good starting position. More or less you have the same options to migrate the data as listed before.

There is a good chance that there is no "SAP" system. If you are lucky then you can extract data using e.g. an "EXCEL" format. A big challenge is to understand the "source data structure" to plan the migration. To analyse and prepare the source data to migrate is the highest effort you can think of. But at least: you must as well define the target scenario in your SAP system. As we have to many source systems to discuss: this is a very specific project having many risks to consider.

For the IT part:

Phrases: you can use standard import or the SAP EHS OCC option

Specification:  you can use standard import or the SAP EHS OCC option

DG data: in most cases you just regenerate the DG or HS master after migrating the "spec" data.

Bad news here. You need to "release" the DG data after migraiton (by using some mass action).

For HS Master Data: luckily there is no "release" process in place; so you need "only" to use the ABAP reports to generate the HS Master data

Removal of old legacy systems


Here nearly the same challenges can be listed as before. The only difference (luckily) is: you know very well your old systems and the options to extract data.

But as well: you need to consider a huge amount of work for "mapping" (old data structure to new data structure). It is as well a good idea to do the migration (if possible) step by step (e.g. start with phrases etc.).

Conclusion


Most of the work to consider is done in relation of "mapping" (source system data structures <=> target system data structures ), defining the "target structures" (do you need new customizing?), what need to be migrated (from source system), in which sequence should the migration be done? How to train the new users (in SAP)?

As EHS is directly linked to SAP MM: you can start the migration only of you have good competencies (link of MM to EHS) in SAP MM as well. The effort involved depends clearly on the "modules" of interest (e.g. EHS-BD, EHS-SAF, etc.)

What data is to be moved/migrated


As explained above:  we have REAL_SUB etc. To load data for REAL_Sub you need first "component" data (e.g. PURE_SUB/LIST_SUB etc.).  Therefore most of the work is "mapping". E.g. CAS number 50-00-0 can have spec key "A" in the source system but "B" in the target system. So for any compositition/spec listing etc. you must make sure that you can map on "B" (if "A" was used in source system)

What are the options to migrate?


As mentioned: you can use standard export/import options; you can use "OCC" and you can use "ALE". But most of the work is not the "technical" part (not easy anyhow) but the mapping and to do the migration in the right sequence.

What are the challenges in migration?


Mapping of any kind is a challenge. On the top: as SAP is not providing any "tool" or "methodolgy" to work on the mapping: it is your job to look for solutions to do the mapping and to apply it (for all the data). Keep in mind. even for small companies you can assume that at least 10.000 REAL_SUB might exist.

Links (PLEASE EXECUTE A QUERY HERE: YOU WILL FIND MANY MORE THREADS)

I have now added some threads discussing as well ALE topics

https://blogs.sap.com/2017/07/01/occ-load-options/

Some recent threads can be listed here discussing "import"/export topics:

https://answers.sap.com/questions/12947152/packing-requirements-data-importing-issues-for-un.html

https://answers.sap.com/questions/12942551/inheritance-issue-in-cg33-specifcation-import.html

https://answers.sap.com/questions/12934151/identifiers-in-lower-case-issue-with-cg33-un-liste.html

https://answers.sap.com/questions/12930647/cg33-specification-import-issue.html

https://answers.sap.com/questions/12925500/cg33-spec-import-is-not-fetching-all-the-data-whic.html

https://answers.sap.com/questions/12915621/exporting-specification-in-cg02-tcode.html

https://answers.sap.com/questions/12903651/error-while-doing-the-specification-import-using-c.html

https://answers.sap.com/questions/12888794/how-to-create-long-text-more-than-132-chars-with-b.html

https://answers.sap.com/questions/470991/ehs---import-specificationsphrasesreportsetc---err.html

https://answers.sap.com/questions/688295/ehs-occ-xml-upload.html

https://answers.sap.com/questions/614781/can-occ-import-spec-identifiers-with-a-specific-us.html

https://answers.sap.com/questions/107314/hello-willem-just-to-ask-how-you-have-used-the-inb.html

https://answers.sap.com/questions/11388420/export-of-specifications.html

https://answers.sap.com/questions/9539633/ehs-master-data-migration-from-legacy-system.html

https://answers.sap.com/questions/10514819/dg-phrase-export-from-ecc-to-tm.html

https://answers.sap.com/questions/3491390/extraction-program-for-ehs-ehs-to-xi-scenario.html

https://answers.sap.com/questions/439471/can-i-upload-the-phrases-in-format-other-than-dat.html

https://answers.sap.com/questions/90420/dg-data-distribution.html

https://answers.sap.com/questions/693181/idocs-for-dangerous-goods-managment-respective-to.html

https://answers.sap.com/questions/10936375/distributing-the-dg-data-to-logistic-system.html

https://answers.sap.com/questions/7131264/ehs-interface-to-distribute-the-specification-data.html

https://answers.sap.com/questions/11282753/create-dg-master-using-bods.html

https://answers.sap.com/questions/11105044/error-during-dg-data-distribution.html

https://answers.sap.com/questions/188924/un-phrase-key-description-import-into-sap-system-f.html

https://answers.sap.com/questions/11877486/dangerous-goods-master-creation.html

https://answers.sap.com/questions/11068950/specification-master-data-upload-through-cg33.html

https://answers.sap.com/questions/11814098/data-editor-tool.html

https://answers.sap.com/questions/12205806/error-in-phrase-import-number-range.html

https://answers.sap.com/questions/12717343/import-long-text-via-idoc-submas02-into-e1bp1077ri.html

https://answers.sap.com/questions/12524629/compliance-requirement-mass-upload.html

https://answers.sap.com/questions/12327599/inbound-submas-idoc-from-external-system.html

https://answers.sap.com/questions/11283552/dg-data-migration.html

https://answers.sap.com/questions/10741548/data-transfer-of-substances-fails.html
7 Comments