Die meisten österreichischen KMUs stehen irgendwann vor der gleichen Weggabelung: Das Unternehmen wächst, manuelle Prozesse häufen sich, und die Führungsebene weiß, dass KI die Antwort sein sollte — doch jedes Pilotprojekt scheitert entweder im Proof-of-Concept oder versagt still in der Produktion. Das ist kein KI-Problem. Es ist ein Architekturproblem.
Illustratives Szenario: Dies ist keine Kundenfallstudie und kein Bericht über einen ausgeführten Auftrag. Das Modell verbindet wiederkehrende Betriebsbedingungen eines Wiener Dienstleistungsunternehmens, damit Entscheider die Methode prüfen können. Umsatz, Teamgröße und Workflow-Mengen sind Szenarioannahmen, keine berichteten Kundendaten. Als Systemumgebung dienen BMD, ein Legacy-CRM und E-Mail-lastige Zusammenarbeit.
Phase 1: Das Chaos-Audit — Aufnahme des Istzustands
Bevor ein einziges KI-Tool empfohlen wird, erfasst das Szenario jeden datenführenden Workflow. Das entstehende Muster ist bewusst typisch für organisch gewachsene österreichische Mittelstandsunternehmen:
🔴 DAS CHAOS — Vor der Architektur
- 📧 Rechnungsverarbeitung: PDFs per E-Mail empfangen → manuell in BMD eingetippt → 3-4 Stunden täglich
- 📊 Kundenberichte: Daten aus CRM nach Excel exportiert → manuell formatiert → als Anhang per E-Mail verschickt
- 🔄 Projektstatus: In drei getrennten Systemen erfasst (E-Mail, Tabellenkalkulation, BMD) — keine einheitliche Datenquelle
- ⚠️ Compliance-Tracking: EU-KI-Gesetz-Bereitschaft — null Dokumentation, kein Prüfpfad
- 💶 Kosten: Geschätzte 62 Stunden pro Woche Mitarbeiterzeit für rein manuelle Datenbewegungen
Das Audit identifizierte vier kritische Engpässe. Jeder einzelne war ein Kandidat für KI-gestützte Automatisierung — aber erst nachdem die zugrunde liegende Datenarchitektur bereinigt wurde. Einen defekten Prozess zu automatisieren ergibt nur einen schnelleren defekten Prozess.
Phase 2: Der Architekturentwurf — Die Grundlage schaffen
Die Entwurfsphase lieferte eine Middleware-Architektur, die die bestehende BMD-Installation und das Legacy-CRM verband — ohne eines der Systeme zu ersetzen. Das ist eine bewusste Entscheidung: Vollständige ERP-Migrationen dauern 18-24 Monate und haben hohe Misserfolgsquoten. Der Middleware-Ansatz liefert 80 % des Nutzens zu 20 % der Kosten und des Risikos.
🟢 DIE ARCHITEKTUR — Nach dem Systemdesign
- ⚡ Rechnungsverarbeitung: Automatisierte OCR + LLM-Extraktion → strukturiertes JSON → API-Push zu BMD → keine manuelle Eingabe
- 📈 Kundenberichte: Live-Dashboard aus einheitlicher Datenschicht → automatisch generierte PDF-Berichte nach Zeitplan
- 🔗 Projektstatus: Einheitliche Datenquelle über zentrale API-Schicht — alle drei Tools schreiben und lesen aus einem Schema
- ✅ Compliance-Tracking: Automatisierter EU-KI-Gesetz-Prüfpfad — jede KI-Entscheidung mit Zeitstempel und Modellversion protokolliert
- 💰 Ergebnis: Dieses illustrative Audit-Beispiel zeigt, wie die Annahmen zu wöchentlich manuell aufgewendeter Zeit geprüft würden — wie viel im Einzelfall tatsächlich wegfällt, hängt von den geprüften Zeitannahmen im jeweiligen Betrieb ab. Mitarbeiter werden für kundenorientierte Arbeit umgeleitet.
Phase 3: Illustrativer 90-Tage-Prüfpfad
Das Szenario kann in drei Entscheidungsphasen geprüft werden. Jede Phase bleibt von Evidenz und Abnahme abhängig; dies ist kein Lieferbericht:
- Tage 1-30: Rechnungspfad kartieren und BMD-Integration mit synthetischen oder freigegebenen repräsentativen Daten testen, bevor produktiver Schreibzugriff erlaubt wird.
- Sprint 2 (Tage 31-60): CRM-Daten würden über eine zentrale API-Schicht vereinheitlicht, ein Berichts-Dashboard getestet und manuelle Excel-Exporte erst nach Abnahme abgelöst.
- Tage 61-90: Evidenzprotokollierung und Status-Synchronisation prüfen; eine operative Übergabe wäre eine gesonderte, abgenommene Entscheidung.
Die zu messende Evidenz
Was das für Ihr Unternehmen bedeutet
Die oben beschriebene Architektur ist nicht auf dieses Szenario beschränkt. Dieselben Engpässe — E-Mail-gesteuerte Dateneingabe, getrennte Legacy-Systeme und manuelle Berichterstellung — treten in österreichischen Professional-Services-, Fertigungs- und Logistikunternehmen wiederholt auf. Ein gescheiterter Pilot kann erhebliches Budget und Managementaufmerksamkeit binden, wenn die Architekturphase übersprungen wird.
Österreichische Unternehmen wie Runtastic haben bewiesen, dass operative Infrastruktur — nicht nur Produktinnovation — das ermöglicht, was Skalierung ausmacht. Runtastic baute Datensysteme, die Millionen von Nutzern verarbeiten konnten, bevor die Adidas-Übernahme stattfand — nicht danach. Dasselbe Prinzip gilt für die KI-Integration: erst Architektur, dann KI.
Ein klar begrenztes Architekturmandat wendet diese Methode auf einen priorisierten Workflow und eine Produktionsentscheidung an. Es ordnet Istzustand, Systemabhängigkeiten, Kontrollen und fehlende Evidenz, setzt aber keine Integrationen um und zertifiziert keine rechtlichen, sicherheitsbezogenen, datenschutzrechtlichen, regulatorischen, technischen oder produktiven Ergebnisse. Eine KI-Produktionsentscheidung besprechen.
Weiterlesen
