API und Individualintegrationen

Verbinden Sie INVO mit jedem BausteinIhrer Systemlandschaft.

Fertige Integrationen sind nur eine Möglichkeit, INVO an Ihre Architektur anzubinden. Über die Integrationsschicht können wir Daten mit Standardsystemen, Eigenentwicklungen und Legacy-Anwendungen austauschen - mit dem Integrationsmodell, das Ihre Umgebung technisch unterstützt.

INVO

Operative Plattform

  • ERPFinanzen · Stammdaten
  • MESProduktionsausführung
  • WMSLager
  • PLMKonstruktion
  • EigenentwicklungenFür Sie gebaut
  • BI / DatenplattformReporting
  • API
  • Webhooks
  • EDI
  • SFTP
  • Dateien
  • Middleware
  • Konnektoren

Auf Interoperabilität ausgelegt

Wir begrenzen Integration nicht auf einige fertige Konnektoren.

In großen Organisationen ist die IT-Landschaft meist aus vielen über Jahre gewachsenen Systemen aufgebaut. Manche sind Standard, manche branchenspezifisch, manche intern entwickelt. INVO kann als weitere spezialisierte Schicht dazukommen.

  • ERPSAP, Oracle, Microsoft Dynamics, lokale und eigene ERP-Systeme.
  • MESBestehende Manufacturing-Execution-Systeme.
  • WMSLager und interne Logistik.
  • EinkaufEinkaufssysteme und Supplier-Management-Plattformen.
  • PLMKonstruktionsstücklisten und Revisionen.
  • Verträge und BestellungenVertrags- und Bestellsysteme.
  • BI und DatenplattformenPower BI, Data Warehouse, Data Lake und weitere Analyseplattformen.
  • HR und PersonalDienstpläne, Arbeitszeit, Anwesenheit und Mitarbeiterdaten.
  • EigenentwicklungenInterne Anwendungen, speziell für die Organisation gebaut.
  • Legacy-SystemeÄltere Lösungen ohne moderne API.

Die Integrationsschicht

Eine Integrationsschicht zwischen INVO und Ihrer Landschaft.

Integration sollte keine willkürlichen Verbindungen zwischen allen Systemen bedeuten. Wir entwerfen den Datenfluss entlang der Verantwortung der einzelnen Anwendungen und Prozesse.

Anwendungen

  • ERP
  • WMS
  • MES
  • PLM

Integrationsschicht

  • API Gateway
  • Authentifizierung
  • Datenmapping
  • Transformation
  • Validierung
  • Ereignisse
  • Monitoring

INVO

Operative Prozesse

  • Planung
  • Einkauf
  • Lager
  • Produktion

Eine Schicht und ein Ort, an dem sichtbar ist, was passiert ist - statt eines Geflechts von Punkt-zu-Punkt-Verbindungen, das niemand prüfen kann.

Integrationsmethoden

Wir wählen die Integrationsart nach den Möglichkeiten Ihres Systems.

Moderne APIs sind der bevorzugte Weg, doch eine reale Enterprise-Architektur muss oft Systeme mit sehr unterschiedlichen Fähigkeiten einbinden.

Moderne System-zu-System-Kommunikation

REST API

Datenaustausch zwischen Anwendungen über API-Endpoints.

  • Stammdaten
  • Bestellungen
  • Status
  • Bestände
  • Produktionsdaten

Auf Ereignisse reagieren, sobald sie auftreten

Webhooks

Ein System kann auf Ereignisse reagieren, statt zyklisch nach neuen Informationen zu fragen.

  • Auftragsbestätigung
  • Produktion abgeschlossen
  • Lieferung angenommen
  • Bestand aktualisiert

Strukturierter Austausch von Geschäftsdokumenten

EDI

Elektronischer Austausch von Geschäftsdokumenten.

  • Bestellungen
  • Bestätigungen
  • Rechnungen
  • Lieferdokumente

Sicherer, automatisierter Dateiaustausch

SFTP

Sicherer Dateitransfer zwischen Systemen.

CSV · XML · XLSX · JSON

Strukturierte Dateien

Für Systeme ohne direkte API können wir ein vereinbartes Datenformat nutzen.

Arbeit mit Ihrer bestehenden Integrationsplattform

Middleware

Betreibt Ihre Organisation eigene Middleware oder einen Integration Bus, kann INVO an dieses Modell angebunden werden.

Wenn Standardmethoden nicht ausreichen

Dedizierter Konnektor

Für spezifische Systeme entwerfen wir einen maßgeschneiderten Kommunikationsweg.

API-first, wo möglich. Flexibel, wo nötig.

Wir setzen nicht voraus, dass jedes Ihrer Systeme eine moderne REST-API hat. Der Anbindungsweg richtet sich danach, was das jeweilige System unterstützt.

  • Modernes SystemREST API
  • Enterprise-PlattformMiddleware / Events
  • Älteres SystemSFTP / Dateien
  • Legacy-SystemDedizierter Konnektor

Ihre Systeme müssen nicht modern sein, um mit INVO zusammenzuarbeiten.

Datendomänen

Wir integrieren die Daten für reale Prozesse.

Welche Daten und Vorgänge verfügbar sind, hängt vom vereinbarten Projektumfang und den bereitgestellten Schnittstellen ab.

Stammdaten

  • Komponenten
  • Produkte
  • Stücklisten
  • Lieferanten
  • Kunden
  • Standorte
  • Mengeneinheiten

Bedarf und Bestellungen

  • Kundenaufträge
  • Bedarf
  • Auftragsänderungen
  • Kundenanforderungen

Einkauf

  • Einkaufsbedarfe
  • Bestellungen
  • Lieferantenbestätigungen
  • Preise
  • Lieferungen

Lager

  • Bestände
  • Wareneingang
  • Lagerbewegungen
  • Verbrauch
  • Korrekturen

Produktion

  • Produktionsaufträge
  • Pläne
  • Produktionsstatus
  • Komponentenverbrauch
  • Produzierte Mengen

Qualität

  • Prüfungen
  • Ergebnisse
  • Abweichungen
  • Status

Logistik

  • Sendungen
  • Lieferungen
  • Spediteure
  • Lieferbestätigungen

Finanzen und Analytik

  • Betriebskosten
  • Ist-Daten
  • Kostenreferenzen
  • Analysedaten

Den Umfang legen wir je Einführung fest - wir integrieren, was der Prozess braucht, nicht alles, was ein Endpoint hergibt.

Nicht alle Daten sollten gleich fließen.

Echtzeit

Daten werden im Moment der Aktion übertragen.

  • Bestellung angelegt
  • Sofortige Antwort
  • Statuswechsel

Ereignisgesteuert

Eine Synchronisation, ausgelöst durch ein konkretes Ereignis.

  • Produktion abgeschlossen
  • Ereignis
  • ERP erhält die Ist-Daten

Batch

Daten werden periodisch ausgetauscht.

  • Stündlich
  • Täglich
  • Nach Tagesabschluss
  • Nach Zeitplan

Wir wählen das Synchronisationsmodell nach dem Geschäftsprozess, nicht umgekehrt.

Wie wir Integrationen bauen

Vom Geschäftsprozess zur funktionierenden Integration.

Zehn Schritte, immer in dieser Reihenfolge. Der Endpoint kommt spät - zuerst der Prozess und das Daten-Ownership.

  1. 01
    Prozess verstehenZuerst klären wir, warum die Systeme kommunizieren müssen. Wir beginnen nicht bei Endpoints.
  2. 02
    Systeme identifizierenWir erfassen alle am Prozess beteiligten Systeme.
  3. 03
    Ownership klärenWir legen fest, welches System die Source of Truth ist.
  4. 04
    DatenumfangWir entscheiden, welche Daten wirklich fließen müssen.
  5. 05
    DatenmappingWir mappen die Strukturen zwischen beiden Umgebungen.
  6. 06
    IntegrationsentwurfRichtung, Frequenz, Trigger, Authentifizierung, Validierung und Fehlerbehandlung.
  7. 07
    UmsetzungWir konfigurieren oder entwickeln die Integration.
  8. 08
    TestsWir testen End-to-End-Geschäftsszenarien.
  9. 09
    Go-liveWir starten die Integration zusammen mit dem zugehörigen Geschäftsprozess.
  10. 10
    MonitoringWir überwachen den Datenaustausch nach dem Start.

Daten-Ownership

Eine Integration beginnt mit klarem Daten-Ownership.

Dass eine Information in mehreren Systemen sichtbar ist, heißt nicht, dass alle sie unabhängig ändern dürfen. Für jeden Bereich definieren wir ein führendes System.

  • KundeSource of TruthERP
    INVOLiest / nutzt
  • FertigungsstücklisteSource of TruthINVO
    ERPErhält ausgewählte Daten
  • Produktions-Ist-DatenSource of TruthINVO MES
    ERP / BIErhält operative Ergebnisse

Eine Information kann an vielen Stellen genutzt werden. Sie sollte dennoch einen einzigen Eigentümer haben.

Verschiedene Systeme. Eine Bedeutung.

Wir verlangen keine identischen Datenmodelle auf beiden Seiten. Jedes System kann dieselbe Information anders benennen und strukturieren - die Integrationsschicht mappt zwischen ihnen.

Legacy-ERP

  • MAT_ID: 8821
  • MAT_NAME: MTR 2807 BLDC
  • BASE_UNIT: PCE

Datenmapping

  • material_code component_id
  • customer_id customer_id
  • qty quantity
  • uom unit
  • Mapping
  • Transformation
  • Validierung
  • Anreicherung

INVO

  • Komponenten-ID
  • BLDC-Motor 2807
  • Basiseinheit: Stk.

Legacy heißt nicht abgehängt

Ein älteres System kann Teil eines modernen Prozesses bleiben.

Nicht jede Organisation kann oder will ein System ersetzen, das seit Jahren kritische Prozesse trägt. Kann es Daten über Dateien, eine Datenbank, Middleware oder einen anderen Mechanismus austauschen, prüfen wir die Anbindung an INVO.

Heute

  1. Legacy-System
  2. Manueller Export
  3. Excel
  4. Manueller Import
  5. INVO

Künftig

  1. Legacy-System
  2. Automatischer Austausch
  3. Dateien · Datenbank · Middleware
  4. INVO

INVO kann innerhalb Ihrer Integrationsstandards arbeiten.

Betreibt das Unternehmen bereits Middleware, einen ESB, eine Integrationsplattform oder eine andere zentrale Integrationslösung, müssen wir diese Architektur nicht umgehen. INVO kann sich in den bestehenden Standard einfügen.

  • SAP
  • Oracle
  • WMS
  • CRM

Wir passen die Integration an die Enterprise-Architektur an, statt ein paralleles Ökosystem zu schaffen.

Zuverlässigkeit der Integration

Eine Integration muss auch dann sichtbar sein, wenn etwas schiefgeht.

In operativen Prozessen genügt „wir haben die Daten gesendet“ nicht. Man muss wissen, ob sie gesendet, empfangen, validiert und korrekt verarbeitet wurden.

  • MonitoringSichtbarkeit jedes Austauschs.
  • FehlerbehandlungFehlgeschlagene Nachrichten werden sichtbar statt zu verschwinden.
  • WiederholungErneute Verarbeitung ohne Neueingabe.
  • LösungAbschluss eines Fehlers mit Nachweis der ergriffenen Maßnahme.
  • HistorieNachvollziehbarkeit, was zwischen welchen Systemen lief.

Integrations-Monitor

  • SAP → INVOStammdatenErfolg10:42
  • INVO → WMSProduktionsbedarfErfolg10:44
  • Lieferant → INVOAuftragsbestätigungIn Bearbeitung10:45
  • INVO → Legacy-ERPVerbrauchFehler10:46
DetailsWiederholenLösenHistorie

Integrationstests

Wir testen Integrationen an realen Geschäftsszenarien.

Zu prüfen, ob ein Endpoint 200 OK liefert, ist kein Test. Wir durchlaufen den gesamten Prozess.

End-to-End-Szenario

  1. 01 Kundenauftrag
  2. 02 INVO
  3. 03 Produktionsplan
  4. 04 Komponentenbedarf
  5. 05 ERP / Einkauf
  6. 06 Produktion
  7. 07 Ist-Daten
  8. 08 ERP

Was wir prüfen

  • Eingangsdaten
  • Transformationen
  • Geschäftslogik
  • Systemantworten
  • Fehler
  • Endergebnis des Prozesses

Wir testen das fachliche Ergebnis der Integration, nicht nur die technische Verbindung.

Erst testen. Dann produktiv.

  1. 01DEV
  2. 02TEST
  3. 03UAT
  4. 04PROD

Integrationen sollten außerhalb der Produktivumgebung gebaut und getestet und anschließend gemäß dem vereinbarten Cutover-Plan gestartet werden.

Sichere Integration

Datenzugriff sollte genauso kontrolliert werden wie Systemzugriff.

  • AuthentifizierungAuthentifizierung von Systemen und Integrationen.
  • AutorisierungKontrolle, auf welche Daten und Vorgänge eine Integration zugreifen darf.
  • VerschlüsselungSichere Kommunikation zwischen Umgebungen.
  • UmgebungstrennungGetrennte Konfigurationen für Test und Produktion.
  • AuditProtokollierung relevanter Integrationsereignisse.

Warum Offenheit zählt

Die Plattform ausbauen, ohne sich an einen Anbieter zu binden.

  • Bestehende Systeme schützen

    Sie müssen funktionierende Systeme nicht austauschen.

  • Weniger manuelles Datenschieben

    Weniger Exportieren, Importieren und Abtippen.

  • Einen Prozess bauen

    Sie verbinden viele Anwendungen zu einem Workflow.

  • Bessere Datenkonsistenz

    Weniger unabhängige Kopien derselben Information.

  • Schnellere Veränderung

    Neue Systeme lassen sich in die bestehende Architektur einfügen.

  • Kein Vendor Lock-in

    Die Architektur bleibt offen für andere Lösungen.

INVO wurde als Teil Ihrer Architektur entworfen, nicht als geschlossenes System daneben.

API und Individualintegrationen

Zeigen Sie uns Ihren heutigen Stack.

In der Discovery gehen wir die genutzten Systeme, Datenquellen und bestehenden Integrationsmechanismen durch. Darauf aufbauend entwerfen wir, wie INVO in Ihre Architektur eingebunden wird.