Nachnutzung beginnt im Code, nicht im Briefing

Ursprünglich 2020 bei publicplan erschienen handelt ees sich hier inhaltlich gleicher Artikel, in meiner persönlichen Sichtweise neu geschrieben.

Das OZG begleitet die deutsche Verwaltung seit fast drei Jahren. Knapp zwei Jahre bleiben, um rund 600 Verwaltungsleistungen zu digitalisieren. Auf der höchsten Stufe des Reifegradmodells: vollständige digitale Abwicklung einschließlich aller Nachweise, mit angebundener E-Akte, E-Payment, E-Rechnung und digitaler Personalausweis-Funktion.

Diese Aufgabe ist groß. Sie ist nicht zu schaffen, indem jede Verwaltung jede Komponente selbst baut. Nachnutzung ist die einzige skalierbare Strategie. Aber Nachnutzung passiert nicht von allein. Sie braucht zwei strukturelle Bedingungen.

Erstens: Basisdienste statt Eigenbau

Bei der OZG-Umsetzung gibt es eine ganze Reihe von Komponenten, die in jeder Online-Leistung gebraucht werden. Authentifizierung, Bezahlfunktion, Suche, Antragsformular-Logik, Statusabfrage. Diese Komponenten gibt es bereits als Basisdienste, die produktiv laufen.

Beispiele aus Nordrhein-Westfalen, die heute funktionieren: das Servicekonto NRW für Authentifizierung, ePayBL für die Bezahlung, das Snippet der Verwaltungssuchmaschine NRW, das auf jeder kommunalen Website mit wenigen Codezeilen die zuständige Stelle für eine Leistung findet. Wer eine Online-Leistung neu baut, sollte diese Bausteine integrieren, nicht parallel entwickeln. Der Fokus der eigenen Arbeit verlagert sich damit dorthin, wo die fachliche Substanz liegt: auf den eigentlichen Verwaltungsprozess. Alles drumherum kommt aus geprüften, standardisierten Quellen.

Das spart nicht nur Zeit. Es macht die entstehende Lösung kompatibel mit anderen Lösungen, die dieselben Basisdienste verwenden. Aus diesem Grundprinzip wächst der Verwaltungsraum, den das OZG eigentlich erzeugen soll.

Zweitens: Quellcode offenlegen

Der zweite, oft unterschätzte Hebel ist die Offenlegung des Quellcodes. Eine Lösung, die in einer Verwaltung produktiv läuft, kann von anderen Verwaltungen nur dann nachgenutzt werden, wenn sie den Code haben. Klingt selbstverständlich, ist es nicht. Viele OZG-Lösungen werden heute proprietär entwickelt. Der Code liegt beim Auftragnehmer, andere Verwaltungen können bestenfalls die fertige Software anwenden, aber sie können sie nicht anpassen, nicht erweitern, nicht eigenständig pflegen.

Ein Beispiel, das den Unterschied zeigt: Das Gewerbe-Service-Portal NRW basiert auf dem Landes-CMS nrwGOV, einer auf Drupal aufgesetzten Open-Source-Plattform. Erweiterungen, die für das Gewerbe-Portal entwickelt wurden, fließen zurück in nrwGOV und stehen damit jedem zur Verfügung, der die Plattform einsetzt. Aus einer einzelnen Lösung wird ein Bauteil-Lager, aus dem andere Verwaltungen schöpfen können.

Open-Source-Entwicklung ist deshalb keine ideologische Wahl . Sie ist die technische Voraussetzung dafür, dass Nachnutzung überhaupt möglich ist. Ohne Code kein Forken, ohne Forken keine Nachnutzung, ohne Nachnutzung kein OZG.

Konsequenz für die Vergabe: Wer Online-Dienste in Auftrag gibt und Nachnutzung als Ziel hat, muss das im Vertrag stehen haben. Quellcode-Übergabe an die Verwaltung, freie Lizenz für die Weitergabe an andere Behörden, Dokumentation als Lieferbestandteil. Wenn diese Punkte nicht im Leistungsverzeichnis stehen, bleibt die Lösung ein Einzelstück. Das ist keine Frage der Software-Architektur, das ist eine Frage des Beschaffungs-Briefings.

Sichtbarkeit gehört dazu

Eine Lösung, die niemand kennt, wird auch von niemandem nachgenutzt. Das klingt trivial, ist aber im OZG-Alltag ein systematisches Problem. Verwaltungen entwickeln digitale Dienste, die fachlich exzellent sind, technisch sauber, datenschutzkonform, und keiner anderen Verwaltung bekannt. Das Rad wird zum dritten Mal erfunden, weil das zweite Rad nicht öffentlich war.

Wer eine Online-Leistung baut und auf Nachnutzung hofft, muss auch dokumentieren, welche Komponenten sie nutzt, wo der Code liegt, wie der Anschluss funktioniert. Ein Stück Marketing für die eigene Lösung gehört zur OZG-Lieferung dazu. Dem IT-Planungsrat fehlt diese Sichtbarkeits-Schicht. Sie aufzubauen ist eine Aufgabe, die in den nächsten Monaten anliegt.

Sichtbarkeit ist nicht nur eine Veröffentlichungs-Frage. Sie ist auch eine Governance-Frage. Wer pflegt die Lösung weiter, wenn Land 1 sie an Land 2 weitergibt? Wer entscheidet über neue Funktionen, wer trägt die Kosten für Wartung und Sicherheits-Updates? Diese Fragen beantworten sich nicht im Pressetext, sondern in einem Betriebsmodell, das die nachnutzenden Verwaltungen mittragen können. Solange das fehlt, bleibt jede Nachnutzung ein Einzelfall, kein Modell.

Was bleibt, ist die Frage der Akzeptanz

Über aller Mechanik steht die Frage, ob die digitalen Verwaltungsleistungen von Bürger:innen und Unternehmen tatsächlich genutzt werden. Eine technisch perfekte Online-Leistung, die niemand findet, niemand bedienen kann oder niemand verstehen will, hilft niemandem. Nutzerfreundlichkeit, Barrierefreiheit und sauberes UX-Design sind keine Kür für die letzte Sprintphase. Sie sind die Grundlage, auf der Akzeptanz entsteht. Und Akzeptanz ist die Variable, an der das OZG am Ende gemessen wird.

Nachnutzung beginnt im Code, nicht im Briefing. Sie wird möglich, wenn die Verwaltung bereit ist, in Bauteilen zu denken statt in fertigen Häusern, und sie öffentlich zu stellen statt im eigenen Tresor zu lagern. Wer das versteht, baut OZG-Leistungen, von denen andere profitieren können. Wer es nicht versteht, hat in zwei Jahren ein Inselchen.

Hat Sie das Thema interessiert?

Dann schreiben Sie mir gerne eine kurze Nachricht.