Wie Asset Manager ihren Bestand digitalisieren und diese Digitalisierung ihren Mietern flexibel zugänglich machen können.

In meinem Blog Digitalisierung – Wer zahlt’s? Wer verdient? hatte ich bereits die Motivation und Business Cases der verschiedenen Stakeholder zur Digitalisierung erörtert.
Hierbei wurde klar:
Der Asset Manager hat durchaus intrinsische Motivation seinen Bestand zu digitalisieren.
z. B.

• - ESG-basiertes Scoring zur Bestandsbewertung wird immer relevanter und hat zukünftig ggf. auch steuerliche Relevanz.
• - Kontinuierliche Transparenz der Energieverbrauchswerte in Richtung des Mieters ist mit der Energieffizienzrichtlinie der EU seit 2020 teilweise Pflicht.
• - Daten zur 'Gesundheit' aller Anlagen in einem Gebäude, die Wartungsfälle auf diesen und Vorhersagen aus der 'Preventive Maintenance' helfen Ausfallzeiten und Regressansprüche zu minimieren.

Ein Ansatz mit 'Verkleben' von ein paar Sensoren und Auflegen von deren Daten in einer IoT-Plattform für Dashboarding und Alarmmeldungen scheint da attraktiv, ist aber zu kurz gegriffen.
Der Asset Manager braucht einen Digitalen Bebauungsplan für die notwendigen Investitionen und die resultierende Systemlandschaft und vor allem deren direkte und indirekte Monetarisierung. Zentraler Bestandteil einer solchen Systemlandschaft ist ein Gebäudebetriebssystem wie Thing-it.
Ein ganz wesentlicher Vorteil eines Ansatzes über ein Gebäudebetriebssystem: die Investition liefert unmittelbar Digital Readiness des Gebäudes für mögliche Anforderungen der Mieter und damit die unmittelbare Möglichkeit den Mietern die Nutzung von Digitalisierungsfunktionen ermöglichen. Zunächst – im Standardfall – über die App des Gebäudebetriebssystems, die der Asset Manager durch seine Digitalisierungsinitiative anbieten kann und die Mietern ohne entsprechende eigene Infrastruktur und App Funktionen wie

• - Arbeitsplatz- und Raumbuchung
• - COVID-19 Prävention über buchungsbasiertes Tracing oder Limitierung der Aerosoldichte in z.B. Besprechungsräumen über CO2-Messungen,
• - Zugangskontrolle,
• - Verwaltung von Lockern für Flex Desking oder
• - Parkmanagement und E-Mobility

zur Verfügung stellt.
Was aber, wenn der Mieter mit einer eigenen/anderen Workplace Experience-App oder anderen Softwaresystemen auf das Gebäudebetriebssystem zugreifen möchte?
Dieser Frage wollen wir uns in diesem Blog widmen.

Welche Sprache wird gesprochen? – ‚it is a Brick House‘

Jede Software, die mit einem digitalisierten Gebäude integriert wird muss verstehen, welche Struktur das Gebäude hat und welche Elemente, Funktionen und Daten es zu Verfügung stellt.

Das gilt z.B. für
• - die eigene Workplace Experience-App eines Mieters,
• - für die Verbindung von Gebäudedaten mit den ERP-Systemen des Mieters, z.B. für die Abrechnung von Ladesäulendaten oder
• - für die Integration mit dem CAFM-System des FM-Dienstleisters zur Umsetzung von Preventive Maintenance-Funktionen.

Zur Darstellung dieser Informationen etabliert sich zurzeit das Brick-Schema. Das Brick-Schema ist eine Beschreibung aller Elemente und Daten eines Gebäudes in einer sogenannten Graphenstruktur, in der verschiedene Objekte mit Beziehungen verbunden werden. Klingt sehr theoretisch, wird aber sehr schnell konkret, wenn man sich z.B. ansieht, wie hier eine Gebäudestruktur mit Stockwerken und die Verortung von Etagenzählern beschrieben werden: Die entsprechenden Konfigurations- und Laufzeitdaten sind der berühmte Digital Twin des Gebäudes.
Software, die mit dem Gebäude kommuniziert macht sich nun diese Informationen zunutze, wie wir uns an drei Beispielen ansehen wollen.

Beispiel 1: Zählerdaten

Während der Mieter ggf. die Zählerdaten der ihn betreffenden Zähler in einer App visualisieren oder in sein ERP-System einpflegen will, möchte der Asset Manager Daten für den Aufzugstrom über alle Liegenschaften des Portfolios auswerten um Kosten nach Hersteller, Alter und ähnlichem zu vergleichen. Mit dem Wissen über das entsprechende Brick-Schema greifen nun beide wie folgt auf die Laufzeitdaten zu den oben beschriebenen Zählern zu, die z.B. in einer zeitgeordneten Datenbank vorliegen – dem berühmten Data Lake. Die Daten zu Zähler G-5 gehören demnach zu den Daten für den Aufzugstrom.

Beispiel 2: Daten von Anwesenheitssensoren

Selbst wenn ein Mieter über eine eigene Workplace Experience-App mit Funktionen zur Buchung von Besprechungsräumen über alle seine Standorte verfügt, kann hier die Raumnutzung optimiert werden, indem für eine Buchung automatisch über Anwesenheit 'eingecheckt' und wenn dieses 'Einchecken' nicht erfolgt, der Raum schnell wieder für weitere Nutzung freigegeben wird.
Hier wird der Mieter vielleicht nicht ständig eine ihm zur Verfügung gestellte Datenbank abfragen ('pollen') wollen. Viel einfacher ist es, wenn die Digitalisierungsplattform des Asset Managers, also das Betriebssystem des Gebäudes Ereignisse an eine sogenannte Publish/Subscribe Queue publiziert, auf die sich der Mieter registrieren kann, um diese Ereignisse weiter zu verarbeiten.

Beispiel 3: Raumbedienung

Natürlich kann man über obige Ansätze nicht nur Daten abfragen, sondern auch Dienste auf den Elementen des Brick-Schemas aufrufen. So kann z.B. die App eines Mieters Beleuchtungsszenen für einen Raum abfragen und diese dann setzen oder aber den Sollwert für die Temperatur dieses Raums einstellen.
Hier zeigt sich, wie die Mechanismen ineinandergreifen:
Aus Sicht des Gebäudebetriebssystems ist die Möglichkeit zum Setzen des Temperatursollwerts oder Einstellen der Beleuchtungsszene grundsätzlich vorhanden. Die Mieter-App mag aber entscheiden, dass diese Bedienung nur möglich ist, wenn sich der Nutzer im betreffenden Raum befindet. Und das kann die Mieter-App ggf. mit den eigenen Mechanismen zur Innenstandortsbestimmung feststellen. Oder aber die Mieter-App kann Innenstandortsbestimmung gar nicht, nutzt aber die Positionierungsmechanismen des Gebäudebetriebssystems und trifft vorgenannte Entscheidung zur Freigabe der Bedienfunktionen im Raum aber wiederum selbst. Und so weiter.

Über was darf gesprochen werden? – Autorisierung

Auch wenn das Brick-Schema das gesamte Gebäude repräsentiert, möchte der Asset Manager natürlich Informationen und Zugriff über die Rollen der jeweiligen Nutzer einschränken:

• - Der Mieter darf die Daten seiner Unterzähler sowie die der Anwesenheitssensoren auf der gemieteten Fläche sehen. Auch darf z.B. der Mieter die Zugangskontrollelemente zu den angemieteten Flächen freigeben. Und das für die eigenen Mitarbeiter oder aber auch für Gäste.
• - Der FM-Dienstleister darf Daten in den Primäranlagen erheben, um hier Fehlfunktionen zu erkennen. Ebenso darf der FM-Dienstleister eigenen Mitarbeitern Zugriff zu diesen Anlagen zur Wartung ermöglichen.

Im Brick-Schema stellt sich das dann so dar:

Gesprochen wird nicht zu viel und nicht umsonst – Throttling und Billing

Damit das Gebäudebetriebssystem störungsfrei funktionieren kann, muss natürlich der Zugriff durch die verschiedenen Systeme und Stakeholder limitiert werden. Man spricht hier von Throttling oder der Zuweisung von Quotae. Diese sind insbesondere wichtig um Hackerangriff aus/über die Drittsysteme durch sogenannte Distributed Denial of Service (DDOS)-Attacken abzuwehren.
Außerdem möchte der Asset Manager vielleicht für die Mehrwerte, die er über sein Gebäudebetriebssystem zur Verfügung stellt und in die er investiert hat, finanziell kompensiert werden – und das nicht über hierzu nur sehr bedingt geeignete Nebenkostenabrechnungen sondern eben abhängig von dem, was der Mieter und Dienstleister mit dem Gebäude besprechen will und der Wertschöpfung die daraus erwächst.
Daher braucht der Asset Manager eine Abrechnung der genutzten Dienste für alle Nutzer. Und das ggf. mit flexiblen Preismodellen, da ja hinter dem gleichen Serviceaufruf oder Datenzugriff nicht immer die gleiche Wertschöpfung steht. Auch das ist Aufgabe und Funktionalität des Gebäudebetriebssystems.

Fazit

Digitalisierung des eigenen Immobilienbestands kann sich in mehrere Richtungen rechnen. Am meisten aber über den Einsatz einer leistungsfähigen Digitalisierungsplattform. Also: Sofort richtig machen.