Gebäudenutzungsmuster-Anomalieerkennung

Das echte Ausmaß des Problems

Aufzugservicebetriebe schließen Wartungsverträge nach einem erwarteten Nutzungsvolumen ab. Dieser Wert, Fahrten pro Tag, Lastspitzen, Etagenverteilung, wird bei Vertragsabschluss grob geschätzt und danach selten überprüft. Gebäude verändern sich aber ständig: Mieter wechseln, Leerstand wird belegt, Erdgeschossflächen werden zur Eventlocation umgewidmet, Einzelhandel weicht Coworking-Betrieb.

Wie oft Verträge unter der tatsächlichen Nutzung liegen, dazu haben wir keine belastbare Branchenzahl gefunden. Für deinen eigenen Bestand lässt es sich ermitteln: Vergleiche bei den Anlagen mit Fahrtenzähler die heutigen Fahrten mit der Annahme, die bei Vertragsabschluss in die Pauschale eingeflossen ist. Ohne diese Daten merkt der Servicebetrieb die Abweichung erst, wenn die Anlage ausfällt, oder wenn ein Techniker wie Markus Brandt vor unerklärtem Frühverschleiß steht.

Das Problem hat drei Dimensionen:

• Verschleiß und Kosten: Türantriebe, Tragmittel und Bremsen altern mit der Zahl der Fahrten und Türzyklen, nicht mit dem Kalender. Ein Aufzug, der dreimal so oft fährt wie kalkuliert, erreicht den Austauschzeitpunkt dieser Teile entsprechend früher. Ob der Verschleiß darüber hinaus überproportional steigt, dazu haben wir keinen belastbaren Wert gefunden.
• Vertragserosion: Vollwartungsverträge werden für Servicebetriebe unrentabel, wenn das Nutzungsvolumen unbemerkt steigt. Die Alternative, häufigere Reparatureinsätze auf eigene Rechnung, schmälert die Marge dauerhaft.
• Reaktives Wartungsverhalten: Ohne Nutzungsdaten weiß das Serviceteam nicht, welche Anlagen unter erhöhter Last stehen. Wartungsintervalle bleiben starr, auch wenn einzelne Anlagen längst intensivere Betreuung benötigen würden.

Mit vs. ohne KI, ein ehrlicher Vergleich

Die Tabelle beschreibt Wirkungen, keine gemessenen Größen. Die oft zitierte Fallstudie von KONE und Solita (40 Prozent weniger Reparatureinsätze) betrifft Fehlerprognose aus Sensordaten, nicht die Auswertung von Nutzungsmustern; für diesen Anwendungsfall belegt sie nichts. Und flexibel sind die Intervalle nur in eine Richtung: Kürzere Intervalle für übernutzte Anlagen sind möglich, längere als vom Hersteller vorgegeben nicht. Die wiederkehrenden Prüfungen durch die zugelassene Überwachungsstelle bleiben ohnehin, die Hauptprüfung spätestens alle zwei Jahre, dazwischen die Zwischenprüfung (BetrSichV Anhang 2 Abschnitt 2). Keine Anomalieerkennung ersetzt eine davon.

Einschätzung auf einen Blick

Zeitersparnis, niedrig (2/5) Die Zeitersparnis ist indirekt: weniger Überraschungseinsätze, weniger ungeplante Techniker-Fahrten, weniger Notfalldiagnosen bei Frühverschleiß. Das sind reale Effekte, aber sie entlasten keine tägliche Routinearbeit wie die Mikro-Ausfallmuster-Erkennung das tut, wo Ferndiagnosen direkte Fahrtzeiten ersetzen. Nutzungsmuster-Anomalieerkennung ist eher ein strategisches Warnsystem als ein tägliches Arbeitstool.

Kosteneinsparung, niedrig (2/5) Das finanzielle Potenzial ist vorhanden, aber es entsteht nur über eine höhere Pauschale oder einen Vertrag, den du nicht mehr mit Verlust verlängerst. Wie groß der Unterschied je Vertrag ist, zeigt nur deine eigene Auftragsbuchhaltung. Und: Der Nutzen hängt komplett davon ab, ob der Servicebetrieb überhaupt eine Vertragstierstruktur hat, die auf Nutzungsdaten reagiert. Ohne definierte Vertragsanpassungsprozesse liefert die Analyse Erkenntnisse ohne direkten Geldhebel. Anders als beim Wartungsvertrags-Profitabilitäts-Drift, der bereits eine Vertragsdaten-Infrastruktur voraussetzt, ist hier der Engpass die IoT-Infrastruktur.

Schnelle Umsetzung, mittel (3/5) Wenn IoT-Konnektivität bereits vorhanden ist, ist ein erster Nutzungs-Dashboard in 6–10 Wochen möglich: Daten fließen, Baseline-Modell lernt, erste Abweichungen sichtbar. Die entscheidende Hürde ist das “wenn”: Viele Servicebetriebe haben noch keine vollständige IoT-Abdeckung ihrer Flotte. Wer Retrofitting der Sensorik einplanen muss, verdoppelt den Zeitplan.

ROI-Sicherheit, niedrig (2/5) Nutzungsmuster-Anomalieerkennung liefert Erkenntnisse, keine automatischen Erlöse. Ob eine erkannte Übernutzung zu einer Vertragsanpassung führt, hängt von Verhandlung, Vertragsrecht und Kundenbeziehung ab. Der ROI ist real, aber stark kontextabhängig und schwer vorab zu kalkulieren. Ohne klar definierte Nachvertragsprozesse bleibt der Nutzen auf der Strecke.

Skalierbarkeit, mittel (3/5) Die Arbeit skaliert gut: Neue Anlagen werden ins Dashboard aufgenommen, Baseline-Modelle lernen automatisch, Alerts fließen in denselben Workflow. Für große Servicebetriebe mit 200+ verwalteten Anlagen ist das ein Vorteil, weil die analytische Kapazität nicht mit der Flottengröße wächst. Die Kosten dagegen wachsen mit: Das Plattformabo läuft je Aufzug, und jede Altanlage braucht ihr eigenes Retrofit-Modul. Deshalb keine hohe Bewertung.

Richtwerte, stark abhängig von IoT-Abdeckung der Flotte, vorhandenem Vertragstiermodell und Flottengröße.

Was das System konkret macht

Im Kern geht es um Machine Learning auf Zeitreihendaten. Jeder IoT-fähige Aufzug liefert kontinuierlich Betriebsdaten: wann fährt er, wohin, wie oft, wie schwer beladen, wie lange öffnen die Türen. Diese Datenpunkte werden zeitlich aggregiert und zu einem Normalprofil des Aufzugs verdichtet.

Das Normalprofil erfasst typische Muster:

• Wochentag vs. Wochenende
• Berufsverkehr-Spitzen morgens und abends
• Etagenpräferenzen (Erdgeschoss → OG 2 dominiert, oder OG 4–6 hat eigene Spitze)
• Saisonale Varianz (Ferienmonate, Weihnachtszeit)

Sobald das Modell dieses Profil kennt, berechnet es für neue Datenpunkte einen Abweichungsscore. SafeLine nennt für Orion eine Baseline in den Wochen drei bis vier nach dem Einbau; für Vertragsfragen würden wir wegen der Schwankungen zwischen Wochen und Monaten eher 45–60 Tage Normalbetrieb abwarten. Überschreitet die Abweichung einen kalibrierten Schwellwert und hält sie sich über mehrere Tage, wird eine Anomalie-Meldung ausgelöst.

Der Algorithmus unterscheidet dabei zwischen:

1. Kurzfristigen Ausreißern, Feiertage, Events, einzelne Mieterveranstaltungen
2. Strukturellen Verschiebungen, dauerhafte Änderungen im Nutzungsmuster, die auf echte Gebäudeveränderungen hindeuten

Für die eigentliche Anomalieerkennung kommen verschiedene Ansätze in Frage: einfachere statistische Methoden wie Z-Score-Analysen über rollierende Fenster funktionieren gut für klare Trendbrüche. Komplexere Modelle wie Isolation Forest oder LSTM-Netze sind genauer bei subtilen Mustern, erfordern aber mehr Daten und Entwicklungsaufwand.

Welche Sensordaten der Aufzug bereits liefert

Das ist die entscheidende Frage vor jedem Projektstart: Welche Daten sind schon vorhanden? Moderne IoT-fähige Aufzüge, ab etwa 2018 neue Anlagen der großen Hersteller, liefern typischerweise:

Ältere Anlagen ohne native IoT-Schnittstelle liefern diese Daten nicht. Sie können mit Retrofit-Modulen wie SafeLine LYRA (Teil des SafeLine Orion -Ökosystems) nachgerüstet werden. LYRA zählt laut Lift Journal Fahrten und Türöffnungen je Etage und erfasst die Position des Fahrkorbs im Schacht, eine Lastmessung hat es nicht. Das reicht für Volumen- und Etagenprofile, nicht für Muster 5 weiter unten, die Lastprofil-Verschiebung.

Praktische Daumenregel: Wenn dein Aufzug keine Netzwerkverbindung hat, beginnt dein Projekt mit Hardware, nicht mit Analytics.

Nutzungsmuster-Typen und was sie verraten

Nicht jede Anomalie bedeutet dasselbe. Erfahrung aus IoT-Projekten zeigt fünf wiederkehrende Muster:

Muster 1: Gesamtvolumen-Sprung Fahrten pro Tag steigen dauerhaft um mehr als 30 Prozent gegenüber dem Basis-Niveau. Häufigste Ursache: Neueinzug eines Mieters mit hoher Mitarbeiterdichte. Handlungsempfehlung: Gebäudeverwalter kontaktieren, Nutzungsänderung bestätigen lassen, Vertrag prüfen.

Muster 2: Neue Etagenspitze Eine bisher wenig genutzte Etage erscheint plötzlich in der Top-3 der Zielstockwerke. Häufigste Ursache: Eröffnung eines Restaurants, Coworking-Betriebs oder Fitnessstudios. Handlungsempfehlung: Türantrieb und Seilführung dieser Etage bei nächstem Einsatz priorisiert prüfen.

Muster 3: Zeitfenster-Verschiebung Spitzenlast verlagert sich von 8–9 Uhr auf 11–14 Uhr oder auf abendliche Stunden. Häufigste Ursache: Gastronomie, Eventhall, Hotel-Check-in-Betrieb. Relevant für: Wartungszeitfenster, die jetzt mit Spitzenzeiten kollidieren.

Muster 4: Wochenend-Aktivierung Anlage, die samstags und sonntags kaum genutzt wurde, zeigt jetzt gleichmäßige Wochenend-Last. Häufigste Ursache: Umwidmung zu Wohnnutzung oder Wellness-/Sportbetrieb. Handlungsempfehlung: Wartungseinsätze nicht mehr pauschal auf Wochenenden legen.

Muster 5: Lastprofil-Verschiebung Durchschnittliche Beladung steigt, ohne dass Fahrtenzahl steigt. Häufigste Ursache: Schwertransporte (Möbellogistik, Warenlieferungen), neue medizinische Nutzung, Krankenhausbetrieb. Kritisch für: Seile, Bremsen, Antriebsmotor. Erkennbar nur, wenn die Anlage eine Lastmessung liefert; das Retrofit-Modul LYRA etwa hat keine.

Jedes dieser Muster hat andere Konsequenzen für Wartungsplanung und Vertragsbewertung. Ein gutes Analyse-Dashboard zeigt nicht nur den Alarm, sondern ordnet ihn diesen Typen zu.

Privacy-Frage: Was darf der Aufzugbauer über Gebäudebewohner wissen?

Das ist die Frage, die in vielen Projekten zu spät gestellt wird, und dann den Launch verzögert.

Aufzugdaten sind keine personenbezogenen Daten im Direktsinne: Ein Fahrtenzähler sagt nicht, wer gefahren ist. Etagenrufe verraten keine Identität. Solange das System aggregierte Nutzungszahlen auswertet, bewegt man sich außerhalb des direkten Anwendungsbereichs der DSGVO.

Aber: Die Situation ändert sich, wenn:

• Zeitstempel und Etagen kombiniert werden, Bewegungsprofile von Gebäudebewohnern lassen sich rekonstruieren, wenn Fahrtdaten hinreichend granular sind (Fahrt von EG nach OG 4 um 22:37 Uhr). In Wohngebäuden kann dadurch ein Personenbezug entstehen.
• Das Gebäude ein Wohngebäude ist, Betreiber von Fahrstühlen in Wohngebäuden müssen bei detaillierter Fahrtprotokollierung eine Datenschutz-Folgenabschätzung prüfen.
• Auf einer Etage nur wenige Menschen arbeiten oder wohnen, auch im Bürogebäude. Hat eine Etage nur eine kleine Praxis, eine Kanzlei oder ein Einzelbüro, verraten schon Türöffnungen je Etage und Stunde, wann diese Menschen kommen und gehen. Ein Zähler je Etage ist dann nicht mehr anonym.
• Das System Bilddaten oder Biometrie integriert, Kamerabasierte Besetzungserkennung für Lastoptimierung ist ein anderer Anwendungsfall mit klaren DSGVO-Pflichten.

Praktische Leitlinie:

• Aggregierte Werte (Fahrten pro 15-Minuten-Fenster, Etagenverteilung pro Stunde) sind in Bürogebäuden mit großen Mieteinheiten unkritisch; für Etagen mit wenigen Personen gröber aggregieren, etwa auf Tageswerte
• Für Wohngebäude: Datenschutzbeauftragten hinzuziehen, bevor granulare Zeitreihen gespeichert werden
• AVV mit dem Plattformbetreiber (z.B. SafeLine Orion ) abschließen, sobald personenbeziehbare Daten entstehen können; im Zweifel vorsorglich
• Einbau und Datenerhebung schriftlich mit dem Eigentümer vereinbaren. Der Aufzug gehört ihm, und die Daten dienen dir auch dazu, mit ihm über den Preis zu verhandeln

Konkrete Werkzeuge, was wann passt

Die Toolwahl hängt stark davon ab, wie viel technische Eigenentwicklung du leisten kannst und ob du bereits über IoT-Infrastruktur verfügst.

SafeLine Orion , für unabhängige Servicebetriebe Die beste Option für Servicebetriebe, die mehrere Aufzugsmarken betreuen und ihre Nutzungsdaten nicht einem einzelnen OEM überlassen wollen. Herstellerunabhängig, EU-Daten, deutschsprachiger Support. Erfordert LYRA-Hardware-Modul für ältere Anlagen. Nutzungsdaten und Anomaliemeldungen fließen direkt ins Orion-Dashboard. Preise auf Anfrage.

InfluxDB + Grafana , für Eigenlösungen Wer bereits IT-Kompetenz im Team hat und seine Plattform selbst betreiben will, kombiniert InfluxDB (Zeitreihendatenbank für Aufzugtelemetrie) mit Grafana (Dashboarding und Alerting). Kostenlos in der Open-Source-Variante, self-hosted auf eigenem Server. InfluxDB verarbeitet Millionen Datenpunkte pro Sekunde und eignet sich ideal für Flottengrößen ab 20 Aufzügen aufwärts. Grafana ML (Enterprise/Cloud) bietet Anomalieerkennung als Plugin; die Community-Edition erfordert externe Modelle. Vorteil: maximale Datenkontrolle, kein Vendor-Lock-in. Nachteil: Signifikanter Entwicklungsaufwand für Datenmodell, Anomalie-Logik und Alert-Routing.

Azure Machine Learning , für den Schritt zum eigentlichen ML-Modell Wenn statistische Baseline-Modelle (Z-Score, einfache Schwellwerte) nicht reichen und du echte Anomalie-Klassifizierer aufbauen willst, ist Azure Machine Learning der nächste Schritt. Modelle wie Isolation Forest oder LSTM-Netze für Zeitreihenerkennung können hier trainiert, deployt und über eine API abgerufen werden. EU-Rechenzentrum (Frankfurt) verfügbar. Erfordert Datenwissenschafts-Know-how oder einen Implementierungspartner.

Azure Digital Twins , für Gebäudedigitalisierung im großen Stil Für Servicebetriebe oder Gebäudeverwalter, die Aufzüge als Teil eines umfassenderen Gebäudedaten-Modells betrachten (HVAC, Beleuchtung, Zugang, Aufzüge) und bereits in Microsoft Azure investiert haben. Azure Digital Twins bildet das gesamte Gebäude als Wissensgraph ab und verbindet Aufzugdaten mit anderen Gebäudeparametern. Hoher Einrichtungsaufwand, klar für Enterprise-Kontext.

Node-RED , als Datenpipeline-Werkzeug Wenn du Aufzugdaten aus verschiedenen Quellen (OPC-UA-Gateway, Hersteller-APIs, MQTT-Broker) aggregieren und in InfluxDB oder Azure leiten willst, ist Node-RED ein pragmatisches Zwischenstück. Open-Source, läuft auf einem Edge-Server oder Raspberry Pi, verbindet Sensordaten mit Analyseplattformen ohne Custom-Entwicklung.

Zusammenfassung: Wann welcher Ansatz

• Herstellergemischte Flotte, keine eigene IT-Entwicklung → SafeLine Orion
• Vorhandene IT-Kompetenz, maximale Flexibilität → InfluxDB + Grafana (+ Azure Machine Learning für ML-Modelle)
• Microsoft Azure bereits im Einsatz, Enterprise-Skalierung → Azure Digital Twins + Azure Machine Learning
• Datenintegration über heterogene Quellen → Node-RED als Brücke

Datenschutz und Datenhaltung

Aufzugbetriebsdaten sind in der Regel keine direkt personenbezogenen Daten, aber der Kontext entscheidet (siehe Abschnitt zur Privacy-Frage oben).

Für die DSGVO-Einordnung sind folgende Punkte relevant:

• SafeLine Orion : Europäische Datenhaltung, AVV erhältlich. Die Daten gehören laut unserer Toolseite dem Kunden, also Servicebetrieb oder Eigentümer, je nachdem, wer den Vertrag mit SafeLine schließt; ein wesentlicher Unterschied zu OEM-Plattformen, die Daten in ihren eigenen Systemen speichern. Wem sie im Verhältnis zum Gebäudeeigentümer gehören, regelst du am besten schriftlich.
• InfluxDB (Open Source, self-hosted): Vollständige Datenkontrolle, keine Drittübertragung. Bei Betrieb auf eigenen oder deutschen Hosting-Servern keine Datenschutzbedenken.
• Azure Machine Learning / Azure Digital Twins : EU-Rechenzentren verfügbar (Frankfurt). Microsoft stellt AVV standardmäßig über den Azure-Rahmenvertrag bereit.

Für Wohngebäude mit granularer Fahrtprotokollierung: Datenschutz-Folgenabschätzung gemäß Art. 35 DSGVO prüfen, bevor das System im Produktivbetrieb geht. In Büro- und Gewerbegebäuden kommt es auf die Granularität an: Werte je Etage und Stunde bei kleinen Mieteinheiten sind personenbeziehbar; dann brauchst du neben dem AVV auch eine Rechtsgrundlage und musst die Betroffenen informieren.

Was es kostet, realistisch gerechnet

Die Kostenstruktur hängt stark davon ab, ob IoT-Infrastruktur bereits vorhanden ist.

Szenario A: IoT-Connectivity vorhanden (Aufzüge liefern bereits Daten)

• Analyseplattform-Einrichtung ( SafeLine Orion oder InfluxDB / Grafana ): 3.000–10.000 Euro einmalig (Annahme dieser Seite)
• Anomalie-Modell-Entwicklung und -Kalibrierung, wenn du sie extern beauftragst: Projektaufwand, der zu allen Summen auf dieser Seite hinzukommt
• Laufende Plattformkosten: 8–20 Euro je Aufzug und Monat (Annahme dieser Seite; SafeLine nennt Preise nur auf Anfrage)
• Baseline-Aufbau: 6–8 Wochen Normalbetrieb ohne Zusatzkosten

Szenario B: Kein IoT, Retrofitting nötig

• Hardware pro Aufzug (LYRA-Modul oder Vergleichbares): 500–1.200 Euro (Annahme dieser Seite, Preise nur auf Anfrage)
• Einbau pro Aufzug: 1–4 Stunden Techniker-Zeit
• Bei 50 Aufzügen: 50 mal 500 bis 50 mal 1.200 Euro, also 25.000–60.000 Euro Hardware, dazu 50–200 Technikerstunden für den Einbau
• Dann erst Szenario A on top

Was du dagegen rechnen kannst: Geld bringt das System nur, wenn eine erkannte Übernutzung zu einer höheren Pauschale führt, oder zu einem Vertrag, den du sonst mit Verlust verlängert hättest. Wie viel Mehraufwand eine übernutzte Anlage verursacht, zeigt deine eigene Auftragsbuchhaltung: Reparatureinsätze und Teile je Anlage und Jahr, verglichen mit dem Schnitt vergleichbarer Anlagen im Bestand. Eine belastbare Branchenzahl dafür haben wir nicht gefunden.

Die Gegenrechnung für eine Flotte von 50 vernetzten Anlagen (Szenario A): Laufend kostet die Plattform 50 mal 8 bis 50 mal 20 Euro im Monat, also 4.800–12.000 Euro im Jahr, dazu 15–30 Minuten Sichtung pro Woche. Erst was die angepassten Verträge darüber hinaus einbringen, zahlt die Einrichtung ab, 3.000–10.000 Euro plus den Modellaufbau. Müssen die Anlagen erst nachgerüstet werden (Szenario B), kommen 25.000–60.000 Euro Hardware hinzu. Das tragen wenige Vertragsanpassungen im Jahr nur, wenn der Mehrerlös je Vertrag hoch ist. Und die Mehrerlöse zahlt der Eigentümer: Er kann auch kündigen, statt mehr zu zahlen. Dann sparst du den Verlust aus dem Vertrag, verdienst aber nichts.

Wie du den Nutzen misst: Nicht über Zeitkalkulationen, sondern über zwei konkrete Indikatoren: (1) Anzahl der aufgedeckten Vertragsabweichungen pro Quartal und nachgefolgte Anpassungsgespräche, (2) Verhältnis ungeplanter zu geplanter Wartungseinsätze, dieser Wert sollte sinken, wenn das System funktioniert.

Drei typische Einstiegsfehler

1. Anomalie-Alerts vor Baseline aktivieren Das ist der häufigste Fehler, und er kostet das Projekt oft seine Glaubwürdigkeit. Wenn das System in den ersten vier Wochen ständig anschlägt, weil es noch kein stabiles Normalprofil hat, ignoriert das Team die Alerts. In den Wochen danach, wenn echte Abweichungen auftreten, werden die Alerts nicht mehr ernst genommen. Die Faustregel: Erst nach 45–60 Tagen Normalbetrieb Schwellwerte scharf stellen.

2. Jede Abweichung als Handlungsauftrag behandeln Nicht jede Nutzungsanomalie rechtfertigt sofort ein Vertragsgespräch. Feiertage, Betriebsfeste, temporäre Bauphasen, all das erzeugt legitime Abweichungen. Ein reifes Analyse-System unterscheidet zwischen einmaligen Ausreißern und strukturellen Verschiebungen. Wer bei jedem Alert den Kunden anruft, wird schnell als Alarm-Generateur wahrgenommen. Empfehlung: Alert erst dann in den Vertriebsprozess weitergeben, wenn die Abweichung über mindestens 14 aufeinanderfolgende Tage stabil bleibt.

3. Das Nutzungsanalyse-System einrichten, aber nicht pflegen Das ist der gefährlichste Fehler, weil er still passiert.

Baseline-Modelle lernen aus Vergangenheitsdaten. Wenn das Gebäude sich über Monate verändert, schrittweise Belegung, wechselnde Mieter, passt sich ein gutes adaptives Modell an. Aber: Wenn das System monatelang ohne Revision läuft und das Team die Ergebnisse nicht regelmäßig validiert, verschiebt sich die Baseline schleichend mit dem neuen Normalzustand. Das System erkennt dann keine Anomalie mehr, weil “alles Normal” ist, obwohl die Nutzung längst außerhalb der vertragsgemäßen Grenzen liegt. Wer diesen Effekt ignoriert, hat nach 18 Monaten ein System, das korrekt trainiert ist, auf die falsche Baseline.

Lösung: Quartalsweise manuelle Plausibilitätsprüfung: Vergleich der aktuellen Baseline mit den Vertragsannahmen des Abschlussjahres. Nicht die KI, sondern ein Mensch muss entscheiden: Hat sich das Gebäude strukturell verändert? Muss die Baseline zurückgesetzt werden?

Was mit der Einführung wirklich passiert, und was nicht

Die größte Überraschung in Projekten dieser Art ist nicht technisch, sondern organisatorisch.

Das technische Setup funktioniert schneller als erwartet. Wenn IoT-Infrastruktur vorhanden ist, sind erste Dashboards in zwei bis drei Wochen produktiv. Daten fließen, Grafiken entstehen. Das Team ist beeindruckt.

Die Nutzung bricht dann ab. Dashboards werden in den ersten Wochen täglich aufgerufen, danach wöchentlich, dann monatlich, dann gar nicht mehr, außer jemand macht es zur Aufgabe. Der Grund: Niemand hat definiert, was bei einem Alert konkret zu tun ist. Wer ruft wen an? Welches Gespräch führt wie? Welche Schwellwerte sind Vertragsgesprächs-Trigger, welche nur Wartungshinweise?

Was konkret hilft:

• Vor dem Launch schriftlich festlegen: bei welchem Anomalie-Level passiert was (intern Notiz / Wartungspriorisierung / Vertragsgesprächsauftrag / eskaliertes Gespräch mit Gebäudeverwalter)
• Eine Person pro Team als Daten-Verantwortlichen benennen, der einmal pro Woche 15 Minuten die aktuellen Alerts sichtet
• Monatlichen Review-Termin im Kalender: drei Anlagen mit den stärksten Abweichungen besprechen
• Vertrieb und Service früh einbinden, die Ergebnisse des Systems sind nur dann wertvoll, wenn beide wissen, was damit zu tun ist

Was nicht passiert: Das System ersetzt nicht das Kundengespräch. Wer einem Gebäudeverwalter mitteilt, dass sein Aufzug dreimal so oft fährt wie kalkuliert und deshalb der Vertrag angepasst werden muss, braucht Gesprächskompetenz, nicht nur Daten. Die Daten helfen, das Gespräch zu führen. Sie ersetzen es nicht.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände, und was dahintersteckt

„Wir wissen schon, welche Gebäude viel genutzt werden.” Erfahrung und Bauchgefühl spielen in der Aufzugbranche eine große Rolle, zu Recht, nach vielen Jahren Berufserfahrung. Aber: Das Gefühl erfasst Extremfälle. Es erfasst nicht die Anlage in Gebäude Nr. 47, die seit sieben Monaten 40 Prozent mehr fährt als kalkuliert, weil sie unauffällig läuft und noch kein Problem gemacht hat. Systematische Daten sind kein Ersatz für Erfahrung. Aber sie erfassen die blinden Flecken, die jedes Bauchgefühl hat.

„Die Gebäudeverwalter informieren uns doch, wenn sich etwas ändert.” Das ist die beliebteste Fehlerwartung in diesem Bereich. Gebäudeverwalter denken selten an den Aufzugservice, wenn ein neuer Mieter einzieht. Ihre Aufgabe ist die Vermietung, die nachgelagerten Konsequenzen für Wartungsverträge sind nicht ihr primäres Problem. Daten zu haben, die dokumentieren, was passiert ist und seit wann, stärkt die eigene Verhandlungsposition deutlich stärker als eine mündliche Aussage.

„Das ist zu aufwändig für unsere Flottengröße.” Das stimmt, für kleine Flotten. Unter 50 Anlagen tragen die angepassten Verträge die laufenden Kosten selten. Darüber hängt es an den Zahlen aus der Gegenrechnung oben: Mehrerlös je angepasstem Vertrag gegen Plattformkosten je Aufzug. Einen günstigeren Einstieg gibt es trotzdem: SafeLine Orion oder vergleichbare Plattformen bieten Monitoring ohne eigene Entwicklung. Der Aufwand liegt dann vor allem in der Hardware.

Woran du merkst, dass das zu dir passt

• Du betreust mehr als 50 Aufzüge und hast keinen realistischen Überblick, wie sich Nutzungsprofile über die Flotte verteilen
• Du hast in den letzten zwei Jahren mindestens einen Fall gehabt, wo Frühverschleiß auf unerkannte Übernutzung zurückzuführen war
• Dein Vertragsmodell kennt Nutzungstiers, d.h. wenn du Übernutzung dokumentieren kannst, hast du eine Grundlage für das Gespräch
• Deine Aufzüge sind IoT-fähig, oder du bist bereit, in Hardware zu investieren
• Du hast jemanden im Team, der sich 15–30 Minuten pro Woche mit Analysedaten befasst

Wann es sich (noch) nicht lohnt, drei harte Ausschlusskriterien:

1. Weniger als 50 verwaltete Aufzüge. Die Baseline je Anlage hängt nicht an der Flottengröße, die Wirtschaftlichkeit schon: Bei wenigen Anlagen gibt es zu selten eine Übernutzung, die eine Vertragsanpassung auslöst, und die Plattformkosten laufen trotzdem. Dazu kommt: Anlagen mit 50–100 Fahrten täglich liefern wenig Datenpunkte, ein Ausreißertag verzerrt das Bild für Wochen.

2. Keine IoT-Konnektivität und kein Budget für Retrofitting. Ohne Sensordaten gibt es keine Analyse. Ein Projekt, das mit Hardware-Installation beginnt, ist ein anderes Projekt als eines, das mit Analyse beginnt. Wer beides gleichzeitig angeht, unterschätzt regelmäßig den Hardware-Aufwand. Kläre zuerst: Wie viele meiner Anlagen sind bereits vernetzt? Dann entscheide, ob Analytics der nächste Schritt ist.

3. Kein definiertes Vertragsanpassungsverfahren. Das schmerzhafteste Ausschlusskriterium: Wenn dein Geschäftsmodell keine Vertragstiers kennt und Nutzungsänderungen nicht vertraglich adressiert, liefert die Analyse Erkenntnisse ohne Handlungshebel. “Wir wissen jetzt, dass Gebäude X dreimal so viel fährt” ist wertlos, wenn es keinen Prozess gibt, was mit diesem Wissen zu tun ist. Zuerst das Vertragsmodell klären, dann die Analytics.

Das kannst du heute noch tun

Starte mit einer einfachen Bestandsaufnahme: Welche Aufzüge in deiner Flotte sind bereits IoT-fähig und liefern aktiv Daten? Welche nicht? Schreib diese zwei Listen auf, das ist der ehrlichste erste Schritt.

Für die IoT-fähigen Anlagen: Export der letzten sechs Monate Fahrtenzähler, sofern dein System das erlaubt. Dann nutze das folgende Analyse-Prompt mit ChatGPT oder Claude , um eine erste Einschätzung zu bekommen:

Quellen & Methodik

• KONE/Solita-Fallstudie (2023): Solita, „Predictive maintenance gets more intelligent with advanced analytics”, dokumentiert für KONE 40 % weniger Reparatureinsätze, 70 % der Störungen proaktiv erkannt und 50 % weniger Einschließungen. Grundlage ist Fehlerprognose aus Sensordaten, keine Nutzungsmusteranalyse. solita.fi
• SafeLine Orion und LYRA: Lift Journal, „Aufzugsmonitoring: Neues Werkzeug für Aufzugsbauer” (September 2024): LYRA erfasst Fahrten, Türöffnungen je Etage, Fahrkorbposition, Geschwindigkeit und Schachttemperatur, keine Lastmessung. lift-journal.de. Baseline laut Anbieter in den Wochen drei bis vier nach Einbau. safelineorion.com
• Wiederkehrende Prüfungen: Betriebssicherheitsverordnung, Anhang 2 Abschnitt 2: Hauptprüfung durch eine zugelassene Überwachungsstelle, Prüffrist höchstens zwei Jahre, Zwischenprüfung in der Mitte des Prüfzeitraums. gesetze-im-internet.de
• Wartungsvertragsrecht: Haufe Immobilien, „Vollwartungsvertrag: Anteil für Instandsetzung nicht umlagefähig”, Hintergrund zu Vollwartungsvertragsstrukturen und Umlagefähigkeit als Rechtskontext.
• Kosten, Baseline-Dauer und Schwellen: Annahmen dieser Seite, keine gemessenen Werte. Setze deine eigenen Zahlen ein.

Willst du wissen, welche deiner Aufzüge bereits IoT-fähig sind und wie ein erster Pilot konkret aussehen würde? Ruf an oder schreib uns, das klären wir in 30 Minuten.