Kvartalsgenomgången börjar med att tre siffror inte stämmer överens. Ekonomiavdelningens uthyrningsgrad säger 94,2 procent. Uthyrningschefens kalkylblad säger 92,8. Styrelsepresentationen från förra kvartalet säger 95,1, och ingen vet längre vilken definition den byggde på. Samtidigt visar det sig att en hyresgäst i ett handelsområde hade en förlängningsoption som skulle sägas upp senast den 31 mars, och att datumet passerade utan att någon reagerade. Det är i det ögonblicket behovet av ett nytt fastighetssystem slutar vara en IT-fråga och blir en fråga om kapitalavkastning.
Den här texten är skriven för dig som redan läst de generiska köpguiderna och vet att "molnbaserat" och "användarvänligt" inte hjälper dig att skilja två leverantörer åt. Här går vi igenom vad som faktiskt avgör om ett system betalar för sig i en kommersiell eller blandad portfölj, och vilka frågor som avslöjar svagheter redan under demon.
Börja med besluten, inte med funktionslistan
De flesta upphandlingar startar med en kravspecifikation på 200 rader där allt är "ska-krav". Resultatet blir att varje leverantör bockar för allt, och att valet till slut sker på pris och magkänsla. Vänd på ordningen. Lista i stället de tio till femton beslut som din organisation fattar varje månad och som i dag tar för lång tid eller fattas på osäkert underlag:
- Vilka hyresavtal löper ut inom 18 månader, och vilka har optioner som kräver aktivt agerande från oss?
- Vilken hyresgäst i vilket läge ligger under marknadshyra, och med hur mycket?
- Vilka vakanser kostar mest per månad, räknat i utebliven hyra plus driftskostnader som inte kan fördelas?
- Hur ser omsättningshyran ut mot fast hyra per butik, och var är brytpunkten nådd?
- Vilken indexuppräkning ska faktureras från vilket datum, och vad blir effekten på årets driftnetto?
Be sedan varje leverantör visa exakt hur systemet svarar på tre av frågorna, med era egna avtal inlästa. Ett system för kommersiell fastighetsförvaltning som inte kan producera svaren utan manuell export till Excel har redan misslyckats med grunduppgiften.
Hyresadministration är ryggraden – ställ hårda krav
Allt annat i ett fastighetssystem bygger på att hyresavtalen är korrekt registrerade. Därför ska ett hyresadministrationssystem bedömas på hur det hanterar avtalets hela livscykel, från förhandling via tillägg och indexering till uppsägning eller förlängning. Konkreta saker att kontrollera:
- Optioner som strukturerad data. Förlängningsoptioner, uppsägningstider och hyresgästens rätt att säga upp i förtid måste vara egna fält med datum och ansvarig person, inte fritext i en anteckningsruta. Fritext går inte att larma på.
- Tilläggsavtal med versionshistorik. När ett tillägg ändrar yta, hyra eller löptid ska det ursprungliga avtalet finnas kvar och skillnaden vara spårbar. Vid en due diligence är detta det första en köpares rådgivare frågar efter.
- Vakanshantering som kostnadspost. En tom lokal ska ha ett startdatum, en beräknad återuthyrningstid och en löpande kostnad, så att vakanser kan rangordnas och prioriteras i uthyrningsarbetet.
- Analys på portföljnivå. Löptidsprofil, hyresspridning per fastighet och andel avtal med omsättningskomponent ska gå att ta fram utan att bygga rapporten själv.
Verktyg som VemLease är byggda just kring den här kedjan: kontraktens livscykel, bevakning av förlängningar, vakanshantering och uthyrningsanalys i samma datamodell. Poängen är inte varumärket utan principen: när avtalet är källan behöver rapporten inte avstämmas mot något annat.
En erfarenhet från implementeringar som sällan står i broschyren
Den största kostnaden i ett systembyte är nästan aldrig licensen. Det är datamigreringen, och närmare bestämt upptäckten att de befintliga avtalsabstrakten är fel. I praktiskt taget varje portfölj vi har sett innehåller mellan fem och femton procent av avtalen avvikelser mellan det som står i det gamla systemet och det som står i det signerade dokumentet: en indexklausul med fel basmånad, en option som aldrig registrerades, en yta som ändrades vid ombyggnad men inte uppdaterades. Budgetera därför tid för att stämma av varje avtal mot originaldokumentet innan det läses in, och kräv att leverantören visar hur importen validerar datum och belopp. Ett system som glatt accepterar ett slutdatum före startdatum kommer att göra samma sak med era data.
Bostadsportföljer: vad du ska kräva utan att låta leverantören definiera behovet
Många läsare förvaltar både kommersiella ytor och bostäder. Där lockar leverantörer gärna med hyresgästportaler, felanmälan via app och digital signering. Det är nyttiga funktioner, men bedöm dem utifrån samma logik som ovan: vilket beslut blir bättre? En portal som tar emot felanmälningar men inte kopplar kostnaden till rätt lägenhet och rätt fastighet ger dig ingen bättre bild av var underhållsskulden växer. Kräv att all hyresgästinteraktion landar i samma avtals- och objektsregister som resten av portföljen, att omflyttningar uppdaterar vakansdata automatiskt, och att du äger exporten av all historik om ni byter leverantör igen om sju år. Om systemet inte kan visa omsättningstakt per fastighet och genomsnittlig tid från uppsägning till ny inflyttning är det en kommunikationskanal, inte ett förvaltningsverktyg.
Rapportering som ägaren faktiskt behöver
Ett rapporteringsverktyg för fastigheter bedöms bäst på en enda sak: kan finanschefen och uthyrningschefen öppna samma rapport och få samma siffra? Det kräver gemensamma definitioner i systemet. Är uthyrningsgraden räknad på yta eller hyresvärde? Ingår avtal som är signerade men inte tillträdda? Räknas en lokal under ombyggnad som vakant? Ett bra system tvingar er att bestämma detta en gång och sedan låsa definitionen, så att varje månadsrapport är jämförbar med den föregående.
För handelsfastigheter tillkommer två datakällor som förändrar vad rapporteringen kan säga. Den första är hyresgästernas omsättning. Med VemTenant rapporterar butikerna sina försäljningssiffror in i systemet, vilket gör att omsättningshyra kan beräknas utan manuella underlag och att butiker kan jämföras mot varandra per kvadratmeter. Den andra är besöksflödet. När VemCounts besöksdata kopplas till hyres- och omsättningsdata kan ägaren se konverteringen per läge – hur stor andel av dem som passerar en butik som faktiskt genererar försäljning – och använda det i hyresförhandlingen. Räkningsnoggrannheten ligger kontraktsmässigt på minst 96 procent och i praktiken oftast på 98 till 99 procent när belysning, lokalens utformning och besökarnas rörelsemönster tillåter det. Det är tillräckligt för att fatta beslut om hyresnivåer och lokalmix, men den som lovar en garanterad siffra utan förbehåll bör få följdfrågor.
Integrationer och ägande av data
Ett system för kommersiella hyresavtal lever aldrig ensamt. Det ska skicka hyresavier till ekonomisystemet, ta emot betalningsstatus tillbaka, och exportera avtalsdata till värderare och banker i ett format de kan läsa. Fråga inte "har ni API?" utan "visa mig en kund som kör månadsstängning mot samma ekonomisystem som vi har, och beskriv vad som går fel när det går fel". Be också om ett skriftligt svar på vad som händer med era data när avtalet med leverantören upphör: format, tidsfrist och kostnad för uttag. Hyresavtalshantering är kärndata i er verksamhet; den ska aldrig vara låst hos någon annan.
Räkna på totalkostnaden över fem år
Jämför inte årslicenser. Jämför summan av licens, implementering, datamigrering, integrationer, utbildning och intern tid över fem år, och ställ den mot värdet av det ni faktiskt ska uppnå: färre missade optioner, snabbare återuthyrning, korrekt indexering från första möjliga månad och en due diligence som tar dagar i stället för veckor. En enda missad uppsägning av en förlängningsoption på en välbelägen butikslokal kan kosta mer i utebliven hyreshöjning än hela systemets årsavgift. Det är den kalkylen styrelsen förstår, och det är den som bör styra valet.
Vill du diskutera hur hyresavtal, hyresgästomsättning och besöksdata kan samlas i en gemensam bild för din portfölj? Kontakta oss på vemcogroup.com/contact-us så går vi igenom era avtal, era rapporteringsbehov och vad ett systembyte realistiskt kräver av organisationen.