Warum Ihr KI-Projekt eine Zeitbombe ist (und wie Design Thinking hilft)

Ein schlechtes KI-Projekt scheitert selten leise. Es verbrennt Budget, bremst Ihre Teams aus und bleibt oft auf halber Strecke stecken, bevor der Rollout überhaupt richtig Fahrt aufnimmt. Am Ende steht ein massiver Vertrauensverlust zwischen der Geschäftsführung, der IT und den Mitarbeitern, die später mit dem Ergebnis arbeiten müssen. Und seien wir ehrlich: Wenn dieses Vertrauen erst einmal weg ist, wird es richtig teuer, es wieder aufzubauen.

Die meisten Unternehmen machen diesen Fehler, bevor sie überhaupt anfangen: Sie lassen sich von Tool-Demos und Versprechen blenden, dass die Software schon irgendwie Ordnung schaffen wird. Erfahrene Teams fangen an einer Stelle an, die deutlich weniger glänzt. Sie konzentrieren sich auf Prozessklarheit, Datenqualität und klare Verantwortlichkeiten. Das klingt im ersten Moment langsamer und mühsamer, aber in der Praxis ist es der deutlich günstigere Weg.

Lassen Sie es mich einfach sagen: Das KI-Projekt selbst ist meistens gar nicht die Zeitbombe. Die Gefahr liegt in den ungeklärten Prozessen, den schwachen Datenmodellen oder den unklaren Übergaben zwischen den Abteilungen. Wenn diese Grundlagen nicht stehen, kann auch die beste Technik nichts retten.

Hier kommt Design Thinking ins Spiel, sofern Sie es richtig nutzen. Betrachten Sie es nicht als nettes Workshop-Ritual mit bunten Klebezetteln, sondern als knallhartes Risikomanagement. In den nächsten Minuten schauen wir uns an, wie Sie den echten Nutzwert, die Datenreife und den ROI prüfen, bevor Sie Geld für teure Implementierungen ausgeben. Aber zuerst räumen wir mit dem üblichen Mythos auf, warum diese Projekte eigentlich scheitern.

Abschnitt 1: Warum KI-Projekte meist scheitern, lange bevor das Modell versagt

Der sichtbare Verlust fängt meistens ganz klein an. Ein Pilotprojekt läuft ein paar Monate, die Demo sieht ordentlich aus, aber danach bewegt sich plötzlich nichts mehr. Der Anwendungsfall erreicht nie den echten Betrieb, während die Mitarbeiter im Hintergrund längst eigene Schattenprozesse aufbauen. Da werden Ergebnisse händisch in Excel-Tabellen korrigiert, die Betriebskosten steigen schleichend an und der Anbieter spricht plötzlich über Zusatzmodule und mehr Lizenzen. Das ist der direkte Weg in hohe laufende Kosten und einen gefährlichen Vendor Lock-in.

Seien wir ehrlich: Die meisten KI-Projekte scheitern nicht an einer zu schwachen Rechenleistung oder einem schlechten Modell. Sie scheitern, weil Unternehmen einen instabilen Prozess in ein glänzendes System füttern und erwarten, dass die Software von allein für Disziplin sorgt. Miese Datenqualität, fehlende Governance und unklare Zuständigkeiten richten weit mehr Schaden an als ein fehlender Prozentpunkt bei der Genauigkeit des Modells.

Was bedeutet das konkret für Sie im Mittelstand? Oft finden wir Legacy-Systeme, die Kernprozesse abbilden, an die sich seit Jahren niemand mehr herantraut. Daneben existieren Excel-Seitenwelten, die von erfahrenen Kollegen gepflegt werden, weil das offizielle System die Realität im Betrieb gar nicht mehr abbildet. Stammdaten liegen in drei verschiedenen Versionen vor, je nachdem, welche Abteilung man gerade fragt. Und dann kommt der Teil, den niemand gerne dokumentiert: die Ausnahmen. Manuelle Freigaben, Sonderregeln für bestimmte Kunden oder Absprachen am Telefon, die nur in den Köpfen der Mitarbeiter existieren.

Wenn Sie jetzt eine KI oben draufsetzen, verschwindet das Chaos nicht, sondern es wird skaliert. Das ist die unangenehme Wahrheit. Eine KI ist extrem gut darin, Prozesse zu beschleunigen, aber wenn der Prozess schwach ist, beschleunigt sie eben auch die Schwachstellen. Wenn der Input unklar ist, produziert das System einfach schneller unklare Ergebnisse. Unklare Verantwortlichkeiten führen dann dazu, dass sich die Verwirrung mit hoher Geschwindigkeit über noch mehr Teams verteilt.

Das eigentliche Risiko ist also kein technisches Versagen im Labor, sondern das operative Scheitern nach dem Launch. Die Geschäftsführung unterschreibt ROI-Zusagen, die auf sauberen Prozessen basieren, die es so in der Realität nie gab. Rollout-Pläne gehen von stabilen Übergaben aus, aber im Live-Betrieb schlagen dann plötzlich die Ausnahmen ein. Die Support-Teams erben diese Last, und die Day-2-Operations werden zur Detektivarbeit, weil niemand festgelegt hat, wer für Qualitätschecks oder das Nachjustieren des Systems zuständig ist.

Stellen Sie sich einen Mittelständler mitten im Rollout vor, bei dem der Business Case in der PowerPoint-Präsentation noch perfekt aussah. Man hat mit idealen Daten und reibungslosen Abläufen gerechnet, doch dann startet der echte Betrieb und die Realität schlägt zu. Ein Compliance-Fall taucht auf, der im Piloten nicht vorkam, oder ein Quellsystem ändert plötzlich einen Statuscode. Ein Freigabepfad bricht zusammen, weil eine Abteilung dachte, die andere sei verantwortlich. Das KI-Modell arbeitet vielleicht technisch einwandfrei, aber der Betrieb drumherum bricht zusammen.

Das ist die Logik der Zeitbombe. Die Explosion passiert nicht bei der Vertragsunterschrift und oft auch nicht während der Testphase. Sie passiert nach dem Go-Live, wenn Sonderfälle und echte Übergaben den Alltag treffen. Genau dann wird ein Projekt, das auf der Rechnung erst günstig aussah, im laufenden Betrieb extrem teuer. Wenn Sie das einmal verstanden haben, stellt sich die Frage nicht mehr, welches Tool Sie kaufen sollten, sondern welches Risiko Sie zuerst ausräumen müssen.

Abschnitt 2: Richtig eingesetzt ist Design Thinking ein Filter für schlechte KI-Ideen

Seien wir ehrlich – Design Thinking hat ein massives Imageproblem. Viele Entscheider denken dabei sofort an bunte Klebezettel, Sitzsäcke und Workshops, die zwar viel Energie erzeugen, aber am Ende keine harten Entscheidungen liefern. Diese Version gibt es leider wirklich, und sie hat in der Branche echten Schaden angerichtet, weil sie eine eigentlich hochgradig pragmatische Methode wie reines Innovationstheater aussehen lässt.

Richtig eingesetzt ist die Sache jedoch viel simpler und vor allem wertvoller für Ihr Budget. Es ist ein strukturierter Filter, um das eigentliche Problem zu verstehen, bevor Sie Geld in die Hand nehmen, die Architektur planen oder Security-Reviews anstoßen. Das ist der entscheidende Punkt. Es geht nicht um den Workshop oder die Wand voll mit buntem Papier, sondern darum, das Risiko zu senken, dass Sie am Ende das völlig falsche Produkt auf eine sehr teure Art und Weise bauen.

Die Phasen dahinter sind kein Geheimnis: Verstehen, Definieren, Ideen finden, Prototypen bauen und Testen. Das war es schon. Aber hinter jedem dieser Schritte steht eine sehr spezifische Risikofrage, die Sie beantworten müssen.

In der Phase des Verstehens sammeln Sie keine Meinungen, nur um der Beschäftigung willen. Sie identifizieren stattdessen ganz konkret, wo Prozesse heute brechen, wer sie wie umgeht, welche Daten wirklich angefasst werden und wo Entscheidungen heute rein auf Bauchgefühl basieren. Wenn Sie diesen Schritt überspringen, starten Sie mit Annahmen, und genau dort verbrennen im Mittelstand meistens die Budgets.

Dann folgt die Definition. Das klingt harmlos, ist aber der Moment, in dem viele Teams in die totale Unverbindlichkeit abdriften. Die Aussage „Wir wollen KI im Support nutzen“ ist keine Problemdefinition, sondern ein Wunschzettel. „Wir wollen die Suchzeit im Second-Level-Support verkürzen und gleichzeitig die Qualität der Freigaben stabil halten“ kommt der Sache schon deutlich näher. Eine gute Definition grenzt das Feld ein, denn sie sagt Ihnen klipp und klar, was Erfolg bedeutet und was explizit nicht zum Projekt gehört.

Erst wenn das Problem glasklar ist, geht es an die Ideenfindung. Hier machen die meisten Unternehmen den Fehler und drehen die Reihenfolge einfach um. Sie starten mit der Lösung und suchen dann krampfhaft nach einem passenden Anwendungsfall. Klartext: Das ist der falsche Weg. Die Ideenphase sollte Optionen liefern, keine festen Zusagen. Vielleicht hilft KI, vielleicht helfen aber auch einfach nur klare Regeln oder eine bessere Datenpflege. Manchmal ist die richtige Antwort sogar, einen Prozessschritt komplett zu streichen, den seit Jahren niemand mehr hinterfragt hat.

Lassen Sie uns kurz über Empathie sprechen. Das Wort wird oft missbraucht, also halten wir es operativ: Empathie bedeutet hier, sich zu den Leuten zu setzen, die die eigentliche Arbeit machen. Das sind die Kollegen, die Tickets bearbeiten, Freigaben prüfen, Reklamationen managen oder Ausnahmen klären. Schauen Sie genau hin, wo diese Leute warten müssen, wo sie Daten händisch kopieren oder wo sie ein zweites System prüfen, weil sie dem ersten nicht trauen. Oft weicht der Prozess auf dem Papier massiv von der Realität ab, weil die Mitarbeiter längst eigene Abkürzungen gefunden haben.

Der Schmerz der Anwender ist aber nur die halbe Wahrheit. Sie brauchen am Tisch auch die Prozessverantwortlichen, die IT-Leitung, die Security-Experten und die Data Owner. Wenn Sie die ignorieren, lösen Sie vielleicht den Frust eines einzelnen Teams, schaffen aber gleichzeitig ein unkalkulierbares Risiko für drei andere Abteilungen. Das passiert in der Praxis deutlich öfter, als Software-Anbieter es gerne zugeben.

Was liefert die Methode also am Ende, wenn man sie ernsthaft durchzieht? Erstens eine scharfe Problemstellung, zweitens eine klare Kennzahl für den Erfolg und drittens einen bewusst klein gehaltenen ersten Scope. Dieser kleine Scope ist entscheidend, weil er Disziplin erzwingt. Hören Sie auf so zu tun, als bräuchte das ganze Unternehmen bis zum nächsten Quartal eine KI-Strategie, und fangen Sie stattdessen an, einen einzigen, messbaren Anwendungsfall sauber zu verproben.

Vergleichen Sie das mal mit dem typischen Tool-fokussierten Denken. Einen KI-Assistenten für einen Prozess zu kaufen, den vorher niemand aufgeräumt hat, ist wie ein Haus zu renovieren, ohne die Elektrik hinter der Wand zu prüfen. Das sieht für einen Moment modern aus, aber beim ersten Fehler merken Sie schnell, dass die hübsche Fassade der billigste Teil des gesamten Irrtums war.

Wenn die Methode sitzt, ist die Frage nicht mehr, ob eine Idee modern klingt. Die eigentliche Frage ist dann nur noch, ob dieser spezifische Anwendungsfall eine Investition überhaupt verdient hat.

Abschnitt 3: Nutzen Sie eine Machbarkeitsmatrix, bevor Sie über Architektur oder Anbieter sprechen

Jetzt kommen wir zu dem Teil, der Ihnen bares Geld spart. Sobald ein Team einen Anwendungsfall gut findet, ist der Drang groß, sofort mit Anbietern zu sprechen. Das ist meistens viel zu früh. Bevor Sie Architekturdiagramme zeichnen, über Plattformen debattieren oder Demos buchen, gehört jeder Use Case in eine einfache Matrix mit zwei Achsen: Geschäftsnutzen und Machbarkeit.

Das ist kein akademisches Spielzeug, sondern ein hartes Management-Tool. Es ist simpel genug, damit die Geschäftsführung es in zehn Minuten versteht, und gleichzeitig streng genug, damit die Fachabteilungen „Nein“ sagen können, wenn die Begeisterung mal wieder schneller ist als die Hausaufgaben.

Geschäftsnutzen klingt groß, ist aber meistens sehr bodenständig. Spart der Case messbar Zeit ein? Verbessert er die Qualität? Senkt er die Fehlerquote oder die Nacharbeit? Verkürzt er Durchlaufzeiten oder entlastet er den Service an der Front? Schützt er den Umsatz, indem er Abwanderung oder Verzögerungen verhindert? Wenn Sie keinen dieser Effekte konkret benennen können, ist der Case vielleicht interessant, aber definitiv noch nicht investierbar.

Die Machbarkeit ist genauso wichtig, und hier werden KI-Diskussionen oft seltsam ausweichend. Haben Sie die Daten, ja oder nein? Sind diese Daten nutzbar – und zwar nicht in der Theorie, sondern in der Qualität, die der Prozess braucht? Ist der Prozess stabil genug, um ihn zu unterstützen, ohne jede Woche die Regeln neu zu erfinden? Wie viel Integrationsaufwand steckt wirklich dahinter und welches regulatorische Risiko kaufen Sie sich ein? Eine Frage wird dabei fast immer vergessen: Werden die Mitarbeiter das Tool am Ende wirklich nutzen oder arbeiten sie im Stress doch wieder daran vorbei?

Hier ist der Teil, den viele Vorstände übersehen, weil er auf den bunten Folien der Anbieter selten auftaucht: die Architektur-Passung und das Betriebsmodell. Ein Anwendungsfall kann auf dem Papier einen hohen Wert haben und trotzdem nicht in Ihre IT-Landschaft passen. Wenn Sie dafür instabile Schnittstellen, unklare Identitätsprüfungen oder manuelle Datenexporte brauchen, ist die Lösung schon beim Start teurer, als sie aussieht. Wer verantwortet das System nach dem Go-Live? Nicht das Projektteam, sondern der Linienbetrieb muss die Qualität, die Eskalationen und das Nachlernen der Modelle sicherstellen.

Genau deshalb sind Ideen mit hohem Wert, aber geringer Machbarkeit oft gefährliche Fallen. In Strategiepapieren sehen sie glänzend aus, weil man den Nutzen leicht beschreiben kann, aber die laufenden Kosten bleiben unsichtbar. Ein großes Versprechen bei schlechter Machbarkeit bedeutet fast immer versteckte Arbeit an den Prozessen, der Integration und der Governance. Auf den Slides sieht das beeindruckend aus, im Betrieb wird es zum Grab für Ressourcen.

Die besseren Kandidaten für den Start sind oft weniger glanzvoll. Denken Sie an repetitive Aufgaben, stabile Eingangsdaten und messbare Ergebnisse. Ein eng gefasster interner Prozess, bei dem die Entscheidungskriterien bekannt sind und das Ergebnis leicht geprüft werden kann, ist ideal. Dort lernen Sie günstig, bauen Vertrauen auf und sehen innerhalb weniger Wochen, ob die Idee wirklich hilft oder nur einen weiteren Klick im Arbeitsalltag bedeutet.

Seien wir ehrlich: Nicht jedes gute Problem braucht KI. Ein bisschen Disziplin schützt hier Ihr Budget massiv. Manche Probleme brauchen einfach nur klarere Regeln, saubere Stammdaten oder eine klassische Workflow-Automatisierung statt maschineller Logik. Wenn eine normale Automatisierung das Problem löst, dann nutzen Sie diese auch. Es gibt keinen Preis dafür, die modischere Lösung zu wählen, wenn sie unnötig kompliziert ist.

Lassen Sie mich den Checkpoint ganz deutlich formulieren: Wenn die Daten unvollständig sind, widersprüchlich vorliegen oder politisch zwischen fünf Abteilungen feststecken, dann hören Sie auf so zu tun, als wäre der Pilot bereit. Er ist es nicht. In diesem Moment haben Sie kein KI-Projekt, sondern ein Daten- und Organisationsproblem, auf dem nur ein KI-Etikett klebt.

Da Risiken nicht verschwinden, nur weil der Scope klein ist, muss die Governance von Anfang an mitlaufen. Inventarisieren Sie den Use Case, klassifizieren Sie das Risiko und legen Sie fest, welche Freigaben nötig sind. Klären Sie, was protokolliert wird, wie Ergebnisse geprüft werden und wie der Plan B aussieht, wenn das System einmal falsch liegt oder ausfällt. Diese Fragen sind keine Bürokratie, sondern ein integraler Bestandteil eines tragfähigen Designs.

Wenn ein Anwendungsfall diesen Filter überlebt hat, sollten Sie ihn trotzdem noch nicht sofort bauen. Der nächste vernünftige Schritt ist erst einmal die Simulation.

Abschnitt 4: Low-Fidelity-Prototyping, wie Sie einen KI-Anwendungsfall testen, ohne KI zu bauen

An dieser Stelle werden viele Teams ungeduldig. Der Anwendungsfall ist gefiltert, die Beteiligten sind sich einig, und plötzlich sagt jemand: „Gut, bauen wir einen Proof of Concept.“ Das klingt effizient, ist es aber oft nicht. In vielen Fällen ist der nächste kluge Schritt eben keine Entwicklung, sondern Prototyping – und zwar nicht als Design-Dekoration, sondern zur Kostenkontrolle.

Klartext: Ein Prototyp ist dazu da, frühzeitig billige Fehler zu machen. Sie versuchen hier niemanden zu beeindrucken, sondern wollen herausfinden, wo die Idee bricht, bevor Beschaffung, Integration und Lizenzkosten eine schwache Annahme in einen teuren Budgetposten verwandeln.

Die gute Nachricht ist, dass Low-Fidelity-Optionen denkbar einfach sind. Sie können den Workflow auf Papier skizzieren oder einen groben Klick-Dummy bauen, der nur die wichtigsten Masken zeigt. Sie können die Ergebnisse, die eine KI liefern würde – etwa eine Antwort, eine Klassifizierung oder eine Zusammenfassung – einfach manuell simulieren. Gehen Sie den Service mit dem Team durch und besprechen Sie jeden Entscheidungspunkt im Detail, während Sie Teile des Prozesses im Hintergrund händisch steuern. Das reicht völlig aus, um zu prüfen, ob der Workflow an sich überhaupt sinnvoll ist.

Eine Methode ist hier besonders wertvoll: der „Wizard of Oz“. Der Name klingt theatralischer, als die Methode eigentlich ist, denn im Grunde wird die KI dabei teilweise von einem Menschen im Hintergrund simuliert. Der Nutzer glaubt, er bewegt sich durch einen automatisierten Prozess, aber die Intelligenz dahinter ist noch reine Handarbeit. Ein Mitarbeiter liest die Eingabe, bereitet das Ergebnis vor und speist es zurück in das System ein, was Ihnen erlaubt, den Service zu testen, bevor Sie in die teure Maschinerie investieren.

Warum ist das wichtig? Weil es Probleme schnell aufdeckt, und zwar nicht die Probleme, die Anbieter gerne in ihren aufgeräumten Benchmark-Diagrammen präsentieren. Sie sehen sofort, wo Nutzer dem Ergebnis misstrauen oder wo eine Anweisung zu vage ist, um ein brauchbares Resultat zu liefern. Oft stellt man erst hier fest, dass Quelldaten genau an dem Punkt fehlen, an dem der Workflow sie zwingend benötigt. Sie finden Eskalationspfade, die in der Theorie gut aussehen, aber in der Praxis scheitern, sobald jemand eine echte Entscheidung treffen muss. So lernen Sie, ob das Ergebnis im Tempo und unter dem Druck des normalen Arbeitsalltags wirklich besteht.

Dieser letzte Punkt wird oft unterschätzt, denn eine Antwort kann technisch plausibel und trotzdem völlig nutzlos sein. Vielleicht ist sie zu lang, zu vage, kommt zu spät oder ist schlicht zu schwer zu verifizieren. Ein Prototyp legt das gnadenlos offen, weil echte Menschen im Kontext darauf reagieren und nicht in einer Workshop-Fantasie.

Halten Sie den Umfang dabei schmal: ein Team, ein Workflow, ein wiederkehrendes Problem. Planen Sie nicht für das ganze Unternehmen oder drei Abteilungen gleichzeitig, denn wenn Ihr erster Test bereits eine große Rollout-Strategie braucht, ist der Fokus zu breit. Es geht darum, unter kontrollierten Bedingungen zu lernen, mit genug operativer Realität für die Ehrlichkeit und genug Eingrenzung, um die Kosten niedrig zu halten.

Bauen Sie das System von Anfang an mit einem „Human in the Loop“ auf. Das bedeutet, dass jemand die Ergebnisse prüfen, überschreiben oder ablehnen kann, bevor der Prozess weiterläuft. Das ist keine Schwäche im Design, sondern ein wesentlicher Teil davon. In vielen Geschäftsprozessen, in denen es auf Qualität oder interne Freigaben ankommt, ist volle Autonomie ohnehin nicht das Ziel, sondern eine assistierte Entscheidungsfindung unter menschlicher Kontrolle.

Es gibt noch einen weiteren Vorteil, den viele übersehen: Ein Prototyp testet nicht nur den Bildschirm oder die Antwort, sondern das gesamte Betriebsmodell. Wer reagiert, wenn das Ergebnis unklar ist, und wie schnell braucht das Team eigentlich eine Rückmeldung? Wer ist für Korrekturen verantwortlich, wenn die Eingabe unvollständig war, und wo landen die Ausnahmen? Das sind die Fragen, die später richtig teuer werden, wenn sie heute niemand stellt.

Aus Sicht der Architektur ist das schlicht disziplinierte Arbeit. Es ist besser, eine schlechte Idee auf Papier zu entlarven, als in einem unterschriebenen Vertrag nach einem halben Jahr Integrationsaufwand. Nutzen Sie den Walkthrough, um festzustellen, dass niemand die Freigaberegeln definieren kann, bevor Schnittstellen gebaut und Support-Teams involviert sind.

Eine trockene Warnung dazu: Viele Firmen nennen etwas einen Proof of Concept, obwohl sie direkt in einen instabilen Piloten gesprungen sind. Das bedeutet meistens echte Nutzer, eine unfertige Integration und gerade genug Sichtbarkeit, um politischen Druck zu erzeugen, aber ohne die nötige Design-Disziplin. Das ist kein Proof of Concept, sondern ein operatives Risiko mit einem schöneren Etikett. Wenn der Prototyp dieser Prüfung standhält, wird die Geldfrage erst richtig ernst.

Abschnitt 5: Prüfen Sie den ROI mit konservativen Zahlen, sonst ist es kein Business Case

An diesem Punkt wird das Papier meistens sehr geduldig und optimistisch. Die prognostizierten Einsparungen gehen von sauberen Daten, stabiler Nutzung und null Widerstand im Team aus, während die Fehlerbehandlung fast komplett ignoriert wird. Mit anderen Worten: Die Kalkulation nimmt eine Welt an, die so nicht existiert, und sechs Monate später wundert man sich dann, warum die versprochene Rendite ausbleibt.

Ein tragfähiger Business Case beginnt mit einer Nullmessung, nicht mit einem Wunschziel. Sie müssen wissen, was der aktuelle Prozess Sie heute wirklich kostet, und zwar im Live-Betrieb und nicht nur in der Theorie. Wie hoch sind die Fehlerkosten, was verschlingt die Nacharbeit, und wo entstehen durch Verzögerungen Folgekosten in anderen Abteilungen? Rechnen Sie aus, wie viel Aufwand in Korrekturen, Klärungen und Eskalationen fließt und wie viel Durchsatz verloren geht, weil Mitarbeiter auf Informationen warten oder Schritte manuell prüfen müssen.

Diese Basis ist entscheidend, weil Einsparungen durch KI am Anfang oft indirekt sind. Sie werden vielleicht keine Stellen abbauen, aber Sie reduzieren die Verschwendung rund um die eigentliche Arbeit. Das kann ein hervorragendes Ergebnis sein, aber nur, wenn Sie es von Anfang an ehrlich messen.

Planen Sie deshalb konservativ und rechnen Sie nur mit einem Teil der erwarteten Ersparnis. Wenn ein Modell sagt, dass eine Aufgabe um die Hälfte verkürzt werden könnte, bauen Sie den Business Case nicht auf diesem Maximalwert auf. Nutzen Sie einen kleineren Anteil und lassen Sie das System den Rest später erst beweisen. Planen Sie außerdem einen Puffer ein, da Integration und Kontrollprozesse immer komplizierter sind, als sie im ersten Meeting wirken. Gehen Sie von einer längeren Amortisationszeit aus, als das Marketing-Deck des Anbieters verspricht, denn deren Job ist es, den Verkaufszyklus zu verkürzen, während Ihr Job darin besteht, die operative Realität zu überleben.

Was bedeutet das konkret für Sie? Wenn die erste Schätzung zu gut aussieht, machen Sie den Stresstest: Reduzieren Sie den Nutzen, verlängern Sie die Anlaufphase und planen Sie mehr Zeit für Support ein. Wenn der Anwendungsfall unter diesen harten Bedingungen immer noch sinnvoll ist, haben Sie etwas Solides in der Hand. Wenn er nur unter perfekten Bedingungen funktioniert, ist es kein Business Case, sondern eine Verkaufsgeschichte.

Erste Erfolge können sich schnell auszahlen, das kommt vor, aber meistens nur, wenn der Fokus scharf und die Metrik vor dem Start klar definiert war. Wenn Sie zu breit anfangen und die Erfolgskriterien mittendrin ändern, wird das Ergebnis politisch statt operativ. Dann sagt die eine Gruppe, der Pilot war ein Erfolg, während die andere behauptet, er habe mehr Arbeit verursacht als gelöst, und am Ende haben beide recht, weil niemand rechtzeitig den Maßstab festgelegt hat.

Bedenken Sie auch, dass ROI nicht nur aus der Reduzierung von Arbeitszeit besteht. Viele Firmen greifen hier zu kurz, dabei liegt der Wert oft in besserer Qualität, schnelleren Durchlaufzeiten oder weniger Eskalationen, die auf dem Schreibtisch der Geschäftsführung landen. Es geht um weniger Compliance-Fehler und einen besseren Zugriff auf Wissen, das vorher in Postfächern oder den Köpfen erfahrener Mitarbeiter feststeckte. Diese Effekte sind real, sie müssen nur an einen konkreten Prozess und eine messbare Kennzahl gekoppelt werden.

Auf der anderen Seite stehen die laufenden Kosten, die genauso viel Aufmerksamkeit brauchen. Lizenzen sind dabei nur der sichtbare Teil der Rechnung. Rechnen Sie die Integration, das Monitoring, die Schulungen und den Governance-Aufwand mit ein, ebenso wie das Risiko, von einem einzigen Anbieter abhängig zu werden. Ein günstiger Einstieg wird schnell teuer, wenn jede Änderung und jede Erweiterung Sie tiefer in die Logik eines Herstellers drückt.

Die Entscheidung sollte daher direkt ausfallen: Wenn Sie die Basis, den Verantwortlichen, die Metrik und einen Plan B nicht benennen können, haben Sie noch keinen Anwendungsfall. Sie haben eine Idee, und Ideen sind gut, aber sie sollten nicht wie fertige Betriebsmodelle finanziert werden. Der letzte Schritt ist dann eigentlich ganz einfach: Stellen Sie früher die harten Fragen.

Fazit: Was Sie tun sollten, bevor Sie das nächste KI-Projekt freigeben

Seien wir ehrlich, der Wechsel zu einer vernünftigen Strategie ist nicht kompliziert, aber er ist unbequem für Unternehmen, die sich am liebsten zuerst Demos zeigen lassen. Gute Entscheidungen beim Thema KI fallen lange vor der Auswahl eines Tools, denn sie fangen bei der Klarheit Ihrer Prozesse, der Qualität Ihrer Daten und der Frage nach der Verantwortung an.

Nehmen Sie sich einen geplanten Anwendungsfall vor und schieben Sie ihn durch einen deutlich härteren Filter. Definieren Sie das Problem präzise und bewerten Sie den echten Nutzen sowie die technische Machbarkeit, bevor Sie überhaupt über eine Automatisierung nachdenken. Testen Sie den Workflow manuell und bauen Sie eine solide Kalkulation für die Rentabilität auf, noch bevor jemand das Wort Rollout in den Mund nimmt.

Holen Sie dafür die richtigen Leute an einen Tisch, also die IT, die Rechtsabteilung und vor allem die Mitarbeiter, die das System täglich nutzen sollen. Es reicht nicht aus, wenn nur die Budgetverantwortlichen im Raum sitzen, da die Architektur und die Weichenstellungen vor der Einführung über den Erfolg entscheiden und nicht die hübsche Oberfläche einer Präsentation.

Wenn diese Fragen unbeantwortet bleiben, sieht die Rechnung am Anfang vielleicht noch akzeptabel aus, aber das operative Risiko wird es sicher nicht sein.

Das war IT for Business.

Wenn Sie aus dieser Folge etwas mitnehmen, dann vielleicht das: Gute IT entscheidet sich nicht im Tool, sondern in der Architektur und den harten Entscheidungen davor.

Wenn Ihnen die Folge gefallen hat, abonnieren Sie den Podcast, damit Sie keine weiteren Einblicke in IT-Entscheidungen aus der Praxis verpassen.

Falls Sie selbst gerade vor einer Modernisierung stehen, stellen Sie die schwierigen Fragen früh und nicht erst, wenn das Kind im Betrieb schon in den Brunnen gefallen ist.

Bis zur nächsten Folge.