Software für Projektentwickler von Hybridparks

Wir haben die Anwendung nach Fachbereichen geschnitten. Flächenscan, Vorprüfung, Katasterdaten, Vertragserfassung, Vertragsgenerierung, Fristen, Projektzuordnung, Auswertung und die Geodatenbereiche stehen als eigenständige Kontexte nebeneinander. Die Fachlogik liegt in einer Schicht, die weder Datenbank noch Framework kennt. Beides wird von außen angebunden.

Der Sicherungsstatus wird dort erfasst, wo er entsteht: je Eigentümer und Flurstück, in dreizehn Abstufungen. Alles darüber leitet das System ab. Dazu gehören der Stand eines Flurstücks mit mehreren Eigentümern, der Stand einer Eigentümergemeinschaft und der Fortschritt eines Projekts nach Fläche, nach Eigentümergemeinschaften und nach Flurstücken. Bei widersprüchlichen Angaben gilt die vorsichtige Regel: Der schlechteste Status setzt sich durch.

Ein gepflegter Gesamtstatus ist am Tag nach der Pflege falsch, ein berechneter ist es nie. Das zählt, wenn ein Investment-Komitee wissen will, wie viel Fläche unter den geplanten Anlagenstandorten gesichert ist. Die Anwendung wertet dafür die tatsächlichen Standortflächen aus und nicht die Poolfläche.

Aus einem Vertrag werden Pflichten gelesen: Zahlungen, Informationspflichten, Optionen, Rückbau. Jede Pflicht bekommt eine Terminierung, einmalig oder wiederkehrend. Daraus erzeugt das System die einzelnen Fristen samt Kritikalität. Projektereignisse wie Baubeginn oder Inbetriebnahme sind eigene Objekte. Verschiebt sich eines, berechnet das System alle davon abhängigen Fristen neu.

Eine Outlook-Erinnerung hält nicht über die Laufzeit eines Nutzungsvertrags. Sie hängt an einer Person, überlebt keinen Rollenwechsel und kennt den Grund nicht, aus dem sie existiert. Eine abgeleitete Frist kennt ihn. Sie lässt sich zuweisen, überwachen und, wenn nötig, erklären.

Wie der Sicherungsstand war, als die Finanzierung beantragt wurde, beantwortet die Anwendung selbst. Verträge, Fristen, Vorprüfungen und Eigentümerdaten behalten jeden Stand, den sie je hatten. Überschrieben wird nichts. Projektereignisse führen ihre Verschiebungen mit Datum, Kommentar und Verfasser mit. So lässt sich nachvollziehen, was galt und warum es geändert wurde. In einer Due Diligence ist das der Unterschied zwischen Behauptung und Nachweis.

Damit liegt auch der Weg jedes Projekts über die Jahre vor. Daraus ließe sich ableiten, wie lange Flächensicherung dauert, woran sie hängt und welche:r Eigentümer:in perspektivisch als Erstes angesprochen werden sollte.

Flurstücke, Eigentümerdaten und Projektflächen liegen räumlich indiziert in derselben Datenbank wie die Verträge. Amtliche Katasterdaten werden importiert und fortgeschrieben, Projektgeometrien als Layer hochgeladen. Für die Layertypen wie Pool, Standorte, Zuwegungen, Kabeltrassen und Ausgleichsflächen gibt es inzwischen ein eigenes Datenmodell, jeweils mit eigenem Sicherungsstatus. Die Karte zeigt damit den Stand, keinen Ausschnitt.

Große Geodateien brauchen einen eigenen Uploadweg aus dem vorherrschenden GIS. Und die Auswertung über Anlagenstandorte statt über Poolflächen musste fachlich sauber definiert sein, bevor sie rechnen konnte.

Woher die Geodaten hinter diesen Karten kommen, beschreibt der zweite Showcase: Import, Verarbeitung, Auslieferung. → Zum Showcase Geodaten-Plattform

Den alten Prozess haben wir nicht nachgebaut, wir haben einen neuen mitgestaltet. Gemeinsam mit der EEF haben wir dafür geklärt, wer einen Vertrag erfasst, wer ihn freigibt, wer eine Frist verantwortet und wer welche Eigentümerdaten sehen darf. Das lief parallel zur Entwicklung, weder davor noch danach. Das Ergebnis steht heute als Rollen- und Rechtekonzept im System: Flächensicherung, Vertragsmanagement, interne Mitarbeitende und Administration sehen jeweils das, wofür sie zuständig sind.

67 automatisierte Abnahmetests fahren die zentralen Abläufe über alle Rollen hinweg durch: Vertragserfassung, Nachträge, Fristen, Kartenansichten, Zugriffsrechte. Vor jeder größeren Änderung klären wir, welche Tests sie braucht. 201 versionierte Migrationen halten das Datenmodell nachvollziehbar.

Jede Änderung kostet dadurch Testarbeit. Dafür sind über 4.000 Änderungen an einem System entstanden, das täglich produktiv genutzt wird, ohne dass ein Release zum Ereignis wird.

Für den nächsten Ausbauschritt haben wir vier geplante Module als klickbare Prototypen vorgelegt, ohne Umweg über ein Konzept: Erinnerungskanäle für Fristen, Grundbuch und Checkliste im Vertragsmodul, Eigentümer-Stammdaten, Pachtenrechner. Anhand dieser Prototypen fiel die Entscheidung über Roadmap und Budget. Offene Fragen wurden dabei ausdrücklich benannt.