SAP EHS Component reimplementation

[#1]

Dear Experts,

Here I am not seeking resolution to any error but just need a thought that can be helpful. The scenario is, one of my clients parted out from another company but during implementation, probably lift & shift sort, it inherited the previous orgs FM's/ codes/ programs and may be some config as well. Now there are multiple issues that are being faced for e,g expert rules issues (while writing data) , duplication of data, some redundant data which is likely to be inherited from former one. As a solution to this issue they want to go with the approach of reimplement EHS Component again (' clean slate') instead of keep resolving issues. Here is where there are multiple unanswered questions are lingering.

1) While other modules (MM, SD, PP, FICO etc) are running in parallel, is it possible to do a reimplementation of only SAP EHS ?

2) Or is it advisable to go and resolve issues module by module (Product safety- SVT, rep mgmt, Templates, DG, Waste Mgmt. etc.)and clean the system. But here it will be complex task to identify the unwanted data and programs.

3) While going through reimplementation, how can this be achieved in production while other business process are running. Only DG, Rep shipping are integrated with logistic. SVT is still not live due to issues.

4) Even in that case also, Is it possible to clean slate every thing at one go ? Here may be the customization can be copied from a prototype environment and reload the master data again. The major challenge here is integrated functionalities will be on hold till that time.

5) Imp question: Is there any other approach that any one has done it before for such situation.

Not sure if all this questions can be answered, but a small thought / suggestion can be helpful.

Regards,

Ashish

[Mark-Pfister]

Hello Ashish,

I would recommend a different approach:

There is no need to migrate the data for the PURE_SUBs that a content provider can provide - or that can be calculated by a rule-set like the GHS classification.

Therefore focus on the properties that have been manually maintained - and only migrate these (after the clean-up).

Same for the REAL_SUBs: only migrate manually maintained data like Composition, PhysChem or Tox data - and let the rest be recalculated using expert rules.

In order to achieve a Go-Live, migrate the existing SDBs - and let the customer over time re-create the data on the REAL_SUBs and release new SDS ...

This approach has proven itself to work...

Best

Mark

[ashish25bp]

Exactly ! we are also going the same way, in fact I forgot to mentioned above that we have sorted out those properties that will be updated through LIST_SUB, LS_UN_SUB or which are update through expert rules resulting into reducing the data maintenance. But even after considering that, there are still much more manually maintained properties; so was checking how can I convert it smartly reducing human efforts.

But any way thanks for suggestions this helps that I am in right direction.

Thanks