Skip to Content
Author's profile photo Former Member

Confused about what is current or successor functionality versus “classic”?

I’ve been asked to try to clarify the different product components within the EHSM space with especially an overview of “overlap” of Component Extension solution and EHS classic. The rapid innovation over the last 5 years has made this a moving target and some different approaches have been taken, for example with respect to the old Industrial Hygiene and Safety application versus product safety topics such as Global Label Management and different again for areas like EHS Regulatory Documentation or Product Stewardship Network.

I suggest that to stay current, consultants should start here and please note that this is a product component view, and is not a 1:1 match to license requirements:

This takes you to all of the official documentation for the

  • component extension for SAP EHS Management.

In particular, consultants should follow the link to the Application Help (SAP Library) and study what is there.

Then, going back to the main page, if you look at the left panel menu, you’ll also see

  • Apps for SAP EHS Management
  • SAP Environmental Compliance
  • SAP Product and REACH Compliance
  • SAP EHS as part of SAP ERP
  • SAP EHS Regulatory Content
  • SAP Product Stewardship Network
  • SAP EHS Regulatory Documentation OnDemand

Looking just at SAP EHS as part of SAP ERP, the component extension for SAP EHS Management as of the 5.01 release has essentially replaced the following older applications: Industrial Hygiene and Safety, Hazardous Substance Management, and part of Occupational Health (all but the actual medical appointments and medical record-keeping.) The component extension has significantly more functionality in the “people health and safety” areas and is a more collaborative solution rather than “system of record” type transactional system. For new customers, the choice is clear to go with the component extension. For customers with heavy implementation of “classic”, they need to carefully consider when is the best time for them to upgrade.

In contrast, for now at least, the product safety applications such as Dangerous Goods and Global Label Management are still in the SAP EHS as part of SAP ERP.

Looking at the product compliance functionality, the component extension for SAP EHS Management is (for now at least) mostly focused on the requirements of discrete industries rather than process industries. It likely replaces the older SAP Product and REACH Compliance, but customer specifics may differ.

The 6.0 release (June 15, 2015) introduced the successor to SAP Environmental Compliance (which is in the JAVA stack) with ABAP Webdynpro in the EHSM component extension. Customers who have already implemented Environmental Compliance do not need to rush to switch over, but can do so sometime in the future when it makes sense for them.

The last three items on the list above are completely different, being content delivery and cloud solutions.

Again, this is a moving target. The development teams are often put in the position of trying to predict the future and are doing their best to leverage new technologies. In December of 2010, when the component extension 1.0 for SAP EHS Management was released to customers, HANA, cloud, and Fiori did not even exist. Who knows what will exist in another few years?

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Christoph Bergemann
      Christoph Bergemann

      Dear Mary

      🙂 😆 😎 😉 😀 😘

      Thanks for providing such a document. I hope that this might help as confusion does exists. The reasons are mentioned as well in your document. Things are changing rapidly. SAP tries to improve their solution landscape  and develop solutions which fits the needs of industry (e.g. now e.g. Cloud solutions are "on hype" as well as SAP HANA). Main challenge in my opinion to seperate the use of SAP EHS Classic from the use of Component Extension". I hope that your document will help here as well.


      PS: Basic conclusion reading your document: SAP will go on and "migrate" SAP solutions from past more or more in direction of modern UI and SAP will try to improve the "integration" options of EHS solutions (e.g. as discussed in different thread "MoC" approach).

      May be you should extend your document. The "use" of SAP solutions per "industry" is one "driver" to select SAP landscape to be used. I believe this is not understood very well (e.g. . difference between "Process industry"/"Discrete industry" etc.). To "map" the SAP solutions to "industry" specific demands could help SAP community to understand the solution landspace of SAP much better.. E.g. the use of SAP GTS in this context might be of interest as well.

      PPS: may be create a table in your document like this (only high level) to make clear which SAP solution support which business process.

      Question                    EHS classic                    Component Extension

      SDS supported          Yes                                   No

      DG supported               Yes                              No

      Waste management     Yes                              No

      SVT REACh               Yes                              No

      BOMBOS                    Yes                              Yes


      Author's profile photo Former Member
      Former Member
      Blog Post Author

      The table you list above seems to be product compliance centric, not mentioning the "people" safety and environmental compliance topics. Product safety and compliance is not my focus area, so I can talk about it at a high level, but not deep.

      To be clear, mixing the component extension and the EHS as part of ERP ("classic") is not a problem for different business processes. So, using the incident management application in the component extension and using the dangerous goods application in EHS as part of ERP is perfectly fine.

      To explain more about discrete industries and process industries:

      Discrete refers to products that are built up by component parts - like a computer or a car. Process refers to industries where materials are processed, usually with chemical reactions or at least changes in physical state - like drilling for oil, mining and processing copper, chemical production, and plastics. Of course there are companies that do both.

      While some business processes are the same or at least very similar for both, others are either completely different or at least the magnitude is different. Let me give some examples.

      • Incident management is a business process that is used by virtually every industry. You may have industry and country specific requirements, such as reporting to the Railroad Administration if you are a railroad company, but the basic process of reporting, managing injuries and getting employees healed and back to work, incident investigation and so forth is common to all.
      • On the other hand, some product compliance business processes are very different between discrete and process. In the process industries, you need to know what raw materials change into during the process (chemical reactions, burning of fuel, etc.) In the discrete industries, you need to track use of specific materials from all of your suppliers (eg. how much tin is contained in my final product.) So, while both process and discrete manufacturers have to meet the REACH requirements, the pain points are different. As you can imagine, if you are building a product out of many parts that come from many suppliers, then keeping track of how much tin is in your final product means that you have to know how much tin is in each of the component parts that you purchased. Different suppliers might even have different amounts of tin in their part. On the other hand, if you are buying basic chemicals and reacting them into a new chemical, then you can't simply calculate from the raw materials to determine what is in the final product. Hence a solution that is designed around the basic process of asking your suppliers what is or is not in their product is not going to be sufficient for a process industry customer.
      • For the SDS authoring process, if you only need to author 20 per year, this is much different than if you need to author 20,000 per year.
      • If you are running a doctor's office or hospital, then medical data management would be quite different from a company who only needs to track whether or not employees had an annual hearing test.

      I am sure everyone can think of many other examples. The point is that the basic business process might be the same, but there are differences in magnitude as well as differences in focus. This means that sometimes the solutions need to be different. In my hospital example above, the small company could probably use a hospital solution, but it would be overkill and the users would undoubtedly find it cumbersome.

      Author's profile photo Christoph Bergemann
      Christoph Bergemann

      Dear Mary

      the tables was only an "example" of structure. But you are right. Structure is  "product compliance centric". But product compliance centric does not mean that you need not to care about "people" safety.  Especially in the area of REACh this is not really possible; and to take care about accidents/incidents is in many countries a "legal" must.

      I can not 100% agree to your statement:

      "To be clear, mixing the component extension and the EHS as part of ERP ("classic") is not a problem for different business processes"

      From technical poitn the answer is "easy": Yes you can use EHS classic and new solution parallel (and there is some interface between them).  But my "wording" would be: for some businesss cases you should prefer to use "EHS classic" and for others you should prefer new solution (in those cases there an "overlap" in functionality exists)

      Regarding your comment:

      • For the SDS authoring process, if you only need to author 20 per year, this is much different than if you need to author 20,000 per year.

      I am not sure If I catch what you are thinking about. If you would use classic "CLEO" (or new solution) you will get some updates in system. So therefore in most cases 4 times per year you will get updates.Based on "if else" scenario (and by using rule sets etc.) will idnetify "easily" which SDS might be effected to be regenerated (same as with Labels). But the need to change something mainly depends on your product portfolio and the legislaiton changes. So there mnight be years there you need to to change something; and in different years the need to change is higher. Overall: I would expect that you will only rerelease not more than two times per year a SDS.

      Conslution: Thanks for feedback and comments.


      PS: honestly the use of EHS-OH seems to be limited (based on the number of threads in this FORUM).

      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Regarding my comment with regard to 20 SDS versus 20,000, what I mean is that if a company only needs to author 20 SDS per year, they actually might decide to outsource the authoring process. SAP has a solution called SAP EHS Regulatory Documentation that provides exactly that. In that case, you don't need to implement and maintain the substance database. There are many good reasons to use the substance database. My point is simply that there are other ways to accomplish SDS authoring, and the less of them that you need to author, the more cost effective it might be to outsource it.

      Regarding your comment about OH - I can't disagree with you 🙁

      Author's profile photo Christoph Bergemann
      Christoph Bergemann

      Dear Mary

      thanks for feedback. I misunderstood your "thinking" in regards of the "authoring topic of SDS". So you are right: the option to use services from SAP as part SAP EHS Regulatory Documentation is helpful.


      Author's profile photo Sunil Jawalkar
      Sunil Jawalkar

      Dear Mary,

      There is one more confusion we have is Audit management is replace by Control Inspection? (Functionality comes with CE 4.0 and 5.0 to measure effectiveness of Control)  Or still Audit management (cross application component) is part of SAP EHSM best practice solution as mentioned in document 999_ERP605_BPD_EN_US (EHP5 for SAP ERP 6.0 June 2011)

      Could you able to share any SAP market place link to get updated document, which supports Audit Management is still part of EHSM best Practice solution, it would be great help for us.

      In many SAP EHSM proposals and best practice solutions Documents, SAP proposed Audit Management solutions for sanitary regulation, Safety Audits etc. Now such scenarios are going be handle under control inspections? 

      If you have different opinion please share.



      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Great question and thanks for asking it so I can provide some information.

      The term auditing is used very broadly and covers a wide spectrum of similar business processes from very simple inspections (audits) to complex multi-day and multi-topic compliance audits. These major audits often have a complex scoring system where section scores roll up into a final audit score. They also often have different types of findings (such as continuous improvement suggestion versus major finding versus non-compliances.) Finally, they typically have a multi-page final report and then follow-up activities such as a Corrective Action Plan (CAP). Any solution that can handle the very complex audits will likely be too heavy for the very light type of audits.

      The control inspection "audit" in the EHSM risk assessment application is intended for the simple type of audit, and in particular it provides a way to assess the effectiveness of the controls that have been put in place in order to reduce a risk. As a simple example, you have the hazard of flammable materials resulting in a risk of a fire at a location. You put in place fire extinguishers in order to mitigate a fire if one should start. And you need to check these fire extinguishers frequently to ensure that they are in place and working. In many companies, the weekly fire extinguisher inspection is assigned out to individuals for two reasons. One is to spread the workload to all workers. But the second is because by doing the inspection, the worker is more safety conscious and more aware of the fire protection program. Other examples of simple audits would be the daily housekeeping inspections conducted by operators on every shift, a monthly inspection of the storm water pollution prevention program, and Personal Protective Equipment (PPE) inspections.

      Advantages and limitations of the control inspection in EHSM risk assessment application:

      + simple to create new question lists

      + simple to create a recurring inspection

      + great UX for the inspector/auditor using the Fiori app

      + links back to the underlying risk that is being mitigated and the risk owner automatically receives notification of the results of the inspection so that s/he understands if the risk is being controlled adequately or not

      - simple yes/no/na answers only (no multiple choice or numerical answers)

      - only uses a simple scoring system (% yes answers)

      - corrective actions are not created within the control inspection app - instead they are created in the risk assessment itself

      For the complex audits, the audit management application in SAP ERP is still a very appropriate solution. In addition, SAP Quality Issue Management (QIM) is a great place to now create the Corrective Action Plan (CAP). You might still need an experienced user to create the audit itself (questions, scoring, etc.) but the people who have to manage the CAP have the great UX provided by QIM.

      One other point about the control inspection in EHSM risk assessment:

      In some companies, some of these light inspections are managed in the Plant Maintenance application. Certainly something like a fire extinguisher inspection can easily be handled in PM. However, since they are often conducted by people who are not working in the maintenance department and who do not need the complexity of the PM work order (such as recording time, materials, etc.), moving these inspections to EHSM will simplify things. And as stated above, EHSM also provides the direct link back to the risk owner which is very useful from a reporting and continuous improvement perspective.

      Author's profile photo Sunil Jawalkar
      Sunil Jawalkar

      We appreciate your efforts to make this simple for us.

      Thanks Mary.