Die meisten Betreiber, die einen Plattformwechsel ernsthaft geprüft haben, haben in irgendeiner Form dieselbe Rechnung aufgestellt: Was kosten das aktuelle Team und die Infrastruktur pro Jahr, verglichen mit den Gebühren, die sie für ein Lademanagementsystem (CPMS) zahlen würden?
Dieser Vergleich hat einen blinden Fleck. Die größten Kosten eines Inhouse-CPMS tauchen in keinem Budget auf. Sie erscheinen weder in der Personalplanung noch auf der Rechnung für die Cloud-Infrastruktur oder bei den Compliance-Ausgaben. Sie sammeln sich in dem, was nie gebaut wurde, in Perspektiven, die nie in die Entscheidungen einflossen, und im Abstand zwischen dem heutigen Stand des Betriebs und dem, was möglich wäre.
Die meisten Inhouse-Plattformen entstanden zu einer Zeit, als kommerzielle Alternativen noch nicht ausgereift genug waren, um ihnen das Kerngeschäft anzuvertrauen. Die ursprüngliche Begründung ist nach wie vor stichhaltig. Geändert hat sich die Rechnung, genauer gesagt die Kosten, die nie in einer Budgetzeile auftauchten. Wir haben Plattformwechsel mit einigen der größten Ladestationsbetreiber (CPOs) Europas begleitet. Was Betreiber dabei immer wieder feststellen: Ihr bisheriger Vergleich ließ genau die Kosten außen vor, die am meisten ins Gewicht fallen.
Die Arbeit, die immer zuerst drankommt
Ein Inhouse-CPMS zu betreiben bedeutet, dass Ihr Entwicklungsteam wiederkehrende Pflichten trägt, die Ihnen keine kommerzielle Plattform abnimmt. Protokoll-Updates, Neuzertifizierungen für Zahlungen, regulatorische Compliance-Zyklen: Sie landen als fest eingeplante Arbeit im Backlog, vor allem anderen, weil Markt und Regulierungsbehörden die Frist setzen und nicht Ihr Produktteam.
Diese Pflichten wachsen mit der Größe: Jeder neue Markt, jeder zusätzliche Hardwarehersteller, jede Rechtsordnung mit eigenem Compliance-Kalender vergrößert den Umfang dessen, was gepflegt werden muss. Die Kapazität des Teams, all das zu pflegen, wächst nicht im selben Tempo.
Die eigentlichen Kosten sind nicht die Stunden selbst, sondern das, was sie verdrängen. Zurückgestellt wird genau die Arbeit, die das Geschäft voranbringen würde. Der Compliance-Sprint ist auf dem Board sichtbar. Der Roadmap-Punkt, den er verdrängt hat, nicht.
Ihr Unternehmen, wie es schon sein könnte
Ihr Betrieb könnte heute schon anders aussehen, wären die Wartungsaufgaben nicht immer vorgegangen. Funktionen, die seit achtzehn Monaten auf der Roadmap stehen. Eine kommerzielle Funktion, die auf den nächsten Zyklus verschoben wurde und dann auf den übernächsten. Kunden-Tools, für die Ihr Team das Know-how hat, aber nicht die freie Kapazität, um damit zu beginnen.
Diese Dinge tauchen in keinem Audit auf, weil es sie nie gab. Sie können alles prüfen, was gebaut wurde. Für das, was nicht gebaut wurde, gibt es keine Prüfung.
Manches von dem, was aufgeschoben wurde, ist inzwischen Standard bei den Betreibern, mit denen Sie im Wettbewerb stehen. Anderes wird in den Märkten, in denen Sie tätig sind, gerade zur kommerziellen Erwartung. Die aufgeschobene Roadmap erzeugt nirgends eine sichtbare Kostenzeile. Ihre Folgen zeigen sich in den Fähigkeiten, die Ihnen fehlen, wenn eine kommerzielle Chance sie erfordert.
Ermitteln Sie mit dem Inhouse-CPMS-Benchmark, wo Ihr Betrieb steht.
Der Maßstab, den es nur von außen gibt
Inhouse-Teams entwickeln echte Expertise in ihrem eigenen Betrieb. Mit der Zeit bringt diese Expertise einen Effekt mit sich, der von innen schwer zu erkennen ist: eine schleichende Verschiebung des Maßstabs. Ohne externe Bezugspunkte richtet sich das Gespür des Teams dafür, was schwierig ist, was normal ist und was wirklich nur das eigene Netzwerk betrifft, immer stärker nach innen. Die Folge ist eine dauerhafte Überschätzung, wie individuell die eigenen Anforderungen sind. Individuelle Abrechnungslogik, die unersetzlich wirkt. Hardware-Sonderfälle, die einzigartig komplex erscheinen. Workflow-Anforderungen, die zu speziell scheinen, als dass eine Standardplattform sie abbilden könnte.
Betreiber, die den Wechsel vollzogen haben, beschreiben danach durchweg dieselbe Erkenntnis: Das meiste, was sich wie unersetzliche, ganz eigene Komplexität anfühlte, war die normale Komplexität eines großen Netzwerks. Firmware-Management über ein Dutzend Hardwarehersteller hinweg, mehrstufige Abrechnungslogik für B2B-Flottenverträge, individuelle Strukturen für Roaming-Zugangsdaten: Diese Herausforderungen haben Dutzende andere Betreiber auf derselben Plattform längst gelöst. Die Lösungen gab es. Sie waren von innen nur nicht sichtbar.
Betreiber auf einer kommerziellen Plattform mit 200+ Netzwerken entwickeln einen Maßstab, der innerhalb eines einzelnen Betriebs strukturell nicht zu haben ist: was vergleichbare Netzwerke bereits gelöst haben, welche Fähigkeiten zu Marktanforderungen werden, bevor sie in einer Ausschreibung auftauchen, und wohin sich die Branche bewegt, bevor es so weit ist. Ein einzelner Betrieb, so gut er auch geführt wird, kann diesen Maßstab nicht aufbauen.
Wissen, das an zu wenigen Köpfen hängt
Jedes Inhouse-CPMS hat eine kleine Gruppe von Entwicklern, die das eigentliche Gedächtnis des Systems sind, durch Betriebszugehörigkeit und Zufall entstanden, nicht durch Planung. Sie wissen, warum eine Abrechnungsregel fest im Code steht. Sie wissen, was der Firmware-Patch von 2021 geändert und was er ungelöst gelassen hat. Sie wissen, welcher Hardware-Sonderfall einen Workaround braucht, der nie formal dokumentiert wurde.
Auch die Codebasis, die sie pflegen, hat über Jahre Entscheidungen angesammelt, die unter betrieblichem Druck getroffen wurden: Entscheidungen, die im Moment sinnvoll waren, in der Summe aber dazu führen, dass jede künftige Änderung etwas mehr Aufwand verursacht, als sie sollte. McKinsey schätzt, dass technische Schulden 20 bis 40 % des Werts des gesamten Technologiebestands ausmachen, ein wachsender Mehraufwand, der selten in einer einzelnen Position auftaucht, bevor er zur Einschränkung wird.
Jede große Codebasis, die über Jahre unter betrieblichem Druck entsteht, entwickelt ganz natürlich diese Art unsichtbarer Last. Die daraus entstehende Fragilität ist ein Risiko für die Geschäftskontinuität, nicht nur ein technisches Problem. Wenn diese Entwickler gehen (durch Fluktuation, bessere Angebote oder die angesammelte Erschöpfung nach Jahren im Wartungsmodus), wandert das Wissen nicht sauber mit. Die Wissenslücke zeigt sich meist dann, wenn der Betrieb sie am wenigsten verkraften kann: während einer Migration, einer Übernahme oder eines Compliance-Sprints, den niemand eingeplant hatte.
Kommt Ihnen dieses Muster bekannt vor? Das Gespräch über einen Proof of Concept (PoC) beginnt mit Ihrer aktuellen Architektur.
Der Abstand, der immer größer wird
Jeder dieser Kostenfaktoren wiegt schon für sich. Zusammen wirken sie jedoch auf eine andere Weise.
Da AMPECO als eine einzige Plattform für alle 200+ Betreiber gleichzeitig gepflegt wird, erreicht jede neu ausgelieferte Funktion alle zugleich: etwa KI-gestützte Fehlerdiagnose, dynamisches Tarifmanagement und Integrationen für das Energiemanagement, die in den Märkten Ihrer Kunden zu Standardanforderungen werden. Bei einer Inhouse-Plattform landet jede davon im Backlog als etwas, das bewertet, abgegrenzt, priorisiert und schließlich gebaut werden muss, allein und von einem Team, das bereits mit Aufholarbeit ausgelastet ist.
Im ersten Jahr sind das ein oder zwei Funktionen. Im dritten Jahr ist der Abstand erheblich: eine Reihe von Fähigkeiten, auf die Ihre Wettbewerber Zugriff haben und die Ihr Team im Backlog noch nicht erreicht hat. Im fünften Jahr geht es um die Frage, was Ihr Unternehmen anbieten kann und was nicht: welche Geschäftsmodelle Sie unterstützen können, welche Marktanforderungen Sie erfüllen können und was Ihr Entwicklungsteam überhaupt bauen kann, wenn Kunden und Wettbewerber sich schneller bewegen, als Ihr Backlog es zulässt.
Der Aufholaufwand, die aufgeschobene Roadmap, der fehlende Maßstab über Netzwerke hinweg, die wachsenden technischen Schulden: Diese Faktoren addieren sich nicht einfach. Sie greifen ineinander und verstärken sich: Der Aufholaufwand verbraucht die Kapazität, die den Backlog abbauen würde, und der aufgeschobene Backlog verhindert die Roadmap-Arbeit, die den Aufwand senken würde. Der Abstand zwischen einem Inhouse-Betrieb und einem Betrieb auf einer kommerziellen Plattform, die diese Kosten zentral auffängt, bleibt mit der Zeit nicht gleich.
Was Betreiber erleben, die beide Seiten kennen
Die Betreiber, die diesen Wechsel mit AMPECO vollzogen haben, haben diese Kosten nicht als Theorie erlebt. Sie haben sie im Nachhinein erkannt: an den Funktionen, von denen sie nicht wussten, dass es sie gibt, an den Problemen, die andere längst gelöst hatten, ohne dass sie davon wussten, und an der Roadmap, die wenige Monate nach dem Wechsel in Bewegung kam, weil die Wartungsaufgaben endlich abgearbeitet waren.
Die Erkenntnis ist immer dieselbe: Sie wussten nicht, was möglich ist, weil niemand innerhalb eines einzelnen Betriebs das ganze Bild dessen sehen kann, was vergleichbare Betriebe bereits gelöst haben.
Bevor Sie zu diesen Schlüssen kommen, lohnt es sich, intern einige Fragen zu stellen:
- Welcher Anteil Ihrer Entwicklungskapazität floss in den letzten zwölf Monaten in Protokoll-Updates, Compliance-Arbeit oder Neuzertifizierungen für Zahlungen?
- Wie viele Roadmap-Punkte wurden mehr als zweimal verschoben?
- Wenn die Entwickler, die die Plattform am besten kennen, morgen gingen: Wie lange würde es dauern, bis der Betrieb darunter leidet?
- Welche kommerziellen Funktionen haben Sie in den letzten zwei Jahren nicht gebaut, die Wettbewerber auf kommerziellen Plattformen heute anbieten?
Diese Erkenntnis kann kommen, bevor sich der Abstand verstärkt, oder danach. Der Unterschied zwischen diesen beiden Zeitpunkten ist erheblich: nicht wegen der Dringlichkeit, sondern weil das Entwicklungsteam dann noch die Kapazität hat, den Wechsel zu steuern, statt ihn nur aufzufangen.
Weiterlesen:
Die Argumente für ein eigenes CPMS sind überholt: die strategische Einordnung, warum sich die Rechnung geändert hat, geschrieben für Geschäftsleitung und Aufsichtsgremien.
Immer im Rückstand: Warum Inhouse-CPMS-Teams nicht für morgen bauen können: der strukturelle Grund für den Wartungsaufwand, warum mehr Personal das Problem nicht löst und was sich ändert, wenn die Pflichtaufgaben auf die Plattform übergehen.
