Sådan planlægger I et skift af ejendomssystem trin for trin

Licensen på det gamle system udløber om ni måneder, leverandøren har varslet, at den ikke bliver forlænget på samme vilkår, og den eksport, I har fået tilsendt, er en flad fil med flere hundrede kolonner, hvor halvdelen hedder noget med "custom_field". Samtidig kører opkrævningen den 1. hver måned, og ingen kan huske, hvorfor tre lejemål har en manuel rettelse, der har stået der siden 2019. Det er den situation, et skift af ejendomssystem reelt handler om: ikke at vælge nyt, men at flytte otte års drift fra ét sted til et andet uden at opkrævningen stopper undervejs.

Denne artikel forudsætter, at valget er truffet. Hvis I stadig er i gang med kravspecifikation og leverandørsammenligning, dækker vores komplette guide til software til ejendomsadministration den del. Her handler det udelukkende om selve migreringen: hvad der skal ud af det gamle system, hvordan det kommer ind i det nye, og hvordan I beviser, at det er rigtigt, inden I slukker for det gamle.

Trin 1: Frys og eksportér, inden I rører noget

Det første, I gør, er at tage et komplet øjebliksbillede af det gamle system på en kendt dato, typisk dagen efter en gennemført opkrævning. Alt, hvad der sker i det gamle system efter denne dato, logges separat, så det kan efterføres. Sørg for at få følgende ud som strukturerede filer, ikke som PDF-rapporter:

• Lejemålsregistret med arealer, anvendelse og tilknytning til ejendom og ejerselskab
• Lejerstamdata inklusive CVR, kontaktpersoner og betalingsoplysninger
• Aktive kontrakter med reguleringshistorik, ikke kun den aktuelle leje
• Åbne poster, depositum og forudbetalt leje pr. lejemål
• Dokumentarkivet med en nøgle, der knytter hvert dokument til et lejemål
• Fakturahistorik for mindst de seneste to reguleringsperioder

Reguleringshistorikken er den post, flest glemmer. Uden den kan det nye system ikke genberegne lejen bagud, og så kan I heller ikke kontrollere, om den leje, I har opkrævet, faktisk stemmer med kontrakten.

Trin 2: Feltmapping er den tunge del af et skift af ejendomssystem

Det gamle system har gemt viden på tre måder: i rigtige felter, i fritekstfelter og i hovedet på den medarbejder, der har siddet med det længst. Mappingdokumentet skal fange alle tre. Opret et regneark med én række pr. kildefelt og angiv for hvert felt, hvilket målfelt det lander i, hvilken transformation der kræves, og hvad der sker med værdier, der ikke kan oversættes.

De typiske problemfelter i et skift af ejendomssystem er indeksklausuler beskrevet i fritekst, optioner uden strukturerede frister og fordelingsnøgler for fællesomkostninger, der er gemt som kommentarer på fakturalinjer. Hver af dem skal læses, fortolkes og tastes ind som felter i VemLease. Det er manuelt arbejde, og det skal budgetteres som sådan. Erfaringen fra den oprindelige gennemgang af porteføljen gælder stadig: 20 til 30 procent af projekttimerne bør ligge i afstemning og undtagelseshåndtering, ikke i selve filoverførslen.

Afgør også her, hvad I ikke tager med. Afsluttede kontrakter ældre end den periode, revisionen kræver, kan arkiveres som dokumenter frem for at migreres som data. Hvert felt, I undlader at flytte, er et felt, I ikke skal afstemme.

Trin 3: Testimport på ét aktiv med alle kontrakttyper

Kør den første import på et enkelt aktiv, der indeholder så mange forskellige kontrakttyper som muligt, gerne et center med både omsætningsleje og fast leje. Lad derefter det nye system beregne den aktuelle leje for hvert lejemål og sammenlign linje for linje med det senest fakturerede beløb fra det gamle system.

Forvent afvigelser. Når kontrakter indlæses struktureret og lejen genberegnes fra klausulerne, afviger resultatet typisk fra det fakturerede på 5 til 10 procent af lejemålene. Hver afvigelse falder i én af tre kategorier: fejl i mappingen, fejl i den gamle opkrævning eller en bevidst aftale, der aldrig blev dokumenteret. Kategoriseringen er vigtig, fordi kun den første type skal rettes i importen. De to andre skal rettes i virkeligheden, og det er en beslutning for asset manageren og i nogle tilfælde for juristen.

Først når testaktivet går igennem uden ukendte afvigelser, låser I importskabelonen og kører resten af porteføljen. Hvis skabelonen ændres undervejs, skal testaktivet importeres igen.

Trin 4: Parallel drift i mindst to opkrævninger

Parallel drift betyder, at begge systemer genererer opkrævningsgrundlaget, men kun det gamle sender fakturaer. Efter hver kørsel sammenlignes de to grundlag, og alle forskelle forklares skriftligt. Planlæg mindst to fulde opkrævninger; én er ikke nok, fordi den første kørsel næsten altid afslører rettelser, der først kan verificeres i den næste.

Parallelperioden er også tidspunktet for at få integrationerne til at køre i praksis. Bogføringen fra VemLease til økonomisystemet skal afstemmes mod hovedbogen i parallelperioden, så den første rigtige måned ikke er den første test. For handelsejendomme skal lejerne onboardes til omsætningsrapportering i VemTenant nu, så der ligger mindst én rapporteringsperiode klar ved go-live, og den første rykkerrunde er overstået, mens det gamle system stadig er sikkerhedsnet. Hvis I kobler besøgsdata fra VemCount på, så sørg for, at den historik, der importeres, er mærket med den nøjagtighed, der gælder: kontraktligt minimum 96 procent, typisk 98 til 99 procent, når lys, indretning og besøgsadfærd tillader det.

Trin 5: Vælg go-live-dato efter reguleringscyklus og tag cutover i én omgang

Go-live lægges i et kvartal med få reguleringer og få fornyelser. Hvis hovedparten af porteføljen reguleres 1. januar, er en go-live midt i december den værste tænkelige dato. Selve cutover-planen bør kunne stå på én side:

• Sidste opkrævning fra det gamle system køres og afstemmes
• Det gamle system sættes til læseadgang, så ingen kan taste videre ved en fejl
• Ændringsloggen fra frysedatoen efterføres i det nye system og kontrolleres
• Åbne poster og depositumsaldi afstemmes mod økonomisystemet pr. lejemål
• Første opkrævning fra det nye system godkendes af en person, der ikke har siddet med importen

Det sidste punkt er bevidst. Den, der har tastet undtagelserne, kender dem for godt til at se, hvad der mangler.

Trin 6: De første 90 dage og nedlukning af det gamle

Behold læseadgang til det gamle system i mindst en reguleringsperiode efter go-live, så tvivlsspørgsmål kan slås op. Planlæg anden uddannelsesrunde omkring tre måneder efter go-live, når brugerne har konkrete spørgsmål frem for generelle. Og sæt en dato for, hvornår den gamle licens opsiges, og arkivet overføres til et format, revisionen kan tilgå uden leverandørens system. En implementering af ejendomssystem er først færdig, når det gamle system kan slukkes, uden at nogen bliver nervøse.

Ofte stillede spørgsmål

Hvor lang tid tager et skift af ejendomssystem? Det afhænger mere af kontrakternes kompleksitet end af antallet af lejemål. En portefølje med omsætningsleje, trappelejeaftaler og uklare indeksklausuler kræver længere tid til mapping og afstemning end en ensartet boligportefølje med mange enheder. Planlæg bagfra fra en go-live-dato med få reguleringer, og lad parallelperioden på mindst to opkrævninger være fast.

Skal al historik migreres? Nej. Reguleringshistorik og fakturahistorik for de seneste to reguleringsperioder skal med som data, fordi de bruges til afstemning. Ældre afsluttede kontrakter kan arkiveres som dokumenter med en nøgle til lejemålet, hvilket sparer både importtid og afstemningstid.

Hvad gør vi med afvigelser, der viser sig at være fejl i den gamle opkrævning? De skal ikke rettes i importen, men behandles som sager. Lejere, der har betalt for meget, er en juridisk risiko, og lejere, der har betalt for lidt, kræver en beslutning om efteropkrævning. Dokumentér hver sag skriftligt i parallelperioden, mens begge systemer stadig kan slås op.

Står I foran at flytte en portefølje fra et eksisterende system til VemLease og vil have en gennemgang af feltmapping, parallel drift og cutover baseret på jeres egne kontrakttyper, så kontakt Vemco Group her.