Augen auf, heißt es besonders für Anbieter, wenn es um Verträge im Bereich Datenbanksysteme geht. Denn wer hier allzu freihändig operiert, bewegt sich auf rechtlich schlüpfrigem Boden. Deshalb ist es in Verhandlung zwischen Hersteller und Benutzer wichtig, den Mittelweg zwischen Wettbewerbserfordernissen und drohenden Haftungsrisiken zu finden. Je präziser die Beschreibung der Leistungen der Lieferanten ausfällt, um so mehr unterbleibt ein peinlicher Vertrauensüberschuß seitens des Kunden, der den Anbieter teuer zu stehen kommen kann.
Jeder Datenbankeinsatz muß sorgfältig vorgeplant werden, soll er erfolgreich laufen. Die vielfach nur unvollständig informierten Kunden sind hier überwiegend auf ergänzende und manchmal auch einführende Informationen des Anbieters angewiesen.
Kaum ein Anbieter wird, mit einem Vertragsabschluß in Aussicht, solche Beratungen schlankweg ablehnen. Er sollte dies auch keineswegs tun, sondern vielmehr im voraus klären, welche rechtlichen Verpflichtungen ihm hieraus erwachsen. Umfassende Ratschläge sind an dieser Stelle nicht möglich. Sie müssen einer konkreten rechtlichen Beratung überlassen bleiben. Deshalb nur einige Hinweise auf besonders kritische Punkte bei Vertragsverhandlungen. Zunächst sollten sich die Anbieter darüber im klaren sein, in welchem Umfang sie (prospektiven) Kunden Beratung anbieten. Die oft notwendige Ist/Soll-Analyse etwa gehört gewiß nicht mehr in den Rahmen vertragsvorbereitender Gespräche. Dennoch läßt es sich selten vermeiden, einzelne Bereiche dieser Analyse zumindest anzusprechen.
Aufklärung und Haftung
Der Anbieter muß beachten, daß der Anwender in aller Regel Entscheidungen auf diese Beratungen stützt und sich hieraus für den Anbieter eine eigene Haftung begründet. Je ausführlicher solche Gespräche geraten, desto weiteren Umfang gewinnt diese Haftung. Riskant wird eine solche Haftung vor allem, wenn der Anbieter mehr oder weniger kompetent Daten und Entwicklungseinschätzungen vorgibt, aus denen Einsatzbedingungen und Auswahlkriterien für angebotene Datenbanksysteme abgeleitet werden sollen. Der Anbieter tut hier gut daran, die Haftung für die Richtigkeit dieser Vorgaben ausdrücklich auszuschließen. Ein solcher Haftungsausschluß ergibt sich nicht von selbst aus den üblichen Standardverträgen. Diese beschränken in der Regel die anwenderseitigen Gewährleistungsrechte und erfassen damit nicht automatisch gesondert übernommene vertragliche Nebenpflichten des Anbieters dergestalt, den Kunden sachgerecht und umfassend zu beraten. Hier haftet der Anbieter über seine vertragliche Mängelgewährleistung hinaus. Das gelieferte Datenbanksystem kann etwa prospektgemäß einwandfrei funktionieren und doch völlig an den mitgeteilten Kundenanforderungen vorbeigehen. War dem Anbieter die mangelnde Erfahrung der Kunden erkennbar, so steht dem Kunden gegen den Anbieter ein Schadensersatzanspruch zu. Selbst wenn die Eignung für einen speziellen Verwendungszweck nicht zugesichert wurde (was ohnehin Haltung aus Gewährleistung auslöst), muß der Anbieter doch für die fehlerhafte Beratung einstehen. Er ist insoweit bereits vorvertraglich zu Aufklärung und Information verpflichtet, wenn er dies nicht ausdrücklich ausgeschlossen hat.
Viele Mitarbeiter glauben immer noch, gehaftet werde erst dann, wenn sie explizit eine konkrete Zusicherung abgeben beziehungsweise allgemein erklären, sie stünden für die Richtigkeit der abgegebenen Aussagen und der Herstellerangaben ein. Tatsächlich ist ein solcher Hinweis im Rahmen von Beratungsgesprächen praktisch überflüssig: Wird dem Kunden nicht umgekehrt eindeutig, nachweisbar und rechtzeitig mitgeteilt, daß bestimmte Aussagen unverbindlich sind, erwirbt er Schadensersatzansprüche (aus positiver Vertragsverletzung), soweit er in seinem berechtigten Vertrauen auf die Richtigkeit der Aussagen enttäuscht wird und hierdurch Schaden erleidet.
Gefährlicher Spielraum
Aber auch ein derartiger Hinweis in den Lieferbedingungen nützt nichts, wenn einzelne Mitarbeiter im Eifer verbindliche Zusagen machen, die insoweit als Individualvereinbarungen den konkret geschuldeten Leistungsumfang erweitern. Diese konkrete "Mehr" an Leistung wird in der Regel auch nicht ohne weiteres von den vorformulierten Klauseln zur Haftungsbeschränkung umfaßt, sondern kann zur Haftung des Anbieters auch für leichte Fahrlässigkeit seiner Mitarbeiter bei trennbaren Beratungsleistungen führen. (Die Beratungspraxis zeigt mit manchen haarsträubenden Beispielen, wieviel Spielraum manche Mitarbeiter zu haben glauben. Wie wichtig eine präzise rechtliche Beurteilung ist, wird häufig übersehen.)
Ein Ausweg besteht darin, ausdrücklich die Haftung für leichte Fahrlässigkeit (leichtes Verschulden) auch bei positiver Vertragsverletzung und Verschulden bei Vertragsschluß auszuschließen. Ein solcher Ausschluß gerade für Verschulden bei Vertragsschluß nützt aber dann nichts, wenn der Kunde von den Allgemeinen Geschäftsbedingungen keine Kenntnis erlangt hat. Dies ist zum Beispiel der Fall, wenn er keinen Vertrag abschließt und deshalb keine Möglichkeit hat, in die Allgemeinen Geschäftsbedingungen/Lieferbedingungen Einsicht zu nehmen. Hier empfiehlt sich zusätzlich ein mündlicher Hinweis. Erscheint dieser Weg als wenig in die Psychologie, des Verkaufsgespräches passender bleibt die weitere Möglichkeit, den AGB-Text in der gültigen Fassung, deutlich sichtbar auszuhängen. Fehlen sowohl Hinweis als auch Aushang, kann sich der Anbieter nicht wirksam auf einen Ausschluß der Haftung für leichtes Verschulden bei Vertragsabschluß berufen.
Probleme definieren
Im allgemeinen nimmt es ein Kunde positiv auf, wenn der Anbieter ihm von vornherein mitteilt, ob eine ausführlichere Beratung erforderlich ist und wieviel sie gegebenenfalls kosten wird. Diesen Kosten sollte das Risiko einer Fehlinvestition gegenübergestellt werden. Fast immer fährt der (insbesondere weniger erfahrene) Kunde dann mit einer getrennten Vergütung für eine (eventuell auch von dritter Seite erbrachte) Beratung besser - übrigens auch der Anbieter. Er investiert nämlich auf eigenes Risiko gelegentlich erhebliche Summen in Vorstudien, Kundengespräche, Personal- und Reisekosten, um den Abschluß eines größeren Vertrages zu sichern, während der Kunde noch nicht einmal die Einsatzbedingungen definitiv festgelegt hat. Vielfach ergeben sich hier Kommunikationsprobleme zwischen der DV-Abteilung, die gerne einen ambitionierten DB-Einsatz ausprobieren möchte, und der Geschäftsleitung, die ein solches Engagement nicht als zwingend ansieht. Diese Unwägbarkeiten des Auswahlprozesses lassen sich weitgehend reduzieren, wenn der Anbieter dem Anwender hilft, dessen Probleme klar und damit lösbar zu definieren, diese Hilfe aber deutlich von dem eigentlichen Vertragsschluß trennt. Übernimmt der Anbieter eine derart separierte Beratung, begründet er bewußt eine überschaubare ("modular" abgegrenzte) Haftung und kann jederzeit feststellen, inwieweit die Ergebnisse der Besprechung mit dem Kunden auf Konzeptionen von Konfigurationen und Datenbanken hinauslaufen, die er leistungsmäßig abzudecken in der Lage ist.
Keine "miracle tools"
Eine solche Strategie führt auch zu Wettbewerbsvorteilen: Viele "Hängepartien" bis zum Vertragsschluß fallen weg, da konkrete Vertragsgespräche erst dann beginnen, wenn alle wesentlichen Rahmenbedingungen feststehen. Die Folge ist, daß die Produkte selbst verbilligt und damit günstiger am Markt angeboten werden können.
Vertragsanbahnungen über Datenbanksysteme und Software-Entwicklungssysteme verlangen gegenwärtig (noch) einen besonders hohen Einsatz des Sales Managements. Vorteile und besondere Einsatzbedingungen solcher Systeme sind den Geschäftsleitungen der als Kunden in Frage kommenden Firmen oft nur in groben Zügen bekannt. Entsprechend ausgeprägt ist die Auskunftsverpflichtung des Anbieters!
Es empfiehlt sich im wohlverstandenen Anbieterinteresse, selbst fortgeschrittene Systeme nicht als "miracle tools" darzustellen, sondern im Hinblick auf die (vor)vertragliche Aufklärungspflicht auch neuralgische Punkte anzusprechen.
Datenbanken werden auf Speichermedien ausgelegt und verbrauchen deren Kapazität unterschiedlich aufwendig (bei 4300 DOS/VSE zum Beispiel insgesamt etwa 28 MB). Anwender haben zwangsläufig nur sehr unklare Vorstellungen, wie hoch dieser "Kapazitätsverbrauch" ausfallen kann.
Code-Übergabe
Für einzelne Funktionen wie Data Dictionaries sollte deshalb deutlich gemacht werden, wie viele MB sie verbrauchen, welche Auswirkungen auf die Responsezeit bestehen und in welchen Fällen ihr Einsatz einen echten Vorteil bringt.
Der Wartungsaufwand muß ebenfalls im voraus abgeklärt und fixiert werden. Bietet der Hersteller beziehungsweise Lieferant gleichzeitig auch Service an, sollte er im eigenen Interesse keine Update-Komponenten in Query-Sprachen aufnehmen.
Begriffe wie Kalt- und Warmstart werden noch immer unterschiedlich gebraucht. Der Bezug zu Before-image- und After-image-Kopien und die Notwendigkeit, für den Fall des Systemzusammenbruchs auf Sicherungsbänder zurückzugreifen, ist ebenso darzustellen wie der zusätzliche Speicher- und Kostenaufwand und die beste Wahl im jeweiligen Anwenderkontext.
Sehr restriktiv geben sich die Anbieter bei der Übergabe des Sourcecodes. Zumindest für den Fall, daß Firmen illiquid werden und den nutzungsberechtigten Anwendern ohne diesen Sourcecode weitere Programmpflege (in eigener und auch in fremder Regie) nicht mehr möglich ist, sollten den Anwendern die Sourcecodes überlassen werden, allerdings unter der ausdrücklichen Anwenderverpflichtung, den Code nicht Dritten zur weiteren Verwendung zugänglich zu machen.
Für laufende Nutzungsüberlassungsverträge sollte genau definiert werden, welcher Hardwarewechsel möglich und in welchen Rechenzentren die überlassene Software zugelassen ist. Völlig offen ist bei solchen vertraglichen Begrenzungen auf ein Rechenzentrum sehr oft, ob andere Anwender die Programme im Wege der DFÜ nutzen dürfen. Nur bei ausdrücklichem Ausschluß im Vertrag wird dies zu verneinen sein. Weder wird nämlich die Software selbst auf einer anderen Anlage verwendet, noch wird das Programm weitergegeben. Entscheidend dürfte hier wohl die Unterscheidung sein, ob der Dritt-User nur Aufgaben an den Vertragspartner des Anbieters übermittelt und, ohne nähere Kenntnis des Programmes, Lösungen zurückübermittelt erhält, oder ob er mit den Programmen selbst Lösungen erarbeitet. Nur im letzteren Fall liegt eine unmittelbare Nutzung der Software durch Dritte vor, die vertraglich ausgeschlossen ist.
Wichtig für den Anwender sind weiter die Umstellungen eigener Programme. Diese kosten oft erhebliche Zeit, die durch getrennte Voranalysen der vorhandenen Programme verkürzt werden kann. Analysen helfen auch bei der Beurteilung, in welchem Umfang gezielte Schulung notwendig ist. Auch hierfür sind rechtzeitige Vereinbarungen oder zumindest ein schriftlich fixierter Hinweis des Anwenders auf die Schulungsnotwendigkeit erforderlich.
Datenstandardisierung
Besondere Vorsicht empfiehlt sich Anbietern relationaler Datenbanken. Diese neue und kritisch diskutierte Vorgehensweise in der DB-Konzeption muß bei den Kunden derzeit (noch) mit viel Skepsis fertig werden.
Besonders die Umstellung bereits vorhandener hierarchischer Datenbanken wirft Probleme auf: Die Datenstandardisierung kann leicht mehrere Mannjahre verschlingen, besonders, wenn sehr viele Datenredundanzen in den Nichtschlüsseldomänen vorliegen. Vor irgendwelchen Zusagen sollte der Anbieter deshalb genau klären, welchen Grad der Normalisierung der Anwender bereits erreicht hat und welche Datenmengen noch in die Normalform zu überführen sind. Erweist sich der Kunde nicht bereits auf Anhieb als ausgesprochener Experte, muß der Anbieter seinen Kunden über diese Fragen im eigenen Interesse ausführlich aufklären.
Übernimmt der Anbieter die Umstellung, so geht er in aller Regel eine werkvertragliche Verpflichtung ein, auch wenn er laut Vertrag nur Software verkauft. Entscheidend ist dann nicht der Standardwortlaut des Vertrages, sondern die tatsächlich versprochene und geschuldete Leistung.
Abnahme schuldet der Kunde erst dann, wenn die Umstellung vollständig und fehlerfrei durchgeführt ist. Aus Kostengründen wird man sich, soweit machbar, auf die anbieterseitige Normalisierung vorher ausgewählter repräsentativer Programmfunktionen beschränken, wobei auch festgehalten werden sollte, wer die Auswahl trifft und bis zu welchem Zeitpunkt Änderungen möglich sind. In diesem Fall ist freilich auch nur eine selektive Funktionsprüfung möglich. Deren erfolgreicher Abschluß muß aber den Beginn der ungeteilten Gewährleistungsfrist für die gesamte Software und die Fähigkeit der geschuldeten Zahlung auslösen.
Zurückhaltung ist weiter bei der Beurteilung angebracht, welche Vorteile die Einführung von relationalen Datenbanken für deren Einsatz in der Fertigungsstruktur,
Auftragsverwaltung etc. des Betriebes hat. Die vielzitierte und bisher noch wenig bewältigte "Software-Krise" zeigt, daß die Anbieter sehr häufig noch nicht über ausreichend branchenspezifische Kenntnisse verfügen, um auch nur tragfähige eigene Analysen durchführen zu können. Die Kundenanforderungen, die wiederum ohne genaue Kenntnisse der Systemspezifika nicht hinreichend formulierbar sind, können deshalb nur in einem mühseligen Trial- und Error-Prozeß eruiert werden. Dem Kunden muß folglich bewußt gemacht werden, daß er ein eigenes Restrisiko zu tragen hat. Bleibt dieses unerwähnt, entsteht beim Anwender ein uneinlösbarer Vertrauensüberschuß, der den Anbieter teuer zu stehen kommen kann.
Zu warnen ist hierbei insbesondere vor voreiligen Schlüssen, wie sie zuweilen an der "Vertriebsfront" gezogen werden: Bekannte Installationen in derselben Anwenderbranche erscheinen zwar vergleichbar, sind es jedoch in versteckten, aber entscheidenden Details nicht. Hier liegen reichlich Fußangeln für zusicherungsfreudige Mitarbeiter.
Auftragsumfang steuert Beratungsrisiko
Der Anbieter sollte immer den Kunden fragen, ob dieser seine betrieblichen organisatorischen Abläufe nicht einfacher gestalten kann und ob eine volle Systemauslegung für die in absehbarer Zeit verfolgbaren Betriebsziele erforderlich ist. Bei begrenzterem Einstieg sinkt zwar (unter Umständen) der Auftragsumfang, aber auch das unumgängliche Beratungsrisiko, da es beide Seiten mit leichter überschaubaren Systemeinheiten zu tun haben.
Zumindest angesprochen werden sollte die Problematik, in welcher Art und Weise eine geplante DB-Umstellung rückgängig gemacht werden kann, welcher Zeitaufwand notwendig ist (hier genügt nicht die Umstellung einer repräsentativen Funktionenauswahl!) und wer diese Rückumstellung zu welchen Kosten durchführen würde.
Präzise Formulierung vermeidet Ärger
Was als vertraglich relevanter Mangel anzusehen ist, läßt sich bei Datenbanken nicht ohne Schwierigkeiten abschließend definieren. In den einzelnen Funktionen können zunächst immanente Fehler auftreten. Gelingt die Fehlerkorrektur nicht und werden akzeptable Toleranzgrenzen überschritten, sind diese Fehler als Gewährleistungsrechte auslösende Mängel zu qualifizieren. Nehmen wir als Beispiel bestimmte Funktionen von Software-Entwicklungssystemen. Unterstützen sie entgegen den Leistungsspezifikationen nicht oder nur unzureichend die angebotenen Entwicklungsphasen (zum Beispiel Projektdefinition, Komponentenentwurf, Modulimplementierung, Systemintegrierung, Installation, Codierung, Dokumentation und Test, Betrieb und Wartung), so liegt insoweit eine negative Abweichung vor, aus der der Anbieter haftet, sofern diese Abweichung nicht nachweislich erst vom Anwender herbeigeführt wurde (dies zeigt, wie wichtig die Protokollierung der Funktionsprüfung ist).
Weniger eindeutig fällt der zweite Teil der Unterscheidung aus: Gewähr muß auch für Eigenschaften von Datenbanksystemen geleistet werden, die relativ auf datenbankexterne Ziele definiert sind, insbesondere also die betrieblichen Anwendungen. Aus rechtlicher Sicht können prinzipiell beliebige mögliche Eigenschaften zugesichert werden. Es hängt vom Anbieter ab, hier die Grenzen zu ziehen. Dies fällt nicht immer leicht: Er muß einen Mittelweg zwischen den Wettbewerbserfordernissen und drohenden Haftungsrisiken finden. Die allgemein konsentierte Formel, derzufolge man von der Aufgabenstellung über die Software (DBS) zur richtigen Hardware gelangt, kann, obwohl von der Vorgehensweise grundsätzlich adäquat, zur Anbieterfalle werden: Unversehens hat der Hersteller/Lieferant dann bindend eine Aufgabenlösung zugesichert, obwohl er eigentlich nur Datenbank-Software anbieten wollte.
Generell ist festzuhalten, daß der Anbieter, besonders bei der Verwendung von Allgemeinen Geschäftsbedingungen, das Präzisionsrisiko trägt. Je ungenauer er seine Leistung beschreibt, desto schwieriger wird es für ihn sein, seine Verpflichtung und Haftung zu begrenzen und zu kalkulieren.
* Dr. Frank Koch ist Rechtsanwalt in München