Eine ERP-Einführung ist eines der risikoreichsten IT-Projekte, das ein Unternehmen durchführen kann. Wenn das Projekt scheitert, stehen oft sechsstellige Beträge im Raum: für die bereits bezahlte Software, für Beratungsleistungen, für den internen Aufwand und für den entgangenen Geschäftsnutzen. In dieser Situation stellt sich die Frage, wer die Verantwortung trägt und wie sich die eigenen Ansprüche durchsetzen lassen. Ein IT-Gutachten kann hier die entscheidende Grundlage schaffen.
Warum ERP-Projekte scheitern – und warum die Schuldfrage selten einfach ist
ERP-Projekte scheitern nicht über Nacht. Sie erodieren über Monate hinweg, durch eine Kette von Problemen, die einzeln beherrschbar gewesen wären, aber in Summe das Projekt zum Kippen bringen. Die häufigsten Ursachen sind ein unvollständiges oder widersprüchliches Lastenheft, ein Pflichtenheft, das die tatsächlichen Anforderungen nicht korrekt abbildet, mangelndes Projektmanagement auf einer oder beiden Seiten, unzureichende Mitwirkung des Auftraggebers, unrealistische Zeitpläne und eine fehlende oder gescheiterte Datenmigration.
Das Problem für die rechtliche Aufarbeitung: In den meisten gescheiterten ERP-Projekten tragen beide Seiten einen Teil der Verantwortung. Der IT-Dienstleister hat vielleicht eine Standardsoftware als passend verkauft, die für die spezifischen Geschäftsprozesse des Kunden nie geeignet war. Aber der Kunde hat möglicherweise seine Anforderungen nie vollständig spezifiziert, interne Ressourcen nicht bereitgestellt oder notwendige Entscheidungen verschleppt.
Genau diese Gemengelage macht ein IT-Gutachten so wichtig. Denn die Frage, wer welchen Anteil am Scheitern trägt, lässt sich nicht allein durch juristische Argumentation beantworten. Sie erfordert eine technische Analyse, die objektiv feststellt, was vereinbart war, was geliefert wurde, wo die Abweichungen liegen und welche Ursachen sie haben.
Lastenheft, Pflichtenheft, Vertrag: Was der Sachverständige zuerst prüft
Die technische Analyse eines gescheiterten ERP-Projekts beginnt nicht am Bildschirm, sondern am Vertrag. Der IT-Sachverständige prüft zunächst die vertragliche Grundlage, um festzustellen, was überhaupt geschuldet war.
Das Lastenheft beschreibt die Anforderungen des Auftraggebers: Was soll das ERP-System leisten, welche Geschäftsprozesse soll es abbilden, welche Schnittstellen werden benötigt? Das Lastenheft wird vom Auftraggeber erstellt und dokumentiert das „Was“. Es ist die Grundlage für die Angebotslegung und die spätere Beurteilung, ob die Leistung vertragsgemäß erbracht wurde.
Das Pflichtenheft ist die Antwort des IT-Dienstleisters: Wie setzt er die Anforderungen des Lastenhefts mit seiner Software um? Welche Module werden eingesetzt, welche Anpassungen (Customizing) sind nötig, welche Abweichungen vom Standard werden vereinbart? Das Pflichtenheft dokumentiert das „Wie“ und ist in der Regel Vertragsbestandteil.
Die Praxis zeigt: In gescheiterten ERP-Projekten ist die Dokumentenlage häufig lückenhaft. Manchmal existiert kein formales Lastenheft, sondern nur eine Sammlung von Gesprächsprotokollen und E-Mails. Manchmal wurde ein Pflichtenheft erstellt, aber nie formell abgenommen. Manchmal wurde der Vertrag auf Basis einer Vertriebspräsentation geschlossen, ohne dass die konkreten Leistungen präzise definiert wurden. All diese Umstände muss der Sachverständige erfassen und in seine Beurteilung einbeziehen.
Was der IT-Sachverständige konkret untersucht
Nach der Analyse der Vertragslage folgt die technische Untersuchung. Bei einem gescheiterten ERP-Projekt umfasst die Befundaufnahme typischerweise mehrere Bereiche.
Die Funktionsprüfung beantwortet die Frage: Erfüllt die gelieferte Software die im Pflichtenheft vereinbarten Funktionen? Der Sachverständige prüft systematisch, welche Funktionen vorhanden sind, welche fehlen und welche zwar vorhanden, aber fehlerhaft implementiert sind. Bei ERP-Systemen geht es dabei nicht nur um einzelne Bildschirmmasken, sondern um komplexe Geschäftsprozesse, die über mehrere Module hinweg funktionieren müssen: vom Angebot über die Auftragsabwicklung und die Produktion bis zur Rechnungslegung.
Die Prüfung der Datenmigration ist häufig ein neuralgischer Punkt. Viele ERP-Projekte scheitern nicht an der Software selbst, sondern daran, dass die Daten aus dem Altsystem nicht korrekt in das neue System übernommen wurden. Kundenstammdaten mit falschen Zuordnungen, unvollständige Lagerbestände, fehlende Artikelstämme oder inkonsistente Preislisten können den Produktivbetrieb unmöglich machen.
Die Analyse der Projektdokumentation zeigt, wie das Projekt geführt wurde. Gab es regelmäßige Statusberichte? Wurden Probleme eskaliert? Wie wurde mit Change Requests umgegangen? Wurden Meilensteine definiert und eingehalten? Gab es ein formales Abnahmeverfahren für Teilleistungen? Diese Fragen sind entscheidend, weil sie zeigen, ob der IT-Dienstleister seine Sorgfaltspflichten eingehalten hat und ob der Auftraggeber seiner Mitwirkungspflicht nachgekommen ist.
Die Bewertung der Systemarchitektur klärt, ob die gewählte technische Lösung für den konkreten Anwendungsfall überhaupt geeignet war. War das ERP-System grundsätzlich in der Lage, die Geschäftsprozesse des Auftraggebers abzubilden, oder wurden grundlegende Anforderungen von Anfang an nicht berücksichtigt?
Die Mitwirkungspflicht des Auftraggebers: Ein häufig unterschätztes Thema
ERP-Einführungen sind keine Einbahnstraße. Der Auftraggeber hat eine Mitwirkungspflicht, die weit über das bloße Bezahlen hinausgeht. Er muss Anforderungen definieren, Testdaten bereitstellen, Ansprechpartner benennen, Abnahmen durchführen, Schulungen ermöglichen und organisatorische Voraussetzungen schaffen.
In der Praxis ist die Verletzung der Mitwirkungspflicht einer der häufigsten Einwände, die IT-Dienstleister erheben, wenn ein Projekt scheitert. Und nicht selten ist dieser Einwand berechtigt. Ein Sachverständiger prüft daher auch die Leistung des Auftraggebers: Wurden die zugesagten internen Ressourcen bereitgestellt? Wurden Entscheidungen rechtzeitig getroffen? Wurden Testphasen ernst genommen und dokumentiert?
Diese Prüfung ist für den Auftraggeber nicht nur ein Risiko, sondern auch eine Chance. Denn wenn der Sachverständige feststellt, dass der Auftraggeber seinen Mitwirkungspflichten nachgekommen ist, stärkt das seine Rechtsposition erheblich. Umgekehrt hilft eine ehrliche Analyse auch dann, wenn beide Seiten Fehler gemacht haben: Sie schafft Klarheit über die Verantwortungsanteile und damit eine realistische Grundlage für Vergleichsverhandlungen.
Die Schadensermittlung: Was ist der tatsächliche Schaden?
Neben der Frage, wer verantwortlich ist, muss auch der Schaden beziffert werden. Bei gescheiterten ERP-Projekten kann der Schaden aus mehreren Komponenten bestehen.
Die direkten Kosten umfassen die bereits geleisteten Zahlungen an den IT-Dienstleister: Lizenzgebühren, Beratungsleistungen, Customizing-Aufwand, Schulungen und Datenmigration. Wenn das Projekt gescheitert ist und die Software nicht produktiv genutzt werden kann, sind diese Kosten grundsätzlich als Schaden geltend zu machen.
Der interne Aufwand umfasst die Arbeitszeit der eigenen Mitarbeiter, die für das Projekt eingesetzt wurden. Projektleiter, Key-User, IT-Abteilung und Geschäftsleitung investieren bei einer ERP-Einführung erhebliche Zeit. Dieser Aufwand ist quantifizierbar und kann als Schadenposition geltend gemacht werden.
Der entgangene Geschäftsnutzen ist die schwierigste Schadenposition. Das neue ERP-System sollte Prozesse optimieren, Kosten senken, Transparenz schaffen. Wenn diese Vorteile nicht eintreten, entsteht ein Schaden, der sich nur schätzen lässt. Hier kann ein Sachverständiger eine fundierte Bewertung liefern, die auf nachvollziehbaren Annahmen basiert.
Die Kosten der Ersatzbeschaffung fallen an, wenn das gescheiterte System durch ein anderes ersetzt werden muss. Die Kosten für die Auswahl, Implementierung und Inbetriebnahme eines Ersatzsystems können den ursprünglichen Projektwert deutlich übersteigen.
Timing: Wann sollten Sie einen Sachverständigen einschalten?
Die Antwort ist eindeutig: so früh wie möglich. Idealerweise noch bevor das Projekt endgültig für gescheitert erklärt wird.
Es gibt mehrere Zeitpunkte, an denen die Einschaltung eines Sachverständigen sinnvoll ist.
Wenn sich das Projekt in einer Krise befindet, der Go-Live wiederholt verschoben wird und die Kommunikation zwischen den Parteien zunehmend konfrontativ wird, kann ein Sachverständiger eine neutrale Bestandsaufnahme liefern. Diese Bestandsaufnahme kann entweder die Grundlage für eine Rettung des Projekts sein oder für eine geordnete Beendigung.
Unmittelbar nach dem Abbruch des Projekts ist die Dokumentenlage noch frisch, Ansprechpartner sind noch verfügbar und die technischen Systeme sind noch zugänglich. Je länger der Abbruch zurückliegt, desto schwieriger wird die Beweissicherung: Server werden abgebaut, Testumgebungen gelöscht, Mitarbeiter wechseln den Arbeitsplatz.
Vor der Einleitung eines Rechtsstreits sollte ein Privatgutachten die Erfolgsaussichten klären. Ein erfahrener Anwalt wird vor einer Klage wissen wollen, ob die technischen Argumente einer sachverständigen Prüfung standhalten. Ein Privatgutachten liefert diese Grundlage und kann eine unnötige Klage vermeiden oder eine berechtigte Klage auf ein solides Fundament stellen.
Was ein Gutachten für Ihre Rechtsposition bringt
Ein IT-Gutachten zu einem gescheiterten ERP-Projekt liefert drei wesentliche Ergebnisse.
Erstens eine objektive Feststellung des Sachverhalts. Was wurde vereinbart? Was wurde geliefert? Wo liegen die Abweichungen? Diese Fragen werden auf Basis der Vertragsunterlagen, der Projektdokumentation und der technischen Analyse beantwortet, nicht auf Basis von Behauptungen der Parteien.
Zweitens eine Zuordnung der Verantwortung. Welche Fehler hat der IT-Dienstleister gemacht? Wo hat der Auftraggeber seine Mitwirkungspflichten verletzt? In welchem Verhältnis stehen die jeweiligen Beiträge zum Scheitern? Diese Frage erfordert sowohl technische als auch projektmethodische Kompetenz.
Drittens eine nachvollziehbare Schadensermittlung. Wie hoch ist der tatsächliche Schaden? Welche Schadenspositionen sind kausal auf welche Fehler zurückzuführen? Diese Bezifferung ist die Grundlage für jede Vergleichsverhandlung und für jedes Klageverfahren.
Ein solches Gutachten wirkt in mehrere Richtungen: Es stärkt die eigene Verhandlungsposition, es schafft Klarheit über die tatsächlichen Aussichten eines Verfahrens und es signalisiert der Gegenseite, dass die Ansprüche fachlich fundiert untermauert sind. Nicht selten führt allein die Existenz eines seriösen Gutachtens dazu, dass die Gegenpartei bereit ist, über eine außergerichtliche Einigung zu verhandeln.
Handlungsempfehlungen: Was Sie jetzt tun sollten
Wenn Ihr ERP-Projekt in der Krise steckt oder bereits gescheitert ist, sollten Sie drei Dinge sofort tun.
Sichern Sie die Dokumentation. Sammeln Sie alle Verträge, Lastenhefte, Pflichtenhefte, Projektprotokolle, E-Mail-Korrespondenz, Statusberichte, Change Requests, Abnahmeprotokolle und Rechnungen. Je vollständiger die Dokumentation, desto belastbarer wird ein späteres Gutachten.
Sichern Sie den technischen Zustand. Sorgen Sie dafür, dass die aktuelle Version des ERP-Systems, die Testumgebungen und die Datenbankstände erhalten bleiben. Wenn der IT-Dienstleister den Zugang zu den Systemen sperrt oder die Umgebung abbaut, gehen entscheidende Beweise verloren.
Lassen Sie die Situation fachlich einschätzen. Bevor Sie eine Klage einreichen oder einen Vergleich akzeptieren, sollten Sie die technischen Fakten kennen. Ein IT-Sachverständiger kann Ihnen in einem Erstgespräch eine erste Einschätzung geben, ob ein Gutachten sinnvoll ist und welchen Umfang es voraussichtlich haben wird.
Als allgemein beeideter und gerichtlich zertifizierter IT-Sachverständiger habe ich Erfahrung mit der Begutachtung gescheiterter IT-Projekte. Ich kenne die typischen Muster, die technischen Fallstricke und die Fragen, die Gerichte und Anwälte an ein solches Gutachten stellen. Kontaktieren Sie mich für ein unverbindliches Erstgespräch.