Analyse

Die App geht, die Daten bleiben

Veröffentlicht: 6 MinutenKI-Management

Kurzfassung: Wenn KI neue Fachanwendungen leichter herstellbar macht, sollte nicht jede Anwendung ihre eigene Datenwelt samt Zugriffsregeln aufbauen. Austauschbare Oberflächen brauchen dauerhafte Datenzugänge und klar geregelte Schreibzuständigkeiten. Architekturleitfäden von Microsoft und AWS zeigen zugleich die Grenze: Eine lesbare Datenkopie ersetzt weder das führende Geschäftssystem noch dessen Buchungsregeln.

Ein Ersatzteilassistent ist schnell vorgeführt: Kundenanfrage öffnen, Anlagenhistorie lesen, passende Teile vorschlagen. Schwieriger wird die zweite Version. Ein anderer Anbieter liefert die bessere Anwendung, doch Kundenkennungen, Berechtigungen und Zuordnungen sind inzwischen in der ersten Lösung verbaut. Der Austausch der Oberfläche zieht einen erneuten Datenumbau nach sich.

Das ist ein hypothetisches Beispiel, aber eine konkrete Architekturentscheidung. Wer KI-generierte Fachanwendungen erwägt, sollte nicht zuerst fragen, welches ERP sie ersetzen können. Wichtiger ist, welche Teile dauerhaft dem Unternehmen zur Verfügung stehen müssen, auch wenn die nächste Anwendung wieder verschwindet.

Datenzugang und Buchungszuständigkeit sind zwei Entscheidungen

Ein Datenbestand kann für mehrere Anwendungen zugänglich sein, ohne dass jede davon verbindliche Geschäftsvorgänge verändern darf. Ein Assistent kann etwa verfügbare Ersatzteile anzeigen. Eine Reservierung muss zusätzlich verhindern, dass zwei Aufträge denselben letzten Bestand erhalten. Die angezeigte Menge und die verbindliche Vergabe erfüllen verschiedene Aufgaben.

Daraus folgt eine sinnvolle Trennung: Fachanwendungen erhalten definierte Datenzugänge; fachliche Änderungen laufen über die dafür zuständigen Dienste. Das bestehende ERP kann zunächst die maßgebliche Instanz für Bestände und Aufträge bleiben. Eine neue Anwendung muss dann nicht sämtliche Buchungsregeln nachbauen, um eine bessere Bedienung anzubieten.

Microsoft beschreibt im Strangler-Fig-Architekturmuster, wie sich Funktionen eines Altsystems schrittweise durch neue Dienste ablösen lassen. Eine vorgeschaltete Vermittlung leitet Anfragen entweder an den Bestand oder an neue Komponenten. Der Leitfaden behandelt ausdrücklich auch gemeinsam genutzte Dienste und Datenspeicher sowie Abhängigkeiten zwischen beiden Systemen.

Das ist kein Beleg dafür, dass KI ein ERP günstig nachbauen kann. Es ist eine Anleitung zur schrittweisen Modernisierung. Für die Beschaffung liegt darin eine Alternative zum Alles-oder-nichts-Projekt: Eine Anwendung darf neu sein, während die verbindliche Verarbeitung im Kernsystem bleibt. Erst wenn eine bestimmte fachliche Zuständigkeit tatsächlich übertragen werden soll, beginnt für diesen Teil die Datenmigration.

Eine Datenkopie ist noch keine neue Geschäftswahrheit

Im Datenbankbeispiel des Microsoft-Leitfadens werden zunächst die Daten einer fachlich abgegrenzten Domäne übernommen. Ein ETL-Prozess überträgt vorhandene Daten; Change Data Capture, kurz CDC, synchronisiert Änderungen aus der bisherigen Datenbank. Vor dem Umschalten verlangt das Muster eine Prüfung der Konsistenz. Erst danach wird die neue Domänendatenbank zum „System of Record“, also zur maßgeblichen Instanz dieses Bereichs.

Diese Reihenfolge ist wichtig. Dass ein Assistent einen Datensatz lesen kann, sagt noch nicht, ob seine Sicht aktuell genug für eine Zusage ist. Und dass eine Kopie vollständig erscheint, überträgt ihr noch keine fachliche Zuständigkeit. Ein Data Lake, in dem viele Bestände zusammenlaufen, kann Auswertungen und Suche erleichtern. Daraus entsteht nicht automatisch ein Ersatz für Auftragsbuchung, Bestandsführung oder Rechnungslogik.

Für den beispielhaften Ersatzteilassistenten könnte die Aufteilung so aussehen: Historien und Produktbeschreibungen kommen aus einem wiederverwendbaren Datenzugang. Vor einer Lieferzusage fragt die Anwendung den aktuellen Bestand beim führenden Dienst ab. Eine Reservierung erhält erst dann einen verbindlichen Status, wenn dieser Dienst sie angenommen hat. Wie viel Verzögerung bei reinen Suchdaten vertretbar ist, entscheidet der jeweilige Anwendungsfall.

Die Entkopplung besteht also nicht darin, möglichst viele Kopien anzulegen. Sie besteht in stabilen Vereinbarungen: Was bedeutet ein Datenobjekt? Welche Kennung bleibt erhalten? Wie aktuell ist die gelieferte Sicht? Welcher Dienst darf den Zustand verbindlich ändern? Diese Vereinbarungen sollten länger leben als die einzelne Oberfläche.

Rechte dürfen beim App-Wechsel nicht verloren gehen

Ein gemeinsamer Datenzugang hilft wenig, wenn jede neue Anwendung die Berechtigungen neu erfindet. Im ungünstigen Fall sieht ein Assistent mehr als die Person, für die er arbeitet. Oder ein Mitarbeiter verliert im führenden System den Zugriff, während eine kopierte Datenwelt ihn weiter zulässt.

Dass feinere Datenrechte technisch umsetzbar sind, zeigt die Dokumentation von AWS Lake Formation zur Datenfilterung. Sie beschreibt Einschränkungen auf Spalten-, Zeilen- und Zellebene für Abfragen über integrierte Dienste. Ein Beispiel begrenzt Personaldaten nach Region, ein anderes blendet sensible Spalten aus. Solche Regeln sind damit nicht bloß eine Eigenschaft der sichtbaren Bedienmaske.

Die Dokumentation nennt aber eine entscheidende Grenze: Die beschriebenen Filter gelten nur für Leseoperationen; mit ihnen wird die Berechtigung SELECT vergeben. Aus gefiltertem Lesen folgt keine Erlaubnis zum Ändern oder Buchen. Ebenso wenig belegt diese Produktfunktion, dass Rechte aus einem beliebigen ERP automatisch korrekt übernommen werden.

Für Unternehmen entsteht daraus ein eigener Arbeitsauftrag. Identitäten, Datenobjekte und zulässige Aktionen müssen zwischen den Systemen zugeordnet werden. Die Rechteprüfung muss auf dem tatsächlich genutzten Zugriffsweg greifen. Wird die Anwendung ausgetauscht, dürfen weder weitergehende Zugriffe entstehen noch fachlich notwendige Einschränkungen verschwinden. Das lässt sich an konkreten Fällen prüfen: Ein Servicemitarbeiter sieht die erlaubten Anlagen, aber keine fremden Kundenkonditionen; ein entzogener Zugriff wird auch in der neuen Anwendung wirksam.

Der erste Auftrag kann kleiner sein als eine neue Datenplattform

Die Konsequenz ist nicht, vor dem nächsten KI-Versuch sämtliche Unternehmensdaten in eine große Plattform zu verschieben. Auch eine neue zentrale Schicht verursacht Betrieb, Abhängigkeiten und Kosten. Microsoft weist beim Strangler-Fig-Muster ausdrücklich auf die temporären Infrastrukturkosten der Übergangsarchitektur hin. Die vorgeschaltete Vermittlung darf zudem weder zum Engpass noch zum einzelnen Ausfallpunkt werden.

Für ein mittelständisches Unternehmen ist deshalb ein begrenzter Anfang oft aussagekräftiger. Eine Fachanwendung bekommt einen dokumentierten Lesezugang für einen klaren Datenbereich und einen gesonderten Weg für verbindliche Änderungen. Fachbereich und IT legen gemeinsam fest, welche Quelle gilt und welche Rechte greifen. Der Einkauf verlangt, dass Kennungen, Schnittstellen und nötige Zuordnungen auch mit einer anderen Anwendung nutzbar bleiben.

Der passende Abnahmetest ist dann nicht nur eine überzeugende Vorführung. Eine zweite, kleine Anwendung sollte denselben Datenzugang verwenden können, ohne Kundenidentitäten und Berechtigungen erneut aufzubauen. Damit wird die versprochene Austauschbarkeit praktisch sichtbar. Der Test zeigt, ob der Datenzugang wiederverwendbar ist. Ob sich die zusätzliche Architektur wirtschaftlich lohnt, muss das Unternehmen gesondert rechnen.

Soll später auch die führende Datenhaltung wechseln, braucht dieser Schritt eine eigene Entscheidung. Microsoft beschreibt den Rückweg als deutlich aufwendiger, sobald alte Tabellen, Prozeduren und Synchronisationsprozesse entfernt sind. Die Abschaltung des Bestands ist deshalb etwas anderes als die Freigabe einer neuen Oberfläche.

Der wirtschaftliche Spielraum liegt genau in dieser Unterscheidung: Fachanwendungen können schneller wechseln, ohne dass das Unternehmen bei jedem Wechsel seine Datenordnung neu aufbauen muss. Das ERP bleibt, wo seine Transaktionsfunktionen gebraucht werden. Ablösbar wird zunächst die Anwendung, nicht ungeprüft die Verantwortung für die Geschäftsdaten.

← Zurück zum Blog