AI einführen: ein Fahrplan für den Mittelstand statt eines Enterprise-Plans

Große Beratungshäuser verkaufen AI-Einführung inzwischen als mehrmonatiges Programm mit Reifegradmodell, Steering Committee und Roadmap über mehrere Quartale. Für ein Konzern-IT-Team mit eigener Governance-Abteilung mag das der richtige Rahmen sein. Für ein Mittelstandsteam mit fünf bis fünfzehn Leuten im Marketing oder Support ist derselbe Fahrplan eher ein Hindernis: Bis das Steering Committee zum ersten Mal tagt, hätte ein kleineres Team längst einen ersten Prozess automatisiert und daraus gelernt.

Warum der Enterprise-Fahrplan für den Mittelstand nicht passt

Der Enterprise-Fahrplan ist für ein anderes Problem gebaut: viele Abteilungen, viele Systeme, viele Stakeholder, die alle mitgenommen werden müssen, bevor irgendwo etwas verändert wird. Im Mittelstand gibt es dieses Problem meistens nicht. Es gibt einen Prozess, der wehtut, ein bis zwei Personen, die ihn heute manuell fahren, und die Möglichkeit, in Wochen statt Quartalen zu testen, ob eine Lösung trägt. Ein Fahrplan, der für die große Organisation gedacht ist, bringt in dieser Situation vor allem eines: Verzögerung, ohne dass am Ende ein besseres Ergebnis steht.

Das heißt nicht, dass Struktur überflüssig ist. Es heißt, dass die Struktur zur Größe des Teams passen muss. Vier Schritte, die jeder im Team in einem Satz erklären kann, sind für ein Marketing- oder Support-Team mit zehn Personen mehr wert als ein zwanzigseitiges Reifegradmodell, das ohnehin niemand zweimal liest. Genau dieser Gedanke steckt hinter dem Weg, den wir mit unseren Kunden gehen: Hinsehen, Rechnen, Bauen, Übergeben, in dieser Reihenfolge, ohne einen Schritt auszulassen.

Schritt 1: Einen Prozess finden, der wirklich wehtut

Der häufigste Fehler am Anfang ist, mit dem Tool zu starten statt mit dem Schmerz. Ein Team hört von einem neuen AI-Feature und sucht danach einen Anwendungsfall dafür, statt umgekehrt vorzugehen. Der bessere Startpunkt ist eine einfache Frage an das Team: Welche Aufgabe macht ihr jede Woche, die euch nervt, weil sie sich wiederholt und wenig Denkarbeit braucht? Bei SNOCKS war das der Ad-Upload, bei Essential Bag das manuelle Nachschlagen in Shopify vor jeder Support-Antwort.

Diese Frage lässt sich am besten in einer kurzen Runde mit dem Team stellen, das die Arbeit tatsächlich macht, nicht nur mit der Führungsebene. Wer selbst nicht täglich im Prozess steckt, unterschätzt regelmäßig, wie viel Zeit eine Aufgabe wirklich kostet, weil sie in der eigenen Wahrnehmung als "das machen wir halt nebenbei" verbucht wird. Genau diese Aufgaben sind es oft, die sich am ehesten lohnen, weil niemand sie bisher als Problem benannt hat.

• Die Aufgabe wiederholt sich mindestens wöchentlich, nicht nur einmal im Quartal
• Sie folgt einem erkennbaren Muster, auch wenn jeder Einzelfall etwas anders aussieht
• Jemand im Team kann in einem Satz sagen, wie viel Zeit sie kostet

Schritt 2: Die Zahl vor dem Tool

Bevor irgendein Anbieter, auch wir, ein Angebot schreibt, gehört eine Rechnung auf den Tisch: Was kostet der heutige Prozess in Stunden und in Euro pro Monat? Diese Zahl entscheidet, ob sich eine Automatisierung überhaupt lohnt, nicht die Begeisterung für die Technik. Manchmal ist die ehrliche Antwort: Der Prozess kostet zu wenig, um eine Investition zu rechtfertigen, und dann ist ein System der falsche nächste Schritt, unabhängig davon, wie interessant die Technik ist.

Diese Rechnung muss nicht kompliziert sein. Stunden pro Woche mal Stundensatz mal Wochen im Jahr ergibt eine grobe, aber ausreichend belastbare Hausnummer. Wichtiger als die Präzision ist, dass die Zahl überhaupt entsteht, bevor die Entscheidung fällt, denn ohne sie wird das Gespräch schnell zu einer Diskussion über Tool-Features statt über Wirtschaftlichkeit.

Schritt 3: Am echten Fall bauen, nicht am Pilotprojekt

Ein Pilotprojekt mit synthetischen Testdaten fühlt sich sicherer an, verschiebt das eigentliche Lernen aber nur nach hinten. Die Probleme, die ein System im Alltag hat, ein unerwartetes Ticket, ein Creative im falschen Format, zeigen sich fast nie im sauberen Testfall, sondern erst am echten Volumen. Deshalb bauen wir grundsätzlich mit den echten Produkten und der echten Marke des Kunden, nicht an einem Beispiel aus einer anderen Branche. Das Team sitzt dabei, statt hinterher einen Report zu lesen, und sieht die Probleme, sobald sie auftreten.

Schritt 4: Übergeben, nicht verlängern

Der Unterschied zwischen einem Projekt und einem Abonnement zeigt sich am Ende. Ein Projekt endet mit einer Übergabe: Das Team kann das System selbst bedienen, anpassen und bei Bedarf erweitern. Ein Abonnement endet nie, weil das Wissen absichtlich beim Anbieter bleibt. Für den Mittelstand ist die erste Variante fast immer die wirtschaftlichere, weil ein System, das euer Team versteht, mit dem Unternehmen mitwächst, statt bei jeder Anpassung eine neue Rechnung zu erzeugen.

Konkret bedeutet Übergeben bei uns drei Dinge: ein Runbook, das beschreibt, wie das System im Alltag bedient wird, eine Prompt-Bibliothek für die Textbausteine, die immer wiederkehren, und mindestens eine Person im Team, die das System schon während des Baus selbst angefasst hat, nicht erst am letzten Tag. Ohne diese drei Punkte bleibt eine Übergabe eine Absichtserklärung, keine Tatsache.

1. Hinsehen: den Ist-Prozess aufnehmen, bevor über ein Tool geredet wird
2. Rechnen: die Kosten des heutigen Prozesses beziffern, auch wenn die Antwort manchmal "lohnt sich nicht" lautet
3. Bauen: am echten Fall, mit echten Produkten und echter Marke, das Team sitzt dabei
4. Übergeben: Runbook, Prompt-Bibliothek und ein Team, das es selbst bedienen kann

• AI-Einführung
• Mittelstand
• Strategie
• Fahrplan