Proof of Concept in der ERP-Auswahl
Stand: November 2026
Ein Proof of Concept (PoC) prüft in der ERP-Auswahl, ob ein kritischer Punkt im Zielsystem mit den Daten und Abläufen des Unternehmens funktioniert, bevor der Vertrag unterschrieben ist. Er steht am Ende der Feinauswahl, nach Anbieterpräsentationen und Prozessworkshops, und gilt nur den Themen, die bis dahin niemand belastbar zeigen konnte. Was er taugt, entscheidet sich vor dem Start: an einem klaren Ziel und an Erfolgskriterien, die das Unternehmen festlegt, bevor der Anbieter beginnt.
Kernaussagen
- Ein Proof of Concept prüft einen kritischen Punkt im Zielsystem, nicht das ganze System. In unseren Auswahlprojekten gibt es dafür genau einen, in der Regel mit dem Anbieter, der sich in den Prozessworkshops durchgesetzt hat.
- Von einer Demo unterscheidet ihn, wer bestimmt. Das Unternehmen gibt Szenario und Testdaten vor und legt die Erfolgskriterien schriftlich fest, bevor der Anbieter beginnt.
- Ein Proof of Concept lohnt sich nur für Muss-Kriterien, die bisher bloß zugesagt sind. Was die Präsentation oder ein Referenzbesuch schon belegt hat, muss er nicht noch einmal zeigen.
- Fällt ein Muss-Kriterium im Proof of Concept durch, wird die Shortlist wieder geöffnet. Genau dafür ist er da: Zusagen aus dem Vertrieb, die technisch nicht zu halten sind, sollen vor dem Vertrag auffallen.
Forschung und Praxis beschreiben den Proof of Concept als begrenzten Nachweis vor einer Entscheidung
Der Begriff stammt nicht aus der ERP-Welt, und seine Bedeutung schwankt je nach Fach. Vier Fassungen nebeneinander:
| Quelle | Was dort gemeint ist | Blickwinkel |
|---|---|---|
| Antognolli und Petrillo, Preprint 2026 [1] | Ein kurzes Experiment, das Annahmen in begrenztem Umfang prüft, die Machbarkeit bewertet, Risiken senkt und Entscheidungen stützt. Sein Ergebnis ist ein Beleg, keine Software; der dafür geschriebene Code ist nicht für den Betrieb gedacht | Forschung, Softwareentwicklung |
| Microsoft, Implementierungsleitfaden für Dynamics 365 [2] | Partner bauen schon im Vertrieb Proofs of Concept oder Modelle einer Lösung. Weil Demos und Proofs of Concept oft auf begrenzter Kenntnis der Abläufe und auf Demodaten beruhen, soll offengelegt werden, welche Abkürzungen und Annahmen darin stecken | Hersteller, Übergang vom Vertrieb ins Projekt |
| Glossar der Softwareauswahl, find-your-software.de [4] | Ein begrenzter Test, in dem ein Anbieter anhand echter Beispiele nachweist, dass seine Lösung die kritischen Anforderungen erfüllt, bevor eine Entscheidung fällt | Softwareauswahl allgemein |
| ERP-Glossar von Find-Your-ERP | Eine frühe, bewusst einfache Umsetzung, die zeigt, ob ein Vorhaben grundsätzlich machbar ist, etwa eine kritische Anforderung im Zielsystem. Gemeint ist nicht die vollständige Umsetzung | ERP-Auswahl |
Gemeinsam ist allen Fassungen der begrenzte Umfang und der Zweck, vor einer Entscheidung einen Beleg zu liefern. Die Forschung denkt dabei an etwas, das erst gebaut wird. In der ERP-Auswahl existiert das System schon, und geprüft wird, ob es einen bestimmten Punkt im Kontext des Unternehmens trägt. Microsoft beschreibt die Schwachstelle: Vorführungen, die auf begrenzter Kenntnis der Abläufe beruhen, wecken leicht zu hohe Erwartungen [2].
Unser Verständnis
Ein Proof of Concept ist in der ERP-Auswahl ein begrenzter, vorab vereinbarter Nachweis im Zielsystem, ob ein kritischer Punkt mit den Daten und Abläufen des Unternehmens funktioniert. Zu ihm gehören ein schriftliches Ziel, Erfolgskriterien, eine feste Testgrundlage und am Ende eine Entscheidung. Er zeigt die Machbarkeit; die fertige Lösung entsteht erst in der Einführung. Wir setzen ihn nur ein, wenn nach den Prozessworkshops ein Muss-Kriterium offen ist, und bündeln dann alle kritischen Themen in diesem einen Proof of Concept.
Ein Proof of Concept klärt, was Demo, Prozessworkshop und Referenzbesuch offenlassen
Jede Stufe der Feinauswahl beantwortet eine andere Frage. Im Proof of Concept prüft das Unternehmen zum ersten Mal mit eigenen Daten und misst das Ergebnis an Kriterien, die vorher feststanden:
| Form | Wer bestimmt den Inhalt | Daten | Was danach belegt ist | Zeitpunkt |
|---|---|---|---|---|
| Anbieterpräsentation | Das Unternehmen gibt Szenarien vor, der Anbieter führt vor | Demodaten des Anbieters oder Beispieldaten des Unternehmens | dass das System die Szenarien grundsätzlich abbildet | nach der Shortlist, für alle Systeme der Shortlist |
| Prozessworkshop | Key User und Anbieter spielen die eigenen Abläufe im System durch | Abläufe und Beispielfälle des Unternehmens | wo der Standard reicht und was gebaut werden muss | mit höchstens zwei Anbietern, meist einem |
| Referenzbesuch | Ein Kunde des Anbieters zeigt sein System im Betrieb | Daten des Referenzkunden | dass das System bei einem vergleichbaren Unternehmen im Alltag läuft | Feinauswahl, in jedem Projekt empfohlen |
| Proof of Concept | Das Unternehmen legt Punkt, Daten und Erfolgskriterien fest, der Anbieter setzt im Zielsystem um | eigene, meist anonymisierte Daten | ob genau dieser kritische Punkt machbar ist | bei offenem Muss-Kriterium, vor dem Vertrag |
| Pilotbetrieb | Das Projektteam nach dem Einführungsplan | produktive Daten eines Bereichs oder Standorts | dass die eingeführte Lösung im Alltag trägt | in der Einführung, nach dem Vertrag |
Wie Präsentationen vorbereitet und bewertet werden, beschreibt der Beitrag zu Anbieterpräsentationen. Was einen guten Referenzkunden ausmacht, steht im Glossar unter Referenzbesuch.
Prototyp und Pilot werden oft mit dem Proof of Concept gleichgesetzt. Antognolli und Petrillo sehen darin eine Ursache dafür, dass Umfang und erwartetes Ergebnis unklar bleiben [1]. Gabler beschreibt den Prototyp als Modell, das die wesentlichen Funktionen eines erdachten Produkts zeigt, um zu demonstrieren, dass es im Prinzip umsetzbar ist [3]. In der ERP-Auswahl passt ein Prototyp deshalb zu geplanten Erweiterungen, etwa einer eigenen Kalkulationslogik, kaum zum Standard. Ein Pilotbetrieb gehört in die Einführung. Er setzt das gewählte System in einem Bereich oder Standort produktiv ein, bevor der Rollout folgt. Wer ihn in die Auswahl vorzieht, kauft das System, bevor er es geprüft hat.
Ein Proof of Concept lohnt sich nur für Muss-Kriterien, die bisher bloß zugesagt sind
Für einen Proof of Concept bereiten Key User Testdaten auf und arbeiten mit, Berater des Anbieters richten das Szenario im System ein. Der Aufwand lohnt sich, wenn ein offener Punkt ein KO-Kriterium betrifft und der Anbieter ihn bisher nur zugesagt, aber nicht an einem Fall des Unternehmens gezeigt hat. Typische Kandidaten sind:
- Schnittstellen, ohne die der Betrieb steht, etwa EDI mit Großkunden oder die Anbindung von Maschinen
- Mengengerüste, bei denen Laufzeiten zählen, etwa die Disposition über alle Artikel oder die Abrechnung am Monatsende
- Branchenlogik, die im Standard nur teilweise vorhanden ist und über Konfiguration oder eine Partnerlösung kommen soll
- Zusagen, die im Workshop mit „das lösen wir über eine Erweiterung“ beantwortet wurden
Nicht in einen Proof of Concept gehört, was schon belegt ist: Funktionen, die der Anbieter an einem Szenario des Unternehmens gezeigt hat, und Abläufe, die ein Referenzkunde mit ähnlichem Profil im Betrieb nutzt. Bedienung und Oberfläche lassen sich in der Präsentation besser vergleichen, weil dort alle Systeme dieselben Szenarien zeigen. Welche Anforderungen nach den Workshops noch als Lücke gelten, hält die Fit-Gap-Analyse fest. Ist dort kein Muss-Kriterium mehr offen, entfällt der Proof of Concept.
Ziel, Erfolgskriterien und Daten stehen fest, bevor der Anbieter beginnt
Antognolli und Petrillo gliedern einen Proof of Concept in Planung, Durchführung und Entscheidung und legen das Gewicht auf die Planung: Zweck, Voraussetzungen wie verfügbare Daten, messbare Erfolgskriterien und ein Zeitrahmen mit Abbruchregeln stehen fest, bevor die Arbeit beginnt [1]. Für die ERP-Auswahl heißt das:
| Baustein | Was vorab festgelegt wird |
|---|---|
| Ziel | eine Frage zu einem kritischen Punkt, als prüfbare Annahme formuliert |
| Erfolgskriterien | messbar oder eindeutig mit Ja oder Nein prüfbar, schriftlich vereinbart und vom Anbieter bestätigt |
| Testgrundlage | eigene Daten des Unternehmens, anonymisiert, mit Sonder- und Fehlerfällen statt nur dem Normalfall |
| Umfang | nur die kritischen Punkte, im Zielsystem in der angebotenen Version; jede Zusatzentwicklung wird als solche benannt |
| Beteiligte | Key User, die das System selbst bedienen, Berater des Anbieters, bei Bedarf IT und Auswahlberatung |
| Dauer und Aufwand | vorab begrenzt, mit einem Termin für die Bewertung und einer Regel, wann abgebrochen wird |
| Kosten | vorab geklärt, auch wer sie trägt und ob sie bei Auftrag angerechnet werden |
Die Checkliste zur Software-Beschaffung auf find-your-software.de nennt für Tests vor der Entscheidung dieselben Grundregeln: Erfolgskriterien schriftlich, Zeitraum begrenzen, Kosten vorab klären [5].
Das meiste Gewicht tragen die Erfolgskriterien. Fehlen sie, bewertet das Team am Ende einen Eindruck, und der Anbieter wird seine Vorführung für gelungen halten. „Die Disposition läuft schnell“ ist kein Kriterium. „Der Dispositionslauf über alle Artikel ist vor Schichtbeginn fertig“ ist eines.
Im Beispiel entscheidet der Proof of Concept über die Abrufverarbeitung
Ein Hersteller von Kunststoffteilen beliefert Automobilzulieferer. Seine Kunden schicken Lieferabrufe per EDI, die sich mehrmals pro Woche ändern. Nach den Präsentationen ist ein System übrig, und in den Prozessworkshops blieb ein Punkt offen: Der Anbieter sagt zu, dass sein EDI-Baustein die Abrufe übernimmt und Änderungen zum vorherigen Abruf zeigt, konnte das aber nur mit eigenen Beispieldateien vorführen. Die Abrufverarbeitung ist ein Muss-Kriterium. Der Proof of Concept wird so vereinbart:
| Baustein | Im Beispiel |
|---|---|
| Ziel | Das System übernimmt die Lieferabrufe der drei größten Kunden mit dem angebotenen EDI-Baustein, ohne Programmierung |
| Erfolgskriterien | (1) Alle Abrufe eines Monats werden ohne manuelle Erfassung übernommen. (2) Mengen- und Terminänderungen zum vorherigen Abruf sind je Position sichtbar. (3) Die geänderten Mengen stehen danach in der Disposition. (4) Abrufe mit unbekannter Artikelnummer landen in einer Klärungsliste |
| Testgrundlage | Abrufdateien eines Monats von drei Kunden, Artikelstamm der betroffenen Teile, zwei absichtlich fehlerhafte Abrufe |
| Beteiligte | Key User aus Disposition und Vertriebsinnendienst, der Verantwortliche für EDI, Berater des Anbieters, Auswahlberatung |
| Ergebnis | Kriterien 1 bis 3 erfüllt. Kriterium 4 nur mit einem Zusatzbaustein eines Partners, der im Angebot fehlte |
Beispielwerte zur Veranschaulichung.
Der Proof of Concept gilt als bestanden mit Auflage. Der Zusatzbaustein kommt mit Preis und Aufwand ins Angebot, und die vier Kriterien werden Teil der Leistungsbeschreibung. Wäre Kriterium 1 gescheitert, hätte das System die Auswahl verlassen, und es wäre mit dem nächsten System aus den Präsentationen weitergegangen.
Das Ergebnis eines Proof of Concept ist eine Entscheidung
Am Ende wird das Ergebnis Kriterium für Kriterium an der vereinbarten Messlatte geprüft, und daraus folgt einer von drei Ausgängen. Bestanden heißt, dass Lösungsweg und Kriterien in Angebot und Leistungsbeschreibung übergehen; aus der Vorführung wird so eine vertragliche Zusage. Bestanden mit Auflage heißt, dass eine Zusatzleistung mit Aufwand und Preis ins Angebot kommt, bevor verhandelt wird. Nicht bestanden heißt bei einem Muss-Kriterium, dass der Anbieter ausscheidet und die Shortlist wieder geöffnet wird.
Erweist sich eine Zusage aus dem Vertrieb erst nach der Unterschrift als technisch nicht haltbar, bleibt nur noch ein Änderungsantrag oder ein Streit über den Leistungsumfang.
Festgehalten wird auch, wie das Ergebnis zustande kam: was Standard war, was konfiguriert und was eigens entwickelt wurde. Microsoft empfiehlt, bei jeder Vorführung Abkürzungen und Annahmen offenzulegen und schon im Vertrieb getroffene Entscheidungen samt verworfener Vorschläge zu dokumentieren, weil die Beteiligten der frühen Gespräche bei späteren Verhandlungen oft nicht mehr dabei sind [2]. Antognolli und Petrillo beschreiben den Proof of Concept ohne Dokumentation als eigenes Fehlmuster: Die Entscheidung fällt, ihre Begründung geht verloren [1].
Drei Irrtümer machen aus dem Proof of Concept eine teure Vorführung
Ein Proof of Concept ist keine verlängerte Demo
Wählt der Anbieter Szenario und Daten selbst, sieht das Unternehmen, was er zeigen möchte, nur ausführlicher. Für die Präsentation hält das der Glossar-Eintrag zur Anbieterpräsentation fest, und für den Proof of Concept gilt es genauso. Ohne eigene Daten und ohne vorab vereinbarte Kriterien kostet er mehr Zeit als eine Demo und liefert denselben Beleg.
Ein größerer Proof of Concept macht die Entscheidung nicht sicherer
Wer möglichst viele Prozesse in den Proof of Concept packt, beginnt eine kleine Einführung vor dem Vertrag. Sie bindet die Key User lange, und je mehr Arbeit beide Seiten hineingesteckt haben, desto schwerer fällt es, den Anbieter noch auszuschließen. Gemeint ist die Demonstration der Machbarkeit, nicht die vollständige Umsetzung.
Was im Proof of Concept läuft, ist noch nicht vertraglich zugesagt
Für einen Proof of Concept richtet der Anbieter das System oft mit Abkürzungen ein, etwa mit vereinfachten Stammdaten oder eigens geschriebenen Skripten. Der Code eines Proof of Concept ist nach Antognolli und Petrillo nicht für den Betrieb gedacht [1]. Was im Projekt gelten soll, muss deshalb im Angebot stehen, mit der Angabe, ob es Standard, Konfiguration oder Entwicklung ist.
Acht Prüfpunkte machen einen Proof of Concept belastbar
Vor dem Start und bei der Bewertung lässt sich prüfen, ob der Proof of Concept trägt:
| Prüfpunkt | Woran Sie es erkennen |
|---|---|
| Anlass | Der kritische Punkt ist benannt und auf ein Muss-Kriterium zurückgeführt |
| Ziel | Eine prüfbare Annahme steht im Mittelpunkt, keine Liste von Wünschen |
| Kriterien | Schriftlich, messbar oder mit Ja oder Nein prüfbar, vor dem Start vom Anbieter bestätigt |
| Daten | Eigene, anonymisierte Daten mit Sonder- und Fehlerfällen |
| System | Zielsystem in der angebotenen Version; Zusatzentwicklungen sind als solche benannt |
| Bedienung | Key User bedienen das System selbst und sehen nicht nur zu |
| Rahmen | Dauer, Aufwand, Kosten und Abbruchregel stehen vorher fest |
| Ergebnis | Die Bewertung je Kriterium ist protokolliert und geht in Angebot und Leistungsbeschreibung ein |
In unseren Auswahlprojekten formulieren wir Ziel und Erfolgskriterien gemeinsam mit den Key Usern, bevor der Anbieter das Testszenario erhält, und bewerten das Ergebnis mit ihnen Kriterium für Kriterium. Der Anbieter bestätigt die Kriterien vorab schriftlich. So misst das Team am Ende an der vereinbarten Messlatte statt am Eindruck aus der Vorführung.
Häufige Fragen
Wer bezahlt einen Proof of Concept?
Das ist Verhandlungssache und sollte vor dem Start feststehen. Manche Anbieter tragen einen kleinen Proof of Concept als Teil ihres Vertriebsaufwands, andere berechnen ihn, vor allem wenn Partner oder Zusatzentwicklung beteiligt sind. Wird er berechnet, lohnt eine Vereinbarung, dass die Kosten bei Auftrag angerechnet werden. Den eigenen Aufwand, vor allem die Zeit der Key User, trägt das Unternehmen in jedem Fall.
Dürfen echte Daten an den Anbieter gehen?
Geschäftsdaten wie Artikelstamm oder Lieferabrufe ja, wenn eine Geheimhaltungsvereinbarung besteht. Bei personenbezogenen Daten, etwa Ansprechpartnern von Kunden oder Daten von Beschäftigten, wird es aufwendiger: Verarbeitet ein Dienstleister sie im Auftrag des Unternehmens, braucht es einen Vertrag zur Auftragsverarbeitung nach Art. 28 DS-GVO, wie die Datenschutzkonferenz erläutert [6]. Für einen Proof of Concept ist es meist einfacher, solche Daten vorher zu anonymisieren. Im Zweifel entscheidet der Datenschutzbeauftragte.
Kann ein Proof of Concept mit zwei Anbietern laufen?
In der Regel nicht. Meist läuft ein Proof of Concept mit einem Anbieter: dem, der nach den Prozessworkshops vorn liegt, und nur, wenn ein kritischer Punkt offen bleibt. Ein zweiter Proof of Concept parallel verdoppelt den Aufwand der Key User und schiebt die Entscheidung hinaus; in unseren Projekten ist er die Ausnahme.
Reicht ein Testzugang statt eines Proof of Concept?
Für Bedienung und Oberfläche ist ein Testzugang aufschlussreich. Er zeigt aber ein leeres oder mit Demodaten gefülltes System, das niemand für das Unternehmen eingerichtet hat. Den kritischen Punkt mit eigenen Daten prüft er nicht, weil gerade die Einrichtung fehlt, um die es geht.
Weiterlesen
Das Vorgehensmodell in sechs Phasen, mit dem wir Auswahlprojekte führen, von der Ist-Analyse bis zur Vorbereitung der Einführung.
Wie ein gemeinsames Drehbuch und eine Bewertungsmatrix die Demos mehrerer Anbieter vergleichbar machen.
Woran Sie echte Muss-Kriterien erkennen und warum es wenige sein sollten.
Wann eine Erweiterung gerechtfertigt ist, wenn der Proof of Concept eine Lücke zeigt.
Die Kurzdefinition und die verwandten Einträge zu Anbieterpräsentation und Referenzbesuch.
Quellen
[1] Antognolli, B. F.; Petrillo, F. (2026): Proof of Concept as a First-Class Architectural Decision Instrument. Preprint, arXiv:2604.05835, abgerufen am 9. November 2026.
[2] Microsoft: Provide overviews of projects and solutions during projects. Dynamics 365 Implementation Guide, Microsoft Learn, Stand 8. Mai 2025, abgerufen am 9. November 2026.
[3] Gabler Wirtschaftslexikon: Prototyp, Revision vom 13. Juni 2025, abgerufen am 9. November 2026.
[4] find-your-software.de: Glossar der Softwareauswahl, Eintrag Proof of Concept, abgerufen am 9. November 2026.
[5] find-your-software.de: Software-Beschaffung: Ablauf, Rollen und Vertrag, Abschnitt Demo und Bewertung, Stand 30. Oktober 2026, abgerufen am 9. November 2026.
[6] Datenschutzkonferenz: Kurzpapier Nr. 13, Auftragsverarbeitung, Art. 28 DS-GVO. Stand 17. Dezember 2018, abgerufen am 9. November 2026.
Die Herstellerdokumentation belegt allgemeine Prinzipien und ist keine Produktempfehlung.
Dr. Benedict Bender
Co-Founder der Sectorlens GmbH
Besprechen Sie Ihren Proof of Concept mit einem ERP-Berater
Im Gespräch klären Sie, ob Ihr offener Punkt einen Proof of Concept rechtfertigt und wie Sie Erfolgskriterien und Testdaten festlegen, bevor der Anbieter beginnt. 30 Minuten, kostenlos und unverbindlich. Anbieterneutral: Kein Anbieter kann seine Platzierung kaufen oder beeinflussen.
Sie haben eine Frage? Dann schicken Sie uns gern eine Nachricht.