ERP-Einkauf: Das Pflichtenheft hat Recht

31.03.2008
Von Jürgen Beckers
ERP-Projekte laufen nicht immer rund, und ihre Kosten ufern oft enorm aus. Das liegt unter anderem daran, dass zu wenig an die juristischen Aspekte gedacht wird.

Zu Beginn der Auswahlphase müssen die bestehenden Geschäftsprozesse eines Unternehmens analysiert werden. Ferner empfiehlt es sich, bereits zu diesem Zeitpunkt darüber nachzudenken, welche Prozesse unvorteilhaft sind und deshalb verändert werden sollten. Die Analyseergebnisse sollten in einem Pflichtenheft dokumentiert werden, um für die Anbietersuche genutzt werden zu können. Im Pflichtenheft sollten auch jene Parameter berücksichtigt werden, die erfahrungsgemäß einen besonderen Einfluss auf die Kosten haben. So kann der Auftraggeber die Anbieter besser vergleichen. Das Pflichtenheft sollte definieren, innerhalb welcher Kostenbudgets (für Lizenz, Beratung, Anpassungen, Individualentwicklungen,

Hier lesen Sie …

auf welche rechtlichen Aspekte es beim ERP-Einkauf ankommt;

warum das Pflichtenheft so wichtig ist und

welches die kritischen Vertragspunkte sind.

Hardware, Umgebungssoftware) das Projekt zu realisieren ist. Und ganz wichtig: in welchem Verhältnis die Unterhaltskosten der Folgejahre zum Umsatz des Unternehmens stehen dürfen, damit das ERP-System wirtschaftlich betrieben werden kann.

Die zentrale Rolle des Pflichtenheftes

Im Pflichtenheft sollte klar ausgewiesen sein, wie Geschäftsprozesse in der ERP-Software abzubilden sind und welche davon in jedem Fall im Standard vorhanden sein müssen. Es sollte die Vorgabe enthalten sein, dass Individualanpassungen mit neuen Release-Ständen kompatibel sein müssen. Andernfalls entstehen hohe Folgekosten, da beim Einspielen eines neuen Release stets wieder neue Individualanpassungen entwickelt werden müssten. Ferner muss festgehalten werden, welches IT-Personal (Qualifikation, Funktion, Anzahl, Wochenstunden) der Auftraggeber bereitstellen kann und in welchem zeitlichen Umfang es für das Projekt verfügbar ist. Falls möglich, sollte auch aufgeführt werden, welche Mitarbeiter einer Fachabteilung in welchem zeitlichen Umfang (Anzahl Wochenstunden) für die Implementierung zur Verfügung stehen. So ist es zum Beispiel notwendig, dass die Mitarbeiter der Buchhaltung dem Personal des ERP-Anbieters zeigen, entlang welchem Schema eine Rechnung bearbeitet wird und wer genau in diesen Arbeitsschritt zu involvieren ist.

Präzise Angaben über die Qualität der Altdaten und Schnittstellen sollten ebenfalls nicht fehlen. Nicht zuletzt ist es wichtig, festzuhalten, wann die Einführung starten soll und wann der Go-Live-Termin vorgesehen ist. Denn das hat Auswirkungen auf die Anzahl der vom IT-Anbieter eingesetzten Berater und auf die Kosten. Angaben zu den Vorgaben für das Lizenzmodell, wie zum Beispiel, welche Organisationseinheiten und Mitarbeiter mit der Software arbeiten sollen und welche Wachstumsraten geplant sind, sind ebenfalls zu empfehlen. Denn wird einmal nicht das für die eigene Organisationsstruktur passende Lizenzmodell vereinbart, können bei Veränderung vereinbarter Lizenzparameter (zum Beispiel durch Firmenaufkäufe, Abspaltungen, Erweiterung der Nutzung auf Tochterunternehmen) sehr schnell Folgekosten entstehen, die die gesamte Finanzplanung sprengen.

Basis für die Angebote

Ein weiterer wichtiger Inhalt des Pflichtenhefts sind Vorgaben für die Erstellung von Formularen und für das Berichtswesen, welche über die ERP-Software abgebildet werden sollen. Wichtig sein können auch gesetzliche Vorgaben (zum Beispiel für die Arzneimittelbranche im Arzneimittelgesetz). Handelt es sich nicht um eine spezielle Branchenlösung, sind solche Gesetze oft nicht automatisch in den Standardprozessen der ERP-Software abgebildet.

Das Pflichtenheft wird in aller Regel den in Frage kommenden ERP-Anbietern übermittelt und stellt die Basis für deren Angebote dar. Damit der Anbieter auch rechtlich an die Inhalte und Vorgaben des Pflichtenheftes gebunden ist, empfiehlt es sich, ihn bei Angebotsanforderung schriftlich darauf hinzuweisen, dass er seine Offerte in jedem Fall unter Berücksichtigung der Pflichtenheft-Vorgaben abgeben muss.

Was ist bei Mehraufwand zu berücksichtigen?

Auch später sollte das Pflichtenheft unbedingt zum festen Vertragsbestandteil gemacht werden, um festzuhalten, unter welchen technischen, kaufmännischen und lizenzrechtlichen Vorgaben der Auftraggeber das ERP-System kauft. Wird es wie beschrieben in die Angebots- und Vertragsstruktur des ERP-Projekts eingebunden, haftet der Anbieter für die Einhaltung aller Punkte im Pflichtenheft. Mehraufwand kann dann nur noch für Punkte geltend gemacht werden, die außerhalb der Vorgaben des Pflichtenheftes liegen. Was ist zu tun, wenn der Anbieter Mehraufwand geltend macht, weil Leistungen vom Auftraggeber verlangt werden, die nicht im Pflichtenheft enthalten waren?

Zunächst ist zu prüfen, ob der Anbieter wirklich Recht hat. Ist das der Fall, stellt sich die Frage, wer für den Fehler verantwortlich war. Hat der Auftraggeber selbst das Pflichtenheft erstellt, muss er den Mehraufwand bezahlen und kann keinen Regressanspruch geltend machen. Hat er hingegen das Pflichtenheft von einer Drittfirma (beispielsweise einem Beratungshaus) erstellen lassen, besteht die Möglichkeit, den entstandenen Mehraufwand der Drittfirma in Rechnung zu stellen, wenn diese bei sorgfältiger Arbeitsweise den Punkt nicht hätte vergessen dürfen. Als Faustregel gilt: je geringer das IT-Know-how des Auftraggebers, desto genauer will die Rechtsprechung Punkte definiert haben, die ein Auftragnehmer bei den Projektanforderungen beachten muss.

Beim Einkauf unbedingt beachten

  1. Vor Anbieterauswahl Erstellung eines umfassenden und hinreichend spezifizierten Pflichtenheftes (eventuell durch Beratungsunternehmen).

  2. Im Pflichtenheft auch Anforderungen für mögliche "Kostentreiber" spezifizieren (wie zum Beispiel Umfang der eigenen Mitwirkungsleistungen, Lizenzkonzept).

  3. Pflichtenheft in der Ausschreibung zur Angebotsgrundlage machen.

  4. Pflichtenheft zum Vertragsbestandteil machen.

  5. Auf vorteilhafte Vertragsgestaltung achten (Achtung bei mehreren Verträgen für ein Projekt).

Die Tücken der Vertragsgestaltung

ERP-Anbieter trennen vertraglich häufig Lizenz, Softwarepflege, Beratung, Customization und Entwicklung. Das hat zur Folge, dass alle Vertragsteile ein eigenes rechtliches Schicksal haben und Fehlleistungen in einem Vertrag nicht notwendigerweise zum Rücktritt vom Gesamtvertragswerk berechtigen. Wenn zum Beispiel ein bestimmter Geschäftsprozess im System nicht so wie vorgegeben abgebildet werden kann, besteht bei dieser Vertragskonstellation die Gefahr, dass der Kunde zwar vom Vertrag über die Customization zurücktreten kann, nicht aber vom Lizenzvertrag. Will man alle Vertragsteile miteinander verbinden, empfiehlt es sich, einen einheitlichen Vertrag zur Einführung eines ERP-Systems zu schließen. Hierin können dann alle Leistungsteile vereint werden. Ist der Anbieter nicht bereit, sich auf eine Vertragseinheit aller Leistungsteile einzulassen, sollte diskutiert werden, inwieweit das daraus resultierende Risiko für den Auftraggeber durch entsprechende Preisnachlässe honoriert wird.

Die Eckpunkte des Vertrages

Neben der Umsetzung der Vorgaben aus dem Pflichtenheft und aus dem kaufmännischen Angebot des Anbieters sind folgende Punkte für die Vertragsgestaltung besonders wichtig:

  1. Verfahren zum Umgang mit Change Requests (Änderungsverlangen).

  2. Voraussetzungen und Folgen für einen Projektausstieg des Auftraggebers (zum Beispiel im Fall von Anforderungen, für die bei Auftragsvergabe noch unklar ist, ob sie sich so im System abbilden lassen, wie der Auftraggeber es wünscht).

  3. Verantwortlichkeiten für Projekt-Management und Überwachung der vertraglichen Vorgaben (einschließlich denen aus dem Pflichtenheft).

  4. Ansprechpartner und Zuständigkeiten.

  5. Beistellungs- und Mitwirkungspflichten des Auftraggebers.

  6. Zeitplan und dazugehörige Meilensteine.

  7. Abnahmekriterien und -verfahren.

  8. Beginn und Leistungsumfang der kostenpflichtigen Softwarepflege. Regelungen zu Kosten und Umfang der Pflege für individuelle Anpassungen.

  9. Service-Levels für die Softwarepflege und die Pflege individueller Anpassungen.

  10. Eventuelle Mindestlaufzeit der Softwarepflege einschließlich individueller Anpassungen sowie Kündigungsmöglichkeiten.

  11. Eskalationsverfahren für Streitpunkte während des Projekts.

(ciw)