Excel automatisieren oder eine interne Anwendung entwickeln?

01 /Berechnung und Arbeitsablauf getrennt betrachten

Eine Arbeitsmappe kann Umsätze prognostizieren, Aufträge zuweisen, Zahlungen erfassen und das Lager benachrichtigen. Das sind unterschiedliche Aufgaben. Berechnungen, die sich jede Woche ändern, können in Excel bleiben, auch wenn die Auftragsbearbeitung ein stärker geregeltes System braucht.

Verfolge einen Datensatz von Anfang bis Ende: Wer legt ihn an, was bedeutet jeder Status, wer darf ihn ändern und was passiert bei fehlenden Angaben? Halte Wartezeiten, doppelte Einträge und Korrekturen fest, bevor du Software beauftragst. Daraus ergibt sich, welcher Teil eine Änderung braucht.

02 /Wann die Tabelle weiterhin gut passt

Bei ersten Budgetentwürfen, Prognosen und gelegentlichen Auswertungen ist Flexibilität oft ein Vorteil. Behalte die Tabelle, wenn eine verantwortliche Person die Regeln versteht, Fehler erkennbar und korrigierbar sind und alle Zugriffsberechtigten die enthaltenen Daten sehen dürfen.

Beginne mit Ordnung: ein Datensatz pro Zeile, eine stabile Kennung, Eingaben getrennt von Formeln, ausdrückliche Statuswerte statt Farben und ein gemeinsamer Ablageort. Dokumentiere die Spalten und lege fest, wer die Datei pflegt. Wenn das den Engpass beseitigt, ist keine Anwendung nötig.

Prüfe auch die Möglichkeiten zur gemeinsamen Bearbeitung, die dein Werkzeug und dein Konto bieten. Mehrere Personen können mit einer gemeinsamen Tabelle arbeiten. Entscheidend ist, ob diese Zusammenarbeit die Regeln eures Ablaufs einhält.

03 /Wann eine Automatisierung rund um die Tabelle reicht

Ein Formular kann einheitliche Eingaben erfassen, ein Import das Kopieren von Aufträgen ersetzen und ein Export einen Bericht versorgen. Lege fest, welches System den verbindlichen Datenstand hält und in welche Richtung Daten fließen. Ein Abgleich in beide Richtungen braucht Konfliktregeln, nicht bloß zwei Skripte.

Jeder Lauf sollte ein überprüfbares Ergebnis hinterlassen: verarbeitete Datensätze, Fehler und die Person, die eine Meldung erhält. Nutze eine stabile Kennung und prüfe vor dem Anlegen, ob der Datensatz bereits verarbeitet wurde. So lässt sich der Import ohne doppelte Aufträge wiederholen. Teste einen Abbruch mitten im Stapel, bevor der Ablauf täglich eingesetzt wird.

Die Plattformen setzen Grenzen: Apps Script nutzt Kontingente und kann beim Überschreiten die Ausführung beenden. Bei Office Scripts hängen Beschränkungen von der Umgebung und dem Einsatz mit Power Automate ab. Prüfe die Dokumentation für dein Konto und deine Last; ein kleiner Test genügt nicht zur Auslegung. Microsoft Graph empfiehlt gegebenenfalls Sitzungen für zusammengehörige Vorgänge und rät von parallelen Schreibzugriffen auf dieselbe Arbeitsmappe ab.

• Google: Kontingente für Apps Script ↗
• Microsoft: Plattformgrenzen für Office Scripts ↗
• Microsoft Graph: Empfehlungen zur Excel-API ↗

Wie du den ersten Ablauf auswählst und den Nutzen prüfst, erklärt der Leitfaden zur Automatisierung von Geschäftsprozessen.

04 /Berechtigungen und Statuswechsel als Warnsignale

Deutlich wird der Handlungsbedarf, wenn die Datei Regeln durchsetzen muss: Techniker dürfen nur eigene Aufträge sehen, freigegebene Bestellungen nicht mehr frei geändert werden oder neue Bankdaten benötigen eine Prüfung. Ausgeblendete Spalten und gefilterte Kopien bilden kein Berechtigungssystem.

Microsoft unterscheidet zwischen Blattschutz und Dateisicherheit: Gesperrte Zellen verhindern bestimmte Änderungen, sind aber nicht als Sicherheitsgrenze gedacht. Die am 7. Oktober 2026 geprüfte Dokumentation hält diese Unterscheidung fest.

In einer internen Anwendung lassen sich Berechtigungen pro Datensatz, zulässige Statuswechsel und ein Änderungsverlauf gezielt umsetzen. Eine Datenbank liefert das nicht automatisch. Nimm diese Anforderungen in den Umfang auf und prüfe jede Rolle mit einem eigenen Konto. Unzulässige Aktionen müssen auch außerhalb der üblichen Eingabemaske abgewiesen werden.

• Microsoft: Schutz und Sicherheit in Excel ↗

05 /Beispiel: Einsätze planen, ohne Excel vollständig nachzubauen

Fiktives Beispiel: Ein Wartungsbetrieb verwaltet Einsätze in einer gemeinsamen Arbeitsmappe. Das Büro weist Termine und Techniker zu; jeder Techniker erhält eine Kopie. Ein weiteres Blatt berechnet Prognosen. Nach einer Terminverschiebung stimmen die Kopien nicht mehr überein.

Die erste Version könnte sich auf Einsatz-ID, Kunde, Adresse, vereinbartes Zeitfenster, Techniker und Status beschränken. Das Büro teilt die Arbeit zu; Techniker sehen ihre Einsätze und erfassen das Ergebnis. Ändern zwei Personen dieselbe Zuweisung, wird ein Konflikt zur Prüfung gemeldet, statt eine Änderung unbemerkt zu überschreiben.

Prognosen bleiben über einen Export zur Auswertung in Excel. Rechnungsstellung, Routenoptimierung und Offline-Nutzung gehören zunächst nicht zum Umfang. Müssen Techniker ohne Netz arbeiten, ändert das die Anforderungen und muss vor dem Pilotbetrieb geklärt werden.

06 /Standardsoftware, Konfiguration und Eigenentwicklung vergleichen

Prüfe vor einer Entwicklung, ob dein CRM, ERP oder eine vorhandene Fachanwendung den gesamten Ablauf einschließlich der Ausnahmen abdeckt. Standardsoftware kann die beste Wahl sein, wenn ihre Regeln passen. Für einen einfachen Ablauf kann ein konfigurierbares Werkzeug genügen, sofern Berechtigungen, Exporte und Schnittstellen ausreichen.

Eine individuelle Entwicklung wird sinnvoller, wenn sich eine wichtige Regel nicht abbilden lässt oder eine Schnittstelle die Arbeit einschränkt. Vergleiche Tabellenpflege und Fehlerkorrekturen mit Lizenzen, Einrichtung, Migration, Schulung, Support und Wartung der Alternative. Weder eine allgemeine Zeilengrenze noch ein pauschales Sparversprechen begründet den Wechsel.

Verlange eine Erprobung mit einem normalen und einem schwierigen Fall: doppelter Auftrag, fehlende Angaben, fehlende Berechtigung oder ausgefallene Schnittstelle. Prüfe auch, wie du beim Anbieterwechsel sämtliche Daten zurückbekommst.

Um festzulegen, was dieser Versuch zeigen soll, hilft der Vergleich von Demo, Prototyp und MVP.

07 /Bei der Migration nur einen schreibenden Datenbestand zulassen

Bereite eine Testkopie mit anonymisierten oder synthetischen Daten vor. Prüfe Kennungen, Dubletten, Datumswerte, Formeln und Pflichtfelder. Gleiche Zeilenzahlen beweisen keine korrekte Migration: Vergleiche auch Statuswerte, Beziehungen und eine Stichprobe vollständiger Datensätze.

Während des Tests bleibt das bisherige System maßgeblich; das neue dient zum Ergebnisvergleich. Beide dürfen keine voneinander unabhängigen Änderungen im laufenden Betrieb annehmen. Lege für den echten Pilotbetrieb einen Umstellungszeitpunkt fest und bestimme, welches System Änderungen annimmt. Das alte bleibt zum Nachschlagen verfügbar.

Vereinbare den Ablauf bei einem Ausfall: Wer gibt die Rückkehr frei, welcher Export oder welches Backup wird wiederhergestellt und wie werden Änderungen seit der Umstellung abgeglichen? Erprobe die Wiederherstellung. Eine alte Datei reicht nicht, wenn später angelegte Einsätze fehlen.

• Daten: Kennungen bleiben erhalten; Abweichungen bei der Anzahl sind erklärt.
• Berechtigungen: Jede Rolle kann ihre Aufgaben erfüllen und sieht keine unzulässigen fremden Datensätze.
• Wiederholung: Ein erneuter Import erzeugt keine doppelten Vorgänge; Fehler erreichen eine zuständige Person.
• Weiterarbeit: Offene Aufgaben bleiben einsehbar und Änderungen lassen sich nach einem geprüften Verfahren wiederherstellen.

08 /Was du für eine Aufwandsschätzung vorbereiten kannst

Bringe eine Beispieldatei ohne sensible Informationen mit, den Weg eines Datensatzes, die beteiligten Rollen und drei Fehler, die heute Zeit kosten. Ergänze unverzichtbare Schnittstellen und eine zuständige Person für die spätere Pflege. Das hilft mehr als eine Liste gewünschter Masken.

Miss einen repräsentativen Zeitraum vor und während des Piloten: Abstimmungsaufwand, Dubletten, Korrekturen und blockierte Aufgaben. Vereinbare, welche Verbesserung den Wechsel rechtfertigt und wer sie prüft. Wenn eine aufgeräumte Tabelle oder vorhandene Software ausreicht, ist auch das ein gutes Ergebnis.