30 Tage als KI-Mittelstaendler: was du Tag fuer Tag, Woche fuer Woche wirklich tust

Erste KI-Adoption-Woche im DACH-Mittelstand. Was du wirklich tust, nicht das Beratungs-PowerPoint-Maerchen. 30 Tage, 4 Wochen, 12 konkrete Aktionen. Am Tag 31 hast du entweder einen Use-Case mit erstem Output, oder du weisst auf 6 Seiten warum es bei dir nicht geht (auch wertvoll).

Dieser Plan ist fuer Geschaeftsfuehrer, Strategy-Leads und Bereichsleiter im DACH-Mittelstand, die ohne externen 80-Tage-Beratungsplan starten wollen. Du brauchst kein Steering-Committee, keine 12-Wochen-Discovery-Phase, kein Tool-RFP. Du brauchst 4 Wochen Disziplin und eine Person die schreibt.

Was 30 Tage realistisch sind, und was nicht

30 Tage reichen fuer einen ersten produktiven Use-Case mit messbarem Output. 30 Tage reichen NICHT fuer Skalierung, Konzern-Rollout oder Daten-Governance-Reform. Halte die Erwartungen sauber, sonst wirst du am Tag 25 enttaeuscht und brichst ab.

Woche	Tage	Phase	Output am Wochenende
Woche 1	Tag 1-7	Discovery	Top-3 Use-Cases, ein Owner pro Case
Woche 2	Tag 8-14	Tool-Setup	Plattform live, Datenzugriff geklaert, 20 Test-Faelle
Woche 3	Tag 15-21	Pilot-Build	Erster Prompt iteriert, Guardrails gesetzt
Woche 4	Tag 22-30	Test, Decide	Go/No-Go-Verdict mit Zahlen, 5 User getestet

Rechne nach: 7+7+7+9 = 30 Tage. Die letzte Woche ist bewusst 9 Tage, weil Tests und Entscheidung mehr Puffer brauchen als Discovery oder Setup. Wer dir einen sauberen 7-7-7-7-Plan verkauft, hat nie ein echtes Pilot-Decide-Gate selbst gemacht.

Woche 1, Tag 1-7: Discovery (was 80 Prozent der Mittelstand-Pilots ueberspringen)

Discovery ist der unterschaetzte Teil. Die meisten springen direkt auf "lass uns ChatGPT Enterprise kaufen", landen drei Monate spaeter mit 47 Lizenzen ohne Use-Case und fragen sich, warum nichts skaliert. Investiere die 7 Tage. Sie sind billig.

Tag 1-2: Use-Case-Inventur

Kein Workshop. Ein Spreadsheet. Eine Spalte fuer Prozesse, eine Spalte fuer Volumen pro Monat, eine Spalte fuer aktuelle Bearbeitungszeit, eine Spalte fuer "geht das mit Text und Daten oder braucht es Spezialwissen". Ziel: 25 bis 40 Eintraege. In unseren Workshops bei SHD und vergleichbaren Mittelstaendlern produziert ein gemeinsamer Vormittag mit 4 Bereichsleitern routinemaessig 30 Kandidaten. Du brauchst keine externe Erhebung.

Was zaehlt als Kandidat: alles wo ein Mensch heute Text liest, Text schreibt, oder zwischen Systemen kopiert. Auftragseingang per Mail. Lieferantenanfragen klassifizieren. Reklamations-E-Mails beantworten. Compliance-Dokumente pruefen. Reisekosten-Belege zuordnen. Recruiting-Lebenslaeufe vorscreenen.

Tag 3-4: Stakeholder-Match

Pro Top-Kandidat brauchst du drei Rollen besetzt: einen Owner (operativ, der den Prozess kennt), einen Sponsor (Budget und Politik), einen Skeptiker (wird das spaeter benutzen muessen, hat aber Bedenken). Wenn du fuer einen Use-Case keinen Skeptiker findest, ist der Use-Case wahrscheinlich nicht real, sondern Wunschdenken.

Wer das ueberspringt, landet im Pilot-Friedhof. Wir haben das im Detail aufgeschrieben, warum Piloten nicht produktiv werden: der haeufigste Grund ist nicht Technik, sondern fehlender Production-Owner.

Tag 5-7: Top-3-Auswahl mit Kriterien

Aus 25 bis 40 Kandidaten wirst du nicht alle bauen koennen. Bewerte nach drei harten Kriterien: Volumen pro Monat (je hoeher, desto besser, weil ROI mit Volumen skaliert), ROI-Potenzial in Stunden pro Monat, Daten-Verfuegbarkeit (haben wir die Daten heute schon irgendwo digital). Multipliziere, nicht addiere. Ein Use-Case mit hohem Volumen aber ohne Daten ist null, nicht halb so gut. Wenn du Hilfe bei der strukturierten Bewertung willst, der 15-Minuten-Reifegrad-Check deckt das Auswahl-Raster ab.

Am Ende von Tag 7: drei Use-Cases auf Papier, drei Owner-Sponsor-Skeptiker-Trios, drei dokumentierte Volumen- und ROI-Schaetzungen. Wenn du nur einen Use-Case bauen kannst (Personalressourcen), bau den mit hoechstem Volumen.

Woche 2, Tag 8-14: Tool-Setup

Diese Woche ist die langweiligste, aber sie entscheidet ob du in Woche 3 ueberhaupt etwas baust. Halte sie kurz. Plane nicht 6 Wochen RFP, wir bauen einen Pilot, kein SAP-Replacement.

Tag 8-9: Plattform-Wahl

Drei realistische Optionen fuer den ersten Pilot: ChatGPT Enterprise (schnell, geringe technische Tiefe), Claude (vergleichbar, oft staerker bei langen Dokumenten), oder Eigen-Build auf API-Basis (mehr Aufwand, mehr Kontrolle). Fuer den ersten 30-Tage-Pilot empfehlen wir fast immer eine der ersten beiden Optionen. Eigen-Build kommt nach dem ersten erfolgreichen Pilot, nicht davor. Wir haben das ausfuehrlich diskutiert, Make, Buy oder Partner bei KI-Agenten.

Wichtig: Enterprise-Vertrag mit Datenverarbeitungs-Auftrag, sonst kommst du in Woche 3 nicht an die produktiven Daten. Standard-Consumer-Account ist fuer den Pilot okay zum Spielen, fuer echte Daten nicht.

Tag 10-12: Datenzugriff

Drei Wege wie der KI-Agent an deine Daten kommt. Erstens File-Upload, du kopierst Dokumente manuell rein (geht fuer 50 Faelle, nicht fuer 5000). Zweitens Connector zu SharePoint, OneDrive, Confluence (die meisten Plattformen haben das fertig). Drittens RAG, du baust einen Vektor-Index auf deinen Dokumenten (was RAG ist und wann du es brauchst, steht im 7-Begriffe-Glossar).

Praxis-Tipp: starte mit Connector oder File-Upload. RAG bauen die meisten Mittelstaendler in Woche 2 nicht, das verbrennt Zeit. Wenn dein erster Pilot in Woche 4 zeigt, dass du tatsaechlich strukturierten Zugriff auf 10.000 Dokumente brauchst, baust du RAG in Woche 5 bis 8.

Tag 13-14: Eval-Set Setup

Das ist der Punkt wo der Mittelstand am haeufigsten schlampt. Du brauchst 20 echte Test-Faelle mit erwartetem Output. Nimm 20 historische Faelle, schreib daneben was die richtige Antwort gewesen waere, das ist dein Eval-Set. Ohne Eval-Set weisst du in Woche 4 nicht ob der Pilot gut oder schlecht ist, du hast nur Bauchgefuehl. Was ein Eval-Set ist und warum 20 Faelle reichen, erklaeren wir im Begriffs-Glossar.

Ende Woche 2: Plattform live, Datenzugriff funktioniert, 20 Test-Faelle mit Soll-Antwort liegen im Spreadsheet.

Woche 3, Tag 15-21: Pilot-Build

Jetzt baust du. Die Versuchung diese Woche zu strecken ist gross, widerstehe ihr. Wenn du in 7 Tagen keinen brauchbaren ersten Output hinkriegst, ist der Use-Case oder die Daten falsch, nicht der Zeitplan.

Tag 15-17: Erster Prompt

Drei Iterationen reichen. Iteration 1: simpler Prompt, du erklaerst die Aufgabe, fuetterst einen Beispiel-Fall, schaust was rauskommt. Iteration 2: du zeigst dem Modell zwei oder drei Gold-Standard-Beispiele (Few-Shot) und reformulierst was du eigentlich willst. Iteration 3: du strukturierst den Output (JSON, feste Felder, klare Sektionen) und legst fest was bei Unsicherheit passiert. Anthropic dokumentiert das System gut in Building Effective Agents, die Kernidee: Start simpel, Komplexitaet nur wenn der einfache Baseline-Prompt versagt.

Tag 18-19: RAG-Integration (nur wenn noetig)

Wenn dein Pilot tatsaechlich strukturierten Dokumenten-Zugriff braucht, baust du jetzt einen kleinen Vektor-Index auf 200 bis 500 Dokumenten. Wenn nicht (und in ~60 Prozent der Mittelstand-Pilots ist die Antwort: nicht noetig), ueberspringst du diesen Block und gewinnst zwei Tage Puffer. Geh nicht aus Prinzip in RAG. Bau es nur wenn der Use-Case ohne strukturierten Dokumenten-Zugriff nicht funktioniert.

Tag 20-21: Guardrails

Drei Basis-Regeln reichen fuer den Pilot. Erstens: was darf der Agent nicht (z.B. niemals Kunden-Mails ohne Freigabe rausschicken, niemals Preisaenderungen vorschlagen). Zweitens: was passiert bei Unsicherheit (eskaliere an Mensch, statt zu raten). Drittens: was wird geloggt (jeder Call, mit Input und Output, fuer das Eval). Was Guardrails sind und warum drei Regeln am Anfang reichen, deckt das 7-Begriffe-Glossar.

Ende Woche 3: ein funktionierender Pilot, der die 20 Test-Faelle aus dem Eval-Set abarbeitet, mit Logging, mit drei Guardrails.

Woche 4, Tag 22-30: Test, Decide

Jetzt kommt der Teil wo der Mittelstand normalerweise zu frueh feiert oder zu schnell aufgibt. Halte die Tests strukturiert.

Tag 22-25: User-Tests mit 5 echten Mitarbeitern

Nicht der Sponsor, nicht der Owner. Fuenf echte operative Mitarbeiter, die den Prozess heute taeglich machen. Sie bekommen 30 bis 60 Minuten, sollen 5 reale Faelle durchspielen, sollen jede Reaktion dokumentieren ("das ist falsch", "das ist langsam", "das ist gut", "das verstehe ich nicht"). Fuenf Tester sind nicht statistisch signifikant, das wissen wir. Sie sind aber praktisch signifikant: wenn 4 von 5 sagen "das ist falsch", musst du nicht weitertesten.

Tag 26-28: Output-Review gegen Eval-Set

Lass den Pilot ueber die 20 Eval-Faelle laufen. Vergleiche Soll- mit Ist-Output. Zaehl die Faelle in drei Buckets: voll richtig, teilweise richtig (akzeptabel mit Korrektur), falsch. Wenn "voll richtig" unter 50 Prozent ist, hast du ein Daten- oder Prompt-Problem, kein Plattform-Problem. Wenn "voll richtig" ueber 80 Prozent ist, hast du einen produktiven Pilot.

Tag 29-30: Go/No-Go mit konkreten Kriterien

Entscheidung am Tag 30, dokumentiert auf einer Seite. Vier Kriterien: User-Akzeptanz (ja, mit Vorbehalt, nein), Eval-Score (Prozent voll richtig), ROI-Schaetzung (Stunden pro Monat eingespart, Annahmen offenlegen), TCO-Schaetzung 12 Monate (Lizenz, Betrieb, Pflege, der TCO-Post gibt die Struktur). Wenn drei von vier Kriterien gruen sind, gehst du in die naechsten 60 Tage Skalierung. Wenn zwei oder weniger gruen sind, dokumentierst du auf 2 Seiten warum, und entscheidest ob du den Use-Case droppst oder die naechsten 30 Tage in Daten- oder Prozess-Vorarbeit investierst.

Die 5 typischen Stolperfallen in den 30 Tagen

Wir haben den Plan oft genug gefahren um die haeufigsten Fehler aufzulisten.

Falle 1: Workshop-Industry-Trap. Drei Tage Workshop, hundert Post-its, null Aktionen. Wenn die ersten 7 Tage nicht in einem Spreadsheet mit Top-3-Cases enden, hast du dich verworkshoppt. Workshops sind ein Tool, kein Output.

Falle 2: Daten-Cleanup-First-Falle. Der Klassiker: "wir muessen erst alle Daten konsolidieren, dann KI". Das ist die teure Variante zu nichts zu tun. Du brauchst fuer einen Pilot nicht alle Daten sauber, du brauchst die 200 Dokumente sauber, die der Use-Case braucht. Den Daten-Cleanup-First-Mythos haben wir an anderer Stelle entkraeftet.

Falle 3: zu viele Pilots gleichzeitig. Mittelstand-Bereichsleiter wollen oft drei Pilots parallel starten, "damit wir Erfahrung sammeln". In 30 Tagen kannst du genau einen sauber zu Ende bringen. Zwei werden beide halbgar, drei werden alle drei Schrott.

Falle 4: Production-Owner fehlt. Du hast Sponsor, Owner, Skeptiker definiert, aber nicht festgelegt wer am Tag 31 die operative Verantwortung uebernimmt. Das ist der wahre Grund warum Piloten im Mittelstand nicht produktiv werden, siehe Pilot-Friedhof-Analyse.

Falle 5: KI-only ohne Mensch-Schnittstelle. Ein Agent der vollautomatisch entscheidet ohne Eskalations-Punkt produziert in Woche 4 entweder Vertrauensprobleme oder echte Schaeden. Plane Human-in-the-Loop von Tag 15 an mit ein, nicht nachtraeglich (das Konzept ist im 7-Begriffe-Glossar ausgefuehrt).

Was am Tag 31 entscheidet, was am Tag 91 entscheidet

Am Tag 31 hast du eine Antwort auf "funktioniert das technisch und akzeptiert es der User". Das ist nicht Skalierung, das ist Konzept-Beweis. Die naechsten 60 Tage entscheiden ob aus dem Pilot ein produktives System wird, mit Monitoring, mit Eskalation, mit Schulung der Belegschaft, mit Integration in die echte Toollandschaft. Die 90-Tage-Use-Case-Matrix ist die natuerliche Fortsetzung dieses Plans, die ersten 30 Tage sind die Hypothesen-Pruefung, Tag 31 bis 90 ist die Operationalisierung.

Schulung der Belegschaft startet aber NICHT am Tag 91. Schulung startet parallel ab Woche 2, weil deine User-Tester in Woche 4 schon ein Grundverstaendnis brauchen. Wie du Schulung pyramidenfoermig aufbaust ohne alle 500 Mitarbeiter zum 3-Tages-Workshop zu schicken, haben wir in der Belegschafts-Pyramide dokumentiert.

FAQ

Brauchen wir externe Beratung fuer die 30 Tage? Nicht zwingend. Du brauchst eine Person die 50 Prozent ihrer Zeit fuer 30 Tage reservieren kann (Owner-Rolle), drei Bereichsleiter die je 4 Stunden pro Woche reinstecken (Sponsor und Stakeholder), und einen technisch versierten Mitarbeiter fuer Woche 2 und 3 (Plattform-Setup, Prompt-Iteration). Wenn das im Haus nicht da ist, lohnt externe Begleitung. Wenn es da ist, mach es selbst.

Was wenn wir nach Tag 30 nicht entscheiden koennen? Dann ist dein Eval-Set zu schwach oder dein Use-Case zu unscharf definiert. Lass dir nicht einreden dass du "noch 30 Tage zur Reife" brauchst, das ist meistens das Pilot-Friedhof-Muster. Entweder du hast Daten fuer eine Entscheidung oder du musst die Pruefkriterien schaerfen, nicht den Zeitraum strecken.

Welcher Use-Case eignet sich am besten fuer die ersten 30 Tage? Text-zu-Text-Use-Cases mit hohem Volumen und niedrigem Compliance-Risiko. Beispiele: interne FAQ beantworten, Lieferantenanfragen klassifizieren, Reklamations-E-Mails strukturieren. Vermeide am Anfang: Use-Cases mit direkter Kundeninteraktion (zu hohes Risiko fuer Pilot), Use-Cases die regulatorisch geprueft werden muessen (zu lange Freigabezyklen), Use-Cases mit komplexer Tool-Integration (zu lange Setup-Zeit).

Wann ist 30 Tage zu kurz? Bei stark regulierten Domaenen (Medizinprodukte, Finanzdienstleistungen mit Audit-Pflicht, kritische Infrastruktur) ist die Freigabe-Logik laenger als der Pilot. Da macht 60 oder 90 Tage Sinn, aber das ist die Ausnahme. Der typische Mittelstaendler aus Maschinenbau, Handel, Dienstleistung kommt mit 30 Tagen sehr weit. Was Agentic AI ueberhaupt ist und wo die Grenzen liegen, fasst der Crashkurs fuer Geschaeftsfuehrer zusammen.

Quellen und naechster Schritt

Quellen: Anthropic Building Effective Agents als Grundlage fuer Prompt-Iteration und Tool-Use-Pattern. Eigene Beobachtungen aus Sentient-Dynamics-Workshops bei SHD (Mittelstand 650 Mitarbeiter, Andernach) und vergleichbaren DACH-Mittelstaendlern, anekdotisch und klar gelabelt. Cross-Referenzen auf unsere weiteren Beitraege wie oben verlinkt.

Wir machen einen 30-Tage-Pilot-Sprint mit deinem Team. Du startest am naechsten Montag, am Tag 30 hast du ein Go/No-Go-Verdict mit Zahlen. Termin buchen.