Excel durch Software ersetzen: Was bleibt, was geht, was Sie vorher klären sollten

Der Hinweis steht oft im Dateinamen: „Planung_final_neu_Version3“. Daneben liegt „Planung_final_neu_Version3_Kopie“, und alle im Büro wissen, dass nur eine der beiden stimmt. Wer sie öffnet, fragt zuerst im Flur, ob gerade jemand darin arbeitet. In diesem Szenario nehmen wir einen kleinen Betrieb an, dessen Aufträge, Termine und Kalkulationen in einer einzigen Arbeitsmappe zusammenlaufen.

Die Mappe ist nicht schlecht gebaut. Sie ist über Jahre gewachsen, und jede Erweiterung war vernünftig: eine Spalte für den Status, ein Blatt für Material, ein Makro, das aus Zeilen ein Angebot erzeugt. Zusammen ergibt das ein System, das funktioniert, solange eine bestimmte Person es bedient. Fällt sie aus, merkt man erst, wie viel Wissen in Zellfarben, Filtereinstellungen und ausgeblendeten Spalten steckt.

Die Frage lautet deshalb selten „Ist Excel schlecht?“. Sie lautet: Wann kostet das Arbeitsblatt mehr, als es nützt, und was verlieren wir, wenn wir es ersetzen? Wer Excel durch Software ersetzen möchte, sollte diese zweite Frage zuerst stellen, denn die Antwort entscheidet, ob das Projekt gelingt oder nur ein neues Werkzeug mit denselben alten Fehlern entsteht.

Hinzu kommt ein Moment, den viele Betriebe kennen: Ein neuer Mitarbeiter soll Daten eintragen und fragt, welche Spalte „Lieferdatum“ und welche „Wunschtermin“ meint. Die Antwort lautet „Das sieht man an der Farbe“. Solche Sätze sind harmlos, solange die Person da ist, die sie erklären kann. Sie sind ein Warnsignal, wenn das Wissen an einer einzigen Stelle liegt.

Excel scheitert selten an Rechenleistung, sondern an Gleichzeitigkeit und Verbindlichkeit. Zwei Personen tragen am selben Vormittag Änderungen ein, eine Version überschreibt die andere, und das fällt erst auf, wenn eine Lieferung fehlt. Auch mit gemeinsamer Bearbeitung in der Cloud bleibt das Grundproblem bestehen: Jede Zelle darf alles enthalten, und niemand prüft, ob ein Datum wirklich ein Datum ist.

Hinzu kommt die Unsichtbarkeit der Regeln. Eine Formel verweist auf ein verstecktes Blatt, ein Makro setzt beim Speichern Werte um, eine bedingte Formatierung färbt Zeilen rot, die älter als zehn Tage sind. Niemand hat diese Regeln je als Anforderung formuliert, und doch verlassen sich Menschen auf sie. Bei einer Ablösung sind das die Stellen, die ohne Warnung verloren gehen.

Schließlich fehlt Nachvollziehbarkeit. Wer hat den Preis in Zeile 214 geändert, und wann? Excel kann Änderungen verfolgen, doch im Alltag ist das Protokoll lückenhaft oder abgeschaltet. Für Betriebe, die Angebote, Prüfprotokolle oder Kundendaten führen, ist das mehr als eine Komfortfrage, denn es berührt Haftung, Reklamation und Datenschutz.

Eine Ablösung beginnt mit einer Sortierung. Excel ist hervorragend für Einzelanalysen, Szenarien, schnelle Rechenmodelle und Auswertungen, bei denen jemand explorativ mit Daten spielt. Es ist schwach bei Daten, die viele Personen gleichzeitig pflegen, die Regeln durchsetzen müssen und eine Historie brauchen. Wer beides in einer Datei mischt, hat meist die Ursache des Problems gefunden.

Eine nützliche Unterscheidung trennt Erfassen, Verarbeiten und Auswerten. Erfassen und Verarbeiten gehören in eine Anwendung mit Formularen, Pflichtfeldern, Rechten und Protokoll. Das Auswerten darf in Excel bleiben, gespeist aus einem sauberen Export. So behalten Mitarbeitende das vertraute Werkzeug dort, wo es Freiheit braucht, und die Daten bekommen dort Disziplin, wo Freiheit Fehler erzeugt.

Nicht jede Tabelle verdient eine Software. Eine Liste mit wenigen Einträgen, die eine Person im Monat pflegt, ist in Excel gut aufgehoben. Eine Ablösung lohnt sich dort, wo viele Menschen dieselben Daten ändern, wo Fehler Geld oder Vertrauen kosten und wo Abläufe sich regelmäßig wiederholen. Wir würden ehrlich benennen, welche Dateien im Betrieb bewusst bleiben können.

Ein Prüfstein ist die Frage, wer die Datei morgen übernehmen müsste. Kann eine neue Kollegin sie nach einer Woche sicher bedienen, ist die Struktur tragfähig. Braucht sie dafür Monate und mündliche Überlieferung, ist die Datei bereits ein Betriebsrisiko, unabhängig davon, wie gut sie rechnet.

Der verlockende Weg ist der große Wurf: Die Mappe wird nachgebaut, an einem Stichtag umgestellt, Excel wird abgeschaltet. Das scheitert erfahrungsgemäß an zwei Dingen. Erstens ist der Funktionsumfang der alten Mappe größer, als er aussieht. Zweitens bringt ein Stichtag Druck in genau den Moment, in dem die ersten Fehler auftauchen. Wir würden diesen Weg nur bei sehr kleinen, überschaubaren Dateien wählen.

Besser eignet sich eine Ablösung in Scheiben. Zuerst wird der Bereich umgestellt, der die meisten Probleme macht und die klarsten Regeln hat, etwa die Auftragserfassung. Die Auswertungen bleiben zunächst in Excel und lesen aus der neuen Quelle. Jede Scheibe liefert für sich einen funktionierenden Zustand, und das Team lernt am überschaubaren Beispiel, statt alles auf einmal zu verkraften.

Als Alternative kommt Standardsoftware in Frage, etwa eine fertige Auftragsverwaltung oder ein Low-Code-Baukasten. Das ist oft die richtige Wahl, wenn die Abläufe des Betriebs ohnehin üblich sind. Individuelle Software lohnt sich, wenn die eigenen Regeln den Wettbewerbsvorteil ausmachen oder kein Produkt sie abbildet. Wir würden beides gegenüberstellen und die Entscheidung dem Betrieb überlassen, nicht dem Anbieter.

Eine dritte Möglichkeit ist, Excel zu behalten und es disziplinierter zu bauen: getrennte Eingabe- und Rechenblätter, Datenvalidierung, geschützte Formeln, eine zentrale Ablage mit klarer Zuständigkeit. Das ist günstig und schnell, stößt aber an Grenzen, sobald viele Personen gleichzeitig arbeiten oder Rechte und Protokoll gefordert sind. Als Zwischenschritt kann es sinnvoll sein, weil es die Regeln ohnehin sichtbar macht, die eine spätere Ablösung braucht.

Der wichtigste Arbeitsschritt ist unscheinbar: Wir lesen die Mappe wie ein Gutachter. Jedes Blatt wird daraufhin geprüft, was es speichert, was es berechnet und worauf es sich verlässt. Verstecktes, Geschütztes und Verknüpftes wird sichtbar gemacht, Makros werden Zeile für Zeile beschrieben. Das Ergebnis ist kein Programm, sondern eine Regelliste in normaler Sprache, die der Betrieb gegenlesen kann.

Dabei treten drei Arten von Regeln zutage. Es gibt explizite Regeln, etwa „Rabatt ab zehn Stück“. Es gibt implizite, die nur durch Gewohnheit gelten, zum Beispiel „Aufträge mit rotem Hintergrund werden zuerst bearbeitet“. Und es gibt Fehlerausgleiche, bei denen die Mappe etwas falsch rechnet und die Mitarbeitenden die Abweichung im Kopf korrigieren. Diese dritte Art darf nicht ungeprüft übernommen werden.

Zur Absicherung dient ein Interview mit denen, die täglich mit der Datei arbeiten, und nicht nur mit der Leitung. Fragen wie „Was machen Sie, wenn die Zahl nicht stimmt?“ fördern zutage, was kein Dokument verrät. Aus beiden Quellen entsteht eine Liste, die gemeinsam entschieden wird: Diese Regel bleibt, diese wird vereinfacht, diese fällt weg, weil sie nur ein Behelf war.

So entsteht nebenbei ein Nutzen, der mit Software noch nichts zu tun hat. Der Betrieb erfährt, wie er eigentlich arbeitet, und kann entscheiden, ob das so gewollt ist. Manche Ablösung wird dadurch kleiner, weil eine überflüssige Regel verschwindet, bevor sie in Code gegossen wird.

Beim Umzug zeigt sich, wie nachsichtig Excel ist. Dieselbe Spalte enthält „12.03.2024“, „März 24“ und „12/3“. Namen erscheinen mit und ohne Titel, Beträge mit Komma, Punkt oder Währungszeichen im Textfeld. Eine Datenbank verlangt Eindeutigkeit, und deshalb entscheidet die Bereinigung über die Qualität des neuen Systems stärker als jede Oberfläche. Rechnen Sie dafür mit einem erheblichen Anteil der Projektzeit.

Technisch läuft die Migration in Skripten, nicht von Hand. Die Daten werden eingelesen, geprüft, normalisiert und in die Zielstruktur geschrieben. Zeilen, die eine Regel verletzen, landen in einer Fehlerliste, die Fachleute im Betrieb abarbeiten. Nach jedem Lauf vergleichen wir Anzahlen, Summen und Stichproben mit der Quelle. Duplikate und Waisen werden bewusst entschieden, nicht stillschweigend gelöscht, und das Original bleibt als Archiv unverändert.

Die Anwendung besteht aus wenigen Bausteinen. Eine Datenbank speichert Aufträge, Kunden und Positionen in getrennten Tabellen, eine Anwendungsschicht erzwingt Pflichtfelder, erlaubte Statusübergänge und Berechnungen an einer einzigen Stelle, eine Weboberfläche bildet die Arbeitsweise im Betrieb ab. Berechtigungen werden in Rollen gedacht: Die Disposition ändert Termine, die Buchhaltung sieht Zahlen, aber keine Kundenkommunikation. Wer Daten nicht braucht, sieht sie nicht, Details klärt der Betrieb mit seiner Datenschutzberatung.

Ein Änderungsprotokoll hält Benutzer, Zeitpunkt, alten und neuen Wert fest, auch beim Löschen. Aus „Wer hat das geändert?“ wird ein Blick in die Historie. Der Export bleibt eine feste Funktion: Jede Liste lässt sich als CSV oder Excel-Datei ausgeben, und die Daten liegen in einem offenen Format vor. So bleibt der Betrieb vom Anbieter unabhängig, und Analysen können in Excel weiterlaufen.

Der Übergang ist der Moment, in dem Projekte kippen. Wir würden alt und neu für einen begrenzten Zeitraum parallel führen: Dieselben Vorgänge werden in beiden Systemen erfasst, und ein regelmäßiger Abgleich zeigt Abweichungen. Das kostet Zeit und ist unbeliebt, deckt aber Regeln auf, die in der Bestandsaufnahme übersehen wurden. Jede Abweichung ist ein Befund über das neue System oder die alte Mappe.

Die Dauer des Parallelbetriebs hängt vom Rhythmus des Betriebs ab. Wer monatlich abrechnet, sollte mindestens einen vollständigen Abrechnungslauf in beiden Systemen erleben. Es braucht außerdem eine klare Rückfalloption: Solange der Abgleich Unklarheiten zeigt, bleibt Excel die führende Quelle, danach wechselt die Führung, und die alte Mappe wird auf Lesezugriff gesetzt, nicht gelöscht.

Mitarbeitende gewinnt man nicht mit Schulungsfolien. Hilfreich ist, die Menschen früh einzubeziehen, die täglich mit der Mappe arbeiten, und ihre Umgehungen ernst zu nehmen. Eine Abkürzung, die jemand erfunden hat, zeigt meist einen echten Bedarf. Kurze Einführungen am echten Fall, ein Ansprechpartner im Haus und eine Anlaufstelle für Rückfragen in den ersten Wochen wirken stärker als umfassende Handbücher.

Ehrlich sollte man auch über Widerstand sprechen. Wer jahrelang mit einer Datei effizient war, verliert im neuen System zunächst Tempo. Dieser Effekt ist normal und vorübergehend, sollte aber eingeplant werden, etwa durch Entlastung bei Terminspitzen. Wer ihn verschweigt, erzeugt Misstrauen, das dem Projekt später mehr schadet als die Einarbeitung.

Ein Sonderfall sind Makros, die externe Programme ansprechen oder Dokumente erzeugen. Hier genügt es nicht, den Code zu lesen, man muss das Ergebnis kennen: Wie sieht das Angebot aus, das der Kunde bekommt, und was darf sich daran nie ändern? Solche Ausgaben werden als Vorlagen nachgebaut und Satz für Satz mit alten Dokumenten verglichen, bevor der erste echte Vorgang darüber läuft.

Eine Software verspricht keine Wunder, aber sie beseitigt bestimmte Fehlerklassen. Versionskonflikte entfallen, weil es nur einen Datenstand gibt. Ungültige Eingaben werden am Formular abgefangen statt in der Auswertung entdeckt. Änderungen sind nachvollziehbar, und Berechtigungen begrenzen den Schaden, den ein Versehen anrichten kann. Das sind strukturelle Verbesserungen, die sich nicht von der Tagesform einer Person abhängig machen.

Messbar wird der Nutzen an Größen, die der Betrieb selbst festlegt, bevor das Projekt startet. Dazu zählen die Zahl der Korrekturen nach der Erfassung, die Zeit für Monatsabschluss und Berichte, die Anzahl der Rückfragen wegen unklarer Stände und die Dauer, bis neue Mitarbeitende selbstständig arbeiten. Wichtig ist eine Vergleichsbasis aus den Wochen vor der Umstellung, sonst bleibt jede spätere Aussage Gefühl.

Was sich nicht zusagen lässt: konkrete Zeitersparnisse in Stunden oder Prozent, bevor die Abläufe bekannt sind. Auch dass alle Beteiligten das neue System lieben werden, wäre unredlich. Realistisch ist das Ziel, dass die Arbeit verlässlicher wird, der Betrieb weniger von einzelnen Personen abhängt und Daten verfügbar bleiben. Ob sich das rechnet, zeigt sich über mehrere Monate, nicht in der ersten Woche.

Dem stehen laufende Kosten gegenüber, die man offen ansprechen sollte. Eine Anwendung braucht Hosting, Updates, Datensicherung und gelegentlich Anpassungen, wenn sich Abläufe ändern. Excel erschien kostenlos, weil die Folgekosten in Arbeitszeit und Fehlern versteckt waren. Der Vergleich ist erst fair, wenn beide Seiten ehrlich aufgestellt werden.

Auch die Qualität der Daten selbst wird zum Maßstab. Nach der Umstellung lässt sich zählen, wie viele Datensätze Pflichtangaben vollständig enthalten und wie viele Einträge nachträglich korrigiert werden mussten. Diese Zahlen sind unbequem, weil sie Schwächen zeigen, die Excel stillschweigend verdeckt hat. Sie sind aber genau das, was ein Betrieb braucht, um Abläufe gezielt zu verbessern, statt Fehler nur zu erdulden.

Aus der Methode lassen sich einige Grundsätze ableiten. Erstens: Die Regelliste ist wichtiger als der Code. Wer sie sauber führt, kann das System später erweitern, ohne das Wissen erneut ausgraben zu müssen. Zweitens: Die Bereinigung der Daten ist ein eigenes Teilprojekt mit eigener Verantwortung im Betrieb, kein Nebenprodukt der Programmierung.

Drittens: Kleine Scheiben schlagen große Würfe. Ein Bereich, der in wenigen Wochen sauber läuft, schafft Vertrauen und liefert Erkenntnisse für den nächsten. Viertens: Excel nicht zum Gegner erklären. Wer die Datei als Auswertungswerkzeug stehen lässt, nimmt dem Projekt Widerstand und erhält eine bewährte Fähigkeit. Fünftens: Der Export gehört von Anfang an dazu, denn er sichert die Unabhängigkeit.

Ebenso lehrreich sind die Fälle, in denen von einer Ablösung abzuraten ist. Wenn die Abläufe selbst noch unklar sind, wird Software sie nur festschreiben. Wenn die Datei von einer Person für eine Person geführt wird, genügt oft ein besser gebautes Arbeitsblatt mit Eingabeprüfung und einer kurzen Dokumentation. Auch das ist ein legitimes Ergebnis einer Beratung.

Ein weiterer Grundsatz betrifft die Zuständigkeit nach dem Start. Eine Anwendung ist kein Gegenstand, den man abnimmt und vergisst. Es braucht jemanden im Betrieb, der Wünsche sammelt, Rechte pflegt und Rückmeldungen priorisiert, sonst entsteht im Neuen schnell wieder ein Wildwuchs aus Sonderlösungen, nur in anderer Form. Diese Rolle muss nicht groß sein, aber sie sollte benannt und mit etwas Zeit ausgestattet werden.

Excel durch Software zu ersetzen ist selten eine technische, sondern zuerst eine organisatorische Aufgabe. Sie müssen wissen, was Ihre Mappe tatsächlich tut, bevor Sie beurteilen können, was ein Nachfolger leisten muss. Die Ablösung gelingt, wenn Regeln dokumentiert, Daten bereinigt, Übergänge geplant und Menschen einbezogen werden. Sie scheitert, wenn man eine Oberfläche baut und hofft, dass der Rest sich ergibt.

Ein erster Schritt kostet wenig. Öffnen Sie Ihre wichtigste Mappe und notieren Sie, wer sie bearbeitet, welche Blätter ausgeblendet sind und welche Makros laufen. Fragen Sie zwei Kolleginnen oder Kollegen, was sie tun, wenn eine Zahl nicht stimmt. Mit dieser Liste lässt sich nüchtern entscheiden, ob eine Ablösung lohnt, ob eine bessere Excel-Datei genügt oder ob zuerst die Abläufe geklärt werden sollten.

Wir schauen uns eine solche Mappe gern mit Ihnen an und geben eine klare Einschätzung, was ersetzt werden sollte, was bleiben darf und mit welchem Aufwand Sie rechnen müssen. Eine Zusage zu Einsparungen machen wir erst, wenn die Abläufe bekannt sind.

Planen Sie dabei nüchtern: Eine Ablösung dauert länger, als der erste Eindruck der Mappe vermuten lässt, weil die versteckten Regeln erst beim Lesen auftauchen. Ein klar umrissener erster Abschnitt mit festem Rahmen ist deshalb ein besserer Einstieg als ein Gesamtangebot für alles.