Lesezeit: 5 Minuten
Vor über einem Jahr ist das OZG-Änderungsgesetz (OZG 2.0) in Kraft getreten. Die Fristen laufen. Es sollte nicht weniger als den Durchbruch der digitalen Verwaltung in Deutschland bringen: Einheitliche digitale Leistungen, weniger Behördengänge, spürbare Entlastung für Bürgerinnen und Bürger sowie für Verwaltungsmitarbeitende.
Die Bundesrepublik hat mit dem Onlinezugangsgesetz eines der ambitioniertesten Digitalgesetze der Welt und dadurch einen verbrieften Rechtsanspruch auf digitale Leistungen. Wer hinter die Kulissen der Rathäuser blickt, sieht allerdings ein Paradoxon: Zwar sind viele Antragsformulare heute online verfügbar, und Plattformen wie die BundID oder das Bundesportal stehen bereit. Aber von echter digitaler Verwaltung, wie sie das Gesetz vorsieht, sind viele Kommunen noch weit entfernt.
Statt Energieeffizienz erleben viele Verwaltungen neue Hürden im Hintergrund: Manuelle Nacharbeiten, fragmentierte Systeme und Prozesse, die an der Oberfläche modern wirken, aber im Backend analog bleiben. IT-Entscheidende und Digitalisierungsbeauftragte in den Kommunen wissen, was die Dashboards des BMI oft verschweigen: Die „Einer-für-Alle“ (EfA)-Dienste stehen bereit, werden aber kaum in der Fläche ausgerollt. Die Registermodernisierung stockt. Die Wartezeiten auf Bescheide werden nicht kürzer, sondern länger. Der Frust wächst auf beiden Seiten.
Dieser Beitrag beleuchtet, warum das so ist und was Kommunen, IT-Leitungen und Digitalisierungsteams jetzt tun können, um das Potenzial von OZG 2.0 wirklich zu nutzen.
Fortschritt bei der Umsetzung des Onlinezugangsgesetzes: Das Frontend-Backend-Paradoxon
Viele Kommunen sind formal „OZG-ready“: Die Anträge sind online erreichbar, die Konten der Nutzenden funktionieren, die Frontends sehen gut aus. Trotzdem wurde Digitalisierung in der Verwaltung die letzten zwei Jahre mit „PDF zum Download“ gleichgesetzt. Doch das alles bringt Bürger:innen wie auch Verwaltungen kaum Vorteile. Wir haben einen analogen Flaschenhals geschaffen. Denn die Prozesse dahinter bleiben oft so aufwendig wie vorher.
Bürgerinnen und Bürger senden Daten (oft schon als strukturierten Datensatz), aber diese treffen im Amt auf eine IT-Landschaft, die sie nicht versteht. In vielen Kommunen endet die digitale Reise des OZG 2.0 im Posteingangskorb. Wir haben das Papier durch PDF ersetzt, aber den Prozess nicht geändert.
Der zentrale Pain Point:
- Fachverfahren und Systeme sind nicht angebunden: Hoch qualifizierte Fachkräfte kopieren Daten aus dem „digitalen Posteingang“ (zum Beispiel EGVP) händisch in das Fachverfahren.
- Das Backend ist nicht automatisiert, sondern blockiert durch isolierte Prozesse, Medienbrüche und fehlende Standards.
Die Bearbeitungsdauer der Anträge verlängert sich teilweise sogar, weil technische Nacharbeiten anfallen. Dazu kommt, dass Fachkräfte mit kopieren beschäftigt sind, statt Entscheidungen zu treffen. Dies alles führt seitens der Bürgerinnen und Bürger zu steigender Frustration. Sie erwarten digitale Geschwindigkeit, doch Verwaltungen können sie nicht liefern.
Gemini; Bilderstellung mit Unterstützung von Nano Banana Pro
Wenn Kommunen allerdings in den kommenden Jahren die Umsetzung des Onlinezugangsgesetzes (OZG) sowie des Onlineänderungsgesetzes (OZG 2.0) erfolgreich durchführen wollen, müssen die einerseits das massive Backend-Problem lösen. Andererseits aber auch den massiven Personalabgang durch anstehende Renteneintritte berücksichtigen. Der wichtigste Schritt ist jetzt: Automatisierung im Backend etablieren, bevor die Fachverfahren kollabieren.
Das Spaghetti-Dilemma: Warum EfA im OZG 2.0 technisch klemmt
Im Kontext von OZG 2.0 ist das EfA-Prinzip („Einer für Alle“) in der Idee bestechend: Ein Bundesland entwickelt eine digitale Leistung, andere nutzen sie nach. In der Praxis scheitert die Skalierung aber oft nicht am Willen der Kommunen, sondern an der Integration in die lokale IT-Landschaft – also dort, wo Fachverfahren, DMS/eAkte, Posteingang und Register zusammenspielen.
Wo es konkret bei der OZG 2.0-Umsetzung hakt
- Datenformate treffen auf Fachverfahren-Realität: Der EfA-Dienst liefert strukturierte Daten (zum Beispiel aus XÖV-Standards), das lokale Fachverfahren kann diese Daten aber nicht ohne Weiteres übernehmen. Ergebnis: Anhänge/PDFs, manuelles Mapping oder händische Übernahme.
- „Standard“ heißt nicht automatisch „kompatibel“: Selbst, wenn ein Standard genutzt wird, unterscheiden sich häufig Pflichtfelder, Validierungsregeln oder Prozessvarianten. Ein simples Beispiel: Feld X ist im entwickelnden Land zwingend befüllt und wird validiert – im nachnutzenden Kontext ist es optional oder anders codiert. Die Folge sind Rückläufer, Nachforderungen oder Abbrüche und dadurch neue Medienbrüche.
- Punkt-zu-Punkt-Anbindungen erzeugen Spaghetti: Wenn jede neue EfA-Leistung direkt mit jedem beteiligten System verdrahtet wird, steigt die Komplexität mit jeder Schnittstelle. Updates brechen Verbindungen, Wartung wird teuer, Rollouts verzögern sich.
Die OZG-Taskforce beschreibt genau dieses Muster: EfA-Prozesse sind häufig nicht unmittelbar nachnutzbar, weil vorab „aufwendige Vorbereitungsarbeiten“ nötig werden. Besonders wegen fehlenden forcierten Standards für Schnittstellen, Nachrichtenübertragung und Qualität.
„Die Folgen dieser fehlenden Standards bekommen die Kommunen täglich zu spüren. So können beispielsweise EfA-Prozesse nicht unmittelbar nachgenutzt werden, da zuvor aufwendige Vorbereitungsarbeiten erforderlich sind. Diese entstehen häufig dadurch, dass das erstellende Bundesland den EfA-Prozess vorranging für das eigene Bundesland entwickelt. Der Prozess ist dadurch zumeist inhärent inkompatibel mit nachnutzenden Bundesländern. Schließlich mangelt es an forcierten fachlichen Standards zu Schnittstellen, Nachrichtenübertragung und Qualität.“
Quelle: Stellungnahme OZG-Taskforce, 2024. https://ozg-taskforce.de/stellungnahme-zum-aktuellen-stand-der-digitalisierung/
Was Sie daraus mitnehmen sollten
Gerade unter OZG 2.0 entscheidet die Integrationsfähigkeit darüber, ob EfA-Nachnutzung wirklich skalieren kann. Wenn bei Ihnen Fachverfahren + DMS/eAkte + Posteingang + ggf. Register betroffen sind, ist EfA in der Regel kein Frontend-Projekt, sondern ein Integrations- und Standardisierungsthema. Dann ist die zentrale Frage nicht „Gibt es den EfA-Dienst?“, sondern: Wie bekommen wir die Daten stabil, wartbar und möglichst automatisiert ins Backend (inklusive Rückkanal, also Status, Nachforderungen, Bescheide)?
Praxischeck OZG 2.0: Vier typische Backend-Brücke – Symptome, Messgrößen und echte Quick Wins
Wenn OZG 2.0 im Alltag keinen spürbaren Effekt bringt, liegt es selten am Portal. Meist liegt es eher daran, dass Eingang, Fachverfahren, DMS/eAkte und Rückkanal nicht als durchgängiger Prozess funktionieren. Genau diese „unvollständige Digitalisierung“ (Oberfläche digital, Backend manuell) ist der Kern des Problems.
Wenn Sie nur 30 Minuten haben: Wo anfangen?
Priorisieren Sie nach Volumen und Schmerz:
- Hoher Eingang / viele Dokumente: (Gerichtspost/EGVP/beBPo): Start mit Szenario 2
- Viele Rückfragen & Statusanfragen: Start mit Szenario 3
- Viele Online-Anträge, aber kein Tempo-Gewinn: Start mit Szenario 1
- Jede neue EfA-Leistung wird zum Mini-Projekt: Start mit Szenario 4
Szenario 1: Der Online-Antrag endet im „digitalen Postkorb“
Symptome: So erkennen Sie es
- Anträge kommen an, werden aber intern als PDF/Anhang weitergereicht oder ausgedruckt.
- Inhalte werden manuell ins Fachverfahren übertragen (Copy/Paste, Abtippen).
- Die Fachabteilung „arbeitet“ den Posteingang ab, statt Fälle systematisch zu bearbeiten.
Messgrößen, damit es nicht Bauchgefühl bleibt
- Manuelle Touchpoints pro Vorgang (z. B. „wie oft muss jemand Daten übertragen/umbenennen/ablegen?“).
- Anteil strukturierter Daten vs. PDF/Anhang bei den Eingängen
- Durchlaufzeit (Eingang -> Fall im Fachverfahren angelegt)
Owner (wer muss es betreiben)?
- IT + Fachbereich (Prozessdefinition) + Fachverfahren-/DMS-Team (technische Übergabe)
Quick Wins (2 bis 6 Wochen, realistisch)
- Einen verbindlichen Eingangskanal je Leistung definieren (keine Mehrkanal-Parallelwelt).
- Pflicht-Metadaten für interne Übergabe einführen: Vogangs-ID/Aktenzeichen, Leistung, Organisationseinheit, Frist.
- Eine einheitliche Ablage-/Benennungsregel festlegen (damit nichts „verschwindet“).
Nächster Schritt (3 bis 6 Monate)
- Strukturierte Übergabe ins Fachverfahren (Import der standardisierten Übergabeschnittstelle) + Protokollierung/Fehlerfälle.
So sieht OZG 2.0 "gut" aus
Antrag -> automatisch als Vorgang im Fachverfahren/eAkte angelegt -> Fachbereich entscheidet, statt Daten zu übertragen
Szenario 2: EGVP/beBPo erzeugt Masse, aber keine Automatisierung
Symptome: So erkennen Sie es
- Mitarbeitende sichten, speichern, umbenennen, ablegen
- Aktenzeichen/Vorgangsbezug wird „interpretiert“, nicht systematisch genutzt.
- eAkte wird befüllt, aber der Prozess dahinter bleibt Handarbeit.
Messgrößen, damit es nicht Bauchgefühl bleibt
- Zeit pro Eingang (Median) vom Posteingang bis zur Zuordnung zur richtigen Akte
- Fehlzuordnungsquote/Nacharbeit (wie oft muss korrigiert werden)
- Backlog im Postfach (Anzahl ungeklärter Eingänge)
Owner (wer muss es betreiben), um OZG 2.0 umzusetzen?
- DMS/eAkte-Team (Ablage/Regeln) + Fachbereich (Kategorisierung) + IT (Betrieb)
Quick Wins (2 bis 6 Wochen, realistisch)
- Zentrale Queue + klare Zuständigkeiten (kein „alle sehen alles“).
- Minimal-Regeln fürs Routing: Absendende/Betreff/Aktenzeichen-Muster -> Zielteam/Zielakte (auch wenn noch nicht perfekt).
- Audit-taugliche Protokollierung einführen (wer hat was wohin gelegt/verschoben) – wichtig für ÖD-Compliance
Nächster Schritt (3 bis 6 Monate)
- Regelbasierte Zuordnung inkl. Dubletten-/Versionierungslogik + definierte Ausnahmebehandlung.
So sieht OZG 2.0 „gut“ aus
- Eingang -> automatische Zuordnung (oder sauberer Ausnahme-Queue) -> eAkte konsistent, ohne „Postfach-Handbetrieb“.
Szenario 3: Nachforderungen & Status laufen außerhalb des Systems
Symptome: So erkennen Sie es
- Rückfragen laufen über Telefon/E-Mail, Nachweise kommen „irgendwie“ rein.
- Statusanfragen werden zum Dauerrauschen („Wo steht mein Antrag?“).
- Kein eindeutiges Case-Tracking: „Welche Unterlagen fehlen? Welche Frist läuft?“
Messgrößen, damit es nicht Bauchgefühl bleibt
- Rückfragenquote pro Leistung (Anzahl Nachforderungen je 100 Vorgänge)
- Zeitverlust durch Pingpong (Schätzung reicht: zum Beispiel Minuten je Rückfrage)
- Anteil Vorgänge ohne eindeutige Vorgangs-ID in der Kommunikation
Owner (wer muss es betreiben)?
- Um OZG 2.0 erfolgreich umzusetzen, benötigen Sie: Fachbereich (Nachforderungslogik, Texte, fristen) + IT (Rückkanal/Status im System)
Quick Wins (2 bis 6 Wochen, realistisch)
- Einheitliche Vorgangs-ID als Pflicht in jeder Kommunikation (auch wenn sie zunächst manuell vergeben wird).
- 5 bis 10 häufigste Nachforderungen je Leistung identifizieren und Standardnachweise/Standardtexte
- Einfache Status-Kategorien festlegen (eingegangen, in Prüfung, Nachforderung, entschieden) – lieber grob und verlässlich als fein und nicht gepflegt.
Nächster Schritt (3 bis 6 Monate)
- Rückkanal technisch sauber integrieren (Status, Nachforderung, Bescheid) + Fristenmanagement.
So sieht OZG 2.0 „gut“ aus
- Bürger:in sieht Status -> Nachforderung ist eindeutig zuordenbar -> Vorgang bleit im System, kein E-Mail-Wildwuchs.
Szenario 4: EfA-Nachnutzung wird zum Schnittstellen-Flickenteppich
Symptome: So erkennen Sie es
- Jede neue Leistung wird ein eigenes Projekt (Mapping, Tests, Sonderfälle, Abstimmungen).
- Updates brechen Anbindungen oder erzeugen Workarounds.
- Betriebskosten steigen schneller als der Nutzen.
Messgrößen, damit es nicht Bauchgefühl bleibt
- Integrationsaufwand pro neue Leistung (Personentage bis stabilen Betrieb)
- Anzahl Schnittstellenvarianten (wie viele „Sonderwege“ existieren?)
- Incident-Rate nach Updates (Störungen/Monat)
Owner (wer muss es betreiben)?
- IT-Architektur/Integration + Fachbereich (Prozessvarianten) + ggf. Landes-IT/Hersteller (Schnittstellenverantwortung
Quick Wins (2 bis 6 Wochen, realistisch)
- Für neue Leistungen einen Backend-Fit-Check als Pflicht einführen: Fachverfahren-Import? DMS/eAkte-Zuordnung? Rückkanal? Logging?
- Ein Schnittstellen-Register führen (Version, Owner, Testfälle, Monitoring – damit Updates nicht „Überraschungen“ werden.
Nächster Schritt (3 bis 6 Monate)
- Wiederverwendbare Integrationsbausteine (Mapping/Validierung/Routing/Monitoring) statt Punkt-zu-Punkt.
So sieht OZG 2.0 „gut“ aus
Neue Leistung nutzt vorhandene Integrationslogik -> weniger Sonderwege -> stabiler Betrieb auch nach Updates
Wenn bei Ihnen mindestens zwei dieser Szenarien zutreffen, ist das kein „Feintuning“ mehr. Dann brauchen Sie Standardisierung im Datenaustausch, klare Schnittstellen- und Betriebsverantwortung sowie eine Form von Datenlogistik im Backend, damit OZG 2.0 nicht bei „digital eingereicht, analog bearbeitet“ stehen bleibt.
Architekturwechsel für OZG 2.0: Intelligente Datenlogistik und Dunkelverarbeitung statt „Abtippen“
Wenn Sie im vorherigen Abschnitt mindestens zwei der typischen Brüche wiedererkennen, ist klar: OZG 2.0 scheitert nicht am Online-Formular, sondern an der Verarbeitung im Backend. Der Hebel ist eine saubere Datenlogistik vom Eingang bis zum Fachverfahren, zur eAkte/DMS und zurück zu Bürgerinnen und Bürgern.
Dunkelverarbeitung bedeutet hier: Standardfälle laufen automatisiert bis zur fachlichen Entscheidung. Mitarbeitende greifen dort ein, wo Prüfen, Bewerten oder Ermessungsspielräume beginnen.
Warum „eine Software für alles“ nicht funktioniert (und warum Entkopplung pragmatisch ist)
In Kommunen existieren viele Fachverfahren, Herstellende und Legacy-Systeme. Komplettlösungen sind meist zu teuer, zu langsam und zu riskant. Der praktikable Weg unter OZG 2.0 ist daher: Entkopplung statt Austausch. Das bedeutet, dass Sie eine Integrationsschicht benötigen, die vorhandene Systeme verbindet und modernisiert, ohne sie sofort zu ersetzen.
Was ein Integrations-Hub ist
Ein Integrations-Hub ist eine Schicht zwischen Portal/EfA-Diensten/EGVP und den internen Systemen (Fachverfahren, DMS/eAkte, Rückkanal). Er sorgt dafür, dass Daten standardisiert, wartbar und betreibbar fließen statt als Punkt-zu-Punkt-Spaghetti.
Die 3 Funktionen, die Sie für OZG 2.0 wirklich brauchen
- Übersetzung (Mapping & Validierung)
Strukturierte Daten annehmen, prüfen (Pflichtfelder/Plausibilität) und ins Zielformat des Fachverfahrens transformieren.
- Verteilung (Routing & Orchestrierung)
Vorgangs-ID/Aktenzeichen vergeben bzw. übernehmen, zuständig routen (Team/Leistung/Ort), eAkte/DMS korrekt befüllen – inkl. Rückkanal (Status, Nachforderung, Bescheid).
- Betrieb (Monitoring, Audit, Datenschutz)
Ausnahme-Queue/Fallback, Protokollierung (Audit-Trail), Rollen/Berechtigungen. Ohne das wird Automatisierung im Betrieb schnell zum Risiko.
Mini-Beispiel: Wohngeld end-to-end
Antrag kommt rein à Validierung (zum Beispiel fehlender Nachweis) à Vorgangs-ID à Routing ins Fachverfahren „Soziales“ + eAkte à Dunkelverarbeitung für Standardchecks (Vollständikgeit/Fristen) à Kanal (Status/Nachforderung/Bescheid) à Monitoring/Audit.
MVP. Klein starten, schnell Nutzen messen
Pragmatischer Start: Beginnen Sie mit einem Hochvolumenprozess (zum Beispiel EGVP) und etablieren Sie mindestens Vorgangs-ID, Routing mit Ausnahme Queue, eAkte-Ablage und Logging. So sinken manuelle Touchpoints messbar.
3 Don’ts, die teuer werden
- Nicht mit 20 Leistungen starten. Erst 1 bis 2 stabilisieren, dann skalieren.
- Nicht ohne Vorgangs-ID & Rückkanal planen, sonst bleibt Pingpong.
- Nicht ohne Ausnahme-Queue & Monitoring automatisieren, sonst steht der Betrieb bei Fehlern.
Reparieren Sie das Fundament, nicht das Dach
OZG 2.0 scheitert nicht am Online-Antrag, sondern an der Verarbeitung dahinter. Wenn Anträge digital eingehen, aber intern manuell verteilt, kopiert und nachgefragt werden, bleibt Digitalisierung eine Fassade.
Der pragmatische Ausweg ist kein Komplettaustausch der Fachverfahren, sondern Datenlogistik und Dunkelverarbeitung: Eingang à Validierung à Routing à Fachverfahren/eAkte à Rückkanal. Sie müssen automatisieren bis zur fachlichen Entscheidung.
Die drei nächsten Schritte:
- Einen Startprozess wählen (z. B. EGVP/beBPo oder eine nachweisintensive Leistung).
- Die Fixpunkte festzurren: Metadaten-Minimum + Rückkanal + Ausnahme-Queue/Monitoring.
- Stabilisieren und messen (Touchpoints, Durchlaufzeit, Rückfragequote). Erst dann auf weitere Leistungen skalieren.
Optional: Ein „Backend-Fit-Check“ liefert eine Prioritätenliste und einen konkreten Maßnahmenplan für Fachverfahren, eAkte/DMS, Rückkanal und Betrieb.
Quellen:
https://www.digitale-verwaltung.de/Webs/DV/DE/onlinezugangsgesetz/das-gesetz/ozg-aenderungsgesetz/ozg-aenderungsgesetz-node.htmlhttps://dashboard.digitale-verwaltung.de/verfuegbarkeit/verwaltungsleistungen
https://www.normenkontrollrat.bund.de/Webs/NKR/DE/home/home_node.html
https://www.it-planungsrat.de/
https://egvp.justiz.de/
https://ozg-taskforce.de/