Warum der Anforderungskatalog 2026 im DACH-Mittelstand entscheidend ist
Zwei Treiber machen den Anforderungskatalog 2026 zur Pflicht: regulatorische Dichte (NIS-2, EU AI Act ab 06.04.2026, CSRD, GoBD, BSI 200-1) und harte Wirtschaftlichkeit (DSAG-Investitionsreport 2026, Trovarit ERP-in-der-Praxis 2024/25). Wer 2026 in eine ERP-Beschaffung geht, braucht beide Schichten dokumentiert.
Geschäftsführerinnen und Geschäftsführer im DACH-Mittelstand stehen 2026 unter doppeltem Druck. Erstens ist die Regulierung dichter geworden: Der BSI-Standard 200-1 liefert seit 2017 den Rahmen für Informationssicherheits-Managementsysteme; mit der NIS-2-Umsetzung wird er für viele Mittelständler direkt anwendbar. Der EU AI Act tritt am 06.04.2026 in Kraft. CSRD und GoBD sind ohnehin laufend in Anwendung. All das muss in den Katalog — sonst kommt es später als Änderungsanfrage mit Vendor-Stundensatz zurück.
Zweitens ist die Wirtschaftlichkeit härter geworden. Der DSAG-Investitionsreport 2026 dokumentiert, dass 38 Prozent der DACH-Unternehmen ihre IT-Budgets gezielter einsetzen; fast 50 Prozent planen den S/4HANA-Umstieg erst bis Ende 2030. Wer 2026 eine ERP-Beschaffung anstößt, hat eine lange Liquiditätsbindung — der Katalog ist das Instrument, das diese Bindung absichert.
Aus über 1.200 Projekten sehen wir, dass 60 Prozent der DACH-Mittelständler ohne strukturierten Katalog in Vertragsverhandlungen gehen — und im ersten Jahr nach Go-Live sechsstellige Änderungsanfragen produzieren. Die Trovarit-Studie ERP in der Praxis 2024/25 dokumentiert eine Service-Qualitätsbewertung von 1,96 — leicht gesunken — das indirekte Signal jener Vertragslücken, die ein nachlässiger Katalog hinterlässt.
Praxisbeispiel: Capability-basierter Anforderungskatalog bei einem Küchenhersteller
Mittelständischer Küchenhersteller mit rund 1.500 produzierten Küchen pro Jahr im Objektauftragsgeschäft, drei Werke, gewachsenes ERP-Umfeld. Mit einem capability-basierten Katalog reduzierte sich die Anbieterliste von 11 auf 3 verifizierte Kandidaten. Entscheidend war die Trennung von Capability und Feature.
Wir haben in einem Projekt mit einem mittelständischen Küchenhersteller aus Süddeutschland (rund 1.500 produzierte Küchen pro Jahr im Objektauftragsgeschäft, drei Werke, etwa 280 Beschäftigte) den Anforderungskatalog capability-basiert aufgebaut. Die Ausgangslage war typisch für den DACH-Mittelstand: gewachsenes ERP, drei Werke mit lokalen Sonderlocken, Konfigurationstiefe über Korpus, Front, Beschlag und Logistik-Sequenz. Erste Marktansprache hatte 11 Anbieter eingeladen — jeder antwortete formal mit „erfüllt", ohne dass die Sondergeschäftsmodelle adressiert waren.
Wir verankerten den Katalog neu entlang 18 Geschäfts-Capabilities aus dem EAM-Vorlauf und erzeugten daraus 142 Anforderungen mit jeweils einem binär prüfbaren Akzeptanzkriterium. Entscheidend war nicht das Template — sondern dass jede Anbieterantwort in einer Fallstudie geprüft wurde, in der die Akzeptanzkriterien, nicht das Marketingmaterial, über die nächste Runde entschieden.
Das Ergebnis war messbar. Die Anbieterliste reduzierte sich von 11 auf 3 verifizierte Kandidaten, die ihre Capability-Erfüllung in einer durchgängigen Fallstudie zeigen mussten. Drei Anbieter scheiterten an der Konfigurationstiefe, vier an der Sequenz-Logistik, einer an der Mehrwerke-Buchungslogik. Der Vertrag enthielt 142 Akzeptanzkriterien — und diese Kriterien wurden im Cut-Over zur Abnahme verwendet. Entscheidend war nicht das Tool, sondern die Trennung der drei Schichten und die saubere Verzahnung mit der Capability-Map aus dem EAM-Vorlauf.
Was die meisten Anforderungskatalog-Leitfäden verschweigen
Drei unbequeme Wahrheiten, die in den öffentlichen Leitfäden zum Anforderungskatalog selten ausgesprochen werden — gestützt auf IREB CPRE-FL, VDI 2519, BSI 200-1, DSAG-Investitionsreport 2026 und unsere 1.200+ Projekte im DACH-Mittelstand. Wer sie ignoriert, kauft Lizenz statt Wirkung.
1. Capability-vs-Feature-Trennung — der Hebel, den keiner zeigt
Die meisten Leitfäden sprechen von funktionalen, nicht-funktionalen, technischen und rechtlichen Anforderungen. Das ist nicht falsch, aber unvollständig. Im Gegensatz zu dieser Vier-Kategorien-Logik trennen wir die Capability (was das Geschäft können muss) von der Anforderung (was das System dafür leisten muss) und vom Feature (wie ein konkreter Anbieter es löst). Aus dem EAM-Vorlauf kommt die oberste Schicht. Wer ohne sie in die Marktansprache geht, vergleicht Feature-Listen, nicht Geschäftsfähigkeiten — Vendor-Wording landet im Vertrag. Aus über 1.200 Projekten haben wir gesehen, dass 80 Prozent der DACH-Mittelstand-Beschaffungen ohne Capability-Schicht starten — und genau diese Beschaffungen erzeugen die teuersten Änderungsanfragen.
2. Die Compliance-Pflichten 2026 sind keine Fußnote — sie sind eigene Schichten
NIS-2, EU AI Act (Inkrafttreten 06.04.2026), CSRD und GoBD werden in vielen Katalogen 2026 als „Datenschutz" abgehandelt. Das reicht nicht. Konkret braucht der Katalog: erstens eine Audit-Trail-Schicht (BSI 200-1, GoBD); zweitens eine KI-Transparenz-Schicht (EU AI Act) für Hochrisiko-Use-Cases; drittens eine ESG-Datenmodell-Schicht (CSRD); viertens eine Sicherheits-Schicht (BSI 200-1, NIS-2) mit ISMS-konformen Mindestanforderungen. Bei öffentlich geförderten Beschaffungen kommt die EU-Vergaberichtlinie in der konsolidierten Fassung 2026 mit Schwellenwerten 140.000 EUR / 216.000 EUR hinzu.
3. Sieben wiederkehrende DACH-Mittelstand-Fehler
Sieben Fehler kehren systematisch wieder: erstens Feature-Inflation (300+ Zeilen, keine Priorisierung); zweitens Vendor-Wording-Copy-Paste; drittens fehlende Schnittstellen-Spezifikation; viertens Daten-Volumen-Vagheit; fünftens unklare Rollen und Rechte; sechstens fehlende Migrationsanforderungen; siebtens keine Akzeptanzkriterien. Wer diese Muster systematisch ausschließt, hat — auch ohne neue Methodik — bereits einen besseren Katalog als 80 Prozent des Marktes.
Unsere Einordnung
Ein Anforderungskatalog ist kein Excel-Werk. Er ist die vertraglich tragende Schicht zwischen Geschäftsmodell und Systemlösung. Wer ihn als Sammlung von Wünschen behandelt, kauft Lizenz statt Wirkung — und zahlt die Differenz später doppelt.
Wie wir Anforderungskataloge methodisch erstellen
Vier Phasen, die wir in jeder ERP-Beschaffung durchlaufen — Capability-Aufnahme aus dem EAM-Vorlauf, Anforderungs-Ableitung, Akzeptanzkriterien-Definition und Marktansprache mit Fallstudie. Der methodische Rahmen ist wichtiger als das Template.
Phase 1 — Capability-Aufnahme. Wir beginnen nicht mit der Anforderung, sondern mit der Geschäfts-Capability. Welche Fähigkeiten muss das Unternehmen 2026, 2028 und 2030 haben? Welche davon stützt das ERP? Welche bleiben in Spezialsystemen? Erst aus dieser Karte entstehen die Anforderungen — und zwar in der Sprache des Geschäfts, nicht in Vendor-Wording. Die Capability-Schicht stammt regelmäßig aus dem EAM-Vorlauf; im SCOReX®-Bezugsrahmen ist sie fest verankert und nicht verhandelbar.
Phase 2 — Anforderungs-Ableitung. Im Sinne der VDI 2519 leiten wir Anforderungen aus den Capabilities ab. Eine Capability erzeugt typischerweise drei bis acht Anforderungen. Wir formulieren jede nach den IREB-CPRE-Qualitätskriterien: eindeutig, vollständig, konsistent, prüfbar. Eine nicht prüfbare Anforderung ist ein Wunsch.
Phase 3 — Akzeptanzkriterien. Wir definieren je Anforderung ein Akzeptanzkriterium — quantitativ oder klar binär prüfbar. Statt „Das System unterstützt Variantenkonfiguration" schreiben wir: „Das System konfiguriert eine 3-zeilige Insel-Küche mit 24 Korpussen, 4 Sonderhöhen und Sequenz-Anlieferung in unter 90 Sekunden Antwortzeit". Diese Kriterien werden zur Abnahme verwendet — und gehören genau deshalb vor den Vertrag, nicht danach.
Phase 4 — Marktansprache mit Fallstudie. Featurelisten gewinnen den Anbieter mit dem größten Marketingbudget; wir lassen Kandidaten stattdessen dieselbe Fallstudie an unseren Akzeptanzkriterien lösen. Diese Methodik ist in unseren Berater-Einblicken dokumentiert und in 1.200+ Projekten verfeinert. Bei unserer ERP-Auswahl im Mittelstand ist sie operative Grundlage.
Häufige Fehler bei der Erstellung von Anforderungskatalogen
Vier Muster, die in unseren Projekten regelmäßig auftauchen — und die fast nie mit der Methode zu tun haben. Wer sie erkennt, spart Vertragsstreit und Änderungsanfragen nach dem Go-Live.
Fehler 1 — Template-First-Ansatz. Das Unternehmen sucht eine Excel-Vorlage, füllt sie ohne Capability-Vorlauf aus und glaubt, einen Katalog zu haben. Tatsächlich hat es eine Funktionsliste. Klassische Excel-Listen sind dafür längst ungeeignet — sie laden zu Vendor-Wording-Übernahme ein und entziehen sich der prüfbaren Strukturierung.
Fehler 2 — unklare Modellierungstiefe. Manche Kataloge modellieren jeden Klick (300+ Zeilen, unlesbar), andere bleiben auf 30.000 Fuß (nicht prüfbar). Beides liefert keinen Vertragswert. Wir arbeiten mit drei Schichten und maximal vier Modellierungsebenen je Schicht.
Fehler 3 — fehlende Schnittstellen- und Stammdaten-Spezifikation. Ein Katalog ohne Datenvolumen-, Frequenz- und Fehlerverhaltens-Angaben in den Schnittstellenanforderungen ist Papier. Wir analysieren die Datenqualität vor dem Katalog — vor allem für Stammdaten — und schreiben harte Schwellwerte in den Katalog.
Fehler 4 — fehlende Logikprüfung. Anforderungen widersprechen sich oft. Der Katalog muss durch eine Logikprüfung — Korrelationen und kausale Zusammenhänge zwischen Anforderungen müssen offengelegt sein. In unseren Projekten haben wir wiederholt erlebt, dass Anbieter genau diese Lückenräume nutzen, sobald der Vertrag unterschrieben ist. Auch der Leitfaden des Kompetenzzentrums Digitales Handwerk, der Asana-Leitfaden zur Anforderungsdokumentation und der VDI-2519-Standard beschreiben dieselbe Disziplin.
Häufig gestellte Fragen
Der Anforderungskatalog ist der Kern; das Lastenheft ist die Hülle; das Pflichtenheft ist die Antwort des Anbieters. Im Sinne der VDI 2519 Blatt 1 ist das Lastenheft das vollständige Anforderungsdokument des Auftraggebers — es enthält den Anforderungskatalog plus Rahmenbedingungen, Projektstruktur und Vertragsklauseln. Das Pflichtenheft beschreibt, wie der Anbieter die Anforderungen umsetzen will. Wer die Begriffe synonym verwendet, überlässt die Definition der Erfüllung dem Anbieter. Wir führen den Katalog als eigenständiges Dokument und binden ihn im Lastenheft als Abschnitt ein.
Eine pauschale Zeilenzahl ist die falsche Metrik. Der IREB CPRE-FL-Syllabus macht keine Vorgabe zur Menge. Aus unseren Projekten liegen Mittelstandskataloge typischerweise bei 80 bis 200 Anforderungen je Geschäftsbereich, abgeleitet aus 12 bis 25 Geschäfts-Capabilities. Entscheidend ist die Prüfbarkeit, nicht die Menge. Wer 500 Anforderungen ohne Akzeptanzkriterien hat, hat eine Wunschliste. Wer 142 Anforderungen mit jeweils einem klaren Akzeptanzkriterium hat, hat einen Vertrag. Im Beispiel des Küchenherstellers mit rund 1.500 produzierten Küchen pro Jahr lagen wir bei 142 Anforderungen aus 18 Capabilities — für den DACH-Mittelstand eine typische Größenordnung.
Die Geschäftsführung definiert die Capability-Schicht — was das Unternehmen 2028 und 2030 können muss. Der DSAG-Investitionsreport 2026 zeigt, dass diese Mandats-Klarheit der entscheidende Hebel für gezielte IT-Investitionen ist. Die Fachbereiche leiten Anforderungen und Akzeptanzkriterien ab. Die IT prüft die technische Konsistenz und die Schnittstellen. Ohne Geschäftsführungsmandat wird der Katalog ein Wunschkonzert; ohne Fachbereichs-Beteiligung wird er ein IT-Dokument ohne Geschäftsbezug. Wir empfehlen ein Tandem aus Geschäftsführung (Capability-Mandat), Fachbereich (Anforderungen) und IT (Konsistenz und Integration).
Aus über 1.200 Projekten mit DACH-Mittelstand-Unternehmen sehen wir, dass die Anpassung 2026 konkret wird: NIS-2-Pflichten (BSI 200-1-abgeleitet) und der EU AI Act (Inkrafttreten 06.04.2026) erscheinen als explizite Katalogpositionen — nicht als Fußnote im Risikoteil. Wir empfehlen, Transparenz-, Audit-Trail-, Datenresidenz- und Human-in-the-Loop-Anforderungen auf demselben Detaillierungsniveau wie funktionale Anforderungen zu dokumentieren. In unserer Praxis verhindert das den typischen Compliance-Rückstau in der Vendor-Auswahl.
Nächste Schritte
Ein belastbarer Anforderungskatalog beginnt mit der Capability-Karte — nicht mit der Excel-Vorlage. Beginnen Sie mit einer Bestandsaufnahme: Liegt eine Capability-Karte vor? Sind die Compliance-Pflichten (NIS-2, EU AI Act, CSRD, GoBD) als eigene Schichten identifiziert? Gibt es zu jeder Anforderung ein prüfbares Akzeptanzkriterium? Dreher Consulting begleitet DACH-Mittelstand-Unternehmen seit 1992 durch ERP-Beschaffungen — von der ERP-Beratung über das ERP-Lastenheft bis zur Einführung. Hintergründe in unseren Einblicken.
30 Minuten mit Dr. Dreher
Eine strukturierte Einschätzung Ihres aktuellen Katalogs oder Ihrer Ausgangslage — anbieterneutral, aus 30+ Jahren Projektpraxis.
