Eigenentwicklung vs. Standardsoftware für Redispatch

Viele Energieversorger und Netzbetreiber verfügen über eigene IT-Abteilungen, die grundsätzlich in der Lage wären, eine Software für die Redispatch-Abrechnung zu entwickeln. Die Frage ist: Sollten sie es tun?

Die Antwort hängt von mehreren Faktoren ab: der Verfügbarkeit von Entwicklerressourcen, der Spezifik der eigenen Anforderungen, dem Zeithorizont und der Bereitschaft, langfristig in Wartung und regulatorische Anpassungen zu investieren. Eine ehrliche Analyse zeigt, dass die Eigenentwicklung in den meisten Fällen teurer und risikoreicher ist als angenommen.

Erfahrungswerte aus der Branche zeigen: Die initialen Entwicklungskosten werden regelmäßig um 50–100 % unterschätzt. Ein typisches Projekt beginnt mit einem Scope von „3 Monate, 2 Entwickler" und wächst auf 12–18 Monate mit 3–4 Entwicklern. Der Grund: Die regulatorische Komplexität der Redispatch-Abrechnung – von der Ausfallarbeitsberechnung über EDIFACT-Parsing bis zur korrekten Abbildung aller Sonderfälle – wird erst im Laufe der Entwicklung sichtbar.

Noch gravierender sind die laufenden Kosten: Regulatorische Änderungen erfordern kontinuierliche Anpassungen. Die Beschlüsse der Bundesnetzagentur müssen innerhalb enger Fristen umgesetzt werden. Das bindet 1–3 Entwickler dauerhaft – Entwickler, die für andere Projekte nicht zur Verfügung stehen.

Der häufigste Fehler: Unternehmen vergleichen die SaaS-Gebühren einer Standardsoftware mit den geschätzten Entwicklungskosten – ohne Wartung, regulatorische Updates und Opportunitätskosten einzurechnen. Auf 5 Jahre gerechnet ist die Eigenentwicklung in den meisten Fällen 3–5× teurer als eine SaaS-Lösung.

Eigenentwicklung kann die richtige Wahl sein, wenn das Unternehmen hochspezifische Anforderungen hat, die keine Standardsoftware abdeckt. Das betrifft etwa Übertragungsnetzbetreiber mit proprietären Schnittstellen zu Leitsystemen oder Unternehmen, die die Redispatch-Abrechnung tief in eine bestehende, selbst entwickelte Plattform integrieren müssen.

Voraussetzung ist in jedem Fall: ein stabiles Entwicklerteam mit energiewirtschaftlichem Know-how, ein realistisches Budget (inkl. 5 Jahre Wartung), und die Bereitschaft, regulatorische Änderungen zeitnah umzusetzen. Wenn eine dieser Voraussetzungen fehlt, ist das Risiko zu hoch.

In der Praxis hat sich ein Mittelweg bewährt: Unternehmen nutzen eine Standardsoftware wie RedisPay für den Kernprozess der Abrechnung und entwickeln ergänzende Module für spezifische Anforderungen. Über APIs lässt sich RedisPay in bestehende Systeme integrieren, während die Kernlogik – insbesondere die regulatorisch sensible Berechnung – vom spezialisierten Anbieter gepflegt wird.

Dieser Ansatz kombiniert die Vorteile beider Welten: die regulatorische Sicherheit und schnelle Verfügbarkeit der Standardsoftware mit der Flexibilität eigener Erweiterungen. Die Gesamtkosten liegen deutlich unter denen einer vollständigen Eigenentwicklung, und das Risiko verteilt sich auf mehrere Schultern.