Wir wollen unser WorkSimple-Portfolio strategisch erweitern und setzen dabei auf echte KI-Anwendungen statt auf Buzzword-Feuerwerk. Genau deshalb machen wir das fundiert, mit sinnvollem Plan und klarer Zielrichtung. Worum es dabei konkret geht, seht ihr in unserem Logbuch.
Im dritten Beitrag kümmern wir uns um das Fundament: den Beginn jeder unternehmensbezogenen KI-Reise. Nach mehreren Kundeninterviews und einer Marktanalyse, die im nächsten Monat samt zugehöriger Use Cases folgt, möchte ich zunächst einen Grundstein für unsere zukünftige Arbeit legen. Dieser unterscheidet sich deutlich von dem, was viele andere Marktanbieter tun…
95% der KI Projekte scheitern - Warum?
Vor zwei Wochen erschien eine neue MIT-Studie, die zeigt: Nur etwa 5 % der KI-Projekte liefern kurzfristig echten geschäftlichen Nutzen. Die übrigen 95 % bleiben im Pilotstatus oder scheitern. Die Hauptursachen:
- Prestigeprojekte statt Alltagsnutzen: Häufig starten Unternehmen „Leuchtturmprojekte“, die nach außen modern und innovativ wirken sollen – etwa Chatbots, die nie genutzt werden, oder Predictive-Analytics-Dashboards, die niemand im Alltag versteht. Diese Projekte schaffen selten echten Mehrwert, sondern verbrauchen Budgets und Ressourcen.
- Schlechte Integration & fehlendes Lernen: KI-Lösungen sind oft nicht in bestehende Prozesse eingebettet und lernen nicht kontextbezogen mit. Dadurch bleibt ihr Nutzen im operativen Alltag aus.
- Mangel an Know-how: Viele Unternehmen verfügen nicht über das nötige Verständnis oder die Fachkompetenz, um KI sinnvoll einzusetzen. Das führt zu ineffektiven Projekten.
- Starre Strukturen: Etablierte Organisationen sind weniger flexibel und tun sich schwer, Prozesse für KI anzupassen. Start-ups sind hier deutlich erfolgreicher.
- Falsche Use Cases: Der Fokus liegt häufig auf Marketing und Vertrieb, obwohl laut Studie der ROI bei internen Prozessen wie Back-Office deutlich höher ist.
- Fehlstrategie bei der Umsetzung: Eigenentwicklungen scheitern doppelt so häufig wie zugekaufte Lösungen. Erfolgsquote: 67 % bei externen Tools vs. 33 % bei internen Projekten.
- Schwaches Change-Management: Ohne Führung, Schulung und Kulturwandel bleiben KI-Initiativen in der Testphase stecken. Interne Widerstände sind ein zentraler Bremsfaktor.
Diese Erkenntnisse decken sich mit den bisherigen Kundeninterviews und der Aussagen diverser Distributoren.
Vom Whiteboard zur Werkbank: Um nicht zu den 95% zu gehören, beginnen wir bei Ulrike
Schaut man sich die Wettbewerbslandschaft an, kommen die meisten KI-Dienstleister aus dem Data-Analytics-Bereich und entwickeln ihre Lösungen technologiegetrieben. Der Knackpunkt: Die Ideen stammen oft aus dem Management, aber niemand spricht mit der operativen Ebene. Dort sitzt zum Beispiel Ulrike, die seit fünfzehn Jahren jeden Handgriff kennt und genau weiß, wo es hakt.
Warum also nicht dort anfangen? Einen Tag über die Schulter schauen, verstehen, was wirklich gebraucht wird. Genau das machen wir. Wir wollen grundlegend mit dem klassichen Shadowing anfangen.
Shadowing: Mitarbeitenden direkt bei ihrer täglichen Arbeit über die Schulter zu schauen, um Abläufe, Herausforderungen und Verbesserungspotenziale aus erster Hand zu verstehen.
Der Vorteil liegt auf der Hand: Wir entwickeln Use Cases mit echtem Mehrwert, direkt aus dem Alltag heraus. Die Mitarbeitenden bringen ihr Wissen ein, gestalten mit und sorgen dafür, dass die Lösungen später auch genutzt werden. Oft lassen sich daraus schlanke Prototypen entwickeln, die schnell Wirkung zeigen.
Natürlich bringt dieser Ansatz auch Herausforderungen mit sich. Shadowing braucht Zeit und Struktur. Nicht jeder Prozess ist technisch sofort umsetzbar, und ohne Rückendeckung des Managements bleibt eine gute Idee schnell lokal stecken.
Deshalb bleiben wir ergebnisoffen. Vielleicht ergibt sich ein KI-Use Case, vielleicht auch einfach ein “klassisches” Softwarethema, das unser Entwicklerteam direkt umsetzen kann. Entscheidend ist, was dem Kunden wirklich hilft.
Shadowing im Einsatz: Zwei Tage, die ein klares Bild liefern
Und hier ist mein Ansatz, dieses Vorhaben als Grundlage jeder Kundensituation innerhalb von zwei Tagen umzusetzen:
Tag | Aktivität | Ziel | Deliverables |
---|---|---|---|
Vorab (remote) | Vorgespräch & Scoping | Erwartungshaltung klären, Rahmenbedingungen und Zielprozesse festlegen, Zugang zu relevanten Rollen sicherstellen, Risiken vermeiden (z. B. dass Mitarbeitende nur „gewünschte Probleme“ platzieren). | Gesprächsprotokoll mit Zielen, Rahmenbedingungen, relevanten Rollen & Scoping-Dokument |
Tag 1 (Vormittag) | Shadowing bei mehreren Mitarbeitenden in unterschiedlichen Rollen | Direkten Einblick in reale Arbeitsabläufe gewinnen, unterschiedliche Perspektiven erfassen, ungeschminkte Schmerzpunkte dokumentieren | Shadowing-Dokumentation (1–2 Seiten) mit Beobachtungen, typischen Aufgaben, Herausforderungen |
Tag 1 (Nachmittag) | Vertiefendes Shadowing in Schlüsselprozessen | Kritische Schnittstellen und Abhängigkeiten erkennen, typische Workarounds und versteckte Ineffizienzen sichtbar machen | Prozess-Mapping Draft (grafische Darstellung zentraler Abläufe inkl. Schwachstellen) |
Tag 1 (Abend) | Prozessskizze & Vorbereitung des Workshops | Abläufe in Prozessdiagrammen oder Journey Maps visualisieren, Hauptprobleme clustern, erste Hypothesen für Use Cases formulieren, Workshop-Agenda aufbauen | Prozessübersicht (Visual) + Workshop-Agenda (1 Seite) |
Tag 2 (Vormittag) | Workshop: Analyse & Ideenentwicklung mit Mitarbeitenden und Stakeholdern | Gemeinsames Prozessverständnis schaffen, Pain Points validieren, Ideen bündeln, mögliche Use Cases aus Mitarbeitersicht entwickeln | Workshop-Protokoll mit dokumentierten Ideen, validierten Pain Points & ersten Use Case-Skizzen |
Tag 2 (Mittag) | Strukturierung & Bewertung der gesammelten Ideen | Use Cases nach Nutzen, Umsetzbarkeit und Relevanz strukturieren, erste Shortlist erstellen | Use Case Matrix (Impact/Effort-Analyse) + Top-3-Shortlist |
Tag 2 (Nachmittag) | Roadmap & Fahrplan-Definition | Pilot-Use Case auswählen, Prioritäten und Quick Wins festlegen, Verantwortlichkeiten klären, nächste Schritte definieren | Mini-Roadmap (2–3 Monate) mit Pilot-Use Case Beschreibung, Zuständigkeiten & nächstem Schritt |