Weil Kunden fast nie wissen, was ihr eigentliches Problem ist, nur was sie dafür halten. Bei 80 Prozent der Projekte war genau das falsch eingeschätzt, und am Ende wurde die falsche Lösung gebaut. Diagnose vor dem Bauen deckt auf, wer im Unternehmen wirklich betroffen ist, bevor Geld und Zeit in die falsche Richtung fließen.
Ich habe lange genau das gemacht, was Kunden mir gesagt haben. Jemand kam mit einem Problem, ich habe eine Lösung gebaut, fertig. Das klang nach einem sauberen Prozess, und eine Weile hat es sich auch so angefühlt. Bis ich anfing, genauer hinzusehen, was aus diesen Projekten tatsächlich geworden ist. Die Zahlen, die dabei herauskamen, haben mich selbst überrascht, und sie haben mich gezwungen, meine gesamte Arbeitsweise neu zu denken.
80 Prozent der Projekte lösten das falsche Problem
Am Anfang war die Methode simpel. Erste Frage an jeden Kunden: Was ist dein größtes Problem? Dann habe ich genau dieses Problem gelöst, so gut ich konnte, mit viel strategischem Denken dahinter. Das hat sich lange richtig angefühlt, bis ich festgestellt habe, dass bei 50 Prozent der Projekte das eigentliche Problem ein anderes war als das, was mir gesagt wurde. Kurz darauf wurde daraus eine noch härtere Zahl: fast 80 Prozent der Projekte waren in die falsche Richtung gebaut, weil der Kunde selbst nicht wusste, was er eigentlich braucht. Nicht weil er gelogen hat. Er kannte die eigentliche Ursache einfach nicht, und ich habe das auch nicht hinterfragt. Ich habe genommen, was er gesagt hat, und daraus eine Lösung gebaut. Das Problem war nur: Das war nicht das, was er wirklich gebraucht hätte. Wir hätten genauer zuhören müssen, bevor überhaupt eine Zeile Code geschrieben wurde.
Ein Detail am Anfang wird zum großen Problem am Ende
Ein Beispiel aus einem echten Projekt zeigt das gut. Es gab Techniker, die am Prozess beteiligt waren, aber nie gefragt wurden, ob die geplante Lösung für sie überhaupt umsetzbar ist. Ich habe daran damals auch nicht gedacht. Zu Beginn war das nur eine Randnotiz, eine Kleinigkeit, die niemand besonders ernst genommen hat. Am Ende wurde genau diese Kleinigkeit zum größten Hindernis im ganzen Projekt. Solche Fälle haben mir gezeigt, dass eine Lösung nie nur von einer Person aus gedacht werden darf. Man muss mit allen Beteiligten sprechen, nicht nur mit dem, der den Auftrag erteilt. Genau diese Einsicht hat mich zur Diagnose als eigenem Schritt geführt, als Voraussetzung, bevor überhaupt gebaut wird. Diese Details sehen am Anfang immer klein aus. Erst später zeigt sich, wie viel an ihnen hängt, und dann ist es oft schon zu spät, um sie noch günstig zu korrigieren.
Diagnose, Bildung und Anpassung als eigentliches Angebot
Mein erstes und wichtigstes Angebot heute ist die Diagnose, mit dem Ziel, zum echten KI-Transformationspartner eines Unternehmens zu werden. Dazu kommt ein Bildungsteil, in dem Mitarbeiter verstehen lernen, was KI für ihre tägliche Arbeit bedeutet, und ein Anpassungsteil, in dem die Lösung an das angepasst wird, was wirklich gebraucht wird. Diese drei Teile gehören für mich untrennbar zusammen. Ohne Diagnose baut man am Problem vorbei. Ohne Bildung versteht niemand im Unternehmen, warum die Lösung so aussieht, wie sie aussieht. Und ohne Anpassung bleibt jede Lösung starr, obwohl sich der Markt gerade so schnell verändert wie nie zuvor. Das macht die Arbeit komplizierter als reines Bauen, aber genau das war nötig, um Kunden tatsächlich weiterzubringen und nicht nur schnelle Lösungen abzuliefern, die am eigentlichen Bedarf vorbeigehen.
Custom Builds bleiben, aber erst nach der Diagnose
Beratung heißt für mich nicht, dass das Bauen verschwindet. Es heißt, dass das Bauen später kommt, nachdem klar ist, was wirklich gebraucht wird. Die meisten Unternehmen haben selbst keine sauberen Abläufe dokumentiert, und genau diese Abläufe müssen zuerst verstanden werden, bevor man sie in eine KI-Lösung übersetzen kann. Jeder Custom Build, den ich seither gebaut habe, hat mir dabei geholfen, das jeweilige Geschäft von innen zu verstehen. Das ist eine der besten Arten, wirklich etwas zu lernen. Gleichzeitig weiß ich, dass sich mein eigener Diagnoseprozess mit jedem Projekt verändern wird. Selbst beim elften Kunden in derselben Nische wird der Ablauf nicht mehr derselbe sein wie beim zehnten, weil sich auch der Markt in der Zwischenzeit weiterbewegt hat. Genau diese ständige Veränderung macht es unmöglich, einmal ein fertiges Schema zu bauen und es dann einfach zu wiederholen.
Fazit: Diagnose zahlt die Rechnungen, bis das eigentliche Geschäft gefunden ist
Beratung ist für mich nicht das Ziel. Sie ist der Weg dorthin, der gerade jetzt notwendig ist. Sie bezahlt die Rechnungen, während ich lerne, welches Geschäft ich wirklich aufbauen will. Ohne echten Kundenerfolg gibt es ohnehin keine langfristige Zukunft für ein Unternehmen, das KI-Lösungen anbietet, egal wie gut der Code ist. Also beginnt jedes Projekt heute mit der Frage, was das Unternehmen wirklich braucht, nicht mit der Frage, was zuerst gebaut werden soll. Custom Build kommt am Ende, wenn überhaupt, und wird dadurch zu etwas, das wirklich trägt, weil es auf einer echten Diagnose steht und nicht auf einer Vermutung. Genau dieser Unterschied entscheidet am Ende darüber, ob ein Kunde wirklich weiterkommt.