Stell dir vor, du hast sechs Monate Arbeit und ein Budget im mittleren fünfstelligen Bereich in ein System investiert, das auf dem Papier perfekt aussah. Die Dashboards leuchten grün, die Architekturvorgaben wurden eingehalten, und trotzdem sitzen deine besten Leute frustriert vor den Bildschirmen, weil die Datenflüsse stocken und die Logik an entscheidenden Stellen bricht. Ich habe genau dieses Szenario in den letzten zehn Jahren immer wieder erlebt: Unternehmen investieren Unmengen in Technik, ignorieren aber das warnende Bauchgefühl derer, die täglich damit arbeiten müssen. Oft ist der Grund für diesen schleichenden Verfall schlichtweg die Tatsache, dass Something Is Not Right Bl im Kern der operativen Struktur nicht adressiert wurde. Es ist dieser Moment, in dem die Theorie der Praxis begegnet und kläglich versagt, weil niemand den Mut hatte, den Prozess zu stoppen, als die ersten Risse sichtbar wurden. Wer hier nur nach Schema F arbeitet, verbrennt Geld schneller, als die Buchhaltung hinschauen kann.
Die Falle der blinden Prozessgläubigkeit und Something Is Not Right Bl
Einer der teuersten Fehler, den ich in der Beratung sehe, ist das unerschütterliche Vertrauen in starre Prozesse. Manager glauben oft, dass ein einmal festgelegter Workflow alle Probleme löst. In der Realität führen diese starren Strukturen oft dazu, dass Probleme zwar bemerkt, aber nicht gemeldet werden, weil „der Prozess es so vorsieht.“
Ich erinnere mich an einen Fall bei einem mittelständischen Logistikunternehmen. Sie hatten ein neues Warenwirtschaftssystem eingeführt. Alles war nach DIN-Normen und Best Practices durchgeplant. Nach drei Wochen stellten die Mitarbeiter im Lager fest, dass die Etikettierung für Sonderversandstücke systematisch falsch lief. Anstatt den Fehler sofort zu korrigieren, wurde er ignoriert, weil die Software-Schnittstelle keine Ausnahme zuließ. Das Ergebnis waren Rücksendekosten von fast 40.000 Euro innerhalb eines Monats. Hier zeigt sich die harte Realität: Wenn das Team spürt, dass Something Is Not Right Bl die Effizienz untergräbt, aber keine Handhabe hat, einzugreifen, entstehen enorme Opportunitätskosten.
Die Lösung ist hier nicht mehr Kontrolle, sondern radikale Transparenz und die Erlaubnis zum Stopp. In der Fertigung nennt man das den „Andon-Draht“ – jeder darf das Band anhalten, wenn ein Fehler auftaucht. In der Wissensarbeit oder bei komplexen IT-Projekten müssen wir eine ähnliche Kultur schaffen. Man muss Fehlentwicklungen benennen dürfen, ohne als Bremser zu gelten. Es bringt nichts, eine Strategie durchzupeitschen, die offensichtlich gegen die Wand fährt. Ein guter Praktiker weiß, dass ein früher Abbruch oder ein massives Umsteuern zehntausende Euro spart, während das „Durchhalten“ meist nur das Ego der Führungsebene rettet.
Der Mythos der perfekten Datenbasis
Ein weiterer Punkt, an dem viele scheitern, ist die Jagd nach der hundertprozentigen Datenkorrektheit vor dem Start. Viele Projekte kommen nie aus der Pilotphase heraus, weil die Beteiligten glauben, sie bräuchten erst den perfekten Datensatz. Das ist Quatsch. Ich habe Projekte gesehen, die zwei Jahre lang nur Daten bereinigt haben, ohne jemals einen Euro Wertschöpfung zu generieren.
Warum Unvollkommenheit dein Freund ist
Man muss lernen, mit „gut genug“ zu arbeiten. Das bedeutet nicht Schlamperei. Es bedeutet, die kritischen 20 Prozent der Daten zu identifizieren, die 80 Prozent des Ergebnisses liefern. In der Praxis sieht das so aus: Du nimmst die vorhandenen Rohdaten, lässt sie durch dein Modell oder deinen Prozess laufen und schaust, wo es knallt. Diese Reibungspunkte sind viel wertvoller als jede theoretische Datenbereinigung im Vorfeld. Wer versucht, jedes kleine Detail vorab zu klären, verliert den Anschluss am Markt. Die Konkurrenz ist dann schon drei Schritte weiter, während du noch über Formatierungen streitest.
Warum externe Berater oft das Problem verschärfen
Es klingt paradox, aber oft ist der externe Rat der Anfang vom Ende. Berater kommen mit Standard-Templates, die in der Theorie bei zehn anderen Firmen funktioniert haben. Aber deine Firma ist nicht diese zehn anderen Firmen. Der Fehler liegt darin, externe Konzepte eins zu eins über die eigene Betriebskultur zu stülpen.
Ich habe erlebt, wie ein Konzern versuchte, agile Arbeitsmethoden einzuführen, nur weil ein großes Beratungshaus das als den heiligen Gral verkaufte. Sie stellten alles um, führten Daily Stand-ups ein und klebten alles mit Post-its voll. Doch die Entscheidungswege blieben hierarchisch. Die Mitarbeiter standen also jeden Morgen 15 Minuten zusammen, nur um danach drei Tage auf eine Freigabe vom Abteilungsleiter zu warten. Das ist nicht nur ineffizient, das ist psychologische Folter für motivierte Leute.
Der richtige Weg ist die schrittweise Anpassung. Man nimmt sich ein Element, testet es in einer kleinen Abteilung und schaut, ob es die Arbeit wirklich erleichtert. Wenn die Leute sagen, das hilft mir nicht, dann fliegt es raus. Egal, wie viel das Template gekostet hat. Wahre Expertise zeigt sich darin, Dinge wegzulassen, nicht darin, das System immer komplexer zu machen.
Ein Vorher-Nachher-Vergleich aus der Praxis
Schauen wir uns an, wie sich ein klassischer Fehlansatz im Vergleich zu einer praxisnahen Lösung schlägt. Nehmen wir das Beispiel einer Einführung von automatisierten Kundenantworten im Support.
Der falsche Ansatz (Vorher): Das Unternehmen entscheidet, die Kosten im Support um 50 Prozent zu senken. Ein Projektteam wird aufgesetzt, das über vier Monate einen komplexen Entscheidungsbaum entwirft. Jede denkbare Kundenanfrage wird kategorisiert. Man kauft eine teure Softwarelizenz und rollt das System für alle Kunden gleichzeitig aus. Nach zwei Wochen bricht der Support zusammen. Die Kunden sind wütend, weil die Automatisierung ihre spezifischen Probleme nicht versteht. Die Mitarbeiter sind überlastet, weil sie nun zusätzlich zu den normalen Anfragen auch noch die Fehler des Systems korrigieren müssen. Die Kosten steigen sogar, statt zu sinken, weil die Fluktuation im Team zunimmt und Kunden abwandern.
Der praxisnahe Ansatz (Nachher): Anstatt das ganze System auf einmal zu ändern, setzt man sich zwei Tage lang mit den Support-Mitarbeitern zusammen. Man identifiziert die drei häufigsten Fragen, die wirklich nerven und leicht zu automatisieren sind – zum Beispiel die Frage nach dem Lieferstatus. Man baut eine einfache Lösung nur für diese drei Fragen und testet sie bei 10 Prozent der Kunden. Man stellt fest, dass die Kunden die schnelle Antwort beim Lieferstatus lieben, aber bei Reklamationen sofort einen Menschen brauchen. Man weitet das System nur auf die funktionierenden Bereiche aus. Nach drei Monaten sind 30 Prozent der Anfragen automatisiert, die Mitarbeiter haben mehr Zeit für komplexe Fälle, und die Kundenzufriedenheit steigt leicht an. Die Kostenersparnis ist real, weil sie auf tatsächlicher Arbeitsentlastung basiert, nicht auf einer theoretischen Wunschvorstellung.
Die unterschätzte Rolle der impliziten Reibung
In jedem Betrieb gibt es Reibungsverluste, die in keinem Reporting auftauchen. Ich nenne das „Schatten-Arbeit.“ Das sind all die Workarounds, die Mitarbeiter bauen, um mit schlechten Systemen arbeiten zu können. Excel-Listen, die neben der Hauptsoftware geführt werden, manuelle E-Mails, um Bestätigungen zu erhalten, die das System eigentlich schicken sollte.
Wenn du Something Is Not Right Bl in deinem Unternehmen spürst, liegt es meist an dieser Schatten-Arbeit. Die Leute arbeiten gegen das System, um ihre Arbeit überhaupt erledigen zu können. Wenn man hier nicht genau hinschaut, optimiert man an der Oberfläche, während der Kern verrottet. Ich habe Unternehmen gesehen, die stolz auf ihre digitalisierten Prozesse waren, während die Mitarbeiter im Hintergrund hunderte Kopien von Dokumenten händisch unterschrieben und eingescannt haben, weil die digitale Signatur zu kompliziert war.
Um das zu lösen, musst du „Go to the Gemba“, wie man im Lean Management sagt. Geh dahin, wo die Arbeit passiert. Setz dich zwei Stunden neben den Sachbearbeiter und schau ihm über die Schulter. Frag nicht nach seiner Meinung, sondern beobachte seine Klicks. Du wirst erstaunt sein, wie viel Zeit durch unnötige Klicks und schlecht platzierte Buttons verloren geht. Das ist kein Kleinkram. Das ist der Unterschied zwischen einer hochprofitablen Einheit und einer, die gerade so überlebt.
Technologischer Übereifer und die Kosten der Komplexität
Wir leben in einer Zeit, in der uns ständig neue Wunderwaffen versprochen werden. KI hier, Blockchain da, Big Data überall. Die Wahrheit ist: Die meisten Probleme in deutschen Unternehmen lassen sich mit sauberer Logik und einer vernünftigen Datenbank lösen. Der Drang, immer das Neueste einzusetzen, führt oft zu einer Komplexität, die niemand mehr beherrscht.
Komplexität ist ein Kostentreiber, der sich exponentiell verhält. Jede neue Schnittstelle, jedes zusätzliche Tool muss gewartet, gesichert und geschult werden. In meiner Zeit als Berater habe ich mehr Projekte durch Vereinfachung gerettet als durch das Hinzufügen neuer Features. Ein System, das nur 80 Prozent der Funktionen hat, aber von jedem im Team blind bedient werden kann, ist tausendmal mehr wert als eine High-End-Lösung, für die man jedes Mal einen externen Spezialisten einfliegen lassen muss, wenn sich ein Parameter ändert.
Hier greift ein Prinzip, das oft ignoriert wird: Die Wartbarkeit steht über der Funktionalität. Wenn dein IT-Team nachts nicht schlafen kann, weil das System so fragil ist, dann hast du ein massives unternehmerisches Risiko. Ein stabiler, langweiliger Prozess ist in der Wirtschaft fast immer besser als ein innovativer, instabiler Prozess.
Der Realitätscheck
Kommen wir zum Punkt, an dem wir die Wunschvorstellungen beiseiteschieben. Erfolg in diesem Bereich hat nichts mit genialen Geistesblitzen oder teuren Tools zu tun. Es ist harte, oft langweilige Detailarbeit. Es geht darum, jeden Tag genau hinzuschauen, wo Sand im Getriebe ist, und diesen Sand konsequent zu entfernen.
Du musst akzeptieren, dass es keine Abkürzung gibt. Wenn du versuchst, ein strukturelles Problem durch den Kauf einer Software zu lösen, hast du danach zwei Probleme: das alte strukturelle Problem und eine teure Software, die nicht richtig funktioniert. Echter Fortschritt tut oft weh, weil er bedeutet, alte Zöpfe abzuschneiden und zuzugeben, dass man sich verrannt hat.
Wer gewinnen will, braucht keine Motivationssprüche, sondern eine Fehlerkultur, die den Namen verdient. Das bedeutet, dass man Scheitern als Information begreift. Wenn etwas nicht klappt, ist das kein Weltuntergang, sondern ein Hinweis darauf, dass der aktuelle Weg nicht der richtige ist. Wer das verstanden hat, hört auf, Zeit und Geld in tote Pferde zu investieren. Er steigt ab, schaut sich um und sucht sich einen neuen Weg. Das ist nicht spektakulär, aber es ist das Einzige, was auf lange Sicht funktioniert. Es gibt keinen magischen Schalter, den man umlegt. Es gibt nur das Handwerk, die Beobachtung und die ständige Korrektur. Wer das nicht akzeptiert, wird weiterhin Lehrgeld bezahlen – und zwar weit mehr, als nötig wäre.
