SAP R/3 functionality is structured using its own proprietary language called ABAP (Advanced Business Application Programming). ABAP, or ABAP/4 is a fourth generation language(4GL), geared towards the creation of simple, yet powerful programs. R/3 also offers a complete development environment where developers can either modify existing SAP code to modify existing functionality or develop their own functions, whether reports or complete transactional systems within the SAP framework.
ABAP's main interaction with the database system is via Open SQL statements. These statements allow a developer to query, update, or delete information from the database. Advanced topics include GUI development and advanced integration with other systems. With the introduction of ABAP Objects, ABAP provides the opportunity to develop applications with object-oriented programming.
The most difficult part of SAP R/3 is its implementation, since SAP R/3 is never used the same way in any two places. For instance, Atlas Copco can have a different implementation of SAP R/3 from Procter & Gamble. Some companies may run multiple productive clients/systems or even multiple instances of SAP R/3. This is seen, for example, when a company running SAP acquires a new business already running SAP. They may elect to keep both systems separate, migrate one into the other, or migrate both onto a completely new instance.
The system landscape is ultimately the customer's decision. There are definite pros and cons on the continuum from single global instance / productive client (master data, impact of configuration changes on multiple business units) to separate instances per business unit (hardware costs and communication between instances/clients)
Two primary issues are the root of the complexity and of the differences:
- Customization configuration - Within R/3, there are tens of thousands of database tables that may be used to control how the application behaves. For instance, each company will have its own accounting "Chart of Accounts" which reflects how its transactions flow together to represent its activity. That will be specific to a given company. In general, the behavior (and appearance) of virtually every screen and transaction is controlled by configuration tables. This gives the implementor great power to make the application behave differently for different environments. With that power comes considerable complexity.
- Extensions, Bolt-Ons - In any company, there will be a need to develop interface programs to communicate with other corporate information systems. This generally involves developing ABAP/4 code, and considerable "systems integration" effort to either determine what data is to be drawn out of R/3 or to interface into R/3 to load data into the system.
Due to the complexity of implementation, these companies recruit highly skilled SAP consultants to do the job. The implementation must consider the company's needs and resources. Some companies implement only a few modules of SAP while others may want numerous modules.
SAP has several layers. The Basis System (BC) includes the ABAP programming language, and is the heart (i.e. the base) of operations and should not be visible to higher level or managerial users. Other customizing and implementation tools exist also. The heart of the system (from a manager's viewpoint) are the application modules. These modules may not all be implemented in a typical company but they are all related and are listed below:
EH&S Environmental Health & Safety
Designed for the management of environmental regulatory information, particularly product safety data as required for Material Safety Data Sheets. EH&S has sub-modules of Product Safety, Dangerous Goods, Waste, Industrial Hygiene, and Occupational Health. These modules can be populated with regulatory information from commercially available databases, such as the LOLI Database.
Posts
No comments:
Post a Comment