Der står typisk mellem tre og otte systemer i en dansk ejendomsvirksomhed. Administrationssystemet, økonomien, noget til vedligehold, en beboerapp, måske en IoT-platform, og et regneark der i praksis holder det hele sammen. De virker. De blev betalt. Og alligevel er der sjældent nogen der kan svare på, hvad det samlede setup har givet.
Det er værd at sige rent ud: hvis I har brugt penge på PropTech og ikke kan pege på hvad I fik, så er I ikke et særtilfælde. I er det typiske tilfælde. Og forklaringen er som regel ikke den I forventer.
Systemet er sjældent problemet
Når et PropTech-projekt ikke leverer, går reflekset til leverandøren. Softwaren var ikke god nok, konsulenten forstod ikke branchen, implementeringen var sjusket. Nogle gange passer det. Langt oftere gør det ikke.
De fleste systemer gør præcis det, de blev solgt til at gøre, hver for sig. Værdien skulle komme fra helheden, og helheden var der aldrig nogen der købte. Den blev antaget.
Prøven: spørg hvem der er ansvarlig for at data kommer korrekt fra administrationssystemet over i vedligeholdssystemet. Hvis svaret er en pause, har I fundet problemet. Det er ikke et softwareproblem.
Fem grunde til at PropTech ikke bliver brugt
1. Systemerne blev købt hver for sig
Hvert enkelt indkøb var fornuftigt da det blev lavet. Forskellige år, forskellige behov, forskellige beslutningstagere. Ingen traf en dårlig beslutning. Summen er alligevel et rod, fordi ingen af beslutningerne blev truffet med de andre i hånden. Det er ikke inkompetence, det er tid.
2. Ingen ejer helheden
Administrationssystemet hører til hos bogholderiet, vedligeholdssystemet hos ejendomsmesteren, beboerappen hos den der stod for kommunikationen. Alle ejer deres eget. Ingen ejer grænsefladerne imellem dem. Og det er præcis i grænsefladerne at værdien enten opstår eller forsvinder.
3. Data blev aldrig ryddet op
Migreringen blev kørt som den var. Lejemål der optræder under to navne, kontrakter med datoer der ikke stemmer, arealer der mangler, leverandører stavet på fire måder. Det forhindrer ikke systemet i at køre. Det forhindrer enhver rapport i at være til at stole på. Og en rapport ingen stoler på, bliver brugt præcis én gang.
4. Driften blev ikke spurgt
De folk der rent faktisk skal registrere arbejdet, blev inddraget til sidst, og kun i form af oplæring. Viceværten beholder sit regneark, fordi det tager tyve sekunder, hvor systemet tager fire minutter og kræver at han finder lejemålsnummeret først. Det er ikke modstand mod forandring. Det er hovedregning, og han regner rigtigt.
5. I målte på implementering, ikke på brug
Projektet blev erklæret færdigt den dag systemet gik i luften. Der blev holdt et afsluttende møde, og succeskriteriet var leverance. Ingen målte hvor mange der stadig loggede ind tre måneder senere. Havde nogen gjort det, havde I opdaget problemet mens det stadig var billigt at rette.
Den ubehagelige del
Det er ikke leverandørens skyld. Det er ubehageligt, fordi det betyder at I ikke kan løse det ved at skifte leverandør.
Den dyreste version af dette problem er at købe et nyt system oven på et der ikke bliver brugt. Det sker ofte, fordi et indkøb er en synlig handling der føles som fremdrift, hvor oprydning i data og ejerskab er usynligt arbejde ingen får ros for. Men et nyt system arver alle fem problemer ovenfor, og lægger et sjette oveni.
Hvis et system ikke bliver brugt, er sandsynligheden for at det næste system bliver brugt ikke højere. Den er lavere, fordi organisationen nu har lært at nye systemer ikke betyder noget.
Sådan måler I hvor galt det står
Man behøver ikke en analyse for at finde ud af det. Fire spørgsmål er nok, og de tager en formiddag at besvare ærligt.
| Spørgsmål | Sundt svar | Svaret I sandsynligvis får |
|---|---|---|
| Hvor mange logger ind om ugen? | Et tal, hentet fra systemet | “Det tror jeg de fleste gør” |
| Hvor skrives data ind to gange? | En kort, konkret liste | “Det er der vist et par steder” |
| Hvem retter fejl i stamdata? | Et navn | Tavshed, eller “det gør vi vel alle sammen” |
| Hvilken beslutning traf I sidst på en rapport herfra? | En konkret beslutning | Ingen, eller en fra sidste år |
Kan I ikke svare på det første spørgsmål med et tal, er det i sig selv svaret. Ingen har kigget efter, og så er der heller ingen der har opdaget det.
Hvad man rent faktisk gør ved det
Rækkefølgen er det vigtigste, og den er den modsatte af den man som regel bliver tilbudt:
- Vælg én arbejdsgang, ikke et system. Følg for eksempel en fejlmelding fra beboeren skriver den, til fakturaen er betalt. Hele vejen, på tværs af de systemer den passerer.
- Find hvor der skrives af. Hvert sted nogen kopierer fra en skærm til en anden, er enten en integration der mangler eller et system for meget. Det er den mest brugbare liste I kan lave.
- Sæt navn på grænsefladerne. Ikke en afdeling, et navn. En person der er ansvarlig for at data kommer korrekt fra A til B.
- Ryd kun de data op der skal bruges. Ikke hele arkivet. De felter den ene rapport har brug for, og så videre derfra. Total oprydning bliver aldrig færdig.
- Mål brug efter seks uger. Ikke tilfredshed. Brug. Antal logins, antal registreringer, antal sager der kom hele vejen igennem.
Det er ikke et spændende program, og det kræver heller ikke et stort budget. Det kræver til gengæld at nogen har mandat til at bede folk om at ændre en vane, og det er som regel dér det går i stå.
Er I usikre på hvad ordet overhovedet dækker, før I går i gang, så start med den korte forklaring af hvad PropTech er. Skal I have styr på tallene på tværs af porteføljen, er det ejendomsdata, analyse og dashboards der er opgaven, og vil I lægge AI oven på bagefter, er rækkefølgen beskrevet på siden om AI til ejendomsbranchen.
Skal nogen se på det udefra?
Vi sælger ikke systemer og får ikke provision fra leverandører. Vi kortlægger hvad I har, hvor det går i stå, og hvad der skal ske for at det bliver brugt.
Paw Lundin
Stifter af Digital Forlomme. 15+ års erfaring med digitalisering, først som intern leder, nu som rådgiver. Underviser, implementerer og rådgiver.
Ofte stillede spørgsmål
Hvorfor bliver vores PropTech-systemer ikke brugt?
Fem årsager går igen: systemerne blev købt hver for sig af forskellige beslutningstagere, ingen ejer grænsefladerne imellem dem, data blev migreret uden oprydning, driften blev inddraget for sent, og projektet blev målt på implementering frem for på faktisk brug. Ingen af dem er softwareproblemer, og derfor løses de heller ikke ved at skifte leverandør.
Er det leverandørens skyld?
Sjældent. De fleste systemer gør præcis det, de blev solgt til at gøre, isoleret set. Værdien skulle komme fra helheden, og helheden var der ingen der købte eller tog ejerskab på. Det er ubehageligt, fordi det betyder at problemet ikke kan løses ved at skifte leverandør.
Skal vi købe et nyt system i stedet?
Det er den dyreste udvej. Et nyt system arver de samme fem problemer og lægger et sjette oveni, fordi organisationen nu har lært at nye systemer ikke betyder noget. Sandsynligheden for at det næste system bliver brugt er lavere end for det forrige, ikke højere.
Hvordan finder vi ud af hvor galt det står?
Fire spørgsmål rækker: hvor mange logger ind om ugen, hvor skrives data ind to gange, hvem retter fejl i stamdata, og hvilken beslutning traf I sidst på baggrund af en rapport fra systemet. Kan I ikke svare på det første med et tal hentet fra systemet, er det i sig selv svaret.
Hvad koster det at rette op?
Typisk mindre end man tror, fordi løsningen sjældent er ny software. Det koster tid til at følge én arbejdsgang hele vejen igennem, kortlægge hvor der skrives af mellem systemer, sætte navn på grænsefladerne og rydde de data op der faktisk skal bruges. Den dyre del er ikke værktøjer, det er mandat til at bede folk ændre en vane.
Hvor lang tid går der før man kan se en effekt?
Mål brugen efter seks uger, ikke tilfredsheden. Antal logins, antal registreringer og antal sager der kom hele vejen igennem uden manuel hjælp. Er de tal ikke flyttet sig efter halvanden måned, er arbejdsgangen ikke lagt om, og så flytter de sig heller ikke efter et halvt år.