Byta fastighetssystem: steg-för-steg-plan för migrering och go-live

Avtalet med den gamla leverantören löper ut om tio månader, det nya systemet är upphandlat och någon har skrivit "migrering" som en enda rad i projektplanen. Samtidigt pågår en debiteringskörning varje månad, hyresgäster rapporterar omsättning, och ingen i förvaltningen kan avvaras på heltid. Det är den situation de flesta befinner sig i när de ska byta fastighetssystem, och det är därför bytet behöver en egen plan, skild från valet av system. Den här artikeln går igenom just den planen: hur ni fryser det gamla, flyttar datan i kontrollerade omgångar, kör parallellt utan att tappa greppet och stänger det gamla systemet på ett datum ni faktiskt håller.

Steg 1: Sätt ett frysdatum för det gamla systemet

Innan en enda rad flyttas behöver ni bestämma från vilket datum det gamla systemet inte längre får ändras utan logg. Utan frysdatum migrerar ni ett rörligt mål: en förvaltare justerar en indexklausul på tisdagen, ekonomi rättar en hyresavi på torsdagen, och den testmigrering ni gjorde på måndagen stämmer inte längre med något. Praktiskt innebär frysningen att alla ändringar i avtal, hyresgäster och ytor efter datumet registreras i en gemensam ändringslista, som sedan spelas in i det nya systemet i samband med sista lasten.

Utse samtidigt en dataägare per område: avtal, debitering, ytor och objekt, hyresgästkontakter, omsättningsrapportering. Dataägaren är den som godkänner att området är rätt i det nya systemet. Utan den rollen hamnar beslutet om "stämmer det här?" hos projektledaren, som sällan är den som kan svara.

Steg 2: Mappa fält för fält och bestäm vad som inte följer med

Exportera hela datamodellen från det gamla systemet, inte bara de tabeller leverantören föreslår. Lägg sedan upp en mappningsmall där varje källfält får ett av fyra beslut: flyttas som det är, flyttas med omräkning, flyttas till fritextfält för senare granskning, eller flyttas inte. Den fjärde kategorin är viktigast och mest försummad. Historiska avier från före ett visst år, nedlagda hyresgäster utan öppna fordringar, interna anteckningsfält som ingen använt på flera år: besluta aktivt att de stannar i ett arkiv i stället för att låta dem förorena det nya systemet.

De fält som brukar kräva omräkning är datumformat, momsbehandling, yttyper och framför allt omsättningsdefinitioner. Om era avtal definierar omsättning olika, med eller utan moms, med eller utan returer, måste det nya systemet kunna hålla definitionen per hyresgäst. Med VemTenant sätts den definitionen per avtal, vilket gör att mappningen blir en kolumn i mallen i stället för ett ärende efter go-live. Den som vill ha en bredare bild av vilka funktioner som ska finnas på plats innan bytet planeras kan läsa vår kompletta guide till fastighetsförvaltningssystem; här håller vi oss till själva flytten.

Steg 3: Testmigrera i omgångar och bygg en regelbok

Gör aldrig en enda stor last. Kör i stället minst tre testmigreringar till en testmiljö, med växande omfång. Första omgången: de tjugo största avtalen mätt i årshyra, migrerade manuellt och kontrollerade fält för fält av en person från förvaltning och en från ekonomi tillsammans. Varje avvikelse ni hittar skrivs in i en regelbok: "indexklausul i fritext med ordet basmånad tolkas så här", "tilläggsavtal i PDF registreras som separat avtalsrad". Andra omgången: en hel pilotfastighet, gärna en med ankarhyresgäster, små lokaler och minst ett omsättningsavtal, eftersom det villkoret belastar hela kedjan från rapportering till faktura. Tredje omgången: hela portföljen, maskinellt, med regelboken som facit.

Acceptanskriteriet för varje omgång är detsamma: en simulerad debiteringskörning i det nya systemet ska stämma mot det gamla på kronan för den migrerade mängden. Klausuler som inte går att tolka entydigt markeras "kräver juridisk granskning" i stället för att gissas. Räkna med att den egna organisationen, inte systemet, blir flaskhalsen, och boka dataägarnas tid i kalendern innan första testlasten.

Steg 4: Parallellkörning med slutdatum

När tredje testlasten är godkänd flyttar ni till produktionsmiljön och kör båda systemen parallellt under ett bestämt antal debiteringscykler. En rimlig tumregel är två fulla månadskörningar, eller en kvartalskörning om ni fakturerar kvartalsvis, så att minst en indexjustering eller en omsättningsavräkning hinner passera. Jämför inte bara totalsummor utan också antal avirader per fastighet, momsbelopp och de avtal som fått manuella rättningar under perioden. Allt som skiljer sig förklaras skriftligt, och förklaringen avgör om felet ligger i migreringen, i regelboken eller i det gamla systemet, vilket händer oftare än man tror.

Parallellkörning gäller även sensordata. Om besöksräkning kopplas in i samband med bytet, låt sensorerna gå minst två veckor jämsides med manuella stickprov innan siffrorna visas för hyresgäster. Kräv ett avtalat lägsta mätvärde av leverantören; för VemCount är det kontraktuella minimumet 96 procent, och i praktiken ligger noggrannheten normalt på 98 till 99 procent när ljus, entréns utformning och besökarnas rörelsemönster tillåter det. Ingen seriös leverantör utlovar ett fast tal utan förbehåll.

Det vanligaste felet i den här fasen är att parallellkörningen aldrig tar slut, eftersom ingen vågar fatta beslutet. Skriv därför slutdatumet i projektplanen redan nu och koppla det till att det gamla systemet sätts i läsläge, inte stängs av helt. Då finns historiken kvar för revision utan att någon frestas att fortsätta registrera där.

Steg 5: Go-live-helgen och de första 90 dagarna

Lägg go-live direkt efter en avslutad debiteringskörning, aldrig i veckan före bokslut. Själva övergången följer en fast ordning: slutlig export från det gamla systemet, inspelning av ändringslistan från frysdatumet, sista last, avstämning mot kontrollsummor, godkännande från varje dataägare, och först därefter öppnas det nya systemet för förvaltarna. Med VemLease ligger avtalens livscykel, förnyelsebevakning och vakansuppföljning i samma datamodell, vilket gör att ni inte behöver synkronisera flera register under själva helgen.

Under de första 90 dagarna är tre saker avgörande. Rapportpaketen till ledning och ägare ska produceras ur det nya systemet från första kvartalet, annars lever kalkylbladen vidare. Hyresgästernas omsättningsrapportering behöver automatiska påminnelser från dag ett, eftersom disciplinen annars sjunker inom några månader. Och förvaltarna ska ha varit med och utformat sina egna vyer redan under parallellkörningen; att implementera fastighetssystem som bara ekonomi känner igen sig i är det säkraste sättet att få ett system för registrering men inte för beslut.

Att byta fastighetssystem är ett dataprojekt, inte ett IT-projekt

Den röda tråden genom alla fem stegen är att det är avtalsdatan, inte tekniken, som avgör om bytet lyckas. Systemleverantören kan installera och konfigurera, men bara er egen förvaltning kan säga vilken version av uppsägningstiden som gäller för lokal 2:14. Planera därför tiden för dataägarna lika noggrant som tiden för konsulterna, och mät bytet med samma mått som ni skulle mäta vilken förvaltningsprocess som helst: stämmer debiteringen, hittar förvaltarna sina avtal och går kvartalsrapporten att ta fram utan manuell bearbetning.

Vanliga frågor

Hur lång tid tar det att byta fastighetssystem? Det beror på antal avtal, hur strukturerad datan är i det gamla systemet och hur mycket tid förvaltning och ekonomi kan avsätta. En bra tumregel är att räkna med dubbelt så lång tid för datamigreringen som leverantören uppskattar, och att lägga minst två debiteringscykler på parallellkörning.

Ska vi migrera all historik eller bara aktiva avtal? Migrera aktiva avtal, öppna fordringar och den historik som behövs för indexberäkning, omsättningsavräkning och revision. Äldre avier och avslutade hyresgäster utan öppna poster hör hemma i ett läsbart arkiv, inte i det nya systemets produktionsdata.

När kan vi stänga av det gamla systemet? När parallellkörningen har levererat minst två debiteringskörningar som stämmer på kronan och varje dataägare har godkänt sitt område skriftligt. Sätt det gamla systemet i läsläge på det datum ni bestämt i förväg, och behåll det så tills revisionen för övergångsåret är klar.

Står ni inför ett systembyte och vill ha hjälp att lägga upp migrering, parallellkörning och go-live för er portfölj? Kontakta Vemco Group så går vi igenom er avtalsstruktur och tar fram en migreringsplan med acceptanskriterier för varje steg.