„Den Rechner fassen wir nicht an. Wenn da ein Update kommt, läuft der Lohnlauf nicht mehr.“ — Diesen Satz habe ich in den letzten Jahren in norddeutschen KMU öfter gehört, als mir lieb ist. Manchmal geht es um den Lohnlauf. Manchmal um die Auftragserfassung. Manchmal um die Provisionsabrechnung. Immer steht irgendwo unter einem Schreibtisch oder in einer Abstellkammer ein Rechner, von dem die halbe Firma abhängt — und den niemand mehr anfasst.
Das ist kein Spezialfall. Das ist der Normalfall.
Was ist das Problem, wenn der Rechner doch läuft?
Er läuft. Bis er nicht mehr läuft. Und dann läuft nichts mehr.
Die Access-Datenbank auf diesem Rechner ist über Jahre gewachsen. Formulare, Berichte, VBA-Module, verknüpfte Tabellen, vielleicht ein paar ODBC-Anbindungen an Altsysteme. Irgendwann hat ein Windows-Update etwas kaputtgemacht — eine ActiveX-Komponente, ein Druckertreiber, eine Referenz auf eine Bibliothek, die es in der neuen Version nicht mehr gibt. Seitdem gilt die Regel: Rechner in Ruhe lassen.
Das Ergebnis ist ein produktives System, das außerhalb jeder IT-Sicherheitsstrategie läuft. Keine Sicherheitsupdates. Oft Windows 10 oder älter, ohne Support. Antivirus deaktiviert, weil der auch schon mal Ärger gemacht hat. Backups? Vielleicht. Getestet? Selten.
Definition: Single Point of Failure Ein Single Point of Failure ist eine einzelne Komponente, deren Ausfall das Gesamtsystem zum Stillstand bringt.
Genau das ist dieser Rechner. Nur dass er meistens keiner offiziellen Systemlandschaft angehört, in der jemand über solche Begriffe nachdenkt.
Was kostet es konkret, wenn die Festplatte stirbt?
Mehr als die meisten Geschäftsführer im Kopf haben. Nicht der Rechner ist teuer — der Stillstand ist es, plus die Wiederherstellung von etwas, das nie dokumentiert wurde.
Rechnen wir es an einem realistischen Beispiel durch. Mittelständisches Handelsunternehmen, 80 Mitarbeiter, Access-Anwendung für Auftragserfassung und Kommissionierung. Montagmorgen, 7:30 Uhr: Der Rechner fährt nicht mehr hoch. S.M.A.R.T.-Fehler, Festplatte defekt.
Phase 1 — Die ersten Stunden (Diagnose und Panik) Der IT-Leiter oder der externe Dienstleister braucht zwei bis vier Stunden, um festzustellen, dass die Platte wirklich tot ist und nicht nur zickt. In dieser Zeit steht die Auftragserfassung. Bei 80 Mitarbeitern ist etwa ein Viertel direkt betroffen, die anderen irgendwann mittelbar. Grobe Hausnummer: 20 Personen stehen still, bei einem Mischkostensatz von 50 Euro pro Stunde sind das 1.000 Euro je Stunde.
Phase 2 — Das Backup (wenn es eins gibt) Jetzt wird das letzte Backup gesucht. Im besten Fall von vorgestern Abend. Das bedeutet: Ein bis zwei Tage Dateneingaben sind weg. Lieferscheine, Bestellungen, Kundenänderungen, die seitdem eingegeben wurden, müssen rekonstruiert werden. Aus Papier, aus E-Mails, aus dem Gedächtnis. Zwei bis drei Tage parallele Nacharbeit für mehrere Mitarbeiter.
Phase 3 — Die Access-Datei selbst Das Frontend liegt lokal auf dem Rechner. Die .accdb– oder .mdb-Datei ist weg. Wenn niemand die aktuelle Version gesichert hat — und bei fest installierten Einzelplatz-Setups ist das oft so — ist auch die gesamte Programmlogik weg. VBA-Code, Formulare, Berichte. Der ursprüngliche Entwickler ist seit fünf Jahren in Rente, sein Nachfolger hat nur Teile weiterentwickelt. Die letzte vollständige Version existiert nur noch auf dieser Platte.
Phase 4 — Wiederaufbau Im günstigen Fall findet sich eine ältere Kopie, die jemand mal auf einen USB-Stick gezogen hat. Dann werden die Änderungen der letzten Monate oder Jahre nachgezogen. Im ungünstigen Fall wird ein Datenrettungsdienst beauftragt — 800 bis 4.000 Euro, Erfolg nicht garantiert.
Aus meiner Praxis im norddeutschen Mittelstand zeigt sich: Der Totalschaden eines solchen Setups liegt selten unter 15.000 Euro, schnell aber auch bei 40.000 bis 80.000 Euro, wenn Daten verloren gehen und Prozesse tagelang manuell laufen müssen. Der Schaden durch verlorenes Vertrauen bei Kunden, die drei Tage auf Lieferscheine warten, ist dabei noch nicht eingepreist.
Ein Rechner, den niemand anfassen darf, ist keine Ersparnis. Er ist eine geparkte Rechnung.
Warum ist das in so vielen KMU so entstanden?
Weil es nie eine einzelne Entscheidung war. Es war eine Reihe vernünftig aussehender Kleinentscheidungen über 10 bis 20 Jahre.
- Jemand hat Mitte der 2000er eine Access-Datenbank gebaut, weil es schnell ging und funktioniert hat.
- Die Datenbank wuchs mit dem Unternehmen mit. Jedes Jahr kamen Formulare und Berichte dazu.
- Der ursprüngliche Entwickler ist intern ausgeschieden oder extern abgesprungen.
- Ein Windows-Update hat mal Ärger gemacht. Seitdem gilt: Finger weg.
- Die IT-Abteilung hat sich aus Selbstschutz zurückgezogen. „Das ist Sache der Fachabteilung.“
- Die Fachabteilung hat keinen Plan B, weil niemand sie jemals nach einem gefragt hat.
Das ist keine Inkompetenz. Das ist, wie Legacy-Systeme entstehen — still, schleichend, durch lauter nachvollziehbare Einzelentscheidungen. Der Punkt ist nur: Irgendwann muss jemand die Summe dieser Entscheidungen wieder aufdröseln.
Was ist jetzt zu tun, ohne gleich alles umzubauen?
Nicht sofort migrieren. Zuerst die Zeitbombe entschärfen. In dieser Reihenfolge:
- Den aktuellen Zustand sichern. Eine vollständige Image-Kopie der Festplatte, nicht nur die
.accdb-Datei. So lässt sich das System im Fehlerfall auf jeder beliebigen Hardware wieder aufsetzen, auch in einer virtuellen Maschine. Kosten: ein paar Stunden, eine externe Platte. - Die Access-Anwendung versionieren. Eine aktuelle Kopie der Datei täglich oder wöchentlich auf ein zweites System ziehen. Automatisiert, nicht per „der Herr Meier denkt da immer dran“. Ein simples Skript reicht.
- Den Rechner virtualisieren. Aus dem physischen Kasten unter dem Schreibtisch wird eine VM auf einem modernen Host. Das macht ihn hardwareunabhängig. Wenn die VM stirbt, läuft in 30 Minuten eine Kopie auf einer anderen Maschine.
- Die Anwendung dokumentieren, bevor jemand sie modernisiert. Welche Formulare werden genutzt, welche VBA-Module tun was, welche Daten fließen wohin. Ohne diese Karte ist jede Migration ein Blindflug.
- Dann erst entscheiden, was daraus wird. Bleibt Access mit SQL Server Backend? Wird es eine Webanwendung? Das ist die Strategiefrage nach der Akutversorgung, nicht davor.
Schritt 1 bis 3 sind in ein bis zwei Tagen erledigt und kosten einen niedrigen vierstelligen Betrag. Sie verhindern den 80.000-Euro-Schaden. Das ist kein schlechtes Verhältnis.
Wo die einfachen Lösungen an Grenzen stoßen
Virtualisierung und Image-Backup entschärfen das akute Ausfallrisiko, aber sie beheben nicht die Ursachen. Der VBA-Code ist immer noch fragil. Die Datenbank-Struktur ist immer noch historisch gewachsen. Die Abhängigkeit von einem Einzelsystem bleibt.
Was die Notfallmaßnahmen kaufen, ist Zeit — Zeit, um die Modernisierung ordentlich zu planen, statt sie im Krisenmodus zu erzwingen. Wer direkt zur Migration springt, ohne vorher zu sichern, migriert möglicherweise einen instabilen Stand in ein neues System und erbt alle alten Probleme samt neuer Bugs.
Struktur vor Migration. Erst absichern, dann sauber planen.
Was als Nächstes sinnvoll ist
Wenn einer der Sätze in diesem Text klingt wie aus dem eigenen Unternehmen zitiert, lohnt ein ehrlicher Blick auf den Ist-Zustand. Ich biete dafür den Access-Datenbank-Schnellcheck an: ein strukturierter Kurzaudit der bestehenden Access-Anwendung und des Systems drumherum, mit klarer Einschätzung zum Risiko und zu den nächsten drei sinnvollen Schritten. Ohne Migrationsdruck und ohne Verkaufsgespräch am Ende.
Mehr dazu unter sesoft.de/access-datenbank-schnellcheck.
Beitragsbild-Vorschlag: Ein alter Desktop-Rechner unter einem Schreibtisch, mit einem handgeschriebenen Zettel „NICHT AUSSCHALTEN!“ auf dem Gehäuse. Staub auf dem Lüftungsgitter. Bewusst leicht zu warm gefärbt, damit die Dringlichkeit unterschwellig mitklingt.
