Kurzantwort: Excel sollte im Mittelstand nicht wegen seines Alters abgelöst werden. Eine Alternative wird wirtschaftlich, wenn ein wiederkehrender Prozess viele manuelle Übergaben, unklare Datenstände, schwer prüfbare Regeln oder komplexe Berechtigungen erzeugt. Dann werden Excel, Low-Code, Standardsoftware und individuelle Software anhand desselben Prozesses und seiner Vollkosten verglichen.
Excel ist schnell, flexibel und fast überall vorhanden. Genau deshalb wird aus einer hilfreichen Kalkulation schleichend ein betriebliches Kernsystem. Neue Spalten ersetzen Anforderungen, Makros ersetzen Schnittstellen und Dateinamen ersetzen Versionsmanagement. Die richtige Frage lautet nicht „Ist Excel professionell genug?“, sondern: Passt das Werkzeug noch zum Risiko und zur Bedeutung des Prozesses?
Wann Excel ablösen im Mittelstand wirtschaftlich wird
Kurzantwort: Das Ablösen von Excel wird wirtschaftlich, wenn der laufende Nutzen einer zentralen Lösung die einmaligen Migrations- und Entwicklungskosten plus Betrieb übersteigt. Gemessen werden müssen echte Prozesszeiten, Korrekturen, Abstimmungen und Pflege. Vermutete Fehlerkosten oder pauschale Produktivitätsversprechen gehören nicht ohne interne Belege in die Rechnung.
Der Kipppunkt entsteht selten durch die Dateigröße. Er entsteht, wenn eine Arbeitsmappe Aufgaben übernimmt, die eigentlich zu einer Anwendung gehören:
- Sie steuert einen wiederkehrenden operativen Prozess.
- Mehrere Rollen bearbeiten denselben Vorgang.
- Daten werden aus anderen Systemen importiert oder dorthin zurückgeschrieben.
- Formeln und Makros enthalten geschäftliche Regeln.
- Freigaben, Statuswechsel oder Fristen müssen nachvollziehbar sein.
- Ein Ausfall oder eine falsche Version stoppt Arbeit oder erzeugt finanzielle Folgen.
Nicht jedes dieser Merkmale rechtfertigt eine Eigenentwicklung. Sie zeigen nur, dass eine strukturierte Entscheidung fällig ist. Der größere Kontext steht im Pillar Individuelle Software für KMU.
Excel, Low-Code, Standardsoftware oder individuelle Software?
Kurzantwort: Excel passt zu flexibler Einzelarbeit, Low-Code zu klaren Abteilungsworkflows, Standardsoftware zu etablierten Prozessen und individuelle Software zu dauerhaft spezifischen Kernabläufen. Entscheidend sind Datenmodell, Rollen, Integrationen, Änderungsbedarf und Betriebsverantwortung. Die technisch schnellste Option ist nicht automatisch die wirtschaftlichste über den gesamten Lebenszyklus.
| Option | Passt besonders, wenn | Kritische Prüfung |
|---|---|---|
| Excel | wenige Bearbeiter, flexible Analyse, Ergebnis leicht prüfbar | Versionen, Verantwortliche, manuelle Übergaben |
| Low-Code | klarer Workflow, vorhandene Plattform, überschaubare Logik | Governance, Lizenzmodell, Plattformgrenzen, ALM |
| Standardsoftware | Prozess ist marktüblich, wesentliche Anforderungen werden abgedeckt | Anpassungszwang, Datenexport, Schnittstellen, Herstellerabhängigkeit |
| individuelle Software | Prozess ist spezifisch, integrationsreich oder wettbewerbsrelevant | Investition, Produktverantwortung, Wartung, Weiterentwicklung |
Excel: flexibel, solange die Arbeit überschaubar bleibt
Excel eignet sich für Analysen, Kalkulationen, Planungen und abgegrenzte Listen. Moderne Microsoft-365-Setups unterstützen laut Microsoft-Dokumentation gemeinsames Bearbeiten und Versionsverläufe. Damit lassen sich viele klassische Konflikte reduzieren.
Diese Funktionen machen aus einer Arbeitsmappe jedoch noch keine Fachanwendung. Rollen, Pflichtschritte, systemübergreifende Transaktionen und fachliche Regeln bleiben häufig in Zellschutz, Konventionen und Wissen einzelner Personen verteilt.
Low-Code: schneller Anwendungsbau mit echten Betriebsaufgaben
Low-Code ist sinnvoll, wenn ein Team Formulare, Freigaben und einfache Datenflüsse auf einer bereits etablierten Plattform abbilden möchte. Der Vorteil ist die Geschwindigkeit. Die Grenze entsteht dort, wo Plattformlogik, Connectoren, komplexe Rechte oder besondere Bedienanforderungen den Prozess bestimmen.
Low-Code bedeutet nicht „ohne Software-Lebenszyklus“. Microsoft zählt in seiner Power-Platform-Dokumentation zu Application Lifecycle Management unter anderem Anforderungen, Architektur, Entwicklung, Tests, Wartung, Änderungen, Support, Deployment und Governance auf. Diese Aufgaben müssen auch bei visuell erstellten Anwendungen jemandem gehören.
Standardsoftware: zuerst prüfen, wenn der Prozess nicht einzigartig ist
Für Buchhaltung, CRM, Warenwirtschaft, Personalverwaltung oder Tickets gibt es etablierte Produkte. Wenn ein Standardprodukt die geschäftskritischen Anforderungen ohne dauerhafte Umgehungslösungen erfüllt, ist es meist sinnvoller als ein eigener Build.
Die Marktprüfung muss trotzdem konkret sein. Eine Demo mit Beispieldaten beweist weder die Eignung der eigenen Rechte- und Freigabelogik noch die Qualität von Schnittstellen und Datenexport. Der richtige Test nutzt reale Prozessfälle und prüft auch Kündigung, Datenmitnahme und Anpassungsgrenzen.
Individuelle Software: wenn der Prozess selbst Teil des Vorteils ist
Eigene Software passt, wenn der Prozess bewusst anders läuft als der Marktstandard, mehrere Bestandssysteme verbindet oder besondere Rollen und Ausnahmen trägt. Dann wird nicht Excel eins zu eins nachgebaut. Stattdessen werden Datenmodell, Regeln und Nutzerfluss neu geordnet.
Den Budgetrahmen und die NLD-Build-Klassen erklärt der Beitrag Was individuelle Software für den Mittelstand kostet.
Warnsignale: Aus einer Tabelle ist ein Schatten-System geworden
Kurzantwort: Kritisch wird Excel, wenn niemand den gesamten Datenfluss erklären kann, mehrere Wahrheiten parallel existieren oder geschäftliche Regeln nur in Formeln und Makros stecken. Weitere Warnsignale sind manuelle Systemüberträge, fehlende Rollen, unklare Änderungen und Abhängigkeit von Einzelpersonen. Entscheidend ist die Kombination und geschäftliche Wirkung dieser Signale.
Mehrere Dateien behaupten, aktuell zu sein
Dateien liegen in E-Mails, lokalen Ordnern, Teams oder SharePoint. Zusätze wie „final“, „neu“ oder Datumsstempel regeln den Status. Das Problem ist nicht der Dateiname, sondern die fehlende eindeutige Quelle für den aktuellen Prozesszustand.
Daten werden regelmäßig kopiert und abgeglichen
Mitarbeiter übertragen Daten aus CRM, ERP, E-Mails oder anderen Tabellen und prüfen Abweichungen anschließend manuell. Dieser Aufwand ist messbar. Er gehört in die Wirtschaftlichkeitsrechnung, bevor über ein Zielsystem gesprochen wird.
Regeln sind an einzelne Personen gebunden
Nur eine Person versteht Makros, verschachtelte Formeln oder die richtige Reihenfolge der Arbeitsschritte. Urlaub, Rollenwechsel oder ein Fehler in dieser Datei wird damit zum Betriebsrisiko. Eine Dokumentation hilft kurzfristig; bei einem Kernprozess kann sie die fehlende Systemstruktur nicht dauerhaft ersetzen.
Berechtigungen passen nicht zur Fachlogik
Blatt- und Dateischutz können Bearbeitung begrenzen. Sobald Nutzer aber je Kunde, Standort, Projekt oder Prozessschritt unterschiedliche Daten sehen und ändern dürfen, wird die Rechtepflege in Dateien schnell schwer prüfbar.
Änderungen sind nicht angemessen nachvollziehbar
Für unkritische Planung genügt oft der Versionsverlauf. Bei Freigaben, Verträgen oder steuerlich relevanten Aufzeichnungen können weitergehende Anforderungen gelten. Die aktuelle BMF-Veröffentlichung zur zweiten Änderung der GoBD zeigt, dass die formalen Rahmenbedingungen gepflegt werden. Excel wird dadurch nicht pauschal unzulässig; das konkrete Verfahren muss geprüft werden.
Die 2025 überarbeitete amtliche AQuA-Book-Leitlinie der britischen Regierung empfiehlt Qualitätssicherung passend zum finanziellen, rechtlichen, operativen und reputativen Risiko. Sie fordert unter anderem Verifikation, Validierung, Dokumentation und klare Verantwortlichkeiten über den Lebenszyklus. Diese Prinzipien sind auch für geschäftskritische Tabellen ein sinnvoller Prüfrahmen.
Wann Excel bleiben sollte
Kurzantwort: Excel sollte bleiben, wenn die Aufgabe bewusst flexibel ist, wenige Personen beteiligt sind, Ergebnisse einfach kontrolliert werden können und weder komplexe Rechte noch stabile Integrationen nötig sind. Eine saubere Arbeitsmappe mit Verantwortlichem, Dokumentation, Datenvalidierung, gemeinsamer Ablage und Versionierung ist oft wirtschaftlicher als eine vorschnell gebaute Anwendung.
Excel ist die richtige Wahl, wenn beispielsweise:
- eine Analyse oder Planung regelmäßig angepasst werden muss,
- die Eingaben überschaubar und fachlich kontrollierbar sind,
- nur wenige benannte Personen bearbeiten,
- keine komplexen Status- oder Freigabeschritte nötig sind,
- keine automatische Synchronisation mit mehreren Systemen erwartet wird,
- Fehler vor der Verwendung durch einen klaren Review auffallen können,
- die Datei keinen dauerhaften Produktbetrieb rechtfertigt.
Dann sollte das Team nicht migrieren, sondern die Arbeitsmappe besser führen:
- einen fachlichen Eigentümer benennen,
- Eingabe, Berechnung und Ausgabe sichtbar trennen,
- Datenvalidierung und geschützte Bereiche einsetzen,
- Formeln, Makros, Datenquellen und Annahmen dokumentieren,
- eine gemeinsame Ablage mit geregelten Rechten nutzen,
- Versionsverlauf und Wiederherstellung testen,
- regelmäßige fachliche Reviews einplanen.
Auch bei Excel gilt: Die Qualitätssicherung sollte zum Risiko passen. Ein persönlicher Reisekostenentwurf braucht weniger Kontrolle als eine Kalkulation, die Preise oder Produktionsmengen steuert.
Modellrechnung: Ab wann kann sich eigene Software rechnen?
Kurzantwort: Eine belastbare Rechnung vergleicht eingesparte Prozesszeit mit Umsetzung, Migration und laufendem Betrieb. Das folgende Beispiel ist ausdrücklich eine Modellrechnung mit frei gewählten Annahmen, kein Benchmark und kein Kundenfall. Es zeigt nur die Rechenlogik. Für eine Entscheidung müssen die Werte am eigenen Prozess gemessen und fachlich freigegeben werden.
Frei gewählte Annahmen
| Annahme | Modellwert | Einordnung |
|---|---|---|
| beteiligte Personen | 6 | frei gewählt |
| Arbeitstage pro Jahr | 220 | frei gewählt |
| heutiger Aufwand je Person und Tag | 35 Minuten | frei gewählt |
| angenommener Restaufwand nach Umstellung | 10 Minuten | frei gewählt |
| interner Vollkostensatz | 45 € je Stunde | frei gewählt |
| einmalige Umsetzung inklusive Migration | 30.000 € | frei gewählt |
| laufender Betrieb und Pflege | 6.000 € pro Jahr | frei gewählt |
Die angenommene Zeitersparnis beträgt 25 Minuten je Person und Arbeitstag.
Jährlicher Bruttonutzen:
6 Personen × 25/60 Stunden × 220 Tage × 45 € = 24.750 €
Jährlicher Nutzen nach laufendem Betrieb:
24.750 € − 6.000 € = 18.750 €
Vereinfachte Amortisation:
30.000 € ÷ 18.750 € = 1,6 Jahre nach dem Go-live
Diese vereinfachte Rechnung berücksichtigt weder Finanzierung noch Abzinsung, Übergangsaufwand oder Veränderungen im Prozessvolumen. Sie bewertet auch keine vermiedenen Fehler, weil dafür keine internen Belege vorliegen. Vor einer Investition werden die Annahmen mit Zeiterfassung, Fallzahlen und Prozessbeobachtung ersetzt.
Ein gutes Modell rechnet außerdem Alternativen: Was kostet es, Excel sauberer zu organisieren? Welche Lizenz-, Einführungs- und Anpassungskosten verursacht Standardsoftware? Was kostet Low-Code über den geplanten Nutzungszeitraum? Erst danach wird individuelle Software wirtschaftlich eingeordnet.
Migrationsplan: Excel kontrolliert ablösen
Kurzantwort: Eine sichere Migration beginnt mit Prozess und Daten, nicht mit dem neuen Bildschirm. Dateien, Regeln, Schnittstellen und Verantwortliche werden inventarisiert, anschließend Zielmodell und Abnahmetests definiert. Nach Bereinigung und Probeladung folgt ein begrenzter Parallelbetrieb. Erst bei fachlich bestätigter Daten- und Ergebnisgleichheit wird kontrolliert umgestellt.
1. Prozess und Entscheidungseigentümer festlegen
Benennen Sie den fachlichen Eigentümer, die betroffenen Nutzer und den konkreten Prozessanfang und -abschluss. Ohne diese Grenze wird aus „Excel ablösen“ schnell ein unkontrolliertes Digitalisierungsprojekt.
2. Arbeitsmappen und Abhängigkeiten inventarisieren
Erfasst werden nicht nur sichtbare Tabellen, sondern auch Makros, Formeln, Verknüpfungen, Datenimporte, Exporte, E-Mail-Schritte, manuelle Kontrollen und lokale Kopien. Für jedes Element wird geklärt, ob es fachlich nötig, veraltet oder nur historisch gewachsen ist.
3. Zieloption mit echten Fällen testen
Excel, Low-Code, Standardsoftware und individueller Build werden an denselben repräsentativen Fällen verglichen. Dazu gehören Normalfälle, Ausnahmen, Rollenwechsel, Korrekturen und Datenexport. Ein Anbieter-Screenshot ist kein Prozessnachweis.
4. Datenmodell und Bereinigung trennen
Die neue Lösung sollte nicht jede Spalte und jeden historischen Workaround übernehmen. Zuerst wird festgelegt, welche fachlichen Objekte und Beziehungen künftig gelten. Danach werden Dubletten, ungültige Werte und fehlende Zuordnungen mit verantwortlichen Fachpersonen bereinigt.
5. Abnahmetests vor der Migration definieren
Testfälle legen fest, welche Eingaben zu welchen Ergebnissen führen, welche Rolle was sehen darf und wie Fehler behandelt werden. Bei Berechnungen werden bekannte Referenzfälle genutzt. Summen, Datensätze und Stichproben werden zwischen Quelle und Ziel abgeglichen.
6. Probeladung und begrenzten Parallelbetrieb durchführen
Eine Probeladung zeigt früh, ob Datentypen, Zuordnungen und Sonderfälle passen. Im Parallelbetrieb bearbeiten ausgewählte Nutzer denselben klar abgegrenzten Prozess in Alt- und Zielsystem. Abweichungen werden erklärt, nicht nur überschrieben.
7. Umstellung, Rückfallweg und Archiv regeln
Der Go-live braucht einen klaren Stichtag, Verantwortliche, Support und einen geprüften Rückfallweg. Alte Dateien werden nicht unkontrolliert weitergeführt. Je nach Aufbewahrungsanforderung bleiben sie schreibgeschützt und zeitlich geregelt zugänglich oder werden kontrolliert archiviert.
Dieser schrittweise Ansatz folgt demselben Grundgedanken wie eine Legacy-Modernisierung ohne Big Bang: zuerst Abhängigkeiten verstehen, dann einen begrenzten Teil sicher ersetzen.
Die Entscheidung in einem Satz
Excel ablösen im Mittelstand ist kein Selbstzweck. Bleibt die Aufgabe flexibel, klein und gut prüfbar, sollte Excel bleiben und sauberer geführt werden. Ist aus der Datei ein geschäftskritischer Mehrnutzer-Prozess mit Integrationen, Rollen und dauerhafter Fachlogik geworden, werden Low-Code, Standardsoftware und individuelle Software anhand von Vollkosten und Prozessfit verglichen.
Für die Umsetzungsfrage hilft ergänzend der Vergleich Softwareentwicklung: Outsourcing oder Inhouse.
Excel-Prozess und wirtschaftliche Zieloption prüfen →
Geschrieben von Simon Maiwald, Gründer von New Life Digital im MAFINEX Mannheim. NLD analysiert gewachsene Excel-Prozesse, prüft Standard- und Low-Code-Wege und baut individuelle Software nur dort, wo sie fachlich und wirtschaftlich trägt.
Quellen und weiterführende Dokumente
- Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff (GoBD); 2. Änderung Bundesministerium der Finanzen
- The AQuA Book UK Government Analysis Function
- Collaborate on Excel workbooks at the same time with co-authoring Microsoft Support
- Overview of application lifecycle management with Microsoft Power Platform Microsoft Learn
Häufige Fragen
Kurz und direkt beantwortet.
Wann sollte ein Mittelständler Excel ablösen?
Excel sollte geprüft werden, wenn ein wiederkehrender Prozess von mehreren Personen abhängt, Daten zwischen Dateien kopiert werden, Rollen nicht sauber trennbar sind oder Änderungen kaum nachvollzogen werden können. Ein einzelnes Warnsignal reicht nicht. Entscheidend ist, ob Aufwand und Risiko regelmäßig höher sind als die Kosten einer passenden Alternative.
Ist Low-Code die beste Alternative zu Excel?
Low-Code passt gut zu klaren Abteilungsworkflows, vorhandenen Plattformen und überschaubarer Fachlogik. Es ist trotzdem Software und braucht Datenmodell, Rechte, Tests, Deployment und Pflege. Sobald komplexe Integrationen, hohe Last, besondere Oberflächen oder starke Unabhängigkeit vom Plattformanbieter wichtig werden, sollte individuelle Software mitgeprüft werden.
Wann ist Standardsoftware besser als individuelle Software?
Standardsoftware ist meist sinnvoller, wenn der Prozess üblich ist und die wesentlichen Anforderungen ohne dauerhafte Sonderwege abgedeckt werden. Individuelle Software passt, wenn der Ablauf einen echten Wettbewerbsvorteil bildet oder Rollen, Integrationen und Ausnahmen dauerhaft spezifisch sind. Vor einer Eigenentwicklung gehört deshalb immer eine ernsthafte Marktprüfung.
Wie berechnet man, ob sich das Ablösen von Excel lohnt?
Berechnen Sie zuerst die heutige Prozesszeit, Korrekturen, Abstimmung und Pflege mit einem internen Vollkostensatz. Stellen Sie dem die einmalige Umsetzung, Migration, Schulung und laufenden Betriebskosten gegenüber. Fehlerfolgen dürfen nur einfließen, wenn sie intern belegt sind. Eine Modellrechnung ersetzt keine Messung am realen Prozess.
Wie migriert man Excel-Daten in eine neue Software?
Zuerst werden Dateien, Formeln, Makros, Datenquellen und Verantwortliche inventarisiert. Danach folgen Datenbereinigung, Zielmodell, Testfälle und eine Probeladung. Fachverantwortliche gleichen Summen, Stichproben und Sonderfälle ab. Erst nach einem kontrollierten Parallelbetrieb wird umgestellt; die alte Datei bleibt definiert und zeitlich begrenzt lesbar.
Ist Excel mit den GoBD unvereinbar?
Nein, die GoBD verbieten Excel nicht pauschal. Wenn eine Arbeitsmappe steuerlich relevante Bücher, Aufzeichnungen oder Unterlagen verarbeitet, müssen jedoch die Anforderungen des konkreten Verfahrens geprüft werden, etwa Nachvollziehbarkeit, Aufbewahrung und Datenzugriff. Die Einordnung sollte mit Steuerberatung und Verfahrensverantwortlichen erfolgen, nicht allein anhand des Dateiformats.