Softwareerstellung und Überlassung eines Handbuch

Die früher viel diskutierte Frage, ob die Lieferung des Handbuchs zur Hauptleistungspflicht des Erstellers einer Individualsoftware gehört, ist durch mehrfache BGH-Entscheidungen umfassend geklärt. Ohne Lieferung der erforderlichen Dokumentation ist die gelieferte Software nicht nur mangelhaft, sondern nach ständiger Rechtsprechung der Vertrag noch nicht einmal erfüllt, was juristisch weitreichende Konsequenzen hat. Ist der Vertrag nicht erfüllt, ist der Hersteller im Verzug und kann sich der Besteller durch Fristsetzung und Ablehnungsandrohung vom Vertrag lösen und Schadensersatz fordern. Weiterhin läuft auch die handelsrechtliche Rüge- und -untersuchungspflicht nicht, da diese erst mit vollständiger Ablieferung beginnt. Diese weitreichenden Konsequenzen haben viele Verfahren über mehrere Instanzen hin beschäftigt und sind nunmehr insoweit geklärt.
Noch wenig geklärt ist allerdings, was konkret unter einem Handbuch oder einer Dokumentation der Individualsoftware genau zu verstehen ist. Herrscht auch Einigkeit im theoretischen Bereich dahingehend, dass erst mit Ablieferung des Handbuchs vollständig erfüllt ist (s. o.) so herrscht noch Uneinigkeit wann denn nun, rein praktisch gesehen, dies der Fall ist. Es stellt sich also die Frage, wie denn nun das Handbuch beschaffen sein muss, was es enthalten muss und wie detailliert es zu sein hat, damit es entsprechend der oben referierten BGH-Rechtsprechung auch zur vollständigen Leistungserbringung tauglich ist. In den oben angesprochenen BGH-Entscheidungen war diese Frage nicht von zentraler Bedeutung, da hier jeweils Handbücher erst gar nicht geliefert worden waren.
Was ist jedoch, wenn ein schlechtes oder auch nur ein mittelmäßiges Handbuch geliefert wird? Und was ist überhaupt ein mittelmäßiges und was ein ordnungsgemäßes Handbuch?
Eine gesetzliche Definition hierzu gibt es nicht. Soweit auch vertraglich nichts gesondert vereinbart ist, wird sich also häufig die Frage stellen, ob mit einer übergebenen Dokumentation tatsächlich die vertragliche Hauptleistungspflicht erfüllt ist oder ob hier nicht vielmehr wesentliches noch aussteht.
Neue Hinweise zum erforderlichen Inhalt des Handbuches lassen sich indes einer neuen Entscheidung des BGH vom Ende Februar diesen Jahres entnehmen. Erste Ansätze für eine Richtlinie über den erforderlichen Inhalt eines Handbuchs ließen sich bereits der Grundintention der früheren Entscheidung des BGH entnehmen. Denn dieser gründete die Wichtigkeit des Handbuchs unter anderem darauf, dass erst durch Übergabe des Handbuches das System vom Endkunden nach vorheriger Einweisung auch tatsächlich in Gebrauch genommen und überprüft werden könne. Im Rückschluss lässt sich entnehmen, dass also das Handbuch so konzipiert sein muss, dass mit ihm tatsächlich das System vom Nutzer erschlossen werden kann. Wie aber nun die neue Entscheidung deutlich macht, reicht hierzu jedoch nicht lediglich ein grober Wegweiser durch das System anhand dessen sich der Kunde das System dann im Wesentlichen selbst erschließen muss.
Ausgangspunkt für die Erstellung der Dokumentation, so führt der BGH aus, ist das fertig gestellte Individualprogramm und die konkrete Feststellung:"... welche Funktionen in das System implementiert sind und wie sich diese in ihrer konkreten Erscheinung dem Benutzer, insbesondere bei dessen Kommunikation mit dem Rechner und ihrem Erscheinungsbild auf dem Monitor darstellen."
Weiter führt der BGH aus, diese konkrete Art und Weise, durch die sich das Programm auf dem Rechner des Kunden darstellt entscheidend ist, was "...insbesondere auch die endgültige Fassung der jeweiligen Bildschirmmasken" einschließt ,"...in die der Benutzer seine Eingaben vornehmen soll...".
Die Dokumentation hat also nicht nur ein grobes Raster von den abstrakten Möglichkeiten oder den allgemeinen Funktionalitäten des Programms wiederzugeben und diese sozusagen nur aufzuzählen. Vielmehr kommt es auf das konkrete "Erscheinungsbild auf dem Monitor" des Nutzers an, in der sich das Programm bei diesem darstellt. Diese konkrete Erscheinungsform des Programms aus Sicht des Nutzers ist also der Ansatzpunkt des Handbuchs und von hier aus hat die Dokumentation darzustellen "...welche Schritte der Anwender für die Benutzung des Systems unternehmen muss...".
Die Dokumentation hat also konkret Bezug zu nehmen auf das konkrete Erscheinungsbild des Programms und von dieser Basis aus darlegend dem Benutzer die einzelnen möglichen Schritte unter konkreter Bezugnahme etwa auf die "jeweiligen Bildschirmmasken" einzugehen und dem Benutzer darzulegen, wie und in welchem Umfang er seine Eingaben vornehmen soll, um die jeweiligen Werte dem System mitzuteilen und deren Abarbeitung durch das System zu ermöglichen.
Die Erklärungstiefe die von der Dokumentation gefordert wird, führt der BGH auch dann noch einmal deutlich aus, wenn er etwa bezugnehmend auf die konkrete Darstellung der Funktionalität ausführt: "Von einer Dokumentation kann und darf er (der Benutzer) erwarten, dass ihm auch diese Darstellung in den Bildschirmmasken erläutert wird".
Der BGH geht also von einer durchaus benutzerfreundlichen Fassung eines Handbuchs aus. Diesem ist das Programm so zu erläutern, wie es ihm bei der konkreten Nutzung auf seinem Rechner und Bildschirm entgegentritt und hier insbesondere sind ihm Erklärungen bis hin zu Details der Bildschirmmasken und der Art und Weise der Eingaben mitzuteilen, die er vorzunehmen hat. Weiterhin ist auch die Abarbeitung der Eingabe innerhalb des Systems aus Benutzersicht zu erläutern.
Der Nutzer, so könnte man mit einer Faustformel zusammenfassen, ist also genauso wenig mit der Auflistung von einfachen Schlagworten und Funktionsüberschriften abzuspeisen, wie er sich mit einem Programmierer-Fachchinesisch zufrieden zu geben hat.
Das Programm ist aus Benutzersicht und im Hinblick auf dessen konkrete Erscheinungsform (Bildschirmmaske usw.) darzustellen und zu beschreiben. Ebenfalls sind die vom Benutzer auf dieser Ebene erforderlichen Schritte zu erläutern und die entsprechenden Verarbeitungsgänge zu erklären.