{"id":26613,"date":"2016-06-01T01:02:04","date_gmt":"2016-05-31T23:02:04","guid":{"rendered":"http:\/\/e3mag.com\/?p=26613"},"modified":"2022-05-01T08:51:22","modified_gmt":"2022-05-01T06:51:22","slug":"sap-standard-liefert-keine-prozesse","status":"publish","type":"post","link":"https:\/\/e3mag.com\/de\/sap-standard-liefert-keine-prozesse\/","title":{"rendered":"SAP-Standard liefert keine Prozesse"},"content":{"rendered":"

Durch die h\u00e4ufige Pr\u00e4senz des Wortes \u201eProzess\u201c ist ein starker Gew\u00f6hnungseffekt eingetreten. Kaum jemand macht sich noch Gedanken dar\u00fcber, was dieser Begriff f\u00fcr Software und ihre Verwendung bedeutet. Der folgende Beitrag konzentriert sich auf Gesch\u00e4ftsprozesse und deren Umsetzung bzw. Unterst\u00fctzung im SAP-ERP-Standard.<\/p>\n

Wareneingangsprozess<\/h3>\n

Einer der prominentesten Gesch\u00e4ftsprozesse im SAP ERP ist der Wareneingangsprozess. Dieser besteht aus den folgenden Schritten: Eine Bestellung wird ausgel\u00f6st 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.<\/p>

\"Fullsize\"<\/a><\/div><\/div>\n

Dieses Beispiel zeigt alle wesentlichen Eigenschaften eines Gesch\u00e4ftsprozesses: Der Prozess hat einen zeitlichen Verlauf, eine Richtung \u2013 einen Fortschritt, der messbar ist. Der Prozess hat zu jedem Zeitpunkt einen definierten Zustand.<\/p>\n

Es gibt verschiedene Bearbeiter: diese k\u00f6nnen seriell oder parallel t\u00e4tig sein. Jeder Prozess f\u00fchrt ein Protokoll mit sich und vergangene Prozesszust\u00e4nde m\u00fcssen ggf. wiederherstellbar sein. Dabei k\u00f6nnen SAP-Belege einbezogen werden oder erstellt werden und physische Dokumente (Formulare) werden einbezogen (z. B. Lieferschein, Bestellung).<\/p>\n

\"Thomas<\/a>Es gibt eine gro\u00dfe Zahl von weiteren, \u00e4hnlichen Gesch\u00e4ftsprozessen, die im Allgemeinen \u00fcber das SAP ERP abgewickelt werden. Als Beispiele seien genannt: der Rechnungseingang, der Reklamationseingang, der Vertriebs\u00adprozess (Kundenanfrage \u2013 Angebot \u2013 Auftrag) und die Inventarisierung.<\/p>\n

Als Gesch\u00e4ftsprozesse 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.<\/p>\n

Die Abwicklung des Prozesses ist dabei allein dem Benutzer \u00fcberlassen. Termine, Fortschritt, Zustand, involvierte Bearbeiter, Dokumente m\u00fcssen vom Benutzer verwaltet werden.<\/p>\n

Es gibt keine zentrale Stelle, an der der Benutzer eine \u00dcbersicht der laufenden Prozesse gewinnen kann. Monitoring der Prozesse ist zeitaufw\u00e4ndig, umst\u00e4ndlich und unzuverl\u00e4ssig, da eine Vielzahl von Datenquellen (Belegen) zur Auswertung herangezogen werden m\u00fcssen.<\/p>\n

Bei der Prozessabwicklung kommt es zu h\u00e4ufigen Medienbr\u00fcchen: Es wird \u00fcber E-Mail, Telefon oder Kurznachrichtendienste kommuniziert. Diese Kommunikation bleibt dabei undokumentiert. Im Nachhinein ist es daher schwer, Entscheidungen nachzuvollziehen. Der SAP-Standard l\u00e4sst hier offenbar \u2013 absichtlich oder unabsichtlich \u2013 eine L\u00fccke erstaunlichen Ausma\u00dfes.<\/p>\n

Anforderungen Prozessabwicklungswerkzeug<\/h3>\n

Will man ein Softwarewerkzeug schaffen, um die Gesch\u00e4ftsprozessabwicklung zu unterst\u00fctzen, so ist es zielf\u00fchrend von speziellen Anwendungsf\u00e4llen zu abstrahieren. D. h. man betrachtet z. B. die Anwendungsf\u00e4lle \u201eRechnungseingang\u201c und \u201eWareneingang\u201c und versucht die gemeinsamen Eigenschaften und Anforderungen zu isolieren.<\/p>\n

Businessobjekt-Prozess: Es hat sich als sinnvoll erwiesen, den Prozess selbst als Businessobjekt zu betrachten. Dieses Businessobjekt muss die Eigenschaften 1\u20138 besitzen, die in der Einleitung genannt wurden.<\/p>\n

Prozesslaufzeit: Prozesse k\u00f6nnen manuell vorangetrieben werden, d. h. vom Benutzer in einer Dialogtransaktion gesteuert, sie k\u00f6nnen aber auch automatisch fortschreiten. Bei den g\u00e4ngigen Gesch\u00e4ftsprozessen kommen h\u00e4ufig beide Formen des \u201eVorantreibens\u201c vor. Daraus folgt, dass zum automatischen Antreiben der Prozesse eine Art \u201eProzesslaufzeit\u201c ben\u00f6tigt wird.<\/p>\n

Monitoring versus Cockpit: Prozess\u00adzustand und -fortschritt m\u00fcssen \u00fcberwachbar sein. Dazu wird eine Monitoringtransaktion ben\u00f6tigt, die alle wesentlichen Kennzahlen ausweist sowie eine Sicht auf die Detaildaten des Prozesses bereitstellt.<\/p>\n

Erlaubt die Monitoringtransaktion au\u00dferdem die Steuerung des Prozesses, d. h. das Vorantreiben des Prozesses und das \u00c4ndern der Prozessdaten, so sprechen wir von Prozesscockpit. Aus Softwaresicht kann Monitor und Cockpit dieselbe Transaktion sein, die unterschiedlich berechtigt wird.<\/p>\n

Softwarearchitektur<\/h3>\n

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