AI/ML 
Rozwój oprogramowania 
Nach unseren eigenen Beobachtungen können Integrationsprobleme bei rund 70 % der gescheiterten KI-Projekte eine wesentliche Rolle spielen. Häufig liegen die Ursachen nicht in der KI selbst, sondern in fehlenden Systemschnittstellen, schlechter Datenqualität und unzureichendem Change Management. VM.PL entwickelt KI-Integrationslösungen über einen API-Layer: Bestehende ERP-, CRM- und Legacy-Systeme können weiter genutzt und um KI-Funktionen ergänzt werden, ohne dass ein vollständiger Systemwechsel erforderlich ist. Die Umsetzung erfolgt nach der 4D-Methodik, nearshore aus Polen und unter Berücksichtigung der DSGVO-Anforderungen.
Datenschutz, Datenresidenz und die Kontrolle über Unternehmensdaten werden bereits bei der Architekturplanung berücksichtigt. Je nach Anforderungen können Cloud-, On-Premise- oder hybride Lösungen eingesetzt werden. Dabei werden Möglichkeiten zur Datenverarbeitung innerhalb der EU sowie Zero Data Retention (ZDR) geprüft, sofern die eingesetzten Dienste diese Optionen unterstützen.
Wann scheitern KI-Implementierungen – und was sind die häufigsten Fehler?
Bei gescheiterten KI-Projekten zeigen sich häufig ähnliche Herausforderungen. Neben technischen Integrationsproblemen spielen insbesondere unklare Geschäftsziele, unzureichende Datenqualität und eine mangelnde Einbindung der Mitarbeitenden eine wichtige Rolle.
| Fehler | Beschreibung | VM.PL-Gegenmaßnahme (4D) |
| Kein klares Geschäftsziel | KI-Projekt ohne definierten ROI gestartet – kein messbares Erfolgskriterium | Discovery: Use-Case-Validierung und Concept Document vor Beginn der eigentlichen Entwicklung |
| Schlechte Datenqualität | Nach unseren eigenen Beobachtungen können 50–70 % des Projektaufwands auf die Datenbereinigung und Datenaufbereitung entfallen – nicht auf die eigentliche Modellentwicklung | Definition: Daten-Audit + Daten-Pipeline-Design als eigene Phase vor Delivery |
| Legacy-System ohne API | Altsysteme ohne Schnittstelle – eine Anbindung kann zusätzliche Integrationsmechanismen erfordern | API-Layer-Ansatz: Custom Connector oder Azure Storage als Datenpipeline – möglichst ohne Änderungen am bestehenden Produktionscode |
| Kein Change Management | Mitarbeitende nicht eingebunden – geringe Nutzerakzeptanz kann den Erfolg nach dem Go-Live gefährden | Direction-Phase: KI-Champions, Schulungsplan und frühzeitige Kommunikation vor dem Rollout |
VM.PL prüft in der Discovery-Phase die technische Machbarkeit und dokumentiert die Ergebnisse in einem Concept Document. Die anschließenden Projektphasen orientieren sich an definierten Anforderungen und abgestimmten Ergebnissen.
Wie integriert VM.PL KI per API-Layer in ERP, CRM und Legacy-Systeme – ohne Systemwechsel?
Der bestehende ERP- oder CRM-Code kann je nach Systemarchitektur unverändert bleiben. VM.PL entwickelt einen API-Layer in Node.js/NestJS oder Java/Spring Boot, der zwischen dem KI-Modul und dem bestehenden System vermittelt. Durch die Entkopplung der Komponenten lassen sich Änderungen kontrolliert einführen und bei entsprechender technischer Konfiguration zurücknehmen. Ziel ist es, die Auswirkungen auf den laufenden Betrieb zu minimieren.
| Systemtyp | Kompatible Systeme (Beispiele) | Integrationsmethode |
| ERP | SAP S/4HANA, Microsoft Dynamics 365, Oracle ERP | REST-API, Azure Integration Services, IDOC |
| CRM | Salesforce, HubSpot, Microsoft Dynamics CRM | REST-API, Webhook, systemspezifische APIs, beispielsweise Microsoft Graph bei unterstützten Diensten |
| Industriesysteme | Siemens S7, Rockwell, Beckhoff, Honeywell | OPC-UA, MQTT, Modbus-Gateway |
| Legacy-Systeme | Altsysteme, Dateiexporte, SMTP-Systeme | Azure Storage als Datenpipeline, IMAP-Connector |
| Azure-Infrastruktur | Azure DevOps / Azure Pipelines | Azure Container Apps (Deployment) |
Für Microsoft-Umgebungen setzt VM.PL Azure Integration Services ein. Für Legacy-Systeme ohne native API-Unterstützung kann Azure Storage als asynchroner Datenpuffer dienen: Das Altsystem stellt Dateien bereit, die der KI-Layer anschließend verarbeitet.
Welche Integrationsarchitektur setzt VM.PL ein – REST API, Microservices und Event-Driven Integration?
Die Wahl der Integrationsarchitektur hängt von drei Faktoren ab: Latenzanforderungen (Echtzeit oder Batch), Systemlandschaft (monolithisches ERP vs. Microservice-Umgebung) und Datenvolumen. VM.PL empfiehlt die Architektur nach dem Systemaudit auf Grundlage der technischen und geschäftlichen Anforderungen.
| Architekturmuster | Wann geeignet | VM.PL-Implementierung |
| REST API (synchron) | Echtzeitanforderung: Eine KI-Anwendung soll beispielsweise innerhalb von weniger als 2 Sekunden antworten (beispielhafte Zielvorgabe) – etwa Chatbot, Klassifikation, Preis-Engine | FastAPI oder Node.js/NestJS als KI-Service-Layer · Azure Container Apps · JSON-Antwort |
| Webhook / Event-Driven | Asynchrone Prozesse: Ereignis im System löst KI-Verarbeitung aus – z. B. neues Dokument, neuer Auftrag, Sensor-Alert | Azure Event Grid oder Azure Service Bus · Python FastAPI als Consumer · Ergebnis zurück per Callback |
| Batch-Pipeline (ETL) | Kein Echtzeit-Bedarf: tägliche oder stündliche ML-Scoring-Läufe – z. B. Nachfrageprognose, Risikoscoring, Reporting | Azure Data Factory · Azure Pipelines · Ergebnisse in Azure SQL oder pgvector/PostgreSQL 16 |
| Microservices | Bestehende Microservice-Architektur: KI-Modul als eigenständiger Service – unabhängig deploybar, skalierbar | Docker-Container · Azure Container Apps · API Gateway · Azure DevOps CI/CD |
| Message Queue | Hohe Last, Entkopplung: Systeme sollen nicht direkt voneinander abhängen – KI verarbeitet Nachrichten asynchron | Azure Service Bus oder RabbitMQ · zuverlässige Nachrichtenverarbeitung mit geeigneten Zustellungs- und Wiederholungsmechanismen |
Hybride Architekturen: In der Praxis kombiniert VM.PL häufig REST APIs für interaktive Anwendungsfälle mit Batch-Pipelines für Hintergrundprozesse. Dabei kann ein KI-Modell über unterschiedliche Schnittstellen und Verarbeitungskanäle bereitgestellt werden. Das API-Design orientiert sich an OpenAPI-Standards für Wartbarkeit und Dokumentierbarkeit.
Wie bereitet VM.PL Daten für die KI-Integration vor – ETL-Pipelines, Datenmigration und Datenqualität?
Nach unseren eigenen Beobachtungen können 50–70 % des Aufwands in einem KI-Integrationsprojekt auf die Datenaufbereitung entfallen. Historische Daten aus ERP- und CRM-Systemen liegen häufig nicht in einem für Machine Learning direkt geeigneten Format vor. Deshalb ist die systematische Vorbereitung der Daten eine wesentliche Voraussetzung für eine erfolgreiche Integration.
Vier Datenaufbereitungs-Aufgaben bei jeder KI-Integration:
- Daten-Audit (Discovery-Phase): VM.PL analysiert Datenquellen, Schemakonsistenz, Vollständigkeit und Qualität. Typische Befunde: inkonsistente Datumsformate, fehlende Felder in 20–40 % der Datensätze (beispielhafter Erfahrungswert aus der Datenanalyse), Duplikate und Inkonsistenzen in historischen Daten nach Systemwechseln. Die Ergebnisse des Audits bilden die Grundlage für die Entscheidung über die weitere Umsetzung.
- ETL-Pipeline-Entwicklung: VM.PL entwickelt robuste Pipelines, die Rohdaten aus ERP-, CRM- und IoT-Quellen extrahieren, transformieren und in ML-geeignete Formate überführen. Stack: Python 3.11+ · Azure Data Factory für Batch-ETL · Apache Kafka für Streaming · pgvector/PostgreSQL 16 als Feature Store. Schema-Validierung, Umgang mit fehlenden Werten und Typkonsistenz werden automatisiert geprüft.
- Datenmigration: Bei historischen Datenbeständen migriert VM.PL Altdaten in das neue Datenmodell – mit vollständigem Audit-Trail, Rollback-Möglichkeit und Qualitätsprüfung vor der produktiven Inbetriebnahme. Eine sorgfältige Migrationsplanung soll Datenverluste und Unterbrechungen des laufenden Betriebs vermeiden.
- DSGVO-konforme Datenaufbereitung: Personenbezogene Merkmale werden je nach Verarbeitungszweck und rechtlichen Anforderungen pseudonymisiert, bevor sie in ML-Pipelines verarbeitet werden. Synthetische Testdaten können Produktionsdaten in Entwicklungs- und Testumgebungen ersetzen. Der Abschluss eines Auftragsverarbeitungsvertrags (AVV) erfolgt, sofern dies für die jeweilige Datenverarbeitung erforderlich ist.
Wie startet VM.PL die KI-Einführung – Proof of Concept, Pilotprojekt und schrittweiser Rollout?
Bevor eine KI-Lösung unternehmensweit eingeführt wird, sollte ihr Mehrwert anhand realer Daten überprüft werden. VM.PL strukturiert die Einführung in drei Reifestufen. Die Ergebnisse jeder Stufe dienen als Entscheidungsgrundlage für den nächsten Schritt.
| Reifestufe | Ziel und Inhalt | Deliverable | Typische Dauer |
| Proof of Concept (PoC) | Technische Machbarkeit prüfen: Läuft das ML-Modell auf echten Unternehmensdaten? Gibt es ausreichend Trainingsdaten? Ist die API-Anbindung möglich? Noch kein produktiver Einsatz, sondern eine kontrollierte Testumgebung | PoC-Report mit Genauigkeits-Kennzahlen und Go/No-Go | 2-4 Wochen |
| Pilotprojekt | Realbetrieb in begrenztem Umfang: KI läuft in einer Abteilung, für einen Standort oder für eine Produktgruppe. Nutzerfeedback, Fehlerkorrektur und erste ROI-Messung. | Produktives Teilsystem + Nutzerfeedback + ROI-Messung | 4-8 Wochen |
| Unternehmensweiter Rollout | Skalierung auf alle relevanten Systeme und Nutzer: zusätzliche Datenquellen, mehrere Standorte, erweiterter Nutzerkreis. MLOps-Betrieb, Monitoring und Re-Training als Dauerbetrieb. | Produktives System im Vollbetrieb | Abhängig von Komplexität |
Stufenlogik: VM.PL empfiehlt, nach positivem PoC zuerst ein Pilotprojekt mit einer repräsentativen Nutzergruppe durchzuführen. Erst wenn der Pilot den geschäftlichen Mehrwert auf realen Daten bestätigt, wird der Rollout freigegeben. Dieser Ansatz reduziert Projektrisiken und schafft interne Fürsprecher für den unternehmensweiten Einsatz.
Wie läuft ein KI-Integrationsprojekt bei VM.PL ab – die 4D-Methodik in der Praxis?
VM.PL arbeitet nach der 4D-Methodik. Die vier Phasen strukturieren die Projektarbeit und umfassen jeweils definierte Aktivitäten und konkrete Ergebnisse.
| Phase | Aktivitäten | Artefakt | Dauer |
| Discovery | Systemanalyse · Daten-Audit · Use-Case-Validierung · DSGVO-Bewertung | Concept Document (Go/No-Go) | 1-3 Wochen |
| Definition | API-Architektur · Integrations-Design · Daten-Pipeline · Aufwandsschätzung | Architecture Blueprint | 1-2 Wochen |
| Delivery | Entwicklung · Tests via Azure Pipelines · Deployment via Azure Container Apps · Abnahme | Produktives KI-System | 4-16 Wochen |
| Direction | MLOps-Monitoring · Überwachung von Modellabweichungen · Modellupdates · Compliance-Pflege | Entwicklungs-Roadmap | laufend |
Die Discovery-Phase liefert eine Grundlage für die Bewertung der technischen Machbarkeit. Die anschließende Definition-Phase konkretisiert die Architektur und die Integrationsanforderungen. Dadurch werden Entscheidungen, Projektfortschritt und Meilensteine nachvollziehbar dokumentiert.
Wie managt VM.PL Change Management und DSGVO-Compliance bei KI-Projekten?
Zu den häufigen Herausforderungen bei KI-Projekten gehören eine unzureichende Nutzerakzeptanz sowie offene Fragen zu Datenschutz und Compliance. VM.PL berücksichtigt beide Aspekte im Projektvorgehen.
Change Management (Direction-Phase):
- KI-Champions: VM.PL hilft, interne Fürsprecher zu identifizieren, die das System im Team verankern.
- Klare Kommunikation vor dem Rollout: KI übernimmt Routineaufgaben – sie unterstützt Mitarbeitende bei ihrer Arbeit und entlastet sie von wiederkehrenden Tätigkeiten, ohne notwendige fachliche Entscheidungen zu ersetzen. Eine frühzeitige und transparente Kommunikation kann Vorbehalte reduzieren und die Akzeptanz fördern.
- Schulungsplan: Anwender werden anhand realer Workflows geschult – nicht anhand generischer Demo-Daten.
DSGVO-Compliance:
- Pseudonymisierung als Standard: Personenbezogene Daten werden entsprechend den jeweiligen Datenschutzanforderungen geschützt. Wo sinnvoll und erforderlich, kommen Pseudonymisierung und datensparsame Verarbeitungsverfahren zum Einsatz.
- Konfigurierbare Löschfristen, Auftragsverarbeitungsvertrag (AVV), kein Datentransfer an Drittdienste ohne Rechtsgrundlage.
- EU AI Act: In der Definition-Phase prüft VM.PL die regulatorische Einstufung der jeweiligen Anwendung, insbesondere ob sie als Hochrisiko-KI-System gilt und welche Transparenz-, Dokumentations- oder Aufsichtspflichten daraus entstehen können.
- On-Premise-Option: Azure Private Deployment oder eigene Infrastruktur – je nach Architektur können Unternehmensdaten innerhalb der eigenen Infrastruktur oder in einer kontrollierten Cloud-Umgebung verarbeitet werden.
Der Unternehmenssitz von VM.PL in Polen ermöglicht die Zusammenarbeit innerhalb des europäischen Rechtsraums. Die DSGVO-Konformität wird dabei durch die konkrete technische und organisatorische Gestaltung der Datenverarbeitung sichergestellt, nicht allein durch den Unternehmensstandort.
Wie skaliert VM.PL KI nach dem Go-Live – MLOps, Monitoring und unternehmensweiter Rollout?
Der Go-Live ist kein Projektabschluss – er markiert den Beginn des produktiven Betriebs und der kontinuierlichen Weiterentwicklung eines KI-Systems. Die Genauigkeit von ML-Modellen kann sich verändern, wenn sich die Datenbasis ändert: Neue Produktgruppen, geänderte Marktbedingungen oder verändertes Nutzerverhalten verschieben die Verteilung der Eingabedaten. VM.PL implementiert MLOps als strukturierten Dauerbetrieb.
Vier MLOps-Komponenten im laufenden Betrieb:
- Performance-Monitoring: Azure Application Insights überwacht technische Betriebskennzahlen wie Inferenzlatenz und API-Verfügbarkeit. Ergänzende Monitoring-Verfahren ermöglichen die Bewertung der Modellgenauigkeit und die Erkennung von Qualitätsveränderungen. Schwellenwertwarnungen bei Qualitätsabweichungen sind nach Metrik und Toleranzbereich konfigurierbar.
- Datendrift-Erkennung: Geeignete Verfahren vergleichen regelmäßig die statistische Verteilung der Eingabedaten mit der ursprünglichen Trainingsbasis. Bei signifikanten Abweichungen kann über Azure Pipelines ein erneuter Trainingsprozess ausgelöst werden.
- Modellversionierung und Rollback: Jedes Modellupdate erzeugt eine neue Version mit eigenem Performance-Report. Das Deployment erfolgt kontrolliert per CI/CD – bei schlechteren Ergebnissen kann bei entsprechender technischer Konfiguration auf die vorherige Modellversion zurückgewechselt werden.
- Multi-System-Rollout: Nach erfolgreichem Pilot skaliert VM.PL das KI-System auf weitere Standorte, Abteilungen oder Systeme. Jede neue Integration nutzt nach Möglichkeit die bestehende API-Layer-Architektur. Dadurch lassen sich bereits entwickelte Komponenten wiederverwenden und zusätzliche Systeme mit geringerem Entwicklungsaufwand anbinden.
Direction-Phase als Dauerbetrieb: VM.PL bietet die Direction-Phase als laufendes Betriebsmodell an – beispielsweise mit monatlichen Monitoring-Berichten, quartalsweisen Modellreviews und jährlichen Architekturbewertungen. Umfang und Häufigkeit werden projektspezifisch vereinbart.
Wie berechnet sich der ROI einer KI-Integration – TCO, Break-Even und Kostenstruktur?
KI-Integration ist eine Investitionsentscheidung. VM.PL erstellt in der Discovery-Phase eine ROI-Modellierung auf Basis realer Unternehmenskennzahlen – mit projektspezifischen Annahmen statt ausschließlich allgemeinen Branchenbenchmarks.
| Kostenblock | Beschreibung | Typische Größenordnung |
| Discovery + Definition | Systemanalyse, Daten-Audit, Architekturplanung – liefert Concept Document und Architecture Blueprint als Entscheidungsgrundlage | In der Regel ein vergleichsweise kleiner Kostenblock, der die Go/No-Go-Entscheidung vor der Hauptinvestition unterstützt |
| Delivery (Entwicklung) | API-Layer, ML-Modell, Integrations-Tests, Deployment – abhängig von Komplexität und Anzahl anzubindender Systeme | Hauptkostenblock; skaliert mit Systemkomplexität und Datenvolumen |
| Direction (Betrieb) | Monitoring, Re-Training, Updates, Compliance-Pflege – als laufendes Modell oder projektorientiert | Laufende Kosten, die in vielen Projekten unter dem ursprünglichen Entwicklungsaufwand liegen können (abhängig vom Betriebsmodell) |
| Infrastruktur (TCO) | Azure Container Apps, Azure SQL, Application Insights – nutzungsbasiert skalierend; On-Premise-Betrieb als Alternative mit eigener Kostenstruktur | Skaliert mit Anfragevolumen und Datenmengen |
ROI-Hebel: KI-Integrationen erzielen ROI über drei Kanäle – Prozessautomatisierung (Personalzeit), Qualitätsverbesserung (Fehlerkosten, Rückrufe) und Entscheidungsqualität (bessere Prognosen, weniger manuelle Analysen). VM.PL quantifiziert alle drei Kanäle im Concept Document auf Basis der Unternehmens-Ist-Daten.
Break-even: Nach unseren eigenen Erfahrungswerten können sich KI-Integrationsprojekte innerhalb von 12–36 Monaten amortisieren. Der tatsächliche Zeitraum hängt von Prozessvolumen, Fehlerquoten, Personalkosten und Investitionsaufwand ab. Die Discovery-Phase von VM.PL liefert eine auf den konkreten Anwendungsfall abgestimmte Amortisationsprognose.
In welchen Branchen setzt VM.PL KI-Integration ein – Industrie, Automotive, Fintech und Mittelstand?
KI-Integration ist nicht auf eine einzelne Branche beschränkt. API-Layer-Architekturen und die 4D-Methodik sind übertragbar, aber Datenlage, Compliance-Anforderungen und Use Cases unterscheiden sich erheblich. VM.PL entwickelt branchenspezifisch.
| Branche | Typische KI-Integrations-Use-Cases | Besondere Anforderungen |
| Industrie / Produktion | Predictive Maintenance in MES · Qualitätskontrolle via Computer Vision · Energieverbrauchsoptimierung · Supply-Chain-Prognose | OPC-UA-Integration · Edge-Deployment · Berücksichtigung relevanter Anforderungen an industrielle Cybersicherheit, beispielsweise IEC 62443 · kurze Latenz an der Linie |
| Automotive | Qualitäts-KI in SAP-Integration · Zulieferer-Risikoscoring · Prognosemodelle für Fertigungsplanung · IATF-16949-konforme Dokumentation, soweit für den Anwendungsfall relevant | IATF-16949-Audit-Trail · Berücksichtigung der ISO-26262-Anforderungen bei sicherheitsrelevanten Funktionen · Human-in-the-Loop für sicherheitskritische Anwendungen |
| Fintech / Versicherung | Betrugs-Erkennung in Core-Banking · Kreditrisiko-Scoring · Schadens-Automatisierung · AML-Monitoring | Relevante Finanzaufsichts- und Datenschutzanforderungen · EU-AI-Act-Einstufung · Erklärbarkeit (SHAP) · DSGVO Art. 22 bei einschlägigen automatisierten Entscheidungen |
| Software / IT-Dienstleister | KI-gestützte Testautomatisierung · Predictive QA · Code-Modernisierungsassistent · DevOps-Optimierung | Azure DevOps-Integration · CI/CD-nativ · schnelle Iterationszyklen |
| Mittelstand (allgemein) | KI-Chatbot für Kundenservice · Dokumentenanalyse · Aufwandsschätzung · HR-Analytics · Demand Forecasting | Pragmatischer Ansatz · kein überdimensioniertes System · frühzeitige Überprüfung des wirtschaftlichen Nutzens durch ein Pilotprojekt |
Wie minimiert VM.PL Risiken bei KI-Integrationsprojekten?
Vier strukturelle Maßnahmen helfen dabei, Projektrisiken zu reduzieren:
- Discovery-First-Prinzip: Die Discovery-Phase klärt die Datenlage, die Systemkompatibilität und das ROI-Potenzial, bevor die eigentliche Entwicklung beginnt. Die Ergebnisse werden in einem Concept Document dokumentiert und bilden die Grundlage für die weitere Projektentscheidung.
- Kontrollierter Rollback: Der API-Layer wird so konzipiert, dass sich Änderungen bei entsprechender Architektur zurücknehmen lassen. Ziel ist es, bestehende Systeme während der Integration funktionsfähig zu halten und Risiken für den Produktionsbetrieb zu minimieren.
- Human-in-the-Loop: Bei sicherheitskritischen Anwendungen werden menschliche Freigaben und geeignete Kontrollmechanismen entsprechend den technischen und regulatorischen Anforderungen vorgesehen. Dies kann beispielsweise im Automotive-Bereich im Kontext von ISO 26262 oder bei industriellen Systemen im Zusammenhang mit IEC 62443 relevant sein.
- Schrittweise Skalierung: VM.PL startet mit einem PoC zur Validierung der technischen Machbarkeit. Nach einem erfolgreichen Pilotprojekt und der Überprüfung des wirtschaftlichen Mehrwerts kann die Lösung unternehmensweit skaliert werden.
Nearshore-Vorteil: VM.PL hat seinen Sitz in Wrocław, Polen, und ist aus dem DACH-Raum gut erreichbar. Neben der standortunabhängigen Zusammenarbeit sind persönliche Vor-Ort-Termine für Integrationsreviews und Abnahmen nach Vereinbarung möglich.
Warum VM.PL als Partner für KI-Integration in bestehende Systeme?
VM.PL kombiniert Erfahrung in der Integration komplexer IT-Landschaften mit Nearshore-Zusammenarbeit und einem strukturierten Projektvorgehen. Im Mittelpunkt stehen individuell entwickelte Lösungen, die bestehende Systeme erweitern und langfristig wartbar bleiben.
- 4D-Methodik: Strukturierter Ablauf mit konkreten Ergebnissen in jeder Phase – von der Analyse der Systemlandschaft über die Architekturplanung und Implementierung bis zur kontinuierlichen Überwachung und Weiterentwicklung der Lösung.
- Kein Vendor-Lock-in: VM.PL setzt auf transparente Architekturentscheidungen und individuell entwickelte Integrationslösungen. Nutzungsrechte am Quellcode, mögliche Lizenzkosten und die Übertragbarkeit auf andere Infrastrukturen werden projektspezifisch vereinbart.
- Nearshore aus Wrocław: Polen, EU – gut erreichbar aus dem DACH-Raum, Deutsch als Arbeitssprache und über neun Jahre Erfahrung in der Zusammenarbeit mit Unternehmen aus der DACH-Region. Der Unternehmensstandort innerhalb der EU erleichtert die Zusammenarbeit im europäischen Rechtsrahmen.
- DACH-Referenzen: queo (Dresden), mindsquare (Düsseldorf), g.a.s.t. e.V., SYSTEMA, Aptean – Kunden aus unterschiedlichen Unternehmensgrößen und Branchen, darunter Industrie, IT und Beratung.
- Flexible Infrastruktur: On-Premise-, private Azure- oder hybride Deployment-Architekturen – abgestimmt auf die bestehende IT-Landschaft sowie die Anforderungen an Datenschutz, Datensicherheit und Datenresidenz.
Die Wirksamkeit dieses Ansatzes zeigt sich in unseren realisierten Projekten. Für ein global tätiges Produktionsunternehmen haben wir eine KI- und LLM-Lösung über eine dedizierte API in das bestehende SAP-System integriert – ohne Änderungen am ERP-System. Heute verarbeitet die Lösung mehr als 90 % der Bestellungen automatisch, verkürzt die Bearbeitungszeit von mehreren Stunden auf wenige Minuten und ermöglicht dem Kunden jährliche Einsparungen von 960.000 Euro. Lesen Sie die Case Study zur KI-Integration mit SAP.