Das Wichtigste für Ihren Betrieb
Ihre Anforderungen müssen aus Ihrer Arbeit entstehen.
In einer unabhängigen ERP-Beratung ist ein Lastenheft 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.
Ein Lastenheft ist nur belastbar, wenn Geschäftsvorfälle, Prioritäten und Entscheidungsrechte beim Unternehmen bleiben.
Jede Muss-Anforderung lässt sich auf einen realen Vorgang, ein Ergebnis und einen Eigentümer zurückführen.
Anbieterwissen ist wertvoll, darf aber die eigene Problemdefinition nicht ersetzen.
IN DIESEM BEITRAG4 Kapitel
Der Interessenkonflikt, 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.
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.
Wie sollte ein unabhängiges Lastenheft aufgebaut sein?
Ein belastbares Lastenheft beschreibt nicht Software – es beschreibt Ihre Prozesse und Ziele. Es entsteht in dieser Reihenfolge:
- Ist-Prozesse aufnehmen, wie sie wirklich laufen. Nicht wie im Organigramm, sondern im Tagesgeschäft – inklusive der Umwege, die sich eingeschlichen haben.
- Muss, Soll und Kann trennen. Erst diese Priorisierung macht Angebote vergleichbar und schützt vor Feature-Gold-Plating.
- Anforderungen anbieterneutral formulieren. Ergebnisse und Regeln beschreiben – nicht die Bedienoberfläche eines bestimmten Systems.
- 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.
Die Faustregel für ein unabhängiges Lastenheft
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.
Wenn aus Anforderungen ein neutraler Anbieter- und Systemvergleich werden soll, führt der nächste Schritt in die herstellerneutrale ERP-Beratung.
Jede Anforderung braucht vier Anker
Nehmen Sie eine Muss-Anforderung aus Ihrem Lastenheft: Können Sie Vorgang, Verantwortliche und Abnahme dazu benennen?
| Prüffeld | Leitfrage | Belastbarer Nachweis | Konsequenz |
|---|---|---|---|
| Vorgang | In welchem realen Fall wird die Fähigkeit benötigt? | Konkretes Szenario und erwartetes Ergebnis. | Abstrakte Features zurückstellen. |
| Priorität | Muss, Differenzierung oder Komfort? | Begründung und Eigentümer. | Wunschliste reduzieren. |
| Nachweis | Wie zeigt ein Anbieter die Fähigkeit? | Demo, Dokument oder Referenz am selben Fall. | Aussagen vergleichbar machen. |
| Trade-off | Welche Alternative oder Einschränkung ist akzeptabel? | Dokumentierte Entscheidung. | Flexibilität und Kosten bewusst abwägen. |
Wer darf Anforderungen festlegen?
Vorgänge und notwendige Ergebnisse liefern.
Nichtfunktionale Anforderungen und Architektur ergänzen.
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.
Quellen, Methodik und Einordnung.
Nachweise und methodische Einordnung sind am Ende des Artikels gebündelt.
Methodik und Einordnung
Methodik des Beitrags
Der Beitrag beschreibt einen eigenen, praxisbasierten Entscheidungsrahmen für Anforderungen vor einer ERP-Auswahl. Er verwendet keine externen Markt-, Studien- oder Benchmarkzahlen als Beleg.
Gerade bei komplexen Änderungs- und Produktionsketten lässt sich diese Logik auch regional anwenden: ERP-Auswahl und Lastenheft in Stuttgart.
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.
Eine Anforderung schärfen.
Bringen Sie eine unklare Muss-Anforderung und den zugehörigen Geschäftsvorfall mit.
Eine Anforderung schärfen →