Michael Bartsch
Themenfelder einer umfassenden Regelung der Abnahme
Ein Überblick zu den möglichen Regelungsgegenständen einer Abnahmeldausel
Die Abnahme wird ein wichtiger Funkt in jedem Projekt
bleiben, ist also im Projektvertrag mit Sorgfalt zu regeln.
Der Beitrag will die Module einer Abnahmeregelung so
umfassend wie möglich zusammenstellen, auch wenn
Vollständigkeit letztlich nie zu erreichen ist. Der Beitrag
versteht sich auch als Anregung, andere Regelungsfelder
(beispielsweise Vergütungsregeln, Leistungsänderungen
und -ergänzungen, Leistungsstörungelt) in einem sol-
chen Format abzubilden.
I. Die Regelung der Abnahme
Die Abnahme zum Abschluss von Projekten bleibt üb-
lich, auch wenn darüber gestritten wird, ob wegen § 651
BGB f ü r Projektverträge nun Kaufrecht gilt. Die Abnah-
me ist auch für beide Vertragspartner zweckmäßig, nicht
nur f ü r den Auftraggeber. Auch der Auftragnehmer will
wissen, ob die Arbeit grundsätzlich akzeptiert wird; sein
Schadensersatzrisiko kann durch eine Inbetriebnahme
des Systems, die verfrüht ist und deshalb abgebrochen
werden muss, deutlich steigen.
1. Notwendigkeit der Abnahme
Schon weil wegen des Problems des § 651 BGB unklar
ist, ob überhaupt eine Abnahme stattzufinden hat, muss
sie vertraglich geregelt werden. Sie ist im Lauf der K o -
operation zwischen den Projektpartnern ein ähnlich
wichtiger Punkt wie der Vertragsabschluss.
Gliedert man den Gesamtbereich eines Projektvertrages in
die vier Körbe Leistung, Vergütung, Organisationsregeln,
> Prof. Dr. Michael Bartsch ist Rechtsanwalt in Karlsruhe und lehrt an der
Universität Karlsruhe und der Hochschule für Gestaltung Karlsruhe
(http://w\vw. bartsch-partner. de/mb).
1 Vgl. Bartsch, Beck'sches Formularbuch Bürgerliches, Handels- und
Wirtschaftsrecht, 8. Aufl. 2003, III.H.4 Anm. 4 (vgl. Heussen, C R
2003, 548); Informatik Spektrum 2003, S. 3 ff. - http-.llwww.bartsch-
partner.del qualitaetssicber ung.
2 Vgl. Siedersieben, Softwaretechnik, 2. Aufl. 2003, S. 299.
Rechtsklauseln, so ist die Abnahme bei den Organisa-
1
tionsregeln einzustufen. Das Regelwerk muss folglich so
gestaltet und formuliert sein, dass es denjenigen, die den
Vorgang durchzuführen haben, als Handbuch dient. Gute
Verträge gehören gerade nicht in die Schublade, sondern
haben den Anspruch, im Vertragsleben hilfreich zu sein.
2. Phasen der Abnahme
Der Gesamtvorgang der Abnahme wird hier in drei Pha-
sen gegliedert:
(A.) Bereitstellung durch den Auftragnehmer (AN).
(B.) Test durch den Auftraggeber (AG).
(C.) Erklärung der Abnahme.
Dies folgt aus dem technischen Vorgang selbst und wird
auch in der Fachliteratur zur Erstellung von Software so
beschrieben. 2
*• •
3. Abnahme durch Erklärung oder durch
Fiktion?
Softwarehäuser verwenden gern Klauseln, durch welche
die Abnahme fingiert oder an konkludentes Verhalten
des A G geknüpft wird. Sie wollen damit rasch über die
Klippe der Abnahme kommen und auch verhindern,
dass der A G das Werk beiseite legt und nicht zügig die
Abnahmeprüfungen durchführt. Die Verlängerung der
Abnahmeprüfung ist für das Softwarehaus teuer, denn
die Arbeitsgruppe muss weiter vorgehalten werden.
A G haben umgekehrt das Interesse, nicht ohne gründ-
liche Prüfung abzunehmen.
Die gesetzliche Lage ist für den A N unzureichend. Die
Abnahmefiktion nach Fristsetzung (§ 640 Abs. 1 Satz 3
BGB) ist wenig hilfreich, weil die Fiktion nur gilt, wenn
das Werk abnahmereif ist, ein Streit, der dann in das Ge-
richtsverfahren getragen wird. Die Klage des A N auf A b -
nahme gibt dem A G viel Zeit, doch noch Fehler zu fin-
 Bartsch
Themenfelder einer umfassenden Regelung der Abnahme
den. Das Sachverständigenverfahren (§ 641a BGB) ist
realitätsfern, schon weil der Sachverständige in das Risi-
ko persönlicher Haftung gerät. 3
Z u favorisieren dürfte ein System sein, das die schützens-
werten Interessen jedes der beiden Vertragspartner be-
achtet:
> Der A G erhält eine ausreichende Zeit f ü r den Test.
t> Werden Fehler gefunden, so wird die Testzeit verlän-
gert oder der Test abgebrochen.
t> Wenn aber zum Ablauf der Testzeit keine abnahme-
verhindernden Mängel benannt sind, gilt die Soft-
ware als abgenommen.
Dieses Konzept entspricht § 640 Abs. 1 Satz 3 BGB; die
Frist wird schon als Abnahmefrist vertraglich verein-
bart. Es lässt dem A G die Freiheit, ob und wie er testet,
aber belastet ihn mit der Konsequenz unzureichender
Tests. Bei diesem Modell ist es für den A N ohne Bedeu-
4
tung, ob der A G tatsächlich testet.
II. Die Themenfelder
Aus dem nachfolgenden strukturierten Überblick zu den
Themenfeldern, die überhaupt für eine Abnahme gere-
gelt werden können, lässt sich das Konzept für den kon-
5
kreten Fall entwickeln, ohne dass das Risiko besteht, Re-
gelungsthemen zu vergessen. Dabei gilt das klassische
Prinzip, dass zunächst der Stoff gesammelt, dann die
Struktur festgelegt und schließlich diese Struktur inhalt-
lich ausgeführt wird.
Der Überblick will nicht dazu verleiten, möglichst um-
fangreiche Abnahmeregeln zu formulieren. Es bleibt bei
der Grundregel, Verträge so kurz wie möglich und so
lang wie nötig zu formulieren. Jede Entscheidung, ein
Regelungsfeld im Vertrag abzubilden oder dies nicht zu
tun, bedarf einer Begründung.
i
A . Bereitstellung zur Abnahme
Der A N erklärt das Werk als abnahmereif und übergibt
es zur Prüfung (häufig Bereitstellung zur Abnahme, BzA,
genannt).
I. Zeitpunkt
Der Zeitpunkt ist üblicherweise dem Projektzeitplan zu
entnehmen. 6
II. Gegenstand
1. Programme
a) Auflistung der einzelnen Programme
b) Begleitende Programme (z.B. f ü r die Erstellung und
Wartung der Software)
c) Lieferung als Maschinenprogramm/als Quellpro-
gramm
d) Format
2. Schriftwerke
a) Herstell- und Wartungsdokumentation 7 z.B. bei der Geschäftsleitung besteht, andererseits die Projektleiter die
b) Nutzerhandbuch
c) Schulungsunterlagen
3. Stand der Arbeiten
Der A N darf die BzA nur erklären, wenn ein vorgegebe-
ner Stand der Arbeiten erreicht ist. 8
10 Zur Schriftform vgl. Fn. 6.
CR 1/2006
4. Gesamtabnahme oder Teilabnahme (vgl. C.IV.5)
5. Erklärungen
a) Erklärung von Subunternehmern i n bezug auf die ur-
heberrechtlichen Befugnisse
b) Angebot des A N für den Pflegevertrag 9
III. Anforderungen an die Software
Die BzA soll nur erfolgen, wenn der Test beginnen kann.
Also müssen die Testanforderungen rechtzeitig vor der
BzA festliegen.
1. Testumgebung: Hardware, Systemsoftware mit ge-
nauer Festlegung des Softwarestandes (Problem: Die
Umgebung der Software, z.B. ein Systemprogramm,
kann sich zum Auslauf des Projektes ändern).
2. Testmaterial: Testdaten, -fälle und -Szenarien
a) Wer stellt das Material? (Typischerweise der A G )
b) Vereinbarung über die Beschaffenheit des Materials,
möglicherweise Verfahren zur einvernehmlichen
Freigabe des Materials.
c) Wann ist das Material zu stellen? (So rechtzeitig, dass
der A N sie zur internen Vorbereitung der BzA zur
Verfügung hat)
d) Folgen einer Verzögerung
e) Darf der A G Testmaterial nachschieben? Wenn ja, bis
wann und in welchem Umfang?
f) Muss der Vertragspartner Einwendungen gegen das
Testmaterial vorbringen, wenn ja, bis wann und wie?
Was gilt mangels vertragsgemäß vorgebrachter Ein-
wendungen?
g) Rechte am Testmaterial (beim A N nur die Nutzung
für die Tests) und Pflichten in Ansehung des Testma-
terials (z.B. Datenschutz).
IV. Durchführung
1. Form der BzA-Erklärung
a) Schriftform 10
b) Liste der übergebenen Gegenstände mit genauer Be-
zeichnung der Stände
3 Sprau in Palandt, 64. Aufl. 2005, § 641a BGB Rz. 10.
4 Die bei Kaufverträgen geltende Konsequenz des § 377 H G B , das „Ab-
schneiden berechtigter Ansprüche aus formalen Gründen", wie der
B G H einmal formulierte, ist unangemessen.
5 Der Autor ist für Ergänzungen und Korrekturen dankbar.
6 Projektzeitpläne ändern sich häufig während des Projektes. Nicht im-
mer wird der neue Zeitplan in der vertraglich vereinbarten Schriftform
vereinbart. Die üblichen pauschalen Schriftformklauseln sind ungeeig-
net, denn während des Projektes gibt es leistungsbestimmende Festle-
gungen in Protokollen und E-Mails, die rechtlich betrachtet Vertragser-
gänzungen sind, aber oft nicht die vereinbarte Schriftform wahren. Das
Risiko, dass in solchen Protokollen weitreichende Änderungen z.B. der
Leistung, des Zeitplanes oder der Vergütung niedergelegt werden, ist
durch eine restriktive Regelungsmacht für solche Protokolle und Ab-
sprachen zu erfassen; vgl. Bartsch, Fn. 1, III.H.4 § 1 Abs. 3, § 12, § 13,
Abs. 2, § 20 Abs. 3. Die Rechtslage wird perplex, also nicht mehr ausle-
gungsfähig, wenn einerseits eine •Schriftformklausel mit Zuständigkeit
Details der Leistungsbestimmungen außerhalb dieser Form vereinbart
haben.
7 Vgl. D I N 66 230.
8 Beispiele: Kein Modul darf fehlen; vorgegebene Tests sind durchgeführt;
Dokumentation, Handbuch und Schulungsunterlagen liegen vor.
9 Der A G sollte den Pflegevertrag mit dem Projektvertrag abschließen. Er
hat später möglicherweise keine freie Verhandlungsposition mehr.
 CR 1/2006 Bartsch 9
Themenfelder einer umfassenden Regelung der Abnahme

2. Auslieferung (Auf CD? Gemeinsame Installation 5. Einhaltung technischer Regeln

beim A G ? Abrufmöglichkeit über das Internet?) a) Stand der Technik, nicht nur Regeln der Technik 13

b) D I N - N o r m e n 14

V. Reaktion des A G
1. Stellungnahme zur Übereinstimmung mit den Vorga-
ben in A.II, und zur Einhaltung der Formalien nach
A.rV, soweit dies ohne technische Untersuchung
möglich ist. Notfalls Rüge. Regeln f ü r die Konse-
quenzen (z.B. kein Beginn der Testphase).
2. Rüge einer Verspätung (vgl. A.I.). Frist f ü r die Rüge
und Konsequenzen einer Verspätung (Auslegung als
Billigung?)
VI. Wirkung
6. Z u duldende Fehler: Software ist nicht fehlerfrei. Ge-
schuldet wird auch nicht theoretische Fehlerfreiheit,
sondern praktische Tauglichkeit. Hier ist festzulegen,
welche Mängel der A N hinzunehmen hat. Beispiel
nach den Fehlerklassen (B.IV.4):
t> Kein Fehler der Klasse 1.
I> Höchstens ... {Zahl) Fehler der Klasse 2.
> Fehler der Klasse 3 hindern die Abnahme nicht, es sei
denn, dass ihre Art und Zahl die Befürchtung aus-
löst, die Software sei ungründlich erstellt.
7. Weitere Prüfkriterien: Beispiele: 15

1. Testphase beginnt.
a) Stabilität der Software beim Test, gemessen beispiels-
2. Kann der A N weiterhin Leistungen (z.B. vervollstän-
weise durch M T B F 1 6

digte oder fehlerbereinigte Software) nachschieben?

A G lehnen das bisweilen ab mit dem Argument, sie b) Sicherheit
müssten die Tests dann wiederholen. Damit riskieren c) Zuverlässigkeit
sie aber, dass die Prozedur niemals endet.
d) Benutzbarkeit

B. Testphase 11 e) Effizienz

Der A G überprüft die Übereinstimmung von Soll- und f) Änderbarkeit

Ist-Beschaffenheit, wie in § 640 BGB vorgegeben. g) Übertragbarkeit
)
I. Gegenstand UT. Vorbereitung
1. Die bei der BzA übergebenen Gegenstände (vgl. A.II.). 1. Ort der Tests
2. Eventuell nachgeschobene Gegenstände (vgl. A.VI.2). a) Test beim A N (z.B. Funktionstest)
b) Test beim A G (z.B. Integrations- und Praxistest)
II. Bestimmung des Soll-Zustandes
2. Testmaterial (vgl. A.III.2, B.II.4)
1. Vertrag mit allen Anlagen
3. Testumgebung (vgl. A.III.l). Möglichkeit des A N ,
2. Vertragsänderungen die Testumgebung zu überprüfen.
3. Weitere Schriftstücke, 12
z.B. Protokolle, E-Mails,
Pläne. IV. Prüfung
4. Testmaterial: N u r das Material nach A.III.2? In die- 1. Testverfahren: Das Verfahren ist detailliert zu planen
sem Falle verhindern Mängel, die durch das Testma- und festzulegen. Details gehören in die H a n d der In-
terial nicht erfasst werden, die Abnahme nicht. Ande- formatiker. 17

rerseits sind Änderungen der Testdatenbasis f ü r den

A N oft unzumutbar. Vermittelnde Lösung: Das Test-
material bleibt verbindlich, außer wenn außerhalb
des Testmaterials ein schwerer Fehler (vgl. Fehler-
klassen B.IV.4) festgestellt wird.
11 Das Testen ist in der softwaretechnischen Literatur umfassend darge-
stellt (vgl. Sommerville, Software Engineering, 6. Aufl. 2001, S. 447 ff.;
Traubotb, Software-Qualitätssicherung, 2. Aufl. 1996, S. 200 ff.; Bal-
zert, Lehrbuch der Software-Technik, 1998, Bd. 2 Teil III.6). Juristen
können sich zur Erstellung von Regeln der Qualitätssicherung aus die-
sem Arsenal der Testkonzepte bedienen.
12 Vgl. Fn. 6.
13 Z u den Begriffen vgl. Bartsch, Fn. 1, HI.H.2 Anm. I l m . Hinw. auf
BVerfG NJW 1979, 332.
14 Es gibt auch im Softwarebereich viele DIN-Normen. Im vorliegenden
Zusammenhang ist die D I N 66 230 „Dokumentation" von.besonderer
Bedeutung.
15 Software muss mehr können, als nur richtige Ergebnisse zu liefern. Auch
2. Organisationsregeln
a) Zuständigkeit
Beispiel: Tests werden beim' A G nur durch qualifi-
zierte Mitarbeiter durchgeführt oder nur durch sol-
che, die die Schulung durchlaufen haben.
Mitwirkung des A N ? Der A N kann zur Mitwirkung
berechtigt oder auch verpflichtet sein.
b) Kooperationspflichten wie während des gesamten
Projektes
c) Fehlerbuchhaltung: Alle Fehler und Fehlerbehaup-
tungen werden aufgelistet unter Angabe von Fehler-
bild, Fehlerklasse, weiterem Verfahren und Zustän-
digkeit.
3. Stufen des Tests 18

Eigenschaften wie Zeitverhalten, Ergonomie, Fehlertoleranz, Wartbar-

keit und Interoperabilität sind zu definieren. Vgl. D I N ISO 9126 und a) Formale Prüfungen (z.B. Übereinstimmung mit Pro-
sehr ausführlich Balzert, Fn. 11, Teil III.
grammerstellungsrichtlinien)
16 M T B F (Meantime Between Failures), kennzeichnet die Zeit zwischen
auftauchenden Fehlern (was nur für die Fehlerklasscn 2 und 3, vgl. b) Modultests
B.IV.4, sinnvoll ist); vgl. Sommerville, Software Engineering, 6. Aufl.
2001, S. 383. Zur Leistungsmessung von Software vgl. Dirlewanger, c) Test des Gesamtsystems
C R 1988,588; Dirlewanger, CR 1988, 774.
17 Vgl.Fn. 11. d) Übernahme von der Testumgebung in die Produktiv-
18 Details ergeben sich aus den Anforderungen der Technik; vgl. Fn. 15. umgebung
 10 Bartsch
Themenfelder einer umfassenden Regelung der Abnahme
4. Fehlerklassen
a) Beispiel f ü r die Klassenbildung: Betriebs- oder test-
verhindernde Fehler; betriebs- oder testbehindernde
Fehler; sonstige Fehler. 19
b) Einstufungsrecht: Vorschlag: Beim projektbegleiten-
den Schlichter (vgl. D.I.3). Seine Entscheidung kann
die eines Schiedsgutachters sein, also verbindlich,
oder nur für die Testphase und unter Vorbehalt der
beiderseitigen Ansprüche gelten, also nur bewirken,
dass die Testphase nicht länger durch diese Mei-
nungsverschiedenheit gestört oder verzögert wird.
Zusatzregelung: Recht des A G , unabhängig von der
objektiv richtigen Fehlereinstufung eine Reaktion
des A N wie bei einem schwereren Fehler zu verlan-
gen; der A N hat dann einen Anspruch auf Zusatzver-
gütung. Der A G kann damit eine beschleunigte Kor-
rektur durchsetzen, w o ihm dies wichtig ist.
c) Umstufung: Ein'Fehler ist in eine andere Klasse um-
zustufen, wenn die Schwere des Problems erst später
festgestellt wird (Hochstufung) oder wenn eine teil-
weise Nachbesserung oder Umgehungslösung vorlie-
gen (Herunterstufung).
d) Beiziehung Dritter (z.B. Subunternehmer des A N ;
Hauptauftraggeber des A G ; Hinterlegungsstelle für
das Quellprogramm; Schlichter, D.I.3).
e) Konsequenzen aus der Versäumung solcher Pflichten.
5. Pflicht des A G zum Test? Wenn ja, Konsequenz
20
einer Versäumung der Pflicht. Wenn der A G die Prü-
fung nicht zügig durchführt, wird er die Erklärung
der Abnahme verzögern. Davon, dass das eine
Pflichtverletzung ist, hat der A N praktisch nichts.
6. Fehlermeldungen
a) Pflicht des A G , Fehler.zu melden? Der A G will einer-
seits, dass Fehler rasch beseitigt werden, aber ande-
rerseits, dass ihm der A N nicht laufend neue, übereilt
erstellte Softwareversionen vorlegt^ die umfassend
neu getestet werden müssen. Der A N andererseits
will nicht, dass der A G mit MängelbehauptUrigen
hinterm Berg hält und dadurch der ordnungsgemäße
Auslauf der Testphase (vgl. B.VI.) scheitert oder hi-
nausgeschoben wird. Ich halte die Pflicht des A G ,
Fehler zu melden, für richtiger.
b) Folgen der Versäumung dieser Informationspflicht.
7. Pflichten des A N
a) Vorlage fehler bereinigter Software entsprechend
A.IV: Beispiel: Für die Beseitigung von Fehlern der
Klassen 1 und 2 werden Fristen vereinbart. Kann das
Softwarehaus die Frist nicht einhalten, gibt es eine
Verlängerung der Testfrist oder einen Neubeginn
(B.V.3); der A G muss nun befürchten, dass die Soft-
ware nicht wartbar ist. O b Fehler der Klasse 3 wäh-
rend des Tests beseitigt werden sollen oder dürfen,
wird vom A G festgelegt und in der Fehlerbuchhal-
tung (B.IV.2.c) dokumentiert.
b) Darlegung der Fehlerbeseitigungsmaßnahmen durch
den A N , damit der A G den neu ausgelösten Prüfauf-
wand abschätzen kann.
V. Dauer der Testphase
1. Beginn (vgl. A . V I . 1)
2. Zeitdauer (üblicherweise i n Wochen oder Monaten)
CR 1/2006
3. Hemmung und Neubeginn: Je nach Schwere eines
auftauchenden Fehlers gilt:
a) Die Testdauer wird um einen festgelegten Zeitraum
verlängert.
b) Die Testdauer endet nicht vor Ablauf eines festgeleg-
ten Zeitraumes, der ab BzA einer fehlerbereinigten
Version berechnet wird.
c) Der Test wird abgebrochen (vgl. B.VI.2).
VI. Ende der Testphase
1. Übergang zur Abnahme
a) Verpflichtung zur Erklärung der Abnahme (vgl.
C.III. 1)
b) Fiktion der Abnahmeerklärung mit Auslauf der -
ggf. nach B.V.3 verlängerten - Testphase (vgl. Vorbe-
merkung 1.3).
2. Abnahmeverweigerung
a) Testabbruch, z.B. bei Fehler Klasse 1 (vgl. B.IV.4). .
Oder weiche Kriterien: z.B. Zumutbarkeit der opera-
tiven Nutzung.
Konsequenz: Rücksetzung des Vorgangs bis vor die
BzA. '
b) Projektabbruch
Erschwerte Voraussetzungen hierfür, z.B. besonders
schwere Fehler, wiederholte Fehler, wiederholte Z u -
rückweisung mangels Abnahmereife, Überschreiten
eines Endtermins. Konsequenzen: Rechtsregeln.
C. Abnahme
Wo die erfolgreich durchlaufene Testphase als Abnahme
gilt (vgl. B.VI.l.b), endet das Abnahmeverfahren mit
vorgegebenem Ende der Testphase. Dies ist der Fall der
Abnahmefiktion; die bei C.III.2 genannten Situationen
sind Abnahmen durch konkludente Handlungen.
I. Gegenstand der Abnahme
1. Die Software, wie sie vertragsgemäß zum Ende der
Testphase vorliegt.
2. Teilabnahme: Definition der Teile des Gesamtwer-
kes. Z u den Konsequenzen der Teilabnahme vgl.
C.IV.5.
II. Voraussetzungen
1. Testphase ordnungsgemäß abgeschlossen.
2. Darf der A G nach dem Ende der Testphase Fehler
nachmelden? Wenn ja, ist die Testphase zu Lasten des
A N weiter verlängert, und der A G hat Vorteile aus
einer vertragswidrigen Verschleppung des Abnahme-
vorgangs. Anderenfalls hat der A G den Nachteil,
trotz schwerer Fehler abnehmen zu müssen. Vor-
schlag: Abgrenzung wie bei B.II.4; zumindest Er-
schwerung der Nachmeldung.
19 BartschyVn. 1, III.H.4 § 21. Diese Definitionen der Fehlerklassen knüp-
fen an die Perspektive des A G an, also nicht daran, ob die Beseitigung
des Fehlers einfach oder schwierig ist, sondern wie der Fehler sich aus-
wirkt. Gelegentlich wird bei den einzelnen Bereichen der Software der
Fertigstellungsgrad festgestellt und vorgegeben, dass die Software, um
abgenommen zu werden, zumindest den Reifegrad X von Y Graden er-
reichen muss.
20 Vgl. Vorbemerkung 1.3.
 CR 1/2006
Themenfelder einer umfassenden Regelung der Abnahme
3. Durchführung der Schulung
4. Restlieferung, wenn beispielsweise noch das Hand-
buch gefehlt hat.
5. Erklärungen
a) Erklärungen nach A.II.5 sind möglicherweise erst
jetzt vorzulegen.
b) Erklärungen Dritter: Gelegentlich will der A G erst
abnehmen, wenn sein Hauptauftraggeber abnimmt;
eine problematische Klausel.
III. Abnahmeerklärung
1. Ausdrückliche Erklärung
a) Vorgabe des Inhalts
b) Wirkung eventueller Vorbehalte
t> Pflicht zur Nachbesserung; Fristvereinbarung
> N u r auf den Fall korrekter Fehlerbeseitigung be-
dingte Abnahme
> Regeln f ü r das Verfahren der Nachabnahme
> Einbehalt von Werklohn bis zur Nachabnahme
der Fehlerbeseitigungsmaßnahme
c) Form
2. Konkludente Abnahme. Beispiele:
a) Volle Werklohnzahlung
b) Produktive Nutzung f ü r einen zu vereinbarenden
Zeitraum
c) Keine Mängelrügen während eines festzulegenden
Zeitraums oder auf Anfrage des A N .
Konkludente Abnahmen sollten stets aufgenommen
werden, denn nicht selten wird die ausdrückliche Abga-
be der Erklärung vergessen oder absichtsvoll hinausge-
schoben.
IV. Folgen
Die Folgen sind gesetzlich festgelegt. Die vertragliche
Wiederholung ist meist überflüssig.
1. Fälligkeit des Werklohns
2. Beginn der Gewährleistungszeit
3. Beweislast beim späteren Auftauchen von Fehlern.
Zur Vermeidung von Zweifeln kann die Hinterle-
gung eines Originals der abgenommenen Software
vereinbart werden.
4. Beginn des Pflegevertrages 21
21 Vgl. Bartsch, NJW 2002,1526 (1528 bei I I A ) .
22 Vgl.Fn. 6.
Bartsch 11
5. Teilabnahme. Möglichkeiten:
a) Die Teilabnahme ist eine Abnahme i m Rechtssinn.
Z u klären ist: Auswirkung von Fehlern, die der A G
erst im Zusammenhang mit späteren Teillieferungen
testen oder feststellen kann. RegelungsVorschlag: Für
solche Eigenschaften beginnt die Gewährleistungs-
zeit erst zusammen mit diesem späteren Teilbereich;
die Beweislast dafür, dass der Fehler anfänglich ist
und erst jetzt getestet werden kann, liegt beim A G .
Oder: Das Herstellen dessen, was fehlt oder unrichtig
ist, gilt als Leistungspflicht der späteren Leistungs-
phase.
b) Die Teilabnahme ist keine Abnahme im Rechtssinn,
sondern nur eine Freigabe.
c) Wo keine Teilabnahmen erfolgen, aber der A G schon
Teile des Werkes in Gebrauch nimmt, sind die Konse-
quenzen zu regeln (z.B. Fehlermeldepflicht; Verände-
rungsverbot; Kosten für die Pflege).
D . Weitere Regelungsfelder
I. Allgemeine Organisationsregeln
1. Zuständigkeiten für die einzelnen Phasen und Vor-
gänge
a) auf Seiten des A G
b) auf Seiten des A N *
c) Zuständigkeit von Sonderfachleuten und Schlichtern
2. Schriftform f ü r einzelne Erklärungen, wenn man
22
dies nicht bei den Erklärungen (Ä.IV.l, V . l , B.IV.6,
C.III. 1) regelt. Klarstellung, ob die elektronische
Form (§ 126a BGB) oder die Textform (§ 126b BGB)
genügen oder in welchen Fällen eine Urkunde § 126
Abs. 1, 2 BGB zu erstellen ist.
3. Streitschlichtung: Wo ein Schlichter oder Schieds-
richter mit vorläufigen oder endgültigen Festlegun-
gen in das Verfahren eingebunden ist (vgl. B.IV.4.b),
sind die organisatorischen Regeln zu treffen.
U. Konsequenzen aus Störungen
Die Konsequenzen aus Störungen gehören nach der
hier verfolgten Systematik (vgl. Vorbemerkung L I ) zu-
meist nicht zu den Organisationsregeln, sondern zum
Bereich Vergütung oder zu den Rechtsregeln. Der Voll-
ständigkeit halber werden hier wenige Stichworte er-
wähnt.
1. Kosten der längeren Testphase beim A G und beim
AN
2. Aufwendungsersatz des A N bei Rügen ohne Grund
3. Verzögerungsschaden
4. Vertragsstrafen