UML-Onboarding, BPM und Wissensmanagement

Projektübersicht

Die Hausarbeit modelliert das Mitarbeiter-Onboarding einer mittelgroßen IT-Firma als UML-Aktivitätsdiagramm nach UML 2.5.1. Das Gesamtmodell umfasst fünf Phasen und sieben beteiligte Rollen. Neben der Reihenfolge werden Entscheidungen, Rückschleifen, parallele Vorbereitungen und dokumentierte Übergaben sichtbar.

Ausgangssituation

Beim Onboarding greifen Geschäftsführung, Personalabteilung, Fachabteilung, IT, Facility Management, Datenschutz beziehungsweise Compliance und der neue Mitarbeiter ineinander. Ohne klaren Soll-Prozess können Zugänge, Arbeitsmittel, Unterlagen oder Einweisungen unvollständig bleiben.

Ziel des Projekts

Ziel war eine Darstellung, in der jede Rolle Aufgaben, Übergaben und Kontrollpunkte ohne zusätzliche mündliche Erklärung erkennen kann. Der Prozess beginnt nach dem unterschriebenen Vertrag und endet erst nach fachlicher Bewertung, persönlichem Feedback und aktualisierter Dokumentation.

Fachliche Planung

Die Aufgabenstellung wurde zunächst abgegrenzt und anschließend in fünf Phasen zerlegt: Vertragsprüfung, Vorbereitung, erster Arbeitstag, Einarbeitung und Abschluss. Jede Aktivität wurde genau einer Rolle zugeordnet.

• Initial Node und Activity Final Node für eindeutige Prozessgrenzen
• Decision und Merge für Prüfung und Korrekturschleifen
• Fork und Join für parallele Vorbereitungen
• Guard Conditions mit klaren Bedingungen wie [ja] und [nein]
• Activity Partitions für Verantwortlichkeiten und Schnittstellen

Werkzeuge und fachliche Grundlagen

Notation

UML-Aktivitätsdiagramm nach UML 2.5.1

Werkzeug

diagrams.net / draw.io

Dokumentation

strukturierte Hausarbeit und PDF

Ausgabe

bearbeitbare .drawio-Datei sowie Grafikexporte

Umsetzung

Nach der Vertragsprüfung starten mehrere Vorbereitungen parallel: Personalunterlagen, Einarbeitung, IT-Zugänge, Arbeitsplatz, Datenschutz- und Sicherheitsunterlagen. Erst ein Join führt den Ablauf weiter, wenn die notwendigen Zweige abgeschlossen sind. Am ersten Arbeitstag folgen Übergaben, Systemtest und Einweisungen; danach Einarbeitung, Zielprüfung und Abschlussdokumentation.

Prozessarchitektur

Das Modell beschreibt einen Soll-Prozess. Recruiting, laufende Entgeltabrechnung, Kündigung und Offboarding sind bewusst nicht enthalten.

Herausforderungen

Die anspruchsvollsten Punkte waren die korrekte Semantik der UML-Knoten, die Trennung von parallelen und alternativen Pfaden sowie die Frage, an welcher Stelle ein Prozessschritt wirklich abgeschlossen ist. Zusätzlich mussten große Diagramme so aufgeteilt werden, dass Gesamtübersicht und Detailansichten zusammenpassen.

Prüfung der Prozesslogik

Geprüft wurden Start und Ende, jede Rollenübergabe, Guard Conditions, Rückwege, Fork-/Join-Paare und mögliche Sackgassen. Decision und Merge wurden bewusst getrennt: Eine Entscheidung verteilt alternative Wege, ein Merge führt sie ohne Synchronisation wieder zusammen.

Umgesetzte Lösungen

• Sieben Swimlanes trennen Rollen und Verantwortlichkeiten.
• Fehlende Unterlagen führen über einen Merge zurück zur erneuten Prüfung.
• Parallele Vorbereitung wird mit Fork und Join korrekt synchronisiert.
• Systemtest und Rückmeldungen prüfen die praktische Nutzbarkeit.
• Fachliche Bewertung, Feedback und Personalakte schließen den Ablauf dokumentiert ab.

Datenschutz und Verantwortung

Das Modell behandelt Personaldaten, Zugriffsrechte und Verpflichtungserklärungen nur auf konzeptioneller Ebene. Es enthält keine realen Mitarbeiterdaten. Bei einer produktiven Umsetzung wären Datenminimierung, Rollenrechte, Protokollierung, Aufbewahrungsfristen und Zugriffsschutz verbindlich zu regeln.

Ergebnis

Entstanden sind eine formal aufgebaute Hausarbeit, ein vollständiges Gesamtmodell, vergrößerte Detailansichten und eine bearbeitbare draw.io-Datei. Der Ablauf macht sichtbar, wie organisatorische Verantwortung, IT-Bereitstellung und dokumentiertes Wissen zusammenwirken.

Wichtigste Lernerfahrungen

Eine Prozessgrafik ist nur dann belastbar, wenn die Semantik stimmt. Rollen, Entscheidungen und Parallelität dürfen nicht nur optisch angedeutet werden. Gute Dokumentation erklärt außerdem Annahmen und Grenzen, damit das Modell nicht mehr verspricht, als es tatsächlich abbildet.

Aktueller Status

Die Fallstudie ist als schulische Hausarbeit und UML-Modell abgeschlossen. Sie ist keine produktive Personalsoftware und wird im Portfolio nur in zusammengefasster, datensparsamer Form beschrieben.

Mögliche zukünftige Verbesserungen

Eine nächste Version könnte Eskalationen, Fristen, Rollenrechte, messbare Serviceziele und Sonderfälle ergänzen. Für eine Softwareumsetzung wären außerdem Datenmodell, Authentifizierung, Audit-Log und ein abgestimmtes Berechtigungskonzept nötig.

Zur Projektübersicht