Projektleitung & -steuerung, Prozessberatung, Architektur- & Infrastruktur-Beratung, Technologieberatung

Meine Aufgabe in diesem Projekt war die Implementierung des CCSDS (Consultative Committee for Space Data Systems) File Delivery Protocols in der Programmiersprache C. Dieses kurz als CFDP bezeichnete Protokoll soll als kommender Standard in der Raumfahrtindustrie genutzt werden, allerdings war zum Zeitpunkt des Projekts noch keine eigene Implementierung bei Airbus Defence and Space vorhanden. Aus diesem Grund wurde ich mit der Aufgabe betraut, eine prototypische Implementierung vorzunehmen, diese gegen eine Referenzimplementierung zu testen und ein grafisches User Interface (GUI) bereitzustellen, um die Funktionsweise des Protokolls demonstrieren. Die Spezifikation des Protokolls legt genau fest, wie der Datenaustausch erfolgen muss und wie die einzelnen Datenpakete strukturiert sind. Da das Protokoll unter anderem in Satelliten zum Einsatz kommen sollte, war es besonders wichtig, dass ich auf eine ressourceneffiziente Implementierung und sehr hohe Qualitätsstandards achte. Neben der reinen Implementierung war auch die Dokumentation der Ergebnisse ein wichtiger Bestandteil meiner Tätigkeit im Projekt. Um die im Standard beschrieben Abläufe besser darzustellen, habe ich diese mit Hilfe von UML-Modellen visualisiert. Darüber hinaus war das Testen meiner Implementierung eine meiner Aufgaben. Hierfür habe ich ein Framework implementiert, mit dessen Hilfe es möglich ist, zwei CFDP-Implementierung gegeneinander zu testen. Das Framework ermöglicht es, mit Hilfe einer Beschreibungssprache die Kommunikation zu initiieren, das erwartete Ergebnis zu definieren und nach Abschluss der Kommunikation zu überprüfen. Ein weiterer Bestandteil des Projekts war die Implementierung der grafischen Oberfläche, um den Datenaustausch per CFDP zu visualisieren. Da diese Software nicht in Satelliten eingesetzt werden sollte, konnte ich hierfür auf C++ als Programmiersprache zurückgreifen. Zusammengefasst waren die Ergebnisse des Projekts eine auf Qt basierende grafische Oberfläche, die einzelne Datenpakete einer Übertragung visualisiert, sowie ein vorhandener Prototyp des CFDP, der als Grundlage für die weitere Implementierung verwendet wurde.

Mein Ziel in diesem Projekt war es, eine Auswahl von nicht relationalen Datenbanksystemen (NoSQL, Not only SQL) im Hinblick auf ihre Einsetzbarkeit für die Archivierung von Dokumenten zu untersuchen. Auf den Ergebnissen dieser Evaluierung aufbauend habe ich dann eine Empfehlung ausgesprochen, ob ein bereits seit 14 Jahren eingesetztes Dokument-Archivsystem umgestaltet werden kann oder nicht. Die Notwendigkeit dieser Untersuchung begründet sich in den Performance-Problemen, welche beim Altsystem im Laufe der Jahre bemerkt wurden. Meine Aufgabe war die Untersuchung des aktuell eingesetzten Systems, die Auswahl der zu untersuchenden nicht relationalen Datenbanksysteme, die Erarbeitung eines Konzepts für den Einsatz des jeweiligen Datenbanksystems und anschließend die Implementierung eines Prototyps. Als nicht relationale Datenbanksysteme habe ich mich zum einen für MongoDB und zum anderen für Apache Cassandra entschieden. Die Erarbeitung des Konzepts umfasste jeweils die Untersuchung der Vor- und Nachteile der Systeme, sowie darauf aufbauend die Übertragung des aktuell existierenden relationalen Datenmodells in ein für das System geeignetes Datenmodell. Außerdem gehörte die Installation der ausgewählten Systeme zu meinen Aufgaben. Da für das momentan eingesetzte Archivsystem ein Wildfly Application Server als Anwendungsserver zwischen Client und Datenbank eingesetzt wird, sollte der Prototyp ebenfalls auf diesem basieren. Aus diesem Grund habe ich eine Vielzahl von J2EE Technologien wie beispielsweise JTA (Java Transaction API) und EJB (Enterprise Java Beans) eingesetzt, um eine Anbindung an die nicht relationalen Datenbanksysteme zu ermöglichen. Abschließend habe ich außerdem noch Performance-Tests durchgeführt, um einen Vergleich zwischen dem aktuell genutzten und dem neuen System zu ermöglichen. Auf Basis der Ergebnisse dieser Tests habe ich dann für das Unternehmen eine Handlungsempfehlung ausgesprochen, mit deren Hilfe über das weitere Vorgehen entschieden werden konnte.

In diesem Projekt ging es um die Portierung eines OSEK-Betriebssystems (Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug) von einer Roboter-Generation auf ihren Nachfolger. Dies war notwendig, da die bisher genutzte Plattform bereits seit einigen Jahren veraltet ist, das Betriebssystem bisher aber noch nicht an die neue Plattform angepasst wurde. OSEK ist seit vielen Jahren der am weitesten verbreitende Standard im KFZ, der von allen Automobilherstellern für die Entwicklung von echtzeitfähiger, ressourceneffizienter Software für Motorsteuergeräte verwendet wird. Meine Aufgabe war neben dem Mitwirken an der Portierung auch die Leitung des Projekts. Das Projektteam zur Umsetzung der Aufgabe bestand dabei aus acht Leuten. Meine Aufgaben als Projektleiter umfassten neben der Erstellung und Verteilung von Arbeitspaketen auch die Erstellung eines Projektplans, sowie dessen Überwachung. Ferner war auch die Abstimmung mit dem Auftraggeber des Projekts und die Organisation der Projektkommunikation ein wichtiger Bestandteil meiner Arbeit. Im Rahmen der Portierung habe ich den gesamten Betriebssystem-Kern an die neue Hardware angepasst. Hierfür war es erforderlich, dass ich mich in ARM-Assembler einarbeite und daraufhin Anpassungen am zu portierenden Quellcode vornehmen konnte. Außerdem wurden die Treiber für das Auslesen der Sensoren und die Ansteuerung der Motoren auf für die neue Plattform implementiert. Um dies zu realisieren, habe ich mich zunächst in die zu Grunde liegenden Kommunikationsprotokolle und -mechanismen (I2C - Inter Integrated Circuit, SPI - Serial Periphal Interface, PWM - Pulse Width Modulation) eingearbeitet. Anschließend konnte die Implementierung der Treiber in der Programmiersprache C erfolgen. Die Ergebnisse des Projekts umfassten neben der Portierung des Betriebssystems und der Treiber auch eine umfangreiche Dokumentation, auf deren Basis eine Weiterentwicklung angestrebt wird.

Aufgabe dieses Projekts war die Implementierung einer Android App, welche in der Lage sein soll, die GPS-Positionsdaten von zwei Endgeräten ohne die Beteiligung eines Servers auszutauschen. Damit soll es den Nutzern ermöglicht werden, den Aufenthaltsort von Freunden in der Nähe genau zu bestimmen. Gleichzeitig soll die Privatsphäre der Anwender geschützt werden. Der Austausch erfolgt direkt über RESTful Web Services. Empfangene Positionsdaten werden auf einer in der App integrierten Karte markiert. Als Programmiersprache habe ich in diesem Projekt Groovy und Java eingesetzt. Bei der Entwicklung selbst wurde auf das agile Vorgehensmodell Scrum gesetzt, um unser Projektteam von 4 Personen zu organisieren. Besonders herausfordernd war für mich die Bereitstellung der benötigten Web Services auf einem Android-Smartphone. Dieses Betriebssystem ist grundlegend nicht darauf ausgelegt, Web Services für eingehende Verbindungen bereitzustellen. Aus diesem Grund habe ich eine Version des Jetty Webservers für Android angepasst und verwendet. Die App wurde im weiteren Projektverlauf um weitere Funktionalität ergänzt. Dazu zählt beispielsweise eine Freundesliste, sowie die Möglichkeit, bestimmte Einträge auf der Karte ein- oder auszublenden. Das Ergebnis des Projekts ist eine funktionierende App, die es dem Nutzer ermöglicht, die Position von Freunden in seiner Nähe genau zu bestimmen und dabei keinen Server für den Datenaustausch benötigt.

In den Workshops habe ich gemeinsam mit den Teilnehmern unterschiedliche Problemstellung aus den Bereichen App-Design, Mobility Infrastruktur und Cloud-Services betrachtet und für jeden Kunden eine passende Lösung erarbeitet. Diese wurde im Nachgang in Form eines Ergebnisdokuments oder Konzepts zusammengefasst und dem Kunden übergeben. Der Umfang richtete sich dabei stets nach den individuellen Bedürfnissen des Kunden, ebenso wie auch die Vorbereitung und der Workshop selbst. Da die Teilnehmer mitunter einen sehr unterschiedlichen Wissensstand hatten, war es eine besondere Herausforderung für mich, sie jeweils dort abzuholen, wo sie sich gerade befinden. Auswahl der Themen, die im Rahmen der Workshops diskutiert und erarbeitet wurden: - SAP Fiori Infrastruktur (Cloud vs. on Premise vs. hybride Szenarien, Zugriffsmöglichkeiten für Anwender) - App-Typen (hybride Apps vs. native Apps vs. Web Apps, Progressive Web Apps / PWA) - SAP Mobile Services, Hybrid Application Toolkit (HAT), Mobile Development Kit (MDK) - Neuerungen unter S/4HANA (Enterprise Search, SAP CoPilot, Fiori 3.0, Launchpad Notifications, etc.) - Einsatz von Services in der SAP Cloud Platform / SAP Business Technology Platform (Neo und Cloud Foundry Umgebungen) - Sicherheit von Daten beim Einsatz mobiler Anwendungen / 2-Faktor-Authentifizierung - Single-Sign-On (SSO) / SAML - Einsatzmöglichkeiten und Empfehlungen für Mobile Device Management und Enterprise Mobility Management Lösungen (MDM / EMM) - Low-Code Plattformen und deren Vor- und Nachteile (auch im Hinblick auf klassische App-Entwicklung mit SAPUI5) - Usability von mobilen Anwendungen / Fiori Design Prinzipien

In diesem Projekt wurde eine App zur Leistungserfassung durch Lieferanten realisiert, welche von zwei Geschäftsbereichen genutzt wird. Diese beiden Geschäftsbereiche haben teilweise unterschiedliche Anforderungen und arbeiten mit anderen Arten von Bestellungen im SAP System. Im Bereich Gase werden Bestellungen genutzt, welche sowohl Material- als auch Dienstleistungspositionen enthalten. Lieferanten werden hier damit beauftragt, TÜV-Prüfungen und weitere Zusatzleistungen für Gasflaschen durchzuführen. Diese Gasflaschen werden anschließend an den Kunden geliefert und können als Material verwendet werden. Dam gegenüber steht der Bereich Energieversorgung, wo nur mit Dienstleistungsbestellungen gearbeitet wird. Die Lieferanten werden hier mit Malerarbeiten an Industriegas-Behältern beauftragt und erfassen anschließend die durchgeführten Malertätigkeiten mit eventuellen Zusatzleistungen. Zudem wird im Bereich Energieversorgung mit CS-Aufträgen gearbeitet, auf welche die Bestellungen kontiert sind. Für die in den CS-Aufträgen enthaltenen Equipments müssen bei Anlage der Leistungserfassung bestimmte Klassenmerkmale gesetzt werden, damit die durchgeführte Tätigkeit der Dienstleister auch über das Equipment nachvollzogen werden kann. Um den Prozess der Leistungserfassung zu beschleunigen und manuellen Arbeitsaufwand für das Abschreiben der Angaben von der Lieferantenrechnung zu reduzieren wurde eine SAP Fiori Anwendung realisiert, welche dem Anwender auf Basis seiner zugeordneten Lieferantennummern die für ihn gültigen Bestellungen mitsamt den Bestellpositionen anzeigt. Zu diesen kann der Lieferant dann erbrachte Leistungen erfassen, welche als Service Entry Sheet (Leistungserfassungsblatt) mit Bezug zur Bestellung im SAP verbucht wird. Neben der Erfassung der erbrachten Leistungen an sich können auch Anhänge wie externe Leistungsnachweise über die App erfasst werden. Diese werden im SAP archiviert und als Anhang zur Bestellung abgelegt. Durch die Bereitstellung einer SAP Fiori App zur Durchführung der Leistungserfassung konnte der Prozess erheblich beschleunigt und vereinfacht werden, sodass die Mitarbeiter der Einkaufsabteilung weniger Zeit dafür aufwenden die erbrachten Leistungen manuell im System zu buchen. Auch Folgeprozesse wie die Rechnungsprüfung profitieren von dieser digitalen Art der Erfassung.

In diesem Projekt wurden die Prozesse rund um das Thema Behälterlogistik digitalisiert und im SAP abgebildet. Zeil war es, den bisherigen intransparenten Prozess systemisch zu unterstützen und diesen damit nachvollziehbarer sowie schneller zu machen. Behälterlogistik beschreibt dabei alle Prozesse, bei denen Industriegas-Behälter transportiert, instandgesetzt und verschrottet werden. Hierfür arbeitet der Kunde mit verschiedenen Dienstleistern zusammen, welche diese logistischen Tätigkeiten übernehmen. Für die Abbildung der Prozesse wurden insgesamt 9 SAP Fiori Apps entwickelt, welche auf den zuvor bereits umgesetzten Apps zur Leistungserfassung aufsetzen. Diese Leistungserfassungs-Apps wurden in einem anderen Projekt realisiert. In beiden Projekten habe ich als Projektleiter fungiert, sodass die Steuerung des Umsetzungsteams, das Projekt-Controlling (Time, Budget, Quality) sowie das Test-Management zu meinen Aufgaben gehört haben. Zudem habe ich für beide Projekte das fachliche und das technische Konzept in Zusammenarbeit mit dem Kunden erstellt. Die umgesetzten Fiori Apps sind jeweils für einen Teilprozess der Behälterlogistik relevant. Dazu zählen Auslieferungen, Rückholungen, Verschrottungen, Instandsetzungen (Regenerationen), routinemäßige Prüfungen sowie Umlagerungen. Die von den Dienstleistern erbrachten Leistungen in diesem Zusammenhang werden mit Bezug zu SAP Bestellungen als Leistungserfassungsblatt gebucht. In diesem Zusammenhang werden auch Zertifikate und Nachweise als Anhang erfasst und im SAP archiviert. Zudem werden die Behälter, welche SAP-seitig als Equipments abgebildet sind, im Rahmen der Verbuchung in technische Plätze ein- oder ausgebaut, sodass jederzeit nachvollziehbar ist, wo sich ein Behälter gerade befindet. Das führende Element zur Identifikation ist dabei die Seriennummer des Behälters. Zur Abbildung von geplanten Umlagerungen werden SAP-seitig Reservierungen verwendet.

In diesem Projekt wurden die Prozesse der Prüflosbearbeitung und der Auswertung von Prüfergebnissen digitalisiert, um den bisherigen Papierprozess abzulösen. Ich habe dabei in meiner Rolle als Projektleiter den Kunden durch den gesamten Projektzeitraum begleitet, angefangen von gemeinsamen Konzeptionsworkshops über die Umsetzungsphase bis hin zu gemeinsamen Tests und der Produktivsetzung. Als Ergebnis des Projekts wurden zwei SAP Fiori Apps realisiert. Eine App zur Prüfabwicklung, d.h. zur Anzeige von Prüflosen mit den dazugehörigen Vorgängen und Prüfmerkmalen sowie zur Erfassung der Prüfergebnisse, und eine App zur Auswertung von Prüfergebnissen, die für ein bestimmtes Material oder für ein bestimmtes Prüfmerkmal die Prüfergebnisse in einem definierten Zeitraum grafisch und tabellarisch anzeigt. Diese zweite App wird verwendet, um bei auftretenden Qualitätsproblemen in der Produktion schnell zu prüfen, wie sich die Qualität der genutzten Rohstoffe im Verlauf der Zeit entwickelt hat. Hierzu können durch grafische Auswertungen auch Trends erkannt werden, beispielsweise dass sich ein bestimmtes Merkmal immer weiter dem Toleranzbereich genähert hat. In der App zur Prüfdurchführung können sowohl neue Stichproben erzeugt werden (sofern dies für das aktuelle Prüflos zulässig ist) als auch Anhänge hochgeladen werden, zum Beispiel um externe Prüfberichte mit im SAP als Anhang zum Prüflos abzulegen. Auch Kommentare bzw. Prüfbemerkungen können über die App erfasst werden. Darüber hinaus können einzelne Merkmale oder ganze Vorgänge des Prüfloses abgeschlossen und somit entsprechend des Customizings im SAP QM automatisch bewertet werden. Abschließend kann auch der Verwendungsentscheid zu einem Prüflos über die App erfasst werden. Bei produktionsbegleitenden Prüfungen kann hier auch der Nachlagerort angegeben werden, sodass festgelegt wird, ob die geprüfte Menge in den freien Bestand oder in den Sperrbestand überführt wird.

Im Rahmen dieses Projekts wurden die Prozesse rund um die Bedarfsmeldung digitalisiert. Das umfasst den Bereich von der Meldung des Bedarfs über die Freigabe durch die entsprechenden Genehmiger bis hin zur Überführung in einem Bestellung. Das Projekt bestand dabei aus zwei Teilprojekten: Zum einen der Einführung des SAP Prozesses zur Bedarfsanforderung (BANF) einschließlich des Customizings der Freigabestrategie und zum anderen der Bereitstellung von insgesamt vier SAP Fiori Apps für die Prozessbeteiligten. Im Rahmen der Einführung des BANF-Prozesses wurde dabei zunächst gemeinsam mit dem Kunden die gewünschte Freigabestrategie erarbeitet. Diese berücksichtigt unter anderem Vorgesetzte, Kostenstellenverantwortliche, Anlagenverantwortliche sowie die Geschäftsführung. Abhängig von der gewählten Kontierung und des Nettowerts der BANF werden die jeweiligen Genehmiger ermittelt und erhalten anschließend ein SAP Workitem zur Genehmigung in ihre Inbox. Ergänzend zu dieser systemischen Abbildung der Bedarfsmeldung, welche zuvor ein reiner Papierprozess war, wurden auch mehrere Fiori Apps bereitgestellt, damit die Anwender eine moderne und anwenderfreundliche Oberfläche nutzen können. Dabei handelt es sich um zwei SAP Fiori Standard Apps (Bestellung nachverfolgen und Bestellanforderung genehmigen) sowie zwei Eigenentwicklungen (BANF anlegen und Nutzerparameter pflegen). Die App zur Pflege der Benutzerparameter ist dabei unterstützend. Hier kann der Anwender sich individuelle Default-Werte hinterlegen (z.B. für Werk oder Anlieferadresse) sowie Vertreter für sich selbst definieren. Die Erfassung der BANF selbst erfolgt dann über die zweite App. Hier können alle relevanten Angaben zum Bedarf gemacht werden, angefangen von Materialnummer über den Wunschlieferant bis hin zur Kontierung der einzelnen Positionen. Auch Anhänge wie z.B. erhaltene Angebote können mit hochgeladen werden. Verbucht werden die erfassten Daten dann als BANF im SAP, wodurch auch der Freigabeprozess gestartet wird. Bei nachträglichen Änderungen an der Bedarfsmeldung wird die Freigabe falls notwendig neu gestartet, beispielsweise wenn sich Freigabegrenzen geändert hat. Da diese Fiori Apps die ersten waren, welche der Kunde eingeführt hat, war auch das Grund-Customizing des SAP Gateway Servers sowie die Einrichtung des SAP Fiori Launchpads Teil des Projekts. Im Rahmen dieser Einführung wurde das notwendige Know-How zur Betreuung der Fiori Apps an die interne IT-Abteilung transferiert, sodass ein reibungsloser Produktivbetrieb gewährleistet ist. Durch die Digitalisierung des Bedarfsprozessen und die Bereitstellung von anwenderfreundlichen SAP Fiori Apps konnte die Prozessdurchlaufzeit erheblich verbessert werden. Zudem ist durch die systemische Freigabe der Bedarfe jederzeit eine Nachvollziehbarkeit und Transparenz gegeben, welche der alte Papierprozess nicht hatte.

In diesem Projekt war es das Ziel, eine zentrale Inbox für Anwender zur Verfügung zu stellen, in welcher alle Arten von Workitems gebündelt dargestellt werden. Die Herausforderung bestand darin, dass neben dem SAP System auch Drittsysteme wie die Oracle HCM Cloud angebunden werden sollten. Der Kunde befand sich gerade in der Ablösung des alten SAP ESS/MSS Portals durch die Oracle HCM Cloud, wollte aber für die Endanwender eine nahtlose User Experience beibehalten und Sprünge zwischen verschiedenen Systemen vermeiden. Daher wurde im Rahmen des Projekts gemeinsam ein Konzept erarbeitet, wie die SAP Fiori My Inbox als eine solche zentrale Inbox verwendet werden kann. Die Konzeption sowie die Umsetzung des Projekts habe ich dabei als Projektleiter begleitet. Die Lösung sah vor, einen sogenannten Custom Task Provider zu implementieren, welcher die Workitems aus der Oracle HCM Cloud abruft und für die Darstellung in der My Inbox aufbereitet. Ein Custom Task Provider ist dabei der von der SAP vorgesehen Weg, um die My Inbox um Workitems aus Drittsystemen anzureichern. Dieser greift über einen ABAP Consumer Proxy, welcher auf einen Endpunkt in der CPI verweist, auf einen Integration Flow (iFlow) zu. Dieser iFlow wiederum fragt die Workitems aus der Oracle HCM Cloud ab und schickt die Daten zurück ans SAP, wo die Aufbereitung für die Darstellung in der Fiori My Inbox erfolgt. In einer späteren Ausbaustufe wurde die Integration zudem noch um eine direkte Genehmigung bzw. Ablehnung über die My Inbox erweitert. Zuvor war es nur Möglich, über einen Direktlink zum jeweiligen Workitem in der Oracle HCM Cloud abzuspringen und dort die entsprechenden Genehmigungsschritte vorzunehmen. Durch die Erweiterung wurde die User Experience noch weiter verbessert. Eine Besonderheit dabei ist, dass die Anmeldeinformationen aus dem SAP über die CPI bis zur Oracle HCM Cloud weitergereicht werden (Principal Propagation). Auf diese Weise wird sichergestellt, dass jeder Anwender nur die Workitems in der My Inbox angezeigt bekommt, die ihm auch zugewiesen sind. Auf den Einsatz von technischen Usern wird gänzlich verzichtet, was die Sicherheit der Integrationslösung verbessert. Der in diesem Projekt realisiert Ansatz ist zudem auch auf andere Szenarien anwendbar. Letztlich kann jedes Drittsystem, welche in irgendeiner Weise über eine Web-Schnittstelle verfügt (REST, OData, SOAP, etc.) auf diese Weise angebunden und die darin enthaltenen Workitems so in die My Inbox integriert werden.

In diesem Projekt wurde ein SAP-Backend realisiert, welches zur Abbildung eines Prozesses im Zusammenhang mit dem Treibhausgas-Emissionshandelsgesetz genutzt wird. Ziel war es dabei, dass Geschäfts- und Privatkunden über ein Self-Service-Portal Elektrofahrzeuge (PKW, LKW, Motorräder, etc.) erfassen können, welche dann im SAP-System des Kunden als Equipment mit bestimmten Klassenmerkmalen angelegt werden. Für diese Elektrofahrzeuge werden dann vom Umweltbundesamt Zertifikate ausgestellt, welche als Alternative zur Reduzierung der eigenen Treibhausgasemission fungieren. Der private oder geschäftliche Endkunde erhält als Ausgleich dafür eine Gutschrift. Der Endkunde muss im Self-Service-Portal lediglich einige grundlegende Angaben zum Fahrzeug machen und den Fahrzeugschein als Anhang hochladen. Diese Daten werden dann über einen OData Service ans SAP übertragen. Um den aktuellen Bearbeitungsstand zu protokollieren, wird der Equipment-Status genutzt. Nach Ausstellung des Zertifikats durch das Umweltbundesamt wird der Status aktualisiert und für den Endkunden ein Kundenauftrag mit einer Gutschrift erzeugt, welcher anschließend direkt fakturiert wird. Auf diese Weise erhält der Endkunde dann seine Ausgleichszahlung.

Ziel dieses Projekts ist die Realisierung einer Service-Techniker-App im Bereich Löschwassertechnik (LWT) und Rauch-Wärme-Abzugsanlagen (RWA). Die App soll den bisher genutzten Papierprozess vollständig ablösen und digitalisieren. Dies wirkt sich auch positiv auf die Prozessdurchlaufzeiten aus, sodass Rechnungen für durchgeführte Wartungsarbeiten schneller gestellt und die Provisionsabrechnung der Service-Techniker ohne Zeitverzug am Monatsende gemacht werden können. Die Datengrundlage im SAP wie zum Beispiel Aufträge, Arbeitsplätze, technische Plätze und Equipments stammt aus den Modulen SAP PM (Instandhaltung) und SAP CS (Kundenservice). Alle in der App erfassten Daten werden auch ins SAP zurückgeschrieben, sodass diese jederzeit revisionssicher abgelegt sind. Als Platform für die Realisierung der App wird dabei auf die Neptune DX Platform gesetzt, da eine essenzielle Anforderung die Offline-Fähigkeit der Anwendung ist. Da die Service-Techniker bei Außendienst-Einsätzen mitunter keine oder nur eine schlechte Internetverbindung haben, muss die gesamte Anwendung vollständig offline nutzbar sein. Dies umfasst alle Bestandteile der Anwendung von der Auftragsplanung über die -bearbeitung bis hin zur Rückmeldung der Aufträge. Die Daten werden dabei ans SAP System übertragen, sobald der Techniker das nächste Mal eine stabile Internetverbindung hat. Die App bietet dem Techniker alle benötigten Funktionen im Bereich der Auftragsbearbeitung. Das umfasst unter anderem die Erfassung von Kopfdaten (Prüfdatum, Kundenansprechpartner, besondere Rechnungstexte, etc.), die Erfassung von Anlagendaten (Equipments mit Zusatzinformationen wie Hersteller, etc.) und Befund-Daten im Rahmen der Wartungstätigkeit sowie die Erfassung von durchgeführten Dienstleistungen und dafür eingesetzten Materialien, welche später für die Rechnungsstellung herangezogen werden. Auch für den Innendienst-Vertrieb relevante Informationen wie weitere Ausbaupotentiale des Kunden können über die App erfasst werden. Aus den erfassten Befund-Daten werden im SAP mit Hilfe von Adobe Forms Prüfprotokolle und Tätigkeitsnachweise erzeugt, welche anschließend an den Kunden geschickt werden. Die Umsetzung dieser Formulare ist ebenfalls Bestandteil des Projekts. Meine Rolle im Projekt war die Steuerung und Leitung. Das Umsetzungsteam bestand aus insgesamt 7 Personen, welche in insgesamt ca. 200 PT die Anwendung realisiert haben. Neben dem Projekt-Controlling mit Blick auf Budget, Time und Quality war auch die Koordination der Test- und Pilotphase Teil meiner Aufgabe. Das Gesamtvolumen des Projekts beträgt ca. 400.000 €. Die Umsetzungsphase für die Erstellung der App und der Adobe Formulare belief sich auf ca. 7 Monate. Anschließend wurde die Anwendung nach einer zweimonatigen Testphase mit der IT und dem Fachbereich zunächst an ausgewählte Pilot-Techniker ausgerollt, welche weitere zwei Monate lang praktische Erfahrung bei der Nutzung der App im Tagesgeschäft gesammelt haben. In dieser Phase wurden sukzessive weitere kleine Verbesserungen umgesetzt, welche sich positiv auf die Usability und damit die Nutzerakzeptanz auswirken.

Der Kunde wollte die Lösung Staffbase einführen, eine Plattform für die unternehmensinterne Kommunikation. Diese sollte bestmöglich in das bestehende ESS-Portal integriert werden, in dem bereits diverse andere ESS-Szenarien auf Basis des SAP HCMs abgebildet sind (Abwesenheiten, Arbeitszeiten, etc.). Bei dem Portal handelt es sich um ein Fiori Launchpad, welches mit Hilfe der Neptune Open Edition realisiert wurde. Die darin befindlichen Anwendungen greifen über Schnittstellen auf das zugrundeliegende SAP-System zu. Meine Rolle in dem Projekt war die Projektleitung und die Steuerung der beiden Entwickler, welche die Umsetzung durchführten. Ich habe den Kunden dabei von der initialen Anforderungsaufnahme über Umsetzung und Test bis hin zum Go-Live begleitet. Anschließend wurde die Lösung für die weitere Betreuung an den mindsquare-Service übergeben. Da es sich bei Staffbase um eine externe Lösung handelt, die nicht direkt in das SAP integriert ist, war das Ziel in diesem Projekt eine eigene Fiori App zu entwickeln, über welche sich der Mitarbeiter bei Staffbase registrieren kann. Die Stammdaten aus dem SAP HCM werden dabei bereits vorbelegt und für die Registrierung verwendet. Außerdem sollte ein Absprung aus dem ESS-Portal nach Staffbase über eine weitere App realisiert werden, in welcher auch die aktuell hinterlegten Staffbase-Daten eingesehen und bei Bedarf aktualisiert werden können. Das Projekt wurde zur Zufriedenheit des Kunden in Time, in Budget und in Quality umgesetzt. Der Rollout von Staffbase, der initial nur für die kaufmännischen Mitarbeiter vorgesehen war, wurde inzwischen ausgeweitet, sodass auch gewerbliche Mitarbeiter die Plattform nun nutzen können.

In diesem Projekt begleite ich den Kunden dabei, ein Altsystem abzulösen und die darin abgebildeten Prozesse ins SAP zu überführen. Der Kunde ist Bereich Blumen- und Pflanzen-Großhandel aktiv. Diese werden auf Ladungsträgern, beispielsweise sogenannten CC- oder EC-Containern, bei den Lieferanten abgeholt, transportiert und schließlich zum Endkunden gebracht. Für die Verweildauer der Ladungsträger bei den Partnern (Lieferanten, Endkunden) fällt eine Miete an, welche monatlich abgerechnet wird. Das Altsystem verwaltete bisher diese Ladungsträger-Bewegungen und führte die daran anknüpfende Abrechnung durch. Bei der Überführung der Prozesse ins SAP sollte vor allem eine Abbildung im SAP-Standard angestrebt werden, sofern dies sinnvoll möglich ist. Diese Zielvorgabe wurde unter anderem mit Blick auf eine bevorstehende S/4HANA Migration gesetzt. Zur Erreichung dieses Ziels musste auch eine umfangreiche Prozessberatung und -Vereinfachung stattfinden und historisch gewachsene Prozesse kritisch hinterfragt werden. Neben der Leitung des Projekts war dies ebenfalls meine Rolle im Projekt. Im Kern besteht das Projekt aus den folgenden beiden Teil-Projekten: 1. Abbildung aller logistischen Prozesse für Ladungsträger-Bewegungen und -Bestandsführung inkl. der dazugehörigen Dispositionsprozesse (Tourenplanung) 2. Abbildung der daran anknüpfenden Mietabrechnungsprozesse mit Hilfe des SAP Agenturgeschäfts (LO-AB) Die logistischen Prozesse für Ladungsträger werden primär mit Hilfe des SAP MM abgebildet. Die Ladungsträger sind dabei entweder im Werksbestand, wenn sie gerade bei einem Standort des Kunden stehen, oder im Kundenleihgutbestand, wenn sie gerade bei einem Partner (Lieferant, Endkunde, Spediteur) stehen. Die Prozesse bilden dabei auch komplexere Fälle ab, wie beispielsweise Transaktionen, die direkt zwischen zwei Partnern stattfinden (Umbuchungen, Streckenlieferungen, etc.). Derartige Bewegungen kennt der SAP-Standard nicht, sodass hierfür möglichst Standard-nahe Lösungen erarbeitet wurden. Ebenfalls Teil der logistischen Abwicklung ist die gesamte Tourenplanung, welche über ein externes TMS erfolgt. Dieses kommuniziert via IDoc mit dem SAP. Die Abbildung von benötigten Lieferpapieren für Ladungsträger war ebenfalls im Scope des Projekts, diese wurden mit Hilfe von Adobe Forms im SAP abgebildet. Die im Kundenleihgutbestand befindlichen Ladungsträger stellen die Grundlage für die monatliche Mietabrechnung dar. Im Folgemonat werden über einen Report alle Tagesbestände und Bewegungen ermittelt. Dabei werden auch komplexere Anforderungen an den Abrechnungsprozess wie z.B. mietfreie Tage oder mietfreie Mengen berücksichtigt. Aus den so ermittelten Tagesbeständen werden dann Regulierungsbelege im Agenturgeschäft (LO-AB) erzeugt, welche anschließend in eine Kundenabrechnung überführt werden. In diesen Belegen findet die Preisfindung mittels SAP-Standard-Konditionstechnik statt. Ebenfalls werden über den SAP-Standard auch relevante Nachrichtensätze für die Rechnung selbst sowie eine dazugehörige Transaktionsübersicht ermittelt. Die zugrundeliegenden Formulare wurden auch mit mittels Adobe Forms realisiert. Das ursprüngliche Projekt hatte eine Laufzeit von ca. 1,5 Jahren von initialer Anforderungsaufnahme bis hin zum Go-Live Mitte 2024. Allerdings begleite ich und unser Projektteam den Kunden auch über den Go-Live hinaus und sorgen so einerseits für einen reibungslosen Ablauf im Tagesgeschäft und andererseits für stetige Optimierungen und Verbesserungen im Prozess. Beispielsweise wurden im Nachgang an den Go-Live noch weitere Prozesse wie Inventuren systemisch unterstützt. Außerdem wurden die Prozesse auch in andere Tochtergesellschaften ausgerollt, sodass eine konzernweite Prozessharmonisierung stattfindet.

Ziel dieses Projekts war die Erstellung eines Lastenhefts für eine Lösung, mit deren Hilfe Obermonteure zukünftig die Wartungs- und Instandhaltungstätigkeiten für das Wärmenetz in Berlin planen können. Der bisherige Planungsprozess basierte in weiten Teilen auf selbst gebauten Excel-Lösungen und war zudem nicht harmonisiert zwischen den fünf Teil-Bereichen, die in die Wartung und Instandhaltung involviert sind. Daher sollte zukünftig eine optimal ins SAP integrierte Lösung geschaffen werden. In diesem Zuge sollten zudem die bestehenden Prozesse hinterfragt und sofern sinnvoll optimiert bzw. vereinfacht werden. Ich habe das Projekt als Projektleiter und Architekt verantwortet. Dabei wurde ich von zwei weiteren Consultants unterstützt. Zu Beginn des Projekts haben wir die Ist-Prozesse vollständig aufgenommen. Dafür haben wir die Obermonteure in den fünf Teil-Bereichen einen Tag lang bei ihrer Arbeit begleitet und dabei die relevanten Tätigkeiten und Arbeitsschritte sowie die aktuellen Schmerzpunkte aufgenommen. Auf dieser Basis haben wir anschließend die Ist-Prozesse modelliert. Im nächsten Schritt haben wir Verbesserungspotenzial in den Ist-Prozessen identifiziert und diese mit dem Kunden besprochen. Für die von uns identifizierten Potenziale wurden jeweils Vor- und Nachteile dargestellt und eine ROI-Betrachtung durchgeführt. Dieses Zwischenergebnis war die Grundlage für das von uns erstellte Lastenheft, welches später auch als Grundlage für eine Ausschreibung diente. Nachdem die fachlichen Soll-Prozesse einschl. der Optimierungen abgestimmt waren, haben wir im zweiten Teil des Projekts eine Evaluierung von Tools und Lösungen am Markt vorgenommen. Ausschlagend dabei waren Aspekte wie die Kosten der Tools (Einführungskosten und laufende Kosten) aber auch die Abdeckung der zuvor definierten Soll-Prozesse. Auch die Option einer Eigenentwicklung auf Basis von Neptune oder SAPUI5 / Fiori wurde mit evaluiert. Das Endergebnis haben wir dem Kunden abschließend vorgestellt und dabei eine Empfehlung zum weiteren Vorgehen gegeben. Diese bestand daraus, dass eine Kombination aus einem am Markt verfügbaren Tool für die eigentliche Disposition der Wartungstätigkeiten in Kombination mit einigen wenigen Eigenentwicklungen für daran angrenzende Rand-Prozesse (z.B. Planung von Rufbereitschaften) die beste Prozessabdeckung bietet. Mit diesem Wissen war der Kunde auf die anstehende Ausschreibung vorbereitet und die passende Anbieterauswahl treffen.

Dieses Projekt bestand inhaltlich aus zwei Teilprojekten: 1. Konzeption und Aufbau einer Schnittstelle zwischen SAP und einem externen Kassensystem, welches in den Filialen des Kunden eingesetzt wird 2. Konzeption und Implementierung von Fiori Apps für Auktionen, welche die im SAP ablaufenden WM-Prozesse bestmöglich unterstützen Ich war dabei Projektleiter für beide Teilprojekte und habe das Umsetzungsteam, bestehend aus bis zu vier Consultants, gesteuert und koordiniert. Parallel dazu habe ich den Kunden auch als Architekt beraten und so dafür gesorgt, dass zukunftssichere und stabile Design-Entscheidungen getroffen werden. Im Teilprojekt zur Anbindung des externen Kassensystems wurden die bestehenden SAP-SD-Prozesse so erweitert, dass wenn eine Aktion im SAP vorgenommen wird, welche eine Interaktion an der Kasse erfordert (z.B. Auszahlung, Rückgabe, Ankauf), diese an die Kasse übermittelt wird. Anschließend erfolgt die Transaktion im Kassensystem, wobei sowohl Bargeld- als auch EC-Transaktionen unterstützt werden. Die Rückmeldung des Kassensystems wird dann ebenfalls per Schnittstelle ans SAP übermittelt, wo die Verbuchung im FI Kassenbuch erfolgt. Das zweite Teilprojekt zur Erstellung der Fiori Apps hatte das Ziel, alle Prozesse im Vorfeld und im Nachgang von Auktionen bestmöglich zu unterstützen. Dafür wurden verschiedene WM-Apps konzipiert und anschließend umgesetzt, um Prozesse wie Einlagerungen, Auslagerungen und Umlagerungen durchzuführen. Diese Prozesse finden in Vorbereitung einer Auktion statt, um die zu versteigernden Artikel zur Auktion zu bringen, bzw. im Nachgang, wenn Artikel nicht versteigert werden konnten und daher wieder eingelagert werden müssen. Durch die Umsetzung der Apps wurde die Effizienz der logistischen Prozesse gesteigert und so insgesamt die Prozessdurchlaufzeiten verbessert.

In diesem Projekt ging es um die Erweiterung einer Lösung für die mobile Instandhaltung, welche ich bereits seit 2019 in Zusammenarbeit mit dem Kunden implementiert und sukzessive weiterentwickelt habe. Der Kunde verwaltet einen großen Industriepark im Raum Frankfurt, in dem eine Vielzahl von Unternehmen ansässig sind. Diese Unternehmen haben ihre Wartungs- und Instandhaltungstätigkeiten dabei an meinen Kunden outgesourct, sodass Wartung und Instandhaltung einen der Kernprozesse darstellt. Ich habe dabei das Projekt zur Weiterentwicklung als Projektleiter begleitet und das Entwicklerteam, bestehend aus zwei Consultants, koordiniert. Darüber hinaus war ich ebenfalls für die Qualitätssicherung zuständig. Im Zuge der Weiterentwicklung habe ich den Kunden durch den gesamten Prozess begleitet. Dies umfasst: - Aufnahme der fachliche Anforderungen - Übersetzung der Anforderungen in technische Lösungsmöglichkeiten und Diskussion dieser Lösungsmöglichkeiten mit dem Kunden - Erstellung von technischen Feinkonzepten für die Umsetzung - Koordination des Entwickler-Teams und Qualitätssicherung der Entwicklungen (Code-Reviews, Beratertests, etc.) - Gemeinsame Kundentests, Sammeln und Bewerten des Testfeedbacks und Umsetzung von Korrekturen sowie notwendigen Anpassungen - Go-Live-Vorbereitung und -Durchführung unter Berücksichtigung von Abhängigkeiten zu anderen Projekten des Kunden Das Erweiterungsprojekt konnte in Time, in Budget und in Quality abgeschlossen werden. Die bereits vorhandenen Prozesse zur mobilen Instandhaltung wurden so weiter optimiert und Effizienzen gesteigert. Ideen für eine zukünftige Weiterentwicklung und weitere Optimierungen sind ebenfalls bereits in Planung.

In diesem Projekt ging es darum, die Mietabrechnungsprozesse des Kunden systemisch abzubilden. Der Kunde hatte bereits einen historisch gewachsenen Mietabrechnungsprozess im SAP umgesetzt, der auf SD-Kundenaufträgen und diversen Eigenentwicklungen sowie Kundentabellen basierte. Im Zuge einer bevorstehenden S/4HANA Migration sollte dieser Prozess überprüft und eine Handlungsempfehlung für die zukünftige Abbildung unter S/4HANA erstellt werden. Insbesondere sollten dabei die Möglichkeiten des S/4HANA Abrechnungsmanagements (ehemals Agenturgeschäft LO-AB) evaluiert und gegen den heutigen Prozess abgewogen werden. Meine Rolle war dabei die Projektleitung und -steuerung. Das Projektteam bestand aus zwei weiteren Consultants, welche das Customizing im System umgesetzt haben. Im ersten haben wir uns im Rahmen eines Kickoffs die bestehenden Mietabrechnungsprozesse angeschaut und diese fachlich hinterfragt. Dabei kam heraus, dass es diverse Sonderfälle und in der Folge Komplexität gibt, da die Abrechnung in unterschiedlichen Landesgesellschaften zu verschiedenen Konditionen erfolgt. Daraus resultierte die Empfehlung an den Kunden, die Mietabrechnungsprozesse generell im Rahmen des S/4HANA Projekts zu harmonisieren und so Komplexität zu reduzieren. Dieser Empfehlung wurde letztlich auch über die Dauer des Projekts hinaus gefolgt. Nach der Aufnahme der Anforderungen an den Mietabrechnungsprozess wurde ein Proof of Concept (PoC) in einer S/4HANA Sandbox aufgebaut und vorgestellt. In diesem Zuge fand auch eine Automatisierung der Belegerstellung für den Abrechnungsprozess mittels periodisch eingeplanten Jobs statt. Der PoC stellte die Grundlage für die abschließende Handlungsempfehlung dar. Am Ende des Projekts wurden die Vorteile der Abbildung mit Hilfe des Abrechnungsmanagements aufbereitet und diskutiert. Obwohl sich einige Optimierungen gegenüber dem heutigen Prozess auf Basis von SD-Aufträgen zeigen ließen, waren diese unserer Einschätzung nach nicht signifikant genug, um ein komplettes Redesign des Prozesses zu begründen. Darüber hinaus hat sich durch eine Analyse auch gezeigt, dass der bestehende SD-Prozess mit einigen Anpassungen bereits S/4HANA-ready gemacht werden kann. Aus diesem Grund habe ich dem Kunden empfohlen, den bestehenden Prozess zu optimieren, die fachlichen Prozesse zu harmonisieren und keinen neuen Prozess auf Basis des Abrechnungsmanagements umzusetzen. Der Kunde folgte diesen Empfehlungen.

In diesem Projekt soll eine alte Lösung zur Touren-/Transportplanung durch ein neues System abgelöst werden, damit alle Prozesse neuen Anforderungen gerecht werden und zudem auch eine stabile, zukunftssichere und damit langfristig nutzbare Plattform etabliert wird. Zu den neuen Anforderungen zählen beispielsweise die digitale Kommunikation mit Sub-Spediteuren oder eine präzise ETA-Berechnung (Estimated Time of Arrival). Das Altsystem konnte diese inzwischen aufgekommenen Business- oder Endkunden-Anforderungen nicht mehr zuverlässig erfüllen. Darüber hinaus war der Support der bisherigen Lösung nur noch eingeschränkt möglich, weshalb im Sinne der Betriebssicherheit eine neue Plattform eingeführt werden sollte. Dabei sollte das bisherige Zusammenspiel zwischen SAP und dem externen TMS nicht einfach 1:1 übernommen werden. Stattdessen war es ein erklärtes Ziel, die bidirektionale Integration der Systeme zu optimieren, um so Datenschiefstände und Systembrüche zu vermeiden. Insgesamt sollen dadurch die operativen Abläufe beschleunigt und die Prozesseffizienz gesteigert werden. Zur Integration der beiden Systeme setzen wir auf gängige Standards wie IDocs und SOAP-basierte Webservices. Im Verlauf der gesamten Planungsprozesse gibt es dabei sowohl Daten, die von SAP an das TMS geschickt werden (Frachtvorschau, Frachtanmeldung, Verlademeldungen, etc.), als auch Daten, die vom TMS zurück ans SAP geschickt werden (Tourenplanung, Abrechnungs-Daten, etc.). Für eine einheitliche Sicht beider Systeme auf die vorhandenen Daten mussten dafür auch komplexere Szenarien wie nachträgliche oder kurzfristige Änderungen sowie deren Auswirkungen auf angrenzende Prozesse berücksichtigt werden (Kommissionierung, Verladung, etc.). Durch das Projekt garantieren wir die Stabilität und Zukunftssicherheit der Touren-/Transportplanungs-Prozesse und werden gleichzeitig den Anforderungen der heutigen Zeit gerecht. Darüber hinaus lösen wir Unzulänglichkeiten im bisherigen Zusammenspiel zwischen SAP und dem TMS auf und sorgen für eine systemübergreifende, konsistente Sicht auf die Daten.

Das Szenario meines Kunden aus dem Bereich Großhandel in diesem Projekt war wie folgt: Die unternehmenseigene Speditionstochter transportiert als Dienstleistung auch Ware von anderen Lieferanten zu Endkunden. Dies geschieht beispielsweise, um freie Transportkapazitäten effizient zu nutzen und um zusätzliche Umsätze zu generieren. Teilweise kommt es jedoch vor, dass diese Fremdware/Drittware auch über die Vertriebsstandorte meines Kunden umgeschlagen werden müssen. Daher wurde nach einer Lösung gesucht, wie diese Ware möglichst effizient in die vorhandenen logistischen Prozesse integriert werden kann. Mit logistischen Prozessen sind hierbei alle Prozesse in Hallenabwicklung vom Wareneingang bis zum Warenausgang gemeint. Ziel war es, dass die Drittware logistisch genauso wie eigene Ware behandelt und durch die Halle bewegt werden kann. Das umfasst beispielsweise eine Stellplatz- und Tourenplanung, die Vereinnahmung der Drittware im Wareneingang und schlussendlich die Verladung der Drittware zusammen mit der eigenen Ware und die anschließende Warenausgangsbuchung. Neben optimierten Abläufen sollte dadurch auch die Transparenz des Prozesses verbessert werden, da so jederzeit nachvollziehbar ist, wo sich die Ware gerade befindet. Zur Lösung dieser Anforderungen haben wir ein Konzept erarbeitet, durch welches das externe TMS in der Lage war, über eine Schnittstelle Drittkundenaufträge im SAP zu erzeugen. Zu diesen Drittkundenaufträgen wurden dann vereinfachte SAP-Belegketten (Bestellung, Anlieferung, Auftrag, Lieferung) generiert, welche in den bereits vorhandenen logistischen Prozessen die Grundlage bilden. Durch das Vorhandensein dieser Belege konnten alle bereits etablierten Prozesse vom Wareneingang bis zum Warenausgang für Drittware genauso gehandhabt werden, wie für die eigene Ware. Darüber hinaus kann dadurch die Drittware auch korrekt auf den Liefer- und Transportpapieren ausgewiesen werden. Durch die Umsetzung dieses Projekts konnten wir die logistischen Abläufe für Drittware verbessern, lange Laufwege zum Suchen nach der Drittware vermeiden und die Prozesstransparenz deutlich verbessern. Somit besteht nun auch die passende systemische Grundlage für die Zukunft, wo davon ausgegangen wird, dass das Volumen der Drittware noch deutlich zunehmen wird.