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 pruefen moechte, ist nicht zwingend auf einen Implementierungspartner angewiesen, um ueberhaupt erst einmal ein lauffaehiges System vor sich zu haben. Microsoft stellt eine kostenlose Self-Service-Trial bereit, die sich in wenigen Minuten ueber ein Geschaeftskonto anfordern laesst und bereits mit einer vollstaendig befuellten Demo-Firma ausgeliefert wird. Dieser Abschnitt beschreibt ausschliesslich 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 verfaellt. Was Sie anschliessend mit eigenen Daten und Szenarien anstellen, wer im Team mittestet und wie Sie mehrere Systeme fair gegeneinander stellen, ist Gegenstand der uebrigen Abschnitte dieser Seite – hier geht es allein um die Maschinerie unter der Oberflaeche, damit Sie ueberhaupt einen funktionierenden Sandkasten haben.

Die wichtigste Erkenntnis vorweg, weil sie die gesamte Planung Ihrer Testphase beeinflusst: Solange Sie ausschliesslich in der vorinstallierten CRONUS-Demo-Firma arbeiten, laeuft der 30-Tage-Trial-Zaehler ueberhaupt nicht. Der Countdown startet erst in dem Moment, in dem Sie eine eigene, produktivnahe Firma anlegen. Das gibt Ihnen einen oft unterschaetzten Spielraum, sich zunaechst 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-Geschaeftskonto voraus. Eine private Outlook- oder Gmail-Adresse genuegt in aller Regel nicht; die Trial ist auf Geschaeftsdomaenen ausgelegt und prueft die Adresse entsprechend. Verfuegt Ihr Unternehmen bereits ueber einen Microsoft-365-Mandanten, koennen Sie diesen nutzen und benoetigen lediglich ein Konto mit den passenden Berechtigungen. Existiert noch kein Mandant, laesst sich im Anmeldeprozess ein neuer, kostenloser Tenant erzeugen – dann erhalten Sie zwangslaeufig eine Adresse mit der Endung onmicrosoft.com, die fuer reine Testzwecke voellig ausreicht.

Die Anforderung selbst erfolgt entweder ueber die offizielle Produktseite von Business Central, ueber den Microsoft AppSource oder direkt aus einem bestehenden Microsoft-365-Portal heraus. Nach Eingabe der Geschaeftsadresse 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 vollstaendig konfiguriertes System vor sich sehen – das verdanken Sie der mitgelieferten Demo-Firma.

Wer hier bereits ahnt, dass die Evaluierung zu einer groesseren Entscheidung heranwaechst, 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 spaeter 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 gewaehlter Lokalisierung tritt sie unter Bezeichnungen wie CRONUS AG, CRONUS International Ltd. oder einer landesspezifischen Variante auf. Inhaltlich handelt es sich um ein mittelstaendisch gepraegtes Handels- und Fertigungsunternehmen mit einem durchgaengig befuellten Datenbestand: Es gibt Debitoren und Kreditoren, einen Artikelstamm mit Lagerbestaenden, gebuchte und offene Belege, einen vollstaendigen Kontenrahmen sowie historische Buchungen, die saemtliche Standardberichte mit plausiblen Werten fuellen. Damit koennen Sie sofort durch Verkaufsauftraege, Einkaufsbestellungen, Lagerbewegungen, Fibu-Buchungen und Auswertungen navigieren, ohne vorher irgendetwas anlegen zu muessen.

Der entscheidende Vorteil von CRONUS ist die folgenlose Spielwiese: Sie koennen Belege buchen, stornieren, Berichte ausfuehren und Funktionen ausprobieren, ohne echte Geschaeftsdaten zu gefaehrden und – wie eingangs betont – ohne die Trial-Frist zu starten. CRONUS ist damit der ideale Ort, um die grundlegende Bedienphilosophie kennenzulernen: die Suche ueber die Lupe, die Navigation ueber Rollencenter und Menueband, das Zusammenspiel von Listen- und Kartenansichten. Wer mit der Begriffswelt von Navision als ERP-System noch nicht vertraut ist, findet in CRONUS eine vollstaendige, in sich konsistente Modellwelt, an der sich die Logik gut nachvollziehen laesst.

Genauso wichtig sind aber die Grenzen. CRONUS bildet ein generisches Standardunternehmen ab, nicht Ihre Branche, nicht Ihre Belegfluesse und nicht Ihre Stammdatenqualitaet. Die Demo-Firma verleitet dazu, Funktionen an idealtypisch sauberen Daten zu beurteilen, die mit der Realitaet eines gewachsenen Betriebs wenig gemein haben. Eine Software wirkt an aufgeraeumten Beispieldaten fast immer ueberzeugend; ob sie auch Ihre Sonderfaelle, Ihre Mengeneinheiten oder Ihre Preislogik traegt, zeigt sich erst an realitaetsnahen Daten. Wie Sie ueber 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 ausdruecklich zum Experimentieren gedacht ist: Aenderungen darin haben keinerlei Auswirkung auf eine produktive Umgebung. Fuer die Evaluierung ist das Gold wert, weil Sie riskante oder destruktive Aktionen ausprobieren koennen – Massenbuchungen, das Aktivieren von Funktionen, das Zuruecksetzen von Einstellungen –, ohne befuerchten zu muessen, 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, fuer unterschiedliche Fragestellungen getrennte Sandboxes zu fuehren: 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 schuetzt Sie vor dem aergerlichen Effekt, dass Sie nach drei Stunden Testen nicht mehr unterscheiden koennen, welcher Zustand der urspruengliche war. Eine Sandbox ist zudem der richtige Ort, um spaeter – etwa mit einem Partner – einzelne Erweiterungen oder Konfigurationen zu prüfen, ohne die Hauptumgebung zu belasten.

Schritt fuer Schritt zum lauffaehigen Testsystem

Die folgende Reihenfolge fuehrt Sie vom voellig leeren Microsoft-Konto bis zu einem System, in dem Sie kontrolliert und fristbewusst testen koennen. 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 laesst

Die Self-Service-Trial deckt einen ueberraschend grossen Funktionsumfang ab. Sie koennen den kompletten Standard von Business Central erleben: Finanzbuchhaltung, Debitoren- und Kreditorenmanagement, Verkauf und Einkauf, Lager- und Bestandsfuehrung, einfache Produktion sowie das Berichts- und Auswertungswesen. Auch die Integration mit den vertrauten Microsoft-365-Werkzeugen – allen voran Excel und Outlook – laesst sich unmittelbar erproben, ebenso die Bedienung ueber Webclient und mobile App. Fuer eine erste Einschaetzung, ob die Oberflaeche zur Arbeitsweise Ihres Teams passt und ob die Standardprozesse Ihren Ablaeufen nahekommen, reicht das voellig aus. Auch das Anlegen eigener Stammdaten, das Erfassen realitaetsnaher Belege und das Durchspielen typischer Tagesablaeufe ist in der Trial moeglich, sodass Sie weit ueber das blosse Betrachten von CRONUS hinauskommen.

Damit eignet sich die Trial hervorragend, um die grundsaetzliche Eignung der Loesung fuer ein ERP im Mittelstand einzuschaetzen, ohne dass bereits Beratungskosten entstehen. Sie verschaffen sich ein belastbares Bild davon, ob das System ueberhaupt in die engere Wahl gehoert, bevor Sie Zeit und Budget in ein partnergestuetztes Proof of Concept investieren.

Wo die Self-Service-Trial an ihre Grenzen stoesst

So weit der Standard traegt, 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 Schluesse ziehen. Drei Einschraenkungen wiegen besonders schwer.

Kein echtes Customizing: Die Trial bildet den Auslieferungsstandard ab. Tiefgreifende Anpassungen, branchenspezifische Erweiterungen aus dem AppSource in produktiver Ausgestaltung oder massgeschneiderte 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 tatsaechlich nutzen wuerden. Gerade die fuer den Mittelstand entscheidenden Sonderanforderungen bleiben in der Trial daher unsichtbar.

Keine echte Datenmigration: Die Uebernahme Ihrer realen Stamm- und Bewegungsdaten aus einem Altsystem – Artikel, Kunden, offene Posten, Buchungshistorie – ist ein Projektthema und nicht Bestandteil der Trial. Sie koennen zwar manuell oder ueber Excel begrenzt Daten einspielen, doch eine saubere, regelbasierte Migration mit Mapping, Validierung und Dublettenbereinigung erfordert Werkzeuge und Erfahrung, die ueber die Self-Service-Umgebung hinausgehen. Damit fehlt der Trial genau jener Realitaetstest, der spaeter ueber Erfolg oder Scheitern entscheidet.

Eingeschraenkte 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 gewaehlte Region gebunden und laesst sich nicht beliebig kombinieren oder um spezielle gesetzliche Anforderungen erweitern. Wer in mehreren Laendern taetig ist oder besondere regulatorische Anforderungen hat, stoesst hier an Grenzen, die nur ein Partner mit den passenden Erweiterungen aufloesen kann.

Diese Grenzen sind keine Schwaeche der Trial, sondern Ausdruck ihres Zwecks: Sie ist ein Werkzeug zur Erst-Einschaetzung, nicht der Ersatz fuer 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 Ueberblick

Empfehlung fuer 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 laeuft keine Frist, und Sie koennen so lange experimentieren, wie Sie moechten. Erst wenn Sie sich sicher bewegen und ein konkretes Testdrehbuch im Kopf haben, legen Sie in der zweiten Phase Ihre eigene Firma an und stossen damit bewusst den 30-Tage-Countdown an. So verschwenden Sie keinen Tag der wertvollen Frist mit reiner Orientierung. Dokumentieren Sie ausserdem von Beginn an, welche Umgebung welchem Zweck dient, und behalten Sie die 45-Tage-Inaktivitaetsgrenze im Blick, damit Ihnen ein zwischenzeitlich pausierter Zugang nicht unbemerkt geloescht wird.

Damit haben Sie die technische Grundlage geschaffen: ein lauffaehiges Testsystem, eine ungefaehrliche Spielwiese und ein klares Verstaendnis der Fristen. Wie Sie diese Umgebung nun mit aussagekraeftigen eigenen Daten fuellen, welche Rollen im Team welche Aufgaben uebernehmen und wie Sie mehrere Kandidaten methodisch vergleichen, fuehren die weiteren Abschnitte dieser Seite aus. Wer das technische Fundament sauber legt, gewinnt fuer all diese inhaltlichen Schritte die noetige Ruhe – und trifft am Ende eine Entscheidung fuer die passende ERP-Loesung, die auf eigener Anschauung beruht statt auf einer reinen Verkaufspraesentation.

Eigene Testdaten und Praxisszenarien aufbauen, statt nur Beispieldaten zu klicken

Ein Testsystem allein beweist noch nichts. Sobald die Umgebung steht und die mitgelieferte Beispielfirma einlaedt, durch fertige Belege und gefuellte Berichte zu klicken, entsteht schnell ein truegerisches Gefuehl von Sicherheit: Alles funktioniert, alles sieht aufgeraeumt aus, die Zahlen stimmen. Genau das ist die Falle. Eine Software wirkt an idealtypisch sauberen Demodaten fast immer ueberzeugend – 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 taeglich produziert. Dieser Abschnitt behandelt ausschliesslich die inhaltliche Vorbereitung des Selbsttests: wie Sie die generische Beispielfirma durch eigene, repraesentative Stamm- und Bewegungsdaten ersetzen, welche End-to-End-Prozesse Sie nachstellen und wie Sie gezielt jene Sonderfaelle einbauen, an denen sich die Eignung einer Loesung wirklich entscheidet. Es geht hier nicht um das Drehbuch der gefuehrten Demo durch einen Anbieter – das ist Gegenstand der gefuehrten Praesentation – und auch nicht um das technische Aufsetzen der Umgebung, sondern um die Daten- und Szenariobasis, mit der Sie eigenstaendig pruefen.

Der Unterschied ist fundamental. In der Beispielfirma bestaetigen Sie, dass eine Funktion existiert. Mit eigenen Daten pruefen Sie, ob diese Funktion Ihre Wirklichkeit traegt. Erst wenn ein Auftrag mit Ihren Artikelnummern, Ihren Mengeneinheiten, Ihrer Rabattlogik und Ihren Lieferkonstellationen sauber durchlaeuft – 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 oberflaechlichen Eindruck.

Warum der Happy Path truegt

Als Happy Path bezeichnet man den idealen Ablauf eines Prozesses: Der Kunde bestellt, die Ware ist vorraetig, die Lieferung geht vollstaendig raus, die Rechnung wird gestellt und fristgerecht bezahlt. Solche Ablaeufe demonstriert jede Software muehelos, denn sie sind der Normalfall, fuer den jedes System primaer gebaut ist. Wer seinen Test auf den Happy Path beschraenkt, erhaelt darum ein systematisch zu positives Bild – er prueft genau das, was ohnehin kaum je das Problem ist.

Die Wahrheit ueber 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 Fremdwaehrung gestellt und spaeter mit abweichendem Kurs bezahlt werden, ein Rabatt gilt nur fuer eine Staffelmenge, ein Artikel ist eine Variante mit eigener Charge, eine Gutschrift korrigiert einen bereits gebuchten Beleg. Diese Faelle 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 spaeter im Produktivbetrieb taeglich Zeit kosten. Ein Test, der diese Grenzfaelle ausspart, verschiebt das boese Erwachen lediglich auf die Zeit nach der Kaufentscheidung.

Bauen Sie Ausnahmen deshalb bewusst und planvoll ein, nicht zufaellig. Notieren Sie vorab, welche Sonderfaelle in Ihrem Betrieb regelmaessig vorkommen, und behandeln Sie jeden davon als eigenes, zu pruefendes Szenario. Erst die Summe aus Normalablaeufen und bewusst gesetzten Grenzfaellen ergibt ein realistisches Bild der Eignung.

Drei bis fuenf End-to-End-Prozesse auswaehlen

Der erste Schritt ist nicht das Eingeben von Daten, sondern die Auswahl der richtigen Prozesse. Versuchen Sie nicht, jeden denkbaren Ablauf abzubilden – das ueberfordert jede Testphase und verzettelt das Team. Konzentrieren Sie sich stattdessen auf drei bis fuenf End-to-End-Prozesse, die fuer Ihren Betrieb charakteristisch und geschaeftskritisch sind. End-to-End heisst dabei: vom ausloesenden Ereignis bis zum buchhalterischen Abschluss, ueber alle beteiligten Abteilungen hinweg, nicht nur ein einzelner Funktionsklick.

Typische Kandidaten fuer ein Handels- oder Fertigungsunternehmen sind die beiden grossen Wertschoepfungsketten – Order-to-Cash (von der Kundenanfrage ueber Angebot, Auftrag, Lieferung und Rechnung bis zum Zahlungseingang) und Purchase-to-Pay (von der Bedarfsmeldung ueber Bestellung, Wareneingang und Eingangsrechnung bis zur Zahlung). Hinzu kommen je nach Geschaeftsmodell ein Fertigungs- oder Montageprozess mit Stuecklistenaufloesung, ein Retouren- und Reklamationsablauf sowie ein periodischer Abschluss mit den fuer Sie relevanten Auswertungen. Waehlen Sie bewusst die Prozesse, die entweder das groesste Volumen tragen oder die heute mit Ihrem Altsystem am meisten Reibung erzeugen – dort liegt der groesste Erkenntnisgewinn.

Beschreiben Sie jeden ausgewaehlten Prozess vorab in wenigen Saetzen als Szenario: Wer loest ihn aus, welche Stationen durchlaeuft er, welche Belege entstehen, womit ist er abgeschlossen. Diese kurze Drehbuchskizze – nicht zu verwechseln mit dem Vorfuehrskript des Anbieters – ist Ihre Pruefliste. Sie sorgt dafuer, dass Sie im System zielgerichtet nachstellen, statt orientierungslos zu klicken, und sie macht die Ergebnisse zwischen mehreren Testern und mehreren Kandidatensystemen ueberhaupt erst vergleichbar.

Realistische Stamm- und Bewegungsdaten importieren

Stehen die Prozesse fest, brauchen sie eine Datengrundlage. Hier gilt die Faustregel: so realistisch wie noetig, so schlank wie moeglich. Sie muessen nicht Ihren gesamten Datenbestand uebernehmen – das waere ein Migrationsprojekt und nicht Aufgabe eines Selbsttests. Es genuegt ein repraesentativer Querschnitt, der Ihre Vielfalt abbildet: ein paar Dutzend Artikel statt Tausender, aber bewusst so ausgewaehlt, dass alle Ihre Besonderheiten vorkommen.

Auf der Ebene der Stammdaten heisst das konkret: Nehmen Sie Artikel mit unterschiedlichen Mengeneinheiten und Umrechnungen, Varianten und Chargen, Artikel mit Mindestbestaenden und solche mit langen Wiederbeschaffungszeiten. Bei den Kunden bilden Sie verschiedene Konstellationen ab – Inlandskunden, Auslandskunden mit Fremdwaehrung 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 Stuecklisten mit mehreren Ebenen, denn an der Stuecklistenaufloesung und der korrekten Mengen- und Kostenfortschreibung entscheidet sich, ob das System Ihre Produktlogik wirklich abbildet.

Fuer den Import bieten sich in der Praxis zwei Wege an. Kleinere, sorgfaeltig ausgewaehlte Datensaetze legen Sie schlicht manuell an – das hat den Nebeneffekt, dass Sie die Pflegemasken und den Erfassungsaufwand gleich mitbeurteilen. Groessere Mengen spielen Sie ueber 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 fuehren? Passt die Feldlogik zu Ihren Gepflogenheiten? Schon der Importvorgang selbst liefert wertvolle Hinweise auf den spaeteren Pflegeaufwand. Eine echte, regelbasierte Datenmigration aus dem Altsystem bleibt davon unberuehrt – sie ist ein Projektthema und nicht Teil des Selbsttests.

Datenschutz nicht vergessen: Wenn Sie reale Kunden- oder Lieferantendaten in eine Testumgebung uebernehmen, handelt es sich um personenbezogene Daten mit allen Pflichten, die daran haengen. Pseudonymisieren oder anonymisieren Sie Namen, Adressen und Kontaktdaten, soweit das fuer die Aussagekraft des Tests nicht zwingend im Klartext noetig ist. Die Datenstruktur – Mengeneinheiten, Preise, Konditionen, Stuecklisten – bleibt dabei realistisch, die Identitaeten muessen 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, prueft tatsaechlich in der Tiefe. Wer auf halber Hoehe stehenbleibt, testet entweder leere Huellen ohne Bewegung oder Bewegungen ohne die Reibung der Realitaet.

Die unterste Ebene bilden die Stammdaten: Artikel, Kunden, Lieferanten, Stuecklisten. Sie sind das Fundament, auf dem alles Weitere ruht. Darueber liegen die Bewegungsdaten – die Belege, die im Tagesgeschaeft entstehen und die Sie im Test selbst erzeugen. Die dritte Ebene verknuepft diese Belege zu Prozessketten: Erst die durchgaengige Kette vom Auftrag bis zum Zahlungseingang zeigt, ob die Uebergaenge zwischen den Schritten sauber greifen. Und ganz oben stehen die Ausnahme- und Grenzfaelle, die Sie diesen Ketten bewusst aufpfropfen. Genau diese oberste Schicht trennt einen aussagekraeftigen Test von einer Vorfuehrung – und sie ist es auch, die ueberhaupt erst sichtbar macht, ob ein System fuer den anspruchsvollen Alltag eines Betriebs taugt.

Grenzfaelle gezielt einbauen

Mit der Datengrundlage und den definierten Prozessen koennen 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 tatsaechlich passiert. Vier Klassen von Grenzfaellen lohnen besondere Aufmerksamkeit, weil sie in nahezu jedem Betrieb vorkommen und Systeme hier deutlich unterschiedlich abschneiden.

Ergaenzen Sie diese Liste um die Sonderfaelle Ihrer Branche: Seriennummern- und Chargenpflicht, Konsignationslager, Streckengeschaefte, Sammelrechnungen, abweichende Steuersaetze oder reverse-charge-Konstellationen im Auslandsgeschaeft. Je naeher diese Szenarien an Ihrer taeglichen Realitaet liegen, desto klarer trennt der Test geeignete von ungeeigneten Kandidaten. Wer ein System spaeter als zentrales Warenwirtschaftssystem einsetzen will, sollte gerade die mengen- und bestandsnahen Grenzfaelle besonders gruendlich pruefen, denn hier wirken sich Schwaechen unmittelbar auf Lager und Liquiditaet 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 noetig war oder ob das System die Anforderung gar nicht abbilden konnte – und mit welchem Aufwand. Vermerken Sie ausserdem den subjektiven Eindruck: Wie viele Klicks, wie viele Bildschirmwechsel, wie verstaendlich die Meldungen? Diese Notizen sind das eigentliche Ergebnis Ihrer inhaltlichen Vorbereitung. Sie verwandeln vage Eindruecke in eine belastbare Grundlage und liefern zugleich die Bausteine, mit denen sich mehrere Kandidaten spaeter sauber gegenueberstellen lassen.

Bewahren Sie die fertig aufbereiteten Testdaten und Szenariobeschreibungen auf. Sie sind nicht nur fuer die aktuelle Runde nuetzlich, sondern auch dann, wenn ein Anbieter Sie zu einem partnergestuetzten Proof of Concept einlaedt: Mit Ihren eigenen Daten und Ihren eigenen Grenzfaellen treten Sie dort nicht als passives Publikum auf, sondern als Auftraggeber, der genau weiss, was sein Betrieb braucht. So wird aus dem ersten Eindruck eine fundierte Entscheidung fuer die passende ERP-Loesung – getragen von eigener Anschauung an echten Daten statt von einer geschliffenen Vorfuehrung an fremden Beispielwerten.

Wer mittestet: Rollen, Verantwortlichkeiten und Zeitbudget im Evaluierungsteam

Ob eine Testphase zu einem belastbaren Urteil fuehrt oder zu einem zufaelligen Bauchgefuehl, entscheidet sich nicht an der Software, sondern an der Frage, wer sie ueberhaupt 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 duennem Eis. Dieser Abschnitt beschreibt deshalb ausschliesslich die personelle Organisation der Evaluierung: welche Rollen ein Testteam besetzen sollte, welche Verantwortung jede einzelne traegt, 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 fuellt, ist Gegenstand anderer Abschnitte dieser Seite; hier nehmen wir an, dass die Umgebung steht, und kuemmern uns um die Menschen, die darin arbeiten.

Der Grund, warum die Teamzusammensetzung so schwer wiegt, ist einfach: Eine ERP-Loesung beruehrt nahezu jeden Bereich eines Unternehmens, von der Auftragserfassung ueber das Lager und die Buchhaltung bis zur Geschaeftsleitung, die am Monatsende verdichtete Zahlen erwartet. Keine einzelne Person ueberblickt all diese Perspektiven aus eigener taeglicher Erfahrung. Wer eine Software allein beurteilt, beurteilt sie zwangslaeufig durch die Brille seiner eigenen Aufgaben – und blendet genau die Reibungspunkte aus, die spaeter andere Abteilungen taeglich spueren. Eine durchdachte personelle Aufstellung ist damit kein organisatorischer Luxus, sondern die Voraussetzung dafuer, dass die Investition in eine spaetere ERP-Implementierung auf einem realistischen Bild beruht.

Die fuenf Rollen im Evaluierungsteam

Ein vollstaendiges Testteam besetzt fuenf typische Rollen. Diese muessen nicht zwingend fuenf 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 Herzstueck jeder Evaluierung. Es handelt sich um erfahrene Mitarbeiterinnen und Mitarbeiter aus den Abteilungen, die spaeter taeglich mit dem System arbeiten werden: die Auftragssachbearbeiterin, der Einkaeufer, 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 Tagesgeschaeft erfassen, mit denselben Sonderfaellen, 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 traegt, 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 unzaehligen kleinen Ausnahmen, die ein gewachsenes Geschaeft 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 umstaendliche Tdaetigkeit deutlich leichter von der Hand geht. Wichtig ist, dass Sie Key-User auswaehlen, 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

Waehrend der Key-User die einzelne Aufgabe testet, beurteilt der Prozessverantwortliche das Zusammenspiel ueber Abteilungsgrenzen hinweg. Seine Frage lautet nicht "Funktioniert dieser eine Schritt?", sondern "Greift die Kette sauber ineinander?" – also: Loest 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 Ablaeufe tatsaechlich organisiert? Diese Rolle uebernimmt haeufig 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 Uebergaben zwischen Abteilungen entstehen erfahrungsgemaess die groessten 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 haetten gesetzt werden muessen. Diese Rolle prueft auch, ob sich die Ablauflogik des Systems mit vertretbarem Aufwand an die eigenen Prozesse anpassen laesst oder ob das Unternehmen seine Prozesse umgekehrt an das System anpassen muesste – eine Frage, die fuer die spaetere Auswahl der passenden ERP-Loesung oft schwerer wiegt als jede Einzelfunktion.

IT und Administration: Integration, Sicherheit und Betrieb

Die IT-Rolle betrachtet das System aus einer voellig anderen Hoehe als die Fachseite. Sie fragt nicht, wie sich ein Auftrag erfasst, sondern wie sich das System in die bestehende Landschaft einfuegt: 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 laesst 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 ueberhaupt liegen? Bei einer Cloud-Loesung wie dem heutigen Business Central verschieben sich diese Fragen teilweise zum Anbieter, verschwinden aber nicht – die Verantwortung fuer Konfiguration, Zugriffe und Integration bleibt im Haus.

Die IT prueft im Test auch den administrativen Unterbau, den Fachanwender nie zu Gesicht bekommen: das Anlegen und Sperren von Benutzern, das Einspielen von Updates, die Moeglichkeiten zum Export und zur Sicherung von Daten, die Anbindung per Schnittstelle. Diese Rolle ist entscheidend, weil ein System, das fachlich ueberzeugt, 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 Anschlussfaehigkeit oft darueber, ob die erhofften Effizienzgewinne tatsaechlich eintreten oder an Medienbruechen verpuffen.

Geschaeftsfuehrung und Entscheider: die verdichtete Sicht

Die Geschaeftsleitung 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 fuer Entscheidungen gebraucht werden. Lassen sich aussagekraeftige Auswertungen, Dashboards und Kennzahlen erzeugen? Gibt das System einen verlaesslichen, aktuellen Blick auf Umsatz, Bestand, offene Posten und Auftragslage? Und passt die Loesung in die strategische und finanzielle Gesamtplanung des Unternehmens?

Damit die Entscheider eine fundierte Meinung bilden koennen, brauchen sie keine Rohdaten, sondern eine Verdichtung: eine kompakte Zusammenfassung der Testergebnisse aus den uebrigen Rollen, ergaenzt um eigene Eindruecke aus den Auswertungs- und Berichtsfunktionen. Es ist eine zentrale Aufgabe der Projektleitung, diese Verdichtung zu liefern, statt die Geschaeftsfuehrung mit dem Detailprotokoll der Fachseite zu ueberfordern. Der Zeitbedarf dieser Rolle ist gering, ihr Gewicht in der Entscheidung jedoch hoch – weshalb es lohnt, die Praesentation der Ergebnisse sorgfaeltig vorzubereiten. Eine strukturierte ERP-Auswahl lebt davon, dass die Entscheidungsebene auf einer sauberen Aufbereitung aufsetzt und nicht auf dem Eindruck einer einzelnen Vorfuehrung.

Projektleitung: die Klammer um das Team

Die fuenfte Rolle haelt das Ganze zusammen. Die Projektleitung testet selbst kaum, sondern organisiert: Sie verteilt die Testaufgaben auf die Rollen, legt den Zeitrahmen fest, sammelt die Rueckmeldungen ein, moderiert Widersprueche und sorgt dafuer, dass am Ende ein konsolidiertes Bild entsteht statt fuenf unverbundener Einzelmeinungen. Diese Rolle ist auch dafuer 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 praegt.

Gerade in kleineren Unternehmen wird diese Rolle gern unterschaetzt oder ganz weggelassen, mit der Folge, dass die Evaluierung im Sande verlaeuft 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 Bruecke zwischen der operativen Testarbeit und der Entscheidungsebene.

Rollen, Aufgaben und Zeitbudget im Ueberblick

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 fuer eine kompakte, fokussierte Evaluierung; sie skalieren mit der Groesse des Unternehmens und der Zahl der zu pruefenden 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 Realitaet angelehnte Auftraege: "Erfassen Sie einen Auftrag fuer Kunde X mit Teillieferung und Sonderkondition" wirkt ungleich mehr als die vage Aufforderung, "mal das Verkaufsmodul anzuschauen". Der Prozessverantwortliche erhaelt umgekehrt durchgaengige Szenarien, die mehrere Abteilungen durchlaufen, damit er die Uebergaben beurteilen kann. Die IT bekommt technische Pruefpunkte, die Geschaeftsleitung am Ende eine verdichtete Sicht.

Bewaehrt hat sich, die Aufgaben schriftlich und vorab zu verteilen, sodass jede Rolle weiss, was von ihr erwartet wird und worauf sie achten soll. Das verhindert, dass alle dasselbe testen und ganze Bereiche ungeprueft bleiben. Es lohnt sich zudem, bewusst Ueberlappungen einzubauen: Lassen Sie einen besonders kritischen Prozess von zwei verschiedenen Key-Usern testen. Decken sich deren Urteile, gewinnt das Ergebnis an Verlaesslichkeit; weichen sie ab, haben Sie einen wertvollen Hinweis auf einen Punkt, der genauer betrachtet werden muss. Diese Verteilungslogik gilt unabhaengig davon, ob Sie ein schlankes Warenwirtschaftsprogramm oder eine breit integrierte ERP-Suite pruefen – sie skaliert lediglich mit der Zahl der betroffenen Bereiche.

Wie viel Zeit realistisch einzuplanen ist

Der haeufigste Planungsfehler besteht darin, das Testen "nebenbei" laufen zu lassen. Wer Key-Usern auftraegt, das System zusaetzlich zum vollen Tagesgeschaeft zu pruefen, erntet fluechtige, oberflaechliche Rueckmeldungen – weil die produktive Arbeit immer Vorrang hat. Eine ernsthafte Evaluierung braucht reservierte, geschuetzte Zeitfenster, in denen die beteiligten Personen vom Tagesgeschaeft entlastet sind. Das muss nicht am Stueck geschehen: Mehrere halbe Tage, verteilt ueber zwei bis drei Wochen, sind oft wirksamer als ein einzelner Marathontag, weil dazwischen Eindruecke reifen und Rueckfragen entstehen.

Als grobe Orientierung gilt: Key-User benoetigen den groessten Anteil – realistisch mehrere halbe Tage je Fachbereich, denn sie tragen die eigentliche Pruefarbeit. Prozessverantwortliche und IT kommen mit ein bis zwei fokussierten Tagen aus, jeweils mit klarem Schwerpunkt. Die Geschaeftsfuehrung braucht nur wenige Stunden fuer die verdichtete Ergebnissicht. Die Projektleitung schliesslich 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 tatsaechlich 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 groesste Gefahr einer Evaluierung ist, dass am Ende eine einzige, womoeglich voreingenommene Stimme den Ausschlag gibt. Das passiert leicht: Eine technikaffine Person ist begeistert von einer eleganten Funktion und uebersieht, dass die Fachabteilung damit nicht zurechtkommt – oder umgekehrt lehnt ein einzelner Skeptiker das System wegen einer Gewohnheitsumstellung ab, die objektiv kein Problem darstellt. Beide Faelle fuehren 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 Rueckmeldung: Wenn jede Rolle ihre Eindruecke getrennt und nachvollziehbar festhaelt, lassen sich Einzelmeinung und breiter Konsens spaeter 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 erwaehnte Doppelpruefung 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 verfuegen Sie ueber das, was eine reine Produktdemo niemals liefern kann: ein Urteil, das von den Menschen getragen wird, die spaeter taeglich mit dem System arbeiten. Wie Sie die so gewonnenen Eindruecke methodisch gegen konkurrierende Systeme abwaegen und in eine saubere Auswahlentscheidung ueberfuehren, fuehren die weiteren Abschnitte dieser Seite sowie die uebergeordnete 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 spaeter in einer halbstuendigen Anbieterpraesentation sieht und ein drittes Produkt nur aus einer aelteren Erinnerung kennt, hat am Ende drei voellig unterschiedliche Eindruecke 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 ueber mehrere Demos und Testlaeufe hinweg – also um die Disziplin, die dafuer sorgt, dass am Ende tatsaechlich Aepfel mit Aepfeln verglichen werden und nicht das Verkaufstalent des einen Anbieters gegen die nuechterne 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 uebrigen Abschnitte dieser Seite. Ebenso bewusst lassen wir die eigentliche Bewertungsmethodik aussen vor: Wie eine Nutzwertanalyse mit Gewichtungen und Punktwerten formal aufgebaut wird, gehoert in den uebergeordneten Kontext der ERP-Auswahl, und ein fertiger Bewertungsbogen liegt bereits vor. Der Fokus liegt hier ausschliesslich auf einer Frage: Wie organisieren Sie den Vergleich selbst so, dass die Zahlen, die am Ende im Bewertungsbogen stehen, ueberhaupt miteinander vergleichbar sind?

Warum unkontrollierte Tests systematisch in die Irre fuehren

Ein Vergleich ist immer nur so belastbar wie die Gleichheit der Bedingungen, unter denen er zustande kommt. In der empirischen Forschung ist das eine Selbstverstaendlichkeit – man veraendert genau eine Variable und haelt alle anderen konstant. Bei der Softwareauswahl wird dieses Prinzip routinemaessig verletzt, meist ohne dass es jemandem auffaellt. Das System, das zuletzt vorgefuehrt wurde, wirkt frischer. Das System, dessen Vertriebsmitarbeiter besonders sympathisch war, bekommt unbewusst Bonuspunkte. Das System, bei dem man zufaellig ein einfacheres Beispiel durchgeklickt hat, erscheint bedienfreundlicher. Keiner dieser Effekte hat das Geringste mit der Eignung der Software fuer Ihr Unternehmen zu tun – und doch praegen sie das Urteil oft staerker als jedes Sachargument.

Drei Verzerrungsquellen sind besonders haeufig und besonders tueckisch. Erstens die ungleichen Testfaelle: 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 gewoehnt und vergeben grosszuegiger – das spaeter getestete System profitiert allein von Ihrer eigenen Lernkurve. Drittens der Anbietereffekt: Eine professionell moderierte Demo mit aufbereiteten Beispieldaten laeuft fast zwangslaeufig 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 Praesentationskunst – nicht die Software.

Identische Testfaelle und identische Datensaetze fuer jedes System

Das Herzstueck eines fairen Vergleichs ist ein fester, im Voraus festgelegter Satz von Testfaellen, der fuer jedes System unveraendert durchgespielt wird. Diese Testfaelle sollten Sie einmal sauber formulieren – als konkrete, an Ihrem Geschaeft orientierte Aufgaben – und dann wie ein Pruefprotokoll behandeln, von dem nicht abgewichen wird. Wenn Sie in einem System den Auftrag fuer Kunde Mueller mit Teillieferung, Sonderkondition und Sammelrechnung erfassen, dann erfassen Sie in jedem anderen System exakt denselben Auftrag fuer denselben Kunden mit denselben Bedingungen. Nur so wird sichtbar, welches System diese eine, immer gleiche Aufgabe leichter, schneller oder vollstaendiger 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 fuer den Test aufgebaut werden; entscheidend ist hier nur, dass dieser Datensatz fuer alle Kandidaten identisch ist und nicht je System variiert. Sonst entsteht der klassische Trugschluss: System A wirkt uebersichtlicher, weil Sie dort nur fuenfzig Artikel angelegt haben, waehrend System B mit zweihundert Artikeln getestet wurde und allein deshalb voller und unuebersichtlicher erscheint. Ein gemeinsamer Referenzdatensatz schliesst diese Fehlerquelle aus. Halten Sie die Testfaelle und den zugehoerigen Datenumfang schriftlich fest, bevor der erste Test beginnt – dieses Protokoll ist die Garantie dafuer, dass Sie spaeter nicht heimlich die Messlatte verschieben.

Ein praktischer Hinweis fuer den Vergleich von Business Central mit Alternativen: Manche Funktionen heissen in verschiedenen Systemen unterschiedlich oder sind anders verortet. Es ist Aufgabe der Vorbereitung, die Testfaelle so zu formulieren, dass sie das fachliche Ziel beschreiben ("Erstellen Sie aus dem Auftrag eine Teillieferung und anschliessend eine Sammelrechnung") und nicht den systemspezifischen Klickweg. So bleibt der Testfall fuer jeden Kandidaten fair, auch wenn die Wege zum Ziel unterschiedlich aussehen. Wie tief Sie dabei in einzelne Module gehen, haengt von Ihrem Schwerpunkt ab – ob Sie eine vollintegrierte ERP-Loesung oder primaer die Faehigkeiten im Bereich ERP-Warenwirtschaft vergleichen.

Eine gemeinsame Bewertungsskala statt wandernder Massstaebe

Selbst wenn alle Systeme dieselben Aufgaben mit denselben Daten durchlaufen, entsteht noch kein fairer Vergleich, solange jeder Tester seinen eigenen, sich verschiebenden Massstab anlegt. Eine gemeinsame Bewertungsskala bedeutet zweierlei. Zum einen: dieselbe Anzahl an Stufen und dieselbe Bedeutung jeder Stufe fuer alle Systeme – ob Sie mit einer Skala von eins bis fuenf oder mit Schulnoten arbeiten, ist zweitrangig, solange der Massstab fuer jeden Kandidaten identisch ist. Zum anderen, und das wird oft unterschaetzt: ein gemeinsames Verstaendnis davon, was eine bestimmte Note bedeutet. Eine "vier" sollte fuer jeden Tester und bei jedem System dasselbe heissen, etwa "die Aufgabe ist loesbar, aber umstaendlich". 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 Massnahme gegen wandernde Massstaebe. Sie verhindert, dass ein nachsichtiger Tester durchgaengig grosszuegiger 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 uebergeordneten ERP-Auswahl beschrieben ist; hier zaehlt allein, dass alle Systeme an demselben Massstab 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 fuehrt 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 Schnittstellenfaehigkeit beurteilt, tut sie das fuer alle Kandidaten.

Das bedeutet nicht, dass alle alles testen muessen – 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 ueber alle Systeme hinweg konstant bleibt. So stellen Sie sicher, dass Unterschiede in den Bewertungen tatsaechlich auf die Systeme zurueckgehen und nicht auf den Wechsel des Beobachters. Bewaehrt hat sich, kritische Prozesse von zwei Personen unabhaengig bewerten zu lassen und das ebenfalls bei jedem System gleich zu handhaben – decken sich die Urteile, gewinnt der Vergleich an Stabilitaet; 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 staerker, als den meisten bewusst ist. Das zuerst getestete System setzt den Massstab, an dem alles Weitere unbewusst gemessen wird – ein Anker, von dem man sich kaum loest. Das zuletzt getestete System bleibt am frischesten in Erinnerung und profitiert davon, dass die Tester inzwischen geuebter sind und die Aufgaben routinierter loesen. Wer drei Systeme nacheinander prueft, vergleicht also nicht nur drei Produkte, sondern auch drei verschiedene Reifegrade der eigenen Vertrautheit mit der Aufgabe.

Vollstaendig ausschalten laesst sich dieser Effekt nicht, aber abmildern. Eine Moeglichkeit 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 Massnahme ist eine bewusste Aufwaermphase 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 waehrend ihrer. Drittens hilft eine zeitliche Naehe der Tests – mehrere Systeme innerhalb einer ueberschaubaren Spanne zu pruefen, vermeidet, dass das zuerst getestete System nur deshalb schlechter abschneidet, weil seine Eindruecke schon verblasst sind. Und viertens sollten Sie Reihenfolge-Effekte zumindest dokumentieren: Wer wann welches System getestet hat, gehoert ins Protokoll, damit Sie bei knappen Ergebnissen einschaetzen koennen, ob die Reihenfolge eine Rolle gespielt haben koennte.

Ergebnisse normalisieren und gewichten

Auch bei sorgfaeltigem Aufbau bleiben Rohwerte selten unmittelbar vergleichbar. Hat ein strenger Tester durchgaengig 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 zusammengefuehrt werden – etwa indem man die Bewertungen je Tester auf ein gemeinsames Niveau bezieht, statt absolute Punktstaende naiv zu addieren. So zaehlt, wie ein Tester die Systeme relativ zueinander eingestuft hat, und nicht, ob er generell zu Strenge oder Milde neigt. Der Aufwand dafuer 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 fuer Ihr Unternehmen gleich wichtig: Wer den Schwerpunkt im Lager und in der Logistik hat, gewichtet die entsprechenden Testfaelle hoeher als etwa die Anlagenbuchhaltung. Wichtig ist nur, dass die Gewichte vor dem Test festgelegt werden und fuer 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 ausgefuehrt. Fuer das vergleichende Testdesign genuegt der Grundsatz: erst normalisieren, dann mit unveraenderlichen Gewichten verrechnen.

Eine letzte, oft unterschaetzte Massnahme schuetzt vor dem maechtigsten Stoerfaktor ueberhaupt – der Sympathie fuer einen Anbieter und der Ueberzeugungskraft seiner Verkaeufer. Trennen Sie die Bewertung der Software sauber von der Bewertung des Anbieters. Beides ist wichtig, aber beides gehoert in getrennte Spalten: Wie gut die Aufgaben im System gelingen, ist eine Frage; wie kompetent, sympathisch oder verkaufsstark der Anbieter auftritt, eine voellig andere. Werden beide Eindruecke vermischt, faerbt das Charisma des Vertriebs unbemerkt auf die Bewertung der Funktionen ab. Halten Sie die Tester ausserdem dazu an, ihre Wertung waehrend oder unmittelbar nach dem eigenen Durchspielen der Testfaelle abzugeben – nicht erst nach einer eindrucksvollen Abschlusspraesentation, deren Glanz die nuechterne Erinnerung an die eigenen Klickwege ueberstrahlt.

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 standhaelt, und einem Bauchgefuehl, das sich im Nachhinein nicht mehr begruenden laesst. Wenn Sie identische Testfaelle auf einem gemeinsamen Datensatz mit denselben Testern, einer geeichten Skala und kontrollierter Reihenfolge durchspielen und die Ergebnisse anschliessend sauber normalisieren und mit vorab festgelegten Gewichten verrechnen, erhalten Sie etwas, das aus blossen Eindruecken 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 begruendete Rangfolge und schliesslich die Wahl des passenden Systems wird, fuehren die Bewertungsmethodik und die uebergeordnete Darstellung zur ERP-Auswahl aus. Das vergleichende Testdesign liefert das saubere Datenmaterial; die Auswahlmethodik formt daraus das Urteil. Wer beide Schritte trennt und jeden fuer sich sorgfaeltig ausfuehrt, vergleicht am Ende tatsaechlich Aepfel mit Aepfeln – und entscheidet auf einer Grundlage, die auch in einem Jahr noch trägt.

Was die Testphase kostet, dauert und an Risiken birgt

Eine Testphase fuehlt sich auf den ersten Blick kostenlos an. Das Trial-System ist umsonst oder fuer wenige Wochen freigeschaltet, die CRONUS-Demo kostet keinen Cent, und niemand schreibt eine Rechnung dafuer, dass jemand ein paar Auftraege probehalber erfasst. Genau diese scheinbare Kostenfreiheit ist der gefaehrlichste 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 ausschliesslich die wirtschaftliche und zeitliche Dimension des Testens selbst: Welche Kosten entstehen tatsaechlich, 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 waehlen –, sondern allein um die Steuerung der Wirtschaftlichkeit und der Risiken waehrend 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 geklaert sind, und richten den Blick auf das Budget und die Fallstricke.

Der unsichtbare Kostenblock: interner Personalaufwand

Der mit Abstand groesste Kostenblock einer Testphase ist der interne Personalaufwand – und er ist gerade deshalb so tueckisch, weil er nirgends als Ausgabe gebucht wird. Wenn eine Key-Userin aus der Auftragsbearbeitung mehrere halbe Tage damit verbringt, ihre realen Arbeitsablaeufe im Testsystem nachzustellen, dann kostet das genauso viel wie jede andere Arbeitszeit dieser Person – nur dass in dieser Zeit keine produktive Wertschoepfung 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 fliessen, ohne dass jemals eine Position dafuer in einer Kostenstelle auftaucht.

Wer den wirtschaftlichen Rahmen einer Evaluierung ehrlich abschaetzen will, sollte diesen internen Aufwand sichtbar machen, statt ihn unter den Teppich zu kehren. Eine einfache Ueberschlagsrechnung genuegt: Summieren Sie die geschaetzten 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 enthaelt. Das Ergebnis ist keine prazise Zahl, aber eine Groessenordnung – und diese Groessenordnung schuetzt vor der Illusion, ein Test sei "umsonst". Sie hilft auch, den Aufwand ins Verhaeltnis zur spaeteren Entscheidung zu setzen: Eine Investition in eine ausgewachsene ERP-Loesung rechtfertigt einen ernsthaften Test, weil eine Fehlentscheidung um ein Vielfaches teurer waere. Eine kleine, gut umrissene Anschaffung dagegen verträgt nur einen schlanken Test, sonst uebersteigt der Pruefaufwand den Nutzen.

Externe Kosten: Beratung und Einrichtung beim partnergestuetzten PoC

Neben dem internen Aufwand koennen externe Kosten hinzukommen, sobald ein Implementierungspartner in die Testphase eingebunden wird. Viele Anbieter und ihre Partner bieten an, ueber 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 partnergestuetzter 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 waehrend des Tests werden als Beratungsleistung in Rechnung gestellt.

Hier ist Klarheit vor Beginn entscheidend. Lassen Sie sich vorab schriftlich erlaeutern, 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 spaeter mit dem Projekt, falls es zustande kommt; andere stellen sie unabhaengig vom Ausgang in Rechnung. Beide Modelle koennen 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 Klaerung dieser Frage gehoert zu einem professionellen ERP-Consulting und sollte Teil der Vereinbarung sein, bevor die erste Datei eingespielt wird.

Opportunitaetskosten: was waehrend des Tests nicht geschieht

Der dritte, am haeufigsten uebersehene Kostenfaktor sind die Opportunitaetskosten. 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 Kapazitaeten: Fuer einen aussagekraeftigen Test brauchen Sie gerade die Personen, die ihren Bereich am besten kennen – also genau jene, die im Tagesgeschaeft am unentbehrlichsten sind. Die Auftragssachbearbeiterin, die jeden Sonderfall im Schlaf beherrscht, ist dieselbe, die waehrend ihrer Testzeit nicht die taeglichen Auftraege abarbeitet. Diese gebundene Arbeitszeit erzeugt keine direkte Ausgabe, aber sie kann zu Rueckstaenden, Verzoegerungen oder Mehrarbeit fuer Kolleginnen und Kollegen fuehren.

Daraus folgt eine schlichte, aber oft missachtete Konsequenz: Die Testphase muss bewusst und mit Augenmass terminiert werden. Eine Evaluierung mitten in der Hochsaison, kurz vor dem Jahresabschluss oder waehrend einer Personalengpass-Phase zu starten, vervielfacht die Opportunitaetskosten und fuehrt fast zwangslaeufig zu fluechtigen, unzuverlaessigen Ergebnissen, weil die Beteiligten innerlich beim Tagesgeschaeft bleiben. Wer den Aufwand realistisch plant, sucht ein Zeitfenster mit ausreichend Luft und stimmt die Freistellung der Tester mit deren Vorgesetzten ab. Opportunitaetskosten lassen sich nicht vermeiden, aber sie lassen sich steuern – durch kluge Terminierung und durch ein klar begrenztes Zeitbudget, das verhindert, dass sich der Test ueber Gebuehr in die Laenge 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 haeufig auf, und es lohnt sich, sie beim Namen zu nennen, damit man sie fruehzeitig erkennt.

Die endlose Testphase ohne Entscheidung. Das haeufigste Risiko ist eine Evaluierung, die nie zu einem Schluss kommt. Es findet sich immer noch eine weitere Funktion, die man "kurz" pruefen koennte, noch ein Szenario, noch eine Variante. Solange kein Abschlusskriterium definiert ist, fehlt der Anlass, einen Strich zu ziehen. Die Folge: Der Aufwand laeuft weiter, ohne dass sich der Erkenntnisgewinn entsprechend erhoeht, und die eigentliche Entscheidung wird immer weiter aufgeschoben.

Ueberladene Anforderungen. Wenn der Test versucht, jede denkbare Anforderung, jeden Sonderfall und jede Wunschfunktion abzudecken, wird er unbeherrschbar. Statt sich auf die geschaeftskritischen Prozesse zu konzentrieren, verzettelt sich das Team in einer endlosen Liste von Pruefpunkten, 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 prueft im Test zuerst und am gruendlichsten die Muss-Kriterien.

Verzettelung in Nebenfunktionen. Eng verwandt damit ist die Faszination fuer das Spektakulaere. Eine schicke Auswertung, eine elegante mobile App, eine clevere Automatisierung zieht die Aufmerksamkeit auf sich, waehrend die unscheinbaren, aber taeglich hundertfach genutzten Kernvorgaenge ungeprueft bleiben. Am Ende weiss man viel ueber Funktionen, die selten gebraucht werden, und wenig ueber die, an denen sich die taegliche Arbeit entscheidet.

Ablaufende Trial-Fristen. Trial-Versionen sind zeitlich befristet. Wer ohne Plan startet, riskiert, dass die Frist ablaeuft, bevor die wesentlichen Szenarien geprueft sind – und steht dann vor der Wahl, mit luckenhaften Erkenntnissen zu entscheiden oder eine neue, womoeglich kostenpflichtige Verlaengerung zu organisieren. Die Trial-Frist sollte deshalb von Anfang an als harte Randbedingung in die Planung eingehen, nicht als nachtraegliche Ueberraschung.

Pro und Contra einer intensiven, laengeren Testphase

Wie tief und wie lang eine Testphase sein sollte, ist eine echte Abwaegung – nicht "je mehr, desto besser". Eine intensive, ausgedehnte Evaluierung hat handfeste Vorteile, aber ebenso reale Kehrseiten. Die richtige Balance liegt zwischen oberflaechlichem Durchklicken und endlosem Pruefen.

Die Konsequenz aus dieser Gegenueberstellung ist nicht, sich fuer ein Extrem zu entscheiden, sondern die Intensitaet am Gewicht der Entscheidung auszurichten. Je groesser die geplante Investition und je tiefer das System in die Kernprozesse eingreift, desto eher rechtfertigt sich ein gruendlicher, laengerer Test. Bei einem ueberschaubaren 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 geoeffnet wird, sollte feststehen, welche geschaeftskritischen Prozesse zwingend geprueft werden muessen und welche nachrangig sind. Aus dieser Priorisierung leitet sich der Aufwand ab: Die Muss-Prozesse erhalten reservierte, geschuetzte Zeitfenster; die Kann-Prozesse werden nur geprueft, wenn nach Abschluss der Pflichtthemen noch Kapazitaet bleibt. So wird verhindert, dass die Nebensaechlichkeiten die Hauptsachen verdraengen.

Das Zeitbudget sollte zudem eine klare aeussere Grenze haben – einen Endtermin, der sich an der Trial-Frist, am verfuegbaren Zeitfenster der Beteiligten und am Entscheidungsdruck orientiert. Ein fester Endtermin wirkt disziplinierend: Er zwingt dazu, das Wesentliche zuerst zu pruefen, und schuetzt vor dem schleichenden Auswuchern. Bewaehrt hat sich, den Test in ueberschaubare Etappen zu gliedern – etwa eine Phase fuer die Kernprozesse, eine fuer die Schnittstellen und den technischen Unterbau, eine fuer die Auswertungssicht – und nach jeder Etappe kurz zu pruefen, ob das bisherige Bild fuer eine Entscheidung ausreicht. Diese Etappierung verhindert, dass der gesamte Aufwand in einen offenen Topf fliesst, und macht den Fortschritt sichtbar. Wer den Aufwand sauber plant, schafft damit zugleich die Grundlage fuer eine realistische Schaetzung der spaeteren ERP-Implementierung, denn die im Test gewonnenen Erkenntnisse ueber Anpassungsbedarf und Komplexitaet fliessen direkt in deren Kalkulation ein.

Wichtig ist schliesslich, das Budget nicht "nebenbei" zu vergeben. Die fuer den Test eingeplante Zeit muss mit den Vorgesetzten der Beteiligten abgestimmt und tatsaechlich freigeraeumt werden, sonst bleibt sie eine leere Zusage und die Tester quetschen die Pruefung zwischen ihre eigentlichen Aufgaben – mit den bekannten oberflaechlichen 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 zufaellig abgelaufen oder die Geduld erschoepft ist, sondern weil ein definierter Reifegrad erreicht wurde. Es lohnt sich, dieses Abschlusskriterium bereits zu Beginn festzulegen, statt es dem Gefuehl zu ueberlassen. Mehrere Signale zeigen verlaesslich an, dass der richtige Zeitpunkt gekommen ist.

Das wichtigste Signal ist die Saettigung des Erkenntnisgewinns: Wenn jede weitere Testaufgabe Ihr Bild nur noch bestaetigt, statt es zu veraendern, ist die Pruefung inhaltlich abgeschlossen. Ein zweites Signal ist die vollstaendige Abdeckung der Muss-Kriterien: Sobald alle geschaeftskritischen Prozesse durchgespielt und beurteilt sind, ist das Pflichtprogramm erfuellt – die verbleibenden Kann-Themen rechtfertigen selten eine Verlaengerung. Ein drittes Signal liefert die Frage, ob das Team eine begruendete, mehrheitlich getragene Einschaetzung abgeben kann: Wenn die Beteiligten ihr Urteil mit konkreten Beobachtungen statt mit vagen Eindruecken belegen koennen, liegt eine tragfaehige Basis vor. Und ein viertes, sehr praktisches Signal ist die nahende Trial- oder Budgetgrenze, die ohnehin zum Abschluss zwingt – idealerweise faellt sie mit der inhaltlichen Saettigung zusammen, weil der Test von vornherein darauf ausgerichtet war.

Umgekehrt sind klare Warnzeichen, dass die Phase laeuft, ohne abzuschliessen: Es werden immer neue Nebenfunktionen entdeckt, die noch "unbedingt" geprueft werden muessen; die Beteiligten verlieren spuerbar die Motivation und testen nur noch pflichtschuldig; oder es wird mehr ueber das Verlaengern der Frist diskutiert als ueber die eigentliche Entscheidung. Wer diese Zeichen erkennt, sollte aktiv einen Abschluss herbeifuehren, statt den Test treiben zu lassen. Denn das Ziel der Testphase ist nicht maximale Vollstaendigkeit, sondern ausreichende Sicherheit fuer die naechste Entscheidung – und sobald diese Sicherheit erreicht ist, kostet jeder weitere Tag nur noch, ohne zu nuetzen. Wie Sie aus den so gewonnenen, gut budgetierten Erkenntnissen die konkrete Auswahlentscheidung ableiten, fuehrt 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