Software für die Flächensicherung
Für einen Projektentwickler von Hybridparks haben wir eine Fachanwendung entwickelt, die Katasterdaten, Eigentümerinformationen und Vertragsstände zusammenführt. So sieht das Team pro Projekt, wo die Flächensicherung steht und wo es als Nächstes handeln muss.
- Erneuerbare Energien
- Prozessdigitalisierung
- Geodaten & Kartenanwendungen
- Systemintegration & Datenarchitektur
- Flächensicherung
- Fachsoftware

- LAUFZEIT
- Seit Dezember 2024
- Vom ersten Datenimport bis zur laufenden Weiterentwicklung.
- ROLLE
- Discovery & Produktentwicklung
- Datenmodell, Fachlogik, Geodaten und Front/Backend eng verzahnt.
- TEAM
- 1 Product Owner, 3 Backend-DEVs, 1 Frontend-DEV
- Klein und crossfunktional.
- BRANCHE
- Erneuerbare Energien
- Projektentwicklung, Genehmigung, Bau sowie Betrieb von Hybridparks
- UMFANG HEUTE
- 35+ Flächenprüfungen
- Aktiv im laufenden Betrieb
- EINSATZ
- Operative Entscheidungsgrundlage
- Sicherungsstand und offene Flächen je Projekt im Blick
Für die Flächensicherung haben wir aus verteilten Kataster-, Eigentümer- und Vertragsdaten eine Fachanwendung gebaut. Sie berechnet den aktuellen Sicherungsstand eines Projekts nachvollziehbar und zeigt ihn an zentraler Stelle. Früher gab es individuelle Auswertungen, heute arbeitet der Fachbereich auf einer gemeinsamen Grundlage.
Wer einen Hybridpark entwickelt, muss die benötigten Flächen rechtzeitig sichern. Dass ein Flurstück grundsätzlich verfügbar ist, reicht dafür nicht aus. Eigentümer, Vertragsstände und unterschiedliche Sicherungsarten müssen zusammenpassen.
Diese Informationen lagen zuvor an verschiedenen Stellen. Katasterdaten kamen aus GIS-Dateien, Eigentümerinformationen aus Tabellen. Den aktuellen Stand einzelner Gespräche kannten die zuständigen Personen aus ihrem Arbeitsalltag.
Für eine belastbare Auswertung musste das Team die Daten immer wieder zusammenführen. Das kostete Zeit und machte Vergleiche schwierig. Hinzu kam ein fachliches Problem: Wer nur die gesicherten Flurstücke zählt, kann zu einem völlig anderen Ergebnis kommen als jemand, der die tatsächlich gesicherte Fläche betrachtet.
Der Projektentwicklung reichte es deshalb nicht zu wissen, wie viele Flurstücke bereits bearbeitet waren. Ihre eigentliche Frage lautete: Wo steht das Projekt wirklich, und auf welche offenen Flächen sollte sich das Team als Nächstes konzentrieren?
Wer für jede Statusfrage erst mehrere Datenquellen zusammenführen muss, verliert Zeit und Vergleichbarkeit.
Viele Einzelfälle, ein wiederkehrender Prozess
Früher musste das Team den Sicherungsstand für eine Auswertung aus mehreren Quellen zusammensetzen. Heute berechnet ihn die Anwendung nach denselben fachlichen Regeln und zeigt die relevanten Informationen zusammen an.
35+ Flächenprüfungen
laufen aktiv, mit eigenen Poolgebieten, Eigentümern und Vertragsständen.
17+ Geodaten-Ebenen
Poolflächen, Kabeltrassen, Fundamente, Zuwegungen und weitere Ebenen müssen je Projekt zusammen betrachtet werden.
1 Arbeitsansicht
Flurstücke, Eigentümer und Sicherungsstatus lassen sich gemeinsam auf der Karte prüfen.
Fachanwendung für die Flächensicherung: Vorgänge, Berechnung, Karte
Die Anwendung verbindet fachlich saubere Sicherungsvorgänge mit einer reproduzierbaren Flächenberechnung und einer Kartenansicht. Auf der Karte lässt sich der Status eines Projekts direkt prüfen.
Ein Flurstück ist nicht einfach „gesichert“
In der Praxis kann ein Flurstück mehreren Personen gehören und je nach Nutzung unterschiedliche Sicherungen brauchen. Ein Häkchen pro Flurstück hätte das nicht abgebildet.
Deshalb betrachtet die Anwendung die Kombination aus Flurstück, Eigentümer und Sicherungsart. Erst daraus entsteht der Status, den Auswertungen und Karte später anzeigen. Offene Fälle bleiben dabei sichtbar und gehen in keinem positiven Gesamtstatus unter.
Sicherungsstand: berechnet aus Kataster- und Projektdaten
In welchem Sicherungsstand die Fläche eines Poolgebiets steht, ermittelt die Anwendung direkt aus den Kataster- und Projektdaten. Auch Flurstücke, die nur teilweise in ein Poolgebiet hineinragen, berücksichtigt sie anteilig.
Die Auswertung hängt damit nicht mehr davon ab, wer sie erstellt oder welche Datei gerade im Umlauf ist. Gleiche Daten und gleiche Regeln führen zum gleichen Ergebnis.
Die Karte zeigt, wo die Flächensicherung noch offen ist
Die Karte zeigt mehr als Grundstücksgrenzen: Sie bildet den fachlichen Stand der Flächensicherung ab. Jedes Flurstück ist entsprechend seinem Status dargestellt. Ein Klick führt zu den zugehörigen Eigentümern und Sicherungsvorgängen. So ist direkt zu erkennen, an welchen Stellen ein Projekt bereits weit ist und wo noch Klärungsbedarf besteht.
„Als Vertragsmanager muss ich jederzeit an die Bereichsleiter und Geschäftsführer reporten können, wie weit ein Projekt gesichert ist. Mit dem Flächensicherungsmodul habe ich diesen Stand gesammelt an einer Stelle, statt ihn jedes Mal aus Mails und Einzeltabellen zusammenzusuchen. Ich sehe sofort, welche Vorgänge offen sind und mein gesamter Fachbereich arbeitet mit den gleichen, korrekten Zahlen.“
Unser Vorgehen: von der Discovery zur Fachsoftware
Discovery: Fachlichkeit klären → Regeln und Datenmodell entwickeln → Change Management: Neuen Prozess für den Arbeitsalltag modellieren → Delivery
Unser durchgehendes Prinzip: Bevor wir einen bestehenden Workflow automatisieren, klären wir, welche Entscheidung die Software zuverlässig unterstützen muss.
Fortschritt der Flächensicherung: Fläche, Flurstücke oder Vorgänge?
„Wie weit ist die Flächensicherung?“ klingt zunächst nach einer einfachen Kennzahl. In der Praxis hängt die Antwort davon ab, ob man Fläche, Flurstücke oder einzelne Sicherungsvorgänge betrachtet.
Wir haben deshalb nicht vorschnell einen einzigen Fortschrittswert festgelegt. Gemeinsam mit der Fachseite haben wir geklärt, welche Perspektiven für die tägliche Arbeit relevant sind. Die Anwendung zeigt nun mehrere Sichtweisen nebeneinander.
Das macht die Oberfläche etwas erklärungsbedürftiger. Es verhindert aber, dass eine einfache Kennzahl eine falsche Sicherheit erzeugt.
Unklare Geodaten sichtbar machen und fachlich klären
Geodaten kommen nicht immer in einem Zustand an, in dem eine Software eindeutig entscheiden kann. Ein Projekt kann beispielsweise mehrere Versionen eines Poolgebiets enthalten. Welche davon fachlich gilt, lässt sich nicht zuverlässig aus technischen Merkmalen ableiten.
Auf eine vermeintlich clevere Heuristik haben wir deshalb verzichtet. Wir haben solche Fälle sichtbar gemacht und mit den zuständigen Fachleuten geklärt.
Dieses Muster wenden wir auch in anderen Fachsoftware-Projekten an: Wir automatisieren, wo die Regel klar ist, und fragen nach, wo Fachwissen entscheidet.
Wir haben die Fachregeln vor der Oberfläche modelliert
Die Karte war der sichtbare Teil des Projekts, der Ausgangspunkt war sie nicht. Zuerst mussten Begriffe und Regeln sauber feststehen: Was genau ist ein Sicherungsvorgang? Wann gilt ein Flurstück als gesichert? Wie gehen wir mit mehreren Eigentümern um? Welche Fläche zählt zu welchem Projekt? Erst danach haben wir daraus eine Oberfläche gebaut.
Das kostet zu Beginn mehr Denkarbeit, als direkt mit Screens und Formularen zu starten. Dafür bildet die Software anschließend den tatsächlichen Prozess ab und geht über die Struktur der Tabellen hinaus, die das Team vorher verwendet hat.
Anwendung
Kotlin
Spring Boot
Preact
Geodaten
PostgreSQL
OpenLayers
Betrieb
AWS
Flyway

