Pilotprojekt zur Inventarverwaltung: erst testen, dann einführen

Sie haben Ihr System zur Inventarverwaltung gewählt. Die Einführung ist geplant. Nächsten Montag legen Sie den Schalter für alle um: fünf Standorte, 500 Leute.

Lassen Sie das.

Ich habe UNIO24 gebaut, weil ich genau diese Szene immer wieder gesehen habe. Ein Team wählt ein Werkzeug, plant die Einführung und streicht das Pilotprojekt, weil „wir dafür keine Zeit haben“. Dann flickt es sechs Monate lang im laufenden Betrieb am System, während die Leute still zum Klemmbrett zurückkehren. Die Teams, die sich zwei Wochen Pilotphase nehmen, starten meist sauber. Das Muster ist brutal beständig.

Ich zeige Ihnen ein Pilotprojekt, das die echten Probleme findet: das WLAN, das nicht bis dorthin reicht, wo die Geräte wirklich stehen, die Etiketten, die nach zwei Wochen verblasst sind, den Ablauf, der 5 Minuten dauert statt 30 Sekunden. Klein testen, die Probleme finden, solange sie billig sind, dann ein System ausrollen, dem das Risiko schon genommen ist.

Warum ein Pilotprojekt keine Kür ist

Ein Pilotprojekt fühlt sich nach Bürokratie an. In Wahrheit ist es Risikobegrenzung, die sich als Formalität verkleidet.

Ein gutes Pilotprojekt leistet fünf Dinge. Es zeigt technische Probleme, bevor sie zur Katastrophe werden: ob das Lager-WLAN wirklich bis in die hintere Ecke reicht, ob der Server 50 gleichzeitige Scans verkraftet, ob Ihre Etiketten die Umgebung überstehen, in der sie tatsächlich kleben. Es deckt unerwartete Probleme im Ablauf auf, die erst auftauchen, wenn jemand mit Handschuhen scannt oder Laptops in der Dockingstation erfasst werden müssen. Es gibt Ihnen eine Rückmeldeschleife, solange Sie noch das System wechseln, Ihre Etikettierstrategie anpassen oder Ihre Datenstruktur umbauen können. Nach der vollen Einführung sitzen Sie fest. Es schafft Fürsprecher, denn wer den Ablauf im Pilotprojekt mitgeformt hat, verteidigt ihn später bei der Einführung. Und es belegt den Nutzen, bevor der große Scheck unterschrieben wird, und genau das braucht eine skeptische Geschäftsführung.

Das Risiko einer Einführung verschwindet nicht, wenn Sie es ignorieren. Es kommt später, in schlimmerer Form und vor mehr Zeugen. Wer die Gesamtbetriebskosten (TCO) wirklich versteht, rechnet dieses Risiko von Anfang an mit.

Welches Pilotprojekt: Abteilung, Standort oder beides?

„Von allem ein bisschen“ lässt sich nicht pilotieren, das ist eine halbgare Einführung. Für einen ordentlichen Test brauchen Sie einen Umfang, der repräsentativ genug ist, um Ihre Annahmen zu prüfen, und klein genug, um beherrschbar zu bleiben.

Drei Zuschnitte taugen etwas.

Eine Abteilung, alle Standorte. Die gesamte IT-Ausstattung im ganzen Unternehmen, sonst nichts. Das passt, wenn Ihre Abläufe an allen Standorten gleich sind und eine Objektklasse eigene Anforderungen hat (IT, Fahrzeuge). Der Haken: Sie testen nicht, wie das System mit Vielfalt umgeht. Büromöbel verhalten sich anders als Elektrowerkzeug.

Ein Standort, alle Objektarten. Alles in der Zentrale, nirgends sonst. Das passt, wenn sich die Standorte stark unterscheiden (Büro, Lager, Baustelle) und Sie die ganze Bandbreite testen wollen. Der Haken: Ihnen entgehen standortspezifische Probleme wie das Funkloch im Lager.

Gemischt. Ein repräsentativer Standort plus zwei oder drei Objektklassen, die verschiedene Einsatzfälle abdecken. Zum Beispiel: Zentrale + IT-Geräte + Büromöbel + Werkzeug. So haben Sie Vielfalt (teuer und billig, mobil und ortsfest, ständig weitergegeben und selten bewegt), ohne sich zu übernehmen. Diesen Zuschnitt würde ich für die meisten Organisationen wählen, ob für das Inventar einer Kirchengemeinde oder eines Vereins oder die Gebäudetechnik einer Hausverwaltung.

Woran Sie einen guten Pilotstandort erkennen

Nehmen Sie einen Standort, der für Ihre Organisation typisch ist (weder der einfachste noch der schwierigste), für die Fehlersuche gut erreichbar, mittelgroß (groß genug für echte Probleme, klein genug, um sie zu bewältigen) und mit Leuten, die mitmachen wollen. Widerwillige Pilotnutzer bringen das Projekt zu Fall.

Lassen Sie Ihren kleinsten, einfachsten Standort aus, er zeigt nicht, wie kompliziert der Alltag ist. Den chaotischsten auch, dort erzeugen Sie nur Frust. Meiden Sie entfernte Standorte, an die Sie nicht selbst hinkommen. Und pilotieren Sie nirgends, wo gerade ein großer Umbruch läuft: Umzug, Umstrukturierung, Wechsel in der Leitung.

Wie viele Objekte

Meine Faustregel:

Untergrenze: mindestens 50 Objekte und 5 aktive Nutzer. Darunter passiert zu wenig, um echte Abläufe zu testen. Obergrenze: höchstens 10 % Ihres gesamten Bestands. Alles darüber ist eine volle Einführung unter anderem Namen.

Den Umfang festlegen

„Probieren wir es mal aus und schauen, was passiert“ ist kein Plan. Ein vager Umfang liefert vage Ergebnisse. Legen Sie vier Dinge ausdrücklich fest.

Was Sie testen. Welche Objektklassen dazugehören (Laptops, Monitore, Schreibtische, Bürostühle) und welche nicht. Schreiben Sie beide Listen aus, damit niemand etwas annimmt. Die Grenzen des Standorts (Gebäude A, Stockwerke 1–3, mit Lagerraum, aber ohne Rechenzentrum). Die Nutzergruppen (Büroleitung, IT, Haustechnik, aber nicht die übrige Belegschaft).

Was Sie messen. Die Erfolgskriterien legen Sie vor dem Start fest: Suchzeit pro Objekt, Anteil der Objekte mit nachweisbarer Zuständigkeit, Akzeptanz bei den Nutzern, Fehlerquote bei der Dateneingabe, Zeit für Aufgaben rund um die Objekte. Die Zahlen dazu folgen unten bei den Kennzahlen.

Welche Abläufe Sie testen. Nicht nur die Software, sondern den ganzen Ablauf. Die Aufnahme neuer Objekte, das Etikettieren, Ausgabe und Rücknahme, Übergaben, die Aussonderung und, ja, auch die Inventur während des Pilotprojekts selbst.

Was Sie noch NICHT testen. Anbindungen an andere Systeme (erst bei der vollen Einführung). Aufwendige Berichte (erst das Wesentliche). Fortgeschrittene Funktionen, die Sie nicht sofort brauchen. Anpassungen, von denen Sie nicht wissen, ob Sie sie brauchen. Am letzten Punkt sterben Pilotprojekte an schleichender Ausweitung: „Wenn wir schon dabei sind, könnten wir doch auch …“ Wer bei null anfängt und heute mit Tabellen arbeitet, findet den Umstieg von der Tabelle auf eine Software zur Inventarverwaltung in einem eigenen Leitfaden.

Zeitplan: wie lange ein Pilotprojekt wirklich laufen sollte

Unter zwei Wochen finden Sie die offensichtlichen technischen Fehler, verpassen aber die Probleme im Ablauf, die erst mit der Zeit kommen, und niemand entwickelt echte Gewohnheiten. Über drei Monate verpufft der Schwung: Alle vergessen, dass es ein Test ist, und behandeln ihn als Dauerzustand, der halt nicht richtig funktioniert.

Für die meisten Organisationen passen vier bis acht Wochen.

Die Wochen 1–2 gehören der Einrichtung und den ersten Schritten: System konfigurieren, Pilotobjekte etikettieren, Anfangsdaten importieren oder eingeben, Nutzer schulen und sie an echte Arbeit setzen. Sie achten auf technische Fehler, grundlegende Bedienprobleme und Rückmeldungen der Sorte „dieser Knopf geht nicht“.

Die Wochen 3–5 sind der Test im Alltag. Das System läuft täglich mit echten Abläufen, erste Probleme im Prozess werden sichtbar, und Sie sehen, welche Funktionen genutzt und welche ignoriert werden. Sie achten auf Reibung im Ablauf, fehlende Funktionen, Lücken in der Schulung und Probleme mit der Datenqualität.

Die Wochen 6–8 sind die Auswertung. Rückmeldungen strukturiert einsammeln, Nutzungsdaten auswerten, Ihre Anpassungen testen, eine kleine Inventur zur Datenqualität fahren und die Go/No-Go-Entscheidung treffen. Sie achten darauf, ob die Verbesserungen gehalten haben und ob das System das eigentliche Problem löst.

Wenn Sie verkürzen müssen

Manchmal schert sich der Kalender nicht um den idealen Zeitplan: Die Jahresinventur steht in sechs Wochen an, eine Behörde macht Druck, die Geschäftsführung wird ungeduldig. Zwei bis drei Wochen können funktionieren, aber nur mit freigestellten Leuten, einer erfahrenen Projektleitung und schlichten Anforderungen:

• Woche 1: Einrichtung, Schulung und erste Tests, alles im Schnelldurchgang.
• Woche 2: voller Betrieb mit täglicher Abstimmung.
• Woche 3: Rückmeldungen schnell einsammeln und entscheiden.

Komplexe Umgebungen verkürzen Sie nicht. Das Pilotprojekt soll Probleme finden. Weniger Zeit heißt weniger Funde.

Erfolgskriterien: messen, was wirklich zählt

„Hat das Pilotprojekt funktioniert?“ ist eine nutzlose Frage. Sie brauchen konkrete, messbare Kriterien, festgelegt vor dem Start. Hier steht, was Sie verfolgen und welche Zahlen Sie anpeilen.

Technische Leistung

Das System muss zuverlässig laufen. Peilen Sie mindestens 99 % Verfügbarkeit an. Kommen die Leute regelmäßig nicht hinein, haben Sie schon verloren. Ein Scan mit dem Handy sollte in unter drei Sekunden vom QR-Code zu den Objektdaten führen. Dauert es länger, finden die Leute Ausreden, nicht zu scannen. Der heimliche Killer ist die Synchronisierung: Prüfen Sie, ob Scans ohne Netz wirklich ankommen, sobald das Handy wieder online ist. Verlorene Scans heißen verlorene Daten, und verlorene Daten heißen verlorenes Vertrauen. Das kommt nicht so leicht zurück.

Akzeptanz bei den Nutzern

Ziel: 80 % oder mehr der Pilotnutzer arbeiten jede Woche aktiv mit dem System. Verfolgen Sie Anmeldungen und Buchungen pro Person. Macht die Hälfte Ihrer Pilotnutzer nicht mit, zerschellt die volle Einführung am ersten Kontakt mit normalen Menschen.

Ob der Prozess eingehalten wird, sagt Ihnen, ob das System zum Ablauf passt. Vergleichen Sie, was physisch passiert, mit dem, was im System steht. Tauchen 90 % oder mehr der Übergaben nicht im System auf, arbeiten die Leute am Werkzeug vorbei. Dann ist Ihr Prozess kaputt, und Sie reparieren ihn jetzt.

Die Einarbeitungszeit ist die Kennzahl zur Abnahme durch die Nutzer, die mir am wichtigsten ist. Grundlegende Aufgaben sollten die Leute nach zwei Tagen allein erledigen. Brauchen sie nach der ersten Woche noch Händchenhalten, stimmt etwas mit der Oberfläche oder der Schulung nicht.

Wirkung im Betrieb

Die Suche nach Objekten sollte mindestens 50 % weniger Zeit kosten. Lassen Sie die Leute vorher und nachher schätzen. Wenn das System das Finden nicht schneller macht, wozu dann das Ganze.

Nachweisbare Zuständigkeit: Für 95 % oder mehr der Pilotobjekte sollten Standort und zuständige Person bekannt sein. Prüfen Sie das zum Schluss mit einer Inventur. Wissen Sie nach dem Pilotprojekt nicht, wo Ihre Objekte sind und wer sie hat, wissen Sie es nach der Einführung auch nicht.

Beispiel aus UNIO24: ein Pilotverzeichnis mit Präfixen nach Objektklasse (IT- für IT-Geräte, TN- für Transport, MB- für Möbel). Jede Zeile hat einen Inhaber in der Spalte „Holder“: einen Standort wie Warehouse #2, einen Servicedienstleister wie Universal IT Service oder eine Person mit ihrer Abteilung. Die Status verteilen sich auf ungenutzt, aktiv und in Wartung. So sehen 95 % und mehr nachweisbare Zuständigkeit aus: Leere Zellen bei „Holder“, fehlende Präfixe oder veraltete Daten in der Spalte „Updated“ sind die Stellen, an denen Sie zum Schluss nachbohren.

Datengenauigkeit: 95 % oder mehr. Standort, Status und Zuordnung stimmen, wenn Sie vor Ort nachsehen. Datenmüll im Pilotprojekt wird Datenmüll im laufenden Betrieb. Zählen Sie außerdem mit, welche Objekte wieder auftauchen. „Verschwundene“ Dinge wiederzufinden bezahlt das Pilotprojekt und verkauft die Einführung.

Zufriedenheit der Nutzer

Mindestens 70 % der Pilotnutzer sollten die Einführung empfehlen. Tun das nicht einmal Ihre begeisterten ersten Nutzer, ist etwas wirklich kaputt. Bei Umfragen sollte die gefühlte Bedienbarkeit im Schnitt bei 4 von 5 oder höher liegen. Und am meisten zählt der gefühlte Nutzen: Hören Sie auf Sätze wie „damit kann ich meine Arbeit besser machen“. Wenn die Leute das System als Beschäftigungstherapie sehen, hilft keine Schulung der Welt. Dann ist es ein Problem des Veränderungsmanagements.

Rückmeldungen sammeln: die richtigen Fragen zur richtigen Zeit

Warten Sie nicht bis zum Schluss, um zu fragen, wie es läuft. Bis dahin haben frustrierte Nutzer innerlich längst abgeschaltet.

In der ersten Woche reden Sie täglich fünf Minuten mit den Leuten oder fragen kurz in Slack nach: Was verwirrt, wo hängen sie fest, was dauert länger als nötig, gibt es Fehlermeldungen? Tägliche Rückmeldung ist hier Pflicht. Ein verwirrender Knopf, der pro Scan 30 Sekunden kostet, kostet über die ganze Pilotphase 500 Minuten. Beheben Sie ihn sofort. (Das gehört zu den Fehlern in der Inventarverwaltung, die ich am häufigsten sehe: Korrekturen „bis zur Einführung“ aufschieben.)

In den Wochen 2–3 wechseln Sie zu kurzen Wochenumfragen: höchstens fünf Fragen, zwei Minuten Aufwand. Bedienbarkeit von 1 bis 5, die Aufgabe, die diese Woche am längsten dauerte, was die Leute ändern würden, welche Funktion fehlt, dazu ein freies Feld für alles, woran Sie nicht gedacht haben. So werden Trends sichtbar. Wenn drei Leute unabhängig voneinander nach derselben Funktion fragen, ist sie wichtig.

In den Wochen 4–6 folgen Einzelgespräche von 15–30 Minuten mit repräsentativen Nutzern. Gehen Sie ihren typischen Arbeitsablauf durch. Wo hilft das System, wo stört es, sind sie produktiver oder nicht, wollen sie weiter damit arbeiten, was würde es hervorragend statt passabel machen? Umfragen liefern Daten. Gespräche liefern Verständnis: warum etwas ein Problem ist, nicht nur, dass es eines ist.

Zum Schluss gibt es eine Abschlussumfrage und eine gemeinsame Nachbesprechung. Die Umfrage fragt nach der Gesamtzufriedenheit (1–10), Einführung empfehlen ja/nein, den drei Dingen, die am besten funktionieren, den drei, die Nachbesserung brauchen, und Bedenken gegen die breite Einführung. Der eigentliche Wert steckt in der Nachbesprechung. Holen Sie die Pilotnutzer zusammen und lassen Sie sie miteinander reden, nicht mit Ihnen. Ihre Gespräche (Erfahrungen vergleichen, über Lösungen streiten, Ideen weiterspinnen) zeigen, was keine Umfrage erfasst.

Eine Frage würde ich in jedes Pilotprojekt aufnehmen: „Wenn wir das morgen im ganzen Unternehmen einführen, würden Sie sich dann eher freuen oder wären Sie eher besorgt?“ Sie schneidet durch die Höflichkeit und zeigt die echte Stimmung. Wenn Ihre ersten Nutzer (das wohlwollendste Publikum, das Sie je haben werden) besorgt sind, sind Sie noch nicht so weit.

Probleme, auf die Sie stoßen werden

Jedes Pilotprojekt, das ich je verfolgt habe, fördert eine Variante derselben Handvoll Probleme zutage. Sie vorher zu kennen verhindert sie nicht, verkürzt aber die Zeit, in der Sie ratlos sind.

Das WLAN reicht nicht dorthin, wo die Objekte stehen. In manchen Bereichen kann niemand scannen, weil kein Netz da ist. Funktioniert das Scannen nicht dort, wo die Geräte wirklich sind, ist das System nutzlos. Die Lösung: ein Offlinemodus (moderne Apps haben einen), zusätzliche Access Points in wichtigen Bereichen oder Geräte mit Mobilfunk für wirklich abgelegene Stellen. So oder so: Testen Sie in der echten Umgebung, nicht im Büro. WLAN-Heatmaps lügen.

Eine Übergabe zu buchen dauert zu lange. Ist der digitale Ablauf langsamer als der alte, scheitert die Akzeptanz. Finden Sie die langsamen Schritte, statt sie zu vermuten. Streichen Sie überflüssige Formularfelder (brauchen Sie wirklich alle 15 für eine Übergabe?). Schalten Sie Sammelaktionen frei, damit zehn Dinge auf einmal übergeben werden statt eines nach dem anderen. Lassen Sie scannen statt tippen, wo immer es geht. Stoppen Sie jeden Routineablauf mit der Uhr; braucht er mehr als drei Klicks und 30 Sekunden, vereinfachen Sie ihn, bis er es nicht mehr tut.

Etiketten lösen sich, verblassen oder scannen nicht mehr. Die Etiketten überstehen ihre Umgebung nicht. Lässt sich das Etikett nicht scannen, lässt sich das Objekt nicht verfolgen, und die Mühe war umsonst. Testen Sie die Haltbarkeit unter echten Bedingungen: Kleben Sie ein Etikett auf ein Gerät und schauen Sie es sich nach zwei Wochen an. Wechseln Sie von Papier zu Polyester, nehmen Sie Metallschilder für raue Umgebungen und ein Schutzlaminat für Objekte draußen oder mit viel Betrieb. NFC lohnt einen Blick bei Metalloberflächen oder Kontakt mit Chemikalien, wo gedruckte Codes nicht überleben. Der Leitfaden Inventar richtig etikettieren geht ausführlich darauf ein, und der Vergleich QR-Code, NFC oder RFID hilft bei der Wahl.

Die Leute wissen nicht, welche Kategorie die richtige ist. „Ist eine kabellose Tastatur IT-Ausstattung oder Bürobedarf?“ Uneinheitliche Kategorien ruinieren Berichte und machen die Suche unmöglich. Bauen Sie einen einfachen Entscheidungsbaum („Hat es einen Stecker → IT. Sitzt jemand darauf → Möbel. Hat es einen Motor → Geräte.“). Senken Sie die Zahl der Kategorien: zehn sind besser als siebenundvierzig. Geben Sie zu jeder Kategorie Beispiele. Erlauben Sie ein „Ich bin nicht sicher“, statt die Leute zum falschen Raten zu zwingen. Ihre Kategorienstruktur ergibt für Sie vollkommen Sinn. Für alle anderen ist sie verwirrend.

Die Pilotnutzer merken nicht, dass sie das System tatsächlich benutzen sollen. Wer nur passiv dabei ist, testet nichts. Sagen Sie beim Auftakt ausdrücklich, was Sie erwarten. Machen Sie die Teilnahme für diese Zeit zum Teil der eigentlichen Arbeit, nicht zu etwas, das nebenher reingequetscht wird. Benennen Sie jemanden, der das Pilotprojekt koordiniert und regelmäßig nachfragt. Und würdigen Sie die Beteiligung, nicht nur die Ergebnisse. Die Leute müssen wissen, dass ihr Einsatz zählt.

Die Daten waren vom ersten Tag an falsch. Wer Datensätze importiert, ohne sie vorher zu bereinigen, startet mit Datenmüll. Die Nutzer verlieren sofort das Vertrauen. Bereinigen Sie Ihre Daten, bevor das Pilotprojekt beginnt; wie das geht, zeigt der Leitfaden Inventardaten übernehmen und bereinigen. Prüfen Sie eine Stichprobe der Datensätze, bevor Sie alles importieren. Fahren Sie in der ersten Woche eine kleine Inventur, solange die Fehler noch überschaubar sind. Und seien Sie gegenüber den Pilotnutzern ehrlich: „Wir wissen, dass einige Datensätze falsch sind, helfen Sie uns, sie zu finden und zu korrigieren“ schafft Zusammenarbeit, wo „das ist ab jetzt die eine Wahrheit“ Frust erzeugt.

Was im Kleinen funktioniert und im Großen bricht

Das ist die Falle, an der ich schon erfolgreiche Pilotprojekte habe scheitern sehen: 20 engagierte Nutzer, hervorragende Datenqualität, begeisterte Rückmeldungen, dann 500 Nutzer bei der Einführung, und alles fällt auseinander. Klein und groß ist nicht dasselbe Spiel.

Im Pilotprojekt fragen die Leute bei Unklarheiten Thomas (den Projektleiter). Bei 500 Nutzern geht Thomas unter. Die Antwortzeit steigt von fünf Minuten auf fünf Tage, die Leute sind genervt und geben auf. Die Lösung ist Hilfe zur Selbsthilfe, aufgebaut vor der Einführung: eine durchsuchbare Dokumentation mit Screenshots, ein FAQ aus den echten Fragen der Pilotphase, Videoanleitungen für häufige Aufgaben (Videos schauen die Leute, Handbücher lesen sie nicht), geschulte Ansprechpartner in den Abteilungen für die ersten Fragen und ein klarer Eskalationsweg, wenn diese nicht weiterkommen.

Pilotnutzer haben sich gemeldet oder wurden ausgewählt. Sie sind motiviert. Sie verzeihen kleine Macken. Sie geben Rückmeldung, ohne dass jemand fragt. Die Nutzer bei der Einführung haben nicht darum gebeten. Sie haben ihre eigene Arbeit. Sie verzeihen keine Reibung. Sie hören einfach auf, das System zu benutzen. Also beheben Sie vorher jedes nennenswerte Ärgernis. Erklären Sie das Warum, immer wieder. Bauen Sie jede Reibung ab, die sich abbauen lässt. Loben Sie gute Mitarbeit öffentlich.

Bei 50 Pilotobjekten können Sie die Datenqualität jede Woche von Hand prüfen. Bei 5.000 Objekten ist das unmöglich. Fehler häufen sich, die Datenqualität verfällt. Bauen Sie vor der Einführung automatische Prüfungen: Objekte ohne Standort markieren, doppelte Seriennummern, verdächtig alte Daten bei „zuletzt gesehen“. Setzen Sie eine tragfähige Inventurstrategie mit rollierenden Zählungen auf, statt auf die Jahresinventur zu hoffen. Und machen Sie die Datenqualität zur ausdrücklichen Aufgabe einer Person: Was allen gehört, gehört niemandem.

Im Pilotprojekt macht die Projektleitung alles: konfigurieren, schulen, importieren, reparieren, Fragen beantworten. Im Großen entstehen überall Engpässe. Schreiben Sie auf, was die Projektleitung weiß, solange noch Zeit ist. Schulen Sie weitere Administratoren, damit das Wissen nicht bei einer einzigen Person liegt. Verteilen Sie klare Rollen auf getrennte Verantwortliche: Schulung, Datenqualität, technische Unterstützung.

Ein neues Objekt anzulegen dauert im Pilotprojekt fünf Minuten. Kein Problem. Im vollen Betrieb sind es aber 50 neue Objekte pro Woche. Das sind vier Stunden Arbeit, jede Woche. Kürzen Sie die Eingabe mit weniger Pflichtfeldern und sinnvollen Vorgabewerten. Nutzen Sie den Massenimport, um 20 gleiche Laptops in einem Zug anzulegen. Binden Sie den Einkauf an, damit Objekte direkt aus Bestellungen entstehen.

Faustregel: Multiplizieren Sie den Aufwand aus dem Pilotprojekt mit Ihrem Skalierungsfaktor. Was dort eine Stunde pro Woche kostet, kostet beim 25-fachen Umfang 25 Stunden. Planen Sie entsprechend.

Die Go/No-Go-Entscheidung

Das Pilotprojekt ist vorbei, Sie haben Daten, Rückmeldungen und Erfahrung. Jetzt entscheiden Sie, nach Belegen, nicht nach Politik oder schon ausgegebenem Geld.

Automatisch Go, wenn alles davon zutrifft: Technik im Ziel (über 99 % Verfügbarkeit, schnelles Scannen), Akzeptanz über 80 %, Datengenauigkeit über 95 %, mindestens 70 % der Nutzer empfehlen die Einführung, kein K.-o.-Problem, und der Nutzen ist belegbar über gesparte Zeit, wiedergefundene Objekte oder schlankere Abläufe. Erreichen Sie diese Zahlen, legen Sie los. Setzen Sie die Pilotnutzer bei der Einführung als Fürsprecher ein.

Automatisch No-Go, wenn irgendetwas davon zutrifft: Das System ist regelmäßig nicht erreichbar, die Nutzer wehren sich oder arbeiten daran vorbei, wichtige Abläufe sind kaputt oder unmöglich, die Datenqualität ist schlechter als vorher, Rückhalt der Leitung oder Budget haben sich in Luft aufgelöst, oder der Anbieter kann kritische Fehler nicht beheben. Dann halten Sie an. Bringen Sie entweder die Grundlagen in Ordnung, wählen Sie ein anderes System zur Inventarverwaltung oder überdenken Sie Ihren Ansatz. Machen Sie nicht weiter in der Hoffnung, dass es besser wird.

Go mit Änderungen ist, wo die meisten Pilotprojekte landen. Das meiste funktioniert, aber es gibt ernsthafte Probleme: Technik annehmbar, aber nicht toll, Akzeptanz bei 60–75 % (gut, nicht hervorragend), einige Abläufe haken, die Nutzer sehen den Nutzen, haben aber Vorbehalte, die Datenqualität wird besser, ist aber noch nicht am Ziel.

Stellen Sie vier Fragen. Lassen sich die Probleme beheben? (Technische meist schon; grundsätzliche Unterschiede zwischen Werkzeug und Arbeitsweise oft nicht.) Wie lange dauern die Korrekturen? (Zwei Wochen sind vernünftig; sechs Monate heißen, dass Sie nicht so weit sind.) Lösen die Korrekturen die Bedenken der Nutzer? (Fragen Sie sie, statt es anzunehmen.) Können Sie es sich leisten zu warten? (Manchmal erzwingt Druck von außen einen ungünstigen Zeitpunkt.) Dann beheben Sie die drei bis fünf wichtigsten Probleme, testen die Korrekturen zwei Wochen in einem Mini-Pilotprojekt und entscheiden endgültig.

Eine Bewertungsmatrix, falls Sie eine wollen

Manche Teams finden es hilfreich, die Entscheidung in Zahlen zu fassen:

Ab 8,0: loslegen. 6,0–7,9: erst die Probleme angehen, dann loslegen. Unter 6,0: Hier ist grundlegende Nacharbeit nötig. Passen Sie die Gewichte an Ihre Organisation an. Ist Ihnen die Zufriedenheit der Nutzer kulturell besonders wichtig, geben Sie ihr 30 %.

Die Ergebnisse kommunizieren

Entschieden ist. Jetzt sagen Sie es den Leuten.

Für die Geschäftsführung

Eine Seite. Geschäftsführer lesen keine Berichte mit vierzig Seiten.

Hinein gehören: ein Überblick (was, wann, mit wem), die wichtigsten Kennzahlen in Zahlen (Akzeptanz, Genauigkeit, gesparte Zeit), eine oder zwei konkrete Erfolgsgeschichten, die gefundenen Probleme und wie Sie sie gelöst haben, die verbleibenden Risiken ohne Beschönigung, die Empfehlung und die nächsten Schritte mit Zeitplan und Ressourcen. Fangen Sie mit den Ergebnissen an, nicht mit dem Ablauf. „Die Pilotnutzer haben die Suchzeit für Geräte um 60 % gesenkt“ schlägt „Wir haben alle Schritte termingerecht abgeschlossen“.

Für das Projektteam

Das ist Ihr Wissen als Organisation. Dokumentieren Sie alles: Umfang und Zeitplan, die Nutzerliste mit Beteiligungsquoten, alle Rückmeldungen nach Themen, technische Probleme und ihre Lösungen, die Änderungen am Ablauf, Vorher-nachher-Vergleiche mit Zahlen, was Sie gelernt haben (was funktioniert hat und was nicht), Empfehlungen für die Einführung und einen Anhang mit Umfragen, Gesprächsnotizen und den Messdaten.

In sechs Monaten, wenn Sie einem Problem bei der Einführung hinterherjagen, ist dieses Dokument Gold wert. In einem Jahr, wenn Sie ein anderes System pilotieren, ist es Ihr Leitfaden.

Für die künftigen Nutzer

Wenn Sie weitermachen, setzt die Ankündigung Erwartungen und weckt Vorfreude. Teilen Sie die Ergebnisse konkret. Heben Sie hervor, was funktioniert hat. Zeigen Sie, dass Sie zugehört haben („nach dem, was wir gelernt haben, haben wir die Übergabe vereinfacht und einen Offlinemodus ergänzt“). Sagen Sie klar, was kommt („Sie bekommen Ihre Schulung zwei Wochen, bevor Ihre Abteilung startet“). Verbinden Sie es mit dem, was den Leuten wichtig ist („weniger Zeit mit Suchen, mehr Zeit für die eigentliche Arbeit“).

Der Ton: selbstbewusst, ohne Bedenken abzutun. „Wir wissen, dass Veränderung schwer ist. Wir haben das gründlich getestet, und es funktioniert“ schlägt „Das wird großartig!“.

Pilotnutzer als Fürsprecher

Ihre Pilotnutzer sind das Wertvollste, was Sie für die Einführung haben. Sie kennen das System, wissen, dass es funktioniert, und beantworten Fragen von Kollegen glaubwürdig. Zitieren Sie sie in den Ankündigungen. Lassen Sie sie die Schulungen in ihren Abteilungen mitleiten. Schulung unter Kollegen ist glaubwürdiger als Anweisung von oben. Machen Sie sie zu den Ansprechpartnern für Fragen in ihrem Bereich. Würdigen Sie ihren Beitrag öffentlich.

Ihre Checkliste für das Pilotprojekt

4–6 Wochen vorher

• Umfang des Pilotprojekts festlegen (Abteilungen, Standorte, Objektklassen)
• Pilotnutzer auswählen (willig, typisch, gut erreichbar)
• Erfolgskriterien und Kennzahlen festlegen
• Zeitplan festlegen (Start, Ende, Auswertung)
• Plan an Geschäftsführung und Pilotnutzer kommunizieren

2–3 Wochen vorher

• System für die Pilotumgebung konfigurieren
• Etiketten und Schilder vorbereiten
• Daten für den Import bereinigen und vorbereiten
• Schulungsunterlagen erstellen
• Kanäle für Rückmeldungen einrichten (Umfragen, Termine für Gespräche)

In der Woche davor

• Pilotobjekte etikettieren
• Anfangsdaten importieren und auf Genauigkeit prüfen
• Pilotnutzer schulen (praktisch, zum Mitmachen)
• Kurzanleitungen verteilen
• Kanäle für Unterstützung einrichten (Slack, E-Mail usw.)

Während des Pilotprojekts

• In der ersten Woche täglich nachfragen
• Laufend wöchentliche Umfragen
• Technische Probleme sofort angehen
• Alle Rückmeldungen und Probleme dokumentieren
• Schnelle Verbesserungen unterwegs umsetzen
• Nutzungskennzahlen laufend verfolgen

Zum Ende des Pilotprojekts

• Abschlussumfrage unter den Nutzern
• Einzelgespräche oder gemeinsame Nachbesprechung
• Inventur vor Ort, um die Datengenauigkeit zu prüfen
• Alle Erfolgskennzahlen berechnen
• Auswerten, was funktioniert hat und was nicht

Nach dem Pilotprojekt

• Zusammenfassung für die Geschäftsführung
• Ausführlicher Bericht zum Pilotprojekt
• Go/No-Go-Entscheidung anhand der Bewertungsmatrix
• Bei Go: Einführungsplan auf Basis der Erkenntnisse
• Bei No-Go oder Go mit Änderungen: nötige Korrekturen dokumentieren
• Ergebnisse an alle Beteiligten kommunizieren
• Den Pilotnutzern danken und ihren Beitrag würdigen

Warum mir das wichtig ist

Diese Muster habe ich zu Vorgaben für das Design von UNIO24 gemacht.

Mobil und offline zuerst, weil ich zu viele Teams ein System habe aufgeben sehen, als das Lager-WLAN zum ersten Mal mitten im Scan ausfiel. Die ersten 50 Objekte sind kostenlos, ohne Kreditkarte und ohne Ablaufdatum, weil ich will, dass Sie wirklich ein Pilotprojekt fahren können, statt mit dem Einkauf zu verhandeln, bevor Sie wissen, ob das Werkzeug passt. Massenimport und Sammelübergabe, weil der Unterschied zwischen fünf Minuten und dreißig Sekunden pro Vorgang genau das ist, was die Akzeptanz zwischen Pilotprojekt und vollem Betrieb tötet. Eine bewusst kurze Kategorienstruktur für den Anfang, weil das Raten bei Kategorien ein Ablaufproblem ist, verkleidet als Bedienproblem.

Nichts davon steht zufällig in diesem Leitfaden. Es steht da, weil ich dieselben Probleme dieselbe Art von Einführung habe zerlegen sehen und dann ein Produkt gebaut habe, das diese Fehler nicht leichter macht.

Fahren Sie das Pilotprojekt. Finden Sie die Probleme, solange sie klein sind. Wenn UNIO24 Ihnen dabei hilft, gut: Starten Sie Ihr kostenloses Pilotprojekt. Wenn etwas anderes besser passt, nehmen Sie das. Lassen Sie nur das Pilotprojekt nicht aus.