Legacy-Systeme ergänzen, statt sie zu ersetzen

"Never touch a running system" klingt nach einer Ausrede - ist aber in vielen Mittelstandsbetrieben eine rationale Haltung. Ein System, das seit Jahren läuft, trägt oft Wissen, das nirgendwo dokumentiert ist: warum ein bestimmter Workaround existiert, welche Abteilung sich auf ein bestimmtes Verhalten verlässt, was passiert, wenn ein Feld anders befüllt wird als vorgesehen. Niemand will derjenige sein, der diese Kette aus Gewohnheit und stillem Wissen anfasst und etwas zerbricht. Die eigentliche Frage ist deshalb selten "wie ersetzen wir das System", sondern "wie bekommen wir den Nutzen einer neuen Oberfläche, ohne dieses Risiko einzugehen".

Ergänzen statt ersetzen: was sich ändert - und was nicht

Die Antwort ist ein Muster, das in der Softwarearchitektur seit Jahren etabliert ist, im Mittelstand aber selten so benannt und eingesetzt wird: eine neue Oberfläche, die über eine schmale, sauber abgegrenzte Integrationsschicht auf das bestehende System zugreift - lesend, gezielt schreibend, oder beides - ohne dessen interne Logik, Datenmodell oder Berechtigungsstruktur zu verändern. Am bestehenden System ändert sich dadurch nichts: keine neue Version, kein Wartungsfenster, kein Risiko, dass ein jahrealter Report plötzlich anders aussieht. Neu ist ausschließlich die zusätzliche Ansicht daneben.

Warum das Change-Management-Problem oft größer ist als das technische

Eine erzwungene Migration bringt fast immer Widerstand mit sich - nicht, weil Mitarbeitende technikfeindlich wären, sondern weil sie ein funktionierendes Werkzeug gegen eines eintauschen sollen, das sie erst lernen müssen, während das Tagesgeschäft weiterläuft. Eine optionale, zusätzliche Oberfläche umgeht diesen Konflikt vollständig: Wer mit dem bestehenden System zufrieden ist, arbeitet unverändert weiter. Wer von einer vereinfachten, auf die eigene Rolle zugeschnittenen Ansicht profitiert, nutzt sie freiwillig. Es gibt keine Deadline, keinen Stichtag, an dem der alte Weg abgeschaltet wird - und genau das nimmt einer Einführung den größten Teil ihres organisatorischen Sprengstoffs.

Eine engere Ansicht als Datenschutz-Vorteil

Eine rollenbasierte Oberfläche zeigt einer Stakeholder-Gruppe nur den Ausschnitt, den ihre Rolle tatsächlich benötigt - statt vollen Zugriff auf ein System zu gewähren, dessen übrige Daten sie nie sehen müsste. Das ist eine gut begründbare Umsetzung von Datenminimierung (Art. 5 Abs. 1 lit. c DSGVO) und dem Need-to-know-Prinzip, das als Standard-Schutzmaßnahme ohnehin erwartet wird. Eine pauschale gesetzliche Pflicht für genau dieses Muster gibt es nicht - es ist eine naheliegende, gut vertretbare Lesart der Grundsätze, keine explizit vorgeschriebene Architektur. Wer diesen Vorteil belastbar dokumentieren will, sollte die konkrete Umsetzung trotzdem mit der eigenen Datenschutzberatung abstimmen, statt sich allein auf diese Einordnung zu verlassen.

Drei Szenarien aus der Praxis

Ein Management-Dashboard über mehreren Systemen

Eine Geschäftsführung oder ein Bereichsleiter braucht monatliche Kennzahlen, keinen vollständigen Zugang zu jedem einzelnen System. Named-User-Lizenzmodelle bepreisen jeden zusätzlichen Zugriff einzeln - eine schreibgeschützte, rollenbasierte Ansicht über eine sauber abgegrenzte Integrationsschicht kann diesen Bedarf oft decken, ohne zusätzliche Lizenzen zu kaufen - abhängig von den Lizenzbedingungen des jeweiligen Anbieters, die vorab zu prüfen sind. Oft liegen die relevanten Zahlen ohnehin nicht in einem einzigen System, sondern verteilt über das ERP, eine gepflegte Excel-Tabelle und ein drittes internes Tool - genau die unaufgeräumte, undokumentierte Datenlage, an der eine generische BI-Lösung wie Power BI oder Tableau scheitert oder zumindest deutlich mehr Aufwand verursacht als geplant. Eine maßgeschneiderte Ansicht, die exakt die Frage beantwortet, die eine Rolle tatsächlich hat, kommt dagegen ohne zusätzliche BI-Lizenzen, ohne Schulungsaufwand für ein weiteres Werkzeug und ohne den Umweg über Rohdatentabellen aus, die ohnehin niemand außerhalb der Integrationsschicht sehen sollte.

Eine vereinfachte Eingabemaske für den Außendienst

Lager- oder Servicepersonal braucht selten die volle Bandbreite eines ERP-Formulars - oft reichen fünf bis acht Felder: Status, Menge, ein Foto, eine Unterschrift. Eine schlanke Oberfläche, die genau diese Felder über die Integrationsschicht zurückschreibt, reduziert Fehlerquellen und Schulungsaufwand gleichzeitig, ohne die volle ERP-Transaktion offenzulegen.

Ein Self-Service-Portal über einer Excel- oder SharePoint-Liste

Viele Prozesse laufen weiterhin in einer von einem Team gepflegten Excel-Datei oder SharePoint-Liste - genau solche Workflows werden selbst schnell zum Betriebsrisiko, sobald sich niemand mehr um Zugriffskontrolle und Nachvollziehbarkeit kümmert. Externe Stakeholder - eine andere Abteilung, ein Lieferant - bekommen heute oft vollen Ordnerzugriff oder eine per E-Mail verschickte Kopie. Ein gefiltertes Portal zeigt stattdessen nur die relevanten Zeilen, während die ursprüngliche Liste weiterhin die führende Datenquelle bleibt.

Wo die Grenzen liegen

Das Muster passt nicht überall. Wenn ein System selbst - nicht nur der Zugriff darauf - das eigentliche Risiko ist (unsichere Authentifizierung, fehlende Protokollierung, ein nicht mehr wartbarer Kern), löst eine zusätzliche Oberfläche dieses Problem nicht, sie verdeckt es höchstens. Und wenn der Schreibzugriff komplex wird - viele verzahnte Felder, Validierungsregeln, die tief in der Fachlogik des alten Systems stecken - wächst die Integrationsschicht selbst schnell zu einem eigenen, pflegebedürftigen System heran. Ab einem gewissen Punkt kann es sinnvoller sein, statt die Integrationsschicht weiter auszubauen, die Ablösung schrittweise anzugehen - eine dauerhafte ergänzende Oberfläche und eine spätere Ablösung sind beides mögliche Wege, keiner davon ist von Anfang an vorausgesetzt. Genau das ist auch mein Ansatz: erst verstehen, was das bestehende System tatsächlich leistet und wo sein Risiko liegt, dann entscheiden, ob eine ergänzende Oberfläche reicht oder ob mehr nötig ist.