Wie detailliert sollte ich ein ERP-Lastenheft vorbereiten?

Question

Ich stehe gerade vor der Aufgabe, die Anforderungen für ein neues ERP-System möglichst sauber zu strukturieren. Dabei merke ich, dass schnell sehr viele Themen zusammenkommen, von Einkauf und Lager bis hin zu Produktion und Finanzbuchhaltung. Mir ist deshalb noch nicht ganz klar, wie tief ich bei den einzelnen Funktionen ins Detail gehen sollte. Einerseits möchte ich keine wichtigen Anforderungen vergessen, andererseits soll das Dokument auch noch praktikabel bleiben. Besonders schwierig finde ich die Frage, welche Kriterien wirklich entscheidend für den späteren Systemvergleich sind. Ich würde gern vermeiden, dass wir erst während der Auswahl feststellen, dass zentrale Prozesse im Lastenheft fehlen. Deshalb suche ich nach einer guten Orientierung für Aufbau und Umfang.

Wie würdet ihr an meiner Stelle ein ERP-Lastenheft strukturieren, damit ich später verschiedene Systeme möglichst zuverlässig miteinander vergleichen kann?

Answer 1

Bei Quant Consulting findet sich ein Beispiel zum ERP Lastenheft, das sehr ausführlich nach Funktionsbereichen gegliedert ist und laut Anbieter auf mehr als 3.000 Kriterien zurückgreift.
Die Struktur reicht dort unter anderem von Materialstamm, Stücklisten und Auftragsabwicklung über Produktionsplanung, Einkauf und Lager bis hin zu Finanzbuchhaltung, Kostenrechnung und Jahresabschluss.

Ich würde mich an so einer Gliederung orientieren und anschließend für jeden Bereich festhalten, welche Funktionen für meine eigenen Prozesse zwingend erforderlich, wünschenswert oder eher optional sind.
Für den späteren ERP-Vergleich dürfte gerade diese klare Gewichtung hilfreich sein, weil sich dadurch verschiedene Systeme nicht nur allgemein, sondern anhand konkreter Anforderungen gegenüberstellen lassen.

Answer 2

Ein kurzer Überblick – warum das Lastenheft wichtig ist

Ein gut strukturiertes ERP‑Lastenheft ist das Rückgrat für einen fairen Systemvergleich. Es hilft nicht nur, die eigenen Prozesse zu durchleuchten, sondern verhindert später teure Überraschungen, wenn ein Anbieter nicht das liefert, was wirklich gebraucht wird.

1. Grundlegende Struktur – das Gerüst, das du brauchst

• Einleitung & Zielsetzung: Kurz beschreiben, warum ein neues ERP eingeführt wird und welche übergeordneten Ziele (Kosten senken, Transparenz erhöhen, Skalierbarkeit…) verfolgt werden.
• Unternehmensprofil: Branche, Größe, Standorte, aktuelle IT‑Landschaft.
• Prozessübersicht: High‑Level‑Diagramm oder tabellarische Auflistung aller Kernprozesse (Einkauf, Lager, Produktion, Finanzbuchhaltung, Vertrieb, CRM usw.).
• Funktionsanforderungen: Aufgeteilt nach Fachbereichen, jeweils mit Priorisierung (Muss‑, Soll‑, Wunsch‑).
• Technische Rahmenbedingungen: Schnittstellen, Datenmigration, Cloud vs. On‑Premise, Sicherheits‑ & Compliance‑Vorgaben.
• Projekt‑ und Implementierungsrahmen: Zeitplan, Budget, Ressourcen, Change‑Management‑Anforderungen.
• Bewertungskriterien: Gewichtung von Kosten, Funktionsumfang, Usability, Support usw.

2. Wie tief ins Detail gehen?

Der Trick ist, **genug Detail zu geben, um die Kernanforderungen eindeutig zu machen, aber nicht jedes einzelne Datenfeld** zu beschreiben. Folgende Praxis hat sich bewährt:

• Prozessschritte beschreiben, nicht jede Eingabemaske: Statt „Feld „Artikelnummer“ muss vorhanden sein“ zu schreiben, lieber „Im Wareneingang muss das System Artikel eindeutig identifizieren und automatisch Bestandsänderungen buchen können.“
• Use‑Case‑Szenarien nutzen: Beschreibe ein typisches Szenario (z. B. „Ein neuer Lieferant wird angelegt, ein Bestellvorschlag erstellt und automatisch an den Lieferanten gesendet“). Das gibt Anbietern klare Kontext‑Infos.
• Priorisieren: Markiere jede Anforderung mit Muss (unverzichtbar), Soll (wünschenswert) oder Optional. So bleibt das Dokument übersichtlich und du kannst später leichter filtern.
• Grenzwerte definieren: Wo es wichtig ist, konkrete Zahlen anzugeben (z. B. „Rechnungsbearbeitung darf nicht länger als 48 Stunden dauern“ oder „System muss mindestens 5.000 gleichzeitige Nutzer unterstützen“).

3. Praktische Tipps für den Vergleich später

• Einheitliche Bewertungstabelle erstellen: Spalte 1 = Anforderung, Spalte 2 = Priorität, Spalte 3‑n = Anbieter‑Erfüllungsgrad (Ja/Nein, Teilweise, Kommentar).
• Scoring‑Modell festlegen: Jeder Muss‑Punkt bekommt z. B. 5 Punkte, Soll‑Punkte 3 Punkte, Wunsch‑Punkte 1 Punkt. So lässt sich schnell ein Gesamtscore berechnen.
• „Deal‑Breaker“-Kriterien definieren: Das sind Muss‑Anforderungen, bei denen ein Anbieter sofort ausscheidet (z. B. keine Anbindung an das bestehende SAP‑Modul).
• Prototyp‑ oder Demo‑Anforderung im Lastenheft