Es ist Montagmorgen, drei Uhr nachts. Ein IT-Leiter in einem mittelständischen Unternehmen in Stuttgart starrt auf seinen Monitor, während die Fehlermeldungen im Sekundentakt über den Bildschirm jagen. Er hat sechs Monate Arbeit und fast zweihunderttausend Euro in ein System investiert, das auf dem Papier perfekt aussah. Die Idee war simpel: Die Implementierung von The Thing That Should Not Be sollte die Effizienz steigern und manuelle Prozesse eliminieren. Doch jetzt, im Live-Betrieb, bricht alles zusammen. Der Grund ist nicht die Technik an sich, sondern ein fundamentaler Denkfehler in der Planung. Ich habe dieses Szenario in den letzten zehn Jahren bei Dutzenden von Kunden miterlebt. Oft fängt es mit einer optimistischen PowerPoint-Präsentation an und endet in einer teuren Rettungsaktion, bei der wir versuchen, die Trümmer eines gescheiterten Projekts irgendwie wieder zusammenzuflicken.
Die Illusion der Automatisierung ohne saubere Datengrundlage
Einer der häufigsten Fehler, die ich sehe, ist der Versuch, komplexe Abläufe zu digitalisieren, bevor die zugrunde liegenden Daten überhaupt eine Struktur haben. Viele glauben, dass die Technik das Chaos magisch ordnen wird. Das Gegenteil ist der Fall. In der Praxis wirkt dieses System wie ein Brennglas: Es macht bestehende Probleme nicht weg, sondern vergrößert sie drastisch.
Nehmen wir ein typisches Beispiel aus der Logistik. Ein Unternehmen wollte seine Lagerhaltung optimieren. Vorher gab es handgeschriebene Listen und viel „Bauchgefühl“ der langjährigen Mitarbeiter. Das hat irgendwie funktioniert, weil Menschen Nuancen verstehen. Dann kam die Umstellung auf eine automatisierte Lösung. Da die Datenqualität der alten Bestände miserabel war, spuckte das neue System ständig unmögliche Befehle aus. Gabelstaplerfahrer wurden zu leeren Regalen geschickt, während die eigentliche Ware in der prallen Sonne auf dem Hof vergammelte.
Die Lösung klingt banal, wird aber fast immer ignoriert: Man muss die Daten bereinigen, bevor man den ersten Cent in die neue Software steckt. Das bedeutet Wochen, manchmal Monate harter Arbeit in Excel-Tabellen und Datenbanken. Wer diesen Schritt überspringt, zahlt später das Zehnfache für Fehlerkorrekturen im laufenden Betrieb. Es gibt keine Abkürzung. Wenn die Basis nicht stimmt, ist jede darauf aufbauende Struktur instabil.
Warum The Thing That Should Not Be kein Selbstläufer für die IT ist
Es herrscht oft die falsche Annahme vor, dass die IT-Abteilung allein für den Erfolg verantwortlich ist. Das ist kompletter Unsinn. In meiner Zeit als Berater habe ich Projekte gesehen, die technisch brillant waren, aber von den Fachabteilungen schlicht boykottiert wurden. Das passiert immer dann, wenn die Technik an den tatsächlichen Bedürfnissen der Anwender vorbeigeplant wird. The Thing That Should Not Be erfordert eine enge Verzahnung zwischen denen, die den Code schreiben, und denen, die am Ende damit arbeiten müssen.
Ein klassisches Missverständnis betrifft die Wartbarkeit. Viele Unternehmen kaufen eine Lösung ein, setzen sie einmal auf und denken, das Thema sei erledigt. Aber Software ist kein Toaster, den man einmal einschaltet und dann jahrelang vergisst. Sie gleicht eher einem Garten. Wenn man sich nicht ständig darum kümmert, übernimmt das Unkraut die Kontrolle. Das bedeutet, man braucht internes Personal, das die Logik hinter der Anwendung wirklich versteht. Ein externer Dienstleister ist gut für den Start, aber wer sich dauerhaft abhängig macht, verliert die Kontrolle über seine eigenen Prozesse und zahlt bei jeder kleinen Änderung horrende Stundensätze.
Die Kostenfalle bei der Skalierung unterschätzen
Viele fangen klein an, was eigentlich lobenswert ist. Doch sie vergessen dabei, wie sich die Kosten entwickeln, wenn das Volumen steigt. Ich habe ein Startup begleitet, das eine Cloud-basierte Strategie verfolgte. Anfangs kostete die Infrastruktur nur ein paar hundert Euro im Monat. Als die Nutzerzahlen stiegen, explodierten diese Kosten plötzlich auf fünfstellige Beträge pro Woche. Sie hatten die Architektur so gebaut, dass jede Anfrage unnötig viele Ressourcen fraß.
Die Architektur der versteckten Gebühren
Oft sind es die API-Aufrufe oder die Datentransferraten, die einem das Genick brechen. Wer hier nicht von Anfang an auf Effizienz trimmt, baut sich eine finanzielle Zeitbombe. Ein falsches Caching-Konzept kann dazu führen, dass dieselbe Information tausendfach pro Sekunde neu berechnet werden muss, anstatt sie einmal im Speicher vorzuhalten. Das ist kein theoretisches Problem, sondern schlägt sich eins zu eins in der monatlichen Abrechnung nieder.
Ein Blick auf Studien des Fraunhofer-Instituts für Materialfluss und Logistik (IML) zeigt oft, wie wichtig die Skalierbarkeit von Systemen in der Industrie 4.0 ist. Dort wird deutlich, dass starre Systeme, die nicht mitwachsen können, langfristig die Wettbewerbsfähigkeit deutscher Unternehmen gefährden. Man muss von Anfang an wissen: Was passiert, wenn wir nicht 100, sondern 100.000 Transaktionen pro Stunde haben? Wer diese Frage erst stellt, wenn es so weit ist, hat bereits verloren.
Das Problem mit den fertigen Lösungen von der Stange
Es gibt diesen verlockenden Gedanken, man könne einfach ein fertiges Paket kaufen, es installieren und fertig. „Out of the box“ ist das Lieblingswort jedes Vertrieblers, aber in der Realität bedeutet es oft „passt nirgends richtig“. Jedes Unternehmen hat eigene, gewachsene Prozesse. Wenn man versucht, diese Prozesse gewaltsam in eine starre Software-Vorgabe zu pressen, bricht meistens der Workflow der Mitarbeiter.
Ich erinnere mich an einen Fall im Maschinenbau. Die Geschäftsführung wollte eine Standard-Software für die Produktionsplanung einführen. Die Software verlangte, dass jeder Schritt exakt dokumentiert wird, bevor der nächste beginnen kann. In der Werkstatt war es aber oft nötig, zwei Schritte parallel zu machen, um Zeit zu sparen. Das Ende vom Lied: Die Mitarbeiter führten Schatten-Listen auf Papier, um arbeiten zu können, und trugen am Abend irgendwelche fiktiven Daten in das System ein, damit der Chef zufrieden war. Die Daten im System waren somit wertlos.
Die Lösung ist ein hybrider Weg. Man nutzt den Standard für die Grundlagen, aber man muss bereit sein, in individuelle Anpassungen zu investieren, wo es um die Kernkompetenz des Unternehmens geht. Wer seine Alleinstellungsmerkmale für eine Standard-Software opfert, gibt seinen Wettbewerbsvorteil auf. Das ist ein hoher Preis für eine vermeintlich einfache Installation.
Vergleich der Ansätze: Theorie gegen harte Praxis
Schauen wir uns an, wie zwei verschiedene Firmen an die Sache herangingen. Firma A folgte dem klassischen Lehrbuchweg, während Firma B den pragmatischen, erfahrungsbasierten Ansatz wählte.
Vorher: Der optimistische Plan von Firma A Firma A kaufte eine teure Lizenz und beauftragte eine große Unternehmensberatung. Es wurden hunderte Seiten Dokumentation erstellt. Man versprach sich eine Reduktion der Durchlaufzeiten um 40 Prozent innerhalb des ersten Quartals. Die Mitarbeiter wurden in zweitägigen Massen-Schulungen „fit gemacht“. Als das System live ging, stellte man fest, dass die Schnittstelle zum alten ERP-System instabil war. Die Produktion stand drei Tage lang still, weil keine Aufträge mehr durchkamen. Die Kosten für den Ausfall überstiegen die gesamten Projektkosten innerhalb einer Woche. Nach einem Jahr wurde das Projekt stillschweigend beerdigt, und man kehrte zu den alten Methoden zurück – mit frustrierten Mitarbeitern und einem riesigen Loch im Budget.
Nachher: Der schrittweise Erfolg von Firma B Firma B hingegen begann mit einem kleinen Pilotprojekt in einer einzigen Abteilung. Ich riet ihnen, erst einmal die bestehenden Prozesse manuell zu optimieren, bevor sie Code schreiben ließen. Sie identifizierten die drei größten Flaschenhälse und bauten dafür eine maßgeschneiderte Lösung, die sich nahtlos in die bestehende Umgebung einfügte. Statt Schulungen gab es eine Begleitung am Arbeitsplatz durch interne Multiplikatoren. Die Kosten waren anfangs höher pro Nutzer, aber es gab keinen Produktionsstopp. Nach sechs Monaten wurde das System auf die nächste Abteilung ausgeweitet. Die Fehlerquote sank kontinuierlich, weil das System mit den Erfahrungen der Nutzer wuchs. Heute, zwei Jahre später, ist das gesamte Unternehmen umgestellt, und die Effizienzgewinne sind messbar und nachhaltig.
Die psychologische Komponente der Veränderung
Man unterschätzt leicht, wie sehr Menschen ihre gewohnten Arbeitsweisen verteidigen. Jede neue Technologie wird erst einmal als Bedrohung wahrgenommen. Wenn man The Thing That Should Not Be einführt, ohne die Leute mitzunehmen, bekommt man passiven Widerstand. Das äußert sich in schlampiger Dateneingabe, dem Auslassen von Schritten oder der ständigen Behauptung, das System sei „kaputt“.
Ich habe gelernt, dass man die größten Kritiker zu den wichtigsten Beratern im Projekt machen muss. Wenn der erfahrenste Meister in der Werkstatt sagt: „Das funktioniert so nicht“, dann hat er meistens recht. Ignoriert man ihn, scheitert das Projekt. Bindet man ihn ein und lässt ihn die Oberfläche mitgestalten, wird er zum Fürsprecher. Das kostet Zeit und Nerven in der Konzeptionsphase, spart aber Monate an Ärger nach dem Rollout. Es geht nicht nur um Bits und Bytes, sondern um Akzeptanz. Wer nur auf die Technik starrt, ist blind für die menschlichen Dynamiken, die über Erfolg oder Misserfolg entscheiden.
Sicherheitsrisiken durch Komplexität und Unwissenheit
Ein oft vernachlässigter Aspekt ist die Sicherheit. Je komplexer ein System wird, desto mehr Angriffsfläche bietet es. Viele Firmen öffnen Schnittstellen nach außen, ohne über die Konsequenzen nachzudenken. Ich habe Systeme gesehen, bei denen sensible Kundendaten quasi ungeschützt über das Internet übertragen wurden, weil jemand beim Aufsetzen der API vergessen hatte, die Authentifizierung zu aktivieren. Das ist grob fahrlässig.
In Deutschland sind die Anforderungen durch die DSGVO (Datenschutz-Grundverordnung) sehr hoch. Verstöße können Millionen kosten. Man kann Sicherheit nicht einfach am Ende „drüberstülpen“. Sie muss Teil des Designs sein. Das bedeutet, dass man von Anfang an über Verschlüsselung, Zugriffskontrollen und Logging nachdenken muss. Viele scheuen diese Zusatzkosten, aber ein einziger erfolgreicher Hackerangriff kann eine Firma in den Ruin treiben. In meiner Praxis ist Sicherheit kein „Feature“, sondern die Grundvoraussetzung für alles andere.
- Datensparsamkeit konsequent umsetzen: Nur das speichern, was wirklich gebraucht wird.
- Regelmäßige Penetrationstests durchführen lassen, um Schwachstellen zu finden.
- Mitarbeiterschulungen für IT-Sicherheit ernst nehmen, nicht als Pflichtübung abhaken.
- Backupsysteme nicht nur einrichten, sondern auch das Wiederherstellen regelmäßig üben.
Diese Liste ist nicht vollständig, aber sie deckt die Punkte ab, die am häufigsten schiefgehen. Oft sind es die einfachsten Dinge, wie ein Admin-Passwort, das nie geändert wurde, die zum Desaster führen.
Realitätscheck
Kommen wir zum Punkt: Erfolg in diesem Bereich ist kein Zufall und auch kein Ergebnis von massivem Geldeinsatz. Es ist das Resultat von Disziplin und Ehrlichkeit sich selbst gegenüber. Wenn Sie glauben, dass Sie mit einem einmaligen Kraftakt und einer Stange Geld alle Ihre Probleme lösen können, werden Sie scheitern. So funktioniert das nicht.
In der Realität ist der Weg steinig. Sie werden auf unerwartete technische Hürden stoßen, Ihre besten Mitarbeiter werden fluchen, und der Zeitplan wird wahrscheinlich mindestens einmal ins Wanken geraten. Erfolg bedeutet hier, dass Sie ein System schaffen, das einen echten Mehrwert bietet, stabil läuft und von den Menschen tatsächlich genutzt wird. Das erfordert Ausdauer. Sie müssen bereit sein, tief in die Details Ihrer eigenen Prozesse einzutauchen, auch wenn das unangenehm ist.
Hören Sie auf, nach der „magischen Lösung“ zu suchen, die alles per Knopfdruck erledigt. Konzentrieren Sie sich stattdessen auf saubere Daten, eine Architektur, die auch in zwei Jahren noch Sinn ergibt, und vor allem auf Ihre Leute. Wenn Sie das tun, haben Sie eine echte Chance. Wenn nicht, sehen wir uns vermutlich in einer nächtlichen Rettungsaktion wieder, wenn das Kind bereits in den Brunnen gefallen ist. Es liegt an Ihnen, ob Sie jetzt die harte Arbeit investieren oder später für den teuren Fehler bezahlen wollen. Wer klug ist, wählt die Arbeit. Es ist am Ende der günstigere Weg.
