Kontext
Stammdaten sind das stille Fundament jedes Prozesses, und genau deshalb fällt niemandem auf, wenn sie schleichend verrotten. Eine Mindestbestellmenge, die dem Rundungswert widerspricht, ein Lieferant, den es faktisch nicht mehr gibt: Solche Fehler erzeugen keine Fehlermeldung, sondern falsche Bestellungen, falsche Auswertungen und falsche Ergebnisse in jedem AI-Vorhaben, das auf diesen Daten aufsetzt.
Geprüft wird bisher von Hand oder mit Datenbankabfragen, die nur die IT schreiben kann. Jede Prüfung gilt für ein System. Was zwischen zwei Systemen nicht zusammenpasst, sieht niemand.
Ansatz
Eine zentrale Anwendung, an die sich die Systeme anbinden lassen, in denen die Daten wirklich liegen: SAP S/4HANA und SuccessFactors, SAP HANA, Salesforce, Databricks, Microsoft Fabric, Dateien in AWS S3 oder Azure, dazu jede REST-Schnittstelle. Wer kein System anbinden will, schickt seine Daten über eine Push-Schnittstelle hinein. Die Anwendung liest, prüft und berichtet. In die Quellsysteme schreibt sie nie.
AI ist in jedem Schritt dabei und entscheidet in keinem allein.
Was die Anwendung kann
Anbinden. Verbindungen anlegen und per Knopfdruck testen. Zugangsdaten liegen verschlüsselt und sind nie wieder lesbar, auch nicht für den Assistenten. Tabellen und Dateien werden mit ihren Feldern automatisch eingelesen, mit Vorschau auf die echten Daten.
Regeln. 65 Standardregeln kommen mit: IBAN, Umsatzsteuer-ID, Postleitzahlen, E-Mail, Ländercodes, Währungen, Handelsregister und mehr, gebündelt in acht fachlichen Profilen wie Adressdaten oder Bankdaten. Vier Regelarten decken den Rest ab: Pflichtfeld, Format, erlaubte Werte, Konsistenz zwischen Feldern. 18 Umformungen bereinigen Werte vor der Prüfung, etwa Leerzeichen, Groß- und Kleinschreibung oder führende Nullen.
Regeln finden. Für jede Tabelle schlägt die Anwendung passende Regeln vor, in zwei Stufen: erst nach Feldtyp und Beschreibung, dann liest die AI die Felder und begründet, welche Regel wozu passt. Jede zugewiesene Regel trägt ihre Herkunft, manuell oder AI-Vorschlag. Die Qualität der Vorschläge wird an einem Testmodell mit Soll-Ergebnissen gemessen, nicht behauptet.
Regeln formulieren. Der Assistent ist in jedem Bereich andockbar und kennt, was gerade geöffnet ist. Wer eine Regel in eigenen Worten beschreibt, bekommt daraus Muster, Regelart und Parameter vorgeschlagen. Bei Unklarheiten fragt er zurück. Jede Änderung geht über eine Karte, in der alle Werte sichtbar und änderbar sind, und wird erst mit Bestätigung gespeichert.
Prüfen. Eine Prüfkonfiguration bündelt Tabellen und Felder und wird freigegeben, bevor sie laufen darf. Sie friert Felder und Regeln ein, damit spätere Änderungen alte Ergebnisse nicht verfälschen. Ein Lauf startet sofort, auf Abruf oder von außen über die Push-Schnittstelle, verarbeitet die Daten in Blöcken und zeigt den Fortschritt live.
Ergebnis. Vom Lauf bis zum einzelnen Verstoß in fünf Ebenen, mit dem geprüften Wert und dem Originalwert. Ein Qualitätswert je Lauf, ein Dashboard mit dem Wert der letzten sieben Tage, Trend je Tabelle und einer Liste „Braucht Aufmerksamkeit”.
Berichten. Auf Knopfdruck schreibt die AI den Bericht zum Lauf: Fazit, Schweregrad, Erkenntnisse mit Ursache (liegt es an den Daten oder an der Regel?), Empfehlungen mit Priorität. Jede Erkenntnis verlinkt auf die betroffenen Datensätze. Berichte haben Versionen, Kommentare und eine Druckansicht. Der Bericht nennt nur, was im Ergebnis steht, und gibt keine personenbezogenen Werte wieder.
Betrieb. Anmeldung mit dem Firmenkonto, drei Rollen, serverseitig gefiltertes Menü. Nichts wird physisch gelöscht. Jede AI-Anfrage wird mit Modell, Tokens, Kosten und Dauer protokolliert, auswertbar nach Bereich und Tag.
Wie es gebaut ist
Die Prüfengine arbeitet bewusst ohne AI: Eine Regel entscheidet jedes Mal gleich, auf parallelen Arbeitsprozessen, in Blöcken zu 5.000 Zeilen. Die AI-Module sitzen daneben: Regeln finden, Assistent, Bericht. Alle drei liefern Vorschläge, keine Fakten in der Datenbank.
| Baustein | Technik | Entscheidung |
|---|---|---|
| Oberfläche | React, TypeScript | Ein Arbeitsbereich je Thema, der Assistent dockt überall an |
| Backend | SAP CAP, PostgreSQL | Dünne Services, Geschäftslogik in Domänen, Fremdsysteme nur über die Integrationsschicht |
| Prüfengine | Node.js Worker | Deterministisch, blockweise, zwei Läufe parallel, Absturzsicherung per Herzschlag |
| AI | Claude über Anthropic oder AWS Bedrock | Umschaltbar per Konfiguration; Bedrock hält die Daten in EU-Regionen; Kosten je Anfrage protokolliert |
| Connectoren | OData, HANA, Salesforce, Databricks, Fabric, S3, Azure, REST | Ein Adapter je System, ausschließlich lesend |
| Plattform | SAP BTP | Anmeldung, Destinations, Credential Store und Datenbank von der Plattform |
Erkenntnisse
- Prüfen und Verstehen sind zwei Aufgaben. Die Engine prüft, jedes Mal gleich. Die AI erklärt, warum etwas verstößt und was zu tun ist. Beides in einem Modul hätte beides schlechter gemacht.
- Vorschlag mit Bestätigung statt Automatik. Weil kein AI-Modul selbst speichert, darf es überall mitreden. Das Vertrauen kommt aus der Karte, nicht aus dem Modell.
- AI-Kosten gehören ins Produkt. Wer jede Anfrage mit Tokens und Preis sieht, entscheidet anders über Prompt-Länge und Caching als jemand, der die Rechnung am Monatsende bekommt.
- Regelfindung muss messbar sein. Ohne Soll-Ergebnisse ist „die AI findet die richtigen Regeln” eine Behauptung. Mit Testmodell ist es eine Zahl.