An Oracle Approach To Environmental, Health, and Safety Enablement
An Oracle Approach To Environmental, Health, and Safety Enablement
An Oracle Approach To Environmental, Health, and Safety Enablement
Environmental, Health,
and Safety Enablement
INTRODUCTION
Companies aspire to be responsible members of their community by creating a safe environment for their employees
and minimizing their impact on the air, water, and land. In conjunction with those efforts, Manufacturing companies
also comply with a series of regulatory requirements aimed at addressing environmental, health, and safety (EHS)
issues.
EHS risk management is focused on the people, materials, and assets that are used to manufacture product and deliver
services. Processes that manage these resources must be established, monitored, and optimized to minimize the impact
on the environment and the health and safety of employees and the community.
To support the full range of their EHS responsibilities, each company must establish an infrastructure for capturing,
analyzing, and acting on data generated by their operations. Oversight bodies at the Federal, State, and local level
require reports using specific formats tied to applicable regulations. The approach at each Company will vary based
on the manufacturing processes and regulatory requirements that are unique to their organization. Each company will
also have a different initial level of maturity, perhaps driving them to start with manual processes and then to move
toward higher levels of sophistication over time.
The goal at Oracle is to provide a set of capabilities that can be leveraged to capture, store, and act on data generated by
the core business processes. The captured data can be used by the EHS team at each Company to develop process-
and regulation-specific plans and reports. Instead of providing a separate application that lays on top of the core
business processes and requires duplication of effort to populate and operate, Oracle embeds EHS operating, tracking,
and monitoring processes in the manufacturing processes that potentially affect the environment or the health and
safety of the employee or general population.
This White Paper provides an overview of the approach Oracle recommends for establishing the EHS infrastructure.
The model will entail the use of Oracle applications, process-specific Bills of Material and Routings, custom reports,
and third party software.
Oracle does not purport to be an expert on EHS laws and regulations and does not make an effort to maintain specific
processes or reports aligned to those legal requirements. Oracle’s reporting capabilities can be leveraged to generate
customized reports that display the unique information required by Federal, State, or Local regulators. As with other
business processes, the transactional flow and data elements can generally be configured to meet the specific regulatory
reporting requirements.
Figure 2 shows the general EHS functional requirements and aligns them with the Oracle module that can be used to
comply. This White Paper provides additional guidance on the approach that can be used to build the appropriate
infrastructure based on the unique requirements at each company location.
Waste
Permits and Licenses Emissions eAM / Quality / Inventory / WIP
Exposures
Screen Shots are included in the Appendix showing the method used within these modules to capture relevant EHS
data. In the sections that follow, links are provided to the specific screen shots referenced in the text.
The graphic below provides the basic framework for the EHS model. Each company will need to evaluate its business
model, objectives, strategy, and policy to determine the breadth and depth of its approach. The applicable Federal,
State, and Local laws and regulations determine the nature of data collection and external reporting that is required.
Identify
Risks Investigation
Findings
Create
Controls Recommendations
Actions
Each aspect of operations introduces hazards that must be exposed, risks that must be identified, and controls that must
be created. Each input, process, and output requires documentation, associated training, and auditing of results to
ensure compliance.
Incidents that arise from process failures must be captured, investigated, and addressed. A closed-loop corrective
action process will help improve the model over time. Across the ecosystem, data must be collected and reports
generated to satisfy the appropriate oversight organizations.
Characteristic of the Activity that changes a Planned activity to verify Unplanned Activity that
Resource Characteristic of the process effectiveness affects a Resource in a
Resource negative way
For each Input, Process, and Output, there are Attributes that define it and its characteristics. These attributes help
answer the Who, What, Where, and How questions about the People, Materials, Tools, Equipment, and Activities that
are used in the business. They can describe who has the appropriate certifications, what safety precautions are
appropriate for inventory items, or what operating tolerances a piece of equipment offers.
There are Transactions that reflect actions taken that affect the attributes of the resource, changing its state, location,
or condition. When People are trained, when material is moved or processed, or when equipment is maintained,
transactions are generated that change the status of the attributes. These transactions generate a history that reflects
activities and processes as they are executed.
Once the EHS models are established, Audits verify that the attributes are accurately reflected and that transactions
have been accurately recorded. In addition to validating that captured information is accurate, audits can be used to
determine if there are unidentified risks or hazards in a work area or associated with a process. An effective audit
program attempts to ensure that the EHS model is working as planned.
If process controls have not been effective, then Incidents occur, and they must be recorded, reported, and addressed.
Incidents reflect a breakdown in the controls put in place to avoid an EHS failure. If a material is spilled, an employee
is injured, or a safety violation occurs, then an extraordinary event has taken place and action must be taken. A
mechanism must be in place to capture the incident and administer the process to address the failure. The process
should be closed-loop so that corrective actions are put in place to prevent recurrences.
ATTRIBUTES
The Attributes of each specific Input, Process, and Output are captured in the relevant business system. Material and
Product attributes can be captured in the Item Master and Bill of Material. Personnel attributes can be captured in the
Employee Record. Asset attributes can be captured in the Enterprise Asset Management (EAM) records. Flex fields
can be created for required attributes that are not standard entries.
Process attributes are captured in the Bill of Material and Routings for manufacturing processes, in the EAM system for
assets requiring calibration, preventive maintenance, and repair, and in the HR system for personnel related processes.
Examples of attributes that are particularly relevant for the EHS model include the following:
Hazardous Material characteristics, including MSDS data can be entered in the Item Master (See Screen Shots 9 –
14)
Hazardous Material planned usage and creation can be captured in the Bill of Material (as an input to and output
from production).
The Inventory and Warehouse functions can be used to identify the quantities and locations of hazardous
materials. This information can include the Unit of Measure and storage method.
Process characteristics can be captured in the Bill of Material (process inputs, formulas, planned waste) and the
Routing (assembly instructions, equipment usage, scrap operations, personnel requirements, and certifications).
The training, certification, and skills for Employees can be captured in their Employee records. When processes
require specific qualifications, the use of the proper resources can be validated by checking the Employee
certification. (See Screen Shots 18-20)
When equipment, plant, or property are used in the manufacturing process, the description, location, bill of
material, and maintenance plan can be captured in the Enterprise Asset Management application. Cumulative
generation of waste can be captured against an asset.
Purchase, receipt, movement, issuance, and conversion of material (including generation of waste or creation of
emissions) can be captured in the Purchasing, Inventory, and Work in Process modules.
Maintenance, calibration, and utilization of equipment, plant, and property can be captured in the Enterprise Asset
Management application.
Hiring, training, certification, and assignment of employees can be tracked in the HR application.
Work by employees against a specific operation or in a particular work area can be captured in the time recording
system.
In addition to the standard transactions enabled by the material, asset, and HR systems, the Oracle Quality module
supports Collection Plans. (See Screen Shots 15-17). A Collection Plan initiates a process flow that intervenes in
standard business processes and requires additional actions or data entry. The graphic below provides an indication of
the type of activities and plans that can be enabled by a Quality Collection plan. Once the data is stored, then the
module enables analytics, charting, and reporting.
Online
Charts Reports Inquiries
Lead Auditor No
No distributes Audit
Acceptable? the audit plan Any
Execution: Yes pending Follow-up
Collect data & audit actions
evidence areas?
Yes
No
Determine No
Audit Areas & Acceptable?
Auditors No Prepare Audit
Is the data Reports with
suf f icient? Findings Audit
Yes Close-out
Prepare Audit Yes
Questions & Audit is
Procedures scheduled Evaluate Prepare Audit
f or execution evidence Reports with
gathered Findings
The Oracle Quality module enables the process steps required for audit initiation and audit execution as shown in the
graphic above. Screen Shots 1 – 6 in the Appendix show the Oracle capability for enabling EHS Audits.
As required, the module can be configured to capture the information that is appropriate for the organization. The
configuration will vary based on sites, locations, organization structure, naming conventions, or business processes. In
each case, the incident report captures the basic Who, What, When, Where information associated with the incident.
Drop-down menus can be added to characterize events in a consistent manner for reporting purposes.
Notification
Sent to
Corporate
Incident Incident
Occurred Reported
Notification
Sent to
Business Unit
Notification Corrective
Sent to Workers Actions Identified / Case
Comp TPA Ownership Assigned Closed
Notification Corrective
Sent to Action Actions
Item Owner Closed
Owner f ollow
Owner Determine Review Implement up on
Reviews Containment Resolution by Action Pending
Request Actions Supplier Actions
Yes No
REGULATORY REPORTING
The extent of regulatory reporting at a company is based on the nature of a company’s business model, the processes it
uses, and the applicability of regulatory reporting requirements as defined by Federal, State, and local oversight
organizations. Although certain Federal reports are standard, the manner in which data is captured and the underlying
meaning of that data can vary by Company and site.
Oracle does not monitor the underlying regulations and reporting requirements to identify changes in coverage, format,
or intent. It is the responsibility of the EHS professionals at the manufacturing company to understand the
applicability of the regulatory environment and its impact on each site. The number of potential reports and variations
due to regulatory jurisdictions and ongoing updates precludes Oracle’s ability to stay current on the requirements at
each Customer location. As a result, Oracle does not attempt to develop standard reports nor suggest the appropriate
business processes to follow.
Oracle supports regulatory reporting through the use of BI Publisher to create custom reporting formats. The
underlying data is available based on attributes, transactions, and data collection described above; the required report
formats are maintained by the manufacturer. By providing the building blocks for data collection and reporting, we
enable our Customers to build the appropriate EHS model for their business processes, regulatory environment, and
level of maturity. Several standard OSHA Forms are represented in the Appendix. Forms that may be required
include:
MSDS Forms (see MSDS format and content per ANSI Z400.1)
Store
Capture Version
Index
Create
Document
Lifecycle Manage
Management
Retain/ Cleanse
Destroy
Search Distribute
Publish
the framework for capturing attribute and transactional data associated with core manufacturing, asset management,
and human resource processes.
the process structure for administering the audit and incident capture processes, and
identifying the Federal, State, and local regulations that are applicable to the business and all of its sites
identifying the inputs, processes, and outputs that are relevant for the business model
defining the EHS hazards, risks, and controls that result from operations
configuring Bills of Material, Routings, and Item Masters to reflect company-specific processes, resources, and assets
defining reports and report formats driven by the laws and regulations affecting each site
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com
The purpose of this standard is to provide information in a consistent manner and to make it easier to find
information regardless of the supplier of the MSDS. The following list indicates the 16 sections of the
MSDS standardized format.
Launch
pad of
common
activities
FIGURES: