Wissensdatenbank · ERP-Auswahl in der Praxis

ERP-Fragenkatalog für die Auswahl

Ein strukturierter Fragen- und Kriterienkatalog als Lastenheft-Basis: Welche Fragen ein mittelständisches Unternehmen an Prozesse, Funktionen, Technik, Integration, Anbieter, Kosten und Datenschutz stellen muss, um ein ERP-System fundiert und vergleichbar auszuwählen — herstellerneutral und praxisnah.

27 Min. Lesezeit
Aktualisiert · Juli 2026
Praxisleitfaden · Konzeptartikel
ERP-Fragenkatalog
INAGRO Wissensdatenbank · 36 ERP-Systeme
Artikeltyp
Konzept- / Praxisartikel
Zweck
Lastenheft- & Auswahlgrundlage
Zielgruppe
Mittelstand (DACH)
Aufbau
Frage- & Kriterienblöcke
Bewertung
Scoring, Muss / Kann
Haltung
Herstellerneutral
INAGRO Eignung KMU
Kapitel 01 · Wozu ein Fragenkatalog

Wozu ein ERP-Fragenkatalog — und was er leistet

Ein ERP-Fragenkatalog ist das strukturierte Rückgrat einer ERP-Auswahl. Er verwandelt ein diffuses „Wir brauchen ein neues System“ in eine geordnete Liste prüfbarer Fragen — und macht damit den Unterschied zwischen einer Bauchentscheidung und einer nachvollziehbaren, vergleichbaren Auswahl.

Die Einführung eines ERP-Systems ist eine der folgenreichsten Investitionsentscheidungen, die ein mittelständisches Unternehmen trifft. Sie bindet über Jahre Budget, Personal und Führungsaufmerksamkeit, und sie prägt, wie die Organisation künftig arbeitet. Trotzdem beginnen viele Auswahlprozesse mit Produktdemos, bevor überhaupt geklärt ist, was das Unternehmen eigentlich braucht. Der Fragenkatalog dreht diese Reihenfolge um: Er zwingt dazu, die eigenen Anforderungen zuerst zu formulieren — und erst dann den Markt daran zu messen.
Der Nutzen liegt auf mehreren Ebenen. Erstens schafft ein Katalog Vergleichbarkeit: Wenn alle Anbieter dieselben Fragen beantworten, lassen sich ihre Antworten nebeneinanderlegen, statt Äpfel mit Birnen zu vergleichen. Zweitens macht er blinde Flecken sichtbar: Themen wie Schnittstellen, Datenmigration oder Datenschutz geraten in der Begeisterung über eine schöne Oberfläche leicht aus dem Blick — ein Katalog stellt sicher, dass sie systematisch abgefragt werden. Drittens dient er als Verhandlungs- und Vertragsgrundlage: Was schriftlich abgefragt und zugesagt wurde, lässt sich später einfordern.

Abgrenzung: Fragenkatalog, Lastenheft und Pflichtenheft

Diese drei Begriffe werden häufig durcheinandergeworfen, bezeichnen aber unterschiedliche Dokumente mit unterschiedlichen Rollen. Ein Fragenkatalog ist zunächst ein Arbeitsinstrument: eine gegliederte Sammlung von Fragen und Kriterien, mit denen das Unternehmen sich selbst und die Anbieter systematisch befragt. Er ist die Vorstufe und Rohmasse, aus der die formalen Dokumente entstehen.
Das Lastenheft beschreibt aus Sicht des Auftraggebers, was das System leisten soll und welche Anforderungen es erfüllen muss — die Gesamtheit der Anforderungen, formuliert ergebnisoffen, ohne die technische Lösung vorwegzunehmen. Es ist das zentrale Dokument, das den Anbietern zur Angebotserstellung vorgelegt wird. Ein guter Fragenkatalog liefert das Gerüst, aus dem sich das Lastenheft speist.
Das Pflichtenheft hingegen ist die Antwort des Anbieters: Es beschreibt, wie die im Lastenheft geforderten Anforderungen konkret umgesetzt werden. Es entsteht also später im Prozess, oft erst nach der Anbieterauswahl, und wird häufig Vertragsbestandteil. Vereinfacht gesagt: Das Lastenheft ist die Frage des Kunden, das Pflichtenheft die Antwort des Lieferanten — und der Fragenkatalog ist das Werkzeug, mit dem man beide sauber vorbereitet.
INAGRO-Einschätzung
Der Kern: Der Fragenkatalog ist kein Selbstzweck, sondern das Handwerkszeug, mit dem aus vagen Wünschen ein belastbares Lastenheft und eine vergleichbare Bewertung werden. Wer die Fragen früh und ehrlich stellt, spart sich teure Überraschungen im Projekt — und behält im Anbietergespräch die Gesprächsführung.

Was ein Fragenkatalog nicht leisten kann

Bei aller Nützlichkeit ist ein Fragenkatalog kein Automatismus, der die Entscheidung von selbst trifft. Er ist so gut wie die Sorgfalt, mit der er ausgefüllt und ausgewertet wird. Eine lange Liste abgehakter Ja/Nein-Fragen kann sogar in die Irre führen, wenn sie den Blick auf das Wesentliche — die tatsächliche Prozesspassung — verstellt. Ein Anbieter, der auf jede Funktionsfrage „ja“ antwortet, ist nicht automatisch der beste; entscheidend ist, wie gut die zugesagten Funktionen im konkreten Einzelfall wirklich zu den eigenen Abläufen passen. Der Katalog strukturiert die Entscheidung, ersetzt aber weder das Urteilsvermögen noch die kritische Prüfung in Referenzgesprächen und Teststellungen.
Ebenso wichtig ist die Erkenntnis, dass ein Katalog kein statisches Dokument ist. Im Verlauf eines Auswahlprozesses lernen die Beteiligten dazu, neue Fragen tauchen auf, andere erweisen sich als unwichtig. Ein guter Katalog wird deshalb als lebendes Arbeitsdokument geführt und bewusst gepflegt, statt einmal erstellt und dann bis zur Entscheidung unverändert weggeschlossen zu werden.
Kapitel 02 · Anforderungen erheben

Anforderungen sauber erheben

Bevor eine einzige Frage an einen Anbieter geht, muss das Unternehmen sich selbst befragen. Die Qualität der späteren Auswahl steht und fällt mit der Qualität der Anforderungserhebung — hier entscheidet sich, ob der Katalog das Richtige misst.

Die Anforderungserhebung ist der unspektakulärste und zugleich wichtigste Teil jeder ERP-Auswahl. Wer sie überspringt, kauft ein System für ein Unternehmen, das er nicht wirklich kennt. Die Erhebung hat zwei Stoßrichtungen: die Aufnahme der Ist-Prozesse (Wie arbeiten wir heute?) und die Formulierung der Soll-Anforderungen (Wie wollen und müssen wir künftig arbeiten?). Beides gehört zusammen, denn ein ERP-Projekt ist selten nur ein Systemtausch, sondern fast immer auch eine Gelegenheit, Prozesse zu hinterfragen.

Prozessaufnahme: die eigenen Abläufe kennen

Am Anfang steht die ehrliche Bestandsaufnahme der Kernprozesse. Es geht nicht darum, jeden Handgriff zu dokumentieren, sondern die geschäftskritischen und die schmerzhaften Abläufe zu erfassen. Hilfreiche Leitfragen für diese Phase sind:
  • Welche Kernprozesse (etwa Angebot bis Rechnung, Beschaffung bis Bezahlung, Produktionsplanung) sind für unser Geschäft entscheidend?
  • Wo klemmt es heute — welche Prozesse sind langsam, fehleranfällig oder von manuellen Umwegen (Excel, Zuruf, Doppelerfassung) geprägt?
  • Welche Prozesse sind ein echtes Alleinstellungsmerkmal, das wir bewahren müssen, und welche sind bloß historisch gewachsen und reformbedürftig?
  • Welche Mengengerüste (Belege, Aufträge, Artikel, Standorte, Mandanten) muss das System heute und in einigen Jahren bewältigen?
  • Welche gesetzlichen oder branchenspezifischen Vorgaben (etwa GoBD, Chargenrückverfolgung, Nachweispflichten) prägen unsere Abläufe?
Eine solche Aufnahme deckt regelmäßig auf, dass „gewachsene“ Prozesse voller Sonderfälle und Workarounds stecken. Genau diese Stellen sind später die Reibungspunkte in der Einführung — und deshalb im Katalog besonders sorgfältig zu behandeln.

Stakeholder: die richtigen Menschen einbinden

Ein ERP-System berührt fast jeden Bereich eines Unternehmens, und entsprechend viele Perspektiven müssen in die Anforderungen einfließen. Wird der Katalog allein von der IT oder allein von der Geschäftsführung erstellt, fehlen die Fachbereiche mit ihrer täglichen Praxis — und die Akzeptanz leidet später. Sinnvoll ist, früh die relevanten Rollen zu identifizieren und ihre Anforderungen einzusammeln: die Fachbereichsleitungen aus Finanzen, Vertrieb, Einkauf, Produktion und Lager, die späteren Key User, die IT für technische Rahmenbedingungen sowie die Datenschutz- und Compliance-Verantwortlichen.
Dabei zeigt sich fast immer ein Zielkonflikt: Die Fachbereiche wünschen sich maximale Abbildung ihrer Sonderwünsche, während IT und Geschäftsführung auf Standardnähe, Wartbarkeit und Budget achten. Diesen Konflikt muss der Erhebungsprozess sichtbar machen, nicht zudecken. Eine bewährte Technik ist, jede Anforderung mit einer Begründung und einer ersten Einschätzung ihrer Wichtigkeit zu versehen, damit später eine Priorisierung möglich ist.
Praxis-Hinweis
Vorsicht vor der Wunschliste: Eine unsortierte Sammlung aller Wünsche aus allen Abteilungen wird schnell zur Utopie, die kein System erfüllt und die das Budget sprengt. Anforderungen brauchen von Anfang an eine Begründung und eine grobe Priorität, sonst ist der spätere Vergleich wertlos. Trennen Sie früh zwischen „geschäftskritisch“ und „wäre schön“.
Der Aufwand dieser Phase wird regelmäßig unterschätzt. Wer sich hier Zeit nimmt und die Anforderungen dokumentiert, gewichtet und mit den Stakeholdern abstimmt, legt das Fundament, auf dem alle folgenden Kapitel dieses Katalogs aufbauen. Die investierte Sorgfalt zahlt sich in jeder späteren Phase zurück — im Angebotsvergleich, in der Vertragsverhandlung und in der Einführung selbst.
Kapitel 03 · Funktionale Fragen

Funktionale Fragen: Module und Fachlichkeit

Die funktionalen Fragen bilden das Herzstück des Katalogs. Sie klären, ob ein System die fachlichen Anforderungen der einzelnen Unternehmensbereiche abdeckt — und zwar nicht auf dem Papier, sondern im konkreten Prozess.

ERP-Systeme sind modular aufgebaut, und die funktionale Prüfung folgt sinnvollerweise dieser Modulstruktur. Wichtig ist dabei die Unterscheidung zwischen der bloßen Existenz einer Funktion und ihrer tatsächlichen Eignung: Nahezu jedes ausgereifte ERP-System hat ein Finanzmodul — aber ob dessen Kontenlogik, Bewertungsverfahren und Auswertungen zu den eigenen Anforderungen passen, entscheidet sich erst bei genauem Hinsehen. Die folgenden Fragenblöcke sind als Anregung gedacht und im Einzelfall an die eigene Branche und Größe anzupassen.

Finanzen, Rechnungswesen und Controlling

Das Finanzmodul ist in vielen Auswahlprozessen der Dreh- und Angelpunkt, weil es gesetzlich reguliert und eng mit externen Anforderungen (Steuer, Prüfung, Reporting) verzahnt ist. Mögliche Fragen:
  • Deckt das System Finanzbuchhaltung, Anlagenbuchhaltung und Kostenrechnung im benötigten Umfang ab — und wie sind sie mit den operativen Prozessen verknüpft?
  • Werden die für uns relevanten steuerlichen und regulatorischen Anforderungen (etwa Umsatzsteuer-Logiken, GoBD-Konformität, elektronische Rechnungsformate) unterstützt?
  • Wie flexibel sind Kontenrahmen, Kostenstellen- und Kostenträgerstrukturen sowie das Berichtswesen?
  • Lassen sich Mehrwährungs-, Mehrmandanten- oder Konzernkonsolidierungsanforderungen abbilden, falls relevant?
  • Wie erfolgt die Anbindung an Banken, Zahlungsverkehr und ein etwaiges Reporting an Wirtschaftsprüfer?

Warenwirtschaft, Produktion und Logistik

Für produzierende und handelnde Unternehmen ist die operative Kette oft das eigentliche Herz des ERP. Hier lohnt besondere Tiefe:
  • Wie werden Einkauf, Lagerhaltung, Bestandsführung und Disposition abgebildet, und passt die Logik zu unseren Beschaffungsmustern?
  • Unterstützt das System unsere Produktionsart (etwa Einzel-, Serien- oder Variantenfertigung) mit Stücklisten, Arbeitsplänen und Kapazitätsplanung?
  • Wie werden Chargen, Seriennummern und Rückverfolgbarkeit gehandhabt, falls unsere Branche das verlangt?
  • Deckt das System unsere Versand-, Kommissionier- und Logistikprozesse ab, inklusive etwaiger Anbindung an Lagerverwaltung oder Versanddienstleister?
  • Wie werden Preise, Rabatte, Konditionen und branchentypische Sonderfälle im Verkauf abgebildet?

CRM, Personal und branchenspezifische Module

Über die klassischen Kernmodule hinaus stellt sich die Frage nach ergänzenden Bereichen — und danach, ob diese im ERP selbst oder besser über spezialisierte Nachbarsysteme abgedeckt werden. Ein integriertes CRM kann Vorteile bei den Stammdaten bringen, während ein spezialisiertes Fremdsystem funktional oft tiefer ist. Leitfragen:
  • Welche CRM-Funktionen (Kontakt- und Opportunity-Management, Vertriebssteuerung, Servicefälle) brauchen wir wirklich im ERP, und welche laufen besser in einem Fachsystem?
  • Sollen Personalstammdaten, Zeitwirtschaft oder Lohn/Gehalt im ERP liegen, oder ist ein spezialisiertes HR-System die bessere Wahl — und wie ist dann die Integration geregelt?
  • Gibt es für unsere Branche spezifische Anforderungen (etwa Projektabrechnung, Dienstleistungssteuerung, Field Service), die das System oder ein Zusatzmodul abdecken muss?
  • Wie modular ist das System — lassen sich Bereiche später ergänzen, ohne das Fundament neu aufzusetzen?
Funktion vorführen lassen
Nicht abfragen, sondern zeigen lassen: Statt reiner Ja/Nein-Fragebögen empfiehlt es sich, kritische Funktionen anhand eigener, realistischer Beispielprozesse (Use Cases) live vorführen zu lassen. Ein Anbieter, der Ihren typischen Auftrag von der Anfrage bis zur Rechnung im System durchspielt, liefert mehr Erkenntnis als jede Selbstauskunft im Fragebogen.
Kapitel 04 · Technische Fragen

Technische Fragen: Architektur und Betrieb

Hinter jeder Funktion steht eine technische Architektur, die über Betrieb, Kosten und Zukunftsfähigkeit entscheidet. Die technischen Fragen klären, wie das System gebaut ist, wo es läuft und wie es mitwächst.

Technische Fragen werden von Fachbereichen gern der IT überlassen — zu Unrecht, denn Architekturentscheidungen haben unmittelbare betriebswirtschaftliche Folgen für Kosten, Flexibilität und Abhängigkeit vom Anbieter. Die folgenden Blöcke helfen, die technische Substanz eines Systems einzuschätzen, ohne sich in Details zu verlieren.

Architektur und Betriebsmodell: Cloud oder On-Premise

Die grundlegendste technische Weichenstellung ist die Frage des Betriebsmodells. Sie prägt Kostenstruktur, Verantwortlichkeiten und Datenhoheit gleichermaßen. Zentrale Fragen:
  • Wird das System als Cloud-Lösung (SaaS), im eigenen Rechenzentrum (On-Premise) oder in einer gehosteten Variante angeboten — und welche Modelle unterstützt der Anbieter?
  • Wie modern ist die technische Basis (Web-Oberfläche, mobiler Zugriff, Browserunabhängigkeit), und wie ist der Stand bei der Weiterentwicklung?
  • Wie werden Updates und neue Versionen eingespielt — automatisch in festen Zyklen oder gesteuert durch uns, und mit welchem Aufwand?
  • Wie sind Verfügbarkeit, Wartungsfenster und Notfallwiederherstellung geregelt, und welche Zusagen (Service Levels) macht der Anbieter?
Die Entscheidung zwischen Cloud und On-Premise ist keine reine Technikfrage, sondern eine strategische — sie hängt eng mit Datenschutz, Investitionslogik und interner IT-Kompetenz zusammen und wird in den Kapiteln zu Kosten und Datenschutz weiter vertieft.

Schnittstellen und Erweiterbarkeit

Kein ERP steht allein. Wie offen ein System für die Anbindung anderer Anwendungen ist und wie es sich erweitern lässt, entscheidet maßgeblich über seine Lebensdauer in einer heterogenen Systemlandschaft. Fragen dazu:
  • Welche standardisierten Schnittstellen (etwa moderne Programmierschnittstellen/APIs, Webservices) bietet das System, und wie gut sind sie dokumentiert?
  • Wie werden individuelle Anpassungen und Erweiterungen umgesetzt — im Kern des Systems oder über eine getrennte Erweiterungsebene, die updatefähig bleibt?
  • Wie stark ist das System an proprietäre Techniken gebunden, und welches Risiko einer Anbieterabhängigkeit (Lock-in) ergibt sich daraus?
  • Welche Anforderungen an internes oder externes Know-how entstehen, um das System zu betreiben und weiterzuentwickeln?

Skalierung und Zukunftsfähigkeit

Ein ERP wird für viele Jahre gekauft, und die Anforderungen von morgen sind selten die von heute. Deshalb gehört die Wachstumsfähigkeit in den Katalog. Wichtig ist dabei, realistisch zu bleiben und nicht für hypothetische Extremszenarien zu überdimensionieren, aber absehbare Entwicklungen einzuplanen:
  • Wie verhält sich das System bei steigenden Nutzerzahlen, Datenmengen und Transaktionsvolumina — bleibt die Performance im Einzelfall geprüft stabil?
  • Lässt sich das System auf weitere Standorte, Länder, Sprachen, Währungen oder Mandanten ausweiten, falls unser Wachstum das erfordert?
  • Wie ist der Anbieter für die Zukunft aufgestellt — gibt es eine erkennbare Produkt-Roadmap und kontinuierliche Weiterentwicklung?
  • Wie gut integriert das System neuere Technologien (etwa Automatisierung, Analytik, KI-gestützte Funktionen), und ist das für uns überhaupt relevant?
Balance halten
Technik dient dem Geschäft: Die technischen Fragen sollen die fachliche Eignung absichern, nicht ersetzen. Ein technisch beeindruckendes System, das die Prozesse nicht trifft, nützt wenig — ebenso wenig wie eine perfekt passende Fachlichkeit auf einer veralteten, schwer integrierbaren Basis. Beide Dimensionen gehören gewichtet zusammen bewertet.
Kapitel 05 · Integration & Daten

Integrations- und Datenfragen

Ein ERP-Projekt ist zu einem großen Teil ein Datenprojekt. Wie ein neues System an die vorhandene Landschaft angebunden wird und wie die Altdaten übernommen werden, entscheidet oft über Erfolg oder Frust der Einführung — und wird regelmäßig unterschätzt.

Kaum ein Thema verursacht in ERP-Projekten so viel unerwarteten Aufwand wie die Integration in die bestehende Systemlandschaft und die Migration der Altdaten. Beides gehört früh und explizit in den Fragenkatalog, denn die schönste Funktionalität ist wertlos, wenn das System nicht mit den Nachbarsystemen spricht oder wenn die übernommenen Daten unbrauchbar sind.

Datenmigration: Altdaten sauber übernehmen

Die Übernahme der Bestandsdaten aus dem Altsystem ist ein Projekt im Projekt. Sie ist selten ein bloßer Datentransfer, sondern fast immer auch eine Gelegenheit — und Notwendigkeit — zur Bereinigung. Fragen dazu:
  • Welche Daten müssen übernommen werden (Stammdaten, offene Posten, historische Bewegungsdaten), und über welchen Zeitraum reicht die Historie zurück?
  • In welchem Zustand sind unsere Altdaten — gibt es Dubletten, Lücken, inkonsistente Formate, und wer verantwortet die Bereinigung?
  • Welche Werkzeuge und Verfahren bietet der Anbieter für die Migration, und wie werden Testläufe und Abgleiche organisiert?
  • Wie wird die Vollständigkeit und Richtigkeit der migrierten Daten geprüft und abgenommen?
  • Welche Daten übernehmen wir bewusst nicht, um Altlasten nicht in das neue System zu tragen?
Ein verbreiteter Fehler ist, Altdaten unbesehen zu übernehmen. Das verlängert die Migration, belastet das neue System und verschenkt die Chance auf einen sauberen Start. Die Frage „Welche Daten brauchen wir wirklich?“ ist deshalb ebenso wichtig wie die Frage, wie migriert wird.

Integration in die bestehende Systemlandschaft

Nahezu jedes Unternehmen betreibt neben dem ERP weitere Anwendungen — Online-Shops, Zeiterfassung, Fachsysteme, Dokumentenmanagement, Datenanalyse. Wie gut das ERP sich in dieses Gefüge einfügt, prägt den Alltagsnutzen. Leitfragen:
  • Welche vorhandenen Systeme müssen an das ERP angebunden werden, und welche Datenflüsse (Richtung, Häufigkeit, Volumen) sind dafür nötig?
  • Bietet der Anbieter für die wichtigsten Nachbarsysteme fertige Konnektoren, oder müssen Schnittstellen individuell entwickelt werden?
  • Wie werden Stammdaten über Systemgrenzen hinweg konsistent gehalten — welches System ist die führende Quelle?
  • Wie robust und wartbar sind die Schnittstellen im laufenden Betrieb, und wer verantwortet sie nach dem Go-live?

Altsysteme und Übergangsszenarien

Selten wird an einem Stichtag das gesamte alte System abgeschaltet und das neue vollständig produktiv geschaltet. Häufig gibt es Übergangsphasen, in denen Alt- und Neusystem parallel laufen oder einzelne Bereiche gestaffelt umgestellt werden. Diese Szenarien wollen bedacht sein:
  • Wird das neue System in einem Schritt eingeführt oder schrittweise, und welches Vorgehen empfiehlt der Anbieter für unsere Situation?
  • Wie werden Altsysteme, aus denen wir nur noch lesen wollen (Archivzugriff auf Historie), behandelt — Migration, Parallelbetrieb oder Archivlösung?
  • Wie lange müssen wir aus regulatorischen Gründen auf Altdaten zugreifen können, und wie wird das gewährleistet?
  • Welche Risiken entstehen in der Übergangsphase, und wie werden sie abgesichert (Rückfallebene, Testbetrieb)?
Kostentreiber Integration
Realistisch einplanen: Datenmigration und Schnittstellen zählen erfahrungsgemäß zu den teuersten und riskantesten Themen einer ERP-Einführung. Wer sie im Fragenkatalog und in der Budgetplanung stiefmütterlich behandelt, erlebt böse Überraschungen. Der konkrete Aufwand ist stark vom Einzelfall abhängig und gehört früh mit dem Anbieter durchgesprochen.
Kapitel 06 · Anbieter & Partner

Anbieter- und Partnerfragen

Ein ERP-System wird nicht nur gekauft, sondern über Jahre gemeinsam mit einem Anbieter und meist einem Implementierungspartner betrieben. Diese Beziehung ist so wichtig wie die Software selbst — und gehört ebenso gründlich geprüft.

Die Auswahl eines ERP ist immer auch die Wahl eines langjährigen Partners. Selbst das beste System nützt wenig, wenn der Anbieter unzuverlässig ist, der Support schlecht erreichbar oder der Implementierungspartner die eigene Branche nicht versteht. Der Fragenkatalog sollte deshalb Anbieter und Partner ebenso systematisch beleuchten wie das Produkt — und dabei zwischen dem Softwarehersteller und dem oft davon getrennten Einführungspartner unterscheiden.

Referenzen und Branchenerfahrung

Die beste Auskunft über einen Anbieter geben Kunden, die mit ihm gearbeitet haben — idealerweise aus einer vergleichbaren Branche und Größenordnung. Referenzen sind mehr als Marketing, wenn man die richtigen Fragen stellt:
  • Kann der Anbieter Referenzkunden ähnlicher Größe und Branche benennen, mit denen wir sprechen dürfen?
  • Wie viele Einführungen dieser Art hat der konkrete Implementierungspartner (nicht nur der Hersteller) bereits durchgeführt?
  • Versteht der Partner unsere Branche und ihre Besonderheiten, oder müssten wir ihm unser Geschäft erst erklären?
  • Was berichten Referenzkunden über Einhaltung von Zeit und Budget, über die Zusammenarbeit und über die Phase nach dem Go-live?

Support, Wartung und Servicequalität

Nach der Einführung beginnt die lange Phase des Betriebs, in der Supportqualität und Wartung den Alltag prägen. Diese Themen werden bei der Auswahl oft vernachlässigt, weil sie in der Aufbruchstimmung fern wirken. Fragen:
  • Wie ist der Support organisiert — Erreichbarkeit, Sprachen, Reaktionszeiten, Eskalationswege — und was ist vertraglich zugesichert?
  • Wer leistet den Support: der Hersteller, der Partner oder beide, und wie ist die Zuständigkeit im Störungsfall geregelt?
  • Wie werden Wartung, Fehlerbehebung und Weiterentwicklung nach dem Go-live gehandhabt und abgerechnet?
  • Welche Unterstützung gibt es in der kritischen Stabilisierungsphase unmittelbar nach der Produktivsetzung?

Unternehmensstabilität und Roadmap

Weil ein ERP eine langfristige Bindung ist, zählt auch die Stabilität und Perspektive des Anbieters. Ein Hersteller, dessen Produkt abgekündigt wird oder der wirtschaftlich wackelt, wird schnell zum Risiko. Prüffragen:
  • Wie ist der Anbieter wirtschaftlich und personell aufgestellt, und wie lange ist er bereits mit dem Produkt am Markt?
  • Gibt es eine erkennbare, glaubwürdige Produkt-Roadmap, und wie werden Kunden in die Weiterentwicklung einbezogen?
  • Wie ist die Verfügbarkeit von Fachkräften und Partnern für dieses System am Markt — finden wir künftig Unterstützung?
  • Welche Möglichkeiten haben wir, im Fall der Fälle das System zu wechseln, und wie hoch wäre die Abhängigkeit (Lock-in)?
Hersteller ist nicht Partner
Zwei Beziehungen prüfen: In vielen Fällen kaufen Sie die Software beim Hersteller, werden aber von einem eigenständigen Partner eingeführt und betreut. Beide Beziehungen sind erfolgskritisch und sollten getrennt bewertet werden — ein gutes Produkt beim falschen Partner kann ebenso scheitern wie ein starker Partner mit einem unpassenden Produkt.
Kapitel 07 · Kaufmännische Fragen

Kaufmännische Fragen: Lizenz, TCO und Vertrag

Die kaufmännischen Fragen entscheiden darüber, ob die Auswahl auch wirtschaftlich trägt. Sie reichen weit über den Angebotspreis hinaus — denn die wahren Kosten eines ERP zeigen sich erst über den gesamten Lebenszyklus.

Der häufigste kaufmännische Fehler bei einer ERP-Auswahl ist, den Lizenz- oder Abopreis für die Gesamtkosten zu halten. Tatsächlich ist die Software oft nur ein Teil der Rechnung; Einführung, Betrieb und Weiterentwicklung dominieren die Gesamtkosten über die Jahre. Der Fragenkatalog muss deshalb die kaufmännische Betrachtung von Anfang an breit anlegen und auf die Total Cost of Ownership (TCO) zielen, nicht auf den Einstiegspreis.

Lizenz- und Betriebsmodelle verstehen

ERP-Anbieter kalkulieren sehr unterschiedlich, und die Modelle sind selten direkt vergleichbar. Ziel der Fragen ist, die Preislogik transparent zu machen und versteckte Kostentreiber aufzudecken:
  • Handelt es sich um ein Kauf-/Lizenzmodell mit Einmalinvestition oder um ein Abomodell mit laufenden Gebühren — und was ist jeweils enthalten?
  • Wonach richtet sich der Preis (Nutzerzahl, Module, Funktionsumfang, Transaktionsvolumen), und wie verhält er sich bei Wachstum?
  • Welche Kosten fallen zusätzlich zur reinen Software an — für Einführung, Anpassungen, Schnittstellen, Schulung, Wartung und Betrieb?
  • Gibt es Staffelungen, Mindestabnahmen oder Kosten, die erst bei bestimmter Nutzung sichtbar werden?

Total Cost of Ownership über den Lebenszyklus

Eine belastbare TCO-Betrachtung trennt einmalige Projektkosten von laufenden Betriebskosten und zieht einen realistischen Zeithorizont von typischerweise mehreren Jahren. Nur so wird sichtbar, dass ein günstiger Einstieg teuer und ein teurer Einstieg über die Jahre günstig sein kann. Zu bedenken sind unter anderem:
  • Einmalige Projektkosten — Beratung, Konfiguration, Datenmigration, Anpassungen, Schulung und Stabilisierung; erfahrungsgemäß der größte Block.
  • Laufende Betriebskosten — Lizenz-/Abogebühren, Wartung, Infrastruktur (bei On-Premise), internes Betriebsteam und regelmäßige Release-Anpassungen.
  • Interne Personalkosten — die über Monate gebundene Arbeitszeit von Projektleitung, Key Usern und Fachbereichen; real, aber in keinem Angebot ausgewiesen.
  • Kosten für Weiterentwicklung — neue Anforderungen, zusätzliche Module, weitere Schnittstellen über die Nutzungsdauer.
Konkrete Preise und Faktoren sind stark vom Einzelfall abhängig und lassen sich nicht seriös pauschalieren; sie gehören im konkreten Angebot geprüft und über den gesamten Lebenszyklus gerechnet, nicht aus Sekundärquellen übernommen.

Vertragslaufzeit und vertragliche Absicherung

Der Vertrag ist das Dokument, das im Streitfall zählt. Gerade bei Abomodellen und Cloud-Lösungen verdienen Laufzeiten, Kündigung und Ausstiegsszenarien besondere Aufmerksamkeit. Fragen dazu:
  • Welche Vertragslaufzeiten und Kündigungsfristen gelten, und wie sind Preisanpassungen über die Laufzeit geregelt?
  • Wie kommen wir im Fall einer Trennung wieder an unsere Daten (Datenexport, Formate, Fristen), und welche Kosten entstehen dabei?
  • Welche Leistungen und Service Levels sind verbindlich zugesichert, und welche Konsequenzen hat eine Nichteinhaltung?
  • Werden zentrale Zusagen aus dem Auswahlprozess (Funktionen, Termine, Aufwände) verbindlich in den Vertrag oder das Pflichtenheft überführt?
Vertragshinweis
Keine Rechtsberatung: Die hier genannten kaufmännischen und vertraglichen Fragen sind eine praxisorientierte Orientierung, kein Ersatz für eine juristische Prüfung. Vertragslaufzeiten, Haftung, Datenexport und Preisanpassungsklauseln sollten im Einzelfall mit fachkundiger rechtlicher Begleitung geprüft werden, bevor unterschrieben wird.
Kapitel 08 · Bewertung & Gewichtung

Bewertung und Gewichtung der Antworten

Ein Fragenkatalog ist erst dann ein Entscheidungswerkzeug, wenn die Antworten strukturiert bewertet werden. Erst Gewichtung und Scoring machen aus einer Sammlung von Einzelurteilen ein nachvollziehbares, vergleichbares Gesamtbild.

Wenn alle Fragen gestellt und beantwortet sind, steht die Organisation vor einer Fülle von Informationen. Ohne eine systematische Auswertung droht die Entscheidung, doch wieder aus dem Bauch zu fallen — oder von der lautesten Stimme im Raum bestimmt zu werden. Ein einfaches, transparentes Bewertungsverfahren verhindert das und macht die Entscheidung auch gegenüber Geschäftsführung und Gremien begründbar.

Muss-, Soll- und Kann-Kriterien

Der erste Schritt jeder Bewertung ist die Trennung nach Verbindlichkeit. Nicht jede Anforderung wiegt gleich schwer, und einige sind schlicht unverzichtbar. Bewährt hat sich eine dreistufige Einteilung:
  • Muss-Kriterien (K.-o.-Kriterien) — Anforderungen, ohne die ein System nicht in Frage kommt. Wer sie nicht erfüllt, scheidet aus, unabhängig von allen anderen Stärken.
  • Soll-Kriterien — wichtige, aber nicht existenzielle Anforderungen, die stark in die Bewertung eingehen und Unterschiede zwischen den Kandidaten sichtbar machen.
  • Kann-Kriterien — wünschenswerte Zusatzfunktionen, die den Ausschlag geben können, wenn Kandidaten ansonsten gleichauf liegen, aber nicht überbewertet werden dürfen.
Die saubere Trennung dieser Ebenen ist entscheidend. Ein häufiger Fehler ist, zu viele Anforderungen zu Muss-Kriterien zu erklären — dann bleibt am Ende kein System übrig, oder die K.-o.-Logik wird aufgeweicht und verliert ihren Sinn. Muss-Kriterien sollten wirklich nur das Unverzichtbare umfassen.

Gewichtung und Scoring in der Praxis

Für die Soll- und Kann-Kriterien empfiehlt sich ein einfaches Punktbewertungsverfahren (Nutzwertanalyse). Jedes Kriterium erhält ein Gewicht, das seine Bedeutung ausdrückt, und für jedes System wird pro Kriterium ein Erfüllungsgrad vergeben. Aus Gewicht und Erfüllungsgrad ergibt sich eine Punktzahl, deren Summe die Kandidaten vergleichbar macht. Wichtig ist, die Gewichte vor der Bewertung der Anbieter festzulegen, damit nicht nachträglich das Ergebnis zurechtgebogen wird.
Kriterienart Rolle in der Bewertung Umgang bei Nichterfüllung
Muss-Kriterium Grundvoraussetzung, nicht verhandelbar Kandidat scheidet aus
Soll-Kriterium Wesentlich, geht gewichtet ins Scoring ein Punktabzug, kein Ausschluss
Kann-Kriterium Zusatznutzen, gibt bei Gleichstand den Ausschlag Geringe Auswirkung
Das Ergebnis eines solchen Scorings ist kein Automat, der die Entscheidung fällt, sondern eine strukturierte Diskussionsgrundlage. Liegen zwei Kandidaten nah beieinander, lohnt der Blick hinter die Zahlen: Wo genau liegen die Unterschiede, und wie belastbar waren die Antworten? Zahlen schaffen Transparenz, ersetzen aber nicht das fachliche Urteil des Auswahlteams.

Von der Longlist zur Entscheidung

In der Praxis verläuft die Auswahl meist mehrstufig, und der Fragenkatalog wird in jeder Stufe mit wachsender Tiefe eingesetzt. Zunächst grenzt eine breite Longlist anhand der Muss-Kriterien und weniger Grundfragen den Markt ein. Aus ihr entsteht eine kompakte Shortlist weniger Kandidaten, die den vollen Katalog beantworten, Referenzen benennen und ihre Lösung anhand realer Beispielprozesse vorführen. Erst am Ende steht die begründete Entscheidung, in die Scoring, Teststellungen, Referenzgespräche und der Gesamteindruck einfließen. Diese Staffelung hält den Aufwand beherrschbar und richtet die Tiefe der Prüfung auf die aussichtsreichsten Kandidaten.
Gewichte zuerst
Reihenfolge zählt: Legen Sie Kriterien und Gewichte fest, bevor Sie Anbieter bewerten. Wer erst die Angebote sieht und dann die Gewichte anpasst, verliert die Objektivität — das Scoring bestätigt dann nur noch eine bereits gefallene Vorliebe, statt sie zu prüfen.
Kapitel 09 · DSGVO, Sicherheit & Datenhoheit

DSGVO-, Sicherheits- und Datenhoheitsfragen

Ein ERP-System verarbeitet die sensibelsten Daten eines Unternehmens — von Personaldaten über Kundeninformationen bis zu Geschäftszahlen. Datenschutz, Sicherheit und Datenhoheit gehören deshalb nicht ans Ende des Katalogs, sondern verbindlich hinein.

In der DACH-Region haben Datenschutz und Datensouveränität einen besonders hohen Stellenwert, rechtlich wie kulturell. Ein ERP-Projekt, das diese Fragen erst nachträglich stellt, riskiert teure Korrekturen oder eine grundsätzlich falsche Weichenstellung — etwa bei der Wahl zwischen Cloud und On-Premise oder beim Serverstandort. Die folgenden Fragen helfen, das Thema systematisch abzudecken, ersetzen aber keine fachkundige rechtliche Prüfung.

Serverstandort, Hosting und Datenhoheit

Wo die Daten physisch liegen und wer rechtlich auf sie zugreifen kann, ist eine Kernfrage der Datensouveränität — besonders bei Cloud-Lösungen. Fragen dazu:
  • Wo werden die Daten gespeichert und verarbeitet — in Deutschland, im EU-Raum oder außerhalb, und lässt sich der Standort vertraglich festlegen?
  • Wer hat rechtlich und technisch Zugriff auf die Daten, und bestehen Risiken durch den Zugriff von Behörden aus Drittstaaten?
  • Wie wird sichergestellt, dass wir jederzeit Herr unserer Daten bleiben und sie bei Bedarf vollständig exportieren können?
  • Bei On-Premise: Welche Anforderungen an die eigene Infrastruktur und deren Absicherung ergeben sich daraus?

Auftragsverarbeitung und rechtliche Rahmenbedingungen

Wenn ein Anbieter personenbezogene Daten in unserem Auftrag verarbeitet — was bei Cloud-ERP regelmäßig der Fall ist — verlangt die DSGVO klare vertragliche Grundlagen. Prüffragen:
  • Stellt der Anbieter einen Vertrag zur Auftragsverarbeitung (AVV) bereit, und deckt dieser die tatsächlichen Verarbeitungen ab?
  • Werden Unterauftragsverarbeiter transparent gemacht, und wie ist deren Einbindung geregelt?
  • Wie unterstützt das System die Erfüllung von Betroffenenrechten (Auskunft, Löschung, Berichtigung) und die gesetzlichen Aufbewahrungs- und Löschfristen?
  • Wie werden Datenschutzvorfälle behandelt, und welche Melde- und Informationspflichten übernimmt der Anbieter?

Sicherheit, Zertifikate und Nachweise

Neben dem rechtlichen Rahmen zählt die tatsächliche technische und organisatorische Sicherheit. Anerkannte Zertifikate und Nachweise sind ein Indiz, ersetzen aber nicht die eigene Prüfung. Fragen:
  • Welche anerkannten Sicherheitszertifizierungen und Standards (etwa für Informationssicherheits-Management) kann der Anbieter nachweisen?
  • Wie sind Verschlüsselung (bei Übertragung und Speicherung), Zugriffskontrolle und Rechteverwaltung im System umgesetzt?
  • Wie werden Datensicherung, Wiederherstellung und Notfallszenarien organisiert und getestet?
  • Gibt es unabhängige Prüfberichte oder Audits, die wir einsehen können, statt uns auf Selbstauskünfte zu verlassen?
Datenschutz & Datenhoheit im Blick

Datenschutz und Souveränität sind bei der ERP-Auswahl im DACH-Mittelstand kein Randthema, sondern ein eigenständiges Bewertungsfeld. Die folgenden Punkte gehören früh geklärt — vor der Editions- und Betriebsmodellentscheidung, nicht danach.

Serverstandort
Speicherort und Verarbeitung vertraglich festlegen
AVV
Auftragsverarbeitung sauber vereinbaren
Zertifikate
Anerkannte Nachweise statt Selbstauskunft
Datenexport
Rückgabe und Portabilität sichern
Wichtiger Hinweis
Keine Rechtsberatung: Die Fragen und Hinweise in diesem Kapitel dienen der praktischen Orientierung und ersetzen keine individuelle rechtliche oder datenschutzfachliche Beratung. Datenschutzrechtliche Bewertungen, insbesondere zu Drittstaaten-Transfers und Auftragsverarbeitung, sollten im Einzelfall mit den eigenen Datenschutz- und Rechtsverantwortlichen geprüft werden.
Kapitel 10 · Häufige Fragen

Häufig gestellte Fragen zum ERP-Fragenkatalog

Was ist ein ERP-Fragenkatalog in einem Satz?
Ein ERP-Fragenkatalog ist eine strukturierte, nach Themenfeldern gegliederte Sammlung von Fragen und Kriterien, mit der ein Unternehmen zunächst die eigenen Anforderungen klärt und anschließend Anbieter systematisch und vergleichbar prüft — er ist die Arbeitsgrundlage für Lastenheft und Auswahlentscheidung.
Worin unterscheiden sich Fragenkatalog, Lastenheft und Pflichtenheft?
Der Fragenkatalog ist das Arbeitswerkzeug, mit dem Anforderungen erhoben und Anbieter befragt werden. Das Lastenheft beschreibt aus Kundensicht, was das System leisten soll, und dient als Ausschreibungsgrundlage. Das Pflichtenheft ist die Antwort des Anbieters, das beschreibt, wie die Anforderungen umgesetzt werden, und wird häufig Vertragsbestandteil. Der Katalog liefert das Gerüst für Lastenheft und spätere Bewertung.
Wer sollte den Fragenkatalog erstellen?
Nicht die IT allein und nicht die Geschäftsführung allein. Ein tragfähiger Katalog entsteht im Zusammenspiel der Fachbereiche (Finanzen, Vertrieb, Einkauf, Produktion, Lager), der späteren Key User, der IT und der Datenschutz- und Compliance-Verantwortlichen. Nur wenn alle relevanten Perspektiven einfließen, deckt der Katalog die realen Anforderungen ab und die spätere Akzeptanz stimmt.
Wie viele Fragen sollte ein ERP-Fragenkatalog enthalten?
Es gibt keine richtige Zahl. Ein Katalog sollte umfassend genug sein, um die geschäftskritischen Themen aller Bereiche abzudecken, aber fokussiert genug, um auswertbar zu bleiben. Entscheidend ist nicht die Menge, sondern die Relevanz: Lieber wenige präzise Fragen zu den wirklich wichtigen Prozessen als hunderte generische Ja/Nein-Fragen, die niemand ernsthaft auswertet. Umfang und Tiefe sind im Einzelfall an Größe und Branche anzupassen.
Sollte man Muss- und Kann-Kriterien wirklich strikt trennen?
Ja, diese Trennung ist zentral. Muss-Kriterien sind K.-o.-Kriterien: Wer sie nicht erfüllt, scheidet aus. Sie sollten nur das wirklich Unverzichtbare umfassen. Soll-Kriterien gehen gewichtet ins Scoring ein, Kann-Kriterien geben bei Gleichstand den Ausschlag. Werden zu viele Anforderungen zu Muss-Kriterien erklärt, bleibt am Ende kein System übrig oder die K.-o.-Logik verliert ihren Sinn.
Wie bewertet man die Antworten fair und nachvollziehbar?
Bewährt hat sich ein einfaches Punktbewertungsverfahren (Nutzwertanalyse): Jedes Kriterium erhält ein Gewicht, jeder Anbieter pro Kriterium einen Erfüllungsgrad, und die gewichtete Summe macht die Kandidaten vergleichbar. Wichtig ist, die Gewichte vor der Bewertung der Anbieter festzulegen. Das Scoring ist eine Diskussionsgrundlage, kein Automat — bei knappen Ergebnissen zählt der Blick hinter die Zahlen.
Welche Fragen werden am häufigsten vergessen?
Erfahrungsgemäß die unbequemen: Datenmigration und Datenqualität, Schnittstellen zu Nachbarsystemen, die Servicequalität nach dem Go-live, die Trennung von Hersteller und Implementierungspartner, die internen Personalkosten sowie Datenschutz und Datenhoheit. Diese Themen wirken bei der Auswahl fern, entscheiden aber später über Erfolg, Kosten und Zufriedenheit — der Katalog sollte sie deshalb bewusst nach vorne holen.
Kann ein Fragenkatalog Produktdemos ersetzen?
Nein, er ergänzt sie. Der Katalog strukturiert, was geprüft wird, und macht Antworten vergleichbar. Ob eine zugesagte Funktion aber im konkreten Prozess wirklich passt, zeigt sich erst in einer Vorführung anhand eigener, realistischer Beispielprozesse und idealerweise einer Teststellung. Fragenkatalog und praktische Erprobung gehören zusammen — der eine ohne die andere führt leicht in die Irre.
Gilt der Katalog auch für kleinere Unternehmen?
Ja, das Prinzip skaliert. Kleinere Unternehmen brauchen keinen hundertseitigen Katalog, profitieren aber ebenso von der strukturierten Vorgehensweise: eigene Anforderungen zuerst klären, dann vergleichbar abfragen, sauber bewerten. Umfang und Tiefe passt man der eigenen Größe und Komplexität an — die Systematik bleibt dieselbe und schützt in jeder Größenordnung vor teuren Fehlentscheidungen.
Ist dieser Fragenkatalog eine Rechtsberatung?
Nein. Dieser Beitrag liefert eine herstellerneutrale, praxisorientierte Orientierung für die ERP-Auswahl. Er ersetzt keine individuelle rechtliche, steuerliche oder datenschutzfachliche Beratung. Insbesondere vertragliche und datenschutzrechtliche Fragen — etwa zu Laufzeiten, Haftung, Auftragsverarbeitung und Drittstaaten-Transfers — sollten im Einzelfall mit fachkundiger Begleitung geprüft werden.

ERP-Auswahl strukturiert angehen

Brauchen Sie einen belastbaren ERP-Fragenkatalog?

Wir helfen herstellerunabhängig, Ihre Anforderungen sauber zu erheben, daraus einen fokussierten Fragenkatalog und ein Lastenheft zu entwickeln und die Anbieter vergleichbar zu bewerten – pragmatisch und auf den Mittelstand zugeschnitten.

Seit 2006 am Markt

Erfahrung aus über 100 Digitalprojekten

DSGVO & Souveränität

Datenschutz von Anfang an mitgedacht

Rückmeldung in 24 h

Schnell, direkt, unverbindlich