In den letzten Jahren hat sich das Angebot rund um Business Software erheblich weiterentwickelt. Neben immer umfassenderen Funktionalitäten gibt es in allen Aspekten von Business-Software-Systemen immer mehr Optionen, aber auch Partnerprodukte. Aus der klassischen Vision des «All in One»-Systemkonzepts ist die «Business Suite»-Realität entstanden, bei der in aller Regel mehr als ein System zur Lösung eingesetzt werden. Daraus resultiert eine Vielzahl von Wahlmöglichkeiten, die sich für die Kunden an erster Stelle als Fortschritt und Vorteil präsentieren. Sie erlauben es, standardisierte Systeme mit einer grossen Individualität und gut angepasst an die Bedürfnisse des Anwenderunternehmens einzuführen und zu betreiben und gleichzeitig die Vorteile von Standardsoftware zu nutzen. Die Vielfalt an Optionen bringt es aber auch mit sich, dass die Rechte und Pflichten zwischen Auftraggeber und Auftragnehmer immer undurchschaubarer und komplexer werden. Jene werden in der Regel durch Verträge oder vertragsähnliche Konstrukte geregelt. Vertragsmanagement fristet im Rahmen der IT-Governance jedoch eher ein Nischendasein und wird von grobschlächtigen Annahmen und einer eher oberflächlichen Behandlung beherrscht.
Vertrag kommt von vertragen
Rein statistisch gesehen scheitern Business-Software-Projekte noch immer viel zu häufig und dies, obwohl in den letzten zehn Jahren sowohl die angebotenen Systeme als auch die Beratungsdienstleistung immer besser geworden sind. Zentrales Problem sind aber die unterschiedlichen Erwartungen zwischen Auftraggeber und Auftragnehmer, die nicht sauber geklärt werden und sich in den entsprechenden vertraglichen Vereinbarungen nicht wiederfinden. Da die Erwartungen nicht sauber geklärt sind, im Englischen spricht man vom «Management of Expectations», sind häufig auch die Eskalationsmechanismen und -praktiken in Projekten schlecht ausgeprägt. In der Regel wird eine gewisse Missstimmung im Projekt als Unwohlsein abgetan und viel zu lange toleriert. Wenn es dann überhaupt nicht mehr geht, wird nach Rechtsanwälten gerufen, die häufig von den Feinheiten der täglichen Projektarbeit überfordert sind und mit klassischen, juristischen Geschützen agieren. Wo liegen also die Probleme bei den üblichen Verträgen rund um Business-Software-Projekte und mit welchen Ansätzen kann man die Situation verbessern?
Mehr als reine IT-Projekte
Vertragsrechtlich gesehen werden Business-Software-Projekte in vielen Fällen als reine IT-Projekte behandelt. Dieser Umstand ist problematisch und führt in der Umsetzung immer wieder zu Problemen. Anders als bei klassischen IT-Projekten ist der Eigenleistungsanteil des Auftraggebers an Business-Software-Projekten ungleich höher. Die Leistungserbringung und der Projekterfolg sind dabei in nahezu allen Bereichen auf eine produktive Zusammenarbeit von Auftraggeber und Auftragnehmer angewiesen. Ein Business-Software-Einführungsprojekt ist ein komplexes Gemisch unterschiedlichster Leistungsanteile von Auftraggeber und Auftragnehmer. Inhaltlich sind sie so komplex, dass sie sich nicht abschliessend und einfach bezüglich des Leistungs- und Lieferumfangs beschreiben lassen. Ausserdem sind sie in der Projektabwicklung auf ein situatives Reagieren und situatives Planen angewiesen. All diese Punkte führen dazu, dass klassische Werkverträge im Bereich von Business-Software-Einführungsprojekten grundsätzlich als problematisch – aber nicht unmöglich – zu betrachten sind und häufig im juristischen Konfliktfall nicht belastbar sind. Dieser Mangel an Belastbarkeit resultiert dabei nicht aus der juristischen Qualität eines Vertragswerks, sondern aus der Realität der alltäglichen Projektpraxis.
So regeln Verträge typischerweise die Mitwirkungspflichten des Kunden. Egal wie detailliert solche Regelungen sind, sie hinken der Projektpraxis hinterher. Daher werden gerade Business-Software-Einführungsprojekte sehr schnell und von vornherein ausserhalb der im Vertrag festgelegten Regelungen abgewickelt und der Vertrag wird in seiner Anwendbarkeit und in seiner Sanktionswirkung ausgehebelt. Diese Praxisferne oder – um es positiver zu formulieren – Unvereinbarkeit von schriftlichen Regelungen und täglicher Projektpraxis machen die meisten Vertragswerke und insbesondere Werksverträge von Anfang an problematisch in Bezug auf die vertragliche Verbindlichkeit. Gleichzeitig gilt die Umkehrung: Würden – rein hypothetisch – Business-Software-Projekte gemäss den in den ihnen zugrunde liegenden Vertragswerken abgewickelt, also quasi Dienst nach Vorschrift gelebt, so würden die Projekte schon aus projektorganisatorischen Gründen scheitern. Natürlich gibt es in der Praxis auch sehr gute Vertragswerke, aber auch hier gilt: Ausnahmen bestätigen die Regel. Daher ist es wichtig, Business-Software-Projekte nicht als klassische IT-Projekte zu verstehen und nicht einfach auf in der IT übliche Vertragskonstrukte zurückzugreifen.
Vielfalt der Verträge
Wunsch des Kunden ist es letztlich, eine lauffähige und einsatzfähige Business-Software-Systemlandschaft zu realisieren, die seinen Erwartungen in Bezug auf den Leistungsumfang (Scope), den Kostenrahmen (Budget) und den Zeitrahmen (Time) entspricht. In der vertraglichen Praxis wird dieses einfache Ziel in eine Vielzahl von verschiedenen Verträgen, Vereinbarungen und Geschäftsbedingungen zerlegt, die für ein Business-Software-Projekt gelten. Im Kern sind dies Dienstleistungsverträge für Beratung, Realisierung, Programmierung, Installation und alle anderen notwendigen Leistungen, um ein System lauffähig zu machen, sowie Lizenz-
verträge für die eigentliche Business Software, für Basissysteme wie Datenbanken und klassische Ergänzungssysteme (3rd-Party Add-ons) sowie den Kauf von Hardware respektive der notwendigen Leistung für den Systembetrieb, etwa durch Outsourcing oder SaaS. Diese Leistungs-Trilogie wird je Bereich in aller Regel durch mehr als einen Vertrag oder eine vertragsrechtliche Regelung abgebildet. In vielen Projekten sind sich dabei weder der Auftraggeber noch der führende Auftragnehmer im Klaren, welche vertraglichen Regelungen überhaupt alle von einem konkreten Projekt tangiert werden. So werden Verhandlungsergebnisse schnell zur Makulatur, da unklar ist, auf welche Verträge ein Verhandlungsergebnis Anwendung findet. Gelten beispielsweise verhandelte Rabatte für Lizenzen auf alle beschafften Lizenzen oder nur für die Lizenzen des führenden Softwareanbieters? Mit der zunehmenden Bedeutung von Partner-Templates und Middleware ist diese Frage ebenso wichtig wie komplex. Hier zeigt sich ein weiteres Problem, das letztlich ein Wahrnehmungsproblem ist, aber auch als Interessenkonflikt umschrieben werden kann: Während der Auftragnehmer immer alle Leistungen und Verträge meint, reduziert der Anbieter, der den Verkaufsprozess führt, alle Verhandlungsergebnisse auf jene Verträge, die mit ihm direkt geschlossen werden. Auf diesen Umstand angesprochen, kommt meist die lapidare Bemerkung, dass man auf andere Verträge, die letztlich nur vermittelt und de facto mit Dritten geschlossen werden, gar keinen Einfluss hat.
Verträge dienen der Projektführung
Im Bereich von Dienstleistungsprojekten ist wichtig, dass mit einem Vertrag auch die Art und Weise der Projektführung festgelegt wird. Auf Neudeutsch spricht man hier auch von der Projekt-Governance. Dieser Umstand ist zentral, da er letztlich auch klar aufzeigt, wieso ein Dienstleistungsvertrag für ein Business-Software-Projekt nicht eine rein juristische Angelegenheit ist. Praxisnahe Regelungen für die Projekt-Governance sind in vielen Verträgen jedoch eine Seltenheit. Problematisch ist dabei insbesondere, dass die Einführungsmethodik des Softwareanbieters als Basis für eine Projekt-Governance meist deutlich zu kurz greift. Gleiches gilt aber auch für Verträge, die auf klassische Methoden der Software-Entwicklung, etwa das V-Modell, verweisen. Dies ist dahingehend problematisch, da Business-Software-Projekte ja eigentlich Standard-Software-Projekte sein sollten und sich daher nicht allzu sehr an Methoden aus der Individualsoftware-Entwicklung anlehnen können.
Lastenheft für Vertragsgrundlage
Basis für einen Dienstleistungsvertrag ist eine saubere Beschreibung des zu liefernden Leistungsumfangs. Dieser wird in der Regel in einem Lastenheft festgelegt. Dass der in der Praxis gerne und häufig verwendete Begriff Pflichtenheft eigentlich falsch ist, kann hier schon als erstes Symptom betrachtet werden. Ein weiteres Problem der meisten Lastenhefte ist, dass sie zwar dick und umfangreich aber nicht problemadäquat sind. Das grösste Problem ist jedoch, dass die übliche Praxis eine Lastenhefterstellung vor dem eigentlichen Auswahlprojekt und Investitionsentscheid vorsieht. Man nutzt das Lastenheft dabei als Hilfsmittel für den Software-Evaluationsprozess. Solche Lastenhefte werden dann häufig als Vertragsgrundlage genutzt, ohne sie am Ende eines Evaluationsprojektes an die gewonnenen Erkenntnisse und die vereinbarten Leistungskomponenten anzupassen. Dabei kann gerade der Prozess der Lastenhefterstellung dem gemeinsamen Management of Expectations zwischen Auftragnehmer und Auftraggeber dienen. Um aber ein rechtlich auch halbwegs belastbares Dokument zu haben, ist es notwendig, einen risikokonformen Detaillierungsgrad zu wählen. Gerade hier sind häufig bereits wieder Interessenskonflikte vorprogrammiert.
Basis der Lizenzkosten ändert sich
In den letzten Jahren sind die User-Vermassungs-Regeln der Anbieter immer komplexer geworden. Eine einfache Messgrösse und Hilfsmittel ist die Frage nach dem Umfang der Preisliste. Jeder Verkäufer wird dem Kunden dabei in offener Solidarität Kund tun, dass die eigene Preisliste immer länger und unüberschaubarer geworden ist. Diese Intransparenz birgt zahlreiche Risiken, deren Extreme eine klare Unter- oder Überlizenzierung sind. Beide Fälle sind ärgerlich und für den Kunden mit ungeplanten oder unnötigen Kosten verbunden. Problematisch ist auch der Umstand, dass die User-Zahlen immer grösser werden, während der Leistungsumfang pro User eher sinkt. Ein wichtiger technologischer Treiber ist hier die Mobilisierung und die «Bring your own Device»-Welle (BYOD), bei der immer mehr User auch kleine Arbeiten, zum Beispiel Stundenrapporte oder Spesenabrechnung, über ein Business-Software-System abwickeln. Dass hier keine «Full User»-Lizenzpreise tragbar sind, versteht sich von selbst. Wie man sich hier aber auf Dauer vertraglich absichert und der entfachte Funktionalitäten-Hunger der Anwender nicht ständig zu Nachlizenzierungen führt, ist von vornherein und vertraglich zu regeln. Problematisch ist auch der Umstand, dass die meisten Lizenzverträge noch immer von klassischen Besitzmodellen ausgehen – die Software kann dort genutzt werden, wo der Käufer einen Anteil von mindestens 51 Prozent hält – und gleichzeitig über Portale und ähnliche Lösungen die Einbindung von Drittpartnern in das eigene Anwendernetzwerk propagiert werden.
Vertragsmanagement aktiv angehen
Die Liste der typischen Problemfälle rund um Verträge in Business-Software-Projekten liesse sich beliebig fortsetzen. Wie sichert man beispielsweise ein Hardware-Sizing sauber vertraglich ab? Dies ist nicht nur eine Frage von Vertragsklauseln sondern auch des Verfahrensweges. Es ist daher sinnvoll, dass Thema Vertragsmanagement von vornherein in jedem Business-Software-Evaluations-Projekt sauber zu adressieren. Neben einem Fachjuristen ist es dabei durchaus sinnvoll, auch Projekt- und Vertragsexperten zu Rate zu ziehen. In jedem Fall sollte man das Thema frühzeitig angehen und die internen Interessen und Erwartungen abklären. Wenn man nach klassischen Modellen erst nach dem eigentlichen Systementscheid mit Vertragsverhandlungen beginnt, ist es häufig zu spät.
