Nicht das beste CPMS.
Das richtige.
Wie Stackbox einen CPO durch Auswahl und Einführung seines CPMS geführt hat – von den eigenen Use Cases über einen gewichteten Anforderungskatalog bis zur unterschriebenen Entscheidung. Herstellerneutral, weil wir selbst CPMS gebaut haben und keins verkaufen.
01 · Challenge
Sechs Anbieter, sechs Demos, kein Vergleich.
Der Markt für Charge Point Management Systeme ist reif – es gibt mehrere sehr gute Systeme. Genau das macht die Entscheidung schwer: Wenn die Anbieter im Kern vergleichbar wirken, fehlt die Grundlage, auf der man sie überhaupt unterscheiden könnte.
Jede Demo zeigt den Idealfall
Präsentiert wird der glatte Standardablauf. Die Fälle, an denen es später wirklich hakt – Sonderkonstellationen, Massenverarbeitung, Tariflogik, Datenexport – kommen in keiner Demo vor. Vergleichbar wird dabei nur die Präsentation, nicht das System.
Anforderungen ohne Gewicht
Ein Katalog mit zweihundert Zeilen, in dem alles ein Muss ist, führt dazu, dass alle Anbieter fast gleich abschneiden. Am Ende entscheidet der Preis oder der sympathischste Vertrieb – nicht die fachliche Passung.
Die Systemlandschaft kommt zu spät ins Spiel
Das CPMS wird isoliert bewertet. Dass es später mit ERP, CRM, Abrechnung und Asset-System sprechen muss, zeigt sich erst im Projekt – wenn die Entscheidung längst gefallen und der Vertrag unterschrieben ist.
Wechselkosten bleiben ungerechnet
Was passiert, wenn es nicht passt? Datenexport, Roaming-Verträge, Migrationspfad, Eigentum an den Ladepunktdaten – Fragen, die vor die Unterschrift gehören und fast immer erst danach gestellt werden.
Ein CPMS ist heute weitgehend Commodity: Die Kernfunktionen können alle relevanten Anbieter. Damit entscheidet nicht mehr die Funktionsliste, sondern die Passung zu den eigenen Use Cases und zur bestehenden Systemlandschaft. Diese Passung lässt sich in keiner Demo erkennen – sie muss vorher definiert und gewichtet werden.
02 · Solution
Erst die eigenen Use Cases. Dann der Markt.
Stackbox dreht die übliche Reihenfolge um: Nicht der Anbieter liefert den Kriterienkatalog, sondern die eigenen Geschäftsprozesse. Wir begleiten den gesamten Weg – von der Anforderungsaufnahme über den RfP bis zur Einführung und dem Anschluss an die bestehende Landschaft.
Use Cases statt Featureliste
Wir starten bei den Geschäftsprozessen: Welche Ladeprodukte, welche Kundengruppen, welche Abrechnungsmodelle, welche Betriebsabläufe. Daraus entsteht der Anforderungskatalog – nicht aus einer Anbieterbroschüre.
Gewichtung vor Bewertung
Jede Anforderung bekommt ein Gewicht und eine Kategorie: Ausschlusskriterium, differenzierend oder wünschenswert. Erst diese Trennung macht aus einer Punktetabelle eine Entscheidung, die man auch im Aufsichtsgremium begründen kann.
Longlist aus Passung, nicht aus Marktanteil
Wir kennen die relevanten Systeme aus der Praxis. Auf die Longlist kommt, was zu Volumen, Region und Produktmodell passt – inklusive der ehrlichen Aussage, welche Anbieter für diesen Fall gar nicht in Frage kommen.
RfP mit prüfbaren Fragen
Statt „Unterstützen Sie OCPI?“ fragen wir nach Version, konkreten Modulen und Referenzen im Produktivbetrieb. Antworten, die man nachprüfen kann – statt Fragen, die jeder Anbieter mit Ja beantwortet.
Proof of Concept an den Sonderfällen
Getestet wird nicht der Standardablauf, sondern die drei, vier Konstellationen, an denen es erfahrungsgemäß hakt. Genau dort trennen sich Systeme, die in der Demo identisch aussahen.
Einführung und Anschluss an die Landschaft
Nach der Entscheidung begleiten wir den Rollout und binden das System an ERP, CRM, Abrechnung und Asset-Management an. Die Auswahl endet nicht mit der Unterschrift, sondern mit einem System, das im Betrieb funktioniert.
Use Case → Prüfkriterium
| Use Case | Kriterium | |
|---|---|---|
| Ad-hoc-Laden mit Karte | → | PSP- & Terminal-Integration |
| Roaming über Partner | → | OCPI 2.2.1 · Module |
| Flottenkunden & Tarife | → | Tarifmodell & Mandanten |
| Eichrecht & Belege | → | Transparenzsoftware · Export |
| Bestand aus Asset-System | → | Import- & API-Fähigkeit |
| Abrechnung ins ERP | → | CDR-Export · Buchungslogik |
Bewertungsmodell
Im Anforderungskatalog geprüft
03 · Impact
Was eine begleitete Auswahl verändert.
Der Unterschied zeigt sich nicht am Tag der Entscheidung, sondern zwölf Monate später – wenn die Prozesse laufen, die vorher niemand geprüft hat.
eigenes Anbieterinteresse in der Bewertung – wir verkaufen kein CPMS
als Ausgangspunkt des Katalogs statt einer Anbieter-Featureliste
Kriterienklassen getrennt bewertet: Ausschluss, differenzierend, wünschenswert
an den Sonderfällen getestet, nicht am Standardablauf
Exit-Szenario und Migrationspfad vor der Unterschrift geklärt
begleitet bis zum Anschluss an ERP, CRM und Abrechnung
Wir hätten uns nach der zweiten Demo entschieden – und zwar falsch. Der Katalog hat sichtbar gemacht, dass zwei unserer wichtigsten Abläufe beim Favoriten gar nicht abgebildet waren.
Stackbox · CPMS Selection
Steht bei euch eine CPMS-Entscheidung an?
Wir schauen uns eure Use Cases an und sagen, worauf es bei eurer Auswahl wirklich ankommt – ohne ein eigenes System im Rennen zu haben.
Gespräch vereinbaren →