Fit-Gap-Analyse (Abgleich von Anforderung und Standard)
Kurz gesagt
Die Fit-Gap-Analyse vergleicht jede Anforderung an ein Standard-ERP mit dem Funktionsumfang des gelieferten Systems und stuft sie ein; die Einteilung in Fit, Konfiguration, Erweiterung und Lücke (Gap) ist eine redaktionelle Ordnung dieses Artikels, die die geöffneten Normen und Glossare nicht vorschreiben. Sie steht nach dem Priorisieren der Anforderungen und vor dem Customizing, stützt sich auf einen festgelegten Systemstand und ein Testsystem und endet mit einer Aufwands- und Entscheidungsliste. Sie ist keine gesetzliche Vorgabe und gilt in Deutschland, Österreich und der Schweiz gleich.
Das Wichtigste
- Die Fit-Gap-Analyse gleicht jede einzelne ERP-Anforderung mit dem Standard des geprüften Systems ab.
- Vier Bewertungsstufen: Fit, Konfiguration, Erweiterung und Lücke (Gap); die Einteilung ist eine redaktionelle Ordnung dieses Artikels, kein Verfahren aus den hier geöffneten Normen und Glossaren.
- Grundlage sind ein vorher festgelegter Systemstand und ein Testsystem, nicht der Verkaufsvortrag.
- Fit und Konfiguration ändern keinen Quellcode; die Erweiterung ist Programmierung.
- Eine Lücke wird entschieden: Prozess ändern, Anforderung streichen oder Lösung neben dem Kern.
- ISO/IEC/IEEE 29148:2018 ist eine Norm, kein Gesetz: Verbindlich wird sie, soweit Vertrag, Regelung oder Weisung sie in Bezug nehmen; ihr öffentlich einsehbares Abstract beschreibt die Fit-Gap-Analyse nicht.
Fit-Gap-Analyse (deutsch: Abgleich von Anforderung und Standard) ist der Vergleich jeder einzelnen Anforderung an ein Standard-ERP mit dem Funktionsumfang, den das gelieferte System bietet; jede Anforderung wird dabei einer Stufe zugeordnet — hier Fit, Konfiguration, Erweiterung oder Lücke. Diese vier Stufen sind eine redaktionelle Ordnung dieses Artikels: In den für diesen Artikel geöffneten Quellen (öffentlich einsehbares Abstract der ISO/IEC/IEEE 29148:2018, CPRE-Glossar 2.2.0, CPRE-Lehrplan 3.3.0) ist eine solche Einteilung nicht beschrieben.
Wozu der Abgleich dient
Ein Standard-ERP entsteht für einen anonymen Markt und deckt die Anforderungen eines einzelnen Betriebs deshalb nur zu einem gewissen Grad ab (Enzyklopädie der Wirtschaftsinformatik, Stichwort Customizing von Standardsoftware). Ob dieser Grad ausreicht, zeigt nicht das Produktdatenblatt, sondern der Abgleich mit der eigenen Anforderungsliste. Sein Ergebnis trägt die Entscheidung: Prozess an das System anpassen, System an den Prozess anpassen oder eine Anforderung fallen lassen. Der Abgleich steht damit nach dem Priorisieren der Anforderungen und vor dem Customizing, das die Anpassung dann ausführt.
So läuft sie ab
- Grundlage festlegen. Halten Sie vor der ersten Sitzung schriftlich fest, welcher Stand des Standards verbindlich ist: Release, Modulumfang und die Umgebung, in der geprüft wird (Referenzmodell, Demo- oder Testsystem). In einem geprüften Projekt der Schweizer Bundesverwaltung beanstandete die Eidgenössische Finanzkontrolle genau diesen Punkt: Es war nicht definiert, welcher Stand des Standards gilt, obwohl die Analyse eine Abdeckung von rund 80 Prozent auswies (EFK-Bericht EFK-20402 vom 13. Oktober 2021).
- Anforderungen prüfen. Jede Position soll eine überprüfbare Aussage über eine Fähigkeit oder Eigenschaft des Systems sein, nicht ein Wunsch (IREB CPRE Glossar, Stichwort Anforderung). Anforderungen werden geprüft, bevor sie bewertet werden (CPRE-Lehrplan, Abschnitt 4.4).
- Im System nachstellen. Lassen Sie jede Anforderung im Testsystem vorführen, statt sie aus der Präsentation zu bewerten. Prüfen Sie mit eigenen Szenarien statt mit dem vorgeführten Ablauf (Demo mit eigenen Szenarien).
- Bewerten und belegen. Ordnen Sie jede Anforderung einer der vier Stufen unten zu und notieren Sie den Beleg: Funktionsort, Testfall, Bildschirm oder Auswertung.
- Aufwand und Entscheid. Schätzen Sie je Abweichung den Aufwand, bündeln Sie die Entscheidungen und halten Sie das Ergebnis schriftlich fest, bevor es in Vertrag oder Pflichtenheft übergeht. Spätere Nachträge laufen als Change Request (Change Requests steuern).
Die vier Bewertungsstufen
Die Stufen sind eine redaktionelle Einordnung (Stand 14. Oktober 2026). Ein Verfahren für diese Einteilung führen die hier geöffneten Quellen — das öffentlich einsehbare Abstract der ISO/IEC/IEEE 29148:2018, das CPRE-Glossar 2.2.0 und der CPRE-Lehrplan 3.3.0 — nicht.
| Bewertung | Bedeutung | Was zu prüfen ist |
|---|---|---|
| Fit | im gelieferten Standard vorhanden, ohne Anpassung nutzbar | Nachweis im Testsystem; Einstellung, die trotzdem nötig ist |
| Konfiguration | durch Einstellen von Feldern, Tabellen und Regeln erreichbar, ohne Programmierung | wer die Einstellung pflegt; Wirkung auf spätere Updates |
| Erweiterung | nur mit einem eigenen Programmteil über die vorgesehene Schnittstelle erreichbar | Aufwand, Zuständigkeit, Verhalten bei Updates |
| Lücke (Gap) | im System nicht erreichbar; nur über Prozessänderung, Streichen oder eine Lösung neben dem Kern zu schließen | Entscheidung auf Leitungsebene; Kosten der Alternativen |
Die Unterscheidung zwischen Konfiguration, Parametrisierung und Erweiterungsprogrammierung folgt der Einteilung der Standardsoftware-Anpassung (Enzyklopädie der Wirtschaftsinformatik, Stichwort Customizing von Standardsoftware). Lassen sich betriebliche Prozesse durch das Customizing nicht abbilden, kann ein Unternehmen nach derselben Quelle gezwungen sein, seine Abläufe an die Standardsoftware anzupassen, womit Wettbewerbsvorteile verloren gehen können. Ob eine Abweichung vom Standard tragbar ist, prüfen Sie nach dem Stichwort Einsatzvoraussetzungen für Standardsoftware daran, ob sie den eigenen Wettbewerbsvorteil berührt: Ist sie nicht wettbewerbsrelevant, kommt nach dieser Quelle auch in Betracht, auf die Anforderung zu verzichten oder den Teil über eine Erweiterungsprogrammierung zu ergänzen, statt die Standardsoftware zu verändern oder Individualsoftware zu beschaffen.
Beispieltabelle mit fünf Anforderungen
Erfundenes Beispiel (Beispielrechnung) für einen Handelsbetrieb, der zwei Systeme vergleicht; die Zahlen sind Annahmen, keine Marktwerte. Aufwandsklassen: K1 unter 1 Personentag, K2 zwei bis fünf Personentage, K3 ab zehn Personentagen, K4 offen bis zum Entscheid.
| Nr. | Anforderung | Bewertung | Beleg | Aufwandsklasse |
|---|---|---|---|---|
| 1 | Bestand je Lagerort und Charge führen | Fit | im Testsystem gezeigt | K1 |
| 2 | Deckungsbeitrag je Kunde aus Umsatz und Wareneinsatz | Fit | Standardauswertung, nur Feldauswahl | K1 |
| 3 | Staffelpreise je Kundengruppe und Menge | Konfiguration | Preisfindungstabelle gesetzt und durchgerechnet | K2 |
| 4 | Seriennummernabgleich beim Kommissionieren über das Handscanner-Gerät | Erweiterung | eigener Programmteil über die angebotene Schnittstelle | K3 |
| 5 | Auftragsbestätigung automatisch aus der Verfügbarkeit terminieren und im Kundenportal anzeigen | Lücke | im Testsystem nicht abbildbar | K4 |
Vier der fünf Anforderungen sind abgedeckt: zwei als Fit, eine über Konfiguration, eine über eine Erweiterung; die fünfte bleibt offen. Zählen Sie die Abdeckung je Bewertungsstufe aus, nicht als eine Zahl — sonst verschwindet der Unterschied zwischen einer Einstellung und einer Programmierung. Für eine Lücke stehen mehrere Wege offen: Sie lässt sich als Erweiterung schließen, über eine Prozessänderung vermeiden, streichen oder durch eine Lösung neben dem Kern ersetzen; vergleichen Sie die Wege im Aufwand und gegen die Alternative einer Individualentwicklung.
Standardbasis
ISO/IEC/IEEE 29148:2018 beschreibt die Prozesse und Ergebnisse der Anforderungstechnik, den Aufbau einer guten Anforderung und Merkmale von Anforderungen (IEEE Standards Association, Status Active Standard, veröffentlicht am 30. November 2018). Er ist eine Norm, kein Gesetz: Verbindlich wird er, soweit ein Vertrag, eine Regelung oder eine Weisung ihn in Bezug nimmt. Das öffentlich einsehbare Abstract dieser Norm beschreibt die Fit-Gap-Analyse nicht; der Volltext ist kostenpflichtig. Die Prüfung, ob Anforderungen die nötige Qualität haben, beschreibt der CPRE-Lehrplan als Validierung von Anforderungen (Version 3.3.0 vom 1. April 2026, Abschnitt 4.4); das CPRE-Glossar (Version 2.2.0 vom 1. Oktober 2025) definiert Anforderung als Bedürfnis, als Fähigkeit oder Eigenschaft eines Systems oder als dokumentierte Darstellung davon.
Nicht zu verwechseln mit
- Customizing: führt die Anpassung aus, die der Abgleich als Konfiguration oder Erweiterung ausweist; die Analyse selbst ändert nichts am System.
- Ist-Aufnahme: hält die heutigen Abläufe fest; der Abgleich stellt dagegen die Soll-Anforderungen dem Standard gegenüber.
- Anforderungsvalidierung: prüft die Qualität der Anforderungen an sich (CPRE-Lehrplan, Abschnitt 4.4); der Abgleich prüft ihre Abdeckung durch ein bestimmtes System.
- Test: der Abnahmetest am gelieferten System prüft nach dem Vertrag, ob der Ablauf mit echten Daten trägt; der Abgleich ordnet vorher ein, was der Standard kann. Prototyping sowie Alpha- und Betatests gehören nach dem CPRE-Lehrplan (Abschnitt 4.4) dagegen schon zur Validierung der Anforderungen.