Baselining im FM: Die 7 häufigsten Fehler – und wie ihr sie vermeidet

In meinem ersten Baselining-Projekt habe ich fast jeden Fehler gemacht, der möglich ist. Daten drei Monate lang gesammelt ohne sie zwischendurch zu validieren. Den Auftraggeber zu spät eingebunden. Versucht, jeden einzelnen Prozess zu erfassen statt mich auf die wesentlichen zu konzentrieren. Am Ende hatte ich einen Ordner voller Daten und einen Kunden, der gefragt hat: „Und was bedeutet das jetzt konkret?”

Seitdem habe ich einige Baselining-Projekte abgeschlossen – manche erfolgreich, manche mit Lehrgeld. Hier sind die sieben Fehler, die ich am häufigsten sehe – bei mir selbst und bei Kollegen.

Fehler 1: Baselining ohne klares Ziel starten

Der häufigste und teuerste Fehler. „Wir machen mal ein Baselining” ist kein Ziel. Baselining ist eine Methode, kein Selbstzweck. Bevor ihr anfangt, muss klar sein: Was soll am Ende herauskommen? Sollen Kosten verglichen werden? Sollen Prozesse standardisiert werden? Soll eine Vertragsgrundlage für eine Neuausschreibung geschaffen werden?

Je nachdem, welches Ziel ihr verfolgt, erfasst ihr andere Daten, in anderer Tiefe, über einen anderen Zeitraum. Ein Baselining für eine Neuausschreibung braucht andere Daten als ein Baselining für interne Prozessoptimierung.

Mein Ansatz: Ich definiere vor Projektstart drei bis fünf konkrete Fragen, die das Baselining beantworten soll. „Was kosten uns die technischen Gewerke pro Standort im Vergleich?” ist eine gute Frage. „Wie ist die Ist-Situation?” ist keine – weil sie zu offen ist und zu einem Baselining führt, das alles erfasst und nichts beantwortet.

Fehler 2: Zu viele Daten erfassen wollen

Der Perfektionismus-Fehler. Die Versuchung ist groß, im Baselining alles zu erfassen – jeden Prozess, jede Anlage, jede Kostenstelle, jede Personaleinsatzstunde. Das Ergebnis: Ein Projekt, das sich über Monate zieht, ohne dass verwertbare Ergebnisse vorliegen.

In meiner Erfahrung liefern 20 Prozent der Daten 80 Prozent der Erkenntnisse. Die Betriebskosten nach Gewerk und Standort, die Anlagenverfügbarkeit der kritischen Systeme und die Personalkapazitäten – damit lässt sich in den meisten Fällen bereits die Kernfrage beantworten.

Mein Prinzip: Startet mit dem Minimum Viable Baseline. Erfasst die Daten, die ihr für eure drei bis fünf Kernfragen braucht. Wenn sich daraus weitere Fragen ergeben, könnt ihr gezielt vertiefen. Aber erhebt nicht auf Verdacht.

Fehler 3: Daten nicht laufend validieren

Dieser Fehler hat mich in meinem ersten Projekt am meisten gekostet. Drei Monate Datenerfassung, und bei der Analyse stellte ich fest: Die Kostenberichte eines Standorts waren fehlerhaft, weil die Kostenstellen-Zuordnung im ERP falsch konfiguriert war. Drei Monate Daten, teilweise unbrauchbar.

Die Lektion: Validiert eure Daten von Anfang an. Nicht am Ende des Erfassungszeitraums, sondern nach der ersten Woche. Plausibilitätsprüfungen: Liegen die Kosten pro Quadratmeter im erwartbaren Bereich? Stimmt die Anzahl der gemeldeten Tickets mit der gefühlten Realität am Standort überein? Gibt es Datenlücken oder Ausreißer?

Ich mache inzwischen nach zwei Wochen Erfassung einen „Daten-Checkpoint”: Alle bisher gesammelten Daten werden grob ausgewertet und auf Plausibilität geprüft. Das kostet einen halben Tag, spart aber Wochen an Nacharbeit.

Fehler 4: Den Auftraggeber zu spät einbinden

Baselining ist kein Selbstläufer im Hintergrund. Der Auftraggeber – ob interner Betriebsleiter oder externer Kunde – muss verstehen, was passiert, warum und was er davon hat. Wenn ihr drei Monate schweigend Daten sammelt und dann mit einem 50-Seiten-Bericht auftaucht, ist die Enttäuschung programmiert.

Ich arbeite inzwischen mit monatlichen Zwischenberichten. Keine langen Dokumente – eine Seite mit den wichtigsten Erkenntnissen, offenen Fragen und nächsten Schritten. Der Auftraggeber bleibt informiert, kann frühzeitig Prioritäten verschieben, und das Endergebnis enthält keine Überraschungen.

Ein positiver Nebeneffekt: Durch die regelmäßige Kommunikation bekomme ich Feedback, das die Datenerfassung verbessert. Der Betriebsleiter sagt: „Die Kosten für Sonderleerungen sind bei uns ein großes Thema.” Das wäre mir ohne dieses Gespräch entgangen – und hätte im Baselining gefehlt.

Fehler 5: Baselining als reine Datenerhebung verstehen

Daten ohne Interpretation sind Zahlen auf Papier. Das Baselining endet nicht mit der Datenerfassung – die eigentliche Arbeit beginnt danach. Was bedeuten die Zahlen? Wo liegen die Abweichungen zum Branchendurchschnitt? Welche Stellhebel ergeben sich?

In meinen Berichten trenne ich klar zwischen Daten und Bewertung. Der Datenteil ist objektiv: Kosten pro Gewerk, Ticketvolumen, Reaktionszeiten. Der Bewertungsteil ist meine fachliche Einschätzung als Projektleiter: Was fällt auf? Wo sehe ich Optimierungspotenzial? Welche Maßnahmen empfehle ich?

Diese Trennung schafft Transparenz. Der Auftraggeber kann die Daten selbst lesen und meine Bewertung hinterfragen. Das ist besser als ein Bericht, der Daten und Meinung vermischt.

Fehler 6: Vergleichswerte ignorieren

Ein Baselining, das nur den Ist-Zustand dokumentiert, ist nur halb so nützlich wie eines, das den Ist-Zustand im Kontext zeigt. „Die technische Wartung kostet 4,50 Euro pro Quadratmeter” – ist das viel oder wenig? Ohne Vergleichswert unmöglich zu sagen.

Vergleichswerte kommen aus verschiedenen Quellen: Branchenbenchmarks von GEFMA oder IFMA, Erfahrungswerte aus eigenen früheren Projekten, oder Vergleiche zwischen verschiedenen Standorten innerhalb desselben Portfolios.

Ich nutze ein Benchmarking-System mit drei Ebenen: Vergleich mit dem eigenen Vorjahr (Tendenz), Vergleich zwischen Standorten im Portfolio (internes Benchmarking) und Vergleich mit Branchenwerten (externes Benchmarking). Nicht jeder Datenpunkt braucht alle drei Ebenen – aber die wichtigsten KPIs sollten immer im Kontext stehen.

Fehler 7: Kein klares Übergabe-Format definieren

Der letzte Fehler ist ein organisatorischer: Das Baselining ist abgeschlossen, der Bericht ist geschrieben – aber die Ergebnisse versickern. Weil der Bericht ein PDF ist, das in einem Ordner liegt. Weil die Daten in einer Excel-Datei stehen, die niemand weiter pflegt. Weil keine Verantwortlichkeit für die Umsetzung der Empfehlungen definiert ist.

In meinen letzten Projekten liefere ich neben dem Bericht auch eine strukturierte Datenbank – die Baseline-Daten in einer PostgreSQL-Datenbank mit einem Dashboard, das der Kunde weiter nutzen kann. So wird das Baselining nicht zum einmaligen Snapshot, sondern zur laufenden Vergleichsgrundlage.

Und ich definiere mit dem Auftraggeber vor der Übergabe: Wer ist verantwortlich für die drei wichtigsten Maßnahmen? Bis wann? Was sind die nächsten Schritte? Ohne diese Vereinbarung bleiben Baselining-Ergebnisse Papiertiger.

Mein konkreter Takeaway

Wenn ihr euer nächstes Baselining-Projekt plant, startet mit diesen drei Schritten: Formuliert drei konkrete Fragen, die das Baselining beantworten soll. Definiert die minimale Datenmenge, die für diese Fragen nötig ist. Und plant nach zwei Wochen den ersten Daten-Checkpoint ein, um Qualitätsprobleme früh zu erkennen.

Baselining ist nicht sexy. Es ist akribische Datenarbeit. Aber ein sauberes Baselining ist das Fundament für jede FM-Optimierung, die danach kommt – ob Digitalisierung, KI-Einsatz oder Vertragsverhandlung.

Was sind eure Erfahrungen mit Baselining-Projekten? Welche Fehler habt ihr gemacht – und welche Lektionen daraus gelernt?