SAP standard does not deliver processes

Due to the frequent presence of the word "process", a strong habituation effect has occurred. Hardly anyone still thinks about what this term means for software and its use. The following article focuses on business processes and their implementation or support in the SAP ERP standard.

Goods receipt process

One of the most prominent business processes in SAP ERP is the goods receipt process. This consists of the following steps: A purchase order is triggered and created as a document in SAP, the purchase order is sent to the vendor, the goods are delivered, recorded and a goods receipt document is created in SAP ERP.

This example shows all the essential characteristics of a business process: The process has a time course, a direction - a progress that can be measured. The process has a defined state at any point in time.

There are different processors: these can operate in series or in parallel. Each process carries a log and past process states must be recoverable if necessary. SAP documents can be included or created and physical documents (forms) are included (e.g. delivery bill, purchase order).

There are a large number of other similar business processes that are generally handled by SAP ERP. Examples include: invoice receipt, complaint receipt, the sales process (customer inquiry - quotation - order) and inventory.

As business processes, however, these processes only exist at the organizational level in SAP ERP. The SAP standard only provides the documents between which the processes run. In the case of goods receipt, for example, it is the purchase order document and the material document that are created during the process.

The handling of the process is left to the user alone. Deadlines, progress, status, involved agents, documents must be managed by the user.

There is no central location where the user can gain an overview of the running processes. Monitoring of processes is time-consuming, cumbersome and unreliable, as a large number of data sources (documents) have to be consulted for evaluation.

There are frequent media discontinuities in process handling: Communication takes place via e-mail, telephone or short message services. This communication remains undocumented. In retrospect, it is therefore difficult to reconstruct decisions. The SAP standard apparently leaves a gap of astonishing proportions here - intentionally or unintentionally.

Requirements process handling tool

If you want to create a software tool to support business process management, it is useful to abstract from specific use cases. This means, for example, considering the use cases "invoice receipt" and "goods receipt" and trying to isolate the common properties and requirements.

Business object process: It has proven useful to consider the process itself as a business object. This business object must have the properties 1-8 mentioned in the introduction.

Process runtime: Processes can be manually advanced, i.e. controlled by the user in a dialog transaction, but they can also progress automatically. In common business processes, both forms of "driving forward" frequently occur. It follows that a type of "process runtime" is required to drive the processes automatically.

Monitoring versus cockpit: It must be possible to monitor the status and progress of the process. For this purpose, a monitoring transaction is required that displays all key performance indicators and provides a view of the detailed process data.

If the monitoring transaction also allows controlling the process, i.e. driving the process and changing the process data, we speak of process cockpit. From the software point of view, monitor and cockpit can be the same transaction that is authorized differently.

Software Architecture

We assume a development in Abap OO, because there are decisive advantages from the Abap runtime, as we will see later.
Handler class: The basis of all application processes is an abstract process without application reference. This is implemented as a simple Abap-OO class (handler class) with a few properties:

• The class is not final
• The class provides its own persistence, i.e. reads from or writes to the database
• The class provides a locking mechanism so that only one modifier is allowed at a time
• The class writes its own protocol
• The class has a dedicated callback method, which is called for "dark" processing from the process runtime

All application-specific classes derive from this abstract process class. These extend the persistence of the base class by their application data by overwriting the persistence methods. There may also be functional extensions.

Runtime: The process runtime searches a registration table at execution time for the handler class that belongs to the particular process (e.g., handler class to the goods receipt process). The handler class is instantiated at execution time and its callback method is called by the runtime.

This concept of late binding is based on the principle of the Component Object Model (COM), which was established by Microsoft as early as 1992 and is still used today, for example, in the new Windows 10 Runtime (WinRT). Also here a DLL (COM object) is loaded only at run time over an object GUID, to which the file path of the DLL in the Windows Registry is deposited. The principle of the late binding can be converted in Abap by the concept of the global classes particularly simply.

From Abap's point of view, the runtime is nothing more than a program that collects all unfinished processes and serially calls their callback method. This program will run periodically in the background and can be scheduled multiple times if necessary to increase throughput. Collisions are resolved in a performant way by the built-in locking mechanism.

Monitoring/Cockpit: Monitoring provides the user with all the necessary information about the progress, number and status of the processes. The log of each individual process should be visible from the base monitor. In addition, the basic monitor should allow the restart and debugging of an individual process and in this respect already fulfills a few cockpit functions.

The monitoring is completely decoupled from runtime and handler class. It can be implemented in any UI technique (SAPGUI, WebDynpro, UI5, Windows). From the point of view of reusability, however, the SAPGUI is the UI technique of choice, since a strict MVC concept can be implemented most stringently with the SAPGUI.

All UI logic can be very easily offloaded to a reusable global or local controller class. In this respect, SAPGUI is more modern than any other UI technology.

Application cockpit: The content of the application cockpit is based on the monitor, but it also offers views of application data and provides application-specific functions. The UI is an extension of the basic monitor.

In SAPGUI (also in the WebDynpro case) the controller class can be derived from the controller class of the monitor. Thus, the cockpit "inherits" all functionality of the base monitor without additional effort. The implementation of a cockpit can thus be accomplished in a very short time.

Conclusion

It can be very worthwhile for companies to close the "process gap" in this way. The reasons are numerous: For example, the software adapts to the business process and not vice versa.

A central entry point is created from a process perspective, which often also corresponds to the departmental perspective. Process cycle times are shortened and measurable, errors are fully logged. Processes become transparent: Reporting can be implemented as a simple extension of monitoring.

The high degree of reuse of once existing software components optimizes project implementation times. The concept becomes future-proof by adapting to new UI technologies with minimal effort. Finally, it should be noted that this principle can of course also be applied to technical processes such as migrations or asynchronous, parallelized mass updates.