In den meisten KMU werden ERP-Änderungen dort gemacht, wo es geht — also direkt in der produktiven Datenbank, freitags nach 16 Uhr, „weil dann eh niemand arbeitet". Bis am Montagmorgen niemand eine Rechnung schreiben kann. Eine Testumgebung ist ein langweiliges Thema, zahlt sich aber meist nach dem ersten verhinderten Ausfall aus.
Ein Szenario, das wir regelmäßig sehen. Das Unternehmen setzt seit Jahren Comarch Optima, enova365 oder Subiekt ein. Unterwegs ist ein eigenes Add-on für den Dokumentenworkflow dazugekommen, eine WMS-Integration, ein Stück Bank-Datenaustausch und ein halbes Dutzend SQL-Berichte. Alles funktioniert — bis jemand auf „Update" klickt oder den Kontenplan ändert. Dann stellt sich heraus, dass eines der Add-ons mit der neuen Version nicht mehr läuft und der Workflow für Kostenrechnungen still und leise keine Buchungen mehr erzeugt.
Eine Testumgebung schützt nicht vor allem davon. Aber sie fängt das meiste ab, bevor es die Arbeit von 30 Personen am Montagmorgen blockiert.
Was eine „Testumgebung" im KMU-Alltag wirklich ist
Lassen wir das Konzernsprech weg. In der Praxis geht es um eine zweite, getrennte ERP-Instanz, an der du etwas kaputtmachen darfst. Das kann eine separate Optima-Installation auf einem anderen Server (oder einer VM) sein, eine Datenbankkopie vom Wochenende, oder sogar ein eigener Rechner mit Subiekt und einer übertragenen Datenbank. Zwei Dinge zählen:
- Die Daten sehen echt aus — echt genug, um reale Szenarien zu testen (gleicher Kontenplan, gleiche Lager, ähnliche Belegmengen).
- Nichts, was du dort tust, landet in der echten Buchhaltung, im echten Lager oder bei der echten Bank.
Das muss nicht teuer sein. Für die meisten KMU reicht eine Datenbankkopie, die einmal pro Woche oder pro Monat aufgefrischt wird, auf demselben Server unter einem anderen Namen läuft und bei der die Verbindung zum Produktiv-SMTP und zur Bank-API gekappt ist. Kosten: ein Abend Admin-Arbeit plus etwas Plattenplatz.
Was es konkret lohnt zu testen, bevor es in die Produktion geht
Die Liste ist länger, als die meisten Firmen denken. Die häufigsten „Kunden" einer Sandbox sind:
- ERP-Upgrades (z. B. jährliches Optima-Upgrade auf eine neue Version, vierteljährliche enova365-Patches). Hier verstecken sich Konflikte mit Add-ons, die für ältere Versionen geschrieben wurden.
- Änderungen am Kontenplan, an Buchungsschemata, an Belegdefinitionen. Eine falsch gesetzte Option reicht, um die Rechnungserstellung oder die Kostenbuchung zu blockieren.
- Neue Add-ons, Integrationen, Berichte. Jedes Add-on eines Drittanbieters muss auf deinen eigenen Daten geprüft werden — die Demo des Anbieters funktioniert immer.
- Importe großer Datenpakete (z. B. eine Preisliste vom Lieferanten, ein Paket mit 5.000 Produkten vom Großhandel). Ein falsch gemapptes Importskript kann den Artikelstamm in zehn Minuten zerlegen.
- Berechtigungsänderungen — wer sieht was, wer darf freigeben. Eine harmlose Rollenanpassung kann den Vertrieb vom Preislisten-Zugriff abschneiden.
- Notfallprozeduren — Restore aus Backup, Datenbankumschaltung. Wenn du die Prozedur das erste Mal während eines echten Ausfalls ausführst, hast du keine Prozedur.
Die Regel ist einfach: Berührt die Änderung irgendetwas mit „Buchhaltung" im Namen oder betrifft sie die Rechnungsstellung — teste sie in der Sandbox. Punkt.
Wie es ohne Sandbox endet
Bei einem unserer Kunden — einem 30-Personen-Möbelhersteller mit Comarch Optima und eigenem WMS — wurden Änderungen ganz traditionell ausgerollt: freitags nach 16 Uhr, „weil dann eh niemand arbeitet". Innerhalb eines halben Jahres gab es drei Montage, an denen keine Rechnungen geschrieben werden konnten, weil etwas auseinandergelaufen war. Jeder kostete im Schnitt 4 Stunden Ausfall in der Fakturierung (Buchhaltung sucht die Ursache, zwei Vertriebsmitarbeiter warten, der Kunde wartet) plus den Stress. Macht zusammen: 12 Stunden produktive Arbeit weg, plus die Reputation bei einigen Kunden, die ihre Rechnung zu spät bekommen haben.
Nach der Einführung einer Sandbox (Datenbankkopie jeden Mittwoch aufgefrischt, identischer Kontenplan, SMTP gekappt) wurde die Regel einfach: jede Änderung zuerst auf der Testumgebung, danach Produktion, und das nur freitags zwischen 16 und 17 Uhr. In den folgenden 12 Monaten: null blockierte Montage aus Änderungsursachen. Die durchschnittliche Testzeit pro Änderung wuchs um 30–45 Minuten. Die ROI-Rechnung machst du selbst.
„Einsparungen", die am meisten kosten
Die häufigsten Argumente gegen eine Sandbox im KMU — und was sich in der Praxis daraus ergibt:
- „Wir haben Backups, im Notfall stellen wir wieder her." Stimmt. Nur bedeutet ein Restore um 9 Uhr am Montag, dass alle Belege ab Samstagmorgen verloren gehen und die Arbeit für 1–3 Stunden blockiert ist. Backup ist die letzte Rettung, kein Testwerkzeug.
- „Die Änderung ist klein, da muss man nichts testen." Die meisten ernsten Ausfälle beginnen mit einer „kleinen Änderung". In Optima reicht ein falsch gesetztes Feld in einer Belegdefinition, damit zwei Wochen Warenausgänge keine Kostenbuchungen erzeugen — und du merkst es beim Monatsabschluss.
- „Der Anbieter hat es getestet." Der Anbieter hat in seiner Umgebung getestet, mit seinem Kontenplan und seinen Add-ons. Deine sind anders. Dass es bei ihm läuft, garantiert nichts.
- „Eine Sandbox ist teuer." Ist sie nicht. Die einfachste Variante ist eine zusätzliche Optima-Instanz auf demselben Server, eine wöchentlich per Skript aufgefrischte Datenbankkopie und gekappte externe Verbindungen. Realer Aufwand: ein paar Stunden Arbeit einmalig plus ein bisschen Disziplin.
Wie wir es in 2 Wochen aufsetzen
In der Praxis ist das Projekt einfacher, als es klingt:
- Zweite Instanz des Systems. Meistens auf demselben Server, unter einem anderen Datenbanknamen. In Optima / enova / Subiekt ist das eine Installation plus das Einhängen der Datenbankkopie.
- Externe Integrationen kappen. Der Sandbox-SMTP sendet keine Mails an echte Kunden. Die Sandbox-Bank-API führt keine Überweisungen aus. Das Sandbox-WMS bewegt nichts im echten Lager. Klingt offensichtlich — und genau deshalb wird es vergessen.
- Refresh-Skript. Einmal pro Woche (meist in der Nacht von Freitag auf Samstag) wird die Testdatenbank mit einer frischen Kopie der Produktion überschrieben. So testest du auf realen Daten, nicht auf einem Museum von vor sechs Monaten.
- Kurze Prozedur auf Papier. Drei Sätze: jede ERP-Änderung zuerst in der Sandbox, in einer Datei dokumentiert, danach Produktion. Ohne diese Prozedur verstaubt die Sandbox nach zwei Monaten.
Zusammen: 5–10 Stunden Admin-Arbeit in der ersten Woche, danach 1–2 Stunden im Monat für die Pflege.
Häufige Fallen
- Sandbox zu alt. Ist die Kopie ein halbes Jahr alt, sind die Tests wertlos — der Produktionskontenplan sieht längst anders aus. Auffrischen.
- Sandbox mit echten Kundendaten nach außen geschickt. Wenn ein Anbieter um „eine Datenbankkopie zur Analyse" bittet, denk vorher an die DSGVO, bevor du das ZIP packst. Beste Praxis: Namen und Steuernummern vor dem Versand anonymisieren.
- Sandbox ohne Verantwortlichen. Wenn niemand dafür sorgt, dass sie aktuell und von außen abgekoppelt ist, stellt sich nach einem Jahr heraus, dass jemand sie an den echten SMTP gehängt und Testrechnungen an 200 Kunden geschickt hat. Bestimme eine Person.
Wo anfangen
Der einfachste erste Schritt ist die Frage: Wo haben wir die letzte ERP-Änderung getestet? Lautet die Antwort „in der Produktion, freitags nach 16 Uhr", hast du die Antwort darauf, ob du eine Sandbox brauchst.
Wenn du Comarch Optima, enova365 oder Subiekt einsetzt und mit dem Russisch-Roulette in der Fakturierung aufhören willst, sprich mit jemandem, der für diese Systeme schon Sandboxes aufgesetzt hat und weiß, was zuerst gekappt werden muss. Das erste Gespräch ist kostenlos und dauert eine halbe Stunde.
Eine Testumgebung ist kein Konzern-Luxus. Sie ist die günstigste Versicherung, die du für dein ERP abschließen kannst — vorausgesetzt, jemand nutzt sie wirklich.