SAP / ERP
Artikel, Stammdaten und freigegebene Belege → Loyalty; Buchungs- und Abstimmexport → ERP.
Im Projekt zu prüfen: ERP-Variante, Version und Datenhoheit prüfen.
Integrationen und Konnektoren
ProLoyalty mit Ihrer Systemlandschaft verbinden
Prüfen Sie, welche Daten aus ERP, CRM, Shop, Kasse und weiteren Systemen übernommen und wohin Ergebnisse zurückgegeben werden.
Mit Datenobjekten beginnen, nicht mit LogosWas kommt hinein?
Was kommt hinein?
Was geht verbindlich zurück?
Ein Systemname beschreibt noch keine funktionierende Integration. Entscheidend sind Datenobjekte, Richtung, Aktualität und die Person, die den jeweiligen Fluss betreibt.
| Beispielfluss | Eingang | Rückweg | Status |
|---|---|---|---|
| SAP / ERP | Artikel und freigegebener Kaufnachweis | Buchungsreferenz und Abstimmexport | Projektintegration: Variante und Umfang bestätigen |
| CRM | Führendes Profil und zulässiger Kontaktstatus | Vereinbarter Programm- und Servicezustand | Objekte und Verantwortlichkeit abstimmen |
| POS / Shop | Kauf, Retoure und Mitgliedsreferenz | Berechtigter Vorteil und Verarbeitungsstatus | Kasse, Version und Fehlerweg testen |
Die Rolle im Datenfluss erkennenIhre Systeme.
Ihre Systeme.
Ihre klare Anschlussfrage.
Dynamics 365 / Salesforce / Siebel
Profile, Servicebezug und freigegebene Ereignisse ↔ definierte Loyalty-Objekte.
Im Projekt zu prüfen: Führende Identität, Consent und Rückkanal abstimmen.Shopware / weitere Shops
Kauf, Konto und Retoure → Qualifikation; berechtigte Vorteile → Shop.
Im Projekt zu prüfen: Checkout-Zeitbudget und Fehlerszenarien testen.POS / Kassensysteme
Mitglied erkennen, Vorteil prüfen, Kauf und Retoure referenziert übernehmen.
Im Projekt zu prüfen: Kassenvariante, Online-/Offlinegrenzen und spätere Synchronisierung prüfen.CDP / BI / DWH
Segmente, Ereignisse und Reportingdaten nach freigegebenen Objekten austauschen.
Im Projekt zu prüfen: Definitionen, Granularität und Datenaktualität dokumentieren.Marketing Automation
Zielgruppe und Trigger → Kommunikationsprozess; Versand- und Sperrstatus zurückführen.
Im Projekt zu prüfen: Consent, Kontaktfrequenz und Zustellstatus abnehmen.HRIS / LMS
Berechtigung oder bestätigten Lernabschluss für das vereinbarte Programm übernehmen.
Im Projekt zu prüfen: Zweck, Personenzuordnung und Wiederholung begrenzen.Payment / Marktplätze
Auszahlung oder Bestellung beauftragen und bestätigten Zustand zurückgeben.
Im Projekt zu prüfen: Partnerrolle, Idempotenz und Abrechnung festlegen.Microsoft 365 / Entra ID / Power BI
Zusammenarbeit, Identitätszugang und Analyse mit jeweils eigenem Zweck anbinden.
Im Projekt zu prüfen: Kein einheitlicher Konnektor für alle drei Aufgaben.9 Systemgruppen angezeigt
Bedeutet eine Nennung „nativ“ oder „zertifiziert“?
Nein. Eine öffentlich genannte Anbindung oder ein beschriebenes Integrationsmuster belegt noch keinen nativen oder zertifizierten Konnektor für jede Version. Der Steckbrief unterscheidet bestätigte Produktanbindung, Partnerlösung, Referenzmuster, offene API und individuelle Projektintegration. Für INVOICE nennt die öffentliche Produktbeschreibung konkrete vorgefertigte Konnektoren; auch dort wird der tatsächliche Umfang abgestimmt.
Ein prüfbarer Anschluss statt einer VermutungDer Integrationssteckbrief
Der Integrationssteckbrief
macht die Zusage konkret.
Ein guter Steckbrief beantwortet die Fragen, die später Entwicklung, Einkauf und Betrieb gemeinsam stellen.
- 01Objekt und RichtungWelche Felder und fachlichen Vorgänge fließen in welche Richtung? Welcher Schlüssel verbindet die Systeme?
- 02Verfügbarkeit und VoraussetzungWelche Produktversion, Lizenz, API-Freigabe und technische Zugangsmethode werden benötigt?
- 03Aktualität und LimitsWelche Verzögerung ist zulässig, welche Menge wird erwartet und wie verhält sich der Fluss bei Begrenzung?
- 04Betrieb und SupportgrenzeWer betreibt Sender, Empfänger und Integration? Wer klärt Feldfehler, Ausfall und fachliche Differenzen?
Zustellung und Fachverarbeitung unterscheidenEin Fehler muss sichtbar bleiben.
Ein Fehler muss sichtbar bleiben.
Eine Wiederholung muss sicher sein.
QUELLE
Vorgang mit stabiler Referenz senden
Das Quellsystem übermittelt den vereinbarten Datensatz mit Herkunft und Ereignisbezug.
VERARBEITUNG
Validieren und fachlich einordnen
Format, Berechtigung, Dublette und gültige Regel bestimmen das Ergebnis. Eine Transportbestätigung ist noch keine Gutschrift.
Normalweg
Ergebnis und Referenz gehen an den vereinbarten Rückkanal. Quelle und Ziel können den Zustand abstimmen.
Fehlerweg
Temporäre Fehler erhalten begrenzte Wiederholung mit Wartezeit. Nicht automatisch lösbare Fälle gehen in eine überwachte Fehlerwarteschlange.
Replay und Backfill
Ein erneuter Lauf nutzt stabile Referenzen und den definierten Zeitraum. Er darf erfolgreiche Vorgänge nicht nochmals vergüten. Bei nachgelieferten Daten muss außerdem klar sein, welche historische Regel gilt.
Dateien vollständig verarbeiten
Batch und SFTP benötigen vereinbarte Dateinamen, Formatprüfung und Vollständigkeit. Prüfsumme, Zeilenzahl und Ergebnisbericht helfen, fehlende oder teilweise verarbeitete Bestände zu erkennen.
Was wird im Monitoring unterschieden?
Erreichbarkeit, Zustellung, technische Verarbeitung und fachliche Ablehnung sind unterschiedliche Signale. Ein leerer Fehlerzähler ist kein Beleg, dass alle Belege oder Käufe angekommen sind. Der Abgleich benötigt erwartete Mengen und belastbare Referenzen.
Am tatsächlichen Vorgang abnehmenDrei Systeme.
Drei Systeme.
Drei konkrete Prüfpfade.
POS
Eingang: Mitgliedskennung und Kauf. Rückweg: Entscheidung oder Verarbeitungsstatus. Test: identischer Kauf zweimal, anschließend Teilretoure.
Erwartung: genau eine ursprüngliche Wirkung und eine referenzierte Korrektur.
ERP
Eingang: Produktstamm und freigegebener Beleg. Rückweg: Abstimmexport. Test: unbekannter Artikel und verspätete Lieferung.
Erwartung: sichtbarer Klärungsbedarf, kein stillschweigender Datenverlust.
CRM
Eingang: führendes Profil und Kontaktstatus. Rückweg: vereinbarter Programmzustand. Test: Abmeldung und Identitätsänderung.
Erwartung: zulässige Datenübernahme und konsistenter Rückkanal.
Erst Hoheit klären, dann verbindenEin Plan für Daten,
Ein Plan für Daten,
Tests und Verantwortung.
- 01
Discovery
Führende Systeme, Schlüssel, Datenzweck und erwartete Mengen erfassen.
- 02
Mapping
Felder, Zustände, Richtung und Fehlerantworten gemeinsam festlegen.
- 03
Sandbox
Zugänge und synthetische Transaktionen kontrolliert einrichten.
- 04
Pilot
Vertrag, Last, fachliche Wirkung und Wiederanlauf testen.
- 05
Betrieb
Go-live, Zuständigkeit, Abgleich und spätere Änderungen dokumentieren.
Allgemeines Architekturmuster zur fachlichen Rückabwicklung: Microsoft Azure Architecture Center. Die Referenz beschreibt ein technisches Muster und belegt keinen konkreten ProLoyalty-Funktionsumfang.
Passende Bausteine
Hier geht Ihr Thema weiter.
Lassen Sie uns konkret werden
Ihr Vorhaben. Unser gemeinsamer nächster Schritt.
Besprechen wir Ihre Zielgruppe, Ihre Datenquellen und den Ablauf, den Sie verbessern möchten. Daraus entsteht eine Demo, die zu Ihrem Programm passt.
Ihre Demo beginnt mit Ihrem Alltag.
Ein normaler Vorgang. Ein Sonderfall. Die beteiligten Systeme. Wir zeigen, wie Regeln, Kanäle und Kontrolle zusammenspielen.