Sie sehen eine Möglichkeit, Ihr Geschäft zu verbessern. Noch ist offen, ob die vorhandenen Daten ausreichen, wie die Lösung im Alltag genutzt würde und welcher Aufwand gerechtfertigt ist. Ein Pilot macht diese Fragen an einer begrenzten, nutzbaren Lösung prüfbar. Sein Ergebnis soll Ihnen eine fundierte Entscheidung über den weiteren Aufbau ermöglichen.
Eine Demo zeigt, wie eine Lösung aussehen oder funktionieren könnte. In einem Pilot wird ein begrenzter Teil mit den Beteiligten praktisch erprobt. Dabei können bereits Grundlagen für das spätere Projekt entstehen: geklärte Daten und Regeln, geeignete Testfälle und nutzbare Teile der Umsetzung. Diese Arbeit muss bei einer Fortsetzung nicht vollständig neu begonnen werden.
Eine Frage wählen, die sich praktisch beantworten lässt
„Wir möchten unsere Daten besser nutzen“ gibt eine Richtung vor, aber noch keinen prüfbaren ersten Umfang. Konkreter wäre: Kann eine morgendliche Liste der blockierten Bestellungen der Versandkoordination helfen, noch vor der Abholung die richtigen Hindernisse zu klären?
Für einen solchen Einstieg werden der betroffene Ablauf, die Nutzer, die benötigten Daten und das erwartete Arbeitsergebnis festgelegt. Eine erste Version könnte die Liste mit den betroffenen Bestellungen und erfassten Hindernissen liefern. Automatische Umbuchungen oder eine neue Lagerverwaltung gehören nicht zu diesem ersten Test.
Sie müssen dafür keine fertige Spezifikation mitbringen. Corvendor hilft, aus Ihrem Ziel einen überschaubaren ersten Umfang zu entwickeln. Beim Erproben werden Anforderungen genauer; Änderungen an Umfang, Aufwand und Kriterien werden gemeinsam festgehalten.
Ein Beispiel: Die Liste stimmt — kommt aber zu spät
Das folgende Beispiel ist erfunden. Es beschreibt eine mögliche Erkenntnis aus einem Pilot, kein Ergebnis eines Corvendor-Projekts.
Ein Händler erprobt eine Liste blockierter Bestellungen für die Versandkoordination. In den ausgewählten Testfällen ordnet die Pilotversion die Bestellungen und erfassten Hindernisse richtig zu. Die Fachleute können die Angaben zu den Quelldaten zurückverfolgen. Bei der Erprobung im Ablauf wird jedoch sichtbar: Der verfügbare Datenexport kommt erst nach der täglichen Paketabholung. Die Liste wäre fachlich brauchbar, erreicht das Team aber zu spät für die gewünschte Handlung.
Die nächste Frage lautet deshalb, ob die erforderlichen Statusdaten früher bereitgestellt werden können. Corvendor und die IT prüfen den Zugang; die Versandkoordination klärt, bis wann sie die Hinweise tatsächlich braucht. Danach kann die geänderte Datenbereitstellung erneut erprobt werden. Ist ein rechtzeitiger Zugang mit vertretbarem Aufwand nicht möglich, muss der Umfang geändert oder das Vorhaben in dieser Form beendet werden.
Der Pilot hat damit etwas Entscheidendes geklärt: Richtige Angaben allein reichen nicht. Sie müssen rechtzeitig ankommen und eine sinnvolle Handlung ermöglichen. Eine ansprechende Demonstration hätte diese Voraussetzung leicht offenlassen können.
Vor dem Test festlegen, woran Sie den Nutzen erkennen
Im Beispiel geht es darum, ob das Team blockierte Bestellungen früher sinnvoll bearbeiten kann. Für die Bewertung könnten folgende Fragen vorab vereinbart werden:
- Richtig: Werden relevante Hindernisse erkannt, und welche fehlen oder werden falsch zugeordnet?
- Rechtzeitig: Liegt der Hinweis vor dem Zeitpunkt vor, zu dem das Team noch eingreifen kann?
- Nutzbar: Versteht die zuständige Person die Angaben und kann sie von dort aus weiterarbeiten?
- Wirtschaftlich sinnvoll: Wie viel Sucharbeit entfällt, und wie viel Aufwand entsteht für Prüfung, Korrekturen und Pflege?
Das Team hält fest, wie es heute dieselben Aufgaben erledigt. So entsteht eine Vergleichsgrundlage. Für den vereinbarten Umfang werden auch die Entscheidungsgrenzen beschrieben: Welche Fehler sind nicht akzeptabel, welcher Zusatzaufwand wäre zu hoch, und welche Unsicherheit darf vor einer Fortsetzung noch offen sein?
Die Kriterien werden vor der Bewertung festgelegt. Neue Erkenntnisse können eine Anpassung begründen; die Änderung sollte sichtbar bleiben. Einzelne gut funktionierende Beispiele reichen nicht, um einen verlässlichen Regelbetrieb oder eine allgemeine Ergebnisverbesserung zu belegen.
Mit geeigneten Fällen und den späteren Nutzern erproben
Der Test braucht typische Fälle und die Ausnahmen, an denen eine Lösung scheitern könnte: fehlende Angaben, widersprüchliche Statusmeldungen oder kurzfristige Änderungen. Ihre Fachleute erläutern, welche Behandlung sie erwarten und warum. Sie prüfen auch die Fälle, bei denen die Pilotversion unsicher ist oder eine manuelle Bearbeitung vorsieht.
Freigegebene historische Beispiele können einen Einstieg ermöglichen. Wenn zunächst nur künstliche Beispiele verfügbar sind, lassen sich damit Darstellung und Ablauf besprechen; eine verlässliche Aussage zur Leistung mit echten Daten folgt daraus nicht. Für die Bewertung sollten auch Fälle verwendet werden, die nicht bereits zur Anpassung der Lösung dienten.
Vor der Erprobung werden Testumgebung, Datenzugriff, Verantwortlichkeiten und der Umgang mit Ergebnissen vereinbart. Corvendor entwickelt die Pilotversion und macht Annahmen und Befunde nachvollziehbar. Fachbereich und Operations beurteilen Nutzen und Ausnahmen; die IT klärt die technischen Voraussetzungen. Der Sponsor sorgt dafür, dass die nötigen Ansprechpartner und Entscheidungen verfügbar sind.
Was aus dem Pilot bleibt
Zum Abschluss sollten Sie die vereinbarte Pilotversion, die Prüfergebnisse und die offenen Punkte gemeinsam durchgehen können. Neben der Entscheidung über die Fortsetzung können konkrete Arbeitsergebnisse für den weiteren Aufbau nutzbar bleiben. Je nach vereinbartem Umfang gehören dazu:
- Fachliche Grundlagen: Geklärte Datenfelder, Statusdefinitionen, Regeln und Zuständigkeiten.
- Material für weitere Tests: Geeignete, zur weiteren Nutzung freigegebene Beispielfälle, Prüfkriterien und dokumentierte Ergebnisse.
- Teile der Umsetzung: Erprobte Datenaufbereitung, Regeln, Schnittstellenentwürfe oder geeignete Softwarebausteine.
- Grundlagen für die Fortsetzung: Präzisierte Anforderungen, bekannte Grenzen und noch zu klärende Abhängigkeiten.
Im Versandbeispiel könnten die vereinbarten Bestellstatus, die Regeln für die Liste und die Testfälle weiterverwendet werden, auch wenn der provisorische Datenexport durch eine frühere Datenanbindung ersetzt werden muss. Wiederverwendung betrifft also sowohl fachliche Arbeit als auch geeignete technische Bestandteile. Welche Ergebnisse übergeben und wie sie weiter genutzt werden können, wird für das Vorhaben vereinbart. Nicht jeder Prototypbaustein ist bereits für den laufenden Betrieb geeignet.
Drei Entscheidungen sind möglich:
- Fortsetzen: Der Nutzen ist für den getesteten Umfang erkennbar; die wesentlichen Voraussetzungen für den nächsten Schritt sind geklärt.
- Anpassen und erneut prüfen: Eine konkrete Änderung, etwa ein früherer Datenzugang, könnte die verbleibende Hürde lösen.
- In dieser Form beenden: Daten, Handlungsmöglichkeiten oder erwarteter Nutzen rechtfertigen den weiteren Aufbau nicht.
Auch eine begründete Entscheidung gegen die Fortsetzung kann nützlich sein. Sie begrenzt weitere Investitionen und hält fest, was gelernt wurde. Sie ersetzt allerdings nicht das Ziel, im Pilot eine tatsächlich prüfbare Lösung zu erarbeiten.
Den Übergang in den Alltag gesondert planen
Bei Fortsetzung wird festgelegt, was aus dem Pilot übernommen werden kann und was für den laufenden Einsatz ergänzt werden muss. Dazu können verlässliche Datenlieferungen, Zugriffe, Integration, Fehlerbehandlung, Übergabe und Zuständigkeiten für Änderungen gehören. Wartung und Unterstützung werden konkret vereinbart.
Ein hilfreicher Test rechtfertigt zunächst den nächsten passenden Schritt, nicht automatisch den Einsatz in allen Bereichen. Umfang, Dauer und Aufwand richten sich nach den offenen Fragen und Abhängigkeiten. Die allgemeinen Schritte der Zusammenarbeit beschreibt unsere Seite zum Vorgehen.
Ein guter Pilot macht sichtbar, was funktioniert, was noch fehlt und warum der nächste Schritt sinnvoll ist — auch wenn dieser Schritt eine Anpassung oder ein Ende des Vorhabens ist.
