Ereignisgetrieben arbeiten: warum Prozesse auf Ereignisse hören sollten statt auf Termine
In den meisten Betrieben laufen Prozesse nach Kalender: Montag Planungsrunde, Dienstag Produktionsbesprechung, Freitag Kennzahlen. Das ist kein Prozessdesign, sondern eine Krücke. Man trifft sich regelmäßig, weil man nicht erfährt, wann etwas passiert.
Terminbasierte Abläufe sind eine Krücke für fehlende Signale: Eine Materialverzögerung vom Mittwoch kostet bis zur Montagsrunde fünf Tage Reaktionszeit. Ereignisgetrieben heißt, dass Systeme Tatsachen mit Zeitpunkt veröffentlichen und andere darauf reagieren. Entscheidend ist die Anreicherung über Systemgrenzen, denn erst der Zusammenhang macht aus einer Meldung eine Entscheidungsgrundlage. Starten Sie mit drei Ereignistypen.
Was ein Ereignis ist
Ein Ereignis ist eine Tatsache mit Zeitpunkt: Auftrag freigegeben, Material verspätet gemeldet, Maschine gestört, Angebot versendet, Reklamation eröffnet. Ereignisgetriebene Architektur bedeutet, dass Systeme diese Tatsachen veröffentlichen und andere darauf reagieren können, ohne dass jemand nachfragt.
Der Unterschied zum Terminmodell ist die Latenz. Wenn eine Materialverzögerung am Mittwoch bekannt wird und die Planungsrunde am Montag ist, verliert der Betrieb fünf Tage Reaktionszeit für eine Information, die längst im System stand.
Was sich praktisch ändert
- Der Planer erfährt von einem Konflikt, wenn er entsteht, nicht wenn die Linie steht.
- Der Vertrieb sieht die Lieferverschiebung, bevor der Kunde anruft.
- Die Qualitätssicherung bekommt Häufungen gemeldet, statt sie im Monatsbericht zu entdecken.
- Besprechungen werden kürzer, weil sie nicht mehr dem Informationsabgleich dienen.
Warum das ohne Verbindungsschicht nicht geht
Ereignisse entstehen in verschiedenen Systemen und bedeuten erst im Zusammenhang etwas. „Charge X verspätet" ist eine Nachricht. „Charge X verspätet, betrifft Auftrag 4711, dessen Liefertermin in vier Tagen liegt, Kunde hat Vertragsstrafe" ist eine Entscheidungsgrundlage. Die Anreicherung ist die eigentliche Arbeit, und sie braucht Zugriff über Systemgrenzen.
Der Einstieg ohne Umbau
Sie müssen nicht Ihre Systemlandschaft umbauen. Beginnen Sie mit drei Ereignistypen, die heute regelmäßig zu spät ankommen, und lassen Sie diese anreichern und zustellen — in den Kanal, in dem die Leute ohnehin arbeiten. Alles Weitere ergibt sich aus den Fragen, die dann gestellt werden.
Häufige Fragen
Müssen wir dafür unsere Systeme umbauen?
Nein. Die meisten Systeme melden Zustandsänderungen bereits oder lassen sich regelmäßig abfragen. Der Aufwand liegt nicht im Umbau, sondern in der Anreicherung: einer Meldung den Auftrag, den Kunden, den Termin und die Folgen beizustellen, damit ein Mensch entscheiden kann statt erst zu recherchieren.
Werden Mitarbeitende dann mit Meldungen überflutet?
Nur bei schlechtem Zuschnitt. Zwei Regeln verhindern das: Es wird nur gemeldet, was eine Entscheidung erfordert, und jede Meldung geht an genau eine zuständige Person oder Rolle. Meldungen ohne Handlungsoption gehören in einen Bericht, nicht in einen Kanal.
Welche Ereignisse eignen sich für den Anfang?
Die, die heute regelmäßig zu spät ankommen und teuer sind: Materialverzug, Maschinenstörung mit Auftragsbezug, Terminverschiebung mit Kundenwirkung. Drei Typen genügen für den Einstieg und zeigen schnell, ob Zuschnitt und Zustellweg stimmen.
Ersetzt das unsere Besprechungen?
Es ersetzt den Teil, der reiner Informationsabgleich ist, und das ist erfahrungsgemäß der größere. Was bleibt, sind Entscheidungen und Abstimmungen, für die Menschen zusammenkommen sollten. Kürzere Runden mit besserer Vorbereitung sind das übliche Ergebnis.
Wie schnell erfahren Sie von Konflikten?
Der Rechner zeigt, was Planungskonflikte Sie heute kosten.
Rechner starten →
