Probleme bei der Abnahme von Software, Teil I

I. Einführung

Die Abnahmeerklärung nach § 640 BGB spielt in Softwareprojekten, die auf der Basis des Werkvertragsrechts durchgeführt werden, eine zentrale Rolle. Ich habe jetzt jüngst erneut eine Reihe von Streitigkeiten begleitet.

Fallgestaltung: Der Auftraggeber nimmt die Werkleistung nicht ab und behält die Schlussvergütung ein. Er behauptet, die erbrachte Leistung umfasse nicht alle vertraglich geschuldeten Funktionen. Der Auftragnehmer (IT- Unternehmen) ist der Ansicht, alle dokumentierten Funktionen seien erbracht worden.

Ich verwende den Terminus „unechter change“ als eine Leistung, bei der keine Einigkeit zwischen den Parteien darüber besteht, ob sie von dem ursprünglichen Auftrag umfasst ist oder nicht. Ein „echter Change“ zeichnet sich dadurch aus, dass beide Parteien von dem Erfordernis einer Neubeauftragung ausgehen.

Die zweite Fallgestaltung: Ein Vertrag soll mittels agiler Projektmethodik (beinahe wie Scrum) auf der Basis des Werkvertragsrechts durchgeführt werden.

II. Problemlage

Es gibt zwei Problemlagen, die gelöst werden wollen.

1.) Sprache

Die fachlichen Anweisungen, also die Anforderungen an die Prozesse und Funktionen, die das IT- Unternehmen zu realisieren hat, werden meistens mit Sprache kommuniziert. Es ist egal, ob das in Tickets, Pflichtenheften, Epics oder Lastenheften geschieht. Das Werkvertragsrecht besagt, dass der Unternehmer einen Erfolg schuldet. Welcher Erfolg das ist, wird meistens mit Sprache festgelegt.

Einhergehend mit der Kommunikation durch Sprache ist die Schwäche von Menschen sich so auszudrücken, dass keine Missverständnisse auftreten. Nicht umsonst möchten Auftraggeber vornehmlich mit Auftragnehmern zusammenarbeiten, die „Branchenerfahren“ sind. Jede Verwendung von Sprache leidet darunter, dass der Sprechende gemeinsam mit der Verwendung von Wörtern einen sinnbestimmenden Kontext verwendet, den die empfangende Seite anders voraussetzt. Damit ist der Boden für Missverständnisse bereitet.

Solche Probleme kann man im Rahmen von reiterativen Modellen am besten lösen. Je häufiger Menschen Ihre Ansichten miteinander vergleichen, desto schneller kommen sie Missverständnissen auf die Spur und können diese lösen.

2.) Rechtslage

Das Werkvertragsrecht für Software ist im Bürgerlichen Gesetzbuch (BGB) geregelt. Es gibt kein eigenständiges Gesetz für die Erstellung von Software. Das BGB ist in weiten Teilen so geschrieben, dass es den Auftraggeber schützt und grundsätzlich nicht unterscheidet, ob der Auftraggeber eine Privatperson oder ein Konzern mit eigenen Fachabteilungen ist. Das Gesetz ist generisch für eine Vielzahl von völlig unterschiedlichen Fällen geschrieben und genau das bedingt viele Probleme.

a.) Leistungsprogramm

aa.) Das Gesetz besagt, dass ein Erfolg einzutreten hat. Wie das geschieht, beschreibt das Gesetz nicht. Sofern die Ressourcen begrenzt sind (Vergütung, Zeit und Mitwirkungspflichten) muss eine Planung stattgefunden haben. Das Gesetz sagt nicht, dass eine am Risiko orientierte ausreichende Planung stattgefunden haben muss, sondern überlässt den Parteien die Ausgestaltung des Detaillierungsgrads und die Durchführung der Planung. Das ist keine „Binse“. Man schaue sich einmal die Formulierungen in dem Art 32 DSGVO an, wo es heißt, dass die Parteien technische und organisatorische Maßnahmen treffen müssen, um die Regelungen der DSGVO im Verhältnis zum Risiko und den Kosten angemessen zu berücksichtigen. Im BGB steht dazu nichts Ausdrückliches und wenn man ehrlich ist, formuliert der § 633 II BGB, dass das Risiko für eine unzureichend detaillierte Planung allein beim Auftragnehmer ist.

bb.) Das Gesetz besagt im § 633 II BGB nämlich, dass das Werk frei von Mängeln ist, wenn es die vereinbarte Beschaffenheit aufweist. Und (nur) dann, wenn die Beschaffenheit nicht ausreichend konkretisiert ist, ist das Werk frei von Mängeln, wenn es den objektiv von dem Auftraggeber mit der Durchführung des Vertrags angestrebten Zweck erfüllt oder (aber die Alternative spielt hier keine Rolle) wenn es die gleichen Eigenschaften aufweist wie ähnliche Werke.

Was das Gesetz will, ist den Auftraggeber zu schützen, der bestimmte Planungsmängel nicht kennt. Sofern ich mir ein Schiff bauen lasse, muss das Schiff auch wasserdicht sein. Wenn ich Schuhe schustern lasse, müssen diese für das Gehen verwendbar sein, ohne dass man diesen Zweck explizit in den Anforderungsdokumenten festlegt.

cc.) Das Gesetz ist aber vielseitig im Hinblick darauf interpretierbar, wie weit dieser Grundsatz reicht. Wie ist zu verfahren, wenn der Auftraggeber anführt: „Es ist zwar nicht ausdrücklich dokumentiert, wird aber trotzdem geschuldet, weil sonst der Zweck nicht erreicht ist“. Maßgeblich dann, wenn der Auftraggeber diese Aussage erstmals im Rahmen des Abnahmeverfahrens tätigt. Das Gesetz verlagert durch den § 633 II BGB das Risiko für das Fehlen bestimmter Punkte auf den Auftragnehmer. Dieser „rennt“ der Abnahme hinterher, wenn der Auftraggeber das Gesetz ausnutzt. Denn keine Dokumentation für Software ist lückenlos.

b.) Schlussfolgerungen

Von Seiten der Auftragnehmer ist klar, dass sie ein elementares Interesse daran haben, das Leistungsprogramm des Gesetzes zu ändern. Mein Vorschlag richtet sich auf drei Stellen.

2.) Folgen der Abnahme

Die Abnahme nach § 640 BGB hat grundsätzlich drei Rechtswirkungen.

a.) Gefahrenübergang

Obsolet ist die Wirkung des Gefahrenübergangs. Der Gefahrenübergang bedeutet, dass das Risiko des zufälligen Untergangs von dem Auftragnehmer auf den Auftraggeber übergeht. Falls Sie einmal ein Haus gebaut haben: Das Risiko eines Verlustes des Hauses durch Brand geht mit dem Moment der Abnahme auf den Bauherrn über und er muss nun die Versicherung bezahlen. Bei Software spielt das Risiko „des zufälligen Übergangs“ keine Rolle. Es gibt Sicherungen. 

b.) Gewährleistung

Das Thema Gewährleistung ist eigentlich auch keines, weil der Anspruch des Auftragsgebers auf Erfüllung des Werkes in den Gewährleistungsanspruch der Nacherfüllung übergeht. Beide richten sich darauf, dass die Software vertragsgemäß erstellt wird. Eine spannende – hier aber nicht zu besprechende – Unterscheidung gibt es aber zwischen dem Zeitraum vor und nach der Abnahme: Der BGH hat in einer Entscheidung aus dem Jahr 2017 dargelegt, dass die Gewährleistungsansprüche erst ab dem Moment der Abnahme greifen können. Sofern produktiv genutzte Software nicht vorher abgenommen wurde, kann der Auftraggeber grundsätzlich keine Schadensersatzansprüche aus dem Betrieb der Software geltend machen. Das wird leider noch häufig übersehen.

c.) Beweislast

Die wichtigste Wirkung hat die Abnahme im Hinblick auf die Beweislast darüber, ob das Werk nun richtig erfüllt worden ist oder nicht.

Zwei Fallgestaltungen:

Der Auftraggeber will nicht auf dem Testsystem abnehmen und führt aus, dass er erst im Realbetrieb feststellen könne, ob die Software richtig funktioniert. Erst wenn die Jahresabschlüsse anstünden, könne man beurteilen, ob die Software mangelfrei programmiert worden sei. Es gäbe keine ausreichende Dokumentation, um alle möglichen Fälle zu umfassen, die ein ERP- System in der Realität falsch machen könne.

Agile Programmierung könne selbstverständlich auch nach dem Werkvertragsrecht erfolgen. Schließlich sei ein Ergebnis geschuldet.

Das ist aus der Sicht des Auftraggebers nach dem Gesetz vertretbar, aber in Wirklichkeit spielt er hier die Schwäche eines Gesetzes aus, das niemals für diese Sachverhalte verfasst worden ist.

3.) Schlussfolgerungen

Nach dem Gesetz hilft jeder Mangel der Planung dem Auftraggeber, weil er immer über den Weg des § 633 II 2.Alt BGB behaupten kann, es sei zwar nicht dokumentiert, müsse aber vorhanden sein, sonst sei der Zweck nicht erreicht. Ein Pyrrhussieg: Überdehnt er das Verhältnis zu dem IT- Unternehmen, erhält er ein toxisches Projekt.

Und der Auftragnehmer ist gut beraten, in Abhängigkeit zu den Risiken des Projektes an zwei Stellschrauben zu arbeiten, um die gesetzlichen Missstände in den Griff zu bekommen: Ihm hilft jede Form von Genauigkeit und Umfang seitens der Planung. Und in den Fällen, in denen die genaue Planung nicht realisierbar ist, also man z.B. agil arbeiten möchte, muss man die Regelungen des Gesetzes, zu den Themen Beweislast in der Abnahme und Gewährleistung anders regeln als es das Gesetz vorsieht.

Dazu dann im Teil II.