Navision Demo: Business Central richtig testen

Eine Demo ist der beste Weg, ein ERP-System wirklich kennenzulernen. Bei „Navision“ – heute Microsoft Dynamics 365 Business Central – können Sie zwischen einer Selbst-Testversion und einer begleiteten Demo wählen. So holen Sie das Maximum heraus.

Welche Demo-Optionen gibt es?

Für einen ersten Eindruck genügt die Online-Testversion. Vor einer echten Investitionsentscheidung ist jedoch eine begleitete Demo oder ein Proof of Concept mit Ihren eigenen Abläufen deutlich aussagekräftiger.

So bereiten Sie die Demo vor

• Szenarien definieren: Ihre wichtigsten Abläufe vom Angebot bis zur Rechnung, inklusive Sonderfälle.
• Beteiligte einladen: die späteren Anwender aus den Fachbereichen.
• Kriterien festlegen: woran Sie Eignung messen (siehe ERP-Auswahl).
• Fragen vorbereiten: zu Schnittstellen, Anpassung, Kosten und Betrieb.

Worauf Sie in der Demo achten sollten

• Wie gut bildet das System Ihre realen Prozesse im Standard ab?
• Wie viele Anpassungen wären nötig – und was kosten sie?
• Wie intuitiv ist die Bedienung für die täglichen Aufgaben?
• Wie laufen Integrationen zu Shop, Versand oder Warenwirtschaft und Buchhaltung?

Ein Bewertungsbogen für die Demo

Damit aus einer Demo eine fundierte Entscheidung wird, sollte sie nicht dem Zufall überlassen, sondern strukturiert bewertet werden. Bewährt hat sich ein einfacher Bewertungsbogen, in dem die wichtigsten Kriterien vorab festgehalten und während der Vorführung von allen Teilnehmenden bewertet werden. Sinnvolle Kategorien sind etwa die Abdeckung der eigenen Prozesse im Standard, die Bedienbarkeit und Übersichtlichkeit, der erkennbare Anpassungsbedarf, die Qualität der Integrationen sowie der Gesamteindruck von Anbieter und Berater. Wenn mehrere Systeme verglichen werden, sorgt derselbe Bogen für jede Demo für echte Vergleichbarkeit und verhindert, dass der zuletzt gesehene Anbieter allein durch den Erinnerungseffekt bevorzugt wird.

Genauso wichtig wie der Bogen ist die richtige Besetzung des Termins. Laden Sie die späteren Anwender aus den betroffenen Fachbereichen ein, nicht nur die Geschäftsführung oder die IT. Diese Mitarbeitenden erkennen sofort, ob ein Ablauf im Alltag praktikabel ist, und ihre frühe Einbindung erhöht später die Akzeptanz des Systems. Halten Sie offene Fragen und Beobachtungen direkt nach der Demo gemeinsam fest, solange der Eindruck frisch ist.

Typische Fehler bei Demos vermeiden

Ein häufiger Fehler ist es, sich von einer perfekt einstudierten Standard-Präsentation beeindrucken zu lassen, ohne die eigenen Sonderfälle zu prüfen. Ebenso problematisch ist es, nur auf das Aussehen der Oberfläche zu achten und die Tiefe der Funktionen zu übersehen. Auch der Preis sollte nicht isoliert betrachtet, sondern stets im Verhältnis zum tatsächlichen Funktions- und Anpassungsbedarf bewertet werden. Wer diese Fallstricke kennt, holt aus einer Demo deutlich mehr Erkenntnis heraus.

Ein realistisches Drehbuch für die Test-Demo

Eine aussagekräftige Demo folgt keinem vorgefertigten Marketing-Skript, sondern einem Drehbuch aus dem eigenen Alltag. Bewährt hat sich, einen vollständigen Geschäftsvorfall von Anfang bis Ende durchzuspielen: vom Anlegen eines Kunden über die Erstellung eines Angebots, die Umwandlung in einen Auftrag, die Lager- und Versandabwicklung bis zur Rechnung und der zugehörigen Buchung. Bauen Sie bewusst Ihre typischen Sonderfälle ein – etwa Teillieferungen, Rückgaben, Sonderpreise oder eine Fremdwährung. So zeigt sich, ob das System Ihre Realität abbildet oder nur den idealen Standardfall beherrscht.

Notieren Sie während der Vorführung, an welchen Stellen Anpassungen nötig wären und wie viele Klicks und Zwischenschritte ein alltäglicher Vorgang erfordert. Diese Beobachtungen sagen mehr über die spätere Arbeitsbelastung aus als jede Funktionsliste.

Nach der Demo: zur fundierten Entscheidung

Direkt im Anschluss an die Demo sollten die Eindrücke gemeinsam festgehalten werden, solange sie frisch sind. Ein einheitlicher Bewertungsbogen hilft, mehrere Systeme objektiv zu vergleichen, statt sich vom zuletzt gesehenen Anbieter leiten zu lassen. Bewerten Sie nicht nur den Funktionsumfang, sondern auch Bedienbarkeit, Anpassungsbedarf, Integrationen und den Gesamteindruck von Anbieter und Berater. Ergänzend ist für eine wirklich belastbare Entscheidung ein Proof of Concept sinnvoll, bei dem das System mit echten eigenen Daten getestet wird. Diese gründliche Prüfung kostet etwas Zeit, schützt aber vor einer teuren Fehlentscheidung, die ein Unternehmen über Jahre bindet. Hintergründe zur Lösung selbst finden Sie unter Navision ERP.

Checkliste: Fragen an den Anbieter

Eine Demo ist auch die Gelegenheit, dem Anbieter die richtigen Fragen zu stellen – jenseits der reinen Funktionsschau. Hilfreich ist, vorab eine Liste vorzubereiten. Fragen zur Eignung könnten lauten: Wie bilden Sie diesen konkreten Sonderfall ab, und ist das Standard oder Anpassung? Fragen zur Umsetzung: Wie läuft eine typische Einführung ab, wie lange dauert sie, und wer ist auf Ihrer Seite beteiligt? Fragen zu Integration: Welche Schnittstellen zu Shop, Versand oder Buchhaltung sind bereits vorhanden und erprobt?

Ebenso wichtig sind Fragen zu Kosten und Zusammenarbeit: Wie setzt sich der Gesamtpreis zusammen, welche laufenden Gebühren fallen an, und wie ist der Support organisiert? Bitten Sie außerdem um Referenzkunden ähnlicher Größe und Branche, mit denen Sie sprechen können. Die Art, wie ein Anbieter auf kritische Fragen reagiert – offen und konkret oder ausweichend –, sagt viel über die spätere Zusammenarbeit aus. Halten Sie die Antworten schriftlich fest, damit sie in den späteren Vergleich einfließen. Diese vorbereitete, kritische Haltung verwandelt die Demo von einer Verkaufsveranstaltung in ein echtes Auswahlinstrument.

Vom Test zum Proof of Concept

Wenn eine Demo überzeugt hat, ist der nächste konsequente Schritt vor der endgültigen Entscheidung oft ein Proof of Concept. Dabei wird das System nicht mit Beispieldaten, sondern mit einem Ausschnitt der eigenen echten Daten und Prozesse erprobt. So zeigt sich konkret, wie gut die Lösung zur eigenen Realität passt, wo Anpassungen nötig sind und wie aufwendig diese ausfallen. Ein Proof of Concept erfordert etwas Vorbereitung und die Mitwirkung eines Partners, liefert aber eine deutlich belastbarere Grundlage als jede Vorführung. Gerade bei einer langfristigen, teuren Investition wie einem ERP-System rechtfertigt die gewonnene Sicherheit diesen Aufwand. Er verwandelt einen guten ersten Eindruck in eine fundierte Gewissheit und senkt das Risiko einer Fehlentscheidung, die das Unternehmen über Jahre binden würde, erheblich.

Demo, Testsystem oder Proof of Concept?

„Demo“ kann sehr Unterschiedliches bedeuten. Für eine fundierte Entscheidung lohnt es, die Formate zu unterscheiden:

Je näher die Demo an Ihren realen Abläufen ist, desto aussagekräftiger wird sie. Eine reine Hochglanz-Präsentation zeigt selten die Sonderfälle, an denen es im Alltag hakt.

Checkliste: die Demo richtig nutzen

• eigene typische Prozesse und Sonderfälle vorab definieren
• die späteren Anwender einbeziehen
• denselben Beispielfall bei allen Anbietern durchspielen
• Standard-Funktion und nötige Anpassung klar trennen
• Antworten und offene Punkte schriftlich festhalten

Selbst testen oder führen lassen?

Das Testsystem selbst einrichten: CRONUS, Trial und Sandbox in der Praxis

Wer Microsoft Dynamics 365 Business Central – den Nachfolger des klassischen Navision – ernsthaft prüfen möchte, ist nicht zwingend auf einen Implementierungspartner angewiesen, um überhaupt erst einmal ein lauffähiges System vor sich zu haben. Microsoft stellt eine kostenlose Self-Service-Trial bereit, die sich in wenigen Minuten über ein Geschäftskonto anfordern lässt und bereits mit einer vollständig befüllten Demo-Firma ausgeliefert wird. Dieser Abschnitt beschreibt ausschließlich das technische Aufsetzen dieser Test-Umgebung: das Anfordern der Trial, die Rolle der mitgelieferten Demo-Firma CRONUS, das Anlegen von Sandbox-Umgebungen sowie die Fristen, nach denen ein ungenutzter Zugang verfällt. Was Sie anschließend mit eigenen Daten und Szenarien anstellen, wer im Team mittestet und wie Sie mehrere Systeme fair gegeneinander stellen, ist Gegenstand der übrigen Abschnitte dieser Seite – hier geht es allein um die Maschinerie unter der Oberfläche, damit Sie überhaupt einen funktionierenden Sandkasten haben.

Die wichtigste Erkenntnis vorweg, weil sie die gesamte Planung Ihrer Testphase beeinflusst: Solange Sie ausschließlich in der vorinstallierten CRONUS-Demo-Firma arbeiten, läuft der 30-Tage-Trial-Zähler überhaupt nicht. Der Countdown startet erst in dem Moment, in dem Sie eine eigene, produktivnahe Firma anlegen. Das gibt Ihnen einen oft unterschätzten Spielraum, sich zunächst ohne Zeitdruck mit der Bedienlogik vertraut zu machen, bevor die eigentliche Frist zu ticken beginnt. Wer diesen Mechanismus kennt, kann seine Evaluierung erheblich entspannter und systematischer angehen – und vermeidet die typische Hektik, in der die wertvollen 30 Tage bereits beim reinen Herumklicken verbraucht werden.

Die 30-Tage-Trial anfordern: vom leeren Konto zum Zugang

Der Einstieg in die Self-Service-Trial setzt ein Microsoft-365-Geschäftskonto voraus. Eine private Outlook- oder Gmail-Adresse genügt in aller Regel nicht; die Trial ist auf Geschäftsdomänen ausgelegt und prüft die Adresse entsprechend. Verfügt Ihr Unternehmen bereits über einen Microsoft-365-Mandanten, können Sie diesen nutzen und benötigen lediglich ein Konto mit den passenden Berechtigungen. Existiert noch kein Mandant, lässt sich im Anmeldeprozess ein neuer, kostenloser Tenant erzeugen – dann erhalten Sie zwangsläufig eine Adresse mit der Endung onmicrosoft.com, die für reine Testzwecke völlig ausreicht.

Die Anforderung selbst erfolgt entweder über die offizielle Produktseite von Business Central, über den Microsoft AppSource oder direkt aus einem bestehenden Microsoft-365-Portal heraus. Nach Eingabe der Geschäftsadresse und einer kurzen Verifizierung wird im Hintergrund eine Umgebung bereitgestellt. Dieser Provisionierungsschritt dauert in der Praxis einige Minuten; danach landen Sie im sogenannten Rollencenter, der personalisierten Startseite der Anwendung. Bemerkenswert ist, dass Sie zu diesem Zeitpunkt noch keine einzige Zahl eingegeben haben und dennoch ein vollständig konfiguriertes System vor sich sehen – das verdanken Sie der mitgelieferten Demo-Firma.

Wer hier bereits ahnt, dass die Evaluierung zu einer größeren Entscheidung heranwächst, sollte den Trial-Zugang von Anfang an als Teil eines strukturierten Vorgehens begreifen. Eine saubere ERP-Auswahl beginnt nicht mit dem ersten Klick im System, sondern mit klaren Kriterien, gegen die Sie das Gesehene später abgleichen. Das Testsystem ist das Werkzeug, nicht das Ziel.

CRONUS: Was die mitgelieferte Demo-Firma leistet – und was nicht

CRONUS ist der Name der fiktiven Beispielfirma, die Microsoft in jeder Business-Central-Umgebung vorinstalliert. Je nach gewählter Lokalisierung tritt sie unter Bezeichnungen wie CRONUS AG, CRONUS International Ltd. oder einer landesspezifischen Variante auf. Inhaltlich handelt es sich um ein mittelständisch geprägtes Handels- und Fertigungsunternehmen mit einem durchgängig befüllten Datenbestand: Es gibt Debitoren und Kreditoren, einen Artikelstamm mit Lagerbeständen, gebuchte und offene Belege, einen vollständigen Kontenrahmen sowie historische Buchungen, die sämtliche Standardberichte mit plausiblen Werten füllen. Damit können Sie sofort durch Verkaufsaufträge, Einkaufsbestellungen, Lagerbewegungen, Fibu-Buchungen und Auswertungen navigieren, ohne vorher irgendetwas anlegen zu müssen.

Der entscheidende Vorteil von CRONUS ist die folgenlose Spielwiese: Sie können Belege buchen, stornieren, Berichte ausführen und Funktionen ausprobieren, ohne echte Geschäftsdaten zu gefährden und – wie eingangs betont – ohne die Trial-Frist zu starten. CRONUS ist damit der ideale Ort, um die grundlegende Bedienphilosophie kennenzulernen: die Suche über die Lupe, die Navigation über Rollencenter und Menüband, das Zusammenspiel von Listen- und Kartenansichten. Wer mit der Begriffswelt von Navision als ERP-System noch nicht vertraut ist, findet in CRONUS eine vollständige, in sich konsistente Modellwelt, an der sich die Logik gut nachvollziehen lässt.

Genauso wichtig sind aber die Grenzen. CRONUS bildet ein generisches Standardunternehmen ab, nicht Ihre Branche, nicht Ihre Belegflüsse und nicht Ihre Stammdatenqualität. Die Demo-Firma verleitet dazu, Funktionen an idealtypisch sauberen Daten zu beurteilen, die mit der Realität eines gewachsenen Betriebs wenig gemein haben. Eine Software wirkt an aufgeräumten Beispieldaten fast immer überzeugend; ob sie auch Ihre Sonderfälle, Ihre Mengeneinheiten oder Ihre Preislogik trägt, zeigt sich erst an realitätsnahen Daten. Wie Sie über das reine Anklicken der Beispieldaten hinauskommen, behandelt der Abschnitt zu eigenen Testdaten und Praxisszenarien auf dieser Seite.

Sandbox-Umgebungen: gefahrlos experimentieren

Business Central unterscheidet zwischen Produktions- und Sandbox-Umgebungen. Eine Sandbox ist eine isolierte Kopie, die ausdrücklich zum Experimentieren gedacht ist: Änderungen darin haben keinerlei Auswirkung auf eine produktive Umgebung. Für die Evaluierung ist das Gold wert, weil Sie riskante oder destruktive Aktionen ausprobieren können – Massenbuchungen, das Aktivieren von Funktionen, das Zurücksetzen von Einstellungen –, ohne befürchten zu müssen, dass Sie sich Ihren Testbestand unbrauchbar machen. Innerhalb des Verwaltungsbereichs (Admin Center) lassen sich Sandbox-Umgebungen anlegen, kopieren und wieder verwerfen.

In der Praxis empfiehlt es sich, für unterschiedliche Fragestellungen getrennte Sandboxes zu führen: eine, in der CRONUS unangetastet bleibt und als Referenz dient, und eine weitere, in der Sie mutig herumprobieren. Geht etwas schief, verwerfen Sie die experimentelle Umgebung und beginnen von vorn. Diese Trennung schützt Sie vor dem ärgerlichen Effekt, dass Sie nach drei Stunden Testen nicht mehr unterscheiden können, welcher Zustand der ursprüngliche war. Eine Sandbox ist zudem der richtige Ort, um später – etwa mit einem Partner – einzelne Erweiterungen oder Konfigurationen zu prüfen, ohne die Hauptumgebung zu belasten.

Schritt für Schritt zum lauffähigen Testsystem

Die folgende Reihenfolge führt Sie vom völlig leeren Microsoft-Konto bis zu einem System, in dem Sie kontrolliert und fristbewusst testen können. Halten Sie sich an die Abfolge, dann nutzen Sie den fristfreien CRONUS-Spielraum optimal aus, bevor der eigentliche 30-Tage-Countdown beginnt.

Was sich ohne Partner selbst testen lässt

Die Self-Service-Trial deckt einen überraschend großen Funktionsumfang ab. Sie können den kompletten Standard von Business Central erleben: Finanzbuchhaltung, Debitoren- und Kreditorenmanagement, Verkauf und Einkauf, Lager- und Bestandsführung, einfache Produktion sowie das Berichts- und Auswertungswesen. Auch die Integration mit den vertrauten Microsoft-365-Werkzeugen – allen voran Excel und Outlook – lässt sich unmittelbar erproben, ebenso die Bedienung über Webclient und mobile App. Für eine erste Einschätzung, ob die Oberfläche zur Arbeitsweise Ihres Teams passt und ob die Standardprozesse Ihren Abläufen nahekommen, reicht das völlig aus. Auch das Anlegen eigener Stammdaten, das Erfassen realitätsnaher Belege und das Durchspielen typischer Tagesabläufe ist in der Trial möglich, sodass Sie weit über das bloße Betrachten von CRONUS hinauskommen.

Damit eignet sich die Trial hervorragend, um die grundsätzliche Eignung der Lösung für ein ERP im Mittelstand einzuschätzen, ohne dass bereits Beratungskosten entstehen. Sie verschaffen sich ein belastbares Bild davon, ob das System überhaupt in die engere Wahl gehört, bevor Sie Zeit und Budget in ein partnergestütztes Proof of Concept investieren.

Wo die Self-Service-Trial an ihre Grenzen stößt

So weit der Standard trägt, so klar sind die Grenzen einer reinen Self-Service-Trial – und es ist wichtig, diese realistisch einzuordnen, damit Sie aus dem Test nicht die falschen Schlüsse ziehen. Drei Einschränkungen wiegen besonders schwer.

Kein echtes Customizing: Die Trial bildet den Auslieferungsstandard ab. Tiefgreifende Anpassungen, branchenspezifische Erweiterungen aus dem AppSource in produktiver Ausgestaltung oder maßgeschneiderte Entwicklungen, wie sie ein Partner im Rahmen einer ERP-Implementierung umsetzt, sind im Self-Service-Modus nicht abbildbar. Was Sie sehen, ist die Software ab Werk – nicht das System, das Sie nach einem Projekt tatsächlich nutzen würden. Gerade die für den Mittelstand entscheidenden Sonderanforderungen bleiben in der Trial daher unsichtbar.

Keine echte Datenmigration: Die Übernahme Ihrer realen Stamm- und Bewegungsdaten aus einem Altsystem – Artikel, Kunden, offene Posten, Buchungshistorie – ist ein Projektthema und nicht Bestandteil der Trial. Sie können zwar manuell oder über Excel begrenzt Daten einspielen, doch eine saubere, regelbasierte Migration mit Mapping, Validierung und Dublettenbereinigung erfordert Werkzeuge und Erfahrung, die über die Self-Service-Umgebung hinausgehen. Damit fehlt der Trial genau jener Realitätstest, der später über Erfolg oder Scheitern entscheidet.

Eingeschränkte Lokalisierung: Business Central wird in landesspezifischen Versionen ausgeliefert, die etwa Kontenrahmen, Steuerregeln und Meldewesen abdecken. In der Self-Service-Trial ist die Lokalisierung an die gewählte Region gebunden und lässt sich nicht beliebig kombinieren oder um spezielle gesetzliche Anforderungen erweitern. Wer in mehreren Ländern tätig ist oder besondere regulatorische Anforderungen hat, stößt hier an Grenzen, die nur ein Partner mit den passenden Erweiterungen auflösen kann.

Diese Grenzen sind keine Schwäche der Trial, sondern Ausdruck ihres Zwecks: Sie ist ein Werkzeug zur Erst-Einschätzung, nicht der Ersatz für ein Evaluierungsprojekt. Wo die Self-Service-Umgebung endet, beginnt sinnvollerweise die Zusammenarbeit mit einem Partner – Themen, die im Rahmen eines ERP-Consulting aufgegriffen werden, etwa wenn aus dem ersten Eindruck ein belastbarer Eignungsnachweis mit Ihren eigenen Prozessen werden soll.

Trial, CRONUS und Sandbox im Überblick

Empfehlung für das technische Aufsetzen

Gehen Sie das Aufsetzen bewusst in zwei Phasen an. In der ersten Phase nutzen Sie CRONUS und eine Sandbox, um sich ohne Zeitdruck einzuarbeiten – hier läuft keine Frist, und Sie können so lange experimentieren, wie Sie möchten. Erst wenn Sie sich sicher bewegen und ein konkretes Testdrehbuch im Kopf haben, legen Sie in der zweiten Phase Ihre eigene Firma an und stoßen damit bewusst den 30-Tage-Countdown an. So verschwenden Sie keinen Tag der wertvollen Frist mit reiner Orientierung. Dokumentieren Sie außerdem von Beginn an, welche Umgebung welchem Zweck dient, und behalten Sie die 45-Tage-Inaktivitätsgrenze im Blick, damit Ihnen ein zwischenzeitlich pausierter Zugang nicht unbemerkt gelöscht wird.

Damit haben Sie die technische Grundlage geschaffen: ein lauffähiges Testsystem, eine ungefährliche Spielwiese und ein klares Verständnis der Fristen. Wie Sie diese Umgebung nun mit aussagekräftigen eigenen Daten füllen, welche Rollen im Team welche Aufgaben übernehmen und wie Sie mehrere Kandidaten methodisch vergleichen, führen die weiteren Abschnitte dieser Seite aus. Wer das technische Fundament sauber legt, gewinnt für all diese inhaltlichen Schritte die nötige Ruhe – und trifft am Ende eine Entscheidung für die passende ERP-Lösung, die auf eigener Anschauung beruht statt auf einer reinen Verkaufspräsentation.

Eigene Testdaten und Praxisszenarien aufbauen, statt nur Beispieldaten zu klicken

Ein Testsystem allein beweist noch nichts. Sobald die Umgebung steht und die mitgelieferte Beispielfirma einlädt, durch fertige Belege und gefüllte Berichte zu klicken, entsteht schnell ein trügerisches Gefühl von Sicherheit: Alles funktioniert, alles sieht aufgeräumt aus, die Zahlen stimmen. Genau das ist die Falle. Eine Software wirkt an idealtypisch sauberen Demodaten fast immer überzeugend – die spannende Frage ist aber nicht, ob das System mit dem zurechtkommt, was sich der Hersteller ausgedacht hat, sondern ob es mit dem zurechtkommt, was Ihr Betrieb täglich produziert. Dieser Abschnitt behandelt ausschließlich die inhaltliche Vorbereitung des Selbsttests: wie Sie die generische Beispielfirma durch eigene, repräsentative Stamm- und Bewegungsdaten ersetzen, welche End-to-End-Prozesse Sie nachstellen und wie Sie gezielt jene Sonderfälle einbauen, an denen sich die Eignung einer Lösung wirklich entscheidet. Es geht hier nicht um das Drehbuch der geführten Demo durch einen Anbieter – das ist Gegenstand der geführten Präsentation – und auch nicht um das technische Aufsetzen der Umgebung, sondern um die Daten- und Szenariobasis, mit der Sie eigenständig prüfen.

Der Unterschied ist fundamental. In der Beispielfirma bestätigen Sie, dass eine Funktion existiert. Mit eigenen Daten prüfen Sie, ob diese Funktion Ihre Wirklichkeit trägt. Erst wenn ein Auftrag mit Ihren Artikelnummern, Ihren Mengeneinheiten, Ihrer Rabattlogik und Ihren Lieferkonstellationen sauber durchläuft – oder eben nicht –, gewinnt der Test Aussagekraft. Diese Verlagerung vom Anschauen zum Nachstellen ist der eigentliche Hebel einer belastbaren Evaluierung und unterscheidet eine fundierte ERP-Auswahl von einem oberflächlichen Eindruck.

Warum der Happy Path trügt

Als Happy Path bezeichnet man den idealen Ablauf eines Prozesses: Der Kunde bestellt, die Ware ist vorrätig, die Lieferung geht vollständig raus, die Rechnung wird gestellt und fristgerecht bezahlt. Solche Abläufe demonstriert jede Software mühelos, denn sie sind der Normalfall, für den jedes System primär gebaut ist. Wer seinen Test auf den Happy Path beschränkt, erhält darum ein systematisch zu positives Bild – er prüft genau das, was ohnehin kaum je das Problem ist.

Die Wahrheit über ein System liegt in den Abweichungen. Im realen Betrieb storniert ein Kunde nach der Teillieferung, ein Lieferant liefert in einer anderen Mengeneinheit als bestellt, eine Rechnung muss in Fremdwährung gestellt und später mit abweichendem Kurs bezahlt werden, ein Rabatt gilt nur für eine Staffelmenge, ein Artikel ist eine Variante mit eigener Charge, eine Gutschrift korrigiert einen bereits gebuchten Beleg. Diese Fälle sind nicht selten – sie sind der Alltag. Und genau an ihnen zeigt sich, ob ein System flexibel mitgeht oder ob es Sie zu Umwegen, manuellen Korrekturen und Workarounds zwingt, die später im Produktivbetrieb täglich Zeit kosten. Ein Test, der diese Grenzfälle ausspart, verschiebt das böse Erwachen lediglich auf die Zeit nach der Kaufentscheidung.

Bauen Sie Ausnahmen deshalb bewusst und planvoll ein, nicht zufällig. Notieren Sie vorab, welche Sonderfälle in Ihrem Betrieb regelmäßig vorkommen, und behandeln Sie jeden davon als eigenes, zu prüfendes Szenario. Erst die Summe aus Normalabläufen und bewusst gesetzten Grenzfällen ergibt ein realistisches Bild der Eignung.

Drei bis fünf End-to-End-Prozesse auswählen

Der erste Schritt ist nicht das Eingeben von Daten, sondern die Auswahl der richtigen Prozesse. Versuchen Sie nicht, jeden denkbaren Ablauf abzubilden – das überfordert jede Testphase und verzettelt das Team. Konzentrieren Sie sich stattdessen auf drei bis fünf End-to-End-Prozesse, die für Ihren Betrieb charakteristisch und geschäftskritisch sind. End-to-End heißt dabei: vom auslösenden Ereignis bis zum buchhalterischen Abschluss, über alle beteiligten Abteilungen hinweg, nicht nur ein einzelner Funktionsklick.

Typische Kandidaten für ein Handels- oder Fertigungsunternehmen sind die beiden großen Wertschöpfungsketten – Order-to-Cash (von der Kundenanfrage über Angebot, Auftrag, Lieferung und Rechnung bis zum Zahlungseingang) und Purchase-to-Pay (von der Bedarfsmeldung über Bestellung, Wareneingang und Eingangsrechnung bis zur Zahlung). Hinzu kommen je nach Geschäftsmodell ein Fertigungs- oder Montageprozess mit Stücklistenauflösung, ein Retouren- und Reklamationsablauf sowie ein periodischer Abschluss mit den für Sie relevanten Auswertungen. Wählen Sie bewusst die Prozesse, die entweder das größte Volumen tragen oder die heute mit Ihrem Altsystem am meisten Reibung erzeugen – dort liegt der größte Erkenntnisgewinn.

Beschreiben Sie jeden ausgewählten Prozess vorab in wenigen Sätzen als Szenario: Wer löst ihn aus, welche Stationen durchläuft er, welche Belege entstehen, womit ist er abgeschlossen. Diese kurze Drehbuchskizze – nicht zu verwechseln mit dem Vorführskript des Anbieters – ist Ihre Prüfliste. Sie sorgt dafür, dass Sie im System zielgerichtet nachstellen, statt orientierungslos zu klicken, und sie macht die Ergebnisse zwischen mehreren Testern und mehreren Kandidatensystemen überhaupt erst vergleichbar.

Realistische Stamm- und Bewegungsdaten importieren

Stehen die Prozesse fest, brauchen sie eine Datengrundlage. Hier gilt die Faustregel: so realistisch wie nötig, so schlank wie möglich. Sie müssen nicht Ihren gesamten Datenbestand übernehmen – das wäre ein Migrationsprojekt und nicht Aufgabe eines Selbsttests. Es genügt ein repräsentativer Querschnitt, der Ihre Vielfalt abbildet: ein paar Dutzend Artikel statt Tausender, aber bewusst so ausgewählt, dass alle Ihre Besonderheiten vorkommen.

Auf der Ebene der Stammdaten heißt das konkret: Nehmen Sie Artikel mit unterschiedlichen Mengeneinheiten und Umrechnungen, Varianten und Chargen, Artikel mit Mindestbeständen und solche mit langen Wiederbeschaffungszeiten. Bei den Kunden bilden Sie verschiedene Konstellationen ab – Inlandskunden, Auslandskunden mit Fremdwährung und abweichender Steuerlogik, Kunden mit individuellen Preisen und Rabattvereinbarungen, Kunden mit abweichender Liefer- und Rechnungsadresse. Analog bei den Lieferanten. Wer fertigt oder montiert, hinterlegt zudem echte Stücklisten mit mehreren Ebenen, denn an der Stücklistenauflösung und der korrekten Mengen- und Kostenfortschreibung entscheidet sich, ob das System Ihre Produktlogik wirklich abbildet.

Für den Import bieten sich in der Praxis zwei Wege an. Kleinere, sorgfältig ausgewählte Datensätze legen Sie schlicht manuell an – das hat den Nebeneffekt, dass Sie die Pflegemasken und den Erfassungsaufwand gleich mitbeurteilen. Größere Mengen spielen Sie über die in solchen Systemen verbreiteten Tabellen- und Konfigurationspakete ein, etwa per Excel-Vorlage. Achten Sie beim Import nicht nur darauf, dass die Daten ankommen, sondern wie: Werden Pflichtfelder erzwungen, die Sie heute gar nicht führen? Passt die Feldlogik zu Ihren Gepflogenheiten? Schon der Importvorgang selbst liefert wertvolle Hinweise auf den späteren Pflegeaufwand. Eine echte, regelbasierte Datenmigration aus dem Altsystem bleibt davon unberührt – sie ist ein Projektthema und nicht Teil des Selbsttests.

Datenschutz nicht vergessen: Wenn Sie reale Kunden- oder Lieferantendaten in eine Testumgebung übernehmen, handelt es sich um personenbezogene Daten mit allen Pflichten, die daran hängen. Pseudonymisieren oder anonymisieren Sie Namen, Adressen und Kontaktdaten, soweit das für die Aussagekraft des Tests nicht zwingend im Klartext nötig ist. Die Datenstruktur – Mengeneinheiten, Preise, Konditionen, Stücklisten – bleibt dabei realistisch, die Identitäten müssen es nicht sein.

Die vier Ebenen der Testtiefe

Es hilft, sich die Vorbereitung als geschichtetes Modell vorzustellen. Jede Ebene baut auf der darunterliegenden auf, und nur wer alle vier durchdringt, prüft tatsächlich in der Tiefe. Wer auf halber Höhe stehenbleibt, testet entweder leere Hüllen ohne Bewegung oder Bewegungen ohne die Reibung der Realität.

Die unterste Ebene bilden die Stammdaten: Artikel, Kunden, Lieferanten, Stücklisten. Sie sind das Fundament, auf dem alles Weitere ruht. Darüber liegen die Bewegungsdaten – die Belege, die im Tagesgeschäft entstehen und die Sie im Test selbst erzeugen. Die dritte Ebene verknüpft diese Belege zu Prozessketten: Erst die durchgängige Kette vom Auftrag bis zum Zahlungseingang zeigt, ob die Übergänge zwischen den Schritten sauber greifen. Und ganz oben stehen die Ausnahme- und Grenzfälle, die Sie diesen Ketten bewusst aufpfropfen. Genau diese oberste Schicht trennt einen aussagekräftigen Test von einer Vorführung – und sie ist es auch, die überhaupt erst sichtbar macht, ob ein System für den anspruchsvollen Alltag eines Betriebs taugt.

Grenzfälle gezielt einbauen

Mit der Datengrundlage und den definierten Prozessen können Sie nun die entscheidenden Ausnahmen durchspielen. Behandeln Sie jeden Grenzfall als eigenes, dokumentiertes Mini-Szenario mit einer klaren Erwartung – was sollte passieren – und einem festgehaltenen Ergebnis – was tatsächlich passiert. Vier Klassen von Grenzfällen lohnen besondere Aufmerksamkeit, weil sie in nahezu jedem Betrieb vorkommen und Systeme hier deutlich unterschiedlich abschneiden.

Ergänzen Sie diese Liste um die Sonderfälle Ihrer Branche: Seriennummern- und Chargenpflicht, Konsignationslager, Streckengeschäfte, Sammelrechnungen, abweichende Steuersätze oder reverse-charge-Konstellationen im Auslandsgeschäft. Je näher diese Szenarien an Ihrer täglichen Realität liegen, desto klarer trennt der Test geeignete von ungeeigneten Kandidaten. Wer ein System später als zentrales Warenwirtschaftssystem einsetzen will, sollte gerade die mengen- und bestandsnahen Grenzfälle besonders gründlich prüfen, denn hier wirken sich Schwächen unmittelbar auf Lager und Liquidität aus.

Ergebnisse festhalten, statt sie zu erinnern

Ein Test ist nur so viel wert wie seine Dokumentation. Halten Sie zu jedem Szenario fest, ob der Ablauf glatt durchlief, ob ein Workaround nötig war oder ob das System die Anforderung gar nicht abbilden konnte – und mit welchem Aufwand. Vermerken Sie außerdem den subjektiven Eindruck: Wie viele Klicks, wie viele Bildschirmwechsel, wie verständlich die Meldungen? Diese Notizen sind das eigentliche Ergebnis Ihrer inhaltlichen Vorbereitung. Sie verwandeln vage Eindrücke in eine belastbare Grundlage und liefern zugleich die Bausteine, mit denen sich mehrere Kandidaten später sauber gegenüberstellen lassen.

Bewahren Sie die fertig aufbereiteten Testdaten und Szenariobeschreibungen auf. Sie sind nicht nur für die aktuelle Runde nützlich, sondern auch dann, wenn ein Anbieter Sie zu einem partnergestützten Proof of Concept einlädt: Mit Ihren eigenen Daten und Ihren eigenen Grenzfällen treten Sie dort nicht als passives Publikum auf, sondern als Auftraggeber, der genau weiß, was sein Betrieb braucht. So wird aus dem ersten Eindruck eine fundierte Entscheidung für die passende ERP-Lösung – getragen von eigener Anschauung an echten Daten statt von einer geschliffenen Vorführung an fremden Beispielwerten.

Wer mittestet: Rollen, Verantwortlichkeiten und Zeitbudget im Evaluierungsteam

Ob eine Testphase zu einem belastbaren Urteil führt oder zu einem zufälligen Bauchgefühl, entscheidet sich nicht an der Software, sondern an der Frage, wer sie überhaupt anfasst. Ein Testsystem ist schnell aufgesetzt, eigene Daten lassen sich mit etwas Aufwand einspielen – doch wenn am Ende eine einzige Person mehr oder weniger nebenbei durch das System geklickt ist, steht das Ergebnis auf dünnem Eis. Dieser Abschnitt beschreibt deshalb ausschließlich die personelle Organisation der Evaluierung: welche Rollen ein Testteam besetzen sollte, welche Verantwortung jede einzelne trägt, wie Sie die Testaufgaben sinnvoll auf diese Rollen verteilen und wie viel Zeit realistisch einzuplanen ist. Es geht hier bewusst nicht um die inhaltlichen Bewertungskriterien – also nicht darum, welche Fragen Sie an das System stellen oder wie ein Bewertungsbogen aufgebaut ist –, sondern allein um die Aufstellung der Mannschaft, die diese Fragen stellt. Wer das Testsystem aufsetzt und mit eigenen Praxisszenarien füllt, ist Gegenstand anderer Abschnitte dieser Seite; hier nehmen wir an, dass die Umgebung steht, und kümmern uns um die Menschen, die darin arbeiten.

Der Grund, warum die Teamzusammensetzung so schwer wiegt, ist einfach: Eine ERP-Lösung berührt nahezu jeden Bereich eines Unternehmens, von der Auftragserfassung über das Lager und die Buchhaltung bis zur Geschäftsleitung, die am Monatsende verdichtete Zahlen erwartet. Keine einzelne Person überblickt all diese Perspektiven aus eigener täglicher Erfahrung. Wer eine Software allein beurteilt, beurteilt sie zwangsläufig durch die Brille seiner eigenen Aufgaben – und blendet genau die Reibungspunkte aus, die später andere Abteilungen täglich spüren. Eine durchdachte personelle Aufstellung ist damit kein organisatorischer Luxus, sondern die Voraussetzung dafür, dass die Investition in eine spätere ERP-Implementierung auf einem realistischen Bild beruht.

Die fünf Rollen im Evaluierungsteam

Ein vollständiges Testteam besetzt fünf typische Rollen. Diese müssen nicht zwingend fünf verschiedene Personen sein – in kleineren Betrieben vereint eine Person durchaus zwei Rollen –, aber jede Perspektive sollte bewusst vertreten sein und nicht stillschweigend unter den Tisch fallen. Entscheidend ist, dass jede Rolle einen klar umrissenen Blickwinkel einbringt und nicht einfach dieselben Klicks aus einer anderen Stuhlreihe wiederholt.

Key-User aus den Fachabteilungen: der Test an der realen Aufgabe

Die Key-User sind das Herzstück jeder Evaluierung. Es handelt sich um erfahrene Mitarbeiterinnen und Mitarbeiter aus den Abteilungen, die später täglich mit dem System arbeiten werden: die Auftragssachbearbeiterin, der Einkäufer, die Lagerverantwortliche, die Person in der Fakturierung. Ihre Aufgabe im Test ist es nicht, das System abstrakt zu bewerten, sondern ihre realen Arbeitsaufgaben darin durchzuspielen – also den Verkaufsauftrag zu erfassen, den sie auch im Tagesgeschäft erfassen, mit denselben Sonderfällen, Teillieferungen und Preisstaffeln, die sie aus der Praxis kennen. Genau hier zeigt sich, ob eine Funktion, die in der Hochglanz-Demo elegant aussieht, auch dann noch trägt, wenn ein Kunde drei verschiedene Lieferadressen und eine Sammelrechnung verlangt.

Key-User bringen ein Wissen ein, das kein externer Berater und kein Entscheider ersetzen kann: das Wissen um die unzähligen kleinen Ausnahmen, die ein gewachsenes Geschäft ausmachen. Sie merken sofort, wenn ein Vorgang, der heute mit drei Klicks erledigt ist, im neuen System acht Schritte braucht – und sie merken ebenso, wenn umgekehrt eine bisher umständliche Tätigkeit deutlich leichter von der Hand geht. Wichtig ist, dass Sie Key-User auswählen, die ihre Abteilung wirklich kennen und genug Routine haben, um Abweichungen vom Gewohnten einzuordnen, statt jede Ungewohntheit reflexhaft als Mangel zu werten. Ein guter Key-User unterscheidet zwischen "das ist anders" und "das ist schlechter" – diese Unterscheidung ist Gold wert.

Prozessverantwortliche: der Blick auf die Ablauflogik

Während der Key-User die einzelne Aufgabe testet, beurteilt der Prozessverantwortliche das Zusammenspiel über Abteilungsgrenzen hinweg. Seine Frage lautet nicht "Funktioniert dieser eine Schritt?", sondern "Greift die Kette sauber ineinander?" – also: Löst der gebuchte Wareneingang automatisch die richtige Bestandsfortschreibung aus? Erscheint der erfasste Auftrag verlustfrei in der Faktura? Passt der Beleg- und Statusfluss zu der Art, wie das Unternehmen seine Abläufe tatsächlich organisiert? Diese Rolle übernimmt häufig jemand aus der Organisations- oder Prozessverantwortung, ein Abteilungsleiter mit Querschnittsblick oder ein interner Projektkoordinator.

Der Prozessverantwortliche achtet auf Bruchstellen, die einzelnen Key-Usern entgehen, weil sie jeweils nur ihren Ausschnitt sehen. Genau an den Übergaben zwischen Abteilungen entstehen erfahrungsgemäß die größten Reibungsverluste – etwa wenn der Vertrieb Daten erfasst, die das Lager in anderer Form braucht, oder wenn die Buchhaltung Informationen vermisst, die weiter vorne im Prozess hätten gesetzt werden müssen. Diese Rolle prüft auch, ob sich die Ablauflogik des Systems mit vertretbarem Aufwand an die eigenen Prozesse anpassen lässt oder ob das Unternehmen seine Prozesse umgekehrt an das System anpassen müsste – eine Frage, die für die spätere Auswahl der passenden ERP-Lösung oft schwerer wiegt als jede Einzelfunktion.

IT und Administration: Integration, Sicherheit und Betrieb

Die IT-Rolle betrachtet das System aus einer völlig anderen Höhe als die Fachseite. Sie fragt nicht, wie sich ein Auftrag erfasst, sondern wie sich das System in die bestehende Landschaft einfügt: Welche Schnittstellen zu vorhandenen Werkzeugen gibt es – zum E-Mail-System, zur Office-Welt, zu einem Webshop, zu einem Versanddienstleister? Wie funktioniert die Benutzer- und Rechteverwaltung, und lässt sich das Berechtigungskonzept so feingranular einstellen, dass jede Rolle nur das sieht, was sie sehen darf? Wie steht es um Datenschutz, Datensicherheit, Protokollierung und die Frage, wo die Daten überhaupt liegen? Bei einer Cloud-Lösung wie dem heutigen Business Central verschieben sich diese Fragen teilweise zum Anbieter, verschwinden aber nicht – die Verantwortung für Konfiguration, Zugriffe und Integration bleibt im Haus.

Die IT prüft im Test auch den administrativen Unterbau, den Fachanwender nie zu Gesicht bekommen: das Anlegen und Sperren von Benutzern, das Einspielen von Updates, die Möglichkeiten zum Export und zur Sicherung von Daten, die Anbindung per Schnittstelle. Diese Rolle ist entscheidend, weil ein System, das fachlich überzeugt, aber technisch schlecht in die Umgebung passt, im Betrieb zur Dauerbaustelle wird. Gerade beim Schritt von einem klassischen Warenwirtschaftssystem hin zu einer integrierten ERP-Plattform entscheidet die technische Anschlussfähigkeit oft darüber, ob die erhofften Effizienzgewinne tatsächlich eintreten oder an Medienbrüchen verpuffen.

Geschäftsführung und Entscheider: die verdichtete Sicht

Die Geschäftsleitung testet nicht im operativen Sinn – sie soll und kann nicht jeden Beleg selbst buchen. Ihre Rolle ist eine andere: Sie betrachtet das System aus der Vogelperspektive und fragt, ob es die Steuerungsinformationen liefert, die für Entscheidungen gebraucht werden. Lassen sich aussagekräftige Auswertungen, Dashboards und Kennzahlen erzeugen? Gibt das System einen verlässlichen, aktuellen Blick auf Umsatz, Bestand, offene Posten und Auftragslage? Und passt die Lösung in die strategische und finanzielle Gesamtplanung des Unternehmens?

Damit die Entscheider eine fundierte Meinung bilden können, brauchen sie keine Rohdaten, sondern eine Verdichtung: eine kompakte Zusammenfassung der Testergebnisse aus den übrigen Rollen, ergänzt um eigene Eindrücke aus den Auswertungs- und Berichtsfunktionen. Es ist eine zentrale Aufgabe der Projektleitung, diese Verdichtung zu liefern, statt die Geschäftsführung mit dem Detailprotokoll der Fachseite zu überfordern. Der Zeitbedarf dieser Rolle ist gering, ihr Gewicht in der Entscheidung jedoch hoch – weshalb es lohnt, die Präsentation der Ergebnisse sorgfältig vorzubereiten. Eine strukturierte ERP-Auswahl lebt davon, dass die Entscheidungsebene auf einer sauberen Aufbereitung aufsetzt und nicht auf dem Eindruck einer einzelnen Vorführung.

Projektleitung: die Klammer um das Team

Die fünfte Rolle hält das Ganze zusammen. Die Projektleitung testet selbst kaum, sondern organisiert: Sie verteilt die Testaufgaben auf die Rollen, legt den Zeitrahmen fest, sammelt die Rückmeldungen ein, moderiert Widersprüche und sorgt dafür, dass am Ende ein konsolidiertes Bild entsteht statt fünf unverbundener Einzelmeinungen. Diese Rolle ist auch dafür verantwortlich, dass kein wichtiger Blickwinkel fehlt und dass nicht eine dominante Stimme – sei es die der lautesten Fachabteilung oder die des technikbegeisterten IT-Kollegen – das Urteil einseitig prägt.

Gerade in kleineren Unternehmen wird diese Rolle gern unterschätzt oder ganz weggelassen, mit der Folge, dass die Evaluierung im Sande verläuft oder zur Privatangelegenheit eines Einzelnen wird. Eine benannte Projektleitung – auch wenn es dieselbe Person ist, die einen Prozessbereich verantwortet – stellt sicher, dass der Test einen Anfang, eine Struktur und einen dokumentierten Abschluss hat. Sie ist die Brücke zwischen der operativen Testarbeit und der Entscheidungsebene.

Rollen, Aufgaben und Zeitbudget im Überblick

Die folgende Tabelle fasst zusammen, was jede Rolle testet, worauf sie dabei besonders achtet und welcher Zeitaufwand realistisch einzuplanen ist. Die Zeitangaben verstehen sich als Orientierung für eine kompakte, fokussierte Evaluierung; sie skalieren mit der Größe des Unternehmens und der Zahl der zu prüfenden Prozesse.

Testaufgaben rollengerecht verteilen

Die Kunst der Aufgabenverteilung besteht darin, jeder Rolle genau die Aufgaben zu geben, die zu ihrem Blickwinkel passen – und nicht jeder Person dieselbe generische Aufgabenliste vorzulegen. Ein Key-User soll seinen eigenen Arbeitsalltag nachstellen, nicht abstrakt "das Lagermodul bewerten". Geben Sie ihm konkrete, an die Realität angelehnte Aufträge: "Erfassen Sie einen Auftrag für Kunde X mit Teillieferung und Sonderkondition" wirkt ungleich mehr als die vage Aufforderung, "mal das Verkaufsmodul anzuschauen". Der Prozessverantwortliche erhält umgekehrt durchgängige Szenarien, die mehrere Abteilungen durchlaufen, damit er die Übergaben beurteilen kann. Die IT bekommt technische Prüfpunkte, die Geschäftsleitung am Ende eine verdichtete Sicht.

Bewährt hat sich, die Aufgaben schriftlich und vorab zu verteilen, sodass jede Rolle weiß, was von ihr erwartet wird und worauf sie achten soll. Das verhindert, dass alle dasselbe testen und ganze Bereiche ungeprüft bleiben. Es lohnt sich zudem, bewusst Überlappungen einzubauen: Lassen Sie einen besonders kritischen Prozess von zwei verschiedenen Key-Usern testen. Decken sich deren Urteile, gewinnt das Ergebnis an Verlässlichkeit; weichen sie ab, haben Sie einen wertvollen Hinweis auf einen Punkt, der genauer betrachtet werden muss. Diese Verteilungslogik gilt unabhängig davon, ob Sie ein schlankes Warenwirtschaftsprogramm oder eine breit integrierte ERP-Suite prüfen – sie skaliert lediglich mit der Zahl der betroffenen Bereiche.

Wie viel Zeit realistisch einzuplanen ist

Der häufigste Planungsfehler besteht darin, das Testen "nebenbei" laufen zu lassen. Wer Key-Usern aufträgt, das System zusätzlich zum vollen Tagesgeschäft zu prüfen, erntet flüchtige, oberflächliche Rückmeldungen – weil die produktive Arbeit immer Vorrang hat. Eine ernsthafte Evaluierung braucht reservierte, geschützte Zeitfenster, in denen die beteiligten Personen vom Tagesgeschäft entlastet sind. Das muss nicht am Stück geschehen: Mehrere halbe Tage, verteilt über zwei bis drei Wochen, sind oft wirksamer als ein einzelner Marathontag, weil dazwischen Eindrücke reifen und Rückfragen entstehen.

Als grobe Orientierung gilt: Key-User benötigen den größten Anteil – realistisch mehrere halbe Tage je Fachbereich, denn sie tragen die eigentliche Prüfarbeit. Prozessverantwortliche und IT kommen mit ein bis zwei fokussierten Tagen aus, jeweils mit klarem Schwerpunkt. Die Geschäftsführung braucht nur wenige Stunden für die verdichtete Ergebnissicht. Die Projektleitung schließlich ist nicht in Tagen messbar, sondern begleitet die gesamte Phase steuernd. Wichtig ist, diese Zeiten vorab mit den Vorgesetzten der Beteiligten abzustimmen, damit die Freistellung tatsächlich erfolgt und nicht zur leeren Zusage wird. Die genauen Kosten, die Dauer und die Risiken der gesamten Testphase behandelt ein eigener Abschnitt dieser Seite – hier geht es allein um die Verteilung des personellen Aufwands auf die Rollen.

Wie Sie ein einseitiges Urteil verhindern

Die größte Gefahr einer Evaluierung ist, dass am Ende eine einzige, womöglich voreingenommene Stimme den Ausschlag gibt. Das passiert leicht: Eine technikaffine Person ist begeistert von einer eleganten Funktion und übersieht, dass die Fachabteilung damit nicht zurechtkommt – oder umgekehrt lehnt ein einzelner Skeptiker das System wegen einer Gewohnheitsumstellung ab, die objektiv kein Problem darstellt. Beide Fälle führen zu einer Fehlentscheidung mit langfristigen Folgen.

Mehrere Vorkehrungen wirken dem entgegen. Erstens die bewusste Mehrstimmigkeit: Jede betroffene Abteilung sollte mit mindestens einem Key-User vertreten sein, sodass keine Perspektive fehlt. Zweitens die strukturierte Rückmeldung: Wenn jede Rolle ihre Eindrücke getrennt und nachvollziehbar festhält, lassen sich Einzelmeinung und breiter Konsens später unterscheiden. Drittens die moderierte Konsolidierung durch die Projektleitung, die abweichende Urteile nicht einfach mittelt, sondern hinterfragt: Beruht die schlechte Bewertung auf einem echten Mangel oder auf mangelnder Einarbeitung? Viertens die erwähnte Doppelprüfung kritischer Prozesse durch zwei Personen.

Wenn die personelle Organisation steht – die Rollen besetzt, die Aufgaben verteilt, die Zeitfenster reserviert und die Vorkehrungen gegen Einseitigkeit getroffen sind –, dann verfügen Sie über das, was eine reine Produktdemo niemals liefern kann: ein Urteil, das von den Menschen getragen wird, die später täglich mit dem System arbeiten. Wie Sie die so gewonnenen Eindrücke methodisch gegen konkurrierende Systeme abwägen und in eine saubere Auswahlentscheidung überführen, führen die weiteren Abschnitte dieser Seite sowie die übergeordnete Darstellung zur ERP-Auswahl aus. Die Mannschaft, die Sie hier aufgestellt haben, ist das Fundament, auf dem all diese Schritte aufbauen.

Mehrere Systeme fair gegeneinander testen: das vergleichende Testdesign

Die meisten Evaluierungen scheitern nicht daran, dass ein einzelnes System schlecht getestet wird, sondern daran, dass mehrere Systeme nicht vergleichbar getestet werden. Wer Business Central an einem Dienstagnachmittag mit eigenen Daten ausprobiert, eine Alternative zwei Wochen später in einer halbstündigen Anbieterpräsentation sieht und ein drittes Produkt nur aus einer älteren Erinnerung kennt, hat am Ende drei völlig unterschiedliche Eindrücke gesammelt – aber keinen Vergleich. Genau hier setzt dieser Abschnitt an: Es geht nicht darum, ob Sie testen, und auch nicht darum, mit welchen Kriterien Sie ein einzelnes System bewerten. Es geht um den Versuchsaufbau über mehrere Demos und Testläufe hinweg – also um die Disziplin, die dafür sorgt, dass am Ende tatsächlich Äpfel mit Äpfeln verglichen werden und nicht das Verkaufstalent des einen Anbieters gegen die nüchterne Sachlichkeit des anderen.

Wir setzen dabei voraus, dass die Testumgebung steht, dass eigene Praxisszenarien aufgebaut sind und dass das Evaluierungsteam mit klaren Rollen besetzt ist – all das behandeln die übrigen Abschnitte dieser Seite. Ebenso bewusst lassen wir die eigentliche Bewertungsmethodik außen vor: Wie eine Nutzwertanalyse mit Gewichtungen und Punktwerten formal aufgebaut wird, gehört in den übergeordneten Kontext der ERP-Auswahl, und ein fertiger Bewertungsbogen liegt bereits vor. Der Fokus liegt hier ausschließlich auf einer Frage: Wie organisieren Sie den Vergleich selbst so, dass die Zahlen, die am Ende im Bewertungsbogen stehen, überhaupt miteinander vergleichbar sind?

Warum unkontrollierte Tests systematisch in die Irre führen

Ein Vergleich ist immer nur so belastbar wie die Gleichheit der Bedingungen, unter denen er zustande kommt. In der empirischen Forschung ist das eine Selbstverständlichkeit – man verändert genau eine Variable und hält alle anderen konstant. Bei der Softwareauswahl wird dieses Prinzip routinemäßig verletzt, meist ohne dass es jemandem auffällt. Das System, das zuletzt vorgeführt wurde, wirkt frischer. Das System, dessen Vertriebsmitarbeiter besonders sympathisch war, bekommt unbewusst Bonuspunkte. Das System, bei dem man zufällig ein einfacheres Beispiel durchgeklickt hat, erscheint bedienfreundlicher. Keiner dieser Effekte hat das Geringste mit der Eignung der Software für Ihr Unternehmen zu tun – und doch prägen sie das Urteil oft stärker als jedes Sachargument.

Drei Verzerrungsquellen sind besonders häufig und besonders tückisch. Erstens die ungleichen Testfälle: Wenn Sie in System A einen komplizierten Auftrag mit drei Teillieferungen durchspielen, in System B aber nur eine simple Bestellung erfassen, vergleichen Sie nicht zwei Systeme, sondern zwei verschiedene Aufgaben. Zweitens die verschobene Bewertungsskala: Am ersten Testtag sind Sie streng, weil alles neu und ungewohnt ist; am dritten Tag haben Sie sich an die Bedienlogik gewöhnt und vergeben großzügiger – das später getestete System profitiert allein von Ihrer eigenen Lernkurve. Drittens der Anbietereffekt: Eine professionell moderierte Demo mit aufbereiteten Beispieldaten läuft fast zwangsläufig runder als ein Selbsttest, bei dem Sie sich durch eine Sandbox tasten. Wer diese drei Quellen nicht aktiv kontrolliert, misst am Ende vor allem die Tagesform, die Reihenfolge und die Präsentationskunst – nicht die Software.

Identische Testfälle und identische Datensätze für jedes System

Das Herzstück eines fairen Vergleichs ist ein fester, im Voraus festgelegter Satz von Testfällen, der für jedes System unverändert durchgespielt wird. Diese Testfälle sollten Sie einmal sauber formulieren – als konkrete, an Ihrem Geschäft orientierte Aufgaben – und dann wie ein Prüfprotokoll behandeln, von dem nicht abgewichen wird. Wenn Sie in einem System den Auftrag für Kunde Müller mit Teillieferung, Sonderkondition und Sammelrechnung erfassen, dann erfassen Sie in jedem anderen System exakt denselben Auftrag für denselben Kunden mit denselben Bedingungen. Nur so wird sichtbar, welches System diese eine, immer gleiche Aufgabe leichter, schneller oder vollständiger erledigt.

Genauso wichtig wie identische Aufgaben sind identische Daten. Ein realistischer Vergleich verlangt, dass in allen Systemen derselbe Stammdatenbestand liegt – dieselben Kunden, Artikel, Lieferanten und Preisstaffeln. Es liegt nahe, dies an die eigenen Praxisszenarien zu koppeln, die ohnehin für den Test aufgebaut werden; entscheidend ist hier nur, dass dieser Datensatz für alle Kandidaten identisch ist und nicht je System variiert. Sonst entsteht der klassische Trugschluss: System A wirkt übersichtlicher, weil Sie dort nur fünfzig Artikel angelegt haben, während System B mit zweihundert Artikeln getestet wurde und allein deshalb voller und unübersichtlicher erscheint. Ein gemeinsamer Referenzdatensatz schließt diese Fehlerquelle aus. Halten Sie die Testfälle und den zugehörigen Datenumfang schriftlich fest, bevor der erste Test beginnt – dieses Protokoll ist die Garantie dafür, dass Sie später nicht heimlich die Messlatte verschieben.

Ein praktischer Hinweis für den Vergleich von Business Central mit Alternativen: Manche Funktionen heißen in verschiedenen Systemen unterschiedlich oder sind anders verortet. Es ist Aufgabe der Vorbereitung, die Testfälle so zu formulieren, dass sie das fachliche Ziel beschreiben ("Erstellen Sie aus dem Auftrag eine Teillieferung und anschließend eine Sammelrechnung") und nicht den systemspezifischen Klickweg. So bleibt der Testfall für jeden Kandidaten fair, auch wenn die Wege zum Ziel unterschiedlich aussehen. Wie tief Sie dabei in einzelne Module gehen, hängt von Ihrem Schwerpunkt ab – ob Sie eine vollintegrierte ERP-Lösung oder primär die Fähigkeiten im Bereich ERP-Warenwirtschaft vergleichen.

Eine gemeinsame Bewertungsskala statt wandernder Maßstäbe

Selbst wenn alle Systeme dieselben Aufgaben mit denselben Daten durchlaufen, entsteht noch kein fairer Vergleich, solange jeder Tester seinen eigenen, sich verschiebenden Maßstab anlegt. Eine gemeinsame Bewertungsskala bedeutet zweierlei. Zum einen: dieselbe Anzahl an Stufen und dieselbe Bedeutung jeder Stufe für alle Systeme – ob Sie mit einer Skala von eins bis fünf oder mit Schulnoten arbeiten, ist zweitrangig, solange der Maßstab für jeden Kandidaten identisch ist. Zum anderen, und das wird oft unterschätzt: ein gemeinsames Verständnis davon, was eine bestimmte Note bedeutet. Eine "vier" sollte für jeden Tester und bei jedem System dasselbe heißen, etwa "die Aufgabe ist lösbar, aber umständlich". Ohne diese Verankerung verkommt die Skala zu einem Stimmungsbarometer.

Hier hilft eine kurze gemeinsame Eichung vor dem eigentlichen Test: Das Team einigt sich an einem Beispiel darauf, was die Endpunkte und die mittleren Stufen der Skala konkret bedeuten. Diese gemeinsame Eichung ist die unscheinbare, aber wirksamste Maßnahme gegen wandernde Maßstäbe. Sie verhindert, dass ein nachsichtiger Tester durchgängig großzügiger bewertet als ein strenger Kollege – ein Effekt, der sonst genau das System bevorzugt, das dem milderen Tester zugelost wurde. Die methodische Ausgestaltung der Skala selbst, ihre Gewichtung und die Verrechnung zu einem Gesamtwert sind Gegenstand der Nutzwertanalyse, die im Rahmen der übergeordneten ERP-Auswahl beschrieben ist; hier zählt allein, dass alle Systeme an demselben Maßstab gemessen werden.

Dieselben Tester, dieselbe Perspektive

Ein Vergleich verliert seine Aussagekraft, wenn ein System von der IT-Abteilung, ein anderes von einem Fachanwender und ein drittes nur vom Projektleiter beurteilt wird. Unterschiedliche Menschen achten auf unterschiedliche Dinge, und schon der Wechsel der bewertenden Person führt eine Verzerrung ein, die mit der Software nichts zu tun hat. Die Regel lautet deshalb: Dieselbe Rolle beurteilt bei allen Systemen denselben Aspekt. Wenn die Auftragssachbearbeiterin den Verkaufsprozess in System A testet, dann testet genau sie ihn auch in System B und C. Wenn die IT die Schnittstellenfähigkeit beurteilt, tut sie das für alle Kandidaten.

Das bedeutet nicht, dass alle alles testen müssen – die Aufgabenverteilung auf die Rollen ist Sache der personellen Organisation und in einem eigenen Abschnitt beschrieben. Es bedeutet lediglich, dass die Zuordnung von Tester zu Testaufgabe über alle Systeme hinweg konstant bleibt. So stellen Sie sicher, dass Unterschiede in den Bewertungen tatsächlich auf die Systeme zurückgehen und nicht auf den Wechsel des Beobachters. Bewährt hat sich, kritische Prozesse von zwei Personen unabhängig bewerten zu lassen und das ebenfalls bei jedem System gleich zu handhaben – decken sich die Urteile, gewinnt der Vergleich an Stabilität; weichen sie ab, haben Sie einen Hinweis auf einen genauer zu betrachtenden Punkt.

Reihenfolge-Effekte erkennen und neutralisieren

Die Reihenfolge, in der Systeme getestet werden, beeinflusst das Urteil stärker, als den meisten bewusst ist. Das zuerst getestete System setzt den Maßstab, an dem alles Weitere unbewusst gemessen wird – ein Anker, von dem man sich kaum löst. Das zuletzt getestete System bleibt am frischesten in Erinnerung und profitiert davon, dass die Tester inzwischen geübter sind und die Aufgaben routinierter lösen. Wer drei Systeme nacheinander prüft, vergleicht also nicht nur drei Produkte, sondern auch drei verschiedene Reifegrade der eigenen Vertrautheit mit der Aufgabe.

Vollständig ausschalten lässt sich dieser Effekt nicht, aber abmildern. Eine Möglichkeit ist die Rotation: Lassen unterschiedliche Tester die Systeme in unterschiedlicher Reihenfolge durchlaufen, sodass kein Kandidat systematisch immer den begehrten letzten Platz oder den undankbaren ersten besetzt. Eine zweite Maßnahme ist eine bewusste Aufwärmphase vor jedem System: Bevor die eigentliche Bewertung beginnt, machen sich die Tester kurz mit der grundlegenden Bedienung vertraut, sodass die Lernkurve weitgehend vor der Wertung liegt und nicht während ihrer. Drittens hilft eine zeitliche Nähe der Tests – mehrere Systeme innerhalb einer überschaubaren Spanne zu prüfen, vermeidet, dass das zuerst getestete System nur deshalb schlechter abschneidet, weil seine Eindrücke schon verblasst sind. Und viertens sollten Sie Reihenfolge-Effekte zumindest dokumentieren: Wer wann welches System getestet hat, gehört ins Protokoll, damit Sie bei knappen Ergebnissen einschätzen können, ob die Reihenfolge eine Rolle gespielt haben könnte.

Ergebnisse normalisieren und gewichten

Auch bei sorgfältigem Aufbau bleiben Rohwerte selten unmittelbar vergleichbar. Hat ein strenger Tester durchgängig niedrigere Punkte vergeben als ein milder, verzerrt das den Vergleich, sobald beide unterschiedliche Systeme beurteilt haben. Normalisierung bedeutet, solche systematischen Niveauunterschiede herauszurechnen, bevor die Werte zusammengeführt werden – etwa indem man die Bewertungen je Tester auf ein gemeinsames Niveau bezieht, statt absolute Punktstände naiv zu addieren. So zählt, wie ein Tester die Systeme relativ zueinander eingestuft hat, und nicht, ob er generell zu Strenge oder Milde neigt. Der Aufwand dafür ist gering, der Gewinn an Fairness erheblich, sobald mehrere Personen mehrere Systeme bewerten.

Von der Normalisierung zu unterscheiden ist die Gewichtung. Nicht jeder Testbereich ist für Ihr Unternehmen gleich wichtig: Wer den Schwerpunkt im Lager und in der Logistik hat, gewichtet die entsprechenden Testfälle höher als etwa die Anlagenbuchhaltung. Wichtig ist nur, dass die Gewichte vor dem Test festgelegt werden und für alle Systeme identisch gelten – sonst besteht die Versuchung, die Gewichte im Nachhinein so zu drehen, dass der heimliche Favorit gewinnt. Die formale Mechanik dieser Gewichtung – wie aus Gewichten und normalisierten Werten ein Gesamtergebnis entsteht – ist Teil der Nutzwertanalyse-Methodik und auf der Seite zur ERP-Auswahl ausgeführt. Für das vergleichende Testdesign genügt der Grundsatz: erst normalisieren, dann mit unveränderlichen Gewichten verrechnen.

Eine letzte, oft unterschätzte Maßnahme schützt vor dem mächtigsten Störfaktor überhaupt – der Sympathie für einen Anbieter und der Überzeugungskraft seiner Verkäufer. Trennen Sie die Bewertung der Software sauber von der Bewertung des Anbieters. Beides ist wichtig, aber beides gehört in getrennte Spalten: Wie gut die Aufgaben im System gelingen, ist eine Frage; wie kompetent, sympathisch oder verkaufsstark der Anbieter auftritt, eine völlig andere. Werden beide Eindrücke vermischt, färbt das Charisma des Vertriebs unbemerkt auf die Bewertung der Funktionen ab. Halten Sie die Tester außerdem dazu an, ihre Wertung während oder unmittelbar nach dem eigenen Durchspielen der Testfälle abzugeben – nicht erst nach einer eindrucksvollen Abschlusspräsentation, deren Glanz die nüchterne Erinnerung an die eigenen Klickwege überstrahlt.

Vom kontrollierten Vergleich zur Entscheidung

Ein vergleichendes Testdesign verlangt mehr Vorbereitung als das schnelle Ausprobieren einzelner Systeme – doch genau diese Disziplin ist der Unterschied zwischen einer Entscheidung, die einer kritischen Nachfrage standhält, und einem Bauchgefühl, das sich im Nachhinein nicht mehr begründen lässt. Wenn Sie identische Testfälle auf einem gemeinsamen Datensatz mit denselben Testern, einer geeichten Skala und kontrollierter Reihenfolge durchspielen und die Ergebnisse anschließend sauber normalisieren und mit vorab festgelegten Gewichten verrechnen, erhalten Sie etwas, das aus bloßen Eindrücken nie entsteht: einen belastbaren, nachvollziehbaren Vergleich, der die Software vom Verkaufstalent trennt.

Damit ist der Versuchsaufbau abgeschlossen, nicht aber die Entscheidung. Wie aus den vergleichbaren Werten eine begründete Rangfolge und schließlich die Wahl des passenden Systems wird, führen die Bewertungsmethodik und die übergeordnete Darstellung zur ERP-Auswahl aus. Das vergleichende Testdesign liefert das saubere Datenmaterial; die Auswahlmethodik formt daraus das Urteil. Wer beide Schritte trennt und jeden für sich sorgfältig ausführt, vergleicht am Ende tatsächlich Äpfel mit Äpfeln – und entscheidet auf einer Grundlage, die auch in einem Jahr noch trägt.

Was die Testphase kostet, dauert und an Risiken birgt

Eine Testphase fühlt sich auf den ersten Blick kostenlos an. Das Trial-System ist umsonst oder für wenige Wochen freigeschaltet, die CRONUS-Demo kostet keinen Cent, und niemand schreibt eine Rechnung dafür, dass jemand ein paar Aufträge probehalber erfasst. Genau diese scheinbare Kostenfreiheit ist der gefährlichste Trugschluss der gesamten Evaluierung. Denn die teuerste Ressource in einem Unternehmen ist nicht die Software-Lizenz, sondern die Arbeitszeit erfahrener Mitarbeiterinnen und Mitarbeiter – und genau diese bindet eine ernsthafte Testphase in erheblichem Umfang. Dieser Abschnitt betrachtet deshalb ausschließlich die wirtschaftliche und zeitliche Dimension des Testens selbst: Welche Kosten entstehen tatsächlich, auch wenn keine Rechnung sichtbar wird? Wie lange darf eine Testphase dauern, bevor sie sich gegen ihr eigenes Ziel wendet? Und welche Risiken lauern, die eine an sich sinnvolle Evaluierung in eine teure Endlosschleife verwandeln? Es geht hier bewusst nicht um die Entscheidung, die nach dem Test ansteht – also nicht darum, wie Sie das Ergebnis bewerten und welches System Sie wählen –, sondern allein um die Steuerung der Wirtschaftlichkeit und der Risiken während der Test- und Evaluierungsphase. Wie Sie das Testsystem einrichten, wer mittestet und wie ein vergleichendes Testdesign aussieht, behandeln eigene Abschnitte dieser Seite; hier nehmen wir an, dass diese Fragen geklärt sind, und richten den Blick auf das Budget und die Fallstricke.

Der unsichtbare Kostenblock: interner Personalaufwand

Der mit Abstand größte Kostenblock einer Testphase ist der interne Personalaufwand – und er ist gerade deshalb so tückisch, weil er nirgends als Ausgabe gebucht wird. Wenn eine Key-Userin aus der Auftragsbearbeitung mehrere halbe Tage damit verbringt, ihre realen Arbeitsabläufe im Testsystem nachzustellen, dann kostet das genauso viel wie jede andere Arbeitszeit dieser Person – nur dass in dieser Zeit keine produktive Wertschöpfung entsteht. Multiplizieren Sie diesen Aufwand mit der Zahl der Beteiligten: mehrere Fachbereiche mit je einem oder zwei Key-Usern, ein Prozessverantwortlicher, eine IT-Rolle, eine Projektleitung, die das Ganze begleitend steuert. In Summe sammeln sich schnell mehrere Personenwochen an Arbeitszeit an, die in den Test fließen, ohne dass jemals eine Position dafür in einer Kostenstelle auftaucht.

Wer den wirtschaftlichen Rahmen einer Evaluierung ehrlich abschätzen will, sollte diesen internen Aufwand sichtbar machen, statt ihn unter den Teppich zu kehren. Eine einfache Überschlagsrechnung genügt: Summieren Sie die geschätzten Arbeitsstunden aller Beteiligten und bewerten Sie sie mit einem internen Stundensatz, der nicht nur das Gehalt, sondern auch die Lohnnebenkosten und einen Anteil der Gemeinkosten enthält. Das Ergebnis ist keine prazise Zahl, aber eine Größenordnung – und diese Größenordnung schützt vor der Illusion, ein Test sei "umsonst". Sie hilft auch, den Aufwand ins Verhältnis zur späteren Entscheidung zu setzen: Eine Investition in eine ausgewachsene ERP-Lösung rechtfertigt einen ernsthaften Test, weil eine Fehlentscheidung um ein Vielfaches teurer wäre. Eine kleine, gut umrissene Anschaffung dagegen verträgt nur einen schlanken Test, sonst übersteigt der Prüfaufwand den Nutzen.

Externe Kosten: Beratung und Einrichtung beim partnergestützten PoC

Neben dem internen Aufwand können externe Kosten hinzukommen, sobald ein Implementierungspartner in die Testphase eingebunden wird. Viele Anbieter und ihre Partner bieten an, über das blanke Trial hinaus einen begleiteten Proof of Concept aufzusetzen – also ein Testsystem, das mit echten Stammdaten, angepassten Belegen und auf die eigenen Prozesse zugeschnittenen Einstellungen vorbereitet wird. Ein solcher partnergestützter PoC liefert ein deutlich realistischeres Bild als eine generische Demo, weil er das System bereits in der eigenen Sprache des Unternehmens zeigt. Er ist jedoch in aller Regel nicht kostenlos: Die Einrichtung, das Einspielen und Aufbereiten der Daten, Workshops zur Aufnahme der Anforderungen und die Begleitung während des Tests werden als Beratungsleistung in Rechnung gestellt.

Hier ist Klarheit vor Beginn entscheidend. Lassen Sie sich vorab schriftlich erläutern, welche Leistungen in einem etwaigen kostenlosen Vorlauf enthalten sind und ab welchem Punkt eine bezahlte Beratungs- oder Einrichtungsleistung beginnt. Manche Partner verrechnen die Kosten eines PoC später mit dem Projekt, falls es zustande kommt; andere stellen sie unabhängig vom Ausgang in Rechnung. Beide Modelle können sinnvoll sein, aber Sie sollten wissen, welches gilt, bevor Sie zusagen. Ein bezahlter PoC ist kein Nachteil – im Gegenteil, er kann die wirtschaftlichste Variante sein, weil er teure Fehlentscheidungen verhindert. Problematisch wird es nur, wenn die Kostenseite unausgesprochen bleibt und am Ende eine Rechnung kommt, mit der niemand gerechnet hat. Die saubere Klärung dieser Frage gehört zu einem professionellen ERP-Consulting und sollte Teil der Vereinbarung sein, bevor die erste Datei eingespielt wird.

Opportunitätskosten: was während des Tests nicht geschieht

Der dritte, am häufigsten übersehene Kostenfaktor sind die Opportunitätskosten. Jede Stunde, die ein erfahrener Key-User im Testsystem verbringt, ist eine Stunde, in der er nicht seine eigentliche Arbeit erledigt. Und es trifft selten die freien Kapazitäten: Für einen aussagekräftigen Test brauchen Sie gerade die Personen, die ihren Bereich am besten kennen – also genau jene, die im Tagesgeschäft am unentbehrlichsten sind. Die Auftragssachbearbeiterin, die jeden Sonderfall im Schlaf beherrscht, ist dieselbe, die während ihrer Testzeit nicht die täglichen Aufträge abarbeitet. Diese gebundene Arbeitszeit erzeugt keine direkte Ausgabe, aber sie kann zu Rückständen, Verzögerungen oder Mehrarbeit für Kolleginnen und Kollegen führen.

Daraus folgt eine schlichte, aber oft missachtete Konsequenz: Die Testphase muss bewusst und mit Augenmaß terminiert werden. Eine Evaluierung mitten in der Hochsaison, kurz vor dem Jahresabschluss oder während einer Personalengpass-Phase zu starten, vervielfacht die Opportunitätskosten und führt fast zwangsläufig zu flüchtigen, unzuverlässigen Ergebnissen, weil die Beteiligten innerlich beim Tagesgeschäft bleiben. Wer den Aufwand realistisch plant, sucht ein Zeitfenster mit ausreichend Luft und stimmt die Freistellung der Tester mit deren Vorgesetzten ab. Opportunitätskosten lassen sich nicht vermeiden, aber sie lassen sich steuern – durch kluge Terminierung und durch ein klar begrenztes Zeitbudget, das verhindert, dass sich der Test über Gebühr in die Länge zieht.

Typische Risiken einer entgleisenden Testphase

Eine Testphase ist nicht nur ein Kostenfaktor, sie ist auch ein Projekt mit eigenen Risiken. Diese Risiken haben die unangenehme Eigenschaft, dass sie sich schleichend aufbauen und erst bemerkt werden, wenn der Schaden bereits entstanden ist. Vier Muster treten besonders häufig auf, und es lohnt sich, sie beim Namen zu nennen, damit man sie frühzeitig erkennt.

Die endlose Testphase ohne Entscheidung. Das häufigste Risiko ist eine Evaluierung, die nie zu einem Schluss kommt. Es findet sich immer noch eine weitere Funktion, die man "kurz" prüfen könnte, noch ein Szenario, noch eine Variante. Solange kein Abschlusskriterium definiert ist, fehlt der Anlass, einen Strich zu ziehen. Die Folge: Der Aufwand läuft weiter, ohne dass sich der Erkenntnisgewinn entsprechend erhöht, und die eigentliche Entscheidung wird immer weiter aufgeschoben.

Überladene Anforderungen. Wenn der Test versucht, jede denkbare Anforderung, jeden Sonderfall und jede Wunschfunktion abzudecken, wird er unbeherrschbar. Statt sich auf die geschäftskritischen Prozesse zu konzentrieren, verzettelt sich das Team in einer endlosen Liste von Prüfpunkten, die in der Praxis kaum eine Rolle spielen. Eine durchdachte ERP-Auswahl arbeitet mit einer priorisierten Anforderungsliste, die zwischen Muss-, Soll- und Kann-Kriterien unterscheidet – und prüft im Test zuerst und am gründlichsten die Muss-Kriterien.

Verzettelung in Nebenfunktionen. Eng verwandt damit ist die Faszination für das Spektakuläre. Eine schicke Auswertung, eine elegante mobile App, eine clevere Automatisierung zieht die Aufmerksamkeit auf sich, während die unscheinbaren, aber täglich hundertfach genutzten Kernvorgänge ungeprüft bleiben. Am Ende weiß man viel über Funktionen, die selten gebraucht werden, und wenig über die, an denen sich die tägliche Arbeit entscheidet.

Ablaufende Trial-Fristen. Trial-Versionen sind zeitlich befristet. Wer ohne Plan startet, riskiert, dass die Frist abläuft, bevor die wesentlichen Szenarien geprüft sind – und steht dann vor der Wahl, mit luckenhaften Erkenntnissen zu entscheiden oder eine neue, womöglich kostenpflichtige Verlängerung zu organisieren. Die Trial-Frist sollte deshalb von Anfang an als harte Randbedingung in die Planung eingehen, nicht als nachträgliche Überraschung.

Pro und Contra einer intensiven, längeren Testphase

Wie tief und wie lang eine Testphase sein sollte, ist eine echte Abwägung – nicht "je mehr, desto besser". Eine intensive, ausgedehnte Evaluierung hat handfeste Vorteile, aber ebenso reale Kehrseiten. Die richtige Balance liegt zwischen oberflächlichem Durchklicken und endlosem Prüfen.

Die Konsequenz aus dieser Gegenüberstellung ist nicht, sich für ein Extrem zu entscheiden, sondern die Intensität am Gewicht der Entscheidung auszurichten. Je größer die geplante Investition und je tiefer das System in die Kernprozesse eingreift, desto eher rechtfertigt sich ein gründlicher, längerer Test. Bei einem überschaubaren Warenwirtschaftssystem mit klar umrissenem Funktionsumfang darf der Test schlank bleiben. Die Vorteile der linken Spalte gelten nur so lange, wie der Test fokussiert bleibt; sobald er ins Endlose kippt, schlagen die Nachteile der rechten Spalte durch, ohne dass die Vorteile weiter wachsen.

Wie ein angemessenes Zeit- und Aufwandsbudget aussieht

Ein angemessenes Budget beginnt nicht mit einer Zahl, sondern mit einer Eingrenzung des Untersuchungsgegenstands. Bevor das erste System geöffnet wird, sollte feststehen, welche geschäftskritischen Prozesse zwingend geprüft werden müssen und welche nachrangig sind. Aus dieser Priorisierung leitet sich der Aufwand ab: Die Muss-Prozesse erhalten reservierte, geschützte Zeitfenster; die Kann-Prozesse werden nur geprüft, wenn nach Abschluss der Pflichtthemen noch Kapazität bleibt. So wird verhindert, dass die Nebensächlichkeiten die Hauptsachen verdrängen.

Das Zeitbudget sollte zudem eine klare äußere Grenze haben – einen Endtermin, der sich an der Trial-Frist, am verfügbaren Zeitfenster der Beteiligten und am Entscheidungsdruck orientiert. Ein fester Endtermin wirkt disziplinierend: Er zwingt dazu, das Wesentliche zuerst zu prüfen, und schützt vor dem schleichenden Auswuchern. Bewährt hat sich, den Test in überschaubare Etappen zu gliedern – etwa eine Phase für die Kernprozesse, eine für die Schnittstellen und den technischen Unterbau, eine für die Auswertungssicht – und nach jeder Etappe kurz zu prüfen, ob das bisherige Bild für eine Entscheidung ausreicht. Diese Etappierung verhindert, dass der gesamte Aufwand in einen offenen Topf fließt, und macht den Fortschritt sichtbar. Wer den Aufwand sauber plant, schafft damit zugleich die Grundlage für eine realistische Schätzung der späteren ERP-Implementierung, denn die im Test gewonnenen Erkenntnisse über Anpassungsbedarf und Komplexität fließen direkt in deren Kalkulation ein.

Wichtig ist schließlich, das Budget nicht "nebenbei" zu vergeben. Die für den Test eingeplante Zeit muss mit den Vorgesetzten der Beteiligten abgestimmt und tatsächlich freigeräumt werden, sonst bleibt sie eine leere Zusage und die Tester quetschen die Prüfung zwischen ihre eigentlichen Aufgaben – mit den bekannten oberflächlichen Ergebnissen. Ein realistisch bemessenes, verbindlich reserviertes Budget ist die wirksamste Versicherung gegen alle vier beschriebenen Risiken zugleich.

Woran Sie erkennen, dass die Testphase abgeschlossen werden sollte

Die schwierigste Disziplin ist nicht der Start, sondern das Ende. Eine Testphase sollte nicht enden, weil die Zeit zufällig abgelaufen oder die Geduld erschöpft ist, sondern weil ein definierter Reifegrad erreicht wurde. Es lohnt sich, dieses Abschlusskriterium bereits zu Beginn festzulegen, statt es dem Gefühl zu überlassen. Mehrere Signale zeigen verlässlich an, dass der richtige Zeitpunkt gekommen ist.

Das wichtigste Signal ist die Sättigung des Erkenntnisgewinns: Wenn jede weitere Testaufgabe Ihr Bild nur noch bestätigt, statt es zu verändern, ist die Prüfung inhaltlich abgeschlossen. Ein zweites Signal ist die vollständige Abdeckung der Muss-Kriterien: Sobald alle geschäftskritischen Prozesse durchgespielt und beurteilt sind, ist das Pflichtprogramm erfüllt – die verbleibenden Kann-Themen rechtfertigen selten eine Verlängerung. Ein drittes Signal liefert die Frage, ob das Team eine begründete, mehrheitlich getragene Einschätzung abgeben kann: Wenn die Beteiligten ihr Urteil mit konkreten Beobachtungen statt mit vagen Eindrücken belegen können, liegt eine tragfähige Basis vor. Und ein viertes, sehr praktisches Signal ist die nahende Trial- oder Budgetgrenze, die ohnehin zum Abschluss zwingt – idealerweise fällt sie mit der inhaltlichen Sättigung zusammen, weil der Test von vornherein darauf ausgerichtet war.

Umgekehrt sind klare Warnzeichen, dass die Phase läuft, ohne abzuschließen: Es werden immer neue Nebenfunktionen entdeckt, die noch "unbedingt" geprüft werden müssen; die Beteiligten verlieren spürbar die Motivation und testen nur noch pflichtschuldig; oder es wird mehr über das Verlängern der Frist diskutiert als über die eigentliche Entscheidung. Wer diese Zeichen erkennt, sollte aktiv einen Abschluss herbeiführen, statt den Test treiben zu lassen. Denn das Ziel der Testphase ist nicht maximale Vollständigkeit, sondern ausreichende Sicherheit für die nächste Entscheidung – und sobald diese Sicherheit erreicht ist, kostet jeder weitere Tag nur noch, ohne zu nützen. Wie Sie aus den so gewonnenen, gut budgetierten Erkenntnissen die konkrete Auswahlentscheidung ableiten, führt ein eigener Abschnitt dieser Seite aus; hier endet die Aufgabe damit, die Testphase wirtschaftlich beherrscht und zum richtigen Zeitpunkt beendet zu haben.

Häufige Fragen