Nicht jeder Systemwechsel braucht eine Ausschreibung. Aber jeder braucht ein grundlegendes Anforderungsmanagement mit Anforderungen, die stimmen und eine Migration, die nichts verliert.
Wir erheben, strukturieren und verwalten die Anforderungen an Ihr Geodatensystem — und begleiten die Migration von Ihren Altdaten in die neue Umgebung. Ob Sie auf QGIS und PostGIS umsteigen, ein proprietäres Altsystem ablösen oder gewachsene Insellösungen zusammenführen.
Erstgespräch vereinbaren →
Kennen Sie das?
-
Sie steigen auf Open Source um. QGIS und PostGIS sollen ein lizenzpflichtiges System ablösen — und jetzt stellt sich heraus, dass niemand genau aufschreiben kann, was das Altsystem eigentlich alles tut.
-
Ihr Altsystem läuft aus. Der Hersteller stellt die Pflege ein, der Vertrag endet, oder die letzte Person, die das System wirklich kennt, geht in Pension.
-
Ihre Daten liegen an fünf Orten. Eine Fachdatenbank, ein Verzeichnis mit Shapefiles, eine Access-Datei als Auftragsverwaltung, ein Excel-Tracker und das Wissen im Kopf von zwei Leuten.
-
Sie führen mehrere Fachanwendungen parallel ein. Jede für sich sinnvoll — zusammen ergeben sie keine Architektur, und die Schnittstellen verhandelt jedes Projekt neu.
-
Sie haben ein Angebot bekommen und wissen nicht, ob es passt. Weil die Anforderung, an der es sich messen ließe, nie geschrieben wurde.
-
Sie stehen vor einer Ausschreibung. Dann ist Anforderungsmanagement der Schritt davor — was danach kommt, steht auf unserer Seite zur Ausschreibung und Vergabebegleitung.
Wenn Ihnen das bekannt vorkommt: Versäumt hat das niemand. Anforderungen aufzuschreiben ist Arbeit, die erst dringend wird, wenn es dafür zu spät ist — und für die neben dem laufenden Betrieb selten jemand freigestellt wird.
Was Sie davon haben
-
Sie wissen, was Sie brauchen — vor der ersten Rechnung. Nicht als Wunschliste, sondern als überprüfbarer Katalog, gegen den man ein Angebot, eine Konfiguration oder eine Abnahme halten kann.
-
Ihr Fachbereich wird entlastet, nicht ersetzt. Ihre Leute liefern in Workshops das Wissen; das Aufschreiben, Ordnen und Nachhalten übernehmen wir. Es bindet niemanden über Monate.
-
Sie verlieren bei der Migration nichts. Weil vorher gemessen wurde, was da ist — statt hinterher zu suchen, was fehlt.
-
Ihr Wissen bleibt im Haus. Was heute in Köpfen und gewachsenen Handgriffen steckt, steht danach in einem Dokument, das auch in fünf Jahren noch jemand lesen kann.
-
Sie können jederzeit abbrechen oder wechseln. Anforderungen und Datenmodell gehören Ihnen — sie sind nicht an ein Produkt und nicht an uns gebunden.
Anforderungsmanagement heißt bei uns: eine Kette, die hält
Die meisten Anforderungskataloge sterben in dem Moment, in dem das Projekt beginnt — weil niemand sie mehr wiederfindet. Wir bauen sie so, dass jede Anforderung von der Beobachtung im Fachbereich bis zum Abnahmetestfall rückverfolgbar bleibt:
-
Beobachtung — Wir schauen zu, wie tatsächlich gearbeitet wird. Nicht wie es im Prozesshandbuch steht.
-
User Story — Jede Anforderung wird aus der Sicht derer formuliert, die damit arbeiten: „Als Bearbeiterin sehe ich …“, „Als System biete ich …“.
-
Klassifizierung — K.O., Hoch, Mittel, Gering. Ohne diese Einstufung wiegt jede Anforderung gleich schwer, und dann lässt sich nicht priorisieren.
-
Gewichtung — Anforderungen, die für Ihren Betrieb kritisch sind, bekommen zusätzliches Gewicht. Nachvollziehbar begründet, nicht nach Bauchgefühl.
-
Zieldatenmodell — Jede Anforderung, die Daten berührt, landet im Modell. So entsteht kein Katalog, der am Datenmodell vorbeiredet.
-
Abnahmetestfall — Zu jeder Muss-Anforderung gehört ein Test, der sie beweist. Sonst ist „erfüllt“ eine Meinung.
-
Betrieb — Was sich im laufenden Betrieb ändert, wird an derselben Anforderung nachgeführt. Der Katalog bleibt lebendig statt ein Projektartefakt zu werden.
In einem aktuellen Verfahren sind daraus 294 funktionale und 70 nicht-funktionale Anforderungen in 26 Funktionsgruppen geworden — jede einzeln klassifiziert, gewichtet und bepreisbar. Die Größenordnung ist kein Selbstzweck: Sie ist der Unterschied zwischen „das System soll Leitungen verwalten“ und einer Aussage, die jemand vertraglich zusagen kann.
Die Anforderung, die niemand nennt
Die kritischen Anforderungen stehen selten in Fragebögen. Sie zeigen sich beim Zuschauen: der Handgriff, den jemand seit zwölf Jahren macht, ohne ihn je erwähnt zu haben. Die Sonderregel für eine Netzregion. Das Feld, das offiziell nicht mehr benutzt wird und an dem drei Auswertungen hängen.
Deshalb arbeiten wir vor Ort und mit echten Daten: mitschauen bei der Bearbeitung, echte Aufträge durchspielen, die Sonderfälle einsammeln, die im Regelprozess nicht vorkommen. Was wir dabei finden, bringen wir in die Sprache zurück, die Ihre Leute verwenden — nicht in unsere.
Wenn es nicht um ein System geht, sondern um eine Landschaft
Nicht jedes Vorhaben ist eine Ablöse. Häufig laufen mehrere Fachapplikationen nebeneinander, jede mit eigener Geschichte, und die eigentliche Aufgabe ist, sie als Landschaft weiterzuentwickeln statt jede für sich zu optimieren. Diese Rolle — Business Analyse und Product Ownership — übernehmen wir für Netzausbauprojekte von Übertragungsnetzbetreibern: über Planung, Genehmigung, Bau und Betrieb hinweg, onshore wie offshore.
-
Bedarf erheben und strukturieren — Anforderungen aus den Fachbereichen aufnehmen, priorisieren und mit IT und externen Partnern abstimmen.
-
Prozesse und Systeme modellieren — bestehende Abläufe und die daran hängenden Anwendungen sichtbar machen und benennen, wo Digitalisierung wirklich etwas bringt.
-
Zielbild und Zielarchitektur — SOLL-Prozesse definieren, eine fachliche Zielarchitektur ableiten, Lösungsoptionen bewerten und als Entscheidungsvorlage aufbereiten.
-
Schnittstellen und Datenmodelle — festlegen, welche Anwendung welche Daten führt und wie sie sie weitergibt. Das ist die Arbeit, die sonst jedes Projekt für sich neu verhandelt.
-
Einführung begleiten — Konzepte und Prototypen fachlich prüfen, Tests und Abnahmen durchführen, Roll-out, Schulungsunterlagen und Wissenstransfer in die Fachbereiche.
-
Nachvollziehbarkeit sichern — jede fachliche Entscheidung bleibt dokumentiert und auffindbar, auch wenn Projekte und Personen wechseln.
Methodisch arbeiten wir mit User-Story-Modellierung und BPMN, in agilen wie in hybriden Projektumgebungen — nach dem, was bei Ihnen gelebt wird, nicht nach Lehrbuch. Ihr Gewinn: Die Rolle zwischen Fachbereich und IT ist besetzt, ohne dass Sie dafür eine Stelle schaffen müssen.
Aktuell begleiten wir in dieser Rolle bei 50Hertz die Einführung eines GIS für Offshore-Netzausbauprojekte sowie die Weiterentwicklung und Einführung der Bau-IT in laufenden und beginnenden Bauprojekten.
Migration: erst messen, dann bewegen
1 — Wir zählen, bevor etwas bewegt wird
Bevor irgendetwas migriert wird, wird gezählt: Objektmengen, Geometrietypen, Attributbelegung, Dubletten, Verwaisungen, Wertebereiche, Historienstände. Ihr Gewinn: Sie erfahren die schlechten Nachrichten am Anfang, wo sie noch billig sind.
2 — Wir bauen das Zielmodell aus Ihren Anforderungen
Das neue Modell entsteht aus Ihren Anforderungen, nicht aus der Struktur des Altsystems. Offen, dokumentiert und OGC-konform — mit einer Abbildungsvorschrift, die jedes Quellfeld einem Zielfeld zuordnet oder begründet, warum nicht. Das Zielbild jeder Migration sind Mustergeodaten: das standardkonforme Referenzmodell, in das wir Ihren Bestand überführen. Ihr Gewinn: Sie schleppen die Altlasten nicht mit ins neue System.
3 — Wir migrieren mehrfach zur Probe
Mindestens zwei Durchläufe je Bereich, jeder mit Prüfprotokoll: Vollständigkeit, Geometrietreue, Sachdatenabgleich, definierte Fehlerklassen mit Schwellenwerten. Ihr Gewinn: Die Produktivmigration ist der dritte Durchlauf, nicht der erste.
4 — Wir schalten um und halten den Rückweg offen
Regional oder fachlich geschnitten, mit begrenztem Freeze-Fenster, getestetem Rollback und Parallelbetrieb, solange es nötig ist. Ihr Gewinn: Ihr Betrieb steht nicht still, und ein Fehlschlag kostet Stunden statt Wochen.
5 — Wir nehmen gegen Testfälle ab und bleiben danach erreichbar
Abgenommen wird gegen die Testfälle aus dem Anforderungskatalog, nicht gegen einen Gesamteindruck. Danach eine Phase erhöhter Aufmerksamkeit, in der die Fälle auftauchen, die im Test nie vorkommen. Ihr Gewinn: „Fertig“ ist ein Zustand mit Kriterien, kein Termin. Was danach kommt — die laufende Aufbereitung, Fortführung und Kartenproduktion — steht auf Betrieb und Datenpflege.
Beispiel: Umstieg auf QGIS und PostGIS
Der Wechsel von einem proprietären System — ArcGIS, GEOgraf, eine CAD-gestützte Bestandsführung — auf QGIS mit PostGIS ist der Fall, nach dem wir am häufigsten gefragt werden. Unsere ehrliche Kurzfassung:
Was gut funktioniert: Erfassung und Bearbeitung, Kartografie und Plandarstellung, Analyse, native Datenhaltung in PostGIS ohne ETL-Zwischenschicht, offene Formate, On-Premise-Betrieb als Normalfall statt als teure Ausnahme.
Was Konfiguration oder Entwicklung braucht: revisionssichere Historisierung, eine in den Bestand integrierte Auftrags- und Fortführungsverwaltung, der automatisiert erzeugte Längsschnitt, durchgängige 3D-Führung mit Z-Koordinate, plangenaue kartografische Textplatzierung, feingranulare Rechte- und Sperrkonzepte. Alles machbar — aber es muss beschrieben, klassifiziert und kalkuliert werden, sonst wird es zur Überraschung.
Wo der eigentliche Gewinn liegt: Historisierung, Datenmodell und Regelwerk liegen in der Datenbank, nicht im Client. Damit überleben sie jeden Werkzeugwechsel — und Sie können den Dienstleister wechseln, ohne Ihre Daten zu verlieren. Die Lizenzkosten sinken; der Anteil für Dienstleistung und Entwicklung steigt. Rechnen Sie deshalb Gesamtkosten über die Laufzeit, nicht Lizenzpreise.
Und Ihre externen Vermessungsbüros? Entweder sie liefern weiter im gewohnten Format und Sie definieren eine belastbare Übernahmeschnittstelle mit Prüflogik — oder sie bekommen selbst einen Arbeitsplatz auf dem Zielmodell. Beides gehört in die Anforderungen und sollte nicht als Detail durchrutschen. Wo die Aufnahme im Feld strukturiert erfolgen soll, ist MoversSurvey unser Baustein dafür: Objekte und Metadaten werden offlinefähig nach Ihrem Datenmodell erfasst — mit Pflichtfeldern und Wertelisten, statt als Freitext, den später jemand interpretieren muss.
Was Sie danach in der Hand halten
- Einen klassifizierten Anforderungskatalog als User Stories, gewichtet und rückverfolgbar
- Ein dokumentiertes Zieldatenmodell, das Ihnen gehört
- Einen Migrationsplan mit Iterationen, Prüfkriterien und Fehlerklassen
- Den Profiling-Bericht Ihrer Altdaten — oft der erste vollständige Blick auf den eigenen Bestand
- Abnahmetestfälle je Funktionsgruppe
- Eine Abbildungsvorschrift von jedem Quell- auf jedes Zielfeld
- Ein Onboarding-Konzept, das an Ihren Arbeitsabläufen ansetzt statt an Softwarefunktionen
Eine Migration ist der Übergang in den nächsten Geodatenzyklus: Was dabei mitkommt, entscheidet darüber, ob der neue Bestand mit dem alten vergleichbar bleibt.
Wie wir arbeiten
An Ihrem Vorhaben arbeitet ein kleines Team aus Wien. Die Person, die Ihre Anforderungen aufnimmt, prüft später auch das Migrationsprotokoll — so gehen zwischen Analyse und Umsetzung keine Informationen verloren.
Wir arbeiten auf Ihrer Seite. Das heißt auch: Wir sagen Ihnen, wenn eine Anforderung, die Sie unbedingt wollen, den Aufwand nicht wert ist. Und wenn ein Vorhaben in der geplanten Form nicht funktioniert, hören Sie das von uns früh — nicht in der Abnahme.
Häufige Fragen
Wir haben doch schon ein Lastenheft. Reicht das nicht?
Oft nicht ganz. Die typische Lücke ist die Klassifizierung: Wenn alle Anforderungen gleich gewichtet sind, kann niemand priorisieren und kein Anbieter sinnvoll kalkulieren. Wir schauen uns Ihr Dokument an und sagen Ihnen, ob es trägt — das ist manchmal ein kurzer Termin und kein Projekt.
Können Sie auch nur die Migration übernehmen?
Ja. Datenprofiling und ein Migrationskonzept lassen sich unabhängig beauftragen — auch dann, wenn die Umsetzung bei Ihrem Systemanbieter liegt. Wir prüfen dann auf Ihrer Seite mit.
Wie viel Zeit kostet uns das intern?
Wir brauchen Ihren Fachbereich für Workshops, das Mitschauen im Tagesgeschäft und die Reviews — in Terminen, die sich planen lassen. Alles dazwischen läuft bei uns. So bleibt die Belastung für Ihr Team überschaubar, auch wenn das Vorhaben über Monate läuft.
Müssen wir alles auf einmal ablösen?
Nein, und meistens raten wir davon ab. Der realistische Weg ist die Ablöse in Schichten: erst die führende Datenhaltung, dann die Arbeitsplätze, zuletzt die angeschlossenen Auskunfts- und Websysteme. Koexistenz auf Zeit ist kein Scheitern, sondern Risikomanagement.
Was ist mit den Anwendern, die seit fünfzehn Jahren anders arbeiten?
Die brauchen keine Softwareschulung, sondern ihre Arbeitsabläufe zurück: vorbereitete Projektvorlagen, angepasste Werkzeugleisten, Erfassungsformulare, Snapping- und Topologieregeln, die dieselbe Sorgfalt erzwingen wie das Altsystem. Deshalb ist das Onboarding-Konzept bei uns Teil des Anforderungsmanagements und nicht der Betriebsphase.
Wie lange dauert das?
Die Anforderungsaufnahme hängt an der Zahl der Beteiligten und der Zahl der Sonderfälle, die Migration an Ihrer Datenqualität. Beides schätzen wir nach einem ersten Blick auf Ihren Bestand ein — nicht vorher.
Und wenn daraus eine Ausschreibung wird?
Dann ist die Vorarbeit schon getan. Ein klassifizierter Anforderungskatalog ist genau das, was ein Leistungsverzeichnis braucht — und aus dem Zieldatenmodell wird der Migrationsteil des Lastenhefts. Wie es dann weitergeht, steht auf unserer Seite zur Ausschreibung und Vergabebegleitung.
Lesetipps
Sprechen wir über Ihren Bestand
Erzählen Sie uns, womit Sie heute arbeiten und was nicht mehr trägt. Wir sagen Ihnen im Erstgespräch, wo wir ansetzen würden — und ob Sie uns dafür überhaupt brauchen.
Erstgespräch vereinbaren →
Ausschreibung und Vergabebegleitung →
Betrieb und Datenpflege →
MoversSurvey kennenlernen →
Geodaten vom Feld bis zur Entscheidung – standardisiert, versioniert & KRITIS-tauglich.
