KI im Unternehmen einführen: ein 30-/60-/90-Tage-Fahrplan
Dieser Fahrplan ist eine umsetzbare Blaupause, kein Kunden-Case und kein Erfolgsversprechen. Er hilft KMU, Claude oder ein anderes KI-Werkzeug kontrolliert einzuführen: mit einem Prozess, klarer Verantwortung, messbarem Pilot und bewusster Entscheidung über den Rollout.
Vor Tag 1: Ziel und Entscheidungsrahmen festlegen
Beginne nicht mit „Wir brauchen KI“, sondern mit einem konkreten Geschäftsproblem. Formuliere, welcher Ablauf verbessert werden soll, wer ihn fachlich besitzt und anhand welcher Werte nach 90 Tagen entschieden wird.
Ein belastbarer Auftrag lautet zum Beispiel: „Wir testen, ob Angebotsentwürfe bei gleichbleibender fachlicher Qualität weniger Bearbeitungszeit und Rückfragen verursachen.“ Eine pauschale Produktivitätsoffensive ist zu ungenau.
- Sponsor: entscheidet Budget, Priorität und Eskalationen.
- Fachlicher Owner: beurteilt Prozess und Ergebnisqualität.
- Technischer Owner: verantwortet Zugriffe, Betrieb und Rückfallweg.
- Datenschutz/Sicherheit: prüft Verarbeitung, Risiken und Maßnahmen.
- Pilotnutzer: testen reale Fälle und dokumentieren Abweichungen.
Tag 1–30: auswählen, begrenzen und einen Pilot bauen
- Ist-Prozess messen: Vorgangsmenge, Bearbeitungszeit, Wartezeit, Nacharbeit und typische Fehler erfassen.
- Use Case priorisieren: hoher Wiederholungsgrad, klare Ein- und Ausgaben, überschaubares Risiko und ein verfügbarer Owner.
- Datenregeln festlegen: erlaubte Quellen, Datenklassen, Rechtsgrundlage, Löschung, Freigaben und ausgeschlossene Inhalte dokumentieren.
- Kleinste Lösung bauen: zunächst Prompt oder Skill; Connector, MCP oder API nur, wenn der Prozess es erfordert.
- Dry-Run: mit anonymisierten oder risikoarmen Beispielen testen, bevor reale Daten oder Aktionen freigegeben werden.
- Pilot starten: wenige Nutzer, echte Fälle, tägliches Fehlerlog und fester wöchentlicher Review.
Ergebnis nach 30 Tagen: ein laufender Pilot, dokumentierte Grenzen und genügend Daten für eine erste Change- oder Stop-Entscheidung.
Tag 31–60: Qualität stabilisieren und Betrieb vorbereiten
- Fehler nach Ursache clustern: fehlender Kontext, unklare Regel, schlechte Quelldaten, Modellgrenze oder Bedienfehler.
- Skill, Beispiele und Ausgabeformat nachschärfen; Sonderfälle bewusst in den manuellen Prozess zurückführen.
- Benötigte Integrationen einzeln mit minimalen Rechten, Logging, Testfall und Rückbauweg ergänzen.
- Nutzungsrichtlinie, Kurzschulung, Supportweg und Offboarding dokumentieren.
- Ist- und Pilotwerte vergleichen: Zeit, Nacharbeit, Qualität, Kosten, Risiko und freiwillige Nutzung.
Ergebnis nach 60 Tagen: ein wiederholbarer Ablauf, der nicht von einer einzelnen Prompt-Person abhängt und bei Störungen auf einen manuellen Weg zurückfallen kann.
Tag 61–90: kontrolliert ausrollen oder bewusst stoppen
- Go-, Change- und Stop-Kriterien im Steuerkreis bewerten.
- Bei Go nur eine Dimension gleichzeitig erweitern: mehr Nutzer, eine weitere Datenquelle oder ein zweiter ähnlicher Prozess.
- Rollen, Berechtigungen, Schulung und Support für die neue Gruppe wiederholen.
- Monatlichen Review für Qualität, Kosten, Vorfälle, ungenutzte Zugriffe und Produktänderungen festlegen.
- Backlog nach belegtem Nutzen priorisieren; kein automatischer Rollout auf alle Abteilungen.
Ein Stop ist kein Scheitern. Wenn Qualität, Datenzugang oder Wirtschaftlichkeit nicht tragen, wird der Pilot beendet oder auf eine einfachere Assistenzstufe zurückgebaut.
Messplan: Ausgangswert, Pilotwert und Ziel
| Messgröße | Vorher | Im Pilot | Entscheidung |
|---|---|---|---|
| Bearbeitungszeit | Stichprobe realer Fälle | gleiche Fallart | Nettoersparnis nach Review |
| Nacharbeit | heutige Korrekturen | Korrekturzeit und Ursache | stabil oder sinkend |
| Qualität | fachliche Checkliste | Blind- oder Stichprobenreview | Mindeststandard erfüllt |
| Risiko | bekannte Fehlerfolgen | Vorfälle und Beinahefehler | beherrschbar mit Maßnahmen |
| Kosten | heutiger Personal- und Toolaufwand | Lizenzen, API, Betrieb, Support | positiver Gesamtfall |
Zielwerte werden für den konkreten Prozess festgelegt. Pauschale Prozentversprechen sind kein Ersatz für eine Baseline.
Go-, Change- und Stop-Kriterien
- Go: Qualitätsminimum wird erreicht, Nacharbeit ist beherrschbar, Daten- und Rechtekonzept funktioniert, Nutzer verwenden den Ablauf und der Gesamtaufwand ist plausibel.
- Change: Nutzen ist sichtbar, aber Fehler konzentrieren sich auf korrigierbare Regeln, Datenquellen oder Schulungslücken.
- Stop: Ergebnis kann fachlich nicht zuverlässig geprüft werden, Risiko bleibt zu hoch, notwendige Daten dürfen nicht genutzt werden oder der Betrieb kostet mehr als der Prozesswert.
Typische Einführungsfehler vermeiden
- Seats kaufen, bevor Prozess und Pilotgruppe feststehen.
- Zu viele Use Cases und Datenquellen gleichzeitig starten.
- Nur Zeitersparnis messen und Nacharbeit oder Risiko ausblenden.
- Schreibrechte vergeben, bevor der Entwurfsmodus stabil ist.
- Datenschutz und IT erst kurz vor dem Rollout einbeziehen.
- Keine Person benennen, die fachlich für Qualität und Änderungen verantwortlich ist.
Nächster Schritt
Wenn der erste Prozess noch unklar ist, starte mit dem kostenlosen Use-Case Check. Der 490-€-Workflow-Audit liefert bei komplexerer Ausgangslage ein priorisiertes Backlog und einen Pilotpfad; ein Skill-Sprint kostet 790 €, vollständige Setups starten bei 1.850 €. Die Preise sind aktuelle Angebotsstufen, keine Aussage über den Gesamtaufwand jedes Projekts.
Für die Umsetzung: Claude im Unternehmen einrichten lassen oder einen Geschäftsprozess automatisieren.
