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

In meinem ersten Baselining-Projekt habe ich fast jeden Fehler gemacht, den man machen kann. Ich habe drei Monate lang Daten gesammelt, ohne sie zwischendurch zu validieren. Ich habe den Auftraggeber zu spät eingebunden. Und ich wollte jeden einzelnen Prozess erfassen statt der wesentlichen. Am Ende hatte ich einen Ordner voller Daten und einen Kunden, der fragte: „Und was bedeutet das jetzt konkret?”

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

Fehler 1: Baselining ohne klares Ziel starten

Das ist der häufigste und teuerste Fehler. „Wir machen mal ein Baselining” ist kein Ziel. Baselining ist eine Methode und kein Selbstzweck. Vor dem Start muss klar sein, was am Ende herauskommen soll: ein Kostenvergleich, standardisierte Prozesse oder eine Vertragsgrundlage für eine Neuausschreibung.

Je nach Ziel erfasst ihr andere Daten, in anderer Tiefe und über einen anderen Zeitraum. Ein Baselining für eine Neuausschreibung braucht andere Daten als eines für interne Prozessoptimierung.

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 zu offen und führt zu einem Baselining, das alles erfasst und nichts beantwortet.

Fehler 2: Zu viele Daten erfassen wollen

Hier schlägt der Perfektionismus zu. Die Versuchung ist groß, jeden Prozess, jede Anlage, jede Kostenstelle und jede Personaleinsatzstunde zu erfassen. Das Projekt zieht sich dann über Monate, ohne dass verwertbare Ergebnisse vorliegen.

In meiner Erfahrung liefern 20 Prozent der Daten 80 Prozent der Erkenntnisse. Mit den Betriebskosten nach Gewerk und Standort, der Anlagenverfügbarkeit der kritischen Systeme und den Personalkapazitäten lässt sich meist schon die Kernfrage beantworten.

Startet deshalb mit dem Minimum Viable Baseline: Erfasst die Daten, die ihr für eure drei bis fünf Kernfragen braucht. Ergeben sich daraus weitere Fragen, vertieft ihr gezielt. Auf Verdacht erhebt ihr nichts.

Fehler 3: Daten nicht laufend validieren

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

Validiert eure Daten deshalb von Anfang an, schon nach der ersten Woche und nicht erst am Ende des Erfassungszeitraums. Prüft die Plausibilität: Liegen die Kosten pro Quadratmeter im erwartbaren Bereich? Passt die Anzahl der gemeldeten Tickets zur gefühlten Realität am Standort? Gibt es Datenlücken oder Ausreißer?

Ich mache inzwischen nach zwei Wochen einen „Daten-Checkpoint”: Ich werte alle bisher gesammelten Daten grob aus und prüfe sie auf Plausibilität. Das kostet einen halben Tag und spart Wochen an Nacharbeit.

Fehler 4: Den Auftraggeber zu spät einbinden

Baselining läuft nicht von selbst im Hintergrund. Der Auftraggeber, ob interner Betriebsleiter oder externer Kunde, muss verstehen, was passiert, warum und was er davon hat. Wer drei Monate schweigend Daten sammelt und dann mit einem 50-Seiten-Bericht auftaucht, provoziert Enttäuschung.

Ich arbeite inzwischen mit monatlichen Zwischenberichten. Sie sind kurz, eine Seite mit den wichtigsten Erkenntnissen, offenen Fragen und nächsten Schritten. So bleibt der Auftraggeber informiert, kann früh Prioritäten verschieben, und das Endergebnis enthält keine Überraschungen.

Die regelmäßige Kommunikation bringt außerdem Feedback, das die Datenerfassung verbessert. Der Betriebsleiter sagt zum Beispiel: „Die Kosten für Sonderleerungen sind bei uns ein großes Thema.” Ohne dieses Gespräch wäre mir das entgangen, und im Baselining hätte es gefehlt.

Fehler 5: Baselining als reine Datenerhebung verstehen

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

In meinen Berichten trenne ich 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?

So kann der Auftraggeber 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, nützt nur halb so viel wie eines, das den Ist-Zustand im Kontext zeigt. „Die technische Wartung kostet 4,50 Euro pro Quadratmeter”: viel oder wenig? Ohne Vergleichswert lässt sich das nicht sagen.

Vergleichswerte stammen aus Branchenbenchmarks von GEFMA oder IFMA, aus Erfahrungswerten früherer Projekte oder aus dem Vergleich zwischen Standorten desselben Portfolios.

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

Fehler 7: Kein klares Übergabe-Format definieren

Der letzte Fehler ist organisatorisch. Das Baselining ist abgeschlossen, der Bericht geschrieben, und die Ergebnisse versickern: Der Bericht ist ein PDF, das in einem Ordner liegt. Die Daten stehen in einer Excel-Datei, die niemand weiter pflegt. Niemand ist für die Umsetzung der Empfehlungen verantwortlich.

In meinen letzten Projekten liefere ich neben dem Bericht eine strukturierte Datenbank mit den Baseline-Daten in PostgreSQL und ein Dashboard, das der Kunde weiter nutzen kann. So wird das Baselining zur laufenden Vergleichsgrundlage und bleibt kein einmaliger Snapshot.

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

Mein konkreter Takeaway

Für euer nächstes Baselining-Projekt empfehle ich drei Schritte. Formuliert drei konkrete Fragen, die das Baselining beantworten soll. Definiert die minimale Datenmenge, die dafür 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. Ein sauberes Baselining bildet aber 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 was habt ihr daraus gelernt?