Gelebtes Prozessmanagement mit BPMN und der prozessgesteuerten Architektur

Die BizDev-Architektur

Matthias Heiler

© Shutterstock / zhu difeng

Wenn Business und IT sich zusammensetzen und die Möglichkeit bekommen, gemeinsam einen einheitlichen und ausführbaren Prozess zu entwickeln, dann kann man getrost von BizDev sprechen. Alles was dafür gebraucht wird, ist die Bereitschaft zur Kommunikation, die BPMN, eine Hand voll Tools und eine prozessgesteuerte Architektur. Der Artikel zeigt am Beispiel der SAP-internen Prozessentwicklung für die Language Services, wie es praktisch geht.

Die grafische Prozessmodellierungsnotation BPMN (Business Process Model and Notation) ist inzwischen weithin bekannt und damit auch die Chancen, die sich mit ihr ergeben. Fachabteilungen werden in die Lage versetzt, ihre Prozesse nicht nur in einem standardisierten, austauschbaren Format zu modellieren, sondern diese Modelle auch in einer spezialisierten BPMN-Engine zur Ausführung zu bringen. Die Nutzung des grafischen BPMN-Modells in einem aktuell ablaufenden Prozess hat darüber hinaus dazu beigetragen, dass die Anwender (fachlich und IT) nun während der Prozessausführung genau erkennen können, welchen Prozessschritt sie gerade im Kontext des ggf. über viele Systeme und Abteilungen verteilten Gesamtprozesses ausführen. Allein diese Aspekte haben zu einer erheblichen Verbesserung des Prozessdenkens und der Prozesstransparenz geführt. Wusste man früher nie so genau, um welchen Prozess es sich eigentlich gerade handelte, zu dem man aktuell durch eine Aktivität beitrug oder welche Prozessschritte die aktuelle Prozessinstanz schon durchlaufen hatte, so kann man nun anhand des Prozessmodells eindeutig die Prozessschritte vor und nach seiner aktuellen Tätigkeit nachverfolgen. Viele Kunden, bei denen SAP und ihre Partner BPM-Projekte durchgeführt haben, berichten, dass erst die Verwendung der BPMN und ihrer Ausführbarkeit zu einer intensiveren Auseinandersetzung und Diskussion über abteilungsübergreifende Prozesse und damit zu einer erheblichen Prozessverbesserung geführt habe. Doch nicht nur Kunden setzen auf BPMN. Auch SAP selbst nutzt BPMN in großem Stil, um ihre Geschäftsprozesse damit zu modellieren und auszuführen.

Vom Modell zum Prozess

Wie aber geht man nun konkret vor, um vom Modell in den ausführbaren Prozess zu kommen? Schließlich erfolgt eine solche Transformation nicht automatisch, sondern bedarf einer genauen Planung und Kenntnisse darüber, wie mögliche Stolpersteine vermieden werden können.

In letzter Zeit hat sich dazu eine Vorgehensweise etabliert, die unter dem Begriff „prozessgesteuerte Architektur“ bekannt ist und auf den Technologietagen der Deutschsprachigen SAP Anwendergruppe (DSAG) 2013 erstmalig präsentiert wurde (für weitere Informationen zur prozessgesteuerten Architektur sei auf das Buch von Volker Stiehl verwiesen: „Prozessgesteuerte Anwendungen entwickeln und ausführen mit BPMN“, dpunkt.verlag). Sie basiert auf BPMN und deren Ausführbarkeit auf speziellen BPMN-Umgebungen. Die Methodik sollte genutzt werden, wenn differenzierende Geschäftsprozesse zu implementieren sind. Dabei handelt es sich um Prozesse, die nicht in einer Standardlösung umgesetzt sein können, da sie das differenzierende Geschäft des jeweiligen Unternehmens adressieren. Gleichzeitig wurde bei der Methodik Wert auf eine prozessgesteuerte Architektur gelegt, die die richtige Balance zwischen Entwicklungs- und Wartungskosten, Skalierbarkeit und Fehlertoleranz findet und dennoch genügend Flexibilität für Anpassungen bietet, ohne selbst dabei zu komplex zu werden. Schließlich setzen sich Dinge dann besonders gut durch, wenn sie hinreichend einfach strukturiert sind. Mit einher geht bei diesem Ansatz ein neues Kollaborationsmodell („BizDevs“), das die gemeinsame Zusammenarbeit von Business („Biz“) und IT („Devs“) an den später auszuführenden BPMN-Modellen beschreibt. Die Fachabteilungen werden somit Teil des Entwicklungsprozesses, das ist eine Neuerung.

Das neue Kollaborationsmodell fußt auf der Zusammenarbeit an einem BPMN-Modell, das dann so wie es ist von der BPMN-Engine ausgeführt wird. Bisher wurden die Modelle, die vom Business kamen, mit IT-Artefakten „verunreinigt“, um sie ausführbar zu machen. Warum aber sollten die wertvollen Modelle des Business für die Ausführung aufgegeben werden? Warum sollte man überhaupt zwei Modelle erzeugen: erst eins für das Business und dann noch eins für die Ausführung? Und wer ist dann für die Synchronisation der Modelle verantwortlich, wenn sich auf der einen oder anderen Seite etwas ändert? Wenn Organisationen akzeptieren, dass Business und IT gleichermaßen für das BPMN-Modell verantwortlich sind, weil es während des Übergangs zur Ausführung beibehalten wird, funktioniert die Zusammenarbeit. Damit ist dann auch die Verantwortung für das ausgeführte Modell auf die Businessseite erweitert. Das ist Ebenfalls eine Neuerung.

Idee der Process-driven Architecture

Der wesentliche Gedanke der Process-driven Architecture (PDA) ist, die damit umgesetzte Anwendung so abstrakt wie möglich von einer konkreten Systemlandschaft zu halten, in der die Anwendung implementiert wird. Schließlich will man das Prozessmodell nicht jedes Mal anpassen, wenn eine Variation im unterliegenden System erfolgt. Dazu werden Funktionalitäten definiert und als Services angeboten, die das Business vorgibt, statt generischer Funktionen, die von der IT kommen und in denen immer weit mehr Daten eines Objekts gepflegt werden müssen, als für die eigentliche Funktion im konkreten Prozesskontext notwendig sind. Diese Services sind nicht für den Einsatz in unterschiedlichen Prozessen gedacht, sondern für Variationen desselben Prozesses, die durch Variationen und Änderungen in der unterliegenden Systemlandschaft verursacht werden. Das ist ein radikal anderer Ansatz in der Philosophie der Architektur.

Das Prozessdesign in einer PDA erfolgt so, dass das Prozessmodell alle Integrationsdetails vom Geschäftsprozessmodell fern hält, das die prozessgetriebene Applikation oder PDA repräsentiert. Im Service „Bestellung verbuchen“ in Abbildung 1 sind keine Annahmen über das System oder dessen aktuellen Schnittstellen enthalten, in dem die Bestellung tatsächlich erfolgt. Stattdessen definiert jeder Service im PDA-Prozess ein festes Service-Contract-Interface, das nur die Elemente spezifiziert, die für die erforderliche Geschäftsfunktion „Bestellung verbuchen“ notwendig ist, unabhängig von der Schnittstelle des Backend-Systems. Das Service-Contract-Interface ist somit im Wesentlichen von Geschäftsprozess- also vom Business- und nicht von der serviceorientierten Architektur (SOA) oder dem Integrationsentwickler definiert. Nur so ist gewährleistet, dass eine Änderung im darunterliegenden System nicht sofort auch eine Änderung im Geschäftsprozess erforderlich macht. Die Umsetzung des Service in die konkrete Systemlandschaft erfolgt im Service Contract Implemention Layer (SCIL).

Die Übersetzung dieses stabilen Service-Contract-Interface zu den sich immer wieder ändernden Interfaces und Daten des realen Backend-Systems liegt in der Verantwortung des SCIL. Der Charme daran ist, dass BPMN nun wiederum auch in diesem SCIL verwendet werden kann, sowohl in statusbehafteten BPM-Prozessen als auch in lose gekoppelte zustandslosen ESB-Prozessen, die geschickt kombiniert die SCIL repräsentieren. Dort findet die Datentransformation statt, werden Anfragen und Antworten von den unterliegenden Systemen orchestriert und technische Ausnahmen behandelt. Der PDA-Prozess ist davon komplett entlastet. Mehr noch: Der SCI-Prozess ist nicht invasiv, da keine Änderungen in den vorhandenen Backend-Systemen oder vorhandenen SOA-Services erforderlich sind. Alles Notwendige für die Umsetzung des PDA in die realen Systeme und Services wird im SCI-Prozess modelliert.

Der große Vorteil daran ist, dass im Gegensatz zum bisherigen Modellansatz der PDA-Prozess für das Business und den Integrationsentwickler der gleiche ist und der differenzierende Prozess, der oft der Diamant des Unternehmens ist, nicht mit technischen Details verunreinigt ist. Damit wird der ausführbare Prozess zum ersten Mal wirklich geschäftsgetrieben.

Zusammenfassend strebt der prozessgesteuerte Ansatz eine Stärkung des Geschäftsprozessmanagements an, um die differenzierenden Geschäftsprozesse zu einer wirkungsvollen neuen Waffe im Köcher eines jeden Unternehmens, unabhängig von dessen Branchenzugehörigkeit, werden zu lassen.

Abb. 1: Dreistufige prozessgesteuerte Architektur, Quelle SAP

Abb. 1: Dreistufige prozessgesteuerte Architektur, Quelle SAP

Umsetzung im Language Service

Im Folgenden wird dieser Ansatz anhand eines konkreten Projekts in den „Language Services“ bei der SAP vorgestellt. Der Ansatz dient als detaillierter Blueprint und für die Prinzipien, wie man solche prozessgetriebenen verteilten Applikationen plant und implementiert. Zunächst ein paar Fakten zu den SAP Language Services (SLS, Abb. 2):

  • SLS gehört zu Globalization Services
  • SLS hat weltweit Niederlassungen und bietet Sprachenservices für alle SAP-Produkte, SAP-Produkt-Services und die Konzernkommunikation in 39 Sprachen
  • SLS arbeitet mit externen Dienstleistern und 2 800 muttersprachlichen Übersetzern zusammen
  • Im Jahr 2014 wurden ca. 280 Millionen Wörter übersetzt
Abb. 2: End-2-End-Szenarien und -Prozesse bei SAP Language Service, Quelle SAP

Abb. 2: End-2-End-Szenarien und -Prozesse bei SAP Language Service, Quelle SAP

Die zu unterstützenden Langue Services sind je nach Übersetzungsszenario unterschiedlich. Mal sind es ABAP-Quellen, mal Java-Quellen, mal Marketingtexte, mal Texte für die interne Kommunikation, die übersetzt werden müssen. Die Szenarien sind wiederum in verschiedene Phase wie „Planung und Beratung“, „Aufbau Produktionsumgebung“ etc. untergliedert. Dabei hat jedes Übersetzungsszenario in den unterschiedlichen Phasen unterschiedliche Varianten eines Service/Arbeitsschritts. Nur durch eine hochgradige Automatisierung sind die Language Services so effizient, dass auch kurzfristige Textänderungen, die ein Entwickler in letzter Minute noch eingebaut hat, auch pünktlich mit der Auslieferung in alle Sprachen übersetzt sind. Insgesamt sind die Anforderungen vielfältig:

  • Über 65 zu automatisierende Prozessmodelle
  • Über 110 zu entwickelnde Fiori-UIs
  • Über 80 Verbindungen ins Haupt-Backend-System
  • Über 600 ABAP-Übersetzungssysteme integrieren
  • Über 50 Projektmitglieder
  • Ungefähr 8 Monate Projektzeit
  • Verwendung von SAP Process Orchestration, SAP Fiori, SAP HANA Enterprise Cloud, SAP HANA Cloud Plattform, SAP Operational Process Intelligence powered by SAP HANA
  • SAP Jam für die Zusammenarbeit im Projekt

Nach einer Ausschreibungsphase an Anbieter von Workflowsystemen für die Übersetzungsbranche ergab die Evaluationsphase, dass keiner der Anbieter die individuellen Anforderungen der SAP hinreichend abbilden konnte. Nach der Vorstellung der PDA und zwei Proof of Concepts hat man sich sehr schnell und mit Zustimmung aller Beteiligten, – den Anwendern und Übersetzungsdienstleistern – sowie unter Berücksichtigung der Vielfalt der Anwendungen für die Umsetzung nach der PDA-Methodik entschieden. Dabei lag die Projektlaufzeit mit 8 Monaten ca. 50 Prozent unter der mit anderen Methoden.

Die Projektorganisation sah Entwicklungen in ABAP, UI5, SAP BPM, eine Basisunterstützung, ein Integrationsmanagement sowie Support und Change Management vor. Die Entwicklung der Lösung selbst wurde mit agilen Methoden (Sprints) umgesetzt.

Projektstart war im Oktober 2014, wo zunächst 65 Prozessmodelle als BPMN-Modelle von BPM-Novizen erstellt wurden. Nach einer kurzen Schulung in der BPMN, insbesondere wie man unterschiedliche Semantiken darin modelliert, waren die Teams schnell in der Lage, ihre eigenen Modelle zu erstellen. Dabei haben die fachlichen Ansprechpartner ihre relevanten Prozesse, zunächst jeder für sich, dann paarweise und zuletzt in einer großen Runde aus rein fachlicher Sicht erstellt. Während zuvor die Prozesse von einer Person nur High Level beschrieben wurden, waren die Modelle jetzt sehr viel fokussierter, weil immer BPMN-Modell-basiert. Durch eine Gliederung in Phasen und Hierarchien (in Abb. 2 nicht abgebildet) konnten dann Teilprozesse definiert werden. So entstanden für die verschiedenen Übersetzungsszenarien insgesamt 65 Modelle untergliedert in die oben beschriebenen Phasen. Die von Bruce Silver beschriebene Vorgehensweise hat hierbei als Best-Practice-Ansatz sehr viel Nutzen gebracht, weil damit einheitliche Modelle entstanden (siehe: Silver, Bruce: „Method & Style A Structured Approach for Business Process Modeling and Implementation Using BPMN 2“). Diese waren gut lesbar, und durch die gute Strukturierung in Phasen und Hierarchien wurden keine riesigen Prozesstapeten produziert, wie man sie aus den in den 90er Jahren vielfachen bekannten Reengineering-Projekten noch gut kennt.

Nachdem die Teams der einzelnen Übersetzungsszenarien ihre Modelle unabhängig voneinander erstellt hatten, wurden die Modelle nun nochmals untereinander verglichen. Durch die intensive Zusammenarbeit wurde dabei oft festgestellt, dass Prozessbestandteile in unterschiedlichen Modellen nahezu gleich waren und sich nur in kleinen Varianten unterschieden. Dank der Modelle konnte man sich nun auf wenige Varianten einigen, was sehr gut mit der zentralen „Run Simple“-Strategie konform ging.

Realisierung der Prozesse

Die eigentliche Umsetzung der Prozessmodelle in ausführbare Prozesse wurde an Kollegen vom SAP-Partner Itelligence übertragen, die sich dank der Prozessmodelle erfreulich schnell in die für sie unbekannten Prozesse der SLS einarbeiten konnten. Wesentlich hierbei war, dass die Modelle entsprechend der PDA-Methodik eben nicht von technischen Artefakten überfrachtet waren und daher ein einfacher Know-how-Transfer über den fachlichen Prozess gewährleistet war.

Während bisher Fachanwender und IT getrennt agierten, die Prozesse getrennt modelliert, dann von der IT implementiert wurden und vor jedem Sprint lediglich diskutiert wurde, ob die Prozesse noch „passen“, hat sich das Bild heute geändert. Jetzt sitzen die Fachanwender mit den BPM-Spezialisten und UI-Entwicklern zusammen und diskutieren beispielsweise, welche Daten für den fachlichen Prozess erforderlich sind, und ob diese von den bereitgestellten Services aus der Servicevertragsimplementierungsschicht geliefert werden können. Diese Art der Entwicklung, in der Fachanwender und IT gemeinsam für die entstehenden Prozessmodelle verantwortlich sind, war für alle Projektbeteiligten neu und hat maßgeblich dazu beigetragen, dass Business und IT wesentlich effektiver kommunizieren und sich besser verstehen.

Die einzelnen Prozesse sahen neben automatisierten Prozessschritten – abgebildet als Web Services –  auch manuelle Prozessschritte vor. Dazu wurden durch die Fachanwender UI5-Mock-ups selbst entwickelt. Dazu bietet SAP mit den Fiori Guidlines und Axure eine Option, interaktive Prototypen zu erstellen, die auf unterschiedlichen Geräten getestet werden können. Durch die Möglichkeit, die Mock-ups mit Testdaten zu versehen, um das reale Verhalten in „Dry Runs“ zu simulieren. Somit sind schon in der Designphase Iterationszyklen mit realen Masken möglich (Abb. 3). Das war ein entscheidendes Merkmal, von den Anwendern von Anfang an Akzeptanz für „ihre“ Lösung zu bekommen. Lediglich bei komplexen UI-Anforderungen wurden UI-Spezialisten hinzugezogen.

Abb. 3: Vom Mock-up (oben) zur Realität (unten), Quelle SAP

Abb. 3: Vom Mock-up (oben) … (Quelle SAP)

Abb. 3: Vom Mock-up (oben) zur Realität (unten), Quelle SAP

Abb. 3: … zur Realität (unten), (Quelle SAP)

Da der in SAP BPM modellierte Geschäftsprozess für das Business und den Integrationsentwickler der gleiche ist, haben Anwender und IT zum ersten Mal ein gemeinsames Verständnis für den Prozess und sind auch gemeinsam für den entstehenden Prozess verantwortlich. Der Vorteil ergibt sich, weil der Prozess nicht mit technischen Details verunreinigt ist, dass diese im Service Contract Implementation Layer zu finden sind. Der ausführbare Prozess wurde somit zum ersten Mal wirklich geschäftsgetrieben (Abb. 4).

Abb. 4: Funktionaler und ausführbarer Prozess sind identisch, Quelle SAP

Abb. 4: Funktionaler und ausführbarer Prozess sind identisch, Quelle SAP

Testen unter Realbedingungen

Weitere Unterschiede zu bisherigen Projektabläufen haben sich auch in der Testphase ergeben. Früher wurden Testfälle von der IT und aus der Sicht der IT geschrieben. Das heißt, es wurde ein Testfall erstellt, der die implementierte Funktionalität oder UI-Verhalten testet. Was dabei völlig unterging war, ob der Testfall überhaupt dem in der Realität vorkommenden Prozessablauf entspricht. Vielleicht läuft der Prozess in Wahrheit völlig anders, und für diesen Ablauf gab es unter Umständen gar keinen Testfall. Jetzt war die Herangehensweise völlig anders. Man sagte einfach: Hier ist die Software, führe den Prozess so aus, wie du ihn in der Realität ausführen würdest und versuche ihn einfach und intuitiv zu bedienen. Dabei wurde dann schnell klar, was noch nicht hinreichend abgebildet ist, wo ein Feld oder eine Maske fehlt oder einfach ein Text helfen würde. Damit wurde in den Sprints ohne ausführliche Anleitung getestet. Es wurde lediglich anhand eines Überblicksdokuments beschrieben, welcher Testfall zu testen ist, z. B. ein (interner) Kunde will eine Übersetzung eines Marketingdokuments in Sprache x beauftragen. Resultat war ein wesentlich intensiverer Umgang mit den UIs, der so früher in den klassischen Testcases gar nicht abgebildet war. Daraus ließen sich auch viel zielgerichteter die Anforderungen an eine gute Endanwenderdokumentation ableiten.

Die beschriebene Vorgehensweise half allen Prozess- und Projektbeteiligten, den Mehrwert der Prozessautomatisierung für die SLS zu erkennen. Wurde früher von SAP ein Major-Release im Abstand von ca. 18 Monaten an Kunden ausgeliefert, sind insbesondere im Cloud-Umfeld nun deutlich kürzere Releasezyklen Realität. Damit sind die SLS-Services auch in deutlich höherer Schlagzahl zu leisten –  ohne Regelwerk und starke Automatisierung der zu liefernden Services wäre man dazu heute kaum in der Lage.

Entscheidungen automatisieren

Ein weiterer Bestandteil der BPM-Lösung ist das Business Rules Management (BRM). Regeln in Prozessen sind in Gateways wichtig, weil damit Entscheidungen (automatisiert) getroffen werden können. Ist die Frage, ob sich bei der Übersetzung von interner Kommunikation und den damit verbundenen Quellsystemen eine maschinelle Übersetzung für Japanisch eignet. Wenn eher nicht, kann man den Schritt „Maschinelle Übersetzung“ auslassen und mit dem Folgeschritt fortfahren. Oder sind für die Übersetzung von Marketingtexten in Sprache X ein oder zwei Reviews vorgesehen? Oder welche Übersetzungsagentur sollte beauftragt werden? Dafür wurden Regeln von den Fachanwendern aufgestellt. Dieses Regelwerk war bisher nur implizit in den Köpfen der Anwender vorhanden, jetzt wird es explizit, transparent und Teil des Prozessmodells.

Während man früher nicht wusste, welches Übersetzungsbüro bei welchen Anforderungen besonders gute Qualität oder Übersetzungen in Price und Budget liefert, kann die in BPM integrierte Business Analytics hier jetzt mehr Einblicke liefern.

In der weiteren Planung ist den Prozessmanagern eine Prozessvisibilität der operativen Prozessinstanzen in einem Dashboard zu bieten. Damit lässt sich in den vielen parallel laufenden Prozessinstanzen sehr schnell erkennen, wie der Status der Übersetzungsprozesse im Allgemeinen oder in einer konkreten Instanz ist und in welcher Phase sich eine Instanz gerade befindet. Die Dashboards sind KPI-getrieben und zeigen, welche Instanz(en) ihre KPI’s bereits verletzt hat oder diese höchstwahrscheinlich verletzen wird. Damit ist die Möglichkeit gegeben, ad hoc Aufgaben für Kollegen zu definieren oder Vorschläge zu unterbreiten, welche nächstbesten Schritte unternommen werden sollten, um ein Problem zu lösen. Hierbei kommt ein weiterer Mehrwert der BPM-Modelle zum Tragen, da diese in der Prozessvisibilitätslösung SAP Operational Process Intelligence direkt wiederverwendet werden können. Das heißt, es müssen lediglich aus den BPMN-Prozessmodellen die relevanten Milestones, die es zu überwachen gilt, definiert und mit KPI hinterlegt werden. Den Rest macht die Lösung, da SAP BPM Event-enabled ist und sich die Laufzeit daher direkt der relevanten Events im Prozess bedient und daraus den Wert der KPI’s ermittelt.

Abb. 5: Vorteile von BPMN und der PDA, Quelle SAP

Abb. 5: Vorteile von BPMN und der PDA, Quelle SAP

War die Wahrnehmung der Stakeholder über die SAP Language Services und Prozesse vor dem BPM-Projekt noch heterogen, hat sich durch die PDA-Methodik und Architektur ein neues Kollaborationsmodell in Form der BizDevs etabliert, womit die Fachabteilungen zum Teil des Entwicklungsprozesses wurden und BPMN sich als gemeinsame, weil einfach zu verstehende Modellierungssprache schnell durchgesetzt hat (Abb. 5).

Zusammenfassung

  • Das Konzept der Entwicklung und Ausführung prozessgesteuerter Anwendungen mit BPMN ist bei SAP Language Services im Rahmen eines komplexen Großprojekts erfolgreich umgesetzt worden.
  • Dabei ist hervorzuheben, dass Prozessdokumentation und gelebte Prozesse völlig übereinstimmen, das funktionale Modell mit dem ausgeführten Modell identisch ist, und auch dynamische, differenzierende Prozesse automatisiert werden können.
  • Durch die frühe und intensive Einbeziehung der Anwender ist deren Akzeptanz der Lösung nahezu vollständig. Die über BPMN vereinheitlichte Kommunikation zwischen IT und Business ist hoch effizient, da diese das Risiko von Missverständnissen nahezu eliminiert. Dadurch wird insgesamt die Geschwindigkeit des Lebenszyklus vom Konzept zur Implementierung erhöht.
  • SLS hat mit dem Projekt einen großen Schritt Richtung „Gelebtes Prozessmanagement“ gemacht.

Aufmacherbild: spiral staircase in modern building via Shutterstock / Urheberrecht: zhu difeng

Geschrieben von
Matthias Heiler
Matthias Heiler
Matthias Heiler ist Physiker und arbeitet als Solution-Architekt im Bereich HANA-Plattform bei der SAP SE in Walldorf. Nach dem naturwissenschaftlichen Studium war er als Anwendungsentwickler bei einem Unternehmen aus der Luftfahrt tätig und später Projektmanager in internationalen Projekten im Bereich Banking/Automotive bei einem amerikanischen Beratungsunternehmen. Seit 1995 ist er bei SAP, zunächst als Referent im Bereich SAP Basis (R/2 und R/3) und seit 1999 im Vertrieb tätig. Er ist zertifizierter SAP ERP Integration Consultant. Seine heutigen Arbeitsschwerpunkte liegen im Bereich Datenbank und Technologie, mit besonderem Fokus auf Integrationsplattformen und Business Process Management. Darüber hinaus unterrichtet er seit 1999 betriebswirtschaftliche Prozesse mit SAP-Systemen zunächst an der International University Bruchsal, derzeit an der SRH Heidelberg und anderen Einrichtungen im In- und Ausland.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: