ERP · Anforderungen · 3 MIN LESEZEIT

Das geliehene Lastenheft: Wer schreibt?

Ein Lastenheft kann sehr professionell aussehen und trotzdem die falsche Entscheidung vorbereiten. Kritisch wird es, wenn Anforderungen bereits durch die Logik eines bestimmten Anbieters formuliert sind, bevor der eigene Betrieb sauber beschrieben wurde.

Veröffentlicht am 21. Mai 2026Von

Einordnung und Relevanz

Beschreiben Sie zuerst den Geschäftsvorfall und das erwartete Ergebnis. Erst danach darf Produktwissen ergänzen, wie ein System diesen Bedarf abbildet.

Wem gehört die Anforderung – dem Unternehmen oder dem Lösungsanbieter?

Projektleitung vor AusschreibungFachbereiche mit AnforderungslisteGeschäftsführung vor Anbieteransprache
AUF EINEN BLICKDer Ursprung der Anforderung verändert die Auswahl.

Übernommene Feature-Liste

„Mobile Freigabe“

Eine Funktion wird gefordert.

Haken in der Tabelle

Der betriebliche Grund bleibt offen.

Eigener Geschäftsfall

Wer genehmigt was – bis wann?

Rolle, Wertgrenze und Ausnahme beschreiben.

Denselben Fall nachweisen

Alle Anbieter zeigen das benötigte Ergebnis.

Eine Funktion wird erst mit ihrem Geschäftsvorfall zu einer prüfbaren Anforderung.

Schematische Darstellung · keine Messdaten

Das Wichtigste für Ihren Betrieb

Ihre Anforderungen müssen aus Ihrer Arbeit entstehen.

Ein Lastenheft ist nur dann eine belastbare Kundengrundlage, wenn Anforderungen aus den eigenen Geschäftsvorfällen, Prioritäten und Verantwortlichkeiten entstehen. Eine Anbieter- oder Vorlagenliste kann Struktur liefern, darf aber nicht die Unternehmensentscheidung ersetzen.

ENTSCHEIDUNG

Ein Lastenheft ist nur belastbar, wenn Geschäftsvorfälle, Prioritäten und Entscheidungsrechte beim Unternehmen bleiben.

NACHWEIS

Jede Muss-Anforderung lässt sich auf einen realen Vorgang, ein Ergebnis und einen Eigentümer zurückführen.

GRENZE

Anbieterwissen ist wertvoll, darf aber die eigene Problemdefinition nicht ersetzen.

01

Der Interessen­konflikt, den kaum jemand ausspricht

Wenn ein neues ERP ansteht, hört man oft denselben Satz: „Der Anbieter kennt sein System am besten, der soll uns sagen, was wir brauchen.“ Das klingt vernünftig – und ist der teuerste Denkfehler der ganzen Auswahl. Denn wer das Lastenheft schreibt, definiert die Anforderungen. Und wer die Anforderungen definiert, entscheidet das Ergebnis, bevor der erste Anbieter überhaupt verglichen wird.

Ein Systemhaus oder Softwareanbieter, der Ihr Lastenheft federführend erstellt, betrachtet Anforderungen naturgemäß durch die Logik des eigenen Produkts. Das ist keine böse Absicht, sondern wertvolles Produktwissen – für eine faire Auswahl sollte es jedoch durch Ihre Prozesssicht und unabhängige Bewertungskriterien ergänzt werden.

02

Was ein geliehenes Lastenheft anrichtet

Die Folgen zeigen sich selten sofort. Sie kommen später – und teuer: Funktionen, die Sie nie gebraucht hätten, stehen im Vertrag. Prozesse, die Ihr Betrieb wirklich braucht, tauchen erst im Projekt auf und werden als kostenpflichtige „Change Requests“ nachberechnet. Und weil das Lastenheft nie neutral war, lassen sich konkurrierende Angebote gar nicht sauber vergleichen. Sie verhandeln aus einer Position der Blindheit.

03

Wie ein unabhängiges Lastenheft aufgebaut ist

Ein belastbares Lastenheft beschreibt nicht Software – es beschreibt Ihre Prozesse und Ziele. Es entsteht in dieser Reihenfolge:

  1. Ist-Prozesse aufnehmen, wie sie wirklich laufen. Nicht wie im Organigramm, sondern im Tagesgeschäft – inklusive der Umwege, die sich eingeschlichen haben.
  2. Muss, Soll und Kann trennen. Erst diese Priorisierung macht Angebote vergleichbar und schützt vor Feature-Gold-Plating.
  3. Anforderungen anbieterneutral formulieren. Ergebnisse und Regeln beschreiben – nicht die Bedienoberfläche eines bestimmten Systems.
  4. Eigene Testszenarien definieren. Ihre realen Geschäftsvorfälle, an denen die Anbieter in der Demo zeigen müssen, was das System kann – nicht umgekehrt.

Damit drehen Sie das Machtverhältnis um: Die Anbieter bewerben sich bei Ihnen, statt Ihnen ihre Sicht zu diktieren.

Übergabe: Sobald Anforderungen, Eigentümer und Prioritäten feststehen, wird daraus kein längeres Dokument um seiner selbst willen. Es entsteht ein Demo-Drehbuch, mit dem alle Anbieter dieselben Vorgänge belegen müssen.

04

Die Faustregel

Das Lastenheft gehört in Ihre Hand – oder in die einer Instanz, die ausschließlich von Ihnen bezahlt wird. Alles andere ist, als ließen Sie den Verkäufer den Kaufvertrag aufsetzen und würden ihn ungelesen unterschreiben.

Praxis-Tipp: Bevor Sie ein Lastenheft aus der Hand geben, fragen Sie sich: Verdient derjenige, der es schreibt, an der Software, die am Ende dabei herauskommt? Wenn ja, ist es kein Lastenheft – es ist ein Angebot in Tarnung.
ENTSCHEIDUNGSHILFE

Jede Anforderung braucht vier Anker

Nehmen Sie eine Muss-Anforderung aus Ihrem Lastenheft: Können Sie Vorgang, Verantwortliche und Abnahme dazu benennen?

PrüffeldLeitfrageBelastbarer NachweisKonsequenz
VorgangIn welchem realen Fall wird die Fähigkeit benötigt?Konkretes Szenario und erwartetes Ergebnis.Abstrakte Features zurückstellen.
PrioritätMuss, Differenzierung oder Komfort?Begründung und Eigentümer.Wunschliste reduzieren.
NachweisWie zeigt ein Anbieter die Fähigkeit?Demo, Dokument oder Referenz am selben Fall.Aussagen vergleichbar machen.
Trade-offWelche Alternative oder Einschränkung ist akzeptabel?Dokumentierte Entscheidung.Flexibilität und Kosten bewusst abwägen.

Wer darf Anforderungen festlegen?

PERSPEKTIVEFachbereich

Vorgänge und notwendige Ergebnisse liefern.

PERSPEKTIVEIT

Nichtfunktionale Anforderungen und Architektur ergänzen.

PERSPEKTIVEManagement

Prioritäten und Trade-offs freigeben.

Warnsignale

  • Anforderungstexte stammen überwiegend vom Anbieter.
  • Jede Funktion wird als Muss markiert.
  • Es gibt keinen Demo-Nachweis.
  • Prozessänderung wird grundsätzlich ausgeschlossen.
FAZIT

Eigene Anforderungen zuerst, Anbieterwissen danach

  • EntscheidungEin Lastenheft ist nur belastbar, wenn Geschäftsvorfälle, Prioritäten und Entscheidungsrechte beim Unternehmen bleiben.
  • NachweisJede Muss-Anforderung lässt sich auf einen realen Vorgang, ein Ergebnis und einen Eigentümer zurückführen.
  • GrenzeAnbieterwissen ist wertvoll, darf aber die eigene Problemdefinition nicht ersetzen.
NÄCHSTER SCHRITT

Eine Anforderung schärfen.

Bringen Sie eine unklare Muss-Anforderung und den zugehörigen Geschäftsvorfall mit.

Eine Anforderung schärfen →