CPMS-Auswahl: 12 Kriterien, die in Ausschreibungen zählen

CPMS-Auswahl per Feature-Matrix: Warum jeder Anbieter alles kann.

Wer ein CPMS ausschreibt, bekommt Angebote zurück, in denen fast jede Zeile der Anforderungsmatrix mit Ja beantwortet ist. OCPP 2.0.1: ja. Eichrecht: ja. Roaming: ja. Das Problem dieser Matrizen ist strukturell: Sie fragen, ob eine Funktion existiert, nicht wie tief sie umgesetzt ist – und genau in dieser Tiefe unterscheiden sich Plattformen, die auf dem Papier identisch aussehen.

Ein belastbarer Kriterienkatalog stellt deshalb andere Fragen: solche, die sich vor Vertragsschluss prüfen lassen – per Demo, per Proof of Concept, per Vertragsentwurf. Die zwölf Kriterien in diesem Artikel sind aus Auswahl- und Migrationsprojekten destilliert und in vier Gruppen sortiert. Für jedes Kriterium gilt dasselbe Muster: warum es im Betrieb zählt und wie es sich konkret überprüfen lässt, solange noch Verhandlungsspielraum besteht.

• Protokoll-Substanz: OCPP-Versionen ohne Sternchen, Hersteller-Interoperabilität, Simulator-Zugang.
• Betrieb: Monitoring in Nachrichtentiefe, Firmware-Kampagnen, Support-Durchgriff.
• Kaufmännisch: Eichrecht mit OCMF, XRechnung, Exit-Klauseln und Datenexport.
• Zukunftsfähigkeit: OCPI-Roaming, ISO 15118 und Plug&Charge, Erweiterbarkeit über APIs.

Protokoll-Substanz: OCPP-Versionen, Interoperabilität, Simulator-Zugang.

„OCPP 2.0.1 wird unterstützt“ steht heute in fast jedem Datenblatt – gemeint ist damit erstaunlich oft nur ein Teil des Protokolls. OCPP 2.0.1 organisiert seine Funktionen in Function Blocks von Security über Provisioning bis Smart Charging, und ein Backend kann formal 2.0.1 sprechen, ohne Gerätemodell, TransactionEvent-Logik oder Security Profiles vollständig umzusetzen. Genau diese Tiefe entscheidet aber darüber, ob Zertifikatsmanagement, Plug&Charge und sauberes Transaktionshandling später funktionieren. Prüfbar wird das Kriterium mit einer schriftlichen Liste: Welche Function Blocks und Security Profiles laufen produktiv bei Bestandskunden, welche stehen nur auf der Roadmap. Ein Anbieter, der hier präzise antwortet, hat die Arbeit gemacht – einer, der auf das Datenblatt verweist, meist nicht.

Kriterium zwei ist Hersteller-Interoperabilität. Reale Flotten mischen Hersteller, Modellgenerationen und Firmwarestände, und jedes Gerät interpretiert OCPP ein wenig anders – beim Reconnect-Verhalten, bei der MeterValues-Konfiguration oder im Timing von Statusmeldungen. Ein CPMS, das nur mit wenigen Modellreihen im Feld steht, verlagert diese Integrationsarbeit in das eigene Projekt. Die Prüfung ist unbequem, aber einfach: eine Liste der produktiv angebundenen Ladepunktmodelle anfordern und im Proof of Concept genau die Geräte anbinden, die im eigenen Bestand stehen – mit den echten Firmwareständen, nicht mit dem Vorführgerät des Anbieters.

Das dritte Kriterium wird in Ausschreibungen fast nie abgefragt: Zugang zu Simulator und Testumgebung. Wer Fehlerbilder nur am produktiven Bestand nachstellen kann, testet im Ernstfall an zahlenden Kunden. Ein Anbieter mit eigener Simulations- und Testinfrastruktur kann Verbindungsabrisse, Offline-Nachlieferungen und Lastszenarien reproduzierbar durchspielen – und dem Kunden denselben Zugang geben. In die Ausschreibung gehört deshalb die Anforderung, definierte Szenarien selbst testen zu dürfen: Verbindungsabriss während einer laufenden Transaktion, Nachlieferung gepufferter Messwerte, gleichzeitiger Reconnect vieler Ladepunkte.

Betrieb: Monitoring, Firmware-Kampagnen und Support-Durchgriff.

Ein Uptime-Dashboard ist noch kein Monitoring. Im Betrieb zählt die Frage, wie schnell sich ein hängender Ladevorgang diagnostizieren lässt – und dafür braucht es Sicht bis auf Nachrichtenebene: welche StatusNotification wann kam, welche Anfrage offen blieb, wie sich der Ladepunkt vor dem Fehler verhalten hat. Fehlt diese Tiefe, wird jede Störung zum Ticket-Pingpong zwischen Betreiber, Plattform und Hersteller. Der Praxistest ist eine Live-Demo mit konkretem Auftrag: einen realen oder simulierten Störfall diagnostizieren, statt die Standard-Ansicht zu präsentieren.

Firmware-Kampagnen sind das zweite Betriebskriterium. Ladeinfrastruktur lebt über Jahre, und Sicherheits-Patches, Protokoll-Updates und Fehlerbehebungen kommen regelmäßig – ohne Kampagnenwerkzeug wird jedes Update zur Handarbeit pro Ladepunkt. Ein brauchbares CPMS staffelt Rollouts über Pilotgruppen, zeigt Erfolgs- und Fehlerraten pro Kohorte und kann eine laufende Kampagne stoppen. Prüfen lässt sich das am Testbestand: Eine kleine Kampagne mit gestaffeltem Rollout und bewusst provoziertem Fehlerfall zeigt schnell, ob das Werkzeug den Namen verdient.

Kriterium sechs ist der Support-Durchgriff. Reaktionszeiten im SLA sagen wenig darüber, was der Support tatsächlich sehen und tun kann, wenn nachts ein Standort ausfällt. Entscheidend ist, ob der Second-Level auf OCPP-Rohdaten und Nachrichten-Timelines zugreifen kann und ob es einen definierten Eskalationspfad zu den Ladepunkt-Herstellern gibt. Im Auswahlprozess lohnt der Blick in die SLA-Definitionen – Lösungszeiten statt nur Reaktionszeiten – und die direkte Frage, welche Diagnosedaten der Support im Störfall vor sich hat.

Kaufmännisch: Eichrecht, XRechnung und der geregelte Exit.

In Deutschland führt an eichrechtskonformer Abrechnung kein Weg vorbei: signierte Messwerte aus MID-konformen Zählern, gespeichert und weitergegeben im OCMF-Format, prüfbar über Transparenzsoftware. Jede Lücke in dieser Kette wird zum Abrechnungs- und Haftungsrisiko, das sich nachträglich kaum reparieren lässt. Ein Datenblatt-Ja genügt hier nicht, denn zwischen „Eichrecht-ready“ und einer durchgängigen Signaturkette liegen Welten. Der Praxistest ist eine End-to-End-Demonstration: vom signierten Messwert am Ladepunkt über die Speicherung im CPMS bis zur erfolgreichen Prüfung des Datensatzes in der Transparenzsoftware.

Kriterium acht betrifft alle, die mit Stadtwerken, Kommunen oder öffentlichen Auftraggebern arbeiten: elektronische Rechnungen. Für Rechnungen an die öffentliche Hand ist die XRechnung in Deutschland verbindlich, und im B2B-Geschäft greift die stufenweise E-Rechnungspflicht. Ein CPMS, dessen Abrechnungsexporte nur PDF und CSV kennen, erzeugt an dieser Stelle dauerhaften Handarbeitsaufwand oder teure Zusatzprojekte im ERP. Die Prüfung ist konkret: eine Beispielrechnung als XRechnung erzeugen, gegen die offiziellen Validierungsregeln prüfen lassen und die Übergabe an das vorhandene ERP-System durchspielen.

Das neunte Kriterium ist unbequem, weil es vom Ende her denkt: Exit-Klauseln und Datenexport. Der beste Zeitpunkt, die Trennung zu regeln, ist vor der Unterschrift – danach bestimmt der Anbieter Format, Frist und Preis. Zum sauberen Exit gehören dokumentierte Exportformate für alle Betriebsdaten und die technische Freiheit, Ladepunkte auf ein anderes Backend umzukonfigurieren. Wer den Datenexport bereits im Proof of Concept testet, weiß im Ernstfall genau, was er bekommt.

• Vollständiger Export von Stammdaten, Transaktionen und OCMF-Datensätzen in dokumentierten, offenen Formaten.
• Mitwirkungspflichten des Anbieters bei einer Migration, mit definierten Fristen und Aufwänden.
• Keine technische Bindung: Backend-URL und Zertifikate der Ladepunkte bleiben umkonfigurierbar.
• Aufbewahrungs- und Löschregeln für eichrechtsrelevante Datensätze nach Vertragsende.
• Testexport schon im Proof of Concept, nicht erst im Streitfall.

Zukunftsfähigkeit: Roaming, ISO 15118 und Erweiterbarkeit.

Roaming entscheidet darüber, wie sichtbar und nutzbar Ladepunkte über die eigene Kundenbasis hinaus sind. De-facto-Standard dafür ist OCPI, in der Praxis heute meist in Version 2.2.1, mit Modulen für Locations, Sessions, Tariffs und CDRs. Interessant ist weniger das Ob als das Wie: Laufen produktive Roaming-Verbindungen direkt zu Partnern oder über einen Hub, und wie schnell propagieren Tarif- und Standortänderungen. Die Prüffrage lautet deshalb: Welche OCPI-Verbindungen sind heute live, welche Module sind implementiert, und wie wird ein Tarifwechsel Ende-zu-Ende getestet.

Seit Januar 2026 gilt die ISO 15118-Pflicht für neue öffentliche AC-Ladepunkte in der EU, und Plug&Charge wandert vom Zukunftsthema auf die Anforderungsliste. Für das CPMS heißt das: Zertifikatsmanagement über OCPP 2.0.1, Umgang mit Vertragszertifikaten und Anbindung an die Plug&Charge-Ökosysteme müssen vorhanden sein oder einen glaubwürdigen Fahrplan haben. Ein Anbieter, der die Installation eines Zertifikats über OCPP live zeigen kann, ist hier weiter als einer mit einer Ankündigungsfolie. Genau das lässt sich in der Ausschreibung verlangen: eine Demonstration des Zertifikats-Handlings statt eines Bekenntnisses zur Norm.

Das zwölfte Kriterium ist Erweiterbarkeit. Kein CPMS deckt alle künftigen Anforderungen ab – entscheidend ist, ob sich fehlende Funktionen über dokumentierte APIs, Webhooks und Event-Streams ergänzen lassen, ohne für jede Kleinigkeit den Anbieter zu beauftragen. Prüfbar wird das über die API-Dokumentation vor Vertragsschluss, einen Sandbox-Zugang und eine klare Versionierungs-Policy. Zusammengenommen machen die zwölf Kriterien aus einer Feature-Ausschreibung ein prüfbares Assessment, das Anbieter nach Substanz statt nach Datenblatt sortiert. Als strukturierter Katalog eignet er sich als Ausgangspunkt für ein CPMS-Assessment in Auswahl- und Migrationsprojekten – und wo einzelne Fähigkeiten fehlen, entscheidet, ob sich die Lücke über modulare Ergänzungen schließen lässt, ohne die Plattform zu wechseln.