Kabel und Anschlüsse an Servern
Digitalisierung und Dateninfrastruktur 4 Min Lesezeit

Datenbank-Aufbau für FM ohne IT-Budget: Wie ich mit PostgreSQL und Supabase angefangen habe

Inhalt
  1. Warum Excel im FM irgendwann an seine Grenzen stößt
  2. Der Einstieg: PostgreSQL und warum ich mich dafür entschieden habe
  3. Meine Datenbankstruktur
  4. Was ich aus dem Prozess gelernt habe
  5. Was das Ganze kostet
  6. Wann eine Datenbank reicht und wann ihr doch ein CAFM braucht
  7. Mein konkreter Tipp

Vor zwei Jahren hatte ich ein Problem: 14 Excel-Dateien mit Anlagendaten, Wartungsintervallen, Kostenzuordnungen und Vertragsdetails, in verschiedenen Versionen auf verschiedenen Laufwerken. Kollege A hatte die aktuelle Kostentabelle, Kollege B die aktuelle Anlagenliste, und keiner wusste, wessen Version wirklich aktuell war. Jeder FM-Projektleiter kennt diese Situation.

Meine Lösung war keine große IT-Initiative, kein sechsstelliges Budget und kein externer Berater. Ich habe mir an einem Wochenende PostgreSQL beigebracht und eine Datenbank aufgesetzt. Heute laufen alle meine Projektdaten darüber, und ich würde nie wieder zu Excel zurückgehen.

Warum Excel im FM irgendwann an seine Grenzen stößt

Excel ist ein fantastisches Tool für Analysen, schnelle Berechnungen und Einzeldateien. Als Datenhaltungssystem für operatives FM taugt es nicht.

Das sehe ich immer wieder: Mehrere Personen arbeiten an verschiedenen Versionen derselben Datei. Formeln werden versehentlich überschrieben. Ab 10.000 Zeilen wird Excel langsam und unhandlich. Verknüpfungen zwischen Anlagen, Verträgen und Kosten laufen über SVERWEIS-Ketten, die bei der kleinsten Änderung brechen.

Bei den meisten FM-Teams ist dieser Punkt früh erreicht: sobald mehr als drei Personen regelmäßig mit denselben Daten arbeiten, sobald Daten aus verschiedenen Quellen zusammengeführt werden müssen oder sobald historische Vergleiche über mehr als ein Jahr nötig sind.

Der Einstieg: PostgreSQL und warum ich mich dafür entschieden habe

Als ich anfing, hatte ich keine Datenbankerfahrung. Mein Auswahlprozess war pragmatisch: Welche Datenbank ist kostenlos, gut dokumentiert und hat eine Community, in der ich Antworten auf Anfängerfragen finde?

PostgreSQL erfüllt alle drei Kriterien. Es ist Open Source, seit Jahrzehnten bewährt, hat eine riesige Community und unzählige Tutorials. Die Einstiegshürde liegt höher als bei Excel, ihr müsst SQL-Grundlagen lernen. Dazu gehören SELECT, INSERT, UPDATE und JOIN, vier Befehle, deren Syntax auf eine Karteikarte passt.

Für den Einstieg empfehle ich Supabase, eine Plattform, die PostgreSQL als Managed Service anbietet. Der Einstieg ist kostenlos, es gibt eine grafische Oberfläche zum Tabellenanlegen und eine REST-API, die ihr sofort für Dashboards oder Webapps nutzen könnt. Die Datenbank läuft in der Cloud, das vereinfacht den Start drastisch: kein Server-Setup, keine Linux-Kenntnisse.

Wer die Daten lieber auf eigener Infrastruktur hat, installiert PostgreSQL lokal oder auf einem kleinen Server. Mit Docker dauert das circa 30 Minuten.

Meine Datenbankstruktur

Meine FM-Datenbank besteht aus fünf miteinander verknüpften Kerntabellen.

Die Tabelle „Standorte” enthält alle betreuten Objekte mit Name, Adresse, Fläche, Nutzungsart und Vertragsbeginn. Die Tabelle „Anlagen” enthält die technischen Anlagen pro Standort mit Anlagentyp, Hersteller, Baujahr, letzter Wartung und nächster Prüfung. In „Verträge” steht die Servicestruktur: Vertragspartner, Gewerk, Laufzeit, Kosten, Kündigungsfrist. „Tickets” speichert alle Störmeldungen und Serviceaufträge mit Anlage, Standort, Beschreibung, Priorität, Bearbeitungszeit und Status. „Kosten” erfasst alle FM-Kosten: Rechnungen, Gewerk, Kostenstelle, Zeitraum.

Den Mehrwert machen die Verknüpfungen aus. Eine einfache SQL-Abfrage zeigt mir alle Kälteanlagen am Standort München, deren letzte Wartung mehr als sechs Monate zurückliegt, samt Vertragskosten und Anzahl der Störmeldungen im letzten Quartal. In Excel wäre das eine Verkettung aus SVERWEIS, ZÄHLENWENN und Pivot-Tabellen, in SQL sind es fünf Zeilen.

Was ich aus dem Prozess gelernt habe

Lektion 1: Startet mit den Daten, die ihr habt. Meine ersten Tabellen waren direkte Importe aus den Excel-Listen, mit allen Fehlern und Lücken. Das ist in Ordnung. Der Umstieg auf eine Datenbank verbessert die Datenqualität nicht von selbst, aber er macht Inkonsistenzen sichtbar, und das ist der erste Schritt zu sauberen Daten.

Lektion 2: Weniger Tabellen, mehr Verknüpfungen. Am Anfang wollte ich für alles eine eigene Tabelle und hatte nach zwei Wochen zehn, zu komplex. Ich habe auf fünf Kerntabellen zurückgebaut und dafür die Verknüpfungen sauber gemacht. Einfachheit schlägt Vollständigkeit.

Lektion 3: Die Datenerfassung muss einfach sein. Die schönste Datenbank ist nutzlos, wenn niemand Daten eingibt. Mit Supabase habe ich eine simple Eingabemaske gebaut: drei Klicks für eine neue Störmeldung, fünf Felder statt fünfzehn. Die Akzeptanz bei den Kollegen stieg sofort, als die Eingabe schneller ging als das Ausfüllen der alten Excel-Vorlage.

Lektion 4: SQL lernen dauert weniger lang als gedacht. Ich habe einen Online-Kurs gemacht, zehn Stunden über drei Wochenenden, und konnte danach die wichtigsten Abfragen selbst schreiben. Für komplexere Sachen frage ich die KI. Claude ist erstaunlich gut darin, SQL-Abfragen aus einer Beschreibung in natürlicher Sprache zu erzeugen.

Was das Ganze kostet

So sieht die Kostenaufstellung meines Setups aus. PostgreSQL ist kostenlos (Open Source). Supabase ist für den Einstieg kostenlos, die Pro-Version mit mehr Speicher und Backups kostet rund 23 Euro pro Monat. Meine Arbeitszeit lag bei circa 40 Stunden für den initialen Aufbau, verteilt über einen Monat, die laufende Pflege kostet zwei bis drei Stunden pro Woche für Datenbereinigung und kleinere Anpassungen. Das Dashboard obendrauf mit Apache Superset ist ebenfalls kostenlos.

Im ersten Jahr kommen so rund 280 Euro für Supabase Pro plus meine Arbeitszeit zusammen (Richtwert, umgerechnet und gerundet). Eine CAFM-Lösung mit demselben Funktionsumfang hätte ein Vielfaches gekostet und wäre in drei Monaten nicht einsatzbereit gewesen.

Wann eine Datenbank reicht und wann ihr doch ein CAFM braucht

Mein Setup ersetzt kein CAFM für einen Konzern mit 50 Standorten und 500 Nutzern. Es ist eine pragmatische Lösung für FM-Teams und Projektleiter, die ihre Daten in den Griff bekommen wollen, ohne auf die IT zu warten.

Habt ihr mehr als 20 Nutzer, die gleichzeitig mit dem System arbeiten, regulatorische Anforderungen an Audit-Trails und Zugriffsprotokollierung oder braucht ihr ein vollintegriertes Flächenmanagement, dann braucht ihr ein echtes CAFM.

Für alles dazwischen reicht eine PostgreSQL-Datenbank mit einem Dashboard obendrauf: für den Projektleiter mit drei Standorten und zehn Kollegen, für die FM-Abteilung, die ihre Vertragsdaten sortieren will, für den Objektleiter, der seine KPIs endlich verlässlich tracken möchte.

Mein konkreter Tipp

Nehmt eure wichtigste Excel-Datei, die mit den meisten Problemen. Erstellt einen kostenlosen Supabase-Account, importiert die Daten in eine Tabelle und schreibt eure erste SQL-Abfrage. Denkt ihr nach zwei Stunden „Warum habe ich das nicht früher gemacht?”, wisst ihr, dass der Weg stimmt.

Wer von euch arbeitet noch komplett in Excel, und wer hat den Sprung zur Datenbank schon gemacht?

Teil der Serie Daten und Datenbanken.