O'Reilly logo

IT-Projektverträge: Rechtliche Grundlagen by Christoph Zahrnt

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

133
6.2 Die Schaffung des IT-Systems
derte Umstände anzunehmen [siehe als Beispiel die Konkretisierung der Aufga-
benstellung bei der Erstellung von Programmen in Kapitel 9.1].
6.2 Die Schaffung des IT-Systems
In der folgenden Darstellung wird nur beschränkt zwischen der Lieferung von
Produkten und Dienstleistungen (in der Einführungsphase) unterschieden, weil
ein Teil der Dienstleistungen dazu dient, das IT-System erst zu schaffen.
Im Vordergrund steht, welche Eigenschaften das IT-System haben muss. Die
Juristen behandeln diese Frage unter dem Blickwinkel, ob das IT-System mangel-
haft ist, nämlich ob es diese Eigenschaften nicht hat. Deswegen wird diese Frage
in Kapitel 6.3 unter der Überschrift Haftung für Mängel abgehandelt.
Die Phase der Einsatzvorbereitung lässt sich nicht scharf von der Benutzungs-
phase [Kapitel 6.5] trennen. Ei
nige Themen, die sich in der Phase der Einsatzvor-
bereitung stellen, können das in der Benutzungsphase weiterhin tun, z.B. die
Erbringung weiterer Unterstützungsleistungen oder die Aufklärung von Störun-
gen, die nicht auf Mängeln in den Produkten beruhen.
Es kommt darauf an, wie die Vertragspartner die Einführung vereinbaren. Bei
einem Projektvertrag ist davon auszugehen, dass der Auftragnehmer ein schlüs-
selfertiges System schaffen soll. Eine Alternati ve dazu liegt darin, dass der Kunde
die Einführung ü
bernimmt und die Mitwirkung des Auftragnehmers auf einzelne
Unterstützungsleistungen beschränkt [Kapitel 5.4 (2)].
Der Auftragnehmer hat die Aufgabe, die Anforderungen des Kunden an das
Einrichten zu ermitteln, soweit sich diese noch nicht aus dem Vertrag ergeben.
Wie er das macht,
ob er erst ein Realisierungskonzept oder ein Business-Blueprint erstellt oder
ob er gleich anhand einer (branchenbezogenen) Standardparametrierung die
Parametrierung anpasst,
hängt von der Situation ab, insbesondere vom Konzept des Auftragnehmers.
Wenn die Anforderungen nur grob oder mittelfein beschrieben und also dement-
sprechend konkretisierungsbedürftig sind, lassen s
ich Auseinandersetzungen
über die geschuldete Funktionalität im Detail kaum vermeiden [Kapitel 6.3.1;
siehe auch IT-PM, Kapitel 3.3.6 bzw. Kapitel 6.3.4].
Planung der Einsatzvorbereitung bei IT-Systemen: Weil der Auftragnehmer seine
Produkte und die erforderlichen Planungen in der Sphäre des Kunden zur Einfüh-
rung des IT-Systems kennt, ist im Normalfall anzunehmen, dass der Auftragneh-
mer für die Planung und, wenn der Kunde seine Aufgaben gemäß dieser Planung
durchführt, für die Lenkung und Kontrolle der Erledigung zuständig ist [siehe
auch Kapitel 9.2.3.2].
Die Einführung eines neuen IT-Systems kann weniger oder mehr organi sato-
rische Maßnahmen beim Kunden verlangen. Dieser ist fü
r sein Veränderungspro-
6 Beschaffung/Lieferung von IT-Systemen
134
jekt [siehe IT-PM, Kapitel 3.3.2] selbst zuständig. Soweit nichts ausdrücklich ver-
einbart ist, braucht der Auftragnehmer den Kunden hinsichtlich dessen
Veränderungsprojekt nur in der Weise zu unterstützen, dass er mitteilt, welchen
Input aus dem Veränderungsprojekt er für das IT-Projekt zu welchem Zeitpunkt
benötigt.
6.2.1 Leistungsumfang
Zum Leistungsumfang gehören alle für ein funktionsfähiges System erforderli-
chen Teile, auch wenn sie im Vertrag nicht aufgeführt sind. Das gilt auch dann,
wenn die Vertragspartner Schriftform vereinbart haben. Ebenso schuldet der Auf-
tragnehmer – unbeschadet der Frage nach der Vergütung – alle Tätigkeiten hin-
sichtlich der Einsatzvorbereitung, soweit sie vom Fachwissen her seine Sache sind.
(1) Geschuldete Sprachform von Softwareprodukten
Es gibt keine Verkehrssitte dahingehend, dass der Auftragnehmer ein Software-
produkt auch als Quellprogramm zu liefern hat. Ausnahmsweise kann sich eine
Pflicht zur Lieferung des Quellprogramms daraus ergeben, dass der Kunde das
Softwareprodukt zwingend als Quellprogramm benötigt.
Zur geschuldeten Sprachform bei Anpassungsprogrammierung durch den Auf-
tragnehmer siehe Kapitel 8.3.1 (4); zur Lieferpflicht für den Fall, dass der Auf-
tragnehmer die Pflege innerhalb derjenigen Frist einstellt, während der er zur
Pflege verpflichtet ist, siehe Kapitel 12.2.3, bzw. dass er die Pflicht zur Män-
gelbeseitigung verletzt, siehe Kapitel 8.4.3 (3).
Bekanntgabe von Schnittstellen: Ungeklärt ist die Frage, ob der Kunde, wenn er
das Softwareprodukt als Objektprogramm erhält, Anspruch auf Bekanntgabe
von Schnittstellen hat, um das Softwareprodukt mit anderen Programmen
zusammenwirken zu lassen. Das Urheberrecht (§ 69e UrhG) überlässt es dem
Rechtsinhaber, ob er die Informationen offen legen oder den Kunden bzw. den
anderen Auftragnehmer auf den meist mühseligen Weg des Dekompilierens oder
anderer Methoden verweisen will [Kapitel 4.3.3.1].
Systemtechnische Dokumentation: Auch wenn das Quellprogramm geliefert
wird, kann (ohne entsprechende Verei
nbarung) nicht angenommen werden, dass
der Auftragnehmer die darauf bezogene systemtechnische Dokumentation, gleich
ob sie innerhalb oder außerhalb des Quellprogramms existiert, ebenfalls schul-
det. Denn das würde zu einer zusätzlichen erheblichen Gefährdung des Know-
hows des Auftragnehmers führen. Der Auftragnehmer ist also berechtigt, Doku-
mentation, die im Quellprogramm enthalten ist, zu löschen.
Das gilt nicht, wenn die Vertragspartner ausdrücklich vereinbart haben, dass
der Kunde zu Änderungen berechtigt sein soll.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required