Der Hub gibt FlowServ eine einzige operative Plattform, auf der das gesamte Geschäft läuft — nicht eine weitere App neben sechs anderen, sondern die Schicht, die alle bestehenden Systeme einbindet und zu einer Oberfläche zusammenführt. Vom ersten Lead im CRM bis zur Rechnung in Sage fließt jede operative Information durch die Plattform. Die Bestandssysteme bleiben als Systems of Record erhalten — Sage bleibt Sage, die Field-App bleibt die Field-App — aber sie werden nicht mehr einzeln bedient. Koordinator:innen, Supervisor:innen und die Geschäftsleitung arbeiten ausschließlich in einer Oberfläche.
Dieser Hub ist eine Anwendung unseres Company-OS-Ansatzes — IJONIS' Methodik, um fragmentierte Betriebstools in eine einheitliche operative Plattform zu überführen und darauf KI-Fähigkeiten zu schichten. Der Ansatz ist hier konkret auf einen HVAC-Dienstleister angewendet; dieselbe Struktur trägt für andere wachsende Servicebetriebe (Logistik, Fertigung, technische Dienstleistungen).
Auf diese einheitliche Basis werden KI-Fähigkeiten in klar getrennten Ebenen aufgesetzt, vom passiven Verstehen von Dokumenten bis zum eigenständigen Handeln über Systemgrenzen hinweg. Jede Ebene wird separat aktiviert, separat kontrolliert und separat auditiert.
Die vier Schichten
Der Hub ist in vier bewusst getrennte Schichten strukturiert. Jede Schicht hat einen klar definierten Zweck, ein eigenes Verantwortungsprofil und wird unabhängig skaliert.
1. Integration Fabric — der Verbinder. Eine read-only Connector-Schicht sitzt über den bestehenden Systemen und normalisiert deren Daten in ein einheitliches Modell. CRM, Field-App und Sage werden über APIs angebunden, Flotten-GPS im 60-Sekunden-Takt gepollt, der Shared Drive mit 15.000+ Legacy-PDFs über Document-AI strukturiert, WhatsApp- und E-Mail-Coordination über Webhook-Brücken eingefangen. Alles fließt in eine einzige Data Pipeline in einer PostgreSQL-Datenschicht — der Single Source of Truth, auf der alles weitere aufsetzt. Die Connector-Schicht erkennt Datenqualitätsprobleme (doppelte Kunden, widersprüchliche Adressen, verwaiste Aufträge) und meldet sie, bevor sie in Reports oder KI-Ausgaben landen.
2. Operational Surface — die Oberfläche. Auf dieser Basis läuft die eigentliche zentrale Oberfläche, mit der alle operativen Rollen tatsächlich arbeiten. Sie ersetzt nicht die Produkte darunter, sondern das Switchen zwischen sechs Produkten.
3. Intelligence Layer — die KI-Schichten. Auf der Oberfläche werden KI-Fähigkeiten in fünf Reifegraden aktiviert, jeweils mit einer eigenen Engine und einem eigenen Nutzungsmuster. FlowServ kann bei Schicht eins einsteigen und sich nach oben bewegen — oder mehrere Schichten gleichzeitig aktivieren. Jede Schicht ist isoliert abschaltbar.
4. Control Plane — die Steuerungsebene. Jede KI-Aktion läuft durch eine zentrale Steuerungsschicht, die dem Unternehmen einen Regler zwischen „vorschlagen", „vorschlagen mit Freigabe" und „autonom ausführen" gibt — pro Workflow, pro Rolle. Reine Information (Report generiert, Benachrichtigung versendet) kann autonom laufen. Dispositionsentscheidungen, Kundenkommunikation und Rechnungsausgaben stehen standardmäßig auf Human-in-the-Loop. Alle Aktionen — KI-generiert oder menschlich bestätigt — werden mit Zeitstempel, Rollenzuordnung und Eingabedaten protokolliert. Das Business kontrolliert den Regler; die Plattform führt aus, was freigegeben ist.
Vertrauensarchitektur
Der Hub zieht eine klare Grenze zwischen dem, was deterministisch berechnet wird, und dem, was KI-interpretiert wird — und macht diese Grenze überall sichtbar.
Alle operativen Zahlen — Auftragsvolumen, Umsatz pro Kunde, SLA-Erfüllung, Fahrzeugauslastung, Bestandsreichweiten — werden deterministisch aus der einheitlichen Datenschicht berechnet. Diese Zahlen sind nie KI-generiert. Die KI-Schicht sitzt darüber: eine Retrieval-Augmented-Generation-Pipeline, die in den realen Daten und in kuratierten Policy-Dokumenten (Service-Levels, Dispositionsregeln, Eskalationspfade) verankert ist.
Jede KI-Ausgabe ist an konkrete Datenpunkte zurückgebunden. Das Modell kann keine Aufträge, Kunden, Teile oder Einsätze fabrizieren, die nicht in den Daten existieren. Wo Daten fehlen — eine lückenhafte Historie, eine verwaiste Adresse — markiert das System die Lücke explizit, anstatt zu interpolieren. Konfidenzniveaus begleiten jede Empfehlung. Jede geschäftskritische Aktion durchläuft das Control-Plane-Gate; Token-Verbrauch pro Query wird erfasst und ausgewiesen.
Datenintegration
Der Hub verbindet sich mit der FlowServ-Toolchain über eine sichere Connector-Schicht: API-Anbindung an das CRM (Live-Webhooks für Quote-Events, inkrementeller Sync für Kundenstammdaten), an die Field-Management-App (Job-Completion-Events in Echtzeit) und an Sage (Rechnungspush + Abgleich). Das GPS-Flottensystem wird im 60-Sekunden-Takt gepollt und mit dem aktiven Auftragsbuch verknüpft. Der Legacy-PDF-Archiv wird initial in einem Batch-Lauf über Document-AI strukturiert (Customer-Mapping + Asset-Extraction + OCR-Qualitätsscore) und anschließend inkrementell. WhatsApp- und E-Mail-Coordination laufen über einen dedizierten Inbound-Agent, der Nachrichten dem richtigen Auftrag zuordnet.
Alle Zugangsdaten liegen verschlüsselt im Google Cloud Secret Manager, werden nie im Klartext übertragen und nutzen kurzlebige Session-Tokens, die nach jedem Lauf invalidiert werden. Der Connector erkennt Datenqualitätsprobleme automatisch und meldet sie vor der Analyse: fehlende Reporting-Linien, doppelte Kunden, verwaiste Aufträge, widersprüchliche Adressen.
Deployment & Rollout
Gehostet auf Google Cloud in africa-south1 (Johannesburg) für Data Residency; optional in der europäischen Region für EU-Kunden. Progressive Aktivierung: Integration Fabric in Woche 1–2 (read-only Anbindung, initiale Datenharmonisierung). Operational Surface live in Woche 3–5 (Auftragsboard, Kunden-360, Dashboards — Teams arbeiten ab hier bereits in einer statt sechs Oberflächen). Intelligence Layer schrittweise in Woche 6–10 (Verstehen → Schließen → Generieren; Orchestrieren und Agentisch folgen nach sichtbarem Vertrauensaufbau). Managed Service mit monatlichen Iterationszyklen für neue Workflows, neue Integrationen und Justierungen der Control Plane.
Weitergedacht — Autonomer Betriebsmodus
Der query- und event-getriebene Hub ist das Fundament. Für Unternehmen, die bereit sind, in den agentischen Modus zu wechseln, unterstützt dieselbe Architektur einen autonomen Betriebsmodus — in dem das System nicht nur reaktiv auf Ereignisse antwortet, sondern proaktiv Muster erkennt und Handlungsvorschläge initiiert.
Agenten überwachen operative Ströme kontinuierlich: Wiederkehrende Fehlermuster, SLA-Drift, Bestandsrisiken, Kundenrückgänge, ungenutzte Flottenkapazität. Ein auffälliges Muster — etwa drei ähnliche Ausfälle derselben Anlagenklasse in 60 Tagen — löst einen vollständigen Vorschlag aus: vermutete Root Cause, proaktive Wartungsvisits in optimierter Route, vorpositionierte Teile, geschätzter ROI. Die Operations-Leitung prüft und gibt frei; das System führt über alle angebundenen Systeme aus.
Die menschliche Rolle verschiebt sich vom Bedienen mehrerer Tools zum Prüfen und Freigeben maschineller Vorschläge. Das Control-Plane-Gate bleibt bestehen — jede geschäftskritische Aktion erfordert weiterhin menschliche Freigabe. Die Initiative aber geht vom System aus.
