SAP-Projekte unterscheiden sich in zwei Kernpunkten von gewöhnlichen DV-Projekten: Zum einen ist mit der Einführung von SAP-Software wie R/3 und Mysap.com häufig auch eine Änderung der Geschäftsprozesse verbunden. Das erschwert zum Beispiel die Erstellung eines Pflichtenheftes. Außerdem ist der Widerstand der späteren Endanwender größer, da sie sich nicht nur in die neue Software einarbeiten, sondern auch in eine neue Organisation einfinden müssen. Zum Zweiten hat das einführende Unternehmen, der Auftraggeber, es mit einer Reihe von Geschäftspartnern zu tun: neben dem Hardwarehersteller gehören dazu das Beratungsunternehmen, das die Einführung begleitet, zusätzliche Programmierer, die einzelne Komponenten entwickeln, die SAP als Lizenzgeber für die Software und andere.
Das wirkt sich auch auf die Vertragsgestaltung aus. Die vielen verschiedenen Leistungen müssen in mehreren Verträgen beschrieben und gegenseitige Abhängigkeiten berücksichtigt werden. Außerdem gilt es, die unternehmensspezifischen Besonderheiten im Auge zu behalten. Insbesondere bei den Softwarelizenzen ist der Spielraum aber gering. "Die SAP ist bei der Vertragsgestaltung relativ unbeweglich", resümiert Markus Schmidt von der Berliner Kanzlei Heuking Kühn Lüer Wojtek, auf einem Seminar über SAP-Projektverträge, das Management Circle GmbH, Eschborn, veranstaltet hat. Der Rechtsanwalt beschäftigt sich schon lange mit DV-Projekten, speziell auch im SAP-Umfeld.
Immerhin in einem Punkt zeigen sich die Walldorfer mittlerweile aber kompromissbereit: bei den Wartungskosten. Für die SAP-Produkte fällt eine Softwarewartungsgebühr in Höhe von 17 Prozent des Lizenzpreises pro Jahr an, die normalerweise ab dem ersten Monat nach Lieferung fällig wird. Dem steht aber die gesetzliche Gewährleistung gegenüber, bei der ein Hersteller in den ersten sechs Monaten nach Kauf für Mängel an seinem Produkt geradestehen muss. SAP gewährt daher auf Nachfrage während dieser Zeit häufig einen Rabatt von typischerweise 50 Prozent. Vielen Anwendern ist außerdem unbekannt, dass die Übertragung der Nutzung an Dritte nicht in den Allgemeinen Geschäftsbedingungen (AGBs) ausgeschlossen werden darf. Bestehende R/3-Lizenzen können also an andere Unternehmen weiterverkauft werden.
Wegen der Vielzahl an Verträgen und Besonderheiten schließen Auftraggeber und Auftragnehmer, also das Beratungsunternehmen, in der Regel zunächst einen "Letter of Intent" darüber, dass R/3 eingeführt werden soll.
Dies ist kein gesetzlich definierter Vertragstyp, hat aber Vertragscharakter. "Was in einem Letter of Intent geregelt wird, entscheiden die Parteien selbst", bringt es Schmidt auf den Punkt. Es hat daher keinen Sinn, bei den Regelungen hier zu sehr ins Detail zu gehen. Zu den Inhalten einer solchen Absichtserklärung können zum Beispiel der Umfang und die Vergütung der vorvertraglichen Tätigkeiten gehören, wesentliche Inhalte des Hauptvertrags können darüber hinaus festgelegt und Vertraulichkeit vereinbart werden.
Der eigentliche Projektvertrag rund um das SAP-Projekt umfasst dann viele Detailvereinbarungen. Hierzu gehören zum Beispiel technische Spezifikationen, Leistungsbeschreibung und Pflichtenheft, aber auch vorvertragliche Pflichten, zum Beispiel Informationspflichten des Auftraggebers und des Auftragnehmers, die Installation und das Customizing, die zu erstellende Dokumentation, Wartung und Pflege nach Abschluss der Einführung sowie möglicherweise Regelungen für einen Outsourcing-Betrieb. Zur erfolgreichen Abwicklung muss auch der Auftraggeber beitragen. Seine Mitwirkungspflichten bestehen zum Beispiel darin, dass Personal und Räume gestellt sowie bestimmte Entscheidungen im Projektverlauf getroffen werden. Solche Dinge sollten im Vertrag spezifiziert sein.
Migration verlangt kombiniertes Know-howEin Knackpunkt ist die Datenmigration. Hierzu sind nämlich Kenntnisse sowohl von R/3 als auch der bisher eingesetzten Software nötig. Solche Spezialisten sind rar. In der Regel können Mitarbeiter der eigenen DV-Abteilung und des Beratungsunternehmens dieses Know-how nur gemeinsam aufbringen. Wer für die Datenmigration verantwortlich ist und was sie kosten darf, muss unbedingt im Vorfeld geklärt werden.
An der Einführung sind meist mehrere Unternehmen beteiligt. Viele Firmen möchten aber einen Ansprechpartner für den Erfolg des Projekts in die Verantwortung nehmen können. Diese Generalunternehmerschaft lassen sich die R/3-Berater in der Regel fürstlich entlohnen. 20 bis 25 Prozent Aufschlag auf die Subunternehmerkosten sind durchaus üblich.
Ein kritischer Bereich sind nachträgliche Änderungen am ursprünglichen Pflichtenheft. "In jedem mir bekannten R/3-Projekt ist es zu Leistungsänderungen gekommen", warnt Schmidt. Es ist daher absolut notwendig, im Vertrag das Vorgehen bei solchen "Change Requests" (CR) festzulegen. Dabei muss klar geregelt sein, wer welche Änderungen in Auftrag geben darf - insbesondere mit Blick auf die dadurch entstehenden Kosten. Der Appetit kommt häufig mit dem Essen. Der Auftraggeber ist in den Vorverhandlungen in einer sehr viel besseren Position als mitten im Projekt. Daher sollte er die Kosten für mögliche Zusatzleistungen und Ergänzungen schon im Vorfeld, also im Vertrag festschreiben. Auch implizite Abhängigkeiten von verschiedenen Verträgen untereinander sollten frühzeitig erkannt und geklärt werden. Ein typischer Problemfall ergibt sich aus Hardwarekäufen. Wird zum Beispiel ein neuer Server speziell für R/3 beschafft, dann aber nicht mehr benötigt, weil die Standardsoftware doch nicht eingeführt wird, ergibt sich daraus nicht automatisch auch ein Rückgaberecht für den Server. Das Gleiche gilt auch für die R/3-Lizenz. Die Rückabwicklung solcher Käufe sollte daher im Projektvertrag vereinbart werden.
Auch die Gewährleistung ist bei Hardwarekäufen ein Problemkind. Häufig werden neue Rechner in einem frühen Stadium der Einführung beschafft und dienen als Test- und Entwicklungssystem. Sollte sich bei der Produktivsetzung ein Fehler zeigen, der erst im Regulär- oder Massenbetrieb auftritt, ist aber die Gewährleistung in der Regel abgelaufen. Auch solche Probleme lassen sich durch eine geschickte Vertragsgestaltung vermeiden.
Im Umgang mit dem Beratungsunternehmen ist darauf zu achten, ob es sich um einen Werk- oder einen Dienstvertrag handelt. Bei einem Dienstvertrag ist der Berater nur für die reine Tätigkeit verantwortlich, nicht aber für den Erfolg seiner Arbeit. Daher favorisieren die SAP-Beratungshäuser diese Vertragsform. Besser für den Auftraggeber ist allerdings ein Werkvertrag. Dieser ist erst dann erfüllt, wenn das Werk erfolgreich abgeschlossen ist, also die Einführung oder Teile der Projekte. Auch die Vergütung wird erst mit der erfolgreichen Abnahme fällig. Nachbesserung und Schadensersatz sind gesetzlich geregelt.
"Die Gerichte bewerten einen Vertrag nach seinem Inhalt. Daher sind R/3-Projektverträge in der Regel als Werkverträge anzusehen, auch wenn Dienstvertrag darüber steht", beruhigt Schmidt. Trotzdem befinden sich die Auftraggeber auf der sicheren Seite, wenn der Vertrag bereits entsprechend deklariert ist. In der Praxis wird es ohnehin zu Mischformen kommen, bei denen Teile des Projekts als Dienstleistung abgewickelt werden, während bei anderen der Erfolg und damit die Abnahme das entscheidende Kriterium sind.
Bereits im Vorfeld sollte festgelegt werden, wer das Projekt abnimmt und was die Kriterien für seinen erfolgreichen Abschluss sind. Auch die Gerichte haben mittlerweile eingesehen, dass es keine fehlerfreie Software gibt. Daher empfiehlt es sich, eine Kategorisierung der möglichen Problemfälle anzulegen. "Das Abnahmeprotokoll ist eines der wichtigsten Dokumente bei einem R/3-Projekt", betont Schmidt.
Die Einführung von R/3 bringt immer bedeutende Änderungen in einem Unternehmen mit sich. Davon sind auch die Arbeitnehmer betroffen, und daher ist ein solches Projekt normalerweise mitbestimmungspflichtig. Eine frühzeitige Einbeziehung des Betriebsrats ist nach Erfahrung von Projektverantwortlichen entscheidend für eine reibungslose Einführung. Außerdem erhöht dies die Akzeptanz unter den Mitarbeitern.
Juristische Hilfe oft unentbehrlichSollte ein R/3-Projekt trotz intensiver Vertragsgestaltung und allen Engagements zu scheitern drohen, geht es oft nicht mehr ohne Juristen. "Ohne anwaltliche Unterstützung ist ein Anwender in der Regel nicht in der Lage, eine formal korrekte Fristsetzung mit Ablehnungsandrohung zu formulieren", warnt Schmidt. Allerdings, und auch das lässt sich im Vorfeld vereinbaren, muss nicht jede Auseinandersetzung zum Scheitern des Projekts führen. Das Eskalations-Mangement sollte vertraglich geregelt sein. Es ist Bestandteil der Projektorganisation. Selbst für den Fall, dass nichts mehr geht, lässt sich vorsorgen, indem Schadensersatz, Vertragsstrafe und Ähnliches schon im Projektvertrag geklärt sind.
Projekt-Tipps- Bei der Organisation sollte das eigene Unternehmen die Oberhoheit behalten. Dazu gehören auch Kleinigkeiten, zum Beispiel, wer die Protokolle schreibt.
- Bei den Lizenzkosten ist der Spielraum gering. Aber bei der Wartung ist SAP mittlerweile offen für eine Preisreduzierung während der gesetzlichen Gewährleistungspflicht von sechs Monaten.
- Die Datenmigration ist immer ein kritischer Bereich. Spezialisten aus dem Unternehmen und des Beraters müssen eng zusammenarbeiten. Wer wofür verantwortlich ist, sollte genau geregelt sein.
- Damit Änderungen im Projekt nicht zur Kostenfalle werden, sollten absehbare Zusatzleistungen schon im Vorfeld preislich festgelegt werden. Außerdem muss klar sein, wer über Änderungen und die damit verbundenen Kosten entscheidet.
- Ein SAP-Projekt umfasst viele Einzelverträge, die zum Teil implizite Abhängigkeiten aufweisen. Das kann zum Beispiel extra für R/3 beschaffte Hardware betreffen. Für den Fall einer Rückabwicklung muss auch deren Rückgabe geregelt sein.
- Beratungsunternehmen favorisieren einen Dienstvertrag, da sie dann für den Erfolg des Projekts nicht geradestehen müssen. Besser für Anwender ist aber ein Werkvertrag, der den Erfolg zur Bedingung dafür macht, dass der Vertrag als erfüllt gilt.
- Die Abnahme ist einer der wichtigsten Augenblicke bei einer Einführung. Schon im Vorfeld sollte festgelegt sein, welche Kriterien für eine erfolgreiche Abnahme angelegt werden und wer diese vornimmt.
- Damit unternehmensinterne Konflikte das Projekt nicht gefährden, sollte der Betriebsrat frühzeitig in die Einführung einbezogen werden.
ProjektorganisationDie richtige Organisation ist entscheidend für den Erfolg der R/3-Einführung. Daher werden die wichtigsten organisatorischen Einheiten und deren Besetzung im Projektvertrag festgelegt.
- Der Lenkungsausschuss entscheidet über das Gesamtprojekt. Er trägt die Verantwortung für das betriebswirtschaftliche Konzept und die daraus resultierenden Anforderungen an die Software.
- Die Projektleitung plant und steuert das Projekt inklusive Schulungen im Rahmen des vorgegebenen Budgets. Sie ist für die konkrete Realisierung verantwortlich und überwacht zum Beispiel Termine, Kosten und Konzept.
- Kernteams für verschiedene Aufgabenbereiche kümmern sich um einzelne betriebswirtschaftliche Komponenten. Sie erstellen das Fachkonzept und wachen über die fachliche Umsetzung in ihrem Bereich.
Wichtig ist, dass die entscheidenden Positionen in der Projektorganisation intern besetzt werden. Zum Beispiel ist es nicht selten entscheidend, wer die Sitzungsprotokolle schreibt. Die in diesen Bereichen angebotenen Leistungen eines Beratungsunternehmens sollten genau hinterfragt werden.
Abb.1: Verlauf eines Einführungsprojekts
Eine klare Projektorganisation vermeidet Probleme. Quelle: Plaut Consulting
Abb.2: Projektorganisation
Alle Mitwirkenden sollten wissen, wer wofür zuständig ist. Quelle: Plaut Consulting