Model, który uczył się od pani Ani
Pani Ania pracuje w budynku od siedmiu lat. Zna go lepiej niż niejeden projektant i lepiej niż system, który nim zarządza. Wie, że winda C w poniedziałkowe poranki reaguje z sekundowym opóźnieniem. Wie, że po spotkaniach zarządu w sali 8.12 niemal zawsze zostaje otwarte okno, więc klimatyzacja do południa próbuje wyrównać temperaturę. Wie, który najemca ma w zespole osobę wrażliwą na zapachy i dlatego na czwartym piętrze stosuje inny środek czystości. Wie też, że jeśli w kuchni na szóstym piętrze przez kilka dni przybywa kubków, problem może nie dotyczyć zmywarki. Czasem jest to po prostu sygnał, że zespół przechodzi trudniejszy moment. Żadnej z tych informacji nie znajdziemy w instrukcji obsługi budynku, systemie CAFM ani dokumentacji technicznej. Nie są to dane z czujników ani reguły zapisane w procedurach. To wiedza zdobywana przez lata obserwacji, doświadczenia i codziennego kontaktu z obiektem. I właśnie tutaj znajduje się jeden z największych, a jednocześnie najmniej wykorzystywanych zasobów operacyjnych budynków. W tysiącach obiektów w Polsce podobna wiedza pozostaje w głowach i doświadczeniu pracowników pierwszej linii. To oni rozpoznają wzorce, wychwytują odstępstwa i podejmują decyzje na podstawie kontekstu, którego system często nie posiada. Z punktu widzenia organizacji jest to wiedza krytyczna, ponieważ wpływa na ciągłość operacji, jakość usług, szybkość reakcji i zdolność do zapobiegania problemom.
REKLAMA
Można ją określić jako wiedzę ukrytą. Jej wartość jest oczywista, ale problem polega na tym, że trudno ją przechwycić i przenieść do systemu. I tu pojawia się właściwe pytanie: czy możemy nauczyć system nie tylko tego, co dzieje się w budynku, ale również tego, co o budynku wiedzą ludzie?
Zasób, którego nie ma w bilansie
W poprzedniej części pisałam o białkowej warstwie danych: wiedzy pracowników pierwszej linii, obserwacjach i doświadczeniach, których nie rejestrują czujniki ani systemy. Dziś chcę zrobić kolejny krok i postawić tezę, która w numerze o syntetycznej rzeczywistości brzmi paradoksalnie: bez tej wiedzy nie da się nawet sensownie myśleć o robotyzacji.
Robot sprzątający potrzebuje nie tylko mapy powierzchni, ale również informacji o sposobie użytkowania przestrzeni. Musi wiedzieć, które strefy wymagają większej częstotliwości sprzątania, kiedy pojawia się największy ruch, gdzie regularnie gromadzi się kurz i które miejsca mają szczególne znaczenie dla użytkowników budynku. Część tych informacji można pozyskać z danych. Ale zanim zaczniemy je zbierać i wykorzystywać, ktoś musi wiedzieć, co mierzyć, kiedy to mierzyć i dlaczego ma to znaczenie. Tę wiedzę mają często pracownicy, którzy od lat wykonują tę pracę. Pani Ania wie, że pod schodami kurz pojawia się szybciej, choć nie wynika to z żadnej instrukcji. Wie też, że określone strefy wymagają innego podejścia w zależności od pory dnia czy sposobu ich użytkowania. I właśnie dlatego doświadczenie ludzi nie jest przeciwieństwem automatyzacji. Jest jednym z jej warunków. Nie da się dobrze zautomatyzować procesu, którego organizacja sama do końca nie rozumie. Zanim robot przejmie zadanie, trzeba opisać nie tylko jego formalny przebieg, ale również wyjątki, zależności i kontekst, które w praktyce decydują o jakości wykonania.
Ten opis często już mamy. Nie znajduje się jednak w systemie, lecz w doświadczeniu ludzi. To zmienia sposób myślenia o robotyzacji. Pracownik pierwszej linii nie jest wyłącznie kosztem, który technologia ma ograniczyć. Jest również źródłem wiedzy potrzebnej do zaprojektowania automatyzacji, jej wdrożenia i późniejszego doskonalenia. Najpierw trzeba więc dobrze poznać pracę, którą chcemy zautomatyzować. A żeby ją naprawdę poznać, trzeba zacząć od ludzi, którzy wykonują ją każdego dnia. Bo dobry robot nie powstaje wyłącznie z technologii, ale z technologii opartej na dobrym rozumieniu rzeczywistej pracy.
Czy to się w ogóle da przenieść?
Filozof Michael Polanyi napisał, że wiemy więcej, niż potrafimy powiedzieć. To dobrze opisuje wiedzę pracowników pierwszej linii. Pani Ania może wiedzieć, że w sali odbyło się nocne spotkanie, choć trudno byłoby jej wskazać jedną konkretną regułę, na podstawie której to rozpoznała. Widzi kilka drobnych sygnałów, które razem tworzą obraz sytuacji. Poproszona o opis wymieni trzy. W praktyce korzysta z kilkudziesięciu.
To jest właśnie natura wiedzy ukrytej. I dlatego pierwsza uczciwa odpowiedź na pytanie z tytułu powinna być: nie, nie da się jej przenieść do systemu w całości. Możemy zapisywać powtarzalne wzorce: co, gdzie i kiedy się wydarza. Możemy identyfikować zależności i przyczyny: dlaczego w konkretnej sali regularnie pojawia się podwyższona temperatura. Możemy rejestrować wczesne sygnały awarii: nietypowy dźwięk urządzenia, zmianę temperatury czy wzrost poboru energii. Możemy też łączyć pozornie niezwiązane obserwacje i szukać zależności, których wcześniej nie zapisywaliśmy. Warunek jest jeden: wiedzę trzeba przechwytywać wtedy, gdy powstaje, a nie próbować odtwarzać jej po fakcie w formularzu.
Są jednak elementy, których nie da się łatwo zamknąć w regułach. Pani Ania może rozpoznać, że stały użytkownik budynku potrzebuje dziś czegoś innego niż zwykle. Wie, kiedy warto zareagować, a kiedy lepiej najpierw obserwować. I tu pojawia się granica technologii. Model może wiedzieć, że okno w sali 8.12 jest otwarte, przewidzieć wpływ tego faktu na temperaturę i zużycie energii, a nawet zarekomendować jego zamknięcie. Nie ma jednak relacji z ludźmi ani troski o ich komfort, ponieważ nie może chcieć, żeby ludziom w tej sali było dobrze.
To rozróżnienie jest ważne. System może przejąć część wiedzy, ale nie musi i nie powinien przejmować całego ludzkiego osądu.
Co zyskamy, a co możemy stracić
Zyskamy kontekst. Dziś system mówi: „28 stopni”. Model, który korzysta z wiedzy pracowników, noże dodać „28 stopni, ponieważ otwarte jest okno, w sali odbyło się spotkanie zarządu, a we wtorki o tej porze zwykle pojawia się więcej osób”. Zyskamy ciągłość: wiedza przestanie wychodzić z budynku o 8:30 wraz z końcem zmiany i znikać przy każdej rotacji. Zyskamy szybsze wdrożenie nowych osób: zamiast trzech miesięcy poznawania budynku na własnych błędach będą mogły korzystać z wiedzy poprzedników. Zyskamy też dane potrzebne do raportowania ESG i CSRD, z których część już dziś istnieje, tylko nie jest systematycznie rejestrowana.
Ale trzeba też uczciwie powiedzieć, co możemy stracić, bo syntetyczna rzeczywistość ma swoją cenę.
Możemy stracić uwagę. Człowiek, który wie, że „system już to widzi”, przestaje patrzeć. To znany mechanizm w systemach o wysokim stopniu automatyzacji: część błędów nie znika, tylko przenosi się na moment, w którym człowiek przestaje aktywnie obserwować sytuację.
Jeśli model przejmie obserwację, ludzie mogą przestać dostarczać nowych informacji, a wtedy system przestanie się uczyć. W efekcie dostaniemy system, który zna budynek sprzed dwóch lat i coraz gorzej rozumie jego dzisiejsze funkcjonowanie.
Możemy stracić bliskość. Budynek bez gospodarza to budynek, w którym wszystko jest zrobione i ale nikt nie zna ludzi, którzy z niego korzystają. Pani Ania, która zna zespół z szóstego piętra, jest dla najemcy częścią tego, co nazywa się doświadczeniem miejsca. Dashboard tego nie zastąpi. Jeśli w pogoni za danymi zamienimy ludzi w sensory, stracimy część tego, co w usłudze najbardziej ludzkie.
Możemy wreszcie stracić coś, co co trudniej zmierzyć: godność pracy. Jeśli wiedza pani Ani trafi do modelu, a ona sama zostanie z niższą stawką i tabletem, który ją kontroluje, nie zbudowaliśmy inteligentnego budynku, lecz system, który wykorzystuje wiedzę człowieka, nie zwiększając wartości jego pracy. Model, który uczy się od człowieka, powinien człowiekowi coś oddawać: mniej pracy rutynowej, lepsze narzędzia, większą sprawczość albo możliwość wykonywania bardziej wartościowych zadań.
Dlatego pytanie nie brzmi: czy zbierać. Brzmi: jak zbierać, żeby ludzie chcieli dzielić się wiedzą i jak zbudować model, który jest dla nich, a nie przeciw nim.
Jak zbierać: organizacja notatek, obserwacji i uwag
Skoro wiedzę trzeba przechwytywać wtedy, gdy powstaje, kluczowe staje się pytanie: jak zrobić to tak, żeby nie zamienić pracy ludzi w wypełnianie kolejnych formularzy?
Przez lata próbowaliśmy zbierać wiedzę właśnie w ten sposób. Efekt był przewidywalny: formularze były wypełniane, ale najważniejsze obserwacje nadal zostawały w głowach pracowników. Dlatego poniższe zasady traktujemy nie jako teorię, ale jako praktyczny standard, który można wdrożyć w praktyce.
Zasada pierwsza: zbieramy przy pracy, nie po pracy
Obserwacja, która wymaga odejścia od wykonywanego zadania, zalogowania się do systemu i wypełnienia formularza, najczęściej nie zostanie zapisana. Obserwacja, która wymaga odejścia od wykonywanego zadania, zalogowania się do systemu i wypełnienia formularza, najczęściej nigdy nie powstanie. Notatka powinna zajmować nie więcej niż dziesięć sekund i być możliwa do wykonania bez przerywania pracy.
Zasada druga: trzy formaty i żadnych innych
Głos: pracownik naciska przycisk w aplikacji na tablecie lub telefonie i własnymi słowami mówi, co widzi,. Zdjęcie: jedno ujęcie tego, co „wygląda inaczej niż zwykle”. Dotknięcie: jeden przycisk „coś jest nie tak” i cztery kategorie do wyboru: czystość, technika, ludzie, bezpieczeństwo. Bez rozbudowanych formularzy i pól obowiązkowych.
Zasada trzecia: miejsce jest kluczem
Każde pomieszczenie, urządzenie i strefa dostają tag NFC lub kod QR, którego zeskanowanie otwiera notatkę już przypisaną do konkretnego miejsca. Pracownik nie musi więc pisać „sala na ósmym piętrze przy windzie”. System wie, gdzie powstała obserwacja. To prosty mechanizm, ale ma duże znaczenie dla późniejszego wykorzystania danych.
Zasada czwarta: rytm. Trzy momenty w tygodniu, w których wiedza ma szansę się ujawnić
Pierwszy to obchód poranny: pierwsze piętnaście minut zmiany przeznaczone na obserwację, jeszcze przed rozpoczęciem podstawowych prac. Drugi to przekazanie zmiany: pięć minut na informacje o tym, co tego dnia funkcjonowało inaczej niż zwykle, również rejestrowane w systemie. Trzeci to cotygodniowa odprawa zespołu: co się powtarza, co się zmieniło, co udało się przewidzieć, a czego nie.
Zasada piąta: potrzebne są role
Każdy może być obserwatorem, ale nie każdy powinien odpowiadać za interpretację wszystkich obserwacji. Brygadzista zmiany lub osoba odpowiedzialna za zmianę przegląda notatki i oznacza je: potwierdzam, sprawdzę, nieistotne. Koordynator obiektu cyklicznie porządkuje zebrany materiał i łączy obserwacje w wiedzę o budynku. Bez tej selekcji zbiór notatek szybko staje się zbiorem danych bez wartości.
Zasada szósta: notatka bez odpowiedzi umiera
To jedna z najważniejszych zasad całego procesu. Jeśli pracownik zgłasza obserwację i nic się z tym nie dzieje, przestaje widzieć sens w kolejnych zgłoszeniach. Dlatego każda notatka powinna w ciągu 48 godzin dostać informację zwrotną co z nią zrobiono, kto ją sprawdził i czy obserwacja się potwierdziła. Nawet odpowiedź „sprawdziliśmy, to nie to” buduje zaufanie do procesu. Ludzie nie oddają wiedzy w próżnię.
Zasada siódma: oceniamy sygnały, nie ludzi.
Liczba notatek nie może być KPI pracownika., Taki wskaźnik szybko prowadzi do tworzenia notatek dla samych notatek. Wartość mierzymy inaczej: sprawdzamy, ile obserwacji pomogło wcześniej wykryć problem, zapobiec awarii albo poprawić sposób działania. To jest miara wartości wiedzy, a nie posłuszeństwa wobec procedury.
Zasada ósma: język należy do pracownika
Notatka może być: po polsku, ukraińsku, angielsku, w języku potocznym i z błędami. Tłumaczenie, porządkowanie i łączenie informacji powinno być zadaniem systemu, systemu, a nie dodatkową pracą człowieka. Jeśli wymagamy od pracownika poprawnego językowo formularza, możemy wykluczyć z modelu właśnie tych ludzi, którzy mają najwięcej praktycznej wiedzy.
Wszystkie te zasady mają jeden wspólny cel: zebrać wiedzę bez odbierania ludziom czasu, sprawczości i odpowiedzialności za pracę. System ma ułatwiać dzielenie się doświadczeniem, a nie tworzyć kolejną warstwę administracji.
Model, który da się zrozumieć
Tu dochodzimy do warunku, bez którego całe zbieranie wiedzy traci sens i przejrzystość.
Pracownik będzie dzielił się swoją wiedzą tylko wtedy, gdy rozumie, co system z nią robi, i widzi, że służy ona również jemu, a nie wyłącznie organizacji To nie jest miękki postulat. To warunek działania systemu. Jeśli pracownicy przestaną ufać modelowi, przestaną dostarczać mu dane. A bez danych jego wartość zacznie spadać.
Co znaczy przejrzysty w praktyce? Sześć zasad
- Lustro. Każdy pracownik powinien widzieć, co system wie o „jego” obszarze pracy, skąd pochodzą te informacje i do czego są wykorzystywane. Powinien widzieć swoje notatki, ich status i ich wpływ. Zasada jest prosta: jeśli dane powstały dzięki pracy człowieka, człowiek powinien mieć do nich dostęp.
- Nie o Tobie. Dane obchodu, ślady z tabletu czy nagrania głosowe nie mogą służyć do ukrytej oceny czasu przerw, tempa pracy czy obecności. Cel wykorzystania danych powinien być jasno określony i zapisany w zasadach organizacji, a nie pozostawiony dobrej woli osoby zarządzającej systemem. Jedno użycie danych przeciwko pracownikowi może zniszczyć zaufanie do całego mechanizmu.
- Autorstwo. Wiedza ma źródło. Kiedy z dwudziestu obserwacji powstaje reguła „w sali 8.12 po spotkaniach zarządu sprawdź okno”, warto zachować informację, kto jako pierwszy zauważył ten wzorzec. To nie jest gadżet. To sposób na pokazanie, że praktyczna wiedza pracownika ma konkretną wartość i zostawia ślad w organizacji.
- Wyjaśnialność. Model nie powinien mówić tylko „priorytet 0,83”. Powinien potrafić wyjaśnić: „sprawdź 8.12, bo w sześciu z ostatnich ośmiu wtorków było tam otwarte okno, a wczoraj odbyło się spotkanie”. Pracownik powinien wiedzieć, dlaczego system rekomenduje określone działanie, i mieć możliwość zakwestionowania tej rekomendacji Taka korekta również jest cenną informacją dla systemu.
- Prawo do korekty. Jeśli model się myli, pracownik powinien móc oznaczyć to jednym ruchem i model to zapamięta. Korekta nie może być traktowana jako błąd pracownika, tylko jako kolejny element uczenia systemu. Ludzie chętniej dostarczają wiedzę, jeśli widzą, że system rzeczywiście potrafi się na jej podstawie zmieniać.
- Portfolio. Kiedy pracownik odchodzi, wiedza o budynku pozostaje w organizacji, ale zapis jego obserwacji, reguł i rozwiązań, które powstały dzięki jego pracy, może stać się również świadectwem jego kompetencji. To ważne zwłaszcza w pracy operacyjnej, gdzie wiele umiejętności pozostaje niewidocznych w formalnym CV. Jeśli system potrafi pokazać, jakie problemy pracownik rozpoznawał, jakie wzorce zauważał i jakie rozwiązania pomagał wypracować, zbieranie wiedzy przestaje być wyłącznie procesem dla organizacji. Staje się także inwestycją w człowieka.
Klient i dostawca: kto za co odpowiada?
Model wiedzy o budynku nie zadziała, jeśli zbuduje go tylko jedna strona. Dostawca ma ludzi i doświadczenie operacyjne. Klient ma budynek, jego kontekst i dostęp do danych systemowych. Podział odpowiedzialności musi być jasny od początku, bo inaczej pierwsza zmiana dostawcy albo pierwszy spór o dane może zniszczyć wypracowaną wiedzę.
Dostawca usługi odpowiada za proces zbierania wiedzy. To on organizuje pracę ludzi, ustala sposób rejestrowania obserwacji, dba o ich ochronę o odpowiada za rytm oraz jakość kuratorowania. Jego rolą jest również zapewnienie, że zasady „nie o tobie” i „lustro” są rzeczywiście przestrzegane. Dostawca odpowiada więc za metodę: jak wiedza jest zbierana, porządkowana i wykorzystywana do uczenia modelu.
Klient odpowiada za kontekst budynku. To on wie, że w przyszłym miesiącu trzecie piętro zmieni najemcę, że w środę na parterze odbędzie się wydarzenie albo że organizacja pracy najemcy zmienia się na cztery dni w tygodniu. Bez tych informacji model widzi skutki, ale nie zawsze rozumie ich przyczyny. Klient odpowiada również za dostęp do danych systemowych: BMS, czujników czy systemu zgłoszeń. Obserwacja człowieka i odczyt z systemu muszą być ze sobą połączone. Potrzebny jest więc jeszcze trzeci element: umowa o wiedzy. Dzisiejsze umowy FM szczegółowo opisują stawki, SLA, zakres usług i kary, ale często nie określają, co dzieje się z wiedzą o budynku, gdy zmienia się dostawca. To warto ustalić przed wdrożeniem.
Proponuję trzy proste zasady do zapisania w kontrakcie.
Wiedza o budynku zostaje przy budynku: Przy zmianie dostawcy klient zachowuje historię obserwacji, reguł i zależności wypracowanych dla obiektu. Nowy dostawca powinien móc z niej korzystać w ramach ustalonych zasad.
Wiedza o metodzie zostaje przy dostawcy: Sposób organizacji procesu, narzędzia czy reguły kuratorowania mogą pozostać jego know-how, o ile nie są elementem wiedzy specyficznej dla konkretnego obiektu.
Wiedza o człowieku zostaje przy człowieku: Zapis jego obserwacji należy do pracownika i nie powinien być automatycznie traktowany jako własność organizacji ani wykorzystywany bez zgody pracownika.
Potrzebny jest też stały mechanizm współpracy. Raz w miesiącu klient i dostawca powinni wspólnie przeglądać, czego budynek nauczył się w ostatnich tygodniach: jakie wzorce się potwierdziły, jakie reguły powstały i gdzie model nadal się myli. Można do tego dołączyć nowy wskaźnik w SLA: liczbę problemów wykrytych przez zespół przed zgłoszeniem ich przez użytkownika. To wskaźnik, który mierzy nie tylko wykonanie usługi, ale także zdolność organizacji do wcześniejszego zauważania problemów. W ten sposób wiedza przestaje być niewidocznym efektem ubocznym pracy ludzi i staje się świadomie zarządzanym zasobem z jasno określonymi zasadami, odpowiedzialnością i korzyścią dla obu stron.
Model do sprawdzenia już teraz: pilot w sprzątaniu
Wszystko, o czym pisałam, można sprawdzić w 90 dni w jednym budynku. Sprzątanie stanowi do tego idealny poligon: zespół jest w obiekcie codziennie, przechodzi przez wszystkie strefy, widzi zmiany, reaguje na problemy i ma dużą wiedzę, która dziś często nie trafia do żadnego systemu. Taki pilot nie wymaga dużego budżetu, ale przede wszystkim decyzji i jasnego zakresu odpowiedzialności.
Zakres: jeden budynek biurowy, dwa lub trzy piętra, jeden zespół liczący od ośmiu do dwunastu osób, jeden brygadzista pełniący funkcję kuratora oraz jeden koordynator po stronie klienta.
Sercem pilota jest prosty graf wiedzy. Na początek wystarczy sześć rodzajów węzłów i pięć rodzajów powiązań. Celem nie jest zbudowanie kompletnego modelu budynku, ale sprawdzenie, czy praktyczną wiedzę pracowników można systematycznie przechwytywać, porządkować i wykorzystywać.
Węzły. Miejsce: piętro, strefa, pomieszczenie lub urządzenie, każde przypisane do konkretnego identyfikatora. Obserwacja: co zauważono, zapisane w oryginalnym języku, z nagraniem lub zdjęciem. Przyczyna: hipoteza wyjaśniająca obserwację, a nie przyjęty z góry fakt, nie pewnik. hipoteza wyjaśniająca obserwację, a nie przyjęty z góry fakt. Działanie: co zostało zrobione. Skutek: co zmieniło się po działaniu. Osoba: kto dokonał obserwacji i w jakiej roli, bez oceny pracownika.
Powiązania. „Zaobserwowano w” łączy obserwację z miejscem. „Wyjaśnia” łączy hipotezę przyczyny z obserwacją. „Prowadzi do” łączy obserwację z działaniem, a działanie ze skutkiem. „Potwierdza” lub „obala” łączy skutek z wcześniejszą hipotezą przyczyny. To właśnie w tym miejscu system może się uczyć. „Powtarza się” łączy obserwację z czasem: dniem tygodnia, godziną, sezonem, zdarzeniem w kalendarzu klienta.
Przykład jednej ścieżki w grafie: Obserwacja „w 8.12 otwarte okno, 28 stopni” zostaje przypisana do miejsca „sala 8.12”. Hipoteza przyczyny „spotkanie zarządu wieczorem”. Działanie „sprawdzić okno przed 7:00 w środy”. Skutek „temperatura w normie w 5 z 5 śród”. Kolejne obserwacje mogą potwierdzić albo podważyć tę zależność. System zapisuje również, że obserwację zgłosiła Pani Ania. Z czasem z pojedynczych obserwacji zaczyna wyłaniać się wzorzec. Jeśli jest powtarzalny i potwierdza się w kolejnych sytuacjach, można zamienić go w regułę działania. Dopiero takie potwierdzone wzorce mogą stać się wartościowym źródłem wiedzy dla automatyzacji i robotyzacji.
Technologia. Niczego nie trzeba budować całego rozwiązania od podstaw. Większość potrzebnych elementów jest dostępna jako gotowe komponenty. Warstwa zbierania: smartfon lub tablet, który zespół już wykorzystuje w pracy. W naszym przypadku może być to EcoSystem, ale technicznie może to być dowolna aplikacja umożliwiająca szybkie nagranie głosu i wykonanie zdjęcia.. Do tego tagi NFC kody QR przypisane do pomieszczeń i urządzeń.
Warstwa rozumienia: transkrypcja mowy i model językowy, który z nagrania wyodrębnia miejsce, obserwację i hipotezę przyczyny. Pracownik nie powinien wypełniać pól formularza. System proponuje uporządkowany zapis, a pracownik potwierdza go jednym działaniem.
Warstwa pamięci: baza grafowa, a na etapie pilota nawet kilka połączonych tabel. Kluczowa jest struktura danych: miejsce, obserwacja, powiązanie, nie wybór konkretnego narzędzia.
Warstwa zwrotna: informacje, które wracają do ludzi. Po zeskanowaniu tagu na sali 8.12 pracownik widzi historię tego miejsca: ostatnie obserwacje, potwierdzone reguły i działania., Raz w tygodniu zespół dostaje krótkie podsumowanie: co budynek robił inaczej, co dało się przewidzieć i co nas zaskoczyło. To nie dodatek, lecz warunek utrzymania zaangażowania pracowników.
Warstwa integracji, dane z BMS, czujników i systemu zgłoszeń trafiają do tego samego modelu. Wtedy obserwacja „urządzenie brzmi inaczej” może zostać zestawiona z odczytem poboru prądu, historią awarii czy zgłoszeniem użytkownika. Można sprawdzić, co pojawiło się wcześniej i czy obserwacja pracownika była sygnałem wyprzedzającym awarię.
Miary sukcesu po 90 dniach: nie wystarczy policzyć, ile notatek powstało. Pilot powinien mierzyć zarówno jakość danych, jak i wartość dla pracy. Najważniejsze wskaźniki to: liczba obserwacji na zmianę, odsetek notatek które otrzymały odpowiedź w ciągu z 48 godzin, liczba problemów wykrytych przez zespół przed zgłoszeniem użytkownika, czas wdrożenia nowej osoby do pracy na danym piętrze rotacja w zespole pilotażowym w porównaniu z resztą obiektu oraz satysfakcja użytkowników mierzona w taki sam sposób jak przed wdrożeniem. Po 90 dniach powinniśmy umieć odpowiedzieć na trzy proste pytania: czy ludzie rzeczywiście dzielą się wiedzą, czy system potrafi zamieniać obserwacje w użyteczne wzorce i czy te wzorce poprawiają działanie budynku.
Zaproszenie
Piszę to przede wszystkim do klientów, bo bez ich decyzji ten model nie ruszy. Nie dlatego, że potrzebujemy kolejnego budżetu na technologię. Potrzebujemy budynku, jego kontekstu, dostępu do danych i zgody na to, żeby wiedzę ludzi potraktować jako zasób, którym warto świadomie zarządzać.
Co klient dostaje? Po pierwsze, pamięć obiektu, która nie znika przy rotacji pracowników ani przy zmianie dostawcy Zapisane obserwacje, zależności i sprawdzone reguły zostają przy budynku. Po drugie, wiedzę o tym, jak przestrzeń naprawdę jest używana. BMS pokaże temperaturę, zużycie energii czy liczbę osób w strefie. Nie powie jednak, że konkretna sala jest regularnie używana inaczej, niż zakładał projekt. Połączenie danych systemowych z obserwacjami ludzi może dać klientowi informacje przydatne przy decyzjach o metrażu, podziale stref czy modelu pracy. Po trzecie, uporządkowane dane operacyjne, które mogą zasilić raportowanie ESG i CSRD. Część potrzebnych informacji już dziś istnieje, ale pozostaje rozproszona między systemami, dokumentacją i doświadczeniem pracowników. Po czwarte, możliwość wcześniejszego wykrywania problemów. Nie dlatego, że model zastąpi czujniki, ale dlatego, że może połączyć sygnały z czujników z obserwacjami ludzi. Po piąte, krótszy czas wdrożenia nowych osób i większą ciągłość wiedzy w zespole. Jeśli wiedza o budynku nie jest wyłącznie w głowach kilku najbardziej doświadczonych pracowników, jej utrata nie musi oznaczać rozpoczynania wszystkiego od początku.
I wreszcie coś, czego nie da się kupić razem z gotowym robotem: własną historię danych o tym, jak naprawdę działa konkretny budynek. To ona może w przyszłości stać się podstawą skutecznej automatyzacji i robotyzacji.
Co klient daje? Dostęp do części danych systemowych, jednego koordynatora poświęcającego około dwóch godzin tygodniowo na pilot,, zgodę na oznaczenie pomieszczeń i urządzeń oraz jasne zasady dotyczące tego, do kogo należy wiedza o budynku, jak może być wykorzystywana i jak chroniona jest wiedza o pracownikach. Potrzebna jest też jedna rzecz, której nie da się zapisać w umowie: gotowość, żeby raz w miesiącu usiąść i posłuchać, czego budynek nauczył się od swoich użytkowników i pracowników.
Dlaczego warto teraz, a nie za dwa lata? Bo wiedza o budynku powstaje w czasie. Nie da się kupić dwóch lat historii obserwacji, zależności i potwierdzonych wzorców dzień przed wdrożeniem. Można kupić technologię. Nie można kupić doświadczenia, którego organizacja wcześniej nie zapisywała. Kto zacznie dziś, za dwa lata będzie miał nie tylko technologię, ale również własną bazę wiedzy o budynku i procesach, które w nim zachodzą. Kto zacznie za dwa lata, będzie musiał zacząć od zbierania tej wiedzy.
I jeszcze jeden powód, dla mnie ten najważniejszy. Pani Ania kiedyś odejdzie z tego budynku. Może odejść razem z siedmioma latami doświadczenia, których nie da się znaleźć w żadnym systemie. Możemy też zrobić coś innego: zapisać to doświadczenie, zachować jej autorstwo i sprawić, żeby część tej wiedzy została w budynku, a część wróciła do niej jako dowód kompetencji i dorobku.
Syntetyczna rzeczywistość może sprawić że to, co ludzkie stanie się częścią systemu. Ważne, żeby przy okazji nie przestało być własnością i dorobkiem ludzi, którzy tę wiedzę tworzą.
No items found.
Opublikowano:
25.09.2026
25.09.2026
.avif)
Aniela Ptak
Dodaj do ulubionych:
Polecane artykuły
Aniela Ptak
Więcej artykułów autora
Najnowsze wydanie!
%201%20(1).svg){kind=icon}
.avif)
Komentarz