Excel stirbt nicht - es fault von innen

Der Moment, als ich mein eigenes System abschaffen wollte - und niemand verstand, warum

Ich saß in einem Meeting und sagte: “Wir müssen das Excel-System ablösen.” Die Reaktion? Stille. Dann: “Wieso? Das läuft doch.” Und das Witzige war: Sie hatten nicht mal Unrecht. Das System lief. Es hatte die Firma über zehn Jahre getragen. Ich hatte es selbst gebaut, Stück für Stück, Makro für Makro. Und jetzt wollte ausgerechnet ich es abschaffen.

Aber ich wusste: Das Ding fault von innen. Nicht weil es schlecht gebaut war - sondern weil die Anforderungen es überholt hatten. Und weil ich mich selbst zum Flaschenhals gemacht hatte.

Hier ist die Geschichte, wie aus einem cleveren Hack ein unwartbares Monster wurde - und was wir daraus gemacht haben.

Wie alles begann: “Das muss doch besser gehen”

Vor über zehn Jahren war lead link noch eine kleine Firma mit unter zehn Mitarbeitern. Aber auch damals mussten über 20 Kunden professionell betreut werden. Als Performance TV Agentur bedeutet das vor allem: Arbeit mit Daten. Buchungsübersichten aufbereiten, Reports erstellen, Auswertungen und Analysen fahren. Die Datenrealität war wild: Excel-Tabellen, EDI-Schnittstellen, teilweise gefaxte Pläne der TV-Sender.

Und ich? Ich hatte die schöne Aufgabe, das alles händisch zusammenzufahren, aufzubereiten, umzugestalten. Stundenlang Daten rumkopieren und formatieren wie ein Idiot. Irgendwann dachte ich mir: Das muss doch besser gehen.

Also hab ich angefangen. VBA konnte ich damals gar nicht - aber ich hab es mir einfach beigebracht. Rudimentär am Anfang, dann immer besser. Mehrere Fortbildungen, jahrelange Praxis. Am Ende hatte ich umfangreiche Makro-Systeme geschrieben, mit denen mehrere Abteilungen über Jahre gearbeitet haben. Ich war jung und brauchte die Effizienz.

Und es hat funktioniert. Richtig gut sogar.

Warum alle an Excel kleben - und warum das rational ist

Bevor ich hier jetzt Excel-Bashing betreibe: Excel ist ein unfassbar mächtiges Tool. Die Einstiegshürde ist niedrig, jeder kennt es, du brauchst kein Dev-Team. Ein VBA-Makro an einem Abend geschrieben und plötzlich geht ein Prozess zehnmal schneller. Die Tabelle sieht “fertig” aus, Stakeholder verstehen sie sofort.

Das ist kein Zufall, dass so viele Unternehmen ihre kritischsten Prozesse in Excel abbilden. Es ist der Path of Least Resistance. Und für eine kleine Firma war es genau die richtige Entscheidung. Kein Budget für eine “richtige” Lösung nötig, schnelle Ergebnisse, maximale Flexibilität.

Das Problem ist nicht, dass Excel schlecht ist. Das Problem ist, was passiert, wenn die Organisation wächst - und Excel nicht mitwächst.

Wann es kippt: Die Fehler-Hydra

Je mehr lead link wuchs und je mehr Leute parallel mit meinen Makros arbeiten mussten, desto deutlicher wurde: Das muss doch besser gehen.

Die Probleme kamen schleichend, nicht als Big Bang. Erst war alles bei mir - ich hatte die Makros, ich wusste wie sie funktionieren, ich war der einzige der VBA konnte. Dann hab ich sie bei anderen eingebaut. Und dann begann die Wartungshölle.

Über 50 Makros waren täglich im Einsatz. Jeder Kollege hatte leicht andere Versionen. Manches war individuell für Kunden angepasst. Wer was wann geändert hatte? Keine Ahnung. Versionierung? In Excel? Viel Spaß. Und Testing? Geht’s noch? Weiß keiner, bis es knallt.

Es wurde zur Fehler-Hydra: Jedes Problem, das man löste, ließ woanders zwei neue aufploppen.

Also hab ich ein AddIn entwickelt, das zentral abliegt und sich automatisch updaten lässt. Löste das Versionsproblem - aber nicht die anderen. Mehrere Leute, die parallel auf denselben Excel-Daten arbeiten: nervig und fehleranfällig. Datenverluste, die unnötig waren. Makro-Transformationen, die über 20 Minuten liefen, weil Kampagnen oft sechsstellige Spot-Anzahlen mit vielen Informationen haben - und viele Kampagnen und Kunden parallel laufen. Am Ende bist du halt in Excel. Vieles musste trotzdem manuell erstmal da rein.

Und dann die Personenabhängigkeit: Niemand sonst in der Firma konnte VBA. Niemand durchblickte die gewachsene Struktur. Wenn ich im Urlaub oder krank war und es gab ein Problem - hab ich es trotzdem gelöst. Ging ja nicht anders, die Firma kann nicht stillstehen. Schönes hausgemachtes Key-Man-Problem.

Eine fast schon lustige Anekdote dazu: Ich hatte mal ein Makro für Datentransformation geschrieben. Beim ersten Zeigen klickte ich zufällig in eine Tabellenzelle, bevor ich das Makro startete. Alles lief. Jahre später nutzt ein Kollege das Tool und macht exakt das Gleiche - klickt vor dem Start in eine bestimmte Zelle.

“Warum klickst du da rein?”, hab ich ihn gefragt.

“Mir wurde gesagt, dass man das für das Makro so machen muss.”

Eine komplette Tradition war entstanden! Dem Makro war natürlich komplett egal, wo man hinklickt. Aber wenn niemand das System wirklich versteht, entstehen solche Rituale. Das ist nicht lustig - das ist ein Warnsignal.

Die Entscheidung: Vom eigenen Baby loslassen

Die Entscheidung, das System abzulösen, ging von mir aus. Und so komisch das klingen mag: Ich musste intern dafür kämpfen. Die Haltung war klar: Wozu ablösen, es läuft doch. Was Neues bauen ist so viel Aufwand, Ausgang ungewiss.

Klar bin ich stolz auf etwas, das die Firma über zehn Jahre getragen hat. Aber Stolz ist kein Argument gegen eine bessere Lösung. Und wenn es besser geht - und sich auch lohnt, es umzusetzen - dann sollte man es besser machen. Gerade beim Herzstück der Datenverarbeitung.

Wie wir das Herz-Kreislauf-System im laufenden Betrieb ausgetauscht haben

Kein Big Bang. Modul für Modul, Schritt für Schritt. Nicht damit es besonders langsam geht, sondern damit wir in sinnvoller Reihenfolge erreichbare Ziele umsetzen können. Wir sind kein Meta mit tausenden internen Dev-Ressourcen - also muss das Vorgehen für uns Sinn ergeben.

Erst denken, dann coden

Bevor auch nur eine Zeile Code geschrieben wurde, haben wir uns Gedanken gemacht. Zielbild definieren. Verfeinern. Mit Externen die Umsetzungsoptionen prüfen. Im Workshop ein Grobkonzept erarbeiten, daraus ein Feinkonzept, das in einen Projektplan bringen. Ich arbeite dabei mit Use Cases - jeder Use Case ist ein Milestone, der einen alten Prozess in einen neuen überführt. Kleinstmöglich, aber in sich geschlossen.

Nicht um alles vorher bis ins letzte Detail durchzuplanen - das wäre Quatsch und gelogen. Aber um vorher genau zu wissen: Welche Maßnahme in welcher Reihenfolge soll welches Problem lösen?

Menschen mitnehmen - oder im Vakuum bauen

Ehrlich gesagt ist das ja viel mehr als ein technisches Thema. Es betrifft Prozesse, Organisation und am Ende die Menschen, die bei uns arbeiten.

Die erste Reaktion war natürlich ein lautes “Wieso?” Nicht aus Verweigerungshaltung, sondern weil solche Veränderungen Angst machen. Da sitzen Leute, deren Job es war, stundenlang alles mit den Makros zu machen - und das wird automatisiert. Klar denken die sich: Was heißt das für mich? Die anderen fragen sich: Muss ich umlernen? Ist dann überhaupt alles noch genauso gut?

Also haben wir kommuniziert. Immer wieder. Mein Job hat unfassbar viel mit Kommunikation zu tun. Wir haben das an Company Days vorgestellt, in einzelnen Workshops, in kleinen Check-Ins. Mein Favorit: Coffee Table Runden - nur fünf bis sieben Leute, kurz erklären was wir vorhaben, dann Raum für Fragen und Austausch. Das funktioniert in kleinen Runden so viel besser als in großen.

Jetzt kann man sagen: Spinnt der Typ, wie ineffizient - als CTO ewig viel Zeit mit Mitarbeiterkommunikation verbringen? Aber die Mitarbeiter sind die, die das System nutzen. Die das Feedback geben. Die die Inspiration liefern, was wir verbessern können. Wenn wir die auf dem Weg verlieren, hätte ich das Ding auch als Hobbyprojekt für mich alleine bauen können - und dann wäre alles sinnlos gewesen.

Das Herz-Kreislauf-System austauschen, während der Patient weiterläuft - kein Big Bang, sondern Modul für Modul

Was dabei herauskam (und was ehrlich gesagt nicht)

Unser neues System - PIX - hat heute über 45 angebundene Quellen unterschiedlichster Art, ein Microsoft Fabric Data Lakehouse und modernes Reporting. Die Ergebnisse sind messbar: Prozesse, die vorher bis zu 91 Minuten Durchlaufzeit hatten, wurden auf etwa 10 Minuten reduziert. Nicht alle gleichermaßen - manche “nur” um 50 Prozent. Aber auch das macht im Alltag einen riesigen Unterschied.

Und was mindestens genauso wichtig ist: Die mentale Last ist massiv gesunken. Wer sich schon mal durch eine Excel-Tabelle mit 40 Sheets, je 90 Spalten und 150.000 Zeilen geklickt hat, um eine Info zu finden, wird nachvollziehen können, wie einen das mental erschöpfen kann. Fehler werden jetzt systemisch verhindert - wo vorher eine Kette von Verarbeitungsschritten eine Vielzahl an potenziellen Fehlerquellen bot.

Und was lief nicht glatt? Wir haben die Komplexität der Quellen unterschätzt. Da schien uns am Anfang sehr klar, was wir anbinden wollen. Aber wenn von 45+ Quellsystemen plötzlich bei verschiedenen die wildesten Probleme auftauchen - mal ändert sich die Codierung von Anlieferung zu Anlieferung, mal werden die gleichen Sachen unterschiedlich benannt, die Datei die immer deutsch kam kommt plötzlich mal englisch - dann hast du schon gut zu tun. Ich hab mal in einem Meeting gesagt: “Wir hangeln uns von Edge Case zu Edge Case.” Der Satz ist hängen geblieben.

Und was ich vermisse? Die Geschwindigkeit. Bei VBA war es: Zack zack zack im Code, hier die Lösung, sofort ready. Nicht sauber, nicht dokumentiert, aber da und es geht. Unser Rhythmus als Performance-Agentur ist in Minuten und Stunden getaktet. Ein wöchentlicher Deployment-Zyklus fühlt sich da manchmal langsam an - aber bei 45+ Quellen ist das der bewusste Trade-off für Stabilität. Ein kaputter Quick-Fix in VBA betraf einen Prozess - ein kaputter Quick-Fix in PIX kann den ganzen operativen Betrieb lahmlegen.

Was ich heute anders machen würde? Vorsichtiger beim Erwartungsmanagement. Die Leute hören gerne den Best Case raus und nicht mehr zu, wenn es darum geht, was das verzögern kann. Und man selbst ist auch euphorisch, wenn erstmal alles läuft. Dann kommt ein komplexer Edge Case, dauert länger als angekündigt - Stimmung mies. Das war nie ein Dealbreaker, aber es hätte besser laufen können.

Falls du auch “das eine Excel” in deiner Firma hast - die VBA-Makros, die seit Jahren laufen, den einen Kollegen der alles zusammenhält: Schreib mir auf LinkedIn - ich bin gespannt auf deine Geschichte.

P.S.: In jedem guten RPG gibt es einen Punkt, an dem dein Starter-Schwert einfach nicht mehr reicht - egal wie viele Upgrades du reingesteckt hast. Dann ist es Zeit für eine neue Waffe. Auch wenn du an der alten hängst.