Lebensereignisbasiertes Behördendesign: Verwaltung neu gedacht

Eine junge Mutter in Berlin bekommt ihr erstes Kind. Innerhalb von sechs Wochen muss sie die Geburt beim Standesamt anmelden, Elterngeld beantragen, die Kindergeldnummer beim Familienkasse einholen, die Krankenkasse informieren, einen Kita-Platz suchen und – falls sie selbstständig ist – ihre Steuervorauszahlungen anpassen. Sechs Behörden, sechs Formulare, sechs Logins, sechs verschiedene Auffassungen davon, was "Geburtsurkunde" eigentlich bedeutet. Kein einziges System weiß, dass sie gerade Mutter geworden ist – obwohl jedes einzelne davon genau diese Information verlangt.

Das ist keine schlecht digitalisierte Verwaltung. Das ist eine Verwaltung, die konsequent nach Zuständigkeit statt nach Lebenswirklichkeit gebaut wurde. Lebensereignisbasiertes Behördendesign dreht dieses Prinzip um: Es organisiert Dienstleistungen nicht entlang von Ressorts, sondern entlang der Momente, in denen Menschen sie tatsächlich brauchen – Geburt, Heirat, Jobverlust, Umzug, Pflegefall, Tod eines Angehörigen. Wer das ernst nimmt, baut nicht mehr zwanzig Formulare, sondern einen Vorgang.

Was bedeutet lebensereignisbasiertes Behördendesign konkret?

Lebensereignisbasiertes Behördendesign bündelt alle Verwaltungsschritte, die zu einem einzigen Ereignis im Leben eines Menschen gehören – etwa "Ich werde Elternteil" oder "Ich verliere meinen Job" – zu einem zusammenhängenden Dienst, unabhängig davon, wie viele Ämter, Kassen oder Register im Hintergrund beteiligt sind. Die Bürgerin erlebt einen Vorgang mit einem Formular, einer Statusanzeige und einem Ansprechpunkt; die Ämter tauschen die Daten intern aus, statt sie der Bürgerin abzuverlangen.

Der Gegenentwurf ist die klassische ressortbasierte Struktur, die Verwaltungen historisch aus guten Gründen entwickelt haben: klare Zuständigkeiten, klare Haushaltslinien, klare Rechtsgrundlagen. Nur folgt kein Lebensereignis dieser Logik. Eine Geburt betrifft Standesamt, Finanzamt, Familienkasse, Krankenkasse und Kommune gleichzeitig – und die Bürgerin soll sich nicht als Übersetzerin zwischen diesen Systemen betätigen müssen.

Warum scheitert die ressortbasierte Verwaltung an echten Lebensereignissen?

Weil sie die Reibung systematisch beim Bürger abladet statt bei sich selbst. Der Verhaltensökonom Cass Sunstein hat für genau dieses Phänomen den Begriff der "Sludge" geprägt – administrative Reibung, die keinen Zweck erfüllt außer, Menschen von einer Handlung abzuhalten oder ihnen unnötigen Aufwand aufzubürden. In seinem Buch "Sludge: What Stops Us from Getting Things Done and What to Do about It" (MIT Press, 2021) beschreibt Sunstein, wie Formulare, Wartezeiten und mehrfache Dateneingaben Bürgerinnen und Bürger von Leistungen abhalten, auf die sie eigentlich Anspruch haben.

Jedes Formular, das eine Behörde erneut ausfüllen lässt, was eine andere Behörde bereits weiß, ist Sludge. Jede Anforderung, eine Geburtsurkunde dreimal in Papierform vorzulegen, ist Sludge. Das Problem ist nicht Bösartigkeit, sondern Trägheit: Systeme, die getrennt beschafft, getrennt budgetiert und getrennt gewartet werden, bleiben getrennt – bis jemand bewusst gegensteuert.

Ressortbasierte Strukturen verstärken zusätzlich einen zweiten Effekt: den Status-quo-Bias. Wenn niemand explizit dafür verantwortlich ist, den Übergang zwischen zwei Ämtern zu gestalten, bleibt er unbearbeitet – nicht aus Absicht, sondern weil Verantwortung dort endet, wo das Organigramm endet. Genau an diesen Schnittstellen, nicht innerhalb der einzelnen Ämter, entstehen die schlechtesten Erlebnisse in der öffentlichen Verwaltung.

Welche Länder haben lebensereignisbasierte Dienste bereits umgesetzt?

Das Konzept ist keine Theorie mehr. Mehrere Verwaltungen haben es in produktive Dienste übersetzt, mit unterschiedlichem Reifegrad:

• Dänemark organisiert sein Bürgerportal borger.dk explizit nach "livssituationer" (Lebenssituationen) – Geburt, Scheidung, Todesfall, Pflege – statt nach Behördennamen. Bürgerinnen suchen nicht "Finanzamt", sondern "Ich habe ein Kind bekommen".
• Estland hat mit seiner X-Road-Infrastruktur das "Once-Only"-Prinzip technisch durchgesetzt: Ein Datum, einmal erfasst, wird nicht erneut abgefragt. Register kommunizieren untereinander, statt den Bürger als Datenkurier einzusetzen.
• Neuseeland bietet mit SmartStart einen Dienst rund um "Ich bekomme ein Baby", der Geburtsanmeldung, Steuerinformationen und Familienleistungen in einem einzigen Vorgang zusammenführt, getragen von Inland Revenue und dem Department of Internal Affairs.
• Australien hat sein Bürgerportal myGov um eine "Life Events"-Navigation erweitert, die Nutzer anhand ihrer Situation statt anhand von Behördennamen zu Leistungen führt.
• Großbritannien strukturiert die Startseite von GOV.UK seit der Umstellung durch den Government Digital Service konsequent nach Themen und Situationen der Nutzer, nicht nach Ministerien.

Die Gemeinsamkeit dieser Beispiele ist nicht die Technik. Estland und Dänemark, Neuseeland und Großbritannien haben völlig unterschiedliche IT-Landschaften. Die Gemeinsamkeit ist eine organisatorische Entscheidung: Jemand hat die Verantwortung für den Übergang zwischen Ämtern explizit einer Stelle zugewiesen, statt sie implizit niemandem zu geben.

Welche Verhaltensökonomie steckt hinter lebensereignisbasierten Diensten?

Zwei Mechanismen erklären, warum dieser Ansatz messbar wirkt, nicht nur besser aussieht.

Der erste ist die bereits erwähnte Reduktion von Sludge durch Defaults und Choice Architecture: Wenn die Geburtsanmeldung automatisch das Kindergeld auslöst, statt einen zusätzlichen Antrag zu verlangen, wird die gewünschte Handlung zur Voreinstellung statt zur Zusatzaufgabe. Das ist derselbe Mechanismus, der bei betrieblicher Altersvorsorge Opt-out-Modelle wirksamer macht als Opt-in-Modelle – nur angewendet auf Verwaltungsprozesse statt auf Finanzprodukte.

Der zweite ist die Peak-End-Rule von Daniel Kahneman: Menschen erinnern sich an eine Erfahrung überproportional stark anhand ihres emotionalen Höhepunkts und ihres Endpunkts, nicht anhand des Durchschnitts jedes einzelnen Schritts. Ein Trauerfall, bei dem die Bürgerin am Ende noch drei weitere Ämter kontaktieren muss, hinterlässt einen anderen Eindruck als einer, bei dem der letzte Kontakt mit der Verwaltung eine klare Bestätigung ist: "Alles ist erledigt." Lebensereignisbasiertes Design gestaltet bewusst diesen Endpunkt – nicht nur den ersten Formularschritt, der in klassischen Projekten meist die meiste Aufmerksamkeit bekommt.

Beide Mechanismen zusammen erklären, warum ein Lebensereignis-Dienst sich nicht wie eine kosmetische Umbenennung von Formularen anfühlt, sondern wie eine andere Beziehung zwischen Bürger und Staat. Wer das Prinzip aus der Nähe verstehen will, findet die zugrunde liegende Journey-Logik in unserem Beitrag zu Journey Mapping versus Service Blueprinting – beide Techniken sind das Handwerkszeug, mit dem man ein Lebensereignis in einen zusammenhängenden Dienst übersetzt.

Wie baut man einen lebensereignisbasierten Dienst in der Praxis auf?

Ich habe diesen Übergang in mehreren Verwaltungsprojekten begleitet, und die Reihenfolge entscheidet über Erfolg oder Stillstand. Wer mit der IT-Integration beginnt, statt mit der Journey, baut ein schnelleres System für einen kaputten Prozess.

1. Das Lebensereignis auswählen und eng abgrenzen. "Ich werde Elternteil" ist ein Ereignis. "Familienangelegenheiten" ist ein Ressort. Je enger die Abgrenzung, desto klarer lässt sich der End-Zustand definieren, an dem die Bürgerin sagen kann: "Fertig."
2. Die tatsächliche Journey der Bürgerin kartieren, nicht die interne Prozesslandkarte. Das bedeutet, mit echten Nutzerinnen zu sprechen, jeden Kontaktpunkt über alle beteiligten Ämter hinweg zu erfassen und jede Stelle zu markieren, an der die Bürgerin dieselbe Information zweimal liefern muss.
3. Die beteiligten Ämter und Register identifizieren – und wer welches Datum bereits besitzt. In den meisten Fällen liegt die Mehrheit der benötigten Daten bereits irgendwo im System. Das eigentliche Projekt ist selten neue Daten zu erheben, sondern vorhandene Daten sichtbar und übertragbar zu machen.
4. Eine verantwortliche Prozesseignerin für das gesamte Ereignis benennen – über Ressortgrenzen hinweg. Ohne diese Rolle fällt jedes Projekt zurück in Silodenken, sobald der erste Konflikt über Budget oder Priorität auftritt.
5. Einen einzigen Einstiegspunkt und einen einzigen Statusstand für die Bürgerin bauen, auch wenn im Hintergrund mehrere Systeme weiterarbeiten. Die Komplexität darf bleiben – sie darf nur nicht mehr sichtbar sein.
6. Mit einem Pilotkohorte in einer Region oder Kommune testen, bevor landesweit ausgerollt wird. Lebensereignisse betreffen reale Menschen in echten Krisensituationen; ein Fehlstart bei einem Trauerfall-Dienst kostet mehr Vertrauen als ein verzögerter Rollout.
7. Die emotionale Belastung des Ereignisses in der Tonalität berücksichtigen. Eine Geburtsanzeige verdient eine andere Sprache als eine Sterbefallmeldung. Prozessdesign ohne diese Differenzierung wirkt kalt, selbst wenn die Technik einwandfrei funktioniert.

Diese Reihenfolge folgt derselben Logik, die wir bei CX Implementation Roadmaps anwenden: Erst die Journey verstehen und priorisieren, dann die Systemarchitektur daran ausrichten – nicht umgekehrt.

Welche Fallstricke zerstören lebensereignisbasierte Projekte in der Praxis?

Die meisten Projekte scheitern nicht an der Technik, sondern an vorhersehbaren organisatorischen Fehlern:

• Das Ereignis wird zu breit definiert. "Digitalisierung der Familienleistungen" ist ein Programm, kein Lebensereignis. Ohne engen Zuschnitt verliert das Projekt seinen Fokus und seine messbare Wirkung.
• Die Verantwortung bleibt bei den einzelnen Ämtern statt bei einer ereignisübergreifenden Rolle. Dann optimiert jedes Amt weiterhin seinen eigenen Teil – und die Übergänge, wo die echte Reibung entsteht, bleiben unbetreut.
• Rechtsgrundlagen werden erst am Ende geprüft. Datenschutzrecht und Zweckbindung bestimmen häufig, welche Register überhaupt Daten austauschen dürfen. Wer das erst nach dem Prototyp klärt, baut ein System, das rechtlich nicht betrieben werden darf.
• Die Offline-Realität wird ignoriert. Nicht jede Bürgerin, die ein Kind bekommt oder einen Angehörigen verliert, hat digitale Kompetenz oder Zugang in diesem Moment. Ein Lebensereignis-Dienst braucht einen gleichwertigen analogen Pfad, sonst verschärft er Ungleichheit statt sie zu verringern.
• Erfolg wird an technischer Fertigstellung gemessen, nicht an Bürgerergebnissen. "Das Portal ist live" ist kein Ziel. "90 Prozent der Eltern erhalten ihr Kindergeld ohne separaten Antrag" ist eines.

Der letzte Punkt verdient eine eigene Einordnung, denn er entscheidet, ob ein Projekt nach dem Launch weiterlebt oder als Referenzfolie in der nächsten Verwaltungsstrategie verstaubt.

Wie misst man den Erfolg lebensereignisbasierter Dienste?

Klassische Verwaltungskennzahlen – Bearbeitungszeit pro Antrag, Anzahl bearbeiteter Fälle – messen die falsche Einheit. Sie messen die Leistung des Amtes, nicht die Erfahrung des Ereignisses. Wer lebensereignisbasiert denkt, misst auf Ebene des gesamten Vorgangs:

• End-to-End-Durchlaufzeit des Ereignisses – von der ersten Meldung bis zur letzten Bestätigung, über alle beteiligten Ämter hinweg.
• Anzahl der Dateneingaben, die die Bürgerin selbst leisten muss – jede vermeidbare Wiederholung ist ein messbarer Sludge-Indikator.
• Abbruchquote im Prozess – wo genau verlassen Menschen den Vorgang, und korrespondiert das mit dem Übergang zwischen zwei Systemen?
• Zufriedenheit am Endpunkt, nicht nur am Anfang – konsistent mit der Peak-End-Logik, sollte die Messung genau dort stattfinden, wo sich das Erlebnis im Gedächtnis festsetzt.

Verwaltungen, die diesen Umbau seriös verfolgen, sollten zunächst den eigenen Reifegrad ehrlich einordnen – etwa mit der CX Maturity Assessment, die entlang zwölf Bausteinen zeigt, wo eine Organisation zwischen Silodenken und echter Journey-Orchestrierung steht, bevor sie in ein Lebensereignis-Projekt investiert.

Wo beginnt die Verwaltung, wenn sie noch nicht bereit für den großen Umbau ist?

Nicht jede Behörde kann morgen ihre gesamte IT-Landschaft um Lebensereignisse neu ordnen. Aber jede Behörde kann heute eine einzige Journey auswählen, sie sauber kartieren und einen einzigen unnötigen Formularschritt eliminieren. Der OECD-Bericht "Digital Government Index" (OECD, veröffentlicht auf oecd.org) verfolgt seit mehreren Jahren, wie konsequent Mitgliedsstaaten ihre digitalen Dienste an tatsächlichen Bürgerbedürfnissen statt an Verwaltungsstrukturen ausrichten – und zeigt, dass dieser Umbau ein mehrjähriger Reifungsprozess ist, kein einmaliges IT-Projekt.

Wer den Aufbau intern nicht allein stemmen kann, sollte den Prozess extern begleiten lassen, statt ihn als reines IT-Vorhaben an einen Dienstleister zu delegieren. Das Service Design für ein Lebensereignis verlangt dieselbe Sorgfalt wie das Design eines Bankprodukts oder einer Fluggesellschaft – nur mit höherem Einsatz, weil die Bürgerin keine Alternative zum Anbieter hat, wenn der Staat versagt. Auch die konkrete Journey-Arbeit lässt sich strukturiert angehen, etwa über CX Journeys, die Kontaktpunkte über Ressortgrenzen hinweg sichtbar machen, oder ergänzend über Public Services Customer Experience & Digital Transformation, wo verwaltungsspezifische Muster bereits dokumentiert sind.

Was bleibt am Ende eines Lebensereignisses?

Eine Verwaltung, die nach Ressorts organisiert ist, verwaltet sich selbst zuerst und die Bürgerin danach. Eine Verwaltung, die nach Lebensereignissen organisiert ist, kehrt diese Reihenfolge um – und genau darin liegt der eigentliche Umbau, nicht in der Technik dahinter. Der nächste Schritt gehört nicht der IT-Abteilung, sondern der Frage, welches einzelne Ereignis im Leben ihrer Bürgerinnen und Bürger gerade am meisten Reibung erzeugt. Wer diese Frage ehrlich beantwortet, hat den schwierigsten Teil des Projekts bereits hinter sich.