SAP-Standard liefert keine Prozesse

Durch die häufige Präsenz des Wortes „Prozess“ ist ein starker Gewöhnungseffekt eingetreten. Kaum jemand macht sich noch Gedanken darüber, was dieser Begriff für Software und ihre Verwendung bedeutet. Der folgende Beitrag konzentriert sich auf Geschäftsprozesse und deren Umsetzung bzw. Unterstützung im SAP-ERP-Standard.

Wareneingangsprozess

Einer der prominentesten Geschäftsprozesse im SAP ERP ist der Wareneingangsprozess. Dieser besteht aus den folgenden Schritten: Eine Bestellung wird ausgelöst und als Beleg im SAP angelegt, die Bestellung wird an den Lieferanten versendet, die Ware wird geliefert, erfasst und ein Wareneingangsbeleg wird im SAP ERP angelegt.

Dieses Beispiel zeigt alle wesentlichen Eigenschaften eines Geschäftsprozesses: Der Prozess hat einen zeitlichen Verlauf, eine Richtung – einen Fortschritt, der messbar ist. Der Prozess hat zu jedem Zeitpunkt einen definierten Zustand.

Es gibt verschiedene Bearbeiter: diese können seriell oder parallel tätig sein. Jeder Prozess führt ein Protokoll mit sich und vergangene Prozesszustände müssen ggf. wiederherstellbar sein. Dabei können SAP-Belege einbezogen werden oder erstellt werden und physische Dokumente (Formulare) werden einbezogen (z. B. Lieferschein, Bestellung).

Es gibt eine große Zahl von weiteren, ähnlichen Geschäftsprozessen, die im Allgemeinen über das SAP ERP abgewickelt werden. Als Beispiele seien genannt: der Rechnungseingang, der Reklamationseingang, der Vertriebs­prozess (Kundenanfrage – Angebot – Auftrag) und die Inventarisierung.

Als Geschäftsprozesse sind diese Prozesse jedoch nur auf organisatorischer Ebene im SAP ERP vorhanden. Der SAP-Standard liefert lediglich die Belege, zwischen denen die Prozesse ablaufen. Beim Wareneingang sind es z. B. der Bestellbeleg und der Materialbeleg, die im Laufe des Prozesses erstellt werden.

Die Abwicklung des Prozesses ist dabei allein dem Benutzer überlassen. Termine, Fortschritt, Zustand, involvierte Bearbeiter, Dokumente müssen vom Benutzer verwaltet werden.

Es gibt keine zentrale Stelle, an der der Benutzer eine Übersicht der laufenden Prozesse gewinnen kann. Monitoring der Prozesse ist zeitaufwändig, umständlich und unzuverlässig, da eine Vielzahl von Datenquellen (Belegen) zur Auswertung herangezogen werden müssen.

Bei der Prozessabwicklung kommt es zu häufigen Medienbrüchen: Es wird über E-Mail, Telefon oder Kurznachrichtendienste kommuniziert. Diese Kommunikation bleibt dabei undokumentiert. Im Nachhinein ist es daher schwer, Entscheidungen nachzuvollziehen. Der SAP-Standard lässt hier offenbar – absichtlich oder unabsichtlich – eine Lücke erstaunlichen Ausmaßes.

Anforderungen Prozessabwicklungswerkzeug

Will man ein Softwarewerkzeug schaffen, um die Geschäftsprozessabwicklung zu unterstützen, so ist es zielführend von speziellen Anwendungsfällen zu abstrahieren. D. h. man betrachtet z. B. die Anwendungsfälle „Rechnungseingang“ und „Wareneingang“ und versucht die gemeinsamen Eigenschaften und Anforderungen zu isolieren.

Businessobjekt-Prozess: Es hat sich als sinnvoll erwiesen, den Prozess selbst als Businessobjekt zu betrachten. Dieses Businessobjekt muss die Eigenschaften 1–8 besitzen, die in der Einleitung genannt wurden.

Prozesslaufzeit: Prozesse können manuell vorangetrieben werden, d. h. vom Benutzer in einer Dialogtransaktion gesteuert, sie können aber auch automatisch fortschreiten. Bei den gängigen Geschäftsprozessen kommen häufig beide Formen des „Vorantreibens“ vor. Daraus folgt, dass zum automatischen Antreiben der Prozesse eine Art „Prozesslaufzeit“ benötigt wird.

Monitoring versus Cockpit: Prozess­zustand und -fortschritt müssen überwachbar sein. Dazu wird eine Monitoringtransaktion benötigt, die alle wesentlichen Kennzahlen ausweist sowie eine Sicht auf die Detaildaten des Prozesses bereitstellt.

Erlaubt die Monitoringtransaktion außerdem die Steuerung des Prozesses, d. h. das Vorantreiben des Prozesses und das Ändern der Prozessdaten, so sprechen wir von Prozesscockpit. Aus Softwaresicht kann Monitor und Cockpit dieselbe Transaktion sein, die unterschiedlich berechtigt wird.

Softwarearchitektur

Wir gehen aus von einer Entwicklung in Abap OO, da sich aus der Abap-Laufzeit entscheidende Vorteile ergeben, wie wir später sehen werden.
Handlerklasse: Grundlage aller Anwendungsprozesse ist ein abstrakter Prozess ohne Anwendungsbezug. Dieser wird als einfache Abap-OO Klasse (Handlerklasse) implementiert mit einigen, wenigen Eigenschaften:

• Die Klasse ist nicht final
• Die Klasse liefert ihre eigene Persistenz, d. h. liest sich von bzw. schreibt sich in die Datenbank
• Die Klasse liefert einen Sperrmechanismus, sodass immer nur ein Änderer zugelassen wird
• Die Klasse schreibt ihr eigenes Protokoll
• Die Klasse hat eine dezidierte Callback-Methode, die für „dunkle“ Abarbeitung von der Prozesslaufzeit aufgerufen wird

Von dieser abstrakten Prozessklasse leiten alle anwendungsspezifischen Klassen ab. Diese erweitern die Persistenz der Basisklasse um ihre Anwendungsdaten durch Überschreiben der Persistenzmethoden. Evtl. gibt es auch funktionale Erweiterungen.

Laufzeit: Die Prozesslaufzeit sucht zur Ausführungszeit in einer Registrierungstabelle nach der Handlerklasse, die zum jeweiligen Prozess gehört (z. B. Handlerklasse zum Wareneingangsprozess). Die Handlerklasse wird zur Ausführungszeit instanziiert und ihre Callback-Methode wird von der Laufzeit aufgerufen.

Dieses Konzept der späten Bindung lehnt sich an das Prinzip des Component Object Models (COM) an, das von Microsoft bereits 1992 etabliert wurde und bis heute z. B. in der neuen Windows 10 Runtime (WinRT) zum Einsatz kommt. Auch hier wird eine DLL (COM-Objekt) erst zur Laufzeit geladen über eine Objekt-GUID, zu der der Dateipfad der DLL in der Windows Registry hinterlegt ist. Das Prinzip der späten Bindung lässt sich in Abap durch das Konzept der globalen Klassen besonders einfach umsetzen.

Aus Abap-Sicht ist die Laufzeit nichts anderes als ein Programm, das alle nicht beendeten Prozesse sammelt und seriell deren Callback-Methode aufruft. Dieses Programm wird periodisch im Hintergrund laufen und kann ggf. auch mehrfach eingeplant werden, um den Durchsatz zu erhöhen. Kollisionen werden performant durch den eingebauten Sperrmechanismus aufgelöst.

Monitoring/Cockpit: Das Monitoring liefert dem Anwender alle nötigen Informationen über Fortschritt, Anzahl und Zustand der Prozesse. Vom Basismonitor aus sollte das Protokoll jedes einzelnen Prozesses einsehbar sein. Außerdem sollte der Basismonitor den Neustart und das Debuggen eines einzelnen Prozesses erlauben und erfüllt insofern bereits einige wenige Cockpit-Funktionen.

Das Monitoring ist vollständig von Laufzeit und Handlerklasse entkoppelt. Es kann in jeder beliebigen UI-Technik implementiert werden (SAPGUI, WebDynpro, UI5, Windows). Vom Standpunkt der Wiederverwendbarkeit ist allerdings der SAPGUI die UI-Technik der Wahl, da sich ein striktes MVC-Konzept mit dem SAPGUI am stringentesten umsetzen lässt.

Sämtliche UI-Logik lässt sich sehr einfach in eine wiederverwendbare, globale oder lokale Controller-Klasse auslagern. In dieser Hinsicht ist der SAPGUI moderner als alle anderen UI-Technologien.

Anwendungscockpit: Das Anwendungscockpit lehnt sich inhaltlich an den Monitor an, bietet darüber hinaus aber Sichten auf Anwendungsdaten und stellt auch anwendungsspezifische Funktionen bereit. Das UI stellt eine Erweiterung des Basismonitors dar.

Im SAPGUI (auch im WebDynpro-Fall) lässt sich die Controller-Klasse von der Controller-Klasse des Monitors ableiten. Dadurch „erbt“ das Cockpit alle Funktionalität des Basismonitors ohne Zusatzaufwand. Die Umsetzung eines Cockpits lässt sich so in sehr kurzer Zeit bewerkstelligen.

Conclusion

Für Unternehmen kann es sehr lohnenswert sein, die „Prozesslücke“ auf diese Weise zu schließen. Die Gründe sind zahlreich: Beispielsweise passt die Software sich dem Geschäftsprozess an und nicht umgekehrt.

Es wird ein zentraler Einstiegspunkt geschaffen aus Prozesssicht, was häufig auch der Abteilungssicht entspricht. Die Prozessdurchlaufzeiten werden verkürzt und messbar, Fehler werden vollständig protokolliert. Prozesse werden transparent: Reporting lässt sich dabei als einfache Erweiterung des Monitorings umsetzen.

Durch den hohen Grad an Wiederverwendung einmal vorhandener Softwarekomponenten werden die Projektumsetzungszeiten optimiert. Das Konzept wird zukunftssicher, indem es sich mit minimalem Aufwand an neue UI-Technologien anpasst. Zum Schluss sei darauf hingewiesen, dass sich dieses Prinzip natürlich auch auf technische Prozesse wie Migrationen oder asynchrone, parallelisierte Massenverbuchungen anwenden lässt.