AllenWeb Site - since 1995
Concerns in SAP R/3 Implementations - Jun 1998
| Project Management |
Concerns in SAP R/3 Implementations
Business Process/Industrial Process Integration*
--------------------------------------------------------------------------------
Integrating plant operations with SAP R/3
Most manufacturing enterprises can be "mapped" as a five-tier model that includes - from the top down - business
systems, production planning, operations management, process control, and the processes themselves. Different
types of software systems serve at each tier, and vendor's supply software that integrates information throughout
the enterprise.
One such software system is R/3 from SAP. The functionality supplied by R/3 covers the top business tier and also
functions within the next two layers. R/3 has been classified as an enterprise resources planning (ERP) product, but
it is more, and it appears that SAP has even grande aspirations for R/3 in the years to come.
SAP offers a modular family of software packages that covers financials, human resources, quality, maintenance,
production planning, and more. While an integrated system is a great advantage to management, it has the
disadvantage of requiring extensive engineering and implementation efforts. Many companies (mostly well-known
consultants) have formed divisions or subsidiaries to support these efforts, which can cost millions of dollars.
Integrating plant operations with the SAP R/3 ERP system is a particularly challenging project, and there are
different ways of approaching the implementation.
--------------------------------------------------------------------------------
The PP-PI Interface
SAP provides several modules that link to different elements of the enterprise operations. The module for
production planning is called PP-PI (Production Planning for the Process Industry). PP-PI provides two-way
communication between R/3 and the next lower layer, operations management, using a library of Remote Function
Calls (RFC's).
PP-PI performs two basic functions: it enables the download of control recipes to lower-level control systems, and
the upload of process-related data to the form of process messages.
In the control recipe, the following data is transferred: process and control parameters; text with instructions for
operators of manually operated lines; and information relating to the process messages that are to be returned.
Process messages returning to PP-PI supply information on:
the status of process orders;
the consumption and production of materials;
the status of resources; and
selected process events.
In essence, PP-PI allows R/3 to generate instructions for production and download these instructions at scheduled
intervals for execution. It also allows the results of execution to be transmitted back to R/3 to keep track of
inventory levels, production status, etc., and to capture unplanned events, such as process shutdowns. While this
overall scheme can be used for both batch and continuous processing, the design of the system is weighted toward
the batch environment.
--------------------------------------------------------------------------------
Connectivity Alternatives
There are three ways in which PP-PI has been connected to the process control system:
indirect - requiring human intervention
middleware messaging system; and
process information management system (PIMS).
In one early application of PP-PI to a batch process, the computer was limited to issuing instructions - via a
computer terminal - for human operators to follow. The instructions included what to do and what information to
collect for PP-PI. For example, PP=PI might instruct the operator to add given amounts of certain materials to a
mixer, stir for 45 minutes, and record temperatures a five-minute intervals. The operator would collect the
requested information and use the computer keyboard to enter it after the process was complete.
There are several disadvantages to this approach: 1) manual data entries are subject to errors; 2) process data
collected by operators are not easily shared through the system; and 3) this approach can only be used for manually
operated batch processes. It has little or no applicability to continuous process or to processes controlled by
distributed control systems (DCS's or PLC's).
Middleware messaging systems solve one of the problems of the indirect connection. They eliminate manually
entered data by electronically linking to process control systems. They also promise to provide the capability to
have multiple process connections to one PP-PI connection. For example, a single middleware system could connect
PP-PI to a laboratory information system (LIMS) and to multiple DCSs, eliminating the need for a separate PP-PI
connection to each of these process level systems.
By themselves, however, middleware messaging systems are not able to disseminate process data from one
process to other process information systems throughout the plant. They only provide the messaging service
between each process and PP-PI. They likewise do not validate or condition the data from the process and may not
even buffer the information passing from PP-PI to the process.
A PIMS not only acts as a connecting layer between process control and PP-PI, providing the messaging services of
the middleware mentioned above, it also provides the other services listed as deficiencies of indirect and middleware
connections. With the proper extensions, a PIMS offers the most comprehensive and ultimately useful approach.
--------------------------------------------------------------------------------
Process Information Management
Using a PIMS, there are three functional layers to the total enterprise model: 1) ERP, the SAP R/3 business server,
which provides non-real-time data at the management level; 2) information management: the PIMS, which manages
the process of transforming second-to-second real-time process data into useful business information, ensuring the
reliability, accuracy and consistency of the data; and 3) process control: the control system server (PLC, DCS),
which manages the operation of the process equipment.
The job of the information management layer is first to pass information back and forth between the ERP layer
above it and the process layer beneath it and second, to enable the ERP system to achieve optimum performance.
Accomplishing the second objective in not trivial, and it is here where a PIMS (with the proper extensions) can
provide much more that with either the indirect or middleware message systems.
When the PIMS is providing complete functional capability, its tasks are to:
Provide a global connection of the ERP layer. This task is similar to the basic work of a messaging system; i.e.,
translating information that is flowing between PP-PI and the process controller. By providing a common platform,
the PIMS can connect multiple process control systems, as well as a LIMS, to one PP-PI, simplifying the overall
network architecture and providing standard interfaces. Because a single PIMS server can encompass all of the
processes that are part of an entire manufacturing operation, and because the PIMS has considerable processing
"smarts," it can pass a global view of the process up to PP-PI, something that may be difficult for a messaging
system.
The global connection provided by PIMS extends the same network that connects PP-PI and the PIMS to other users
of process information throughout the plant. These users at their desktops then can visualize process data using
tools provided by the PIMS and also can import the data into their favorite desktop spreadsheets or databases.
Support ERP message needs. PP-PI messages contain recipes to be made, tests to be performed and actual results
achieved, such as the amount of material made, its characteristics, peak temperatures during manufacturing,
laboratory quality assays, and SPC charts. These messages must be both buffered and converted to a meaningful
format for the process control layer.
Buffering acts to synchronize the transactional nature of information at the business layer with the real-time nature
of information within the process control layer. Buffering also manages timing differences between the business and
process control layers. For example, PP-PI can pass a group of recipes for weekend manufacturer, and the
buffering function within the PIMS message layer can distribute the recipes to the process control system as needed
during the weekend.
Message conversion includes matching data elements between the business layer and the process control layer,
since the business layer and the process control layer do not generally speak the same language. What the
business layer calls a particular data element rarely will be the same name used by the process control layer. These
differences can be rationalized by data element mapping within the message layer of the PIMS.
Convert and reconcile process data. Another conversion function performed in the PIMS is unit conversion, which
can be more complex than simply converting metric tons to kilograms. For example, the business layer typically
uses weight while the process control layer typically measures flow. The PIMS must handle the requisite conversion
based on process parameters.
Even more important, the PIMS verifies that the data being passed up to SAP make sense: a middleware messaging
system, on the other hand, simply translates the data and passes it on without regard to integrity. A PIMS looks at
the data logically; for example, does the quantity produced equal the sum of the quantities put into the process? Is
the average reaction temperature within the correct range for SPC temperature data? Is the production time
appropriate?
Answering questions like these is absolutely crucial to the functioning of SAP, which relies on the validity and
accuracy of the data it gets. An error inadvertently passed up to SAP can be perpetuated within the company at an
alarming and potentially devastating rate.
Monitor real-time events. The PIMS must pick up information in real-time and convert it to a meaningful
transactional format for SAP. PP-PI does not keep track of time. It identifies a transaction that it wants to happen
and the results that it wants back when the transaction is complete. The PIMS must capture the beginning and end
of every transaction and synchronize transactions with real-time events. Int the case of continuous processes, the
PIMS must also translate an ongoing process into discrete and measurable events, viewing the continuous process
as a sequence of timed transactions that are tightly linked, each one occurring immediately after the previous one is
completed.
Track available resources. PP-PI provides a certain level of scheduling based on the order in which it passes recipes
down to the process control system. However, PP-PI does not track resource availability - so if a recipe requires
certain equipment that is currently occupied, executing the recipe mus be held up until the equipment is available.
A PIMS can provide information on equipment availability to either PP-PI or another scheduling system outside of
SAP, making it a valuable resource optimization tool.
Deliver product genealogy and material tracking. When problems occur in a manufacturing process or questions
arise regarding the quality of a delivered order, the genealogy of the product or raw material is of great importance.
The PIMS can trace the path to find out what may have caused the problem. A PIMS also can trace material
forward to tag downstream products that might be impacted by the defective material. The capability to chain
backward and forward along a manufacturing path is critical to the FDA and other standards organizations, and it is a
job that is difficult for both SAP and messaging systems.
Provide data visualization and SPC/SQC charting. Critical decisions in troubleshooting and improving processes
depend on knowing the cause-and-effect relationships within the process. The PIMS provides the computerized
visualization and analysis tools to enable operators and engineers to make these critical decisions. Currently, these
tools work against data sets within the PIMS; in the future either may be able to work against model data. This
capability is not available form the middleware messaging and the indirect
connect systems.
The PIMS also tells operators whether or not the process is in control through the SQC/SPC charts it displays. The
control limits could be supplied from the DRP layer and the violations could be passed back to the DRP layer,
although this is not currently supported in the software. At present, both control limits and violations are handled by
the PIMS, which makes this information available to operators and process engineers through the same visualization
tools mentioned above.
Enable advanced process control and process optimization. Control of manufacturing processes using conventional
single-loop controllers provides adequate control in most cases. However, achieving the highest level of
performance with the least product variability and at the least cost requires multivariable control and optimization
based on models. The computing power of the PIMS can provide the necessary platform for this advanced
technology.
--------------------------------------------------------------------------------
Server or Desktop?
Another critical issue is involved at the layer between the ERP and process control: should the functions described
above be performed at the server level or PIMS or at the desktop? While certain functions within the operation of a
manufacturing process belong to the desktop, there are other functions that are better done at the server level.
Simple visualization and ad hoc analysis belong at the desktop, amenable to the power of OLE, ODBC, and the
Microsoft Windows 95 and NT platforms. And although process data gathered and reconciled by the PIMS can be
manipulated by various desktop tools, it makes more sense to handle it within the PIMS server. That requires that
PIMS has some extra :smarts" built into it, that it become an Intelligent Process Data Server (IPDS).
Functions that should be performed by an IPDS at the server level are best identified by examining the problems
associated with doing them at the desktop.
Calculating and reconciling data from raw process data only should be performed once. Having multiple users do this
individually leads to different results for different people, even when they use the same computerational algorithms.
These errors can propagate into the enterprise decision process as well as SAP, with extremely bad results.
Different users may attack the same problem from different directions, arriving at different answers to the same
question.
Because users are working with raw data, there is much more traffic on the communication network. A large
number of users all working on the same data at the same time can bring a network to its knees.
Without an IPDS, a key link in the closed-loop information cycle that links SAP to the process control level is at risk.
Desktop technology is appropriate for certain tasks, but the actual two-way transfer of data between the ERP layer
and the process layer requires a secure, reliable, accurate, and intelligent interface mechanism.
--------------------------------------------------------------------------------
The Scope of the Problem
The architecture considerations presented here are, of course, only part of the job in determining what kind of
system to implement as the interface between the ERP and process control layers. In addition to supporting a PIMS
architecture that will protect and maintain the data, a vendor should be able to provide answers to other important
questions:
Does the vendor have active ongoing programs to develop a PP-PI interface to SAP?
does the vendor support third-party products that interface to PP-Pi, such as Hewlett Packard's Enterprise Link?
Does the vendor provide full support data access for desktop users via Microsoft ActiveX technology?
Does the vendor's PIMS product include an intelligent process data server that can provide enterprise solutions with
all the elements listed previously?
Does the vendor provide consulting and engineering support services? This is not an off-the-shelf application, and
enterprises that treats it as if it were do so at their peril.
Is the vendor certified (or seeking certification) by SAP?
With a good architectural approach and an experienced vendor, new ERP tools of the type offered by SAP can
redefine the manufacturing and chemical processing industries of the future. Such integrated systems soon may be
a requirement for remaining competitive in the 21st Century.
--------------------------------------------------------------------------------
- END -
| Disclaimer: This is Paul Allen's personal business library. Articles and papers contained therein are for his use and reference. While this information is being made public by being published on the internet, any use of any material or guidance contained herein is at one's own risk. Neither the author Paul Allen nor Project Executive Group have any responsibility if anything is taken from this website and utilized. While we believe these articles and papers make a significant contribution to learning, beware that anyone who uses this information does so at their own risk. We make no representations to accuracy or completeness. |
| Disclaimer: This is Paul Allen's personal business library. Articles and papers contained therein are for his use and reference. While this information is being made public by being published on the internet, any use of any material or guidance contained herein is at one's own risk. Neither the author Paul Allen nor Project Executive Group have any responsibility if anything is taken from this website and utilized. While we believe these articles and papers make a significant contribution to learning, beware that anyone who uses this information does so at their own risk. We make no representations to accuracy or completeness. |
| Return |
