Gebäudenutzungsmuster-Anomalieerkennung

Das echte Ausmaß des Problems

Aufzugservicebetriebe schließen Wartungsverträge auf Basis eines erwarteten Nutzungsvolumens 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.

Laut Branchenanalysen des Deutschen Aufzugverbands liegen Wartungsverträge für Büro- und Gewerbegebäude häufig 20–40 Prozent unter dem tatsächlichen Nutzungsvolumen, sobald Gebäude älter als fünf Jahre sind und mindestens einen größeren Mieterwechsel erlebt haben. Der Servicebetrieb merkt das 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, Kabinen und Seilführungen sind für ein bestimmtes Nutzungsprofil ausgelegt. Übernutzung beschleunigt Verschleiß nicht linear, sondern progressiv — ein Aufzug, der dreimal so viel genutzt wird wie kalkuliert, verschleißt vier- bis sechsmal schneller an kritischen Komponenten.
• 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 Vergleichswerte basieren auf Erfahrungswerten aus IoT-gestützten Wartungsprojekten im Aufzugbereich sowie der Fallstudie von KONE/Solita (2023), die nach Einführung von Nutzungsdatenanalyse eine Reduktion reaktiver Serviceeinsätze um 40 Prozent dokumentierten.

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 — ein aufgedeckter unterkostendeckter Vertrag kann 5.000–20.000 Euro jährlich Unterschied machen. Aber: 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 — hoch (4/5) Das ist der klare Stärkenbereich: Einmal aufgebaut, skaliert das System linear über Hunderte von Aufzügen. 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 echter Wettbewerbsvorteil — weil die analytische Kapazität nicht mit der Flottengröße wächst.

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 — das dauert typisch 45–60 Tage Normalbetrieb — berechnet es für neue Datenpunkte einen Abweichungsscore. Ü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 — allerdings erfassen diese Module häufig nur Fahrtenzähler und Türzyklen, nicht die feingranulare Etagenverteilung. Das reicht für einfache Volumenanomalien, nicht für detaillierte Etagenprofil-Analysen.

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.

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 das 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. In Bürogebäuden ist das deutlich weniger problematisch.
• Das System Bilddaten oder Biometrie integriert — Kamerabasierte Besetzungserkennung für Lastoptimierung ist ein anderer Anwendungsfall mit klaren DSGVO-Pflichten.

Praktische Leitlinie:

• Aggregierte Minutenwerte (Fahrten pro 15-Minuten-Fenster, Etagenverteilung pro Stunde) sind in Bürogebäuden und Gewerbeimmobilien unkritisch
• Für Wohngebäude: Datenschutzbeauftragten hinzuziehen, bevor granulare Zeitreihen gespeichert werden
• AVV mit dem Plattformbetreiber (z.B. SafeLine Orion) abschließen, auch wenn keine direkte Personenbezogenheit vorliegt — das Gebäude und seine Bewohner werden technisch erfasst

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. Der Servicebetrieb bleibt Eigentümer der Nutzungsdaten — ein wesentlicher Unterschied zu OEM-Plattformen, die Daten in ihren eigenen Systemen speichern.
• 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 reicht in der Regel der abgeschlossene AVV.

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
• Anomalie-Modell-Entwicklung und -Kalibrierung: 5.000–15.000 Euro (extern beauftragt)
• Laufende Plattformkosten: 80–200 Euro/Monat pro 10 Aufzüge (je nach Anbieter und Feature-Tier)
• 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
• Einbau pro Aufzug: 1–4 Stunden Techniker-Zeit
• Bei 50 Aufzügen: 30.000–75.000 Euro allein für Hardware und Einbau
• Dann erst Szenario A on top

Laut Marktdaten aus dem internationalen Aufzugservicemarkt liegen die durchschnittlichen IoT-Sensorpakete für Aufzugsmonitoring bei 7.500–14.000 Euro pro Aufzug für umfassende Systeme (inklusive Vibrations-, Last- und Türsensoren), mit jährlichen Plattformabonnements von ca. 1.100–2.800 Euro pro Anlage.

Was du dagegen rechnen kannst: Ein unterkosteter Vollwartungsvertrag in einem Bürogebäude mit 300% Mehrnutzung kann 8.000–20.000 Euro jährlichen Mehraufwand verursachen, den der Servicebetrieb trägt. Entdeckt und vertraglich angepasst: direkter Ertrag. Bei einer Flotte von 50 Anlagen reicht es, wenn drei bis vier dieser Vertragsanpassungen pro Jahr gelingen — dann amortisiert sich die Analyse-Infrastruktur.

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 300% mehr fährt als 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. Mit 30 Anlagen macht die Analyse wenig Sinn. Bei 80+ Anlagen beginnt der Nutzen die Kosten zu übertreffen. Aber es gibt einen günstigeren Einstieg: 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. Das Nutzungsvolumen reicht nicht für statistisch stabile Baseline-Modelle. Einzelanlagen mit 50–100 Fahrten täglich haben zu wenig Datenpunkte für zuverlässige Anomalieerkennung — ein Ausreißertag zerstört das Bild für Wochen. Die Analyse macht erst Sinn, wenn ein Portfolio aggregiert werden kann.

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”, 2023 — dokumentiert 40 % Reduktion reaktiver Serviceeinsätze, 70 % der Faults proaktiv identifiziert, 50 % weniger Einschließungen nach Einführung von IoT-gestützter Aufzugsanalyse bei KONE. solita.fi
• IoT-Sensorik-Kostenrahmen: Marktdaten für Aufzug-IoT-Monitoring-Systeme, zusammengefasst in „How to Choose the Best Elevator IoT Monitoring System in 2026”, Alibaba SmartBuy (2025/2026): Hardware $7.500–14.000 je Aufzug, jährliche Plattformabonnements $1.100–2.800 je Anlage. smartbuy.alibaba.com
• SafeLine Orion DACH-Launch: Lift Journal, „Aufzugsmonitoring: Neues Werkzeug für Aufzugsbauer” (2023) — SafeLine LYRA und Orion für herstellerunabhängiges Monitoring seit 2023 im DACH-Raum. lift-journal.de
• Baseline-Aufbau und Alert-Kalibrierung: OxMaint, „Elevator Predictive Maintenance: AI Fault Detection Guide” (2025) — Empfehlung 45–60 Tage Baseline, False-Positive-Rate unter 10 % bei reifen Systemen, Alarmfatigue als häufigste Ursache für Systemabbruch in der Praxis.
• Wartungsvertragsrecht: Haufe Immobilien, „Vollwartungsvertrag: Anteil für Instandsetzung nicht umlagefähig” — Hintergrund zu Vollwartungsvertragsstrukturen und Umlagefähigkeit als Rechtskontext.
• Verschleiß und Übernutzung: Erfahrungswerte aus Aufzugservice-Projekten; progressive Verschleißrate bei Übernutzung (Multiplikator 4–6x bei 3x Normalnutzung) basierend auf Herstellerangaben zu Komponentenlebensdauer (u.a. TK Elevator, KONE technische Dokumentation).

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.