Pilotprojekt Automatisierung im Mittelstand: Erst testen, dann entscheiden

„Und wenn es nicht funktioniert?” Diese Frage fällt in fast jedem Gespräch über Automatisierung, meist irgendwann zwischen der ersten Begeisterung und der Frage nach dem Budget. Sie ist berechtigt. Wer schon einmal ein Softwareprojekt erlebt hat, das länger dauerte und mehr Ressourcen gebunden hat als geplant, geht vorsichtig an das nächste heran. Und wer einen Betrieb mit knapper Personaldecke führt, kann sich ein halbes Jahr Experiment ohne Ergebnis schlicht nicht leisten. Ein Pilotprojekt für die Automatisierung im Mittelstand ist der Weg, diese Frage vorab zu beantworten.

Die gute Nachricht: Sie müssen diese Wette nicht eingehen. Zwischen „wir machen nichts” und „wir automatisieren den ganzen Betrieb” gibt es einen dritten Weg, der in der Praxis erstaunlich selten gewählt wird. Sie wählen einen einzelnen, begrenzten Prozess aus, legen vorher fest, woran Sie Erfolg messen, und lassen ihn in einem überschaubaren Zeitraum unter echten Bedingungen laufen. Das ist ein Pilotprojekt.

Dieser Artikel zeigt, wie das konkret aussieht. Er beschreibt, was einen Piloten von einem Großprojekt im Kleinformat unterscheidet, wie Sie einen geeigneten Prozess finden, welche Kriterien Sie vorab festhalten sollten und wie die Auswertung am Ende ehrlich ausfällt. Alle Zahlenbeispiele sind als Annahmen gekennzeichnet und dienen nur dazu, die Rechenlogik zu zeigen.

Was ein Pilotprojekt zur Automatisierung im Mittelstand ist und was nicht

Ein Pilot ist ein zeitlich und inhaltlich begrenzter Versuch, der eine konkrete Frage beantworten soll. Die Frage lautet nicht „Können wir Automatisierung?”, sondern etwa: „Spart die automatische Verarbeitung dieses einen Ablaufs bei uns tatsächlich Zeit und akzeptiert das Team die neue Arbeitsweise?” Je genauer die Frage, desto brauchbarer die Antwort.

Damit ist auch klar, was ein Pilot nicht ist. Er ist kein halbfertiges Endprodukt, das man schon einmal „so mitlaufen lässt”. Er ist auch kein Dauerprovisorium, das nach drei Monaten immer noch in der Testphase steckt, weil niemand entschieden hat, wie es weitergeht. Und er ist keine Demo, die auf frisierten Beispieldaten läuft. Ein Pilot arbeitet mit echten Vorgängen, echten Ausnahmen und den Menschen, die den Prozess täglich erleben. Nur dann sagt das Ergebnis etwas über den späteren Betrieb aus.

Ein zweiter Unterschied betrifft das Ziel. Bei einem Großprojekt ist das Ziel die fertige Lösung. Bei einem Piloten ist das Ziel zunächst Erkenntnis: Wie hoch ist der Aufwand wirklich, wo liegen die Ausnahmen, wie reagieren die Beteiligten, welche Annahmen haben sich als falsch erwiesen? Diese Erkenntnis ist auch dann wertvoll, wenn der Pilot am Ende gestoppt wird. Sie haben dann für einen überschaubaren Aufwand erfahren, was ein größeres Projekt Sie gekostet hätte, bevor es überhaupt Nutzen gebracht hätte.

Dazu passt ein Gedanke, den wir im Beitrag über die Gründe, warum Automatisierungsprojekte scheitern, ausführlicher beschreiben: Projekte scheitern selten an der Technik. Häufiger fehlt ein gemeinsames Bild davon, was am Ende besser sein soll. Ein Pilot zwingt zu genau diesem Bild, weil er ohne messbares Ziel gar nicht erst startet.

Den richtigen Prozess auswählen

Der wichtigste Einzelschritt eines Piloten passiert vor dem ersten Zeilencode: die Auswahl des Prozesses. Ein ungeeigneter Prozess macht aus dem Piloten eine Enttäuschung, selbst wenn Technik und Umsetzung einwandfrei sind. Ein geeigneter Prozess liefert dagegen schon nach wenigen Wochen belastbare Zahlen.

Gut geeignet sind Abläufe, die häufig vorkommen, weil sich nur dann in kurzer Zeit genug Vorgänge ansammeln, um etwas zu messen. Sie sollten außerdem weitgehend nach festen Regeln ablaufen. Wenn die Entscheidung in jedem Einzelfall von Erfahrung, Bauchgefühl und einem Telefonat abhängt, ist der Prozess für einen ersten Versuch zu anspruchsvoll. Dazu kommt, dass der heutige Aufwand überhaupt messbar sein muss. Wer nicht weiß, wie viel Zeit der Ablauf jetzt kostet, kann später nicht belegen, dass sie gespart wurde.

Schließlich zählt die Größe des Kreises. Ein Prozess, an dem zwei oder drei Personen beteiligt sind, lässt sich viel leichter begleiten als einer, der durch sechs Abteilungen läuft. Das ist kein Argument gegen die großen Abläufe, sondern dafür, mit einem kleinen anzufangen und das Gelernte später zu übertragen. Die folgende Übersicht hilft bei der Einschätzung:

Wenn mehrere Prozesse infrage kommen, entscheidet nicht der größte Hebel, sondern die beste Mischung aus Nutzen und Beherrschbarkeit. Ein Ablauf, der 30 Prozent einsparen könnte, aber an drei Fremdsysteme gekoppelt ist, eignet sich als erster Pilot schlechter als einer mit 15 Prozent Potenzial, der sauber abgrenzbar ist. Wer die Kandidaten sortieren will, findet in der Prozessanalyse das passende Werkzeug: Dort werden Abläufe beschrieben und bewertet, bevor etwas gebaut wird. Auch der Reifegrad-Check liefert einen ersten Überblick, welche Bereiche überhaupt bereit sind.

Erfolgskriterien festlegen, bevor es losgeht

Der häufigste Fehler bei Pilotprojekten ist nicht ein technisches Problem, sondern ein fehlender Maßstab. Wenn niemand vorher festgelegt hat, was „erfolgreich” bedeutet, wird am Ende nach Gefühl bewertet. Dann loben die Begeisterten das Ergebnis, die Skeptischen finden Gegenbeispiele und die Entscheidung fällt nach Stimmung statt nach Fakten.

Legen Sie deshalb vor dem Start schriftlich drei Dinge fest. Erstens die Zeit: Wie lange dauert ein Vorgang heute, und welcher Wert wäre ein klarer Erfolg? Zweitens die Qualität: Wie oft treten heute Fehler oder Rückfragen auf, und wie viele wären akzeptabel? Drittens die Akzeptanz: Würden die Beteiligten mit dem neuen Ablauf weiterarbeiten wollen? Die dritte Frage wird häufig vergessen, entscheidet aber, ob eine Lösung im Alltag überlebt. Ein technisch korrekter Ablauf, den das Team umgeht, spart keine Zeit.

Zur Veranschaulichung eine Beispielrechnung. Die Zahlen sind eine reine Annahme und sollen nur die Logik zeigen: Angenommen, in einem Betrieb werden täglich 25 gleichartige Vorgänge bearbeitet. Jeder dauert heute durchschnittlich 8 Minuten. Als Erfolgsschwelle legt das Team fest, dass der Aufwand pro Vorgang auf höchstens 3 Minuten sinken soll, einschließlich der Zeit für Kontrolle und Korrektur. Die Rechnung lautet dann: 25 Vorgänge mal 5 eingesparte Minuten ergeben 125 Minuten pro Arbeitstag, also etwas mehr als zwei Stunden. Ob das für Ihren Betrieb viel oder wenig ist, hängt von Ihrer Situation ab. Wichtig ist, dass die Schwelle vorher feststeht.

Genauso wichtig ist die Gegenrechnung. Ein Pilot kostet selbst Zeit: Das Team muss Beispiele liefern, Fragen beantworten und Ergebnisse prüfen. Wer ehrlich bilanzieren will, stellt den Aufwand des Piloten dem erwarteten Nutzen gegenüber. Wie sich solche Überlegungen strukturieren lassen, zeigt der Beitrag zur Frage, ob sich die Automatisierung eines Prozesses lohnt. Das gilt für den Piloten genauso wie für das spätere Gesamtprojekt.

Vier Wochen im Überblick: ein typischer Ablauf

Wie lange ein Pilot dauert, hängt vom Prozess ab. Als Größenordnung hat sich bewährt, den Zeitrahmen so zu begrenzen, dass er in einem Quartal sicher abgeschlossen ist, oft sogar in wenigen Wochen. Entscheidend ist weniger die genaue Dauer als die Tatsache, dass sie vorab feststeht und ein klares Ende hat. Das folgende Beispiel zeigt einen möglichen Vier-Wochen-Ablauf. Er ist eine Orientierung und kein starres Schema:

In der ersten Woche entsteht oft die größte Klarheit, noch bevor irgendetwas gebaut wurde. Wer einen Ablauf Schritt für Schritt beschreibt, entdeckt Lücken, Sonderfälle und Abhängigkeiten, die vorher niemand benannt hat. Manchmal zeigt sich schon hier, dass der gewählte Prozess ungeeignet ist. Auch das ist ein Ergebnis und zwar ein günstiges.

In der zweiten Woche steht der technische Aufbau im Mittelpunkt. Hier lohnt sich der Verzicht auf Perfektion: Es geht darum, den Normalfall sauber abzudecken und die Ausnahmen sichtbar zu machen, nicht darum, jede denkbare Abweichung vorab zu lösen. Welche Art von Werkzeug dafür infrage kommt, erklärt unsere Seite zur Workflow-Automatisierung. Für den Piloten ist die Werkzeugfrage allerdings zweitrangig. Sie wird erst relevant, wenn feststeht, dass der Ablauf überhaupt automatisiert werden soll.

Parallelbetrieb und Rückfallebene

Der Parallelbetrieb ist das wichtigste Sicherheitsnetz eines Piloten. Der automatisierte Ablauf verarbeitet dieselben Vorgänge wie bisher, aber die bisherige Arbeitsweise bleibt gültig. Das Ergebnis des neuen Ablaufs wird mit dem Ergebnis der gewohnten Arbeit verglichen. Stimmen beide überein, wächst das Vertrauen. Weichen sie ab, wird geklärt, wer recht hatte und warum.

Dieser Ansatz hat zwei Vorteile. Zum einen entsteht kein Risiko für den laufenden Betrieb, weil der Kunde, die Buchhaltung oder das Lager zu keinem Zeitpunkt vom Ergebnis eines ungeprüften Versuchs abhängen. Zum anderen erhalten Sie genau die Vergleichszahlen, die Sie für die Auswertung brauchen: Wie oft stimmt das Ergebnis, wo treten Abweichungen auf und wie hoch ist der Aufwand für die Korrektur?

Planen Sie außerdem vorab eine Rückfallebene ein. Das bedeutet nicht mehr als die Antwort auf die Frage: „Was tun wir, wenn der neue Ablauf morgen ausfällt?” Im einfachsten Fall lautet die Antwort, dass die bisherige Arbeitsweise sofort weiterläuft, weil sie nie abgeschaltet wurde. Wer das vorher klärt, nimmt dem Team die Angst vor dem Experiment. Und diese Angst ist ein echter Faktor: Menschen, die fürchten, dass ein Fehler an ihnen hängen bleibt, behandeln einen Piloten zurückhaltend und liefern deshalb weniger ehrliche Rückmeldungen.

Beziehen Sie das Team deshalb von Beginn an ein. Die Menschen, die den Prozess heute täglich bearbeiten, kennen die Sonderfälle besser als jede Dokumentation. Sie wissen, welche Kunden regelmäßig Ausnahmen brauchen und welche Felder in der Praxis anders genutzt werden, als es das Formular vorsieht. Ein Pilot, der an diesen Menschen vorbei entsteht, bildet den Prozess nur auf dem Papier ab.

Die ehrliche Auswertung: weiter, anpassen oder stoppen

Am Ende des Zeitraums steht eine Entscheidung. Sie sollte nicht aus dem Bauch fallen, sondern aus dem Vergleich mit den Kriterien, die Sie in der ersten Woche festgehalten haben. Dafür genügt eine einfache Gegenüberstellung: Ausgangswert, Zielwert, erreichter Wert, jeweils für Zeit, Qualität und Akzeptanz.

Aus dieser Gegenüberstellung ergeben sich drei mögliche Ergebnisse. Im ersten Fall wurden die Schwellen erreicht oder übertroffen. Dann geht es darum, den Piloten in den Dauerbetrieb zu überführen und die nächsten Prozesse auszuwählen. Im zweiten Fall wurden die Schwellen knapp verfehlt, aber die Ursachen sind klar benennbar, etwa ein häufiger Sonderfall oder eine unsaubere Datenquelle. Dann ist eine gezielte Anpassung sinnvoll, gefolgt von einer kurzen zweiten Runde. Im dritten Fall bleibt der Nutzen deutlich hinter der Erwartung zurück und die Gründe liegen nicht in Details, sondern im Kern des Prozesses. Dann ist „stoppen” die richtige Entscheidung.

Dieses „Stoppen” verdient eine eigene Würdigung, weil es in vielen Betrieben als Niederlage gilt. Tatsächlich ist es das beste Ergebnis, das ein Pilot im ungünstigen Fall liefern kann: Sie haben für einen begrenzten Aufwand erfahren, dass dieser Ansatz für diesen Prozess nicht trägt, und Sie haben die Entscheidung auf Basis echter Daten getroffen. Ein Großprojekt hätte denselben Befund erst nach deutlich höherem Einsatz geliefert.

Wichtig ist, dass die Entscheidung tatsächlich fällt. Ein Pilot, der nach der Auswertung ohne Beschluss weiterläuft, wird zum Dauerprovisorium. Bestimmen Sie deshalb vorab, wer entscheidet und bis wann. Eine einzige verantwortliche Person und ein festes Datum reichen dafür aus.

Falls der Pilot erfolgreich war, lohnt der Blick auf das große Bild. Die Ergebnisse zeigen, wie viel Aufwand ein weiterer Prozess voraussichtlich bedeutet, und sie liefern dem Team ein eigenes Erfolgserlebnis, das die nächste Runde deutlich erleichtert. Eine saubere Einordnung, in welcher Reihenfolge weitere Abläufe sinnvoll folgen, beschreibt auch das Glossar zur Prozessoptimierung.

Typische Fehler und wie Sie sie vermeiden

Pilotprojekte scheitern selten spektakulär. Meistens versanden sie leise, weil sich ein paar Grundfehler eingeschlichen haben. Die häufigsten sind schnell aufgezählt und lassen sich mit etwas Disziplin vermeiden.

Der erste Fehler ist ein zu großer Zuschnitt. Aus dem Wunsch, möglichst viel zu lernen, wird der Pilot um weitere Abläufe ergänzt, bis er kein Pilot mehr ist, sondern ein Großprojekt ohne dessen Planung. Die Regel lautet: ein Prozess, eine Frage, ein Zeitrahmen. Alles Weitere kommt danach.

Der zweite Fehler ist der fehlende Maßstab, den wir oben bereits beschrieben haben. Der dritte ist ein unklarer Verantwortlicher. Wenn jeder ein bisschen zuständig ist, fühlt sich am Ende niemand für die Auswertung verantwortlich. Benennen Sie eine Person, die den Piloten begleitet, Rückmeldungen sammelt und die Entscheidung vorbereitet.

Der vierte Fehler betrifft das Team. Wer den Piloten als Überraschung einführt, erntet Misstrauen, vor allem bei Menschen, die befürchten, ihre Arbeit könnte überflüssig werden. Sprechen Sie offen darüber, was sich ändern soll und was nicht. In der Regel geht es nicht darum, Menschen zu ersetzen, sondern darum, ihnen wiederkehrende Handgriffe abzunehmen, damit mehr Zeit für Aufgaben bleibt, die Urteilsvermögen verlangen.

Der fünfte Fehler ist ein unsauberer Datenbestand. Wenn die Eingangsdaten voller Dubletten, Schreibvarianten und Lücken sind, liegt das Problem nicht an der Automatisierung, aber der Pilot bekommt es zu spüren. Prüfen Sie deshalb schon in der ersten Woche, in welchem Zustand die Daten sind. Wenn es nötig ist, wird der Datenbestand selbst zum ersten kleinen Projekt und der Pilot startet danach.

Wann ein Pilot nicht sinnvoll ist

So hilfreich ein Pilot meistens ist, er ist nicht in jeder Lage die richtige Antwort. Es gibt Konstellationen, in denen er mehr Aufwand erzeugt, als er Erkenntnis bringt.

Dazu zählt der Fall, dass der Prozess so selten vorkommt, dass in vier Wochen kaum Vorgänge anfallen. Dann fehlt die Datenbasis für eine Auswertung und es ist besser, den Ablauf zunächst sauber zu beschreiben und zu vereinfachen. Ähnlich liegt es bei Abläufen, die sich selbst noch ständig verändern. Wer mitten in einer Umstellung steckt, automatisiert ein bewegliches Ziel. Hier ist es sinnvoll, erst den neuen Standard zu etablieren und dann zu testen.

Ein Pilot lohnt sich auch dann nicht, wenn die Entscheidung bereits feststeht und nur noch die Umsetzung fehlt. Wenn der Nutzen offensichtlich ist, etwa weil ein Ablauf täglich Stunden bindet und die Lösung bei vielen vergleichbaren Betrieben bewährt ist, kann ein direkter Einstieg in die Umsetzung effizienter sein. Auch dann gelten die Grundprinzipien weiter: klare Kriterien, schrittweises Vorgehen und ein Parallelbetrieb zu Beginn.

Und schließlich gibt es Situationen, in denen ein Pilot das eigentliche Problem nicht trifft. Wenn die Probleme eines Betriebs vor allem in unklaren Zuständigkeiten, fehlenden Absprachen oder widersprüchlichen Zielen liegen, hilft Software zunächst nicht weiter. Dann steht eine Klärung der Organisation am Anfang und die Automatisierung folgt später.

Ihr nächster Schritt: eine Stunde Vorbereitung

Sie brauchen keine Entscheidung für ein Projekt, um mit dem Piloten-Gedanken zu beginnen. Eine Stunde Vorbereitung genügt. Schreiben Sie fünf Abläufe auf, die in Ihrem Betrieb regelmäßig Zeit binden. Bewerten Sie jeden nach den sechs Kriterien aus der Tabelle weiter oben und markieren Sie, wo Sie mit „gut geeignet” antworten können. Den Ablauf mit den meisten Markierungen nehmen Sie als Kandidaten. Messen Sie dann eine Woche lang, wie lange er heute tatsächlich dauert.

Mit diesen Zahlen in der Hand wird das Gespräch über eine Automatisierung konkret. Sie wissen, wo Sie stehen, welches Ziel Sie anstreben und woran Sie den Erfolg erkennen würden. Wenn Sie dabei Unterstützung wünschen, finden Sie bei der Prozessanalyse beschrieben, wie wir einen solchen Start begleiten. Der Anfang ist bewusst klein gehalten, damit die Entscheidung über das Weitermachen auf Fakten beruht.

Transparenzhinweis: Bei der Erstellung dieses Beitrags kam KI-Unterstützung zum Einsatz.