Anforderungsanalyse zur Umsetzung eines digitalen Zwillings im Containerterminal

Logistik 4.0 bezeichnet grundlegend die Verknüpfung der vierten industriellen Revolution (Industrie 4.0) mit ihren Auswirkungen auf die Logistik. Dabei beschreibt Industrie 4.0 die intelligente Vernetzung von Maschinen und Prozessen in der Wirtschaft mit Unterstützung von Informationstechnologie (IT).Die Digitalisierung ist dabei Kernbestandteil und liefert neue Möglichkeiten, durch Daten von Maschinen und das digitale Abbilden von Prozessen die Daten in nahezu Echtzeit zu verarbeiten und auszutauschen (Urbach and Ahlemann 2017). Folglich lassen sich damit ganze Wertschöpfungsketten optimieren, aber auch Prozesse mit einem Detailgrad digital abbilden, welcher bislang nicht möglich war (Sucky and Asdecker 2019). In Bezug auf Logistiksysteme sind somit Routenoptimierungen von ganzen LKW-Flotten ebenso wie die automatische Vertragsabwicklung bei Lieferung oder das Nachverfolgen von weltweiten Warenbewegungen Bestandteile von Logistik 4.0. Die Optimierungen von z. B. Warentransporten oder Lagerprozessen innerhalb einer Organisation können aber ebenfalls unter Logistik 4.0 gefasst werden (Bousonville 2017).

Aufgrund hoher Anforderungen arbeiten viele Logistikunternehmen an der digitalen Transformation, z. B. durch die Einbindung von digitalen Marktplätzen oder die Anbindung von Sensoren (Bitkom 2022). Dabei ist jedoch der unterschiedliche Digitalisierungsstand als Basis der Transformation zu berücksichtigen, wie dies im Hafen- und Terminalkontext ebenfalls sichtbar ist (Neugebauer et al 2022). Wie viele Daten in einem Logistikunternehmen bereits gesammelt oder verarbeitet werden, hat bspw. direkten Einfluss auf die Rahmenbedingungen für die Umsetzung digitaler Schlüsseltechnologien als Teil von Logistik 4.0 (Heilig et al 2017b). Zu den digitalen Schlüsseltechnologien gehören unter anderem das Internet der Dinge (IoT), Big Data, Simulationen und Cloud Computing (Pistorius 2020). Die Liste der anwendbaren Technologien umfasst unzählige Weitere, die zu Anwendungsfällen wie der Lieferkettenüberwachung oder der intelligenten Wartung und Steuerung genutzt werden können (Terziev et al 2020).¹

Im Allgemeinen lassen sich die meisten der wissenschaftlichen Definitionen zu Logistik 4.0 auf die Auswirkungen des Paradigmenwechsels in der Produktion hin zur Massenindividualisierung zurückführen. Die Veränderungen der Logistikprozesse auf den Einsatz digitaler Technologien und die Bedeutung des Menschen, der in seiner Rolle als Mitarbeitender, Kunde und anderer Stakeholder betrachtet wird, sind jedoch ebenfalls Teil der Definition (Winkelhaus and Grosse 2020). Diese Bereiche müssen im Folgenden betrachtet werden. Die im beschriebenen Forschungsprojekt verwendete Technologie des digitalen Zwillings soll nachfolgend näher erörtert werden.

Obwohl der digitale Zwilling oft auch als „Cyber-Physisches System“ (CPS) bezeichnet wird, kann ein digitaler Zwilling als „virtuelle Darstellung eines physischen Systems (und seiner zugehörigen Umgebung und Prozesse), welches durch den Austausch von Informationen zwischen dem physischen und dem virtuellen System aktualisiert wird“ (Van Der Horn and Mahadevan 2021), beschrieben werden. Diese Definition ist aus einer Überprüfung vieler Definitionen in der Literatur abgeleitet und stellt den aktuellen Stand der Forschung dar. Dabei grenzt sich der digitale Zwilling durch die eins zu eins Integrationsebene vom CPS ab (Tao et al 2019). Wie in Abb. 1 dargestellt, ist der Informationsfluss zwischen dem physischen und dem digitalen Objekt eines Zwillings vollständig integriert und in alle Richtungen automatisiert, was wiederum die Merkmale eines digitalen Zwillings beschreibt. Jeder digitale Zwilling enthält ein Modell von unbestimmter Komplexität, welches ein repräsentatives Verhalten des physischen Systems oder Betrieb des Zwillings abbildet (Fuller et al 2020). Ein digitaler Zwilling ist erst dann realisiert, wenn die zugrunde liegenden Prozesse und Veränderungen aus dem Betrieb automatisch den Zwilling verändern sowie das Verhalten und Lernen des Zwillings durch Entscheidungen automatisch in den physischen Betrieb einfließen (Grieves and Vickers 2017). Im Gegensatz dazu wird ein digitaler Schatten als einseitige Integration beschrieben.

Ein Beispiel ist die Integration von nahezu Echtzeitdaten, die durch das Modell angereichert, in 3D visualisiert und dann durch eine Person analysiert werden. In der Praxis könnte das Modell eines Straddle Carriers auf der Grundlage von nahezu Echtzeitdaten zeigen, dass ein Weiterfahren mit der gleichen Geschwindigkeit zu einer Überhitzung führt. Dementsprechend kann das technische Personal den Fahrenden auffordern, langsamer zu fahren. Nach diesen Definitionen könnte das digitale Unterstützungssystem z. B. ein 3D-Modell oder eine technische Dokumentationsdatei sein. Dies bedeutet, dass es keinen automatisierten Datenfluss oder eine Aktualisierung zwischen dem digitalen Modell oder System und dem physischen Objekt oder Prozess gibt. Digitale Zwillinge bilden in der Regel die Grundlage für eine echtzeitnahe und hoch effektive digitale Repräsentation von Objekten oder Systemen zur Weiterverwendung im Rahmen der Optimierung, Simulation oder für andere technologische Anwendungen (Zheng et al 2019). Bei ordnungsgemäßer Umsetzung eines digitalen Zwillings überwiegen jedoch die Vorteile der Kostensenkung und der Schaffung neuer Einnahmemöglichkeiten die Schwierigkeiten, die bei der Umsetzung zu überwinden sind (Min 2022). Darüber hinaus können die im digitalen Zwilling enthaltenen Simulationen in Logistikprozessen und -unternehmen auf der Grundlage der digitalisierten Systeme dazu beitragen, komplexe Systeme zu bewerten, zu optimieren und sogar weitere Daten zu generieren. Dies bietet neue Möglichkeiten, die komplexen Systeme zu analysieren und kurz- bis langfristig für Verbesserungen zu nutzen (Zhou et al 2018).

Trotz der beschriebenen Vorteile sind digitale Zwillinge bisher vor allem im Kontext von Containerterminals eher selten oder meist auf Teilkomponenten beschränkt. Zudem beschreiben die meisten wissenschaftlichen Arbeiten eher digitale Schatten (Neugebauer et al 2022). Dennoch gibt es beispielhafte Projekte für digitale Zwillinge, die auch Erkenntnisse für das in Abschn. 3 beschriebene Projekt bieten. Beispielhaft ist das Zwillingsmodell im Hafen von Anzio (Italien) für die Planung und Kontrolle des Energieverbrauchs und die optimierte Implementierung von erneuerbaren Energiesystemen (Agostinelli et al 2022). Das von Szpytko and Duarte (2019) beschriebene Zwillingsmodell einer Containerbrücke kann ebenfalls als Ausgangspunkt für Teilkomponenten des in Abschn. 3 beschriebenen Projekts angesehen werden. Noch größeren Einfluss haben jedoch die thematisch näher gelegenen Forschungsarbeiten in Long Beach bzw. Los Angeles (USA) und Singapur. In der Ersten wird die Entscheidungsunterstützung für Infrastruktursicherheit im Hafenbereich thematisiert (Lennon et al 2012). In der Zweiten haben insbesondere die Simulationskomponenten Implikationen für das beschriebene Projekt in Hamburg (Li et al 2020). Einen digitalen Zwilling, wie dieser im Projekt TwinSim umgesetzt werden soll, gibt es aktuell allerdings noch nicht, trotzdem sind die umfassenden Forschungen zur Modellierung und Simulation große Hilfestellungen. Außerdem gibt es bereits einen umfangreichen Forschungsstand zu den verschiedenen technischen Bereichen, sodass die aktuelle Forschung zumindest für die einzelnen Komponenten, aber auch für Optimierungen der meisten Bereiche genutzt werden kann. Der Umfang des Projekts ist derzeit neuartig, insbesondere durch die Kombination der verschiedenen Optimierungsprobleme und die vollständige Modellierung aller Prozesse anhand von Echtzeitdaten. Es gibt derzeit keine praktischen Berichte über die Anforderungsanalyse für solche Projekte, obwohl Beispiele aus anderen Bereichen herangezogen werden können.

Zusammenfassend bedeutet dies für die Umsetzung des digitalen Zwillings im Projekt, dass eine sinnvolle Verknüpfung der bereits bestehenden Arbeiten erfolgen muss, wobei ein Wissenstransfer aus anderen Themenbereichen z. B. für den Anforderungsanalyseprozess sinnvoll ist. Allgemein führt die Komplexität, welche sich aus dem Umfeld der Containerterminals und die große Anzahl von Stakeholdern in den Logistikprozessen ergibt, zu einer komplexen Definition von Anforderungen und Anwendungsfällen (Use Cases), weshalb nachfolgend eben diese Themen näher betrachtet werden.

Jegliche Digitalisierung oder digitale Transformation sollte, um damit zusammenhängende Ziele zu erreichen, auf Basis von konkreten Anforderungen und Anwendungen erfolgen. Hierbei sollte ebenfalls berücksichtigt werden, ob bei einer bestimmten Anforderung überhaupt eine Lösung mittels IT zu dem gewünschten Ergebnis führen kann. Dies beantwortet in der Regel ebenfalls, ob es sich um ein Logistik 4.0-Thema handelt. Die Anforderungsanalyse und -ermittlung innerhalb der IT, häufig als Requirements Engineering bezeichnet, dient zur strukturierten Ermittlung einer zu erfüllenden Zielstellung (Herrmann 2022; Balzert 2009). Dies kann ein Soll-Prozess sein, aber auch ein zu erfüllendes Merkmal eines Produkts oder einer Software. Um sicherzustellen, dass alle Anforderungen vollständig, in der richtigen Qualität und Detailgenauigkeit und von allen relevanten Parteien enthalten sind, gibt es eine Vielzahl von Methoden und Vorgehensweisen. Nachfolgend sollen nicht alle in Frage kommenden Methoden aufgelistet², sondern vielmehr die im praktischen Beispiel in Abschn. 4 verwendeten Methoden erläutert werden. Ein besonderer Fokus liegt dabei auf den Use Cases, welche in dem Prozess der Anforderungsermittlung inkludiert werden.

Angefangen bei der Auswahl der relevanten Stakeholder kann insbesondere die Stakeholder-Analyse ein geeignetes Mittel sein. Hierbei werden zuerst alle betroffenen Stakeholder identifiziert und dann entsprechend ihrer Stellung und ihres Einflusses im Unternehmen sowie bezüglich ihrer Interessen eingeordnet (Eckert and Trautnitz 2016). Dies kann ebenfalls grafisch erfolgen, indem Einfluss und Interesse auf zwei Koordinatenachsen gezeichnet werden und die jeweiligen Stakeholder dementsprechend im Diagramm eingeordnet werden (Herrmann 2022). Bei großen Projekten, wie dem in Abschn. 4 beschriebenen, eignen sich überdies gesonderte Analysen je nach Organisation.

Ist die Identifikation der relevanten Stakeholder abgeschlossen, so bietet die Methode des Design Thinkings, welche in Abb. 2 dargestellt wird, einen guten Leitfaden für das weitere Vorgehen. Design Thinking führt problemorientiert zu neuen Lösungsansätzen und kann zumindest an vielen Stellen der Anforderungsermittlung eine Unterstützung bieten (Meinel et al 2011).

Im Rahmen der Anforderungsermittlung ist insbesondere wichtig zu verstehen, welche Herausforderungen für welche Prozesse existieren, die folglich eine Chance zur Verbesserung bieten können (Wächter and Bullinger 2016). Dabei sollte nicht nur ein Prozess verstanden werden, sondern die Wünsche und Anforderungen der jeweiligen Stakeholder. Methoden wie Persona-Vorlagen oder User Storys, also Anwendererzählungen, die aus dem agilen Arbeiten entstanden sind und bspw. im Rahmen von SCRUM Verwendung finden, können dazu dienen, den aktuellen Prozess und die Herausforderungen zu verstehen und festzuhalten (Oltersdorff 2016). Abhängig von der Komplexität der jeweiligen zu lösenden Herausforderung können, nach der Aufnahme der Problemstellung, Lösungsideen idealerweise zusammen mit den Stakeholdern gesucht werden. Hierbei können Methoden wie Interviews, Mindmaps, Brainstorming und viele Weitere, ebenfalls Unterstützung bieten (Rupp et al 2009).

Im Anschluss an den Prozess der Ideenfindung ergeben sich Use Cases. Über den Prozess der Anforderungsermittlung und die dazugehörigen Methoden lassen sich funktionale und nicht funktionale Anforderungen gleichermaßen ermitteln (Herrmann 2022). Es ist folglich zu erwarten, dass durch die verschiedenen Stakeholder die gewünschten Funktionen und Soll-Prozesse definiert werden. Zusätzlich ergeben sich allerdings auch technische Anforderungen oder solche, die sich anschließend in technische Anforderungen übertragen lassen. Ein Beispiel wäre, dass ein Stakeholder den aktuellen Standort eines Fahrzeugs sehen möchte. Hierfür müssen technische Anforderungen implementiert werden, wie z. B. das Erfassen und Speichern der Standortinformationen sowie dessen Visualisierung. Diese können bezogen auf die jeweiligen Use Cases gesammelt betrachtet werden und noch um die aktuellen Prozesse und weitere Kriterien erweitert werden, sodass ein ganzheitliches Bild des jeweiligen Use Cases entsteht. Auch Befragungen der Stakeholder zu geschätzten Umsetzungsdauer- oder Kosten sowie die Implikationen des jeweiligen Use Cases können ergänzt werden, sodass ein umfangreiches Lastenheft entsteht. Das Einhalten eines vorgegebenen Reifendrucks als Use Case würde z. B. die Anforderung der Überwachung, aber auch den Prozess des Nachfüllens von Luft umfassen. Es könnten dementsprechend auch Kosten für die Nachrüstung von Reifendrucksensoren und weitere technische Vorbedingungen zum Anzeigen der Drücke im Use Case inkludiert werden.

Die Auswahl der umzusetzenden Use Cases und dementsprechend der relevanten Anforderungen ist insbesondere bei größeren IT-Projekten oder einem großen Lösungsraum, wie dieser in Abb. 2 dargestellt ist, notwendig. Hierfür kann strukturierte Entscheidungsfindung als Unterstützung des Auswahlprozesses dienen (Gerstbach and Gerstbach 2020). Ebenso gewährleistet diese, dass etwaige Unternehmensziele berücksichtigt werden. Überdies kann eine richtige Durchführung ebenfalls das IT-Business-Alignment sicherstellen. Im Rahmen der strukturierte Entscheidungsfindung sind viele Methoden nutzbar, wobei die Zielstellungen variieren.

Die Nutzwertanalyse ist eine bekannte und weit verbreitete Methodik und soll einen rationalen Entscheidungsprozess ermöglichen. Grundvoraussetzung für eine erfolgreiche Durchführung ist, dass die zuvor ermittelten Kriterien des jeweiligen Use Cases bewertbar, relevant, vollständig und reproduzierbar sind (Kühnapfel 2019). Anschließend werden dann die Kriterien gewichtet und bewertet. Sollte im Rahmen der Gewichtung der Kriterien ebenfalls ein strukturiertes Vorgehen erforderlich sein, so können bspw. die Wünsche der Stakeholder und die Unternehmensziele als Teil eines Analytischen Hierarchieprozesses (AHP) betrachtet werden (Saaty 1990). Bei großen Logistik 4.0-Projekten sind viele Kriterien zu berücksichtigen, weshalb insbesondere das strukturierte Vorgehen mittels AHP sinnvoll sein kann (Nimawat and Gidwani 2020).

Die betrachteten strukturierten Entscheidungsverfahren führen zu einem dokumentierbaren und rationalen Auswahlprozess und legen darüber hinaus fest, welche Anforderungen am Ende der Auswahl relevant sind. Zusätzlich ergibt sich eine Reihenfolge der umzusetzenden Use Cases anhand der Wichtigkeit dieser, obgleich etwaige technische Abhängigkeiten durch die Anforderungen zu berücksichtigen sind. Große IT-Projekte im Kontext der Logistik 4.0 sind äußerst umfangreich. Dementsprechend sind sehr viele funktionale- und nicht funktionale Anforderungen zu berücksichtigen. Um ein breiteres Verständnis für diese Prozesse zu erlangen, wird im Folgenden das Forschungsprojekt TwinSim vorgestellt und der durchgeführte Anforderungs- und Auswahlprozess der Use Cases beschrieben.

Zu Beginn der Anforderungsanalyse bzw. Use Case Definition waren insbesondere zwei Fragestellungen zu erörtern. Zum einen mussten der technische Rahmen und die Zielstellung des Forschungsprojekts erörtert werden, welche sich aus den Zielen der Projektpartner und den Fördervorgaben des BMDV ergaben, zum anderen mussten die Stakeholder identifiziert werden, welche anschließend in den Prozess mit einbezogen werden sollten. Für das allgemeine Verständnis, was nachfolgend insbesondere für die Arbeit im Problemraum des Design Thinking Vorgehensmodells wichtig war, wurde das in Abb. 3 dargestellte Schaubild erarbeitet. Ergänzende Folien und weitere Beispiele wurden im Rahmen des ersten Workshops und der Vorstellungen des Projekts verwendet, um möglichst ein tiefes Verständnis bei den Mitarbeitenden und Stakeholdern zu schaffen. Dabei wurden die Funktionen, die bereits bekannten Stakeholder, Erwartungen an das Projekt, Ziele, die übergeordnete Strategie und die Kommunikationswege und -gruppen dargestellt, sodass ein möglichst umfassendes Verständnis entstehen konnte. Da ein frühes Einbeziehen der Stakeholder äußerst wichtig für den Erfolg eines Projekts dieser Größe ist (Neugebauer et al 2022), wurden bereits vorab Vorstellungen des Projekts im Allgemeinen mit allen der Organisation zugehörigen Gruppen durchgeführt. Interessenbekundungen, Bedenken und weitere Anmerkungen halfen unmittelbar bei der anschließenden Stakeholderanalyse. Das in Abschn. 2.3 beschriebene Diagramm wurde für jede Organisation einzeln aufgebaut, wobei am Ende fünf verschiedene Diagramme entstanden. Aufgrund der vielen Mitarbeitenden wurde für die Erstellung der Diagramme die Online-Kollaborationsplattform Miro verwendet (Miro 2022).

Anschließend wurde das weitere Vorgehen abgestimmt und den Stakeholdergruppen wurden das Projekt und die damit verbundenen Möglichkeiten in der beschriebenen Präsentation vorgestellt. Zur Erhebung der Use Cases wurde sich für eine zweistufige Struktur entschieden. Zu Beginn wurde ein Workshop mit den identifizierten Stakeholdern durchgeführt. Bei diesem wurde im Rahmen von moderierten Brainstormingsitzungen in kleineren Gruppen alle Ideen in Mindmaps aufgenommen. Hierbei lag der Fokus insbesondere darauf, keine Ideen zu filtern oder zu früh zu bewerten, da dies möglicherweise den Ideenprozess gehemmt hätte (Putman and Paulus 2009). Während des gesamten Prozesses wurde immer wieder auf die Kernfunktionen des digitalen Zwillings verwiesen, sodass ein geleiteter Brainstormingprozess stattfand. Anschließend kamen die kleinen Gruppen zusammen, sodass ein Austausch über die genannten Problemstellungen im operativen Prozess und die Ideen zur Lösung oder Verbesserung dieser stattfinden konnte.

Um den weiteren Prozess nachvollziehbar zu machen, sollen zwei Ideen vorgestellt werden, die am Ende auch als umzusetzende Use Cases gewählt wurden. Der erste Use Case ist die bereits beschriebene Reifendruck-Überwachung. Aktuell wird das Aufpumpen in fixen Zeitintervallen oder bei Bedarf durchgeführt. Als zweiter Use Case ist die Optimierung der Fahrwege auf dem Containerterminal beschrieben. Hierbei sollen möglichst die Fahrzeiten minimiert und Fahrzeuge sinnvoll eingesetzt werden, sodass die Umschlagsleistung gesteigert werden kann. Aktuell findet die Zuweisung der Fahrzeuge auf dem Containerterminal nur anhand der Distanz zwischen den Fahrzeugen und dem Auftragsstartort statt.

Im Nachgang des Workshops wurden alle Beteiligten gebeten, ein Online-Formular auszufüllen. Dieses enthielt Angaben wie die Bezeichnung der Idee, den Namen des Ideengebenden, eine kurze Beschreibung der jeweiligen Idee und einige weitere Eckdaten wie die betroffenen Bereiche und Systeme. Das Formular stand dabei nicht nur während des Workshops zur Verfügung, sondern konnte noch Wochen danach verwendet werden, sodass später entstehenden Ideen der Stakeholder ebenfalls berücksichtigt werden konnten. Da zeitlich ein schnelles Vorgehen und gleichzeitig eine vollständige Ermittlung der Use Cases und der dazugehörigen Ideen stattfinden sollten, wurde die Identifikation in zwei Phasen durchgeführt.

Zu Beginn wurden der Hauptprojektpartner EUROGATE Technical Services sowie Stakeholder vom EUROGATE Containerterminal Hamburg befragt. Hiervon ausgehend konnten daraufhin bereits die späteren Phasen des Entscheidungsprozesses und der Anforderungsanalyse begonnen werden. In der zweiten Phase wurden dann weitere Stakeholder außerhalb des Projekts befragt. Der Fokus lag dabei auf den weiteren deutschen Containerterminals der EUROGATE-Gruppe in Bremerhaven und Wilhelmshaven. Hierdurch wurde ebenfalls sichergestellt, dass die umgesetzten Use Cases für die gesamte Unternehmensgruppe relevant sind. Das Vorgehen in zwei Phasen ermöglichte außerdem ein agiles Arbeiten und der Prozess konnte zeitlich adaptiert werden.

Die Liste der dokumentierten Use Cases wurde nach der initialen Erfassung durch die Ideengebenden unter Zuhilfenahme der Online-Fragebögen gefiltert. Dabei wurden unter anderem solche Use Cases verworfen, die:Gefilterte Use Cases wurden, wenn möglich, an entsprechende Stellen weitergeleitet oder der Vollständigkeit halber dokumentiert. Ein Beispiel für diese Filterung war die Idee, dass Reifendrücke dem Fahrenden angezeigt werden sollen. Diese Idee wurde im Rahmen der Filter mit der Reifendrucküberwachung zusammengelegt. Das Ergebnis dieses Prozesses war eine Vielzahl von Use Cases und Ideen, mit den zugehörigen Stakeholdern. Diese Use Cases bildeten den Lösungsraum, welcher anschließend Ausgangspunkt der weiteren Schritte war.

Anschließend sind die Anforderungen als zweiter Schritt des Prozesses, welcher in Abb. 4 beschrieben ist, für den jeweiligen Use Case aufgenommen und analysiert worden. Hierfür wurde eine tabellarische Vorlage erarbeitet. Diese enthielt eine erweiterte Beschreibung, die bereits erfassten Informationen, aber auch mögliche Vor- und Nachbedingungen. Zusätzlich enthielt die Vorlage Felder für Ist- und Soll-Prozesse anhand von User Storys, die Häufigkeit des Problems bzw. des Nutzens und den generell erhofften Zustand. Außerdem wurde etwaige Datenfelder für benötigte eingehende und ausgehende Datenverbindungen mit Beschreibungen zu diesen festgehalten. Die jeweiligen Einheiten und die möglicherweise aktuell gegebenen Verwendung wurden ebenfalls erfasst. Weitergehend wurden bereits vorhandene Schnittstellen und Daten sowie möglicherweise zu beachtende gesetzliche Bestimmungen und Anforderungen zur Verfügbarkeit und Kritikalität des jeweiligen Use Cases dokumentiert. Um diesen Prozess möglichst effizient zu gestalten, wurde jeder relevante Stakeholder gebeten, die Vorlage mit so vielen Informationen wie möglich selbstständig zu füllen. Hierfür waren gute und umfassende Erklärungen in der Vorlage enthalten mit Kontaktdaten, falls in diesem ersten Teil bereits Fragen aufkamen. Für die Optimierung der Fahrwege wurden somit im Rahmen des Prozesses die bereits beschriebenen Prozesse, aber auch die erforderlichen Verbindungen zum TOS dokumentiert. Zusätzlich wurde dieser Use Case als sehr kritisch eingestuft, da das operative Geschäft hiervon abhängt. Als Nebenbedingung wurde außerdem festgehalten, dass die aktuell verwendeten Regeln zur Fahrwegoptimierung vorab exportiert werden müssen.

Nachdem die jeweiligen Vorlagen zu den Use Cases ausgefüllt waren, wurden diese bei Bedarf konsolidiert und Einladungen zu Interviews an alle betroffenen Stakeholder versandt. Auf Basis der Vorarbeit der jeweiligen Stakeholder konnten dann durch die Mitarbeitenden der Anforderungsanalyse weitere Nachfragen oder Hilfestellungen gegeben werden. Zum Teil mussten einzelne Passagen zur besseren Verständlichkeit umformuliert werden oder es wurden Informationsbedarfe erfasst, die im Nachgang an die Interviews durch weitere Stakeholder oder anderweitige Recherchen bearbeitet wurden.

Anschließend waren alle gefilterten Use Cases mit den Anforderungen und nötigen Informationen für eine Dokumentation und weitere Verarbeitung gefüllt. Zielstellung der Dokumentation war, dass eine im jeweiligen Bereich nicht versierte Person trotzdem in der Lage ist, die Problemstellung oder Idee und die dazugehörigen Ist- und Soll-Prozesse mit allen Anforderungen zu verstehen. Dies ist insbesondere für die Vielzahl der beteiligten Stakeholder und Unternehmen wichtig, welche aus völlig verschiedenen Themenbereichen an dem Projekt beteiligt sind, damit anschließend eine sinnvolle Bewertung und Auswahl, aber ebenso eine generelle Nachvollziehbarkeit der Arbeit gewährleistet war. Durch die umfangreiche Beschreibung der vielen Prozesse und Ideen wurde die Grundlage für die strukturierte Entscheidungsfindung gelegt.

Auf der Grundlage der gesammelten Use Cases und der Entwicklung eines klaren Problem- und Lösungsraums konnte der strukturierte Entscheidungsprozess für die Auswahl der Use Cases beginnen. Da jedoch alle Anwendungsfälle bereits einen hohen Detaillierungsgrad erforderten, war es nicht das Ziel, nur eine kleine Anzahl von ihnen zu implementieren und die Anderen zu verwerfen, sondern vielmehr zu entscheiden, welche der Anwendungsfälle für die weitere Arbeit im Forschungsprojekt priorisiert werden sollten.

Zu Beginn des Entscheidungsprozesses mussten Kriterien definiert werden, auf deren Basis die entsprechenden Bewertungen und Gewichtungen anschließend getroffen werden konnten. Zusätzlich wurde die Nutzwertanalyse als Bewertungsverfahren aufgrund der guten Verständlichkeit gewählt. Außerdem bietet diese die Möglichkeit, eine Vielzahl von Personen und qualitative sowie quantitative Kriterien zu berücksichtigen (Kühnapfel 2021). Die Definition der Kriterien geschah auf der Grundlage der strategischen Ziele der Projektpartner und in Abhängigkeit von den Zielen des Forschungsprojekts. Folgende neun Kriterien wurden für die Auswahl der Use Cases definiert:Die Beschreibung zur Bedeutung des Use Cases in Bezug auf diese Kriterien durch die Ideengebenden wurde bereits über die Use Case Vorlage sichergestellt und in der dritten Phase bei der Aufnahme der Use Cases beachtet. Darüber hinaus wurde zusätzliche Informationen zu den jeweiligen Kriterien durch die jeweiligen Spezialisten in den Bereichen ergänzt. Dabei wurde bspw. für die Fahrwegoptimierung in nahezu allen Bereichen eine positive Bewertung ausgesprochen, da die Implikation unmittelbar alle Kriterien betrafen. Lediglich die Umsetzungskosten und -dauer wurden eher niedrig bewertet, da die Umsetzung als komplex und umfangreich eingeschätzt wurde. Die Auswahl der bewertenden Personen fand auf Basis der vorab identifizierten Stakeholder statt. Es wurden vier Stakeholdergruppen für die Auswahl identifiziert. Die Gruppen setzten sich aus dem operativen Geschäft, der IT-Abteilung, der Abteilung für die Wartung und Instandhaltung und den operativen Mitarbeitenden aus den Standorten der Containerterminals zusammen. Die bewertenden Personen aus den vier Gruppen wurden anschließend zufällig zu den jeweiligen Use Cases für die Bewertung dieser ausgewählt, sodass keine mathematisch signifikante Beeinflussung oder Abhängigkeit der Bewertung im Rahmen der Nutzwertanalyse möglich war. Die Bewertung als solche wurde anschließend auf Basis einer fünfstufigen Likert-Skala für jeden Use Case durchgeführt. Zusätzlich wurden für die Bewertung Hilfestellungen, Beschreibungstexte und Beispiele gegeben, um ein möglichst einheitliches Verständnis bei den bewertenden Personen zu erzielen. Im Rahmen der Anforderungsanalyse und der Definition der Use Cases wurden zwei Use Cases unabhängig von der Bewertung durch die Stakeholder ausgewählt, die bereits absehbar einen großen Nutzen für das Projekt versprachen. Dies Auswahl fand deshalb statt, da somit ein vorzeitiger Beginn der Arbeiten und ersten Entwicklungen möglich war.

Nach Abschluss aller Bewertungen durch die Stakeholder wurde die Gewichtung der Kriterien zusammen mit den Projektbeteiligten durchgeführt. Die Vorarbeit hierfür war bereits parallel zur Festlegung der Nutzwertanalyse und während des Bewertungsprozesses möglich. Die Gewichtung normiert die Ergebnisse und erlaubt ebenfalls eine Einflussnahme auf die Relevanz der definierten Kriterien. Um die Gewichtung sinnvoll festlegen zu können, wurden die Projektbeteiligten gebeten, mittels des AHP eine Rangfolge zwischen den Kriterien zu definieren. Hieraus ergaben sich prozentuale Werte für die Wichtigkeit der jeweiligen Kriterien aus Sicht der jeweiligen Stakeholder. Diese prozentualen Werte aus den Ergebnissen des AHP-Vorgehens wurden anschließend in einem gesonderten Workshop mit allen Beteiligten diskutiert und es wurde sich gemeinschaftlich auf eine einheitliche Gewichtung der Kriterien geeinigt. Dabei wurden unter anderem die Prozessverbesserung und die Kriterien der Skalier- und Erweiterbarkeit relativ stark gewichtet, sodass deren Bewertungen am meisten Einfluss hatte.

Auf Basis der Bewertungen der Stakeholder wurde schlussendlich je Kriterium der Mittelwert gebildet, welcher anschließend mit dem Prozentsatz der definierten Gewichtung multipliziert wurde. Hiermit konnte die finale Bewertung berechnet werden, die die vorläufige Priorisierung festlegte. Auf Basis der 25 bestbewerteten Use Cases wurde eine Abstimmung mit allen Projektbeteiligten angestoßen und im nächsten Schritt mit der finalen Entscheidungsfindung begonnen.

Durch die Priorisierung und Bewertung der Use Cases anhand der Kriterien konnte eine vorläufige Auswahl der relevantesten Use Cases getroffen werden. Unter den vorausgewählten Use Cases waren auch die zum Reifendruck und der Fahrwegoptimierung. Im Rahmen dieses Prozesses konnte jedoch nicht berücksichtigt werden, welche Abhängigkeiten insbesondere technischer Natur möglicherweise bei der Umsetzung der Use Cases bestehen könnten. Hierfür wurden von den 25 bestbewerteten Use Cases die jeweiligen technische Grundbedingungen durch die IT-Abteilung und von anderen technischen Abteilungen bewertet. Diese Grundbedingungen, bspw. definiert durch Datenprozessoren, müssen technisch umgesetzt werden, um eine Funktionsfähigkeit der jeweiligen Use Cases zu erzielen. Beispiele für die beschriebenen Prozessoren können Zeitdienste, Optimierungsprozessoren oder Schnittstellen zur Wartung sein. Die Liste der Prozessoren wurde anhand der 25 priorisierten Use Cases zusammengeführt, sodass über die Anzahl der Prozessoren je Use Case die ungefähre technische Komplexität ersichtlich war. Die technische Komplexität ist für die Reifendrucküberwachung mittel und eher hoch in Bezug auf die Fahrwegoptimierung, da diese viele Optimierungsprozessoren und Schnittstellen benötigt. Insbesondere für das technisch geprägte Projektziel, den Aufbau eines digitalen Zwillings, ist die technische Komplexität von großer Bedeutung. Ein exemplarischer Aufbau dieser technischen Übersicht kann Tab. 1 entnommen werden.

Zusätzlich zur absoluten Anzahl der Prozessoren je Use Case wurde ermittelt, wie viele zusätzliche Prozessoren je Use Case erarbeitet werden müssen, wenn bereits die beiden priorisierten Use Cases umgesetzt worden sind.⁵ Dies war ein Maß für den zusätzlichen Aufwand und um technische Synergieeffekte zu identifizieren.

Um die Abstimmung der Projektpartner und die finale Auswahl vorzubereiten, wurde ein Workshop mit den Projektbeteiligten durchgeführt. Im Rahmen des Workshops wurden die jeweiligen Minimalziele der Projektpartner festgehalten. Auf Basis der Minimalziele und unter Berücksichtigung der technischen Komplexität wurden alle Use Cases durch die Stakeholder erneut geprüft. Daraus resultierend wurden durch die Stakeholder die Use Cases ausgewählt, die umgesetzt werden sollen. Hierbei handelte es sich um insgesamt 14 Use Cases. Alle Use Cases wurden entsprechend des Beispiels in Abb. 5 dargestellt.

Mit den abschließend durch die Ziele und Abhängigkeiten gewählten Use Cases entstand eine Priorisierung in vier Stufen. Da Abhängigkeiten zwischen den Use Cases bestehen, also ein Use Case nicht vor dem Fertigstellen eines Anderen umgesetzt werden kann, ergeben sich logische Gruppierungen und Reihenfolgen. Überdies sind bestimmte Use Cases einfacher umsetzbar oder haben einen größeren Nutzen als andere Use Cases. So kann bspw. der Use Case zur Überwachung des Reifendrucks erst umgesetzt werden, wenn die entsprechenden Datenschnittstellen aus einem anderen Use Case fertiggestellt sind. Mit diesen Informationen wurde die finale Umsetzungsreihenfolge mit allen beteiligten Projektpartnern festgelegt.

Der zweite Workshop, welcher als vorletzter Schritt in Abb. 4 dargestellt ist, wurde mit allen Stakeholdern durchgeführt, um die finale Auswahl darzulegen und etwaige Bedenken oder mögliches Feedback zu berücksichtigen. Die Use Cases benötigten zum Teil noch zusätzliche Informationen für ihre spätere Umsetzung. Diese Informationen wurden anschließend durch die Stakeholder in Zusammenarbeit mit Experten der jeweiligen inhaltlichen Fachbereiche weitergehend ergänzt.