In Zeiten der digitalen Transformation deutscher Unternehmen führen diese zahlreiche IT-Projekte durch. Die meisten Unternehmen erwerben dabei eine Softwarelizenz (Kauflizenz) oder ein zeitlich begrenztes Nutzungsrecht an der Software (Software as a Service) und implementieren diese im Unternehmen bzw. der Unternehmensgruppe oder in einer vom Anbieter oder dem Unternehmen betriebenen oder gemieteten Cloud. Klassische Beispiele solcher größeren IT –Projekte sind die Einführung von Enterprise Resource Planning („ERP“)-, Customer Relation Management („CRM“)- oder Human Capital Management („HCM“)-Systemen sowie einer Lieferantenmanagement-Plattform. Diese häufig kostspieligen IT-Projekte werden intensiv und lang vorbereitet und umgesetzt. Gleichwohl ist ihr Scheitern in vielen Fällen leider keine Ausnahme. Weit überschrittene Projektpläne und Budgets geben dem jeweiligen Projekt oft den Rest. Und dies obwohl das IT-Projekt sinnvoll ist und die Prozesse und Abläufe im Unternehmen oder in der Unternehmensgruppe erleichtern und optimieren würde. Aber warum scheitern so häufig sinnvolle IT-Projekte?
Dieser Beitrag befasst sich mit den klassischen Stolpersteinen von IT-Projekten und erläutert, wie man diesen bereits im Vertrag mit entsprechenden Regelungen begegnen kann.
Vertragsdokumente
Dazu wird zunächst erläutert, welcher Vertrag üblicherweise bei einem größeren IT-Projekt abgeschlossen wird und welche Regelungen dieser in der Regel enthält. Neben dem Hauptvertrag gibt es meist noch weitere Vertragsdokumente. Auch diese sollen im Folgenden kurz beleuchtet werden, bevor die Stolpersteine und sinnvollen Regelungen zu deren Vermeidung dargestellt werden:
Hauptvertrag
In der Praxis kauft oder mietet das Unternehmen oder die Unternehmensgruppe ein Softwareprodukt und lässt es entweder durch den Softwareanbieter oder einen Dritten (im Folgenden insgesamt der „Implementierungspartner“) implementieren entweder im eigenen Rechenzentrum oder in einer Cloud. Die meisten größeren IT-Projekte bestehen aus verschiedenen Projektphasen. Häufig kommt es auch zu einem zeitlich versetzten Roll Out in der gesamten Unternehmensgruppe. Daher bietet sich in den meisten Fällen der Abschluss eines IT-Projekt-Rahmenvertrages („Rahmenvertrag“) an. Denn ein Rahmenvertrag regelt die grundsätzliche Zusammenarbeit der Parteien, in dem er bestimmte Rahmenbedingungen festlegt, die auf alle unter dem Rahmenvertrag abgeschlossenen Einzelverträge (z.B. in Form eines SOW oder einer Bestellung – dazu sogleich) Anwendung finden. Der Rahmenvertrag regelt typischerweise allgemeine Anforderungen an die Leistung, Mitwirkungspflichten des Unternehmens, den Verzug, die Gewährleistung und Haftung des Implementierungspartners sowie die Abnahme, sofern es sich bei den Implementierungsleistungen oder ggf. sonstigen Leistungen um Werkleistung i.S.d. § 631 BGB handelt. Bei Werkleistungen wird im Unterschied zu Dienstleistungen ein Erfolg geschuldet. Indizien für eine Werkleistung sind die Vereinbarung eines Festpreises sowie Regelungen zur Abnahme. Erbringt der Implementierungspartner Leistungen auf der Basis „Time and Material“ spricht dies eher für eine Dienstleistung.
Soll über den Rahmenvertrag auch die Software gekauft oder gemietet werden, sollte dieser ebenfalls Regelungen zum Lizenz- bzw. Nutzungsumfang sowie zum Support, zur Wartung und den Service Leveln (z.B. zu Reaktionszeiten und bei Implementierung in der Cloud zur Verfügbarkeit) enthalten.
Statement of Works und Bestellungen
Neben dem Rahmenvertrag gibt es sog. Statement of Works („SOW“). Dabei handelt es sich um die eigentliche Leistungsbeschreibung. Im SOW wird also festgelegt, welche Leistungen der Implementierungspartner in der jeweiligen Projektphase erbringt. Häufig enthalten SOWs auch den Zeitplan der jeweiligen Projektphase. Das SOW kann zugleich die Einzelbestellung unter den Rahmenvertrag darstellen. Die Organisation mancher Unternehmen fordert ggf. darüber hinaus die Auslösung einer Bestellung aus dem jeweiligen ERP-System des Unternehmens. Erst der Einzelvertrag – ob in Form des SOWs oder einer Bestellung – löst Leistungs- und Zahlungspflichten der Parteien aus.
Auftragsverarbeitungsvertrag
Verarbeitet der Implementierungspartner und/oder der Softwareanbieter personenbezogene Daten des Unternehmens auf dessen Weisung und in dessen Auftrag ist zusätzlich ein Auftragsverarbeitungsvertrag abzuschließen.
Stolperstein 1: Unklare und widersprüchliche Vertragsgestaltung
Klare und eindeutige vertragliche Regelungen, bei denen alle Vertragsdokumente ineinandergreifen, tragen zum Erfolg des IT-Projekts bei. Beide Parteien müssen zu jedem Zeitpunkt im Projekt wissen, wer welche Leistungen bzw. Mitwirkungshandlungen zu welchem Zeitpunkt erbringen muss (dazu auch Stolperstein 5). Daher sollte das SOW nur rechtliche Regelungen z.B. zur Haftung oder zur Rechtsfolge bei verspäteten oder unterlassenen Mitwirkungspflichten enthalten, wenn im Einzelfall von beiden Parteien ausdrücklich eine Ausnahme von der oft lang und intensiv verhandelten Regelung im Rahmenvertrag gewollt ist. Da die Rechtsabteilung oder externen Rechtsberater häufig nur in die Verhandlung des Rahmenvertrags eingebunden sind und die SOWs primär im Projektteam abgestimmt werden, empfiehlt es sich, dass der Rahmenvertrag die rechtlichen Bedingungen abschließend regelt. Andernfalls besteht das Risiko, dass im Laufe des IT-Projekts unbemerkt Widersprüche zwischen SOW und Rahmenvertrag entstehen.
Im Rahmenvertrag sollte auch eine Rangfolge zwischen den einzelnen Vertragsdokumenten festgelegt werden und der Rahmenvertrag dem SOW vorgehen. Es bietet sich zusätzlich an, während der Rahmenvertragsverhandlungen ein Muster-SOW zu vereinbaren, das dem Rahmenvertrag als Anlage beigefügt wird. Dieses sollte schon keinen Raum für die abweichende Vereinbarung rechtlicher Regelungen geben, in dem das Dokument vor allem Leistungen, Mitwirkungspflichten und Meilensteine definiert und etwa per Kommentar klarstellt, dass rechtliche Rahmenbedingungen abschließend im Rahmenvertrag geregelt sind und es somit keiner Regelung im SOW bedarf. Auf diese Weise wird sichergestellt, dass das Projektteam nicht unbemerkt und aus Versehen zum Rahmenvertrag abweichende oder widersprüchliche Regelungen im SOW aufnimmt.
Und was ist eigentlich mit der Geltung von Allgemeinen Geschäftsbedingungen der Parteien? Deren Geltung sollte ausgeschlossen werden. Wozu haben die Parteien schließlich oft über mehrere Wochen und Monate intensiv den Rahmenvertrag verhandelt, wenn am Ende der Satz „es gelten unsere Einkaufsbedingungen“ in der Bestellung dazu führt, dass die Parteien im schlimmsten Fall gar nichts vereinbart haben. Am besten derartige Sätze werden aus der Bestellung gestrichen, sofern das jeweilige ERP-System so viel Individualismus zulässt. Im Rahmenvertrag sollte jedenfalls geregelt werden, dass Allgemeine Geschäfts- und Einkaufsbedingungen selbst für den Fall ausgeschlossen werden, dass diese von einer der Parteien in einem späteren Dokument, z.B. der Bestellung einbezogen werden.
Stolperstein 2: Kein „richtiger“ Leistungsgegenstand durch ungenaue Anforderungen
Die eindeutige Regelung der Leistungen, die der Implementierungspartner in den verschiedenen Projektphasen zu erbringen hat, erfolgt im SOW und ist für das Gelingen des Projekts entscheidend.Die Leistung kann umso detaillierter beschrieben werden, je besser das Unternehmen zuvor seine Anforderungen an die IT-Lösung definiert hat.
Viele IT-Projekte scheitern in der Praxis am fehlenden Anforderungsmanagement. Oft werden Anforderungen von Mitarbeitern aufgestellt, die später gar nicht an der Durchführung des Projekts beteiligt sind. Im Vorfeld ist im Unternehmen gut zu überlegen, wer die Stakeholder des jeweiligen IT-Projekts sind, diese sollten in Workshops die Anforderungen im Team gemeinsam entwickeln. Bei neuartigen Softwareprodukten und aufgrund des Projektcharakters kann eine genaue Leistungsbeschreibung ggf. schwierig sein, weil sich diese z.B. im Projekt erst entwickelt oder oft ändert. In diesen Fällen oder auch insgesamt können neben einer genauen Leistungsbeschreibung auch sog. Catch-All-Klauseln helfen, sofern diese beim Implementierungspartner durchsetzbar sind. Diese verpflichten den Implementierungspartner dazu, alle für die Implementierung der Software erforderlichen Leistungen zu erbringen. Auf diese Weise kann kein Streit über den vereinbarten Leistungsumfang aufkommen, macht das Projekt aber ggf. teurer, weil die Preiskalkulation für den Implementierungspartner schwieriger ist.
Stolperstein 3: ungenaue Abnahmeprozesse
Werden Anforderungen nicht richtig definiert, ist es nicht selten, dass es auch an einem präzisen Abnahmeprozess fehlt. Einer Abnahme bedarf es nur bei Werkleistungen (siehe oben unter Hauptvertrag). Die Abnahme ist präzise zu regeln, da diese von großer rechtlicher Bedeutung ist. Die Gewährleistungsfrist fängt mit der Abnahme an zu laufen. Oft hängen weitere Zahlungen von der Abnahme ab.
Bei komplexen IT-Projekten können Tests sinnvoll sein, die der Abnahme vorangehen und im Rahmenvertrag ausführlich geregelt werden sollten. Die Abnahme ist bei erfolgreichem Test zu erklären. Dabei kann es ferner empfehlenswert sein, Fehler, die bei der Abnahme bzw. dem Abnahmetest auftreten können, zu klassifizieren z.B. nach High, Medium und Low. Denn nach dem Bürgerlichen Gesetzbuch darf eine Abnahme bei unerheblichen Mängeln nicht verweigert werden. Aber was bedeutet dies konkret bei einem IT-Projekt? Über Fehlerklassen lässt sich etwa der unerhebliche Mangel definieren und Streit im IT Projekt vermeiden.
Stolperstein 4: Fehlende und falsche Projektkommunikation
Die richtige Kommunikation im IT-Projekt trägt ebenfalls zu dessen Gelingen bei. Dabei sollte im Rahmenvertrag die Zusammenarbeit näher spezifiziert werden. Dazu legen die Parteien Gremien und dessen Mitglieder fest, die in bestimmten Zeitintervallen tagen. Bewährt hat sich zumindest einen regelmäßigen Jour Fix des Projektteams sowie einen Lenkungsausschuss mit den fachlichen Vorgesetzten zu vereinbaren. Der Lenkungsausschuss sollte vor allem immer dann zusammenkommen und Entscheidungen treffen, wenn das Projektteam nicht weiterkommt.
Damit diese regelmäßigen Treffen sinnvoll genutzt werden können, sollten diese gut vorbereitet werden. Üblicherweise ist der Implementierungspartner für die Vorbereitung durch Versendung einer Agenda und ggf. Vorbereitung einer Präsentation zuständig. Der Implementierungspartner sollte auch von jedem „offiziellen“ Treffen der vertraglich vereinbarten Gremien ein Protokoll anfertigen. Diese sind vom Unternehmen sorgfältig zu lesen und Widerspruch einzulegen, falls das Unternehmen der Auffassung ist, dass Gesprächsinhalte des Treffens nicht richtig oder vollständig wiedergegeben sind. Dieser Ablauf ist im Rahmenvertag zu regeln. Dieser sollte auch festlegen, dass Inhalte von Protokollen nur bei Unterzeichnung durch beide Parteien Rechtswirkungen entfalten können (dazu auch Stolperstein 5).
Stolperstein 5: Fehlendes Projektmanagement
Projekte können sehr dynamisch ablaufen und oft ist der Zeitdruck hoch. Daher ist ein gutes Projektmanagement das A & O. Der Rahmenvertrag sollte u.a. vorsehen, dass nur schriftliche Vereinbarungen in Form von förmlichen Change Request-Verfahren insbesondere den Leistungsgegenstand, Meilensteine und die Vergütung ändern können. Andernfalls könnten bloße E-Mails, die sich das Projektteam vermutlich täglich zigfach hin und her schickt sowie auch nicht unterschriebene Protokolle von Treffen der Parteien den Leistungsgegenstand, die Leistungszeit sowie die Vergütung ändern. Im Laufe des IT-Projekts birgt ein solch nicht gemanagtes Verhalten das hohe Risiko, dass keiner der am IT-Projekt Beteiligten mehr nachvollziehen kann, welche Leistungen zu welchem Zeitpunkt geschuldet sind.
Nur bei einem guten und sauberen Projektmanagement, zu dem auch eine saubere Dokumentation gehört, kann das Unternehmen, wenn es hart auf hart kommt, etwaige Ponälen im Verzugsfall (dazu Stolperstein 7) oder Schadensersatz wegen Schlechtleistung geltend machen. Die Beweislast, ob ein Anspruch und in welcher Höhe dieser Anspruch besteht, liegt beim Unternehmen als Auftraggeber – eine Bürde, die in der Praxis nicht zu unterschätzen ist – nicht zu Letzt bei sehr dynamischen IT-Projekten. Hier ist Disziplin von allen am IT-Projekt Beteiligten gefordert. Verspätungen und Mängel sind sorgfältig zu dokumentieren. Zur Erleichterung der Projektarbeit können u.a. für Change-Request- und andere Verfahren wie z.B. die Abnahme entsprechende Muster vorgehalten werden.
Stolperstein 6: Hinreichende Qualifikation des Projektleiters
Bei der Durchführung des IT-Projekts ist der Projektleiter, den der Implementierungspartner stellt, ebenfalls entscheidend für den Projekterfolg. Dieser muss die fachlichen Kompetenzen mitbringen und alle am IT-Projekt Beteiligten führen können. Das Unternehmen kann im Rahmenvertrag auf eine Regelung bestehen, dass der Implementierungspartner nur hinreichend qualifizierte, geschulte, mit dem IT-Projekt vertraute Mitarbeiter in dem IT-Projekt einsetzen darf, deren Qualifikation er etwa durch Zusendung der Lebensläufe und von Fort- und Weiterbildungsmaßnahmen nachweisen muss. Diese Regelung sollte durch das Recht des Unternehmens, den Austausch einzelner Mitarbeiter des Implementierungspartners bei Vorliegen eines wichtigen Grundes zu verlangen, ergänzt werden. Als ein wichtiger Grund sollte die fehlende fachliche Eignung genannt werden. Bei derartigen Regelungen ist ein besonderes Augenmerk auf die richtigen Formulierungen zu legen, um sich nicht der Problematik der Arbeitnehmerüberlassung auszusetzen.
Stolperstein 7: IT-Projekte dauern oft länger als geplant und werden dadurch teurer
Die wenigsten größeren IT-Projekte werden rechtzeitig umgesetzt. Bei der Auswahl des Implementierungspartners sollte im Unternehmen kritisch hinterfragt werden, ob der zu dem Zeitpunkt ohnehin meist nur geschätzte Projektzeitplan und Kostenaufwand realistisch und plausibel sind.
Häufig hat das Unternehmen diverse Mitwirkungspflichten bei Implementierungsprojekten, die nur gemeinsam realisiert werden können. Der Implementierungspartner ist von Informationen und Mitwirkungshandlungen des Unternehmens abhängig. Erfolgt diese nicht, verspätet oder in mangelnder Qualität, bedeutet dies faktisch einen Projektstopp, den das Unternehmen selbst verursacht hat. Im Unternehmen sind daher eigene Ressourcen gut zu planen und einzusetzen. Eine kleine IT-Abteilung wird nur schwer verschiedene größere IT-Projekte parallel stemmen können. Um keine kommerziell bösen Überraschungen zu erleben, ist ein besonderes Augenmerk bei der Vertragsgestaltung auf die Rechtsfolge im Falle der unterlassenen oder verspäteten Mitwirkungspflichten zu legen. Hier sollten sinnvolle „Haftungsbeschränkungen“ vereinbart und der Implementierungspartner zur Information an das Unternehmen über die Auswirkungen der unterlassenen und verspäteten Mitwirkungshandlung verpflichtet werden.
Um den Implementierungspartner zur Einhaltung fest zugesagter Termine bzw. Meilensteine anzuhalten, können Vertragsstrafen („Pönalen“) oder zumindest Regelungen über pauschalierten Schadensersatz im Falle des Verzugs sinnvoll sein. Diese erleichtern es dem Unternehmen im Verzugsfall den Schaden ersetzt zu bekommen, in dem zumindest der Nachweis der Schadenshöhe erlassen und der Implementierungspartner „pauschal“ einen bestimmten Betrag zu zahlen hat (siehe aber Stolperstein 5).
Fazit
Bei umfangreichen IT-Projekten sollte also ein besonderes Augenmerk auf die Vertragsgestaltung gelegt werden, um im besten Fall Stolpersteinen mit Hilfe guter vertraglicher Regelungen begegnen zu können. Darüber hinaus sind IT-Projekte sorgfältig zu planen. Dabei ist es vor allem wichtig, dass alle für das IT-Projekt notwendigen Mitarbeiter des Unternehmens frühzeitig und dauerhaft einbezogen werden und, dass das Unternehmen ausreichend eigene Ressourcen hat, um den Implementierungspartner im erforderlich Umfang zu unterstützen. Hierbei darf die Komplexität nicht unterschätzt werden. Werden dann noch Aufwandsschätzungen und Zeitpläne der einzelnen Implementierungspartner bei deren Auswahl kritisch auf Plausibilität geprüft, kann eigentlich nichts mehr schiefgehen.