EfA-Leistungen skalieren: Was funktioniert und was scheitert in der Praxis

Der Einer-für-Alle-Ansatz klingt schlüssig: Ein Bundesland entwickelt einen digitalen Verwaltungsdienst, die anderen übernehmen ihn. Einmal investieren, vierzehnmal profitieren. In der Theorie ist EfA eines der klügsten Konzepte, die die deutsche Verwaltungsdigitalisierung hervorgebracht hat. In der Praxis ist „Mitnutzung" eine der anspruchsvollsten Koordinationsaufgaben, die ein Projektleiter in diesem Umfeld bewältigen kann.

Wer EfA-Umsetzungsprojekte von innen kennt, weiß: Die eigentliche Arbeit beginnt nicht mit der technischen Umsetzung, sondern mit der interföderalen Abstimmung, die ihr vorausgeht. Und sie endet nicht mit dem Go-live des federführenden Landes, sondern erst dann, wenn der letzte Mitnutzer den Dienst tatsächlich in Betrieb hat.

Was EfA skalierbar macht – die Bedingungen, die erfüllt sein müssen

Skalierung funktioniert dann, wenn drei Voraussetzungen zusammenkommen. Erstens: Ein standardisiertes Datenmodell auf Basis des Föderalen Informationsmanagements. FIM-konforme Leistungs-, Prozess- und Datenfeldbeschreibungen schaffen die gemeinsame Fachsprache, auf die sich Länder mit unterschiedlichen Fachverfahren einigen können. Ohne diese Basis verhandelt jedes Land seinen eigenen Standard – und am Ende gibt es so viele Varianten, dass von „Einer-für-Alle" kaum noch die Rede sein kann.

Zweitens: Eine klare Governance-Struktur. Das federführende Land muss nicht nur den Dienst entwickeln, sondern auch die Koordination mit den Mitnutzern dauerhaft übernehmen – in der Entwicklungsphase, beim Rollout und bei späteren Anpassungen. Projekte, in denen diese Verantwortung nicht klar zugeordnet ist, verlieren sich in Abstimmungsschleifen.

Drittens: Technische Offenheit im Sinne echter Portierbarkeit. Ein Dienst, der auf einer proprietären Infrastruktur des federführenden Landes aufbaut und sich nicht ohne erheblichen Aufwand in andere Systemlandschaften integrieren lässt, ist kein EfA-Dienst – er ist eine Insellösung mit freundlichem Label.

Wo Skalierung in der Praxis scheitert

1. Technische Heterogenität der Länder-Infrastruktur

Kein Bundesland gleicht dem anderen, wenn es um Portallandschaften, Servicekonto-Systeme und Fachverfahren geht. Was in NRW über das WSP.NRW läuft, muss in Brandenburg in eine völlig andere Infrastruktur eingebettet werden. Projekte, die diese Heterogenität erst beim Rollout berücksichtigen, zahlen einen hohen Preis in Form von Nachentwicklung und Verzögerungen. Die Anforderungserhebung bei Mitnutzern muss deshalb früh beginnen – idealerweise parallel zur Konzeptionsphase des federführenden Landes.

2. Rechtliche Abweichungen zwischen den Bundesländern

Bundesrecht schafft einen Rahmen, Landesrecht füllt ihn. Und dieser Rahmen variiert erheblich: Zuständigkeiten, Fristen, Nachweispflichten und Ermessensspielräume können sich von Bundesland zu Bundesland unterscheiden – selbst bei Leistungen, die scheinbar vollständig bundesrechtlich geregelt sind. Ein EfA-Dienst, der diese Varianz nicht systemseitig abbilden kann, zwingt Mitnutzer entweder zu einem schlechten Kompromiss oder zu eigenen Anpassungen, die die Skalierungsidee konterkarieren.

3. Rollout-Koordination ohne ausreichende Ressourcen

Der Go-live des federführenden Landes ist für Mitnutzer nur der Startpunkt. Sie müssen den Dienst in ihre eigene Infrastruktur integrieren, Behörden schulen, Kommunikation mit Bürgerinnen und Bürgern aufsetzen und den Betrieb sicherstellen. Diese Phase erfordert intensive Begleitung – technisch und fachlich. Projekte, die den Rollout als nachgelagerte Formalität betrachten, erleben, dass Mitnutzung auf dem Papier beschlossen, aber in der Realität nicht vollzogen wird.

Was in der Praxis tatsächlich hilft

Die wichtigste Maßnahme ist zeitlich: Föderale Abstimmung muss vor der Umsetzung stattfinden, nicht daneben oder danach. Wer Bundesländer erst einlädt, wenn ein Dienst bereits konzipiert ist, bekommt im besten Fall Kommentare, im schlechtesten Fall Nachforderungen, die das gesamte Konzept in Frage stellen.

• Strukturierte Anforderungserhebung bei Mitnutzern schon in der Konzeptionsphase – mit standardisierten Vorlagen, die föderale Abweichungen explizit dokumentieren.
• Klare Trennung zwischen Kernfunktionen und länderspezifischen Modulen in der technischen Architektur, damit Mitnutzer Anpassungen vornehmen können, ohne den Kern zu destabilisieren.
• Dedizierte Rollout-Begleitung für Mitnutzer – nicht als Nachsorge, sondern als eigenes Arbeitspaket mit Zeit und Ressourcen.
• Regelmäßige Mitnutzer-Koordination nach dem Go-live, um Betriebserfahrungen zu sammeln und in zukünftige Versionen einfließen zu lassen.

Fazit

EfA funktioniert – aber nur unter der Bedingung, dass man den Koordinationsaufwand ehrlich einplant. Die Idee, einmal zu bauen und vierzehnmal zu sparen, ist richtig. Die Annahme, dass Skalierung automatisch geschieht, ist falsch. Der Unterschied zwischen einem EfA-Dienst, der wirklich genutzt wird, und einem, der als Mitnutzungsangebot auf dem Papier steht, ist in der Regel keine Technologie-Frage – es ist eine Koordinations- und Begleitungsfrage.

Projekte, die das von Anfang an wissen und entsprechend planen, haben die besseren Chancen. Alle anderen lernen es im Rollout – und zahlen den Preis in Zeit und Vertrauen.