Leistung · VBA
VBA · Excel und Access
Office-Automatisierung als ganze Disziplin, nicht als zwei getrennte Werkzeuge. Excel-VBA für Klick-Strecken, Reports, Outlook-Integration. Access-VBA für Formulare, Berichte, gewachsene Datenbanken bis 5 Millionen Zeilen. Refactoring auf Option Explicit, getypte Bereiche, Custom-Error-Klassen. Backend-Migration nach SQL Server, wenn Access aus den Hufen kommt. Code, der nicht beim nächsten Office-Update zerbröselt.
Das Problem
In den meisten Unternehmen, in denen ich gerufen werde, hängt mindestens ein geschäftskritischer Ablauf an einer einzigen Excel-Datei: SAP-Export landet im Sheet, eine Person klickt sich durch zwölf Pivot-Tabellen, am Ende geht ein PDF an die Geschäftsführung. Funktioniert, solange diese eine Person da ist, kein Spaltenname sich ändert und kein Patch von Microsoft das Object-Model anfasst.
Was ich typisch vorfinde: 800 Zeilen VBA ohne Option Explicit, globale Variablen die quer durch die Module wandern, On-Error-Resume-Next als Fehlerbehandlung, alte FileSystemObject-Aufrufe ohne Late-Binding-Schutz. Häufig ist sogar die Datei selbst das Problem: gemischte Datentypen in der gleichen Spalte, verbundene Zellen in der Datenzone, Formeln mit hartcodierten Zellbezügen, die bei jeder Einfügung brechen.
Excel ist nicht das Problem. Excel ohne Struktur ist das Problem. Ein Refactor-Aufwand von 2-4 Tagen erspart oft Monate an Symptom-Bekämpfung.
Die Lösung
Ich räume bestehendes VBA in klar geschnittene Module auf: Datenzugriff, Geschäftslogik, UI/Reporting separat. Workbook und Sheet werden in Eingabe-, Verarbeitungs- und Ausgabezonen zerlegt, mit benannten Tabellen (ListObjects) statt Range-Adressen. Fehlerbehandlung mit definierten Custom Errors, Logging in ein eigenes Worksheet oder Logfile, keine stillen Exit-Subs mehr.
Externe Quellen binde ich mit Power Query als Lade-Schicht an, wo das die robustere Lösung ist. VBA übernimmt dann nur noch das, was Power Query schlecht kann: Steuerung, Benutzerinteraktion, Outlook- oder PDF-Ausgabe. Die Trennung macht Wartung in beiden Welten dramatisch einfacher.
Lieferumfang ist immer dasselbe Paket: refaktorierte XLSM- oder XLSB-Datei, exportierte .bas/.cls-Module für Versionskontrolle (ich lege sie auf Wunsch in Ihr Git oder Azure DevOps), eine README mit Setup, Annahmen, bekannten Grenzen und einer Schritt-für-Schritt-Anleitung für Wartung. Ein zweiter Entwickler kommt in unter einer Woche rein.
Typische Anwendungsfälle
- Monatliches Management-Reporting: SAP-/Salesforce-Exporte einlesen, mit Stammdaten joinen, Kennzahlen berechnen, PDF erzeugen, per Outlook versenden
- Bestehende VBA-Bestände (500-3.000 Zeilen) refaktorieren auf Option Explicit, getypte Variablen, Custom-Error-Klassen, Modul-Separation
- Bulk-Imports von CSV/XLSX mit Schema-Validierung, Plausibilitätsprüfungen und detailliertem Fehler-Log statt Crash bei der ersten ungültigen Zelle
- PDF-Export-Pipelines mit reproduzierbarem Layout, Seitenumbruch-Logik, dynamischen Anhängen pro Empfänger, Ablage nach festem Namensschema
- Outlook-Integration: Vorlagen mit personalisierten Daten füllen, Anhänge, Empfängerlisten aus Excel, Logging der versendeten Mails
- Migration von Excel-Logik in Power Query, wenn die VBA-Schicht zu groß geworden ist und PQ technisch besser passt
Konkreter Nutzen
- Wartbarkeit: ein zweiter Entwickler übernimmt die Datei in 3-5 Tagen ohne mündliche Übergabe
- Robustheit: Custom-Error-Klassen mit Logging statt On-Error-Resume-Next, Updates des Office-Pakets brechen nichts Stillschweigendes
- Versionierbarkeit: VBA-Module liegen als .bas/.cls-Dateien im Git, Diffs sind lesbar, Code-Review möglich
- Performance: 10.000-Zeilen-Operationen statt 90 Sekunden in 3-4 Sekunden (Range-Variant statt Cell-by-Cell, ScreenUpdating-Off, Calculation-Manual)
- Audit-Fähigkeit: jede Datenmanipulation hinterlässt eine Log-Spur, nachvollziehbar für Revisor oder Wirtschaftsprüfer
So läuft die Zusammenarbeit
Discovery (90 min, remote)
Sie zeigen mir die Datei und beschreiben den Prozess. Ich frage nach Quellsystemen, Häufigkeit, Nutzern, Datenschutz-Constraints. Sie bekommen schriftlich eine Einordnung mit Risiken und Empfehlung: lohnt sich Refactor, Neubau oder Migration auf Power Query.
Audit (1-2 Tage, optional)
Bei größeren Beständen: vollständige Begutachtung der VBA-Codebasis und Datenarchitektur. Output ist ein 4-6-seitiger Bericht mit Findings (z. B. fehlende Option Explicit, ungeschützte Schreibvorgänge, kritische Performance-Hotspots), priorisiertem Backlog und realistischem Aufwand.
Refactor / Neubau in 1-2-Wochen-Inkrementen
Iterative Umsetzung mit kurzen Reviews. Jedes Inkrement ist lauffähig, getestet mit echten (anonymisierten) Daten, dokumentiert. Sie können jederzeit aussteigen, ohne mit halbfertigem Code dazustehen.
Übergabe mit Doku, Code-Walkthrough, optional Retainer
Finale Datei, README, exportierte Module für Ihr Git, 30-60 min Live-Walkthrough mit Aufzeichnung. Optional Retainer für Wartung, Erweiterungen, Office-Update-Reviews.
Häufige Fragen
Ist VBA nicht veraltet, sollten wir nicht auf Python oder Power Automate setzen?
Kommt auf den Use-Case an. Wenn der Output in Excel bleibt und der Prozess Office-Welt nicht verlässt, ist VBA in 2026 immer noch die robusteste Antwort: läuft offline, braucht keine zusätzliche Lizenz, ist auf jedem Office-Client verfügbar. Sobald mehrere Quellsysteme dazukommen oder die Daten Excel verlassen, sage ich von mir aus Power Query, Python oder n8n. Ehrliche Beratung kostet weniger als ein falsches Tool.
Können wir die Lösung später selbst pflegen?
Ja, wenn die Struktur stimmt. Genau dafür sind getypte Module, Option Explicit, exportierte .bas-Dateien, README und Code-Walkthrough da. Ein Mitarbeiter mit grundlegender VBA-Erfahrung übernimmt in einer Woche. Bei tieferen Erweiterungen können wir einen Retainer vereinbaren.
Was passiert bei einem Office-Update oder einer Microsoft-365-Migration?
Mit Option Explicit, Late-Binding für externe Bibliotheken und Vermeidung deprecated APIs (z. B. veralteter MSXML-Versionen) sind die meisten Macros updateresistent. Die häufigsten Brüche kommen durch ActiveX-Controls und Listobjekte aus Excel 2003-Zeiten. Bei Migrationen prüfe ich die Codebasis auf solche Risiken vorab.
Wie verhindern Sie, dass die Datei nach 18 Monaten wieder unleserlich ist?
Strikt getrennte Module (Data, Logic, UI), eine README mit Erweiterungs-Konventionen, und der Verweis aufs Git mit den .bas-Exports. Wenn das Team die Konventionen nicht einhält, kann auch der beste Code zerfallen. Deshalb ist die kurze Schulung Teil der Übergabe.
Wie lange dauert ein typisches Projekt und was kostet es?
Refactor einer mittelgroßen Datei (1.500-2.500 Zeilen VBA): 8-14 Werktage, je nach Datenkomplexität. Neubau einer Reporting-Pipeline inkl. Power-Query-Schicht: 10-20 Werktage. Bei Stundensatz 140-180 € sind das 9.000-25.000 €. Nach dem Discovery-Workshop gibt es einen belastbaren Rahmen, größere Projekte können auf Festpreis umgestellt werden.
Arbeiten Sie auch mit verschlüsselten oder passwortgeschützten Dateien?
Ja, wenn Sie das Passwort haben. Ich entferne Schutzmechanismen nicht ohne ausdrücklichen Auftrag und nur an Dateien, die Ihnen gehören. Bei Drittanbieter-Add-Ins oder lizenzgeschützten Vorlagen klären wir vorab die Rechtslage.
Passende weitere Leistungen
Excel-VBA-Bestand auditieren lassen?
Schicken Sie mir die Datei oder eine anonymisierte Version. Sie bekommen innerhalb von zwei Werktagen eine ehrliche Einschätzung zurück: lohnt sich Refactor, lohnt sich Neubau, oder ist Power Query die bessere Antwort.