Zum Inhalt springen

Häufig gestellte Fragen

Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?

Die DIN 69901-5 trennt beide Dokumente klar: Das Lastenheft beschreibt die vom Auftraggeber festgelegte Gesamtheit der Forderungen an Lieferungen und Leistungen, also das Was und Warum, und wird vom ERP-Anwender vor der Anbieterauswahl erstellt. Das Pflichtenheft enthält die vom Auftragnehmer erarbeiteten Realisierungsvorgaben auf Basis des Lastenhefts, beantwortet also das Wie und Womit. In der Praxis verschickt der Auftraggeber das Lastenheft an mehrere Bieter, die daraufhin jeweils ein Pflichtenheft erstellen. Beide Dokumente werden Vertragsbestandteil, sobald sie vertraglich einbezogen werden, weshalb das Pflichtenheft vom gewählten Anbieter formell freigegeben werden sollte.

Wer sollte das ERP-Lastenheft im Unternehmen erstellen?

Die Verantwortung liegt beim Auftraggeber, in der Regel bei einem abteilungsübergreifenden Projektteam aus IT, Fachbereichen und Geschäftsführung, teils ergänzt durch externe Beratung. Die Key User der Fachabteilungen tragen den Großteil der funktionalen Anforderungen bei, da sie die operativen Prozesse am besten kennen. Eine zu späte Einbindung der Fachbereiche zählt zu den häufigsten Fehlern und führt zu kostspieligen Nachträgen. Eine breite, früh angesetzte Beteiligung erhöht zugleich die Akzeptanz des späteren Systems im Betrieb.

Wie lange dauert die Erstellung eines ERP-Lastenhefts?

Für mittelständische Projekte mit etwa 50 bis 200 Anwendern sind drei bis sechs Monate realistisch, größere oder komplexere Vorhaben können sechs bis zwölf Monate beanspruchen. Die Zeit wird vor allem für das Sammeln, Strukturieren und Priorisieren der Anforderungen aus allen Fachbereichen benötigt. Sehr kurz erstellte Lastenhefte bleiben meist zu oberflächlich und liefern keine belastbare Vergleichsgrundlage. Der scheinbare Mehraufwand zahlt sich aus, weil Anbieter ein präzises Lastenheft genauer kalkulieren und so spätere Budgetabweichungen reduziert werden.

Wie werden die Anforderungen im Lastenheft priorisiert?

Bewährt hat sich die MoSCoW-Methode, die Anforderungen in Must-have, Should-have, Could-have und Won't-have einteilt. Als Faustregel sollten die Muss-Anforderungen nicht mehr als rund 60 Prozent des Gesamtaufwands ausmachen, da ein höherer Anteil den Projekterfolg gefährdet; Should-have liegt typischerweise bei 20 bis 30 Prozent und für die Could-have sollte ein Puffer von etwa 20 Prozent eingeplant werden. Ergänzend erhält jede Anforderung ein numerisches Gewicht für die spätere Bewertungsmatrix, in der der Gesamtscore eines Anbieters als gewichtete Summe aus Gewicht und Erfüllungsgrad berechnet wird. Ohne klare Priorisierung wird das Lastenheft zur beliebigen Wunschliste und das Auswahlergebnis kaum noch belastbar.

Soll ich einen externen Berater für das Lastenheft beauftragen?

Bei Investitionen über 250.000 EUR ist eine erfahrene Auswahlbegleitung häufig sinnvoll, weil sie Lehrgeld vermeidet und den Prozess deutlich beschleunigt. Lizenzgebühren machen typisch nur 25 bis 35 Prozent der Gesamtprojektkosten aus, die übrigen 65 bis 75 Prozent entfallen auf Implementierung, Customizing, Schulung und Datenmigration. Wichtig ist, dass der Berater unabhängig und anbieterneutral arbeitet, damit das Lastenheft nicht zugunsten eines Systems verzerrt wird. Cloud-Modelle senken die Anfangsinvestition, verlagern die Kosten aber dauerhaft in die laufenden Betriebsausgaben.

Wie weit darf das Lastenheft vorgeben, welcher Anbieter gewinnt?

Das Lastenheft sollte branchenneutral formuliert sein und anbieterspezifische Begriffe oder Architekturen vermeiden, da die Auswahl sonst angreifbar wird und einzelne Bieter unzulässig bevorzugt. Es beschreibt grundsätzlich nur das Was und Warum, nie das Wie, und überlässt die konkrete Lösung dem Bieter. Eine belastbare Auswahl kombiniert das Lastenheft mit einer Demo anhand eigener Daten, Referenzbesuchen bei vergleichbaren Unternehmen und einem Proof-of-Concept auf zwei bis drei kritischen Prozessen. Da das Lastenheft bei vertraglicher Einbeziehung Vertragsbestandteil wird, schafft eine saubere, neutrale Formulierung zugleich rechtliche Klarheit für beide Seiten.

In welcher Reihenfolge sollten die Kapitel eines Lastenhefts entstehen?

Sinnvoll ist die Reihenfolge Unternehmensprofil, Zielbild, Prozesslandkarte, Anforderungen, dann die Querschnittskapitel Rollen, Daten, Integrationen, Rahmenbedingungen und Mengengerüst. Der Grund ist inhaltlich: Jede einzelne Anforderung sollte sich auf einen Prozessschritt zurückführen lassen, und die Prozesse wiederum auf ein messbares Ziel. Wer mit dem Anforderungskatalog beginnt, sammelt Wünsche ohne Bezugsrahmen und muss später aufwendig aussortieren. Die Zusammenfassung für die Geschäftsführung wird trotz ihrer Position ganz vorn immer zuletzt geschrieben.

Wie viele Anforderungen sollte der Anforderungskatalog enthalten?

Eine feste Zahl gibt es nicht, die Bandbreite reicht von einigen Dutzend bis zu mehreren hundert Positionen je nach Branche und Prozesstiefe. Wichtiger als die Menge ist der Anteil der Anforderungen, die tatsächlich zwischen Anbietern differenzieren: Funktionen, die jedes marktübliche System beherrscht, kosten nur Bearbeitungszeit auf beiden Seiten. Bewährt hat sich, alle Standardfunktionen gebündelt abzufragen und die Detailtiefe für die Prozesse zu reservieren, in denen das eigene Geschäft besonders ist. Ein geschärfter Katalog erzeugt vergleichbarere Angebote als ein vollständiger.

Braucht ein Cloud-Projekt ein anderes Lastenheft als eine On-Premises-Einführung?

Die Gliederung bleibt gleich, die Gewichtung verschiebt sich. Bei standardnaher Cloud-Software verliert der detaillierte Funktionskatalog an Bedeutung, weil kaum angepasst werden soll, während Schnittstellen, Berechtigungen, Verfügbarkeit, Datenhaltung und Exit-Regelungen deutlich wichtiger werden. Ebenso relevant ist die Frage, welche eigenen Prozesse an den Standard angepasst werden können und welche nicht verhandelbar sind. Ohne diese Klärung entstehen im Cloud-Projekt genau die Anpassungen, die den Kostenvorteil des Standards wieder aufzehren.