Wo Prozesse reißen: Schnittstellen, Auslöser und Übergaben

Bitte die HR-Abteilung, ihren Onboarding-Prozess zu beschreiben. Du erhältst eine saubere Liste: Vertrag erstellen, Unterschrift einholen, Person im HR-System anlegen, Unterlagen anfordern, Willkommensmail schicken. Fragst du die IT nach ihrem Teil, bekommst du eine ebenso saubere Liste: Hardware bestellen, Gerät einrichten, Benutzerkonto anlegen, Berechtigungen vergeben.

Beide Listen sind vollständig. Beide Abteilungen arbeiten zuverlässig ab, was auf ihrer Liste steht. Und trotzdem sitzt die Hälfte der neuen Mitarbeitenden am ersten Tag ohne Laptop da.

Das Problem steht auf keiner der beiden Listen. Es liegt dazwischen, in dem Moment, in dem HR der IT Bescheid sagen müsste.

Drei Arten von Bruchstellen

In meinen Process Cards finde ich Schnittstellenprobleme in drei Formen.

Der fehlende Auslöser. Ein Ereignis in einer Abteilung müsste eine Aktivität in einer anderen starten, tut es aber nicht systematisch. Beim Onboarding ist die Vertragsunterschrift das Ereignis. Sie passiert bei HR. Die IT erfährt davon per E-Mail, wenn jemand daran denkt, und oft erst wenige Tage vor dem Starttermin.

Die unklare Übergabe. Ein Vorgang wechselt die Abteilung, aber es ist offen, was genau übergeben wird und wann die Übergabe abgeschlossen ist. Bei der Reklamation leitet der Service den Fall an die Qualität weiter. Ob die Qualität ihn angenommen hat, ob ihr alle Informationen vorliegen und wer jetzt den Kunden informiert, bleibt unklar.

Die Vorlaufzeit, die nicht passt. Eine Abteilung braucht mehr Zeit, als ihr der vorgelagerte Schritt lässt. Die Lieferzeit für einen Laptop beträgt zwei Wochen. Die IT erfährt fünf Tage vor dem Start von der neuen Person. Selbst wenn alle Beteiligten sofort handeln, geht die Rechnung nicht auf.

Warum Abteilungssicht diese Probleme verbirgt

Klassische Prozessdokumentation ist oft nach Abteilungen organisiert. Jede Abteilung beschreibt ihren Teil, und am Ende steckt jemand die Teile zusammen. Die Schnittstellen erscheinen in diesem Modell als Pfeile zwischen Kästchen. Ein Pfeil sieht immer so aus, als würde er funktionieren.

Progressive BPM beginnt deshalb beim Symptom, das ein Mensch am Ende des Prozesses erlebt. Die neue Mitarbeiterin ohne Laptop. Der Kunde, der seinen Fall zum dritten Mal erklärt. Die Rechnung, die keiner Bestellung zugeordnet werden kann. Wer vom Symptom rückwärts geht, landet fast zwangsläufig an der Schnittstelle, an der es entsteht.

Fristen relativ zum Zielereignis

Eine einfache Technik hat sich bei Schnittstellenproblemen bewährt: Alle Aufgaben bekommen eine Frist relativ zu einem gemeinsamen Zielereignis.

Beim Onboarding ist das Zielereignis der erste Arbeitstag, Tag 1. Daraus ergibt sich eine Checkliste mit festen Zeitpunkten:

• T-14: IT bestellt Hardware oder reserviert ein Gerät aus dem Puffer.
• T-5: IT legt Benutzerkonto und Standardberechtigungen an. Die Führungskraft plant die erste Woche.
• T-1: Gerät ist eingerichtet, Arbeitsplatz vorbereitet, Pate oder Patin informiert.
• Tag 1: Begrüßung, Übergabe von Gerät und Zugängen.
• Woche 1: Erstes Feedbackgespräch.

Diese Darstellung hat einen Vorteil gegenüber einem Ablaufdiagramm. Jede Abteilung sieht sofort, wann sie dran ist, und alle sehen, dass T-14 nur funktioniert, wenn die Vertragsunterschrift spätestens 15 Tage vor dem Start bei der IT ankommt. Die Vorlaufzeit wird zu einer gemeinsamen Anforderung statt zu einem Problem der IT.

Den Auslöser automatisieren

Die Checkliste ist die Sofortmaßnahme. Die mittelfristige Lösung beseitigt den fehlenden Auslöser: Die Vertragsunterschrift erzeugt automatisch Aufgaben bei IT, Facility und Führungskraft.

Dafür braucht es nicht zwingend ein großes System. Viele HR-Systeme können bei einem Statuswechsel eine E-Mail an einen Verteiler senden oder ein Ticket im IT-Servicedesk anlegen. Diese Funktion ist oft vorhanden und nur nicht eingerichtet. Wo sie fehlt, reicht ein Formular, das HR bei Vertragsunterschrift ausfüllt und das an einer festen Stelle landet.

Wichtig ist, dass der Auslöser nicht von der Erinnerung einer einzelnen Person abhängt. Solange jemand daran denken muss, die IT zu informieren, wird es irgendwann vergessen. Ein Auslöser, der an ein Ereignis gekoppelt ist, vergisst nichts.

Puffer gegen Vorlaufzeiten

Manchmal lässt sich die Vorlaufzeit nicht verlängern. Kurzfristige Einstellungen gehören zum Alltag. Dann hilft ein Puffer.

Die IT hält eine kleine Zahl an Standardgeräten vorrätig, bei zehn Einstellungen im Monat vielleicht drei oder vier. Wenn eine Einstellung kurzfristig kommt, nimmt die IT ein Gerät aus dem Puffer und bestellt Ersatz nach. Das bindet etwas Kapital, kostet aber weniger als ein neuer Mitarbeiter, der eine Woche lang nicht arbeiten kann.

Dasselbe Prinzip funktioniert an anderen Schnittstellen. Rollenbasierte Berechtigungsprofile sind ein Puffer für Zugänge: Statt jede Berechtigung einzeln zu beantragen, wählt die Führungskraft ein Profil, und alle Zugänge entstehen auf einmal. Die strukturelle Lösung auf meiner Onboarding-Card sieht genau das vor.

Übergaben mit Quittung

Bei unklaren Übergaben hilft eine einfache Regel: Eine Übergabe ist erst abgeschlossen, wenn die empfangende Seite sie bestätigt hat. Bis dahin bleibt der Vorgang bei der abgebenden Seite.

Im Reklamationsprozess lässt sich diese Regel noch weiter treiben. Mit einem Case Owner gibt es gar keine Übergabe mehr. Der Fall bleibt bei einer Person, und die anderen Abteilungen liefern ihr zu. Die Schnittstelle verwandelt sich in eine Anfrage mit Antwort. Diese Form ist leichter zu steuern, weil klar ist, wer auf wen wartet.

Schnittstellen über das Ereignis hinaus

Eine Stolperfalle notiere ich auf der Onboarding-Card ausdrücklich: Onboarding endet nicht am ersten Tag. Die Wochen zwei bis zwölf fehlen in den meisten Plänen. In dieser Zeit entscheidet sich, ob neue Mitarbeitende bleiben. Die Schnittstelle zwischen HR und Fachbereich zieht sich über Monate, nicht über einen Tag.

Die Card sieht deshalb Feedbackgespräche nach 30 und 90 Tagen als feste Messpunkte vor. Sie sind die zweite Hälfte des Prozesses, die in vielen Organisationen niemandem gehört.

Woran du Schnittstellenprobleme erkennst

Drei Signale weisen fast immer auf eine Bruchstelle hin:

• Die Betroffenen am Ende des Prozesses beschweren sich, aber jede beteiligte Abteilung hält ihren eigenen Teil für erledigt.
• Wichtige Informationen fließen per E-Mail oder Zuruf zwischen Abteilungen.
• Auf die Frage „Wo steht der Vorgang gerade?“ kann niemand sofort antworten.

Wenn du zwei dieser drei Signale siehst, lohnt es sich, eine Process Card mit Fokus auf die Schnittstelle zu schreiben. Die Lösung ist oft überraschend klein: ein Auslöser, eine Frist, eine Quittung.