Von Excel zur echten Datenbank: Der Praxisweg für FM-Teams

Fast jedes FM-Team, das ich kenne, hat mindestens eine Excel-Datei, von der alle wissen, dass sie eigentlich eine Datenbank sein sollte. Sie heißt „Anlagenliste_final_v3.xlsx”, hat zwölf Tabellenblätter, drei verschiedene Datumsformate und genau eine Person im Haus, die versteht, warum Spalte AH ausgeblendet ist. Der Umstieg auf eine echte Datenbank klingt nach IT-Großprojekt. Richtig angegangen ist er eher eine gründliche Aufräumaktion mit klarem Fahrplan.

Warum die Tabelle irgendwann bricht

Excel ist am Anfang unschlagbar: schnell, flexibel, jeder kann es. Mit wachsender Anlagenzahl kippt das. Eine falsch eingetragene Zahl, ein gelöschtes Wartungsdatum oder eine kaputte Formel wirken banal und lösen später größere Folgefehler aus. Sobald mehrere Personen gleichzeitig arbeiten, werden Felder überschrieben, Verknüpfungen brechen, Zeilen verschwinden, und niemand kann mehr sagen, welche Version die aktuelle ist. Auf dem Handy oder Tablet im Feld ist die Tabelle ohnehin unbrauchbar, deshalb tragen Techniker Daten verspätet oder gar nicht ein.

Das Ergebnis sind zwei Sorten von Datenleichen. „Geister-Assets” stehen in der Liste, existieren aber physisch nicht mehr. „Zombie-Assets” sind real vorhanden, tauchen aber in keiner Liste auf. Beides kostet Geld, durch verpasste Wartung oder durch Budget für Anlagen, die es gar nicht mehr gibt.

Der Sechs-Phasen-Umzug

Die Migration von der Tabelle in eine strukturierte Datenbank lässt sich in sechs Phasen gliedern. Für ein mittleres Portfolio von rund 2.000 Anlagen ist sie realistisch in vier bis sechs Wochen zu schaffen:

1. Bestandsaufnahme (3 bis 7 Tage): Alle Excel-Dateien, ERP-Exporte und Papierlisten zusammentragen, die irgendwo im Haus Anlagendaten enthalten. Meistens ist das mehr, als man denkt.
2. Bereinigung und Deduplizierung (1 bis 3 Wochen): Doppelte Einträge zusammenführen, Schreibweisen vereinheitlichen, veraltete Datensätze archivieren statt löschen.
3. Feldzuordnung (3 bis 5 Tage): Festlegen, welches alte Excel-Feld in welches neue Datenbankfeld wandert, schriftlich dokumentiert und nicht im Kopf.
4. Pilotmigration (3 bis 5 Tage): Testlauf mit 50 bis 200 repräsentativen Anlagen, um Zuordnungsfehler früh zu erwischen.
5. Vollmigration (1 bis 3 Tage): Die restlichen Daten in Batches einspielen, sobald der Pilot sauber lief.
6. Nachkontrolle (2 Wochen): Die Fachbereiche prüfen die migrierten Daten und korrigieren, was beim Testlauf nicht auffiel.

Der wichtigste Merksatz aus der Praxis: Etwa 60 bis 70 Prozent der gesamten Zeit gehen in Bereinigung und Deduplizierung und nur der kleinere Teil in die technische Migration. Wer zuerst die Technik baut, um die Daten „später” zu bereinigen, macht aus einem Zwei-Wochen-Projekt zuverlässig eine Zwei-Monats-Reparaturaktion. Ein Zeitpuffer von 50 Prozent auf die erste Schätzung ist Erfahrungswert und keine Übervorsicht.

Was beim Aufräumen typischerweise auftaucht

Ein Beispiel aus der Praxis zeigt die Größenordnung. Bei einem Bestand von 500 Anlagen fanden sich bei der Bereinigung 78 doppelte Einträge, 34 Geister-Assets ohne physisches Gegenstück, 156 Anlagen ohne hinterlegten Standort und 203 Datensätze ohne Seriennummer. Dazu kamen 89 Einträge mit dem Platzhalter-Datum „01.01.2000”, weil irgendwann niemand das echte Datum kannte und das Feld trotzdem ausgefüllt werden musste. Wer im eigenen Bestand eine ähnliche Größenordnung erwartet, plant realistischer.

Für jede Anlage sollte die neue Datenbank mindestens diese Felder verbindlich vorschreiben: eine eindeutige ID, Bezeichnung, Kategorie, verantwortliche Person und Standort. Den Standort modelliert man als Hierarchie und nicht als Freitext. „Gebäude A → Etage 3 → Raum 305 → Arbeitsplatz 2” lässt sich filtern, auswerten und später mit Sensordaten verknüpfen, „3. Stock hinten rechts” nicht. Kategorien, Standorte, verantwortliche Personen und Anlagenstatus (in Betrieb, eingelagert, in Reparatur) legt man außerdem vor der Migration als feste Auswahllisten an. Sonst landet in der neuen Datenbank derselbe Wildwuchs wie in der alten Tabelle, nur besser formatiert.

Technik: CAFM-Software oder eigene Datenbank

Für den Wechsel gibt es im Kern zwei Wege. Etablierte CAFM- oder CMMS-Software bringt fertige Strukturen, Reporting und mobile Apps mit, kostet dafür laufend Lizenzgebühren und lässt sich nur begrenzt an die eigenen Prozesse anpassen. Der zweite Weg ist eine schlanke, selbst aufgesetzte Datenbank, etwa mit Supabase auf Postgres-Basis, kombiniert mit einem einfachen Formular oder einer kleinen Web-App für die Dateneingabe im Feld. Das erfordert mehr Aufbauarbeit. Dafür passt sich die Struktur exakt an die eigene Anlagenlogik an, und man hängt nicht von einem Anbieter-Update ab, wenn sich am nächsten Tag eine neue Anforderung ergibt. Welcher Weg passt, hängt weniger von der Unternehmensgröße ab als davon, ob im Haus die Zeit und das Interesse da sind, die Datenstruktur selbst zu pflegen.

Fazit

Der Umstieg von Excel auf eine echte Datenbank scheitert selten an der Technik. Meist rechnet man damit, dass die Migration schneller geht als die Bereinigung der eigenen Daten. Wer die sechs Phasen einplant, für die Bereinigung genug Zeit reserviert und die Datenstruktur, vor allem die Standort-Hierarchie, von Anfang an sauber anlegt, hat nach wenigen Monaten belastbare Daten statt einer Tabelle, die niemand mehr vollständig versteht. Organisationen, die diesen Weg konsequent gegangen sind, erreichen nach etwa drei Monaten systematischer Kontrolle rund 97 Prozent Datengenauigkeit. Diesen Wert hält keine noch so gepflegte Excel-Tabelle auf Dauer.

Quellen:

• 8 Reasons it’s time to move on from asset management spreadsheets
• Asset Data Migration & Cleansing: 2026 Guide