Die folgenden Praxisbeispiele zeigen Datenintegration in Aktion – über Portal, Salesforce, SAP und ChargePoint be.ENERGISED. Schritt für Schritt wird sichtbar, wie flevo Synchronisation und Orchestrierung so umsetzt, dass End-to-End-Prozesse im Tagesgeschäft zuverlässig laufen.
Praxisbeispiele Datenintegration – End-to-End Prozesse mit flevo
Viele E-Mobility-Projekte scheitern nicht an fehlenden Systemen, sondern an inkonsistenten Datenständen zwischen Portal, ERP, CRM und Charging-Backend. Die folgenden Praxisbeispiele zeigen anhand konkreter End-to-End-Prozesse, wie flevo Datenintegration im Tagesgeschäft umsetzt – nachvollziehbar, skalierbar und betriebsfest.

Warum Praxisbeispiele bei Datenintegration entscheidend sind
Datenintegration klingt in der Theorie oft sauber – in der Praxis zeigt sich jedoch schnell, ob Prozesse wirklich durchlaufen oder in manuellen Klärschleifen enden. Gerade im E-Mobility-Betrieb mit ERP, CRM und Charging-Backend entstehen Kosten nicht durch fehlende Funktionen, sondern durch unklare Datenhoheit, fehlende Rückmeldungen und inkonsistente Statusstände.
Diese Praxisbeispiele zeigen deshalb nicht abstrakte Architekturdiagramme, sondern konkrete Abläufe, wie sie im Alltag von E-Mobility-Betreibern, Energieversorgern und Stadtwerken vorkommen:
Bestellungen, die systemübergreifend angelegt, referenziert und rückgemeldet werden
Statusänderungen, die für Kunden und Betrieb nachvollziehbar bleiben
Datenstände, die konsistent sind – ohne Excel, Tickets oder manuelle Nachpflege
flevo übernimmt dabei die Rolle der Orchestrierungs- und Synchronisationsebene zwischen bestehenden Systemen. Das Charging-Backend bleibt fachlich führend, ERP und CRM bleiben gesetzt – flevo sorgt dafür, dass End-to-End-Prozesse tatsächlich funktionieren.
Praxisbeispiele aus dem Betrieb
Praxisbeispiel: Lademedien bestellen – nachvollziehbar statt „Ticket im Postfach“
Bei der Lademedien-Bestellung wird aus einer Portal-Eingabe ein durchgängiger Prozess über Salesforce, flevo und ChargePoint be.ENERGISED. Der Nutzer bestellt im Self-Service, erhält Bestellnummer und Status zurück ins Portal, und die bereitgestellten Lademedien stehen nach dem Abgleich im Portal zur Verfügung – inklusive späterer Zuweisung und Aktivierung durch den Flottenmanager.
Der Nutzer übernimmt die hinterlegten Kundendaten. Standardmäßig wird keine abweichende Lieferadresse erfasst; Rechnungs- und Lieferadresse sind identisch.
Der Nutzer wählt die Anzahl der Lademedien. Mindest- und Maximalmengen werden aus Salesforce geliefert und im Portal direkt berücksichtigt.
Nach dem Absenden wird die Bestellung automatisch in Salesforce angelegt. Eine Rückmeldung zur erfolgreichen Übertragung wird abgefangen; die Salesforce-Bestellnummer wird direkt an das Portal zurückgegeben.
In Salesforce werden der Bestellung die angefragten leeren Lademedien zugewiesen. Je Lademedium wird ein Event erzeugt.
Die Salesforce-Events werden verarbeitet; die referenzierten Lademedien werden in be.ENERGISED aktualisiert. Dabei wird u. a. der Billing-Contact mit der Unternehmens-ID gepflegt, aus dessen Kontext die Bestellung abgeschickt wurde.
Salesforce setzt die Bestellung auf „Geliefert“. Das Status-Event wird abgefangen und in flevo gespeichert. Im Portal ist die Statusänderung in der Bestellübersicht nachvollziehbar – inkl. Tracking-ID und Lieferdatum (sofern hinterlegt).
Nach dem Abgleich/Synchronisationslauf werden die gelieferten Lademedien in flevo übernommen und stehen anschließend im Portal zur Verfügung. Im selben Zuge werden Karten-/Asset-Informationen auch wieder nach Salesforce synchronisiert (Systemstände bleiben konsistent).
Der Flottenmanager sieht die neuen Lademedien in der Übersicht „Lademedien verwalten“ zunächst unzugewiesen. Er kann eine Karte bearbeiten, Fahrer und Fahrzeug zuordnen und die Karte aktivieren. Diese Änderungen werden in Echtzeit nach be.ENERGISED übertragen.
Der Flottenfahrer sieht die ihm zugewiesene Karte anschließend im Bereich „Meine Lademedien“. Die Identifikation erfolgt über die im Nutzerkontext hinterlegte be.ENERGISED-UUID.
Nachgelagerte Änderungen (z. B. Zuordnung/Status in be.ENERGISED) werden beim Abgleich über flevo nach Salesforce übertragen, damit CRM- und Charging-Backend-Stand konsistent bleiben.
Praxisbeispiel: Wallbox-Bestellung – Status und Datenstände durchgängig im Prozess
Bei der Wallbox-Bestellung wird aus einer Portal-Eingabe ein systemübergreifender Prozess über Salesforce, SAP und be.ENERGISED: Produktkatalog, Bestellung, Status, Accounts/Verträge und Assets werden systemseitig sauber referenziert und im Portal nachvollziehbar gemacht.
flevo orchestriert diesen Ablauf und hält die Datenstände zwischen Portal, Salesforce, SAP und be.ENERGISED konsistent – damit Status, Zuordnungen und Bereitstellungen ohne manuelle Abgleiche nachvollziehbar bleiben.
Der Nutzer wählt im Self-Service-Portal Produkte aus dem Salesforce-Produktkatalog und erfasst Rechnungs-, Liefer- und Installationsadresse sowie ergänzende Hinweise.
In SAP wird der Fahrer als privater Account angelegt und erhält eine GP-Nummer. Zusätzlich wird ein Vertrag angelegt und mit einer Vertragsnummer versehen. Diese Referenzen werden für den weiteren Prozess an flevo zurückgegeben.
Mit GP-Nummer und Vertragsnummer wird in Salesforce der entsprechende Account angelegt. Der Account erhält einen Shared Contract (über die SAP-Vertragsnummer), der auf den Wallbox-Vertrag des Sub-CPOs verweist. So kann Salesforce die Bestellung eindeutig kundenseitig und vertraglich referenzieren.
In be.ENERGISED wird der Account angelegt; dabei wird auch der zugehörige CRM-Kontakt erzeugt. Der Nutzer ist damit im Charging-Backend vorhanden und kann anschließend mit Assets (z. B. Karten und Wallbox) verknüpft werden.
In flevo wird der Nutzer um die Identifikatoren aus SAP, Salesforce und be.ENERGISED ergänzt. Dadurch können Kontakte und Accounts systemübergreifend eindeutig referenziert werden – ohne Dubletten und ohne fehlerhafte Zuordnungen.
Der Nutzer sieht den Fortschritt der Bestellung direkt im Portal, z. B. „Ausgangsstatus“ → „Bearbeitung“ → „Geliefert“. Statusänderungen werden aus Salesforce zurückgespielt und im Portal angezeigt.
In Salesforce werden der Bestellung die relevanten Assets zugeordnet, z. B. Wallbox inkl. Seriennummer sowie Karten.
- Die Karten werden in be.ENERGISED korrekt verknüpft: Die private Freischaltkarte wird dem Nutzer zugeordnet und ist direkt aktiv. Die Rückerstattungskarte wird ebenfalls zugeordnet, bleibt jedoch zunächst deaktiviert; die Aktivierung erfolgt zu einem späteren Zeitpunkt im Prozess.
Nach Bereitstellung/Abgleich stehen Wallbox und Karten im Portal zur Verfügung (z. B. „Meine Wallbox“, „Meine Lademedien“) – rollenbasiert und je Nutzerkontext sichtbar.
Der Nutzer setzt den Tarif/Arbeitspreis und lädt den Installationsnachweis hoch. Diese Informationen werden in flevo gespeichert und an be.ENERGISED sowie Salesforce übertragen.
Nach Prüfung werden Statuswechsel (z. B. „Zu prüfen“ → „Abgeschlossen“) zurückgemeldet und im Portal sichtbar. Gleichzeitig werden die erforderlichen Aktivierungen in den Zielsystemen gesetzt – insbesondere wird die Rückerstattungskarte in be.ENERGISED aktiviert.
Was diese Praxisbeispiele für Ihren Betrieb bedeuten
Unabhängig vom konkreten Prozess zeigen alle Beispiele dasselbe Muster:
- Klare Datenhoheit: Jedes System tut das, wofür es gedacht ist – ohne Doppelpflege
- Nachvollziehbare Statusstände: Bestellungen, Zuordnungen und Aktivierungen sind systemübergreifend konsistent
- Weniger Rückfragen & Supportaufwand: Kunden und interne Teams arbeiten mit derselben Datengrundlage
- Skalierbarkeit: Mehr Kunden, mehr Assets oder mehr Bestellungen erhöhen nicht den Abstimmungsaufwand
Datenintegration ist kein IT-Sideprojekt, sondern die Voraussetzung dafür, dass E-Mobility wirtschaftlich betrieben und sauber skaliert werden kann.