Das Datenmodell als Foundation
Die Ausgangslage
Salesforce für Kunden.
SAP für Aufträge, Lager, Einkauf.
Power BI fürs Reporting.
Personio für HR.
Interne Tools für Workforce Management.
Das ist die Realität in den meisten Unternehmen. Mindestens fünf Systeme. Oft zehn oder mehr. Jedes mit eigener Datenbank. Jedes mit eigener Wahrheit.
Jedes System bringt seine eigene Struktur mit. Die meisten davon wurden nicht für das eigene Unternehmen gebaut. Man passt sich an, oder passt es unter großen Schmerzen an. Man nutzt die Felder, die Salesforce vorgibt. Man arbeitet mit den Strukturen, die SAP liefert. Man baut Workarounds für alles, was nicht passt.
Dazwischen: Menschen. Die Daten abgleichen, Exporte bauen, Prozesse steuern. In den Systemen und zwischen den Systemen.
Das Geschäftsmodell dahinter? Meist Pay-per-User. Die SaaS-Welt der letzten 15 Jahre. Jeder neue Mitarbeiter kostet mehrfach Lizenz.
Und einmal drin, kommt man schwer wieder raus. Sobald ein System in die Kernprozesse greift, ist der Wechsel ein Projekt für sich: Datenmigration, Umschulung, neue Schnittstellen. Der "Lock-In" ist gewollt.
Das alles ist über Jahre gewachsen. Lose gekoppelt. Manchmal im Sync. Oft nicht.
Warum das jetzt zum Problem wird
Das funktionierte, solange Rückenwind im Markt war und Menschen die Brücke sein konnten. Aber zwei Dinge haben sich geändert:
Der Wind hat gedreht. Die wirtschaftliche Lage zwingt Unternehmen, effizienter zu werden. Jeder manuelle Prozess, jede Brücke, die ein Mensch sein muss, kostet Geld. Geld, das viele nicht mehr haben.
AI kommt ins Spiel. Und AI Agents arbeiten anders als Menschen. Sie fragen nicht nach. Sie interpretieren nicht. Sie lesen Daten. Direkt.
Die eigentliche Frage
Die meisten Unternehmen fragen: „Wie integrieren wir AI in unsere bestehenden Systeme?"
Die bessere Frage ist: „Was ist die Wahrheit unseres Geschäfts, und wo lebt sie?"
Ein Datenmodell ist nicht nur eine technische Struktur. Es ist die Abbildung dessen, wie ein Unternehmen tatsächlich funktioniert. Welche Objekte gibt es? Wie hängen sie zusammen? Was passiert, wenn sich etwas ändert?
Wenn diese Grundstruktur die von Salesforce ist, gebaut als Kompromiss für hunderttausend verschiedene Unternehmen, dann ist es nicht die eigene Wahrheit. Es ist ein generisches Modell, an das man sich angepasst hat.
AI braucht Klarheit. Eine Wahrheit. Ein Modell, das die Realität des Geschäfts abbildet, nicht die Vorstellung eines Softwareanbieters davon.
Die naheliegenden Einwände
„Warum nicht einfach ein System als Single Source of Truth nutzen?" Das klingt logisch, funktioniert aber selten. Salesforce ist für CRM gebaut, nicht für Workforce Management. SAP ist für ERP optimiert, nicht für Marketing-Automation. Man kann Systeme zwingen, Dinge zu tun, für die sie nicht gemacht wurden. Aber man bezahlt den Preis in Komplexität und Workarounds.
„Warum nicht klassische Data Warehouses?" Data Warehouses lösen das Reporting-Problem, nicht das Operational-Problem. Sie sind für Analysen gebaut, nicht für Echtzeit-Entscheidungen. Ein AI Agent, der einen Termin stornieren und gleichzeitig einen anderen Kunden vorziehen soll, um die Lücke zu füllen, muss schreiben können. Nicht nur lesen.
Kurz gesagt: Data Warehouses beantworten Fragen. AI Agents treffen Entscheidungen.
„Ist das nicht einfach ein neues System?" Ja und nein. Es ist ein System, das von Anfang an für AI gebaut wurde. Der Unterschied: Es übernimmt nicht die Strukturen anderer, sondern bildet das eigene Unternehmen ab. Es ist nicht „noch ein System", sondern die Grundlage, auf der alles andere aufsetzt.
Ein konkretes Beispiel
Bei Foty, unserem Blueprint für eine Firma mit AI im Kern, sind wir anders vorgegangen. Bevor irgendeine Zeile Code geschrieben wurde, stand eine Frage: Was ist die Wahrheit dieses Geschäfts?
Dahinter steckt ein vollständiges Unternehmen:
- Kunden mit ihren Hunden (mehrere Hunde pro Kunde, mehrere Besitzer pro Hund)
- Therapeuten mit Verfügbarkeiten, Qualifikationen, Abwesenheiten
- Termine, die gebucht, verschoben, storniert werden können
- Behandlungen mit Befunddokumentation
- Ein Kartensystem (5er-Karten, 10er-Karten mit Ablaufdatum)
- Rechnungen, Zahlungen, offene Posten
- Marketing-Automation
- Routenplanung für mobile Einsätze
- DATEV-Anbindung
Alles muss zusammenspielen. Wenn ein Kunde storniert, muss der Termin frei werden. Wenn ein Therapeut krank ist, müssen alle seine Termine neu zugewiesen werden können. Wenn ein Hund eine 10er-Karte hat, muss bei jeder Behandlung eine Einheit abgezogen werden.
Ist das ein komplexes Modell? Nein. Es ist eine (Hunde-) Physiotherapie.
Aber: Heute ein Therapeut, ein Standort. In 4 Wochen: Voice AI für Terminbuchung. In ein paar Monaten: eigene Lagerhaltung im Modell.
Werden wir uns eine Warenwirtschaft anschaffen? Ein CRM? Ein externes Workforce Management? Nach heutigem Stand: eher nicht.
Der Prozess: Schneller, aber nicht trivial
Klassisch hätte die Konzeption einer solchen Grundstruktur Monate gedauert:
- Anforderungsworkshops
- Stakeholder-Abstimmungen
- Review-Runden
- Dokumentation
- Roadmaps, Sprints, Backlogs
- Kleine Teams mit Product Manager, Developer, Data Engineers
- Meetings, um Meetings vorzubereiten
- Warten auf Feedback, Kalender, Verfügbarkeiten
Mit Claude als Sparringspartner hatten wir die erste belastbare Version in zwei Wochen. Nicht weil wir schneller tippen können, sondern weil sich die Art der Zusammenarbeit verändert hat.
Ein Beispiel aus dem Dialog:
"Was passiert, wenn ein Hund mehrere Besitzer hat?"
"Wie bilde ich ab, dass ein Termin Teil eines Behandlungsplans ist?"
"Soll die Rechnung am Termin hängen oder am Kunden?"
Mit jeder Frage wurde das Modell präziser. Das Hin und Her fühlte sich an wie ein Gespräch mit einem sehr geduldigen, sehr schnellen Kollegen.
- Geschäfts-Logik beschreiben, in natürlicher Sprache, nicht in technischer
- Fragen beantworten: Was passiert wenn...? Wie hängt X mit Y zusammen?
- Iterieren: jede Antwort führte zu neuen Fragen, das Modell wurde präziser
- Validieren: das Modell gegen echte Szenarien testen
Wichtig zu verstehen: Zwei Wochen für die erste Version bedeutet nicht „fertig in zwei Wochen". Die Struktur entwickelt sich weiter, auch jetzt, im laufenden Betrieb. Aber der Unterschied ist: Man startet mit einer durchdachten Grundlage statt mit einem leeren Blatt oder einem System, das für jemand anderen gebaut wurde.
Am Ende: 27 Tabellen in 8 logischen Bereichen. Ein vollständiges Praxis-Management.
Was das für Entscheider bedeutet
Die Frage ist nicht, ob AI kommt. Die Frage ist, ob die eigene Organisation bereit dafür ist.
Unternehmen, die heute in AI investieren, starten oft bei den Tools. Verständlich, aber riskant. Ohne eine klare Datengrundlage werden die Systeme nicht miteinander sprechen. Die Agents werden raten müssen. Die Ergebnisse bleiben hinter den Erwartungen.
Die strategische Frage lautet: Was ist die Wahrheit unseres Geschäfts, und wo lebt sie?
Wie wir bei Foty vorgehen, dokumentieren wir laufend auf arial.io/ai-native-company
Über Arial.
Wir bauen das Neue.
Geschäftsmodelle mit AI im Kern. Ideen, die gerade entstehen. Ventures, die intern nicht die Priorität bekommen. Oder ein kompletter Neustart für Unternehmen, die Legacy überspringen statt transformieren wollen. Wir bauen robuste Systeme. In Wochen, nicht Jahren.
Was wir auch tun: Automation und AI Agents, die an Bestehendes andocken.
Was wir nicht tun: Legacy transformieren. SAP-Salesforce-ERP-Migrationen. Das ist nicht unser Fokus. Wir bauen, was noch nicht existiert. Mit den Daten, die zählen.
