Wyobraźmy sobie budynek biurowy. W komputerze zarządcy działa rozbudowana platforma analityczna. System zbiera dane z instalacji, przewiduje zużycie energii, wykrywa anomalie i tworzy efektowne wykresy. Na ekranie wszystko wygląda imponująco: kolorowe wskaźniki, trójwymiarowy model budynku, automatyczne rekomendacje. W tym samym czasie kilka pięter niżej pracownik techniczny zapisuje na kartce przy drzwiach pomieszczenia technicznego, że jedno z urządzeń chłodniczych po raz kolejny pracuje niestabilnie. Facility manager wysyła wiadomość z pytaniem, czy można już zatwierdzić jego naprawę. Property manager próbuje odpowiedzieć na kolejną skargę najemcy dotyczącą temperatury, a asset manager widzi w zestawieniu rosnące koszty eksploatacji.

Właśnie w tym widzę jedną z największych pułapek cyfrowej transformacji w nieruchomościach. Właściciele i zarządcy coraz częściej zakładają, że zakup nowego systemu automatycznie przełoży się na oszczędności, poprawę jakości usług oraz większą wartość aktywów. Moje doświadczenie podpowiada jednak coś mniej efektownego: technologia nie naprawia niewłaściwie zaprojektowanych procesów. Może natomiast sprawić, że zaczną działać szybciej. Niekiedy znacznie szybciej. Także wtedy, gdy zmierzają one w złym kierunku…

Nowoczesna technologia nałożona na stary model

Branża nieruchomości komercyjnych dysponuje dziś narzędziami, które jeszcze kilka lat temu wydawały się rozwiązaniami rodem z NASA. Systemy wykrywania anomalii, cyfrowe bliźniaki, zdalne odczyty mediów, predykcyjne utrzymanie urządzeń, automatyczna analiza faktur czy raportowanie ESG stają się standardowymi elementami prezentacji dostawców technologii. A jednocześnie w codziennej pracy wielu organizacji wciąż widać rzeczy bardzo przyziemne: długie łańcuchy wiadomości, lokalne arkusze kalkulacyjne, ręcznie przepisywane dane i wiedzę przechowywaną w pamięci pojedynczych pracowników. To nie jest zarzut, raczej opis realiów, z którymi branża mierzy się na co dzień.

Powstaje zasadnicza sprzeczność. Firma inwestuje w oprogramowanie odpowiadające możliwościom XXI w., ale pozostawia procesy decyzyjne zaprojektowane w czasach, gdy dostęp do danych był ograniczony, a informacje przepływały przede wszystkim między poszczególnymi działami. W takim środowisku sztuczna inteligencja nie staje się impulsem do transformacji. W rezultacie organizacja szybciej generuje raporty, których nikt nie analizuje. Sprawniej wysyła powiadomienia, na które nikt nie reaguje. Automatycznie tworzy zadania, które krążą pomiędzy kolejnymi osobami bez jasno wskazanego właściciela decyzji. Zamiast cyfrowej transformacji powstaje cyfrowa warstwa organizacyjnego chaosu.

POTOB jako rama projektowania transformacji

Metodyczną odpowiedź na tę sprzeczność daje moim zdaniem publikacja pod redakcją naukową Krzysztofa Ratyńskiego Praktyki obsługi technicznej obiektów budowlanych (POTOB). Autorzy, wyłonieni wśród członków Polskiej Rady Facility Management, proponują rozpocząć projektowanie usługi nie od narzędzia ani modelu dostawczego, lecz od identyfikacji potrzeb, oczekiwań, ograniczeń i obowiązków organizacji. Dopiero potem potrzeby zalecają przekształcić w wymagania, a następnie w odpowiedzi na trzy pytania: gdzie usługa ma być świadczona, co ma obejmować i na jakim poziomie jakości ma być realizowana (POTOB, s. 26–32).

Ta kolejność ma bezpośrednie zastosowanie do cyfryzacji. Przed wyborem platformy trzeba zdefiniować rezultat biznesowy i techniczny, który ma ona wspierać. Inaczej możliwości systemu zaczną odwzorowywać proces, zamiast odpowiadać na potrzeby obiektu i jego użytkowników.

Bardzo drogi alarm, którego nikt nie słucha

Wyobraźmy sobie, że system wykrywa nietypowy wzrost zużycia energii na jednym z pięter budynku. Teoretycznie wszystko działa prawidłowo. Dane zostały zebrane, odchylenie rozpoznane, a komunikat wysłany. Czy to oznacza, że firma osiągnęła oszczędność? Nie. System zidentyfikował jedynie możliwość podjęcia działania.

Rzeczywista wartość pojawi się dopiero wtedy, gdy ktoś przeanalizuje przyczynę wzrostu zużycia, sprawdzi pracę instalacji, oceni skalę problemu, podejmie decyzję o naprawie, zabezpieczy środki finansowe, zleci wykonanie prac, a następnie zweryfikuje uzyskany rezultat. Jeżeli powiadomienie trafia do skrzynki pracownika otrzymującego każdego dnia setki podobnych komunikatów, system staje się bardzo drogim alarmem. Informuje wszystkich, ale nie uruchamia żadnego działania. Dlatego przed wdrożeniem narzędzia organizacja powinna odpowiedzieć na kilka podstawowych pytań: 

• Kto otrzymuje informację? 
• Kto odpowiada za jej analizę? 
• W jakim czasie powinien zareagować? 
• Kto ma uprawnienia do podjęcia decyzji? 
• Z jakiego budżetu zostanie sfinansowane działanie? 
• W jaki sposób zostanie zmierzony jego efekt? 
• A może warto dokupić więcej modułów, żeby system był bardziej autonomiczny?
  
  

POTOB pokazuje, że samo pojęcie „czasu reakcji” jest zbyt ogólne. Należy rozróżnić co najmniej przyjęcie zgłoszenia, podjęcie pracy, przybycie na miejsce, naprawę i potwierdzenie wykonania, a priorytet ustalać z uwzględnieniem krytyczności urządzenia, lokalizacji, możliwych skutków oraz liczby użytkowników dotkniętych problemem. W przypadku urządzeń monitorowanych przez BMS początkiem pomiaru może być chwila wystąpienia zdarzenia, a przy innych usterkach na przykład moment skutecznego utworzenia zgłoszenia (POTOB, s. 103–104). W praktyce trzymam się prostej reguły: alert powinien mieć właściciela, priorytet, termin, ścieżkę eskalacji i kryterium zamknięcia. Bez tych elementów system tworzy informację, ale nie tworzy efektu.

Trzy perspektywy, jeden budynek

Szczególnym wyzwaniem w sektorze nieruchomości jest rozdzielenie odpowiedzialności pomiędzy Facility Management, Property Management i Asset Management. Każdy z tych obszarów patrzy na ten sam budynek z innej perspektywy. Facility manager widzi stan urządzenia, historię awarii, ryzyko techniczne i czas potrzebny na naprawę. Jego priorytetem jest bezpieczeństwo oraz ciągłość funkcjonowania instalacji. Property manager widzi skargi najemców, standard obsługi, realizację zobowiązań umownych i wpływ problemu na relacje z użytkownikami budynku. Asset manager analizuje koszty, wynik operacyjny, plan nakładów inwestycyjnych oraz wpływ decyzji na wartość nieruchomości. Problem zaczyna się wtedy, gdy każda z tych osób podejmuje decyzje wyłącznie na podstawie własnego fragmentu informacji.

Technik po raz kolejny naprawia urządzenie, ponieważ pojedyncza naprawa jest tańsza od jego wymiany. Property manager przeprasza najemców i podejmuje działania doraźne. Asset manager widzi rosnące koszty, ale nie zna pełnej historii awarii ani ich wpływu na satysfakcję użytkowników. Dopiero połączenie tych perspektyw pozwala odpowiedzieć na właściwe pytanie: czy dalsze naprawianie urządzenia ma ekonomiczne uzasadnienie, czy też jego wymiana będzie korzystniejsza dla całego aktywa?

Do wspólnej decyzji potrzebny jest również wspólny język pomiaru. POTOB wskazuje, że ocena usługi technicznej może łączyć dane o częstotliwości awarii, udziale zdarzeń planowanych i nieplanowanych, dostępności instalacji, czasie naprawy, czasie między awariami, kosztach OPEX i CAPEX, realizacji przeglądów, reklamacjach oraz satysfakcji użytkowników (POTOB, s. 87–88, 102–110).

Zestaw takich wskaźników powinien pomagać odpowiedzieć na konkretne pytanie decyzyjne: naprawiać, modernizować czy wymieniać? Dopiero połączenie parametrów technicznych, kosztów i wpływu na użytkowników pozwala ocenić konsekwencje dla całego aktywa. Sztuczna inteligencja może zgromadzić informacje i przedstawić je na wspólnym ekranie. Nie zastąpi jednak procesu współpracy pomiędzy zespołami. Nie zdecyduje również, kto ma prawo uruchomić inwestycję i ponosi za nią odpowiedzialność.

Automatyzowanie chaosu

Jednym z najczęstszych błędów popełnianych podczas transformacji cyfrowej jest automatyzowanie procesu bez wcześniejszej oceny, czy proces ten w ogóle powinien istnieć. Organizacja przyjmuje, że skoro określona procedura obowiązuje od lat, należy ją po prostu przenieść do nowego systemu. W rezultacie sztuczna inteligencja może sprawnie przekierowywać prosty wniosek przez pięć szczebli akceptacji, automatycznie tworzyć stustronicowe raporty lub przesyłać każde, nawet najmniejsze odchylenie do kilkunastu odbiorców. Jest to cyfrowe odtworzenie dotychczasowej biurokracji, a nie transformacja.

Sztuczna inteligencja z jednakową skutecznością przyspieszy dobry proces i organizacyjny absurd. Właściwa kolejność działań powinna być odwrotna do tej, którą często obserwujemy na rynku: najpierw należy wyeliminować czynności, które nie tworzą wartości. Następnie uprościć ścieżkę decyzyjną. Dopiero na końcu można ją automatyzować. Jeżeli firma zacznie od ostatniego elementu, może otrzymać proces szybszy, ale nadal nieefektywny.

Autorzy POTOB zwracają uwagę, że sposób i szczegółowość raportowania należy ustalać pod kątem specyfiki obiektu, realnych potrzeb oraz użyteczności danych. Zalecają okresową walidację raportów i eliminowanie informacji, które są gromadzone, lecz nie wspierają decyzji (POTOB, s. 86–89). W kontekście AI jest to zasada fundamentalna: automatyzować należy nie produkcję informacji, lecz przepływ od zdarzenia do działania i weryfikacji efektu.

Komputer rekomenduje, człowiek odpowiada

Nie wierzę, że wdrożenie sztucznej inteligencji w zarządzaniu nieruchomościami powinno polegać na prostym zastępowaniu ludzi algorytmami. Wartość widzę raczej we właściwym podziale pracy. Systemy powinny przejąć zadania, w których przewyższają człowieka: gromadzenie dużych zbiorów danych i ich szybka analiza, według zadanych przez ludzi kryteriów. Człowiek powinien zachować odpowiedzialność za decyzje wymagające oceny kontekstu, wyważenia ryzyka i zrozumienia konsekwencji biznesowych. 

Algorytm może wskazać, że wymiana dużej jednostki systemu HVAC będzie w perspektywie kilku lat korzystniejsza niż jego dalsze naprawianie.  Nie musi jednak wiedzieć, że w tym samym czasie firma prowadzi negocjacje o przedłużeniu umowy z kluczowym najemcą. Dłuższa przerwa w funkcjonowaniu instalacji mogłaby zakłócić jego działalność. W takich realiach szybki, doraźny remont – mimo że kosztowniejszy w długiej perspektywie – wyda się odpowiedniejszy tu i teraz. System może rekomendować ograniczenie pracy instalacji po godzinach funkcjonowania budynku. Nie zawsze uwzględni jednak specyficzne lub sezonowe wymagania najemcy, funkcjonowanie pomieszczeń technologicznych czy zobowiązania wynikające z umowy. Technologia przygotowuje decyzję. Człowiek ocenia jej szersze konsekwencje i bierze za nią odpowiedzialność. Hasło „system tak wyliczył” nie może stać się sposobem na unikanie odpowiedzialności zarządczej.

POTOB przypomina też o pułapce niewłaściwie zdefiniowanej jakości. Zbyt niski poziom usługi może zakłócać podstawową działalność użytkownika, ale nadmierny poziom jakości może być ekonomicznie nieefektywny i niepotrzebnie zwiększać koszty. Oczekiwany standard powinien być zatem realny, osiągalny i powiązany z celami organizacji oraz dostępnymi zasobami (POTOB, s. 101–102). Równie istotne jest podejście do niezgodności. Potrzebne są analiza przyczyn, plan działań naprawczych i uzgodniony sposób powrotu do oczekiwanego poziomu usługi (POTOB,
s. 111–112). W tym obszarze algorytm może wskazać odchylenie, ale odpowiedzialność za reakcję pozostaje po stronie organizacji.

Prawdziwy test zaczyna się po pilotażu

Udany pilotaż w jednym nowoczesnym budynku nie jest jeszcze dowodem dojrzałości technologicznej organizacji. W obiekcie wyposażonym w komplet czujników, aktualną dokumentację oraz spójne systemy automatyki stosunkowo łatwo jest zbudować atrakcyjny model analityczny. Znacznie trudniejsze jest zastosowanie tego samego rozwiązania w całym portfelu, obejmującym budynki z różnych okresów, wyposażone w odmienne systemy, mające niepełną dokumentację i obsługiwane według różnych procedur. Dlatego prawdziwym testem jest dla mnie zdolność do powtarzalnego wdrażania rozwiązania w kolejnych nieruchomościach. Wymaga to standaryzacji danych, procesów, zakresów odpowiedzialności i sposobów mierzenia efektów. Oznacza także konieczność odpowiedzi na pytanie, czy rozwiązanie może działać w przeciętnym budynku należącym do portfela, a nie wyłącznie w jego najbardziej nowoczesnej części.

Skalowanie wymaga również ujednolicenia definicji. Ten sam wskaźnik musi oznaczać to samo w każdym budynku: identyczny okres odniesienia, sposób liczenia czasu, zakres urządzeń i źródła danych. POTOB podkreśla, że nawet zaawansowane wskaźniki utrzymania instalacji są użyteczne tylko przy precyzyjnym zdefiniowaniu parametrów i świadomym wyborze urządzeń krytycznych, które rzeczywiście warto monitorować w BMS, CAFM lub CMMS (POTOB, s. 87–89, 103–109). Chodzi o zbudowanie powtarzalnego modelu, w którym dane są porównywalne, odpowiedzialności jednoznaczne, a wynik możliwy do zweryfikowania w skali całego portfela. Technologia tworzy wartość dopiero wtedy, gdy staje się elementem codziennego modelu operacyjnego.

Nowoczesność nie zaczyna się od licencji

Oszczędność nie powstaje w momencie zakupu systemu ani podpisania umowy z dostawcą technologii. Nie pojawia się również wtedy, gdy algorytm po raz pierwszy wykryje anomalię. Powstaje dopiero w chwili, w której informacja prowadzi do lepszej decyzji: szybszej naprawy, trafniejszej inwestycji, ograniczenia zużycia energii, poprawy komfortu najemców albo uniknięcia kosztownej awarii. Dojrzała cyfrowo organizacja to taka, w której pracownicy wiedzą, jakie znaczenie mają dane, kto powinien na nie reagować i w jaki sposób podejmowane decyzje wpływają na wynik całego portfela. Patrzę na sztuczną inteligencję jak na doskonałe narzędzie analityczne. Może ostrzegać, prognozować i rekomendować. Nie zastąpi jednak jasnych odpowiedzialności, sprawnych procesów i gotowości do podejmowania decyzji.

POTOB to praktyczna rama projektowania modelu operacyjnego: od celów organizacji, przez wymagania, przedmiot i zakres usługi, po poziom jakości, organizację świadczenia, realizację i ciągłe doskonalenie. Właśnie dlatego publikacja jest szczególnie aktualna w okresie przyspieszonej cyfryzacji. Pomaga uporządkować to, czego nie zrobi za organizację nawet najbardziej zaawansowany system. Dla właścicieli nieruchomości, zespołów Asset, Property i Facility Management oraz dostawców usług książka może pełnić funkcję listy kontrolnej przed wdrożeniem technologii, przygotowaniem SLA albo zmianą modelu obsługi. Najpierw porządkuje proces, a dopiero potem pozwala dobrać narzędzie.

 Sztuczna inteligencja jest kompasem, nie podróżnikiem. Może bardzo dokładnie wskazać kierunek, ale w drogę musimy wyruszyć sami. A przed wymarszem warto się zastanowić, czy jesteśmy odpowiednio spakowani i czy nie powinniśmy wyrzucić z bagażu zbędnego balastu. Przytroczona 20 lat temu do plecaka saperka raczej Ci się już na nowoczesnym kempingu nie przyda… choć trochę strach ją odpinać, prawda?