Öffentliche Beschaffung : So beschafft man moderne Software (nicht)

Seit Inkrafttreten des aktuellen Koalitionsvertrages hat die Ampel-Koalition 1727 Software-Entwicklungsaufträge erteilt (Stand: August 2024). Die Diskussionen rund um digitale Verwaltung driften dabei immer wieder in die gleichen Richtungen ab: Wie wird eine Leistung dem Onlinezugangsgesetz (OZG) gerecht? Was kostet das Ganze? Wird die Anwendung Open Source entwickelt? Welchem Dienstleister kann man vertrauen?

Viele dieser Debatten haben ihre Berechtigung. Was dabei aber meist vollkommen untergeht, ist das Fundament jedes dieser 1727 Aufträge: die Vertragsgestaltung. Aktuell werden Software-Entwicklungsverträge in der Verwaltung zumeist als Werkverträge mit detaillierter Leistungsbeschreibung zu bestimmten Features oder Teilleistungen abgeschlossen, die am Ende als erledigt abgehakt werden sollen. Schon das Standardvertragsmuster ist ein Werkvertrag, die sogenannten „Ergänzenden Vertragsbedingungen für die Beschaffung von Informationstechnik (EVB-IT) – Erstellung“. Der Werkvertrag ist allerdings eine schlechte Basis, um Software-Projekte erfolgreich und effizient umzusetzen: Er bremst moderne Software-Entwicklung aus.

Warum Werkverträge nicht für Software-Produkte geeignet sind

Warum ist das so? Beim Werkvertrag geht es darum, ein konkretes Arbeitsergebnis zu einem bestimmten Zeitpunkt zu versprechen beziehungsweise zu erreichen. Aber schon die zugrundeliegende Annahme, dass das Werk irgendwann „fertig“ ist, trifft auf Software prinzipiell nicht zu: Um sie an aktuelle Anforderungen und Gegebenheiten anzupassen, braucht es kontinuierlich neue Releases. Für Software-Projekte bedeutet ein Werkvertrag außerdem die Vereinbarung, eine Software mit im Voraus definierten Funktionen und innerhalb eines festgelegten Zeitrahmens zu liefern, unter Umständen auch noch zu einem vorab festgelegten Pauschalpreis.

Was ist das Problem damit? Der Fehler liegt im Detail, es geht um Begriffe wie „im Voraus“, „konkret“ und „festgelegt“. Das steht im Widerspruch dazu, wie moderne Software-Entwicklung funktioniert. Die Erkenntnis, dass der „Wasserfallansatz“, also die werkvertragstypische Vorab-Detailplanung, in schlechte Software mündet, führte bereits Anfang des Jahrtausends zum sogenannten „Agilen Manifest“.

Das war die Geburtsstunde agiler, iterativer Software-Entwicklung. Diese setzt auf Flexibilität, Zusammenarbeit und iterative Verbesserung. Die Entwicklung soll sich an den ständig ändernden Anforderungen und Prioritäten der Kund:innen oder Nutzer:innen ausrichten. Der agile Ansatz ist geprägt von kurzen Entwicklungszyklen, ständiger Rückmeldung und der engen Zusammenarbeit im Team und mit den Stakeholdern. Begriffe aus der Wortfamilie „im Voraus“, „konkret“ und „festgelegt“ kommen hier nicht vor. Sie erscheinen gar konträr zu „Flexibilität“ und „iterativ“.

Fortschritt wird künstlich verschlafen

Werkverträge zwingen daher Dienstleister:innen, die digitale Lösungen für die öffentliche Hand erarbeiten, entgegen den Grundsätzen moderner Software-Entwicklung zu handeln. Bereits jetzt zu versprechen, welche exakten Bausteine eine Software-Lösung hat, wie viel Zeit jeder einzelne Entwicklungsschritt genau braucht und wie hoch die exakten Kosten sein werden, führt nicht dazu, dass gute Software entsteht, die von Bürger:innen oder Verwaltungsmitarbeiter:innen gerne, problemlos und effizient genutzt wird.

So wird schlimmstenfalls jahrelang an einer Software entwickelt, die, wenn die Anforderungen aus der Leistungsbeschreibung abgearbeitet sind, nicht mehr den Ansprüchen des fortgeschrittenen Ökosystems gerecht wird. Wer beispielsweise 2019 einen Software-Auftrag auf werkvertraglicher Basis erteilt hat, dessen Ziel eine Software-Bereitstellung 2023 war, hätte damit leben müssen, dass die „fertige“ Software den Fortschritt und die Möglichkeiten, die mit der rasanten Entwicklung von Künstlicher Intelligenz rund um 2021 gekommen sind, kaum einbeziehen würde. Das dem Vertrag entsprechende Produkt befindet sich dann auf dem Stand von vor vier Jahren.

Es braucht eine neue Mentalität in der Verwaltung

Das Problem um Werkverträge bei der Software-Entwicklung ist damit offensichtlich. Warum werden sie aber im öffentlichen Sektor weiter auch in diesem Bereich genutzt? Nach langjähriger Arbeit für und mit Beschaffer:innen der öffentlichen Hand wage ich eine These: Es geht um ein tief verwurzeltes Sicherheitsbedürfnis.

Verwaltung ist seit jeher auf Sicherheit und Risikovermeidung optimiert, das steckt in der DNA der handelnden Personen. Und unter Risiken werden, so meine Erfahrung, vor allem rechtliche Risiken – aus dem Haushaltsrecht, dem Vergaberecht, dem Vertragsrecht – verstanden. Daher der Hang zum Werkvertrag: Wer eine klare Leistung beschreibt, einen klaren Zeitraum definiert und ein klares Budget absteckt, der hat gefühlt erst einmal alles dafür getan, dass die Sache läuft und eine adäquate Erfolgskontrolle möglich ist. Es steht ja alles im Vertrag. Dass das so beileibe nicht immer stimmt, zeigen zahlreiche Beispiele aus der Realität. Vor allem Bauverträge der öffentlichen Hand, klassischerweise Projekte auf Werkvertragsbasis, laufen immer wieder völlig aus dem Ruder.

Wie aber können wir Verträge so gestalten, dass sie moderne Software-Entwicklung ermöglichen – und gleichzeitig das verständliche Bedürfnis der Auftraggeberseite nach Sicherheit bedienen? Dafür muss das Rad nicht neu erfunden werden. Die bessere Option sind Dienstverträge – mit einigen zweckdienlichen Regelungen, die der Auftraggeberseite Einfluss und Steuerung erlauben. Beim Dienstvertrag wird kein konkretes Arbeitsergebnis geschuldet, sondern lediglich die Erbringung einer bestimmten Art von Leistung, also zum Beispiel Software-Entwicklung.

Das heißt nicht, dass es am Ende kein Arbeitsergebnis gibt. Es heißt nur, dass nicht ganz konkret vorab definiert wird, wie dieses erreicht wird und auszusehen hat. Bezogen auf Software-Entwicklung bedeutet das, dass die Ausgestaltung der Software, zum Beispiel Art und Zahl der Features, statt im Voraus während der Entwicklung gemeinsam von den Vertragspartner:innen festgelegt wird.

Ein Dienstvertrag erlaubt daher eine gemeinsame Reise zu einem Ziel. Nur die Wegpunkte dahin sind nicht vorab definiert. Das gibt den notwendigen Spielraum, immer wieder nachzujustieren und Lösungen durch frühen Live-Betrieb wirklich auf die Nutzer:innen zuzuschneiden. Und wenn das Entwicklungsteam merkt, dass sich eine anfangs aufgestellte Annahme in der Realität als falsch herausstellt, kann es zügig umlenken. So wird vermieden, dass ein Projekt zu lange „in die falsche Richtung läuft“ und somit das Ziel am Ende womöglich gar nicht – oder nur mit erheblicher Verzögerung und starkem Mehrkostenaufwand – erreicht werden kann.

Auch aus diesem Grund richtet die staatliche US-amerikanische Innovationsagentur 18F in ihrem „State Software Budgeting Handbook“ den eindeutigen Hinweis an staatliche Beschaffer:innen: „Procure Services, not Software: Don’t think of procuring custom software as buying a thing. Instead, think of it as buying a service: the service of a team of developers and designers performing work as prioritized by the product owner.“ Also: Beauftragt Dienstleistungen, nicht Software!

Heißt das, dass Dienstleister machen können, was sie wollen? Natürlich nicht: Das legitime Bedürfnis der öffentlichen Auftraggeber:innen nach Sicherheit wird im agilen Software-Entwicklungsvertrag zwar nicht über eine detaillierte Beschreibung der Leistung und später dann deren förmliche Abnahme erreicht. Stattdessen sind die Auftraggeber:innen engmaschig über strukturierte Formate und Artefakte in die Leistungserbringung eingebunden. Auftraggeber:innen behalten den Überblick und die Lenkungsfunktion über die Leistungen innerhalb des Projekts. In den Vertragswerken kann das agile Projektvorgehen beschrieben und so auch förmlich zur Vertragspflicht gemacht werden.

Agile und iterative Software-Entwicklung heißt in keinem Fall, dass plan- oder kopflos gearbeitet wird. Im Gegenteil stellen agile Frameworks hohe Anforderungen an die Strukturiertheit von Leistungserbringung und Zusammenarbeit. Die Methoden sind nicht neu, vielmehr in der Privatwirtschaft schon Usus. Daher gibt es sehr erfahrene Entwickler:innen, die Software-Produkte auf dieser Basis gezielt entwickeln können. Der passende rechtliche Rahmen dafür mag ungewohnt sein. Es ist aber kein Hexenwerk, ihn sich zu erschließen.

Es braucht allerdings schon etwas Mut: den Mut, etwas anders zu machen als bisher. Der Satz „Weil wir es schon immer so gemacht haben“ steht Innovation und Modernisierung im Weg. Dabei brauchen wir beides so dringend für eine digitale Verwaltung und einen leistungsfähigen Staat.

Anja Theurer ist CFO des Digital Service des Bundes und verantwortet dort unter anderem die Bereiche Recht, Compliance und Beschaffung. Zuvor baute sie als CFO den Cyber Innovation Hub der Bundeswehr mit auf, wo sie unter anderem den Einkauf von Software-Lösungen bei Start-ups verantwortete.