Markedet for ejendomsadministrative systemer har været præget af få alternativer. Løsninger med 20+ år på bagen har sat dagsordenen på markedet i en lang årrække. Der er derfor et teknologisk efterslæb at indhente. Ikke kun den danske lejelovgivning har givet høje entrebarrierer, men også konservatisme blandt købere af ejendomsadministrative systemer. Systemerne virker jo ud fra en eller anden niveaubetragtning.
Markedet har dog ændret sig de seneste 3-4 år, hvor nye løsninger baseret på alternative teknologier kommer på markedet. Min holdning er, at der er meget ”hype” og at det som køber kan være svært at adskille førnævnte fra reel innovation!
En del løsninger på markedet er udtryk for tankegangen det ”gælder om at hoppe over hvor gærdet er lavest” for at komme hurtigt på markedet med en løsning. Prisen skal være attraktiv og funktionaliteten ramme de lavest hængende frugter. Personligt har jeg altid ment at det er en god ide at komme hurtigst i mål, men det må ikke være en hindring for på sigt at optimere den samlede forretning. Genvejen viser sig pludselig som en ”Dead End”. Mållinjen er jo dynamisk og flytter sig hele tiden. Sandsynligheden skal være at man kan flytte med.
Jeg oplever mange simplificerende tiltag som ”huslejeopkrævninger - det klarer vi i et ”snuptag”!” Men hvad med lejereguleringen eller påkravsprocessen, der er kompleks, kan den nu også klares? Mennesker og processer betyder fejl, og hvor let er det så lige at synkronisere systemerne i disse tilfælde?
Med nærværende ”White Paper” har jeg ønsket at fremhæve funktioner og strukturer som en beslutningstager bør være opmærksom på ved erhvervelse af et system til ejendomsadministration.
Da min kollega og værdsatte partner læste artiklen kaldte han den en "Wall of Text". Det har man nok ret i. Yes, jeg lover at dette blogindlæg ikke, bliver repræsentativ for det indhold, der kan findes på "bloggen".
Omvendt er det også tilfældet at der ikke er tilgængelig læsestof der behandler emnet her, som bare er komplekst i natur.
Så det forbliver "væggen", da det må være muligt at se kompleksiteterne behandlet et eller andet sted.
Andre elementer er naturligvis vigtige, eksempelvis som andre brugeres erfaringer mv., indlægget har som sagt et funktionsorienteret perspektiv, fremfor at være en komplet guide til hvordan et nyt ejendomsadministrativt system bør erhverves.
Det er vigtigt at holde ”in mente”, at det selvfølgelig er godt når processer er systemunderstøttede, men i visse scenarier, kan processer sagtens håndbæres. Det er dog godt at have indblik i hvor kompromiserne er, og hvor optimeringsmulighederne slutter. Dette ”White Paper” hjælper med afdække kompromiserne.
Udgangspunktet er, at værdien af det man foretager sig skal overstige omkostningen! Derfor vil der være ikke være en ultimativ løsning for alle.
Læseren kan med rette anklage forfatteren for en ”bias” mod vores eget system, men i Dynamics Property, har vi indtænkt de elementer vi gennemgår i dette ”White Paper” allerede i det tidligere design af løsningen. Af dyrekøbt erfaring ved vi nemlig hvor urimeligt svære funktionerne er at implementere korrekt på bagkant.
Det er jo let nok at regulerer lejen med et nettoprisindeks, men hvad med depositum i X-rater der også skal reguleres. Så var der i øvrigt også lige at skatter - og afgifter kan reguleres med tilbagevirkende kraft, og det var jo så også faktisk en del af lejen. Og den del skulle jo så ikke indeksreguleres, eller hvad?.
Alternative holdninger er legitime og velkomne, såfremt de fremmer afviklingen af processer inden for ejendomsadministrationens værdikæde.
Broen mellem teknisk og funktionelt behov synes at være for bred til at kunne blive krydset. Der er sikkert ikke mange programmører og nørder der har lavet ejendomsadministration i praksis!
Der eksisterer efterhånden flere systemer til ejendomsadministration på det danske marked. Den ældre generation af ejendomsløsninger er gennemprøvede og procesoptimerede, men bygger på en aldrende teknologi, der på mange måder ikke honorerer fremtidens krav til IT-platformen omkring åbenhed.
Hermed være sagt at virksomheder, der driver ejendomsadministration, ikke er undtaget for de konkurrenceparametre som virksomheder fremadrettet vil blive mødt af, når det angår de krav som IT-platformen skal indfri omkring automatiseringer.
Nærværende blogindlæg forsøger at opstille en række funktions- & platformskriterier for ejendomsadministrationssystemer som en virksomhed kan tage afsæt i, når der skal vælges ny løsning til ejendomsadministration.
Indlægget er ikke tiltænkt som komplet købsguide, men en hjælp til at afdække essentielle forhold, der skal tilstede for at få en ejendomsløsning der giver en høj grad af procesunderstøttelse. Listen kan således bruges til at holde op mod funktionerne & platformen i en ny ejendomsløsning, der er af interesse.
Nærværende blogindlæg kan med fordel læses af beslutningstagere der ønsker en forståelse for nogle centrale funktioner, der skal på plads før forvente en procesunderstøttelse.
Når man taler om løsninger til ejendomsadministration, er det nødvendigt at sondre mellem løsninger, der optimerer vedligehold og driftsopgaver angående bygningen (teknisk defineret), og løsninger, der beskæftiger sig de økonomiske og administrative processer, der omgiver ejendommen (juridisk defineret).
Der er naturligvis et overlap mellem de 2 systemkategorier, idet førstnævnte system tager et teknisk afsæt, medens 2. system tager afsæt i optimering af afviklingen af lejeforholdet. Økonomi er en af fællesnævnerne, medens udbedringshistorik i forbindelse med konkrete lejemål er et andet.
Generelt kommunikerer ”kategori 1”-systemerne i BIM-koder, bygningstegninger, energioptimering og vedligeholdelsesinstrukser/planer. Systemerne tilgås typisk af en vicevært, bygningsansvarlig m.v. Populært benævnes disse ”Facility Management Systemer”.
”Kategorien 2” systemerne, beskæftiger sig med lejeopkrævninger, regulering af lejen, bogføring af istandsættelse omkostninger m.v. Systemerne i 2. kategori tilgås typisk af ejendomsadministratorer. Populært benævnes disse ejendomsadministrationssystemer. Dynamics Property tilhører denne 2. kategori.
I det efterfølgende vil kun systemer i 2. kategori blive behandlet. Vi taler således om ejendomsadministration og økonomi. Ikke bygningsvedligehold.
Da vi i Dynamics Property er IT – leverandører af vort eget system, sætter vi ikke navne på konkurrerende systemer, men derfor kan læseren fint selv tage system ved navn ”X” og holde op mod de her opsatte principper.
Diskussionen vil ske på baggrund af hele ejendomsadministrationens værdikæde, jf. nedenstående diagram.
Erhvervslivet i Danmark og i den øvrige verden vil fremtiden have stigende mulighed for at automatisere deres processer. Men det fordrer en software bygget på en åben platform, så de kan tilgås af andre systemer.
Innovationen vil være tiltagende og det vil være vigtigt for virksomheder at aktivere denne for at forblive konkurrencedygtige. Ejendomsadministration er præget af kompleks lovgivning, men der er klare regler for mange forhold og derfor vil det i stigende grad være muligt at bygge automatiseringer inden for branchen.
Men afsæt i ovenstående opstiller således følgende generelle kriterier for en normativ platform:
”Microsofts Dynamics 365” er et eksempel på sådan en platform.
Selvom nedenstående er af stærkt generaliserende i natur, er klassifikationen relevant da applikationer inden for ejendomsadministration har et basisperspektiv alt efter hvornår de er bragt på markedet.
Ældre ejendomsadministrationssystemer har ofte økonomistyringen som integreret del. Årsagen hertil, er at mange af ejendomsadministrationens processer ligger relativt tæt på transaktionen. Det giver transparens og effektivitet, da data ikke skal fragtes mellem 2 delsystemer.
Løsningerne er gennemprøvede og processerne er strømlinede. Løsningerne dækker i forskellig omfang ejendomsadministrationens værdikæde.
Generelt kan økonomistyringen og finansdelen dog betegnes ”svag”. Økonomistyringen er skabt målrettet til ejendomsadministrationsdelen.
Danmark er et lille land og ejendomsadministration er en begrænset vertikal. Antallet af brugere af økonomidelen er afgrænset til brugerne af programmet som sådan. På det grundlag er det ikke muligt at skabe en tidssvarende økonomistyringsdel.
Det kommer bl.a. til udtryk en svag validering af hvad der ønskes bogført og finansjournaler der er svært tilgængelige. Data kan typisk kun tilgås via bestemte af leverandøren valgte BI-systemer. Brugerfladen er forældet og blot det at få et listebillede af alle ens ejendomme kan være en udfordring.
Økonomistyringsdelen kender dog til pligtige pengeydelser, kan håndtere mange juridiske enheder. Forhold der er nødvendige for at økonomistyringsdelen fungerer overhovedet.
Så selv om økonomistyringen ikke måler sig med de nyeste systemer, er der en række forhold som gør at selv det nyeste økonomistyringssystem ikke løser opgaven optimalt.
Her menes løsninger, der har været på markedet i mindre en 10 år.
En nyere trend er, at ejendomsadministrationsdelen (seneste 3-4 år) er separeret fra økonomistyringssystemet. Det giver mulighed for at lave en specialiseret funktionalitet udbudt som tjeneste. Det er typisk er opkrævningsdelen med Nets eller lignende funktionalitet, der er tilgængelig.
Årsagen til netop denne funktion vælges, er at denne opgave er fælles for alle ejendomsadministrationer og er kritisk! Men valget af denne funktion må ikke sætte begrænsninger op for at ejendomsadministrationen kommer i mål med at inkludere den øvrige værdikæde i optimeringsbestræbelserne, eller heller på sigt!
Data flyttes til et økonomistyringssystem typisk via filer og webservices. Problemet med denne arkitektur kontra den klassiske er, at stamdata og transaktionsdate ikke ligger i samme system og, der ikke fokuseres på hele værdikæden.
Verden er ikke perfekt og et system bør også vurderes på basis af hvor let det er at kunne rette fejl.
Med 2 systemer opstår muligheden for at de 2 systemer kommer i en asynkron tilstand. Depositum i system 1 udviser X, medens Depositum i system 2 udviser Y. Hvad er gældende?
Der eksisterer også løsninger baseret på ERP-systemer i denne kategori, men de har ikke fundet bredt indpas på markedet, hvilket har givet dem en relativ smal ejendomsfunktion og ikke altid en gennemtænkt struktur, da virksomhederne ikke er specialiseret inden for feltet.
Disse ERP-brancheløsninger er ofte blevet kundetilpassede og har derfor mere projekter end produkter. Det er dog også sin berettigelse, idet virksomheder her har fået understøttet specielle processer som de ældre systemer ikke har kunnet understøtte.
Disse løsninger vokser ud af komponenter skabt af en større IT-leverandør, der kan aktiveres til at skabe en sammenhængende IT-platform. Et eksempel herpå er Microsoft med Dynamics 365 platformen.
Ved at vælge ”SaaS-vejen er der kun 1 kodebase, hvis funktionalitet stilles til brugernes rådighed.
Dynamics Property befinder i denne kategori. Ved at lægge ejendomsadministrationsdelen i selve økonomistyringssystemet kan en række klassiske værdier tages med og samtidig overkomme nogle af de klassiske barrierer i den strategiske IT-udvikling.
Der kan kommunikeres med dokumentarkivsystemet, Teams eller mailprogrammet via et standard API. Integrationerne skal bygges til formålet, men standardsystemerne er klar til at blive brugt.
I ”Dynamics Property” er vi den klassiske skole, nemlig at arbejdet med ejendomsadministration så transaktionsforbunden, at aktiviteterne bør ligge i samme system som økonomistyringen og der bør kigges på hele værdikæden for optimere forretningen.
Kernen er et ERP-system (”Enterprise Ressource Planning”). De søger netop at at dække hele virksomhedens værdikæde, men ud fra generelt perspektiv. Således mangler ejendomsadministrationsdelen typisk. Disse tilføjes som 3. parts produkter og er en del af systemet.
På den måde genskabes klassiske dyder, men nu på en moderne stærk Cloud SaaS platform, der tager afsæt i datadrevne forretningsprocesser og fremtidens muligheder. Dynamics 365, gør det muligt at bygge en sammenhængende platform med integrationer til SharePoint, Outlook, Teams osv., hvor systemerne fremstår stærkt forbundne med store effektiviseringsgevinster til følge.
Platform er én ting. En anden er, hvordan funktionaliteten, er designet, da selv den stærkeste platform ikke løser opgaven, hvis funktionaliteten ikke løser det faktiske behov.
I det efterfølgende vil vi fokusere på en række basisopgaver, hvor korrekt design er kritisk:
• Mange juridiske enheder
• Mulighed for at kunne registrere alle relevante stamdata
• Stamdata hierarki
• Fra potentiel lejer til faktisk lejer
• Opkrævningen
• Reguleringen
• Deposita, forudbetalt lejer m.fl.
• Compliance
• Restanceprocessen
• Forbrugs- & fordelingsregnskaber
• Arbejdet i økonomistyringen
• Rettelser/omposteringer
• Håndtering af leverandørfakturaer
• Flyttesyn
• A9 Lejekontrakter
• Standard paradigmer / korrespondance
• Opbevaring af sagshistorik og GDPR
Afslutningsvis vender vi tilbage og ser på 3 elementer omkring en platform:
• Åbenhed i platformen
• Muligheden for løbende at blive opgraderet
• System understøttelse af unikke forretningsprocesser
Det er fristende at kigge på opgaverne isoleret men det er ikke muligt, da der har en række indbyrdes sammenhænge for optimalt funktionsdesign mellem punkterne inden byrdes.
Når en ejendom enten erhverves eller opføres, placeres ejerskabet ofte hos et selskab. Formålet med fremgangsmåde er 1) afgrænse risikoen og/eller 2) investor ved ikke på erhvervelsestidspunktet om det er selskabet eller ejendommen, der skal frasælges.
Ved større ejendomsporteføljer kan dette resultere i 100 eller sågar flere selskaber!
I de ældre ejendomsløsninger er selskabskonstruktionen ikke et problem, idet har man lavet formålsrettet økonomistyring til at håndtere de mange selskaber, men i et traditionelt økonomistyringssystem er der en række udfordringer!
For hvert regnskab, er der er et sted, hvor selskabsoplysninger (CVR-nummer adresse osv.) kan indgives og et sted fra hvor nummerserien til diverse dokumenter trækkes. Et ERP-regnskab er derfor som udgangspunkt ikke egnet til at holde flere juridiske personer.
Fremgangsmåden er følgelig typisk at ejendomme, der placeres i egne regnskaber.
Det resulterer i fragmenterede arbejdsprocesser! Eksempelvis er der 50 regnskaber i konstruktionen, skal der hvert regnskab åbnes for opkrævningskørslen og påkravsprocessen kan afvikles for det specifikke selskab. Det betyder procesfragmentering og manglende overblik. Naturligvis kan man forsøge at danne sig et overblik via rapportering på tværs af regnskaber, men en effektiv og velfungerende tilgang bliver det aldrig.
Økonomistyringsdelen i de klassiske ejendomssystemer løser udfordringen, men er til gengæld meget enkel, da den blot er skabt til et afgrænset formål. Ved ”enkel” menes at den rummer basal debet/kreditfunktionalitet. Eksempelvis er det i flere af systemerne muligt af bogføre samme bilag over flere datoer, hvilket fortæller om et ofte utilstrækkeligt valideringsniveau i systemerne.
I et typisk tidssvarende ERP-system, ville valget være at lade stamdata være placeret i de respektive regnskaber, grundet ovennævnte forhold omkring nummerserier og muligheden for at indgive selskabsinformationerne 1 sted samt evt. brugerrettigheder. Dvs. ejendomsstamdata vil være placeret og opdelt per regnskab.
I den kreative afdeling kan man være fristet til samle stamdata i samme regnskab og forsøge at dimensionere sig ud af problemstillingen. Dvs. hver ejendom gives en dimensionsværdi. Der kan laves en finansbalance osv. pr. regnskab. Det løser mange af problemstillingerne. Men ”best practice” kan ikke være at slutresultatet er en sammenblanding af flere selskabers regnskabsdata i samme regnskab, da transaktionsnummeret ikke er fortløbende pr. regnskab og der vil være huller i nummerserien på bogførte bilag pr. selskab.
I Dynamics Property har valgt at bygge videre på tanken om et regnskab, men ført tanken videre ved at tilføje et klient-niveau i regnskabet. Data fragtes fra et (evt. flere) produktionsregnskaber ud til klientregnskaberne og der er mulighed for at indgive en nummerserie pr. klient og selskabsoplysninger for hver klient. Opdelingen er også gjort at der kan defineres regnskabsroller, således at der kan opsættes konteringsregler der beskytter mod fejlposteringer.
Der bør løbende laves afstemninger mellem styrings- & klientregnskaber, hvilket der leveres værktøjer til.
Strukturen er fordelagtig når der skal laves integrationer, da disse typisk er per regnskab. Skal aktiveres et nyt regnskab er det blot at kopiere et regnskab og oprette en ny klient.
Generelt er dette et undervurderet punkt. Da det er en besværlig proces at få tilføjet et felt. Ofte vil dette kræve en ændring af grundsystemet.
I de ældre systemer er det en ekstrem tidskrævende proces, der kræver at kunden kan overbevise leverandøren om at feltet er ”god ide”, da feltet hvis tilføjet kerneløsningen også vil være tilgængelige for andre kunder.
Nyere løsninger er bygget på webteknologi er typisk funktionsspecialiserede. Der en bagvedliggende logik-motor og en eller flere databaser. Det bagvedliggende udviklingssprog er ikke egnet til at modellere forretningsprocesser i, da det er målrettet webudvikling. Her tænkes på sprog PHP, JavaScript mv. Det gør det vanskeligt for leverandøren at efterkomme et ønsker om understøttelse af en specifik en forretningsproces eller modellere komplekse processer med variabilitet. Udfordringen er her således den samme som ved de ældre systemer.
Er der en information uden et felt til formålet, er resultatet ofte at tilgængelige ”ledige” felter misbruges til at holde ikke tilsigtede data. Det gør processerne personbårne og migration til andre systemer ekstremt tidskrævende, idet tung datavask er påkrævet.
I ERP-systemer tilføjes felter på tabelniveau som kundetilpasninger, hvilket betyder at kunden ender ud med en kundetilpasset løsning. Bygges der processer på tilføjede felter, har kunden til sidst ikke en brancheløsning, men en pludselig projektløsning. Det vil typisk være en glidende proces væk fra ”brancheløsning” til ”kundeløsning”. I værste fald holder leverandøren ikke en grundversion, men plukker blandt tidligere kundeleverancer og finder den bedst egnede til det konkrete formål. Dokumentation og andet læringsmateriale er ikke til stede, da viden omkring den konkrete version er placeret i konsulenternes hjerner.
I Dynamics Property har vi et begreb vi kalder ”attributter”. Det er felter som brugeren selv kan oprette og anvende i eksempelvis reguleringsprocessen. Attributter kan være lister, tekstfelter osv. På den måde kan brugeren i praksis registrere alle stamdata uden diskussion/ventetid og bare sin ”brancheløsning” intakt.
Arrangering af stamdata burde, ud fra det fælles problemdomæne som løsningerne er bragt i verden til at håndtere, være relativt ens. Det er dog ingenlunde tilfældet. Det er kritisk at gøre sig klart hvilken model der passer. Også på sigt, da behovet kan skifte hvis ejendomsporteføljen ændrer sammensætning.
Et kvalitetskriterie er, at mængden af data, der skal vedligeholdes, skal være så begrænset som muligt, og at der skal være et afstemningsgrundlag.
Specielt større beboelsesporteføljer stiller særlige systemkrav. Et lejemål i en beboelsesportefølje, vil alt andet lige være mere statisk end et erhvervslejemåls, der genforhandles ved hver genudlejning.
Datastrukturen bør i større ejendomsporteføljer sikre at der skal røres så lidt som muligt ved den løbende opkrævning på tværs af skiftende lejeforhold for at minimere risiko for fejl.
I erhvervslejemål, kan det argumenteres for at lejekontrakten er den bærende enhed. Problemet ved at lægge sine data her, er at man mister et overordnet afstemningsgrundlag og en ”vejledende sats”.
Hoteldrifts-lignende scenarier, eksempelvis kontorhoteller kræver en ”agil” datastruktur, hvor priserne kan variere over weekends eller i højsæsoner.
”Hoteldrift” og boligporteføljer har modsatrettede egenskaber. Førstnævnte kalder på agilitet medens sidstnævnte kalder på at ofte store opkrævningsbeløb er korrekte. Det er 2 modsat rettede behov. Visse kunder har begge typer af ejendomme i den samme portefølje og det bør grundigt overvejes som de skal ligge i samme ejendomsadministrationsløsning, da dette i hvert brugsscenarie introducere en unødig kompleksitet.
I Dynamics Property er strukturen: Klient, Ejendom, lejemål og lejer.
En ydelseslinje vil enten tilhøre lejemålet eller lejeren. Den grundlæggende, ide er at tilhørsforholdet defineres rette sted for at skabe afstemningsgrundlag og minimere antal data, der skal vedligeholdes. En huslejeydelse vil således tilhøre lejemålet og er der en lejenedsættelse vil beløbet blive korrigereret på lejeren. Ophører et lejeforhold med nedsat leje, går lejen således tilbage til udgangspunktet. Deposita og forudbetalt leje, tilhører lejeren og bær derfor ligge på lejeren.
Der føres tomgangsleje mellem lejeperioder, således der skabes et afstemningsgrundlag.
I en række løsninger lægges lejen på lejeren/lejekontrakten, hvilket dog er uhensigtsmæssigt, idet der herved ikke er en vejledende sats der går på tværs af lejemål. Det kan ved første øjekast synes som en fordel, når man taler erhvervslejemål med forhandlede priser. Det er dog stadigt ikke optimalt da man mangler et afstemningsgrundlag. Når man taler beboelseslejemål, er det decideret et dårligt design at lægge lejesatserne på lejeren alene.
Tomgangslejen kan ikke kalkuleres!
Bemærk at punktet også hænger sammen en ”Mange juridiske enheder”, idet der hierarkiet bør være afsat plads til en entitet, der associerer ejendommen med et selskab. Selve associeringen er dog ikke tilstrækkelig, idet nummerserier & virksomhedsinformationer bør håndteres pr. selskab i forretningsprocesserne.
Systemer der regner deposita og depositum som en fast relativ anden af lejen er få så vidt ok, men det er mere vanskeligt at forstå en procentdel end deposita skal være lig X måneders leje.
Der bør være en proces for hvordan en potentiel lejer bliver en faktisk lejer. Ofte sender en udlejer flere kontrakter ud før lejekontrakten indgås. Engang indgivne oplysninger bør genbruges.
I Dynamics Property, registreres kontakter, og hvilke boligpræferencer der haves. Der kan sendes en lejekontrakt og når denne er underskrevet og indbetalt, oprettes lejeren på baggrund af aftalen.
De klassiske systemer tilbyder et ventelistesystem, men et sådan er endnu ikke tilgængelig for Dynamics Property. Nuværende beboere har typisk fortrin fremfor nytilkomne.
Processen bør kunne understøttes med tjekliste.
En af de vigtigste funktioner i en ejendomsløsning er ”opkrævningen”. Mange nye webbaserede løsninger fokuserer forståelig nok på denne kernefunktionalitet, der er essentiel for ejendomsadministratoren.
Umiddelbart virker det ikke problematisk, da ”X kr. pr. måned” burde være til at håndtere!
Imidlertid kompliceres forholdet en del, når man går i detaljen. Tages eksempelvis afsæt i en af de mest simple reguleringsmetoder ”nettoprisindeks”, vil kompleksiteterne begynde at udfolde sig. Jf. lejelovens §§ 50-52 kan der også efteropkræves for stigninger i skatter og afgifter. En mulighed udlejer typisk ønsker at benytte. For at dette kan ske, skal skatter og afgifter udskilles fra den øvrige leje. Ellers vil det ikke være muligt at regulere denne.
Skatter- & afgifter skal reguleres efter andel af total lejen, og pludselig kommer der en anden reguleringsform (”andel af totallejen”) ind i billedet. Det er også et lovkrav at udlejeren kan viser lejeren hvordan beløbet fremkommer. Beløbet skal efteropkræves, såfremt datofrister overholdes og i øvrigt bør depositum og forudbetalt leje reguleres så beløbene er i samme forhold til lejen før og efter reguleringen. Deposita og forudbetalt leje skal i øvrigt opkræves i rette antal rater.
Rater der opkræves bør dannes frem i tid, således reguleringen kan forberedes på det tidspunkt mulige tidspunkt og lægges ind i selve opkrævningsplanen.
Påmindelser der angiver at en bestemt regulering skal udføres efter en huslejeopkrævning, er udført er et kompromis! Typisk er det udtryk for at der ikke foreligger en opkrævningsplan og eneste værdi der holdes, er kommende huslejeopkrævning, som er beløbet der regnes på. Det er ikke optimalt, da reguleringen ikke kan udføres når ejendomsadministratoren har sidste relevante information som er nødvendig for at udføre reguleringen. Dvs. udføring af reguleringen vil ofte være en presset aktivitet tidsmæssigt.
Der er mange niveaubetragtninger, der kommer ind her. Visse processer kan naturligvis håndbæres, men er der mange lejemål der skal reguleres, er det vigtigt at have ovenstående in mente.
Et godt funktionsdesign er derfor at:
• ”Rater bør kunne dannes fremad i tid.
• Deposita og forudbetalt leje bør kunne beregnes korrekt af systemet og opkræves i rette antal rater.”
• Skatter og afgifter skal være leje men en udskilt del for at kunne reguleres særskilt jf. lejelovens §§50 -52’s betingelser.
• Tjek af skatter kan efteropkræves. Husk at det er et krav i lejelovens §50, stk. 4 at lejeren skal kunne se beregningen af hvordan reguleringen er fremkommet.
Ovenstående er vel og mærke ud fra et ideal-scenarie. Dynamics Property tillader ovenstående.
I de fleste systemer, er det muligt at registrere depositum & forudbetalt leje på lejeren. Det er vigtigt der eksisterer redskaber til at fange differencer i deposita og forudbetalt leje. Er noget bogført fejlagtigt bør det være intuitivt at rette fejlen.
Deposita og forudbetalt leje bør være tilknyttet huslejen for korrekt regulering af disse.
Systemerne bør være skruet således sammen at deposita og forudbetalt leje ikke er en endelig liste af konti, der kan registreres transaktioner på. Et eksempel herpå er lejelovens § 22 konto til indvendigt vedligehold. Denne konto hører lejemålet til. Eller den bundne konto til udvendigt vedligehold af ejendommen boligreguleringslovens 18B.
Verden er jo ikke statisk og systemet bør være åbent for at brugeren kan definere nye konti.
Det bør være muligt at definere en ”best practice” for en forretningsproces og få dokumentet dets udførelse.
Ideelt bør processer kunne:
1. Defineres per ejendom, således de kan rumme de specielle vilkår ejendommen rummer
2. Defineres til at virke på tværs af alle ejendomme for processer der altid skal følges
3. Aktiveringen skal være simpel.
4. Trin i forretningsprocessen er ikke nødvendigvis obligatoriske.
5. Trinnet i processen bør præsenteres for den ansvarlige
6. Afviklingen af processen bør kunne genfindes som dokumentation for hvorledes den er blevet afviklet.
7. Der kan være deadlines på de enkelte procestrin, eksempelvis er fremsendelse af ophævelsesskrivelsen kritisk i en restanceprocessen.
8. Igangværende processer bør aggregeres over hele hierarkiet og have en ansvarlig.
Det skal være uhyre enkelt at aktivere en proces og den skal være mulig at genfinde dokumentationen for at den blev korrekt afviklet.
Der eksisterer flere varianter af ovenstående, men løsninger der fokuserer, på en lille del af værdikæden kan selvsagt kun levere en begrænset dokumentation.
Erhvervslejemål rykkes efter erhvervslejelovens §69 og boliglejemål efter Lejelovens §93, stk. 2. Uden at komme i detaljer her, kalkuleres et rykkergebyr efter skyldige pengepligtige ydelser og efter forskellige principper.
Selvom der er undtagelser, er påkravsudfærdigelse normalt ikke en højfrekvensopgave, men det er fatalt at lave en procedurefejl eller en fejl i selve skrivelsen. Berammelsestiden for fogedretten, tager tid og en fejl betyder at sagen skal genberammes uden der modtages leje for lejemålet. Er lejeren ikke solvent, vil det mange gange resultere i et lejetab og skal der ske en effektiv fogedforretning er depositum og evt. forudbetal leje ikke nok til at dække tabet.
Er ambitionen at udfærdige påkrav manuelt, eksempelvis via et Word-dokument, vil man altid kunne komme i mål. Men et kvalitetskriterie kunne være i hvor høj udstrækning rykkerskrivelserne kan forud fyldes via systemerne for at minimere fejl.
Et andet kvalitetskriterie er i hvilken udstrækning virksomheden kan udforme påkravsprocessen, skal der eksempelvis sendes en notifikation før påkravet sendes, eller skal påkravsprocessen sættes midlertidigt i bero hvis der laves en aftale med lejer!
De ældre ejendomssystemer, hvor der er integreret økonomistyring, har en stor fordel her, idet de på kreditorsiden har tilføjet kendskabet til pengepligtige ydelser og derfor kan danne påkrav. De specialiserede systemer med generel økonomistyring har ikke denne mulighed og brugeren må håndtere rykkerprocessen manuelt.
I Dynamics Property har vi ikke blot tilføjet den pengepligtige ydelse, men vi medtager også delbetalinger fra lejeren i påkravsprocessen. Påkrav kan naturligvis dannes for boliger- og erhverv, jf. lejelovens og erhvervslejelovens krav, flettes ud til Word. Påkravsgebyrer kan overføres til en finanskladde og bogføres.
I Dynamics Property kan der defineres forskellige påkravsprocesser for forskellige boligtyper. Dvs. du kan designe 1 proces for erhverv (f.eks. uden notifikation) og en anden for boliger med Notifikation.
En opgørelse over forbrugsregnskabet kan håndbæres dvs. der kan efter forbrugsårets afslutning laves en beboerliste, der kan angiver hvem har beboet i lejemålene, hvilken periode er der tale om og indbetalt acontobeløb. Denne kan sendes til forbrugspartneren med årets forbrug, hvorefter de foretager fordelingen.
Indgås et lejemål i december med starten af januar, vil første månedsleje og aconto forbrug blive erlagt i december, dvs. et andet designkriterie er at bogføringsdato og forbrugs år ikke nødvendigvis følger
Mangler oplysninger kan der foretages korrektioner ud fra eksempelvis graddage. Tages perspektivet at processen skal systemunderstøttes i størst muligt omfang, er der nogle designkrav der skal være honoreret fra systemets side.
Skal der laves et forbrugs- eller fordelingsregnskab, er det nødvendigt også at have styr på tomgangsperioderne, idet disse er ejendommens andel af forbruget. Således er det ikke nok at holde styr på lejeperioderne, men der skal også holdes styr perioderne derimellem.
Aconto indbetalinger for forbrugsperioden bør være et forslag, da man ikke ud fra bogføringsdatoen kan udlede, hvilken forbrugsperiode transaktionen vedrører.
Der skal afleveres en fil til forbrugspartneren og opgørelsen skal importeres. Flowet skal være korrekt og der bør anvendes en afstemningskonto, der går i 0 når afregningen til beboerne er pågået. Flere og flere forbrugspartnere tilbyder at fremsende afregningen til beboerne, så fremsendelseshåndteringen bliver stadig mindre kritisk.
EU’s ”Energy Efficiency Directive” (Energieffektivitetsdirektivet) med månedlige kontrolaflæsninger stadig mere kritisk. Her kommer forbrugspartnerens portal ind, således at de månedlige kontrolaflæsninger ikke nødvendigvis behøver passere gennem ejendomsadministrationssystemet. Det er dog nødvendigt at der eksisterer en let og fleksibel måde at notificere forbrugsafregningsvirket om flytningen på. Det ville nu også være et behov uden EED.
I ejerforeninger er det ikke unormalt at afholdte udgifter skal fordeles efter et fordelingstal, der afviger fra ejerlejlighedens areal. Det er derfor vigtigt at systemet kan håndtere forskellige fordelingsnøgler.
Dynamics Property er designet med ovenstående in-mente, og mange af de ældre ejendomsløsninger på markedet ligeså.
Når der arbejdes i kladde m.v., er det en designkvalitet, hvis stamdata fra ejendomsadministrationsdelen være tilgængelige i konteringsarbejdet.
Hvis dette ikke er tilfældet bliver arbejdet unødvendigt tidskrævende og fejl fyldt. Skal der posteres på et lejemål, må det fra kladdelinjen kunne udvirkes en søgning der identificerer supplerende konteringsoplysninger ud fra eksempelvis adressen eller navnet på lejeren posteringen vedrører.
I Dynamics Property er der lavet en lejerfinanskladde, der gør det tilgængeligt at arbejde med rette bogføringsinformationer. Ligeledes på kan dimensionsstrukturen udledes på alle bilag via søgning i stamdata.
Verden er ikke perfekt og det er derfor godt design let at foretage rettelser uden at historikken (altså at der er begået en fejl) forsvinder.
I et 2 delt system (ejendomsadministration i et og økonomistyring i et andet), er der alt andet lige et par ekstra arbejdsprocesser her. Det er vigtigt at være opmærksom på afstemningsværtøjer i begge systemer, da 2 asynkrone systemer kan resultere i fejl. Det er fatalt såfremt de rette korrektionsværktøjer ikke er til stede.
Det bør eksempelvis være let at korrigere et forkert posteret depositum, eller en forkert udarbejdet flytteopgørelse.
I ældre ejendomsadministrations systemer med integreret økonomistyring er dette en almindelig bogføringsopgave. Det er dog ligeledes nødvendigt at afstemningsværktøjer er tilgængelig her.
Det samme er tilfældet i Dynamics Property, da perspektivet er det samme som de ældre systemer.
Dette område er så stort, at det ville berettige til sin egen ”White Paper”.
Grundlæggende skal økonomisystemet kunne modtage leverandørfakturaer elektronisk (OIOUBL) og via PDF-filer, der hvor data OCR behandles.
Det giver ikke mening at specialiserede ejendomssystemer håndterer denne del, da den er en del af økonomifunktionen. Ejendomsstamdata er imidlertid ikke tilgængelige her, hvorfor processeringen bliver tidskrævende. Der skal m.a.o. være datatilgængelige, således det kan angives hvor fakturaen hører til. En lang kontostruktur er uhensigtsmæssig, men dog en mulighed hvis der ikke er andre værktøjer til stede. Måske er der en mulighed for manuelt at definere et ”tag”/dimensionsværdi.
Leverandørfakturaer skal sættes i et godkendelsesflow. Best practice er at der arbejdes med købsordre og et efterfølgende match mellem købsordre og faktura. På denne måder har administrationen et overblik over likviditetstrækket. Det vil være hensigtsmæssigt at overveje at godkendelsesprocessen ligger tidligt nemlig allerede på tidspunktet hvor købsordren afgives. I praksis vil der i et vist antal virksomheder være en holdning til at dette er for tidskrævende og besværligt. Det er en holdningssag, der kan skifte.
Der bør være mulighed for OCR-behandling af leverandørfakturaen eller tolkning af XML-filen i fald der anvendes OIOUBL.
Større ejendomsadministrationer, vil søge at sætte hårdt ind for at optimere denne tidskrævende aktivitet.
Det kan være ved at – lige som det offentlige - sætte krav om elektronisk fakturering til leverandørerne. Der kan med fordel søges at lægges en validering ind tidligt. Eksempelvis når leverandørerne afsender fakturaerne er skal ejendomsnummeret være udfyldt af leverandøren, ellers afvises fakturaen.
I praksis er sådanne regler komplekse at implementere. Revisorregningen vil eksempelvis ikke kræve et ejendomsnummer, dvs. ejendomsnummeret var reelt kontekstafhængig. Undersøges kostsiden af en avanceret validering af elektroniske leverandørfakturaer, vil det kun være rentabelt for store ejendomsadministrationer med 100.00 eller mere leverandørfakturaer årligt.
Ældre systemer er knap så åbne for import af filer, men da dette er en standard aktivitet er de efterhånden – modsat de specialiserede systemer – som generel regel gode hertil.
I Dynamics Property er der flere niveauer for løsningen af opgaven. Det er muligt at anvende Kofax (ReadSoft), der er en del af Business Centrals standard pakke, eller Document Capture der er 3. parts software. Sidstnævnte er en nødvendighed, hvis der skal arbejdes med købsordre, og hensigtsmæssigt hvis der skal arbejdes med OIOUBL fakturaer.
Opgaven udføres typisk af en vicevært eller en ressource ansat til formålet, når lejemålet starter eller ophører. Derfor er denne opgave ideelt set en opgave for ”kategori 1” systemer, og derfor uden for afgræsningen. Der er dog en sammenhæng som bør nævnes.
Ejendomsadministrationssystemet, hvor kontrakterne laves, bør dog notificere det andet system om den kommende begivenhed. Da begivenheden ligger ude i tiden kan til/og fraflytningstidspunktet ændrer sig.
Af hensyn til sporbarhed, bør der i det administrative system dannes flytteposter.
Det er en niveaubetragtning, hvor detaljeret udbedringshistorikken bør være, da det kan være en omkostningstung proces at vedligeholde data omkring enkelte bygningsdele. Vælges niveauet at meget detaljeret, eksempelvis typen af anvendte skruer skal registreres, er det en tung omkostningskrævende proces.
Lejekontrakter til erhverv er ikke underlagt de samme formularkrav som boliglejekontrakter og er lettere at arbejde med.
Ændres i boliglejekontraktens formulartekst er den ugyldig, og lejelovens almindelige vilkår er gældende, hvilket er mildest talt ofte er ugunstigt for udlejer
• Boliglejekontraktens data bør komme fra ejendomsadministrationssystemet for at minimere fejl, hvilket også indbefatter § 11 i lejekontrakten
• Ovenstående implicerer således også at ejendomsadministrationssystemet bør indeholde lejekontraktens værdier i struktureret form
• Data bør leveres i et beskyttet dokument (kunne være Word formular visning), således der ikke utilsigtet rettes det forkerte sted i dokumentet.
• Der bør mulighed at kombinere et standarddokument med eksempelvis husordensreglementer osv. Dette for at kunne bevare en standard lejekontrakt skabelon på tværs af ejendomme.
• Dokumentet skal evt. kunne konverteres til et pdf. dokument til digital underskrift. Vær opmærksom på at ikke alle udbydere af digitale underskrifter accepterer flere dokumenter.
Erhvervslejekontrakten er mere simpel, da det fint blot kan være et almindeligt tekstdokument der flettes ud til fra ejendomssystemet. Visningen behøver således ikke være beskyttet.
Data i ejendomssystemet bør kunne kombineres med skabeloner fra et tekstbehandlingsprogram til at generere standard skrivelser til lejerne.
For korrekt adressering bør programmet holde styr på adresser. Brevsamlinger bør kunne opbygges pr. ejendom.
Det bør også være muligt at fremsende breve til evt. interesserede lejere. Adgangen til udskriftfunktionaliteten bør være simpel.
Ovenstående er muligt i Dynamics Property.
Sagshistorik bør samles i et dokumentarkiveringssystem. Følgende bør beagtes:
• Dokumentsystemet bør være adskilt fra ejendomssystemet
• Strukturen for ejendomssystemet bør være modelleret i arkivsystemet, således arkiveringsfoldere er selvforklarende, dvs. uden at skulle ty til ejendomssystemet.
• Arkiverede entiteter skal kunne markeres som de må slettes efter lejeperiodens ophør ud fra GDPR-hensyn
• Indgående og udgående korrespondance bør arkiveres i samme kasse således at der er et sted med komplet historik, både indgående og udgående.
• Arkivering
Processen med der vedrører oprettelse og vedligehold af arkivstruktur samt arkivering er pt. håndbårne i Dynamics Property. Ved anvendelse af SharePoint 365 er det muligt at honorere øvrige punkter, se eksempelvis efterfølgende skærmbillede.
Det er vigtigt at der er mulighed for løbende at blive opgraderet. Her excellerer de nye webbaserede systemer, da der er et grundsystem. Ændres dette opdateres kunderne automatisk.
I de ældre systemer, foregår opdateringen typisk lokalt og tidspunktet besluttes. Det har fordele og ulemper. Først og fremmest kan administrationen selv beslutte hvornår der skal opdateres. Omvendt kan det være en besværlig og tidskrævende proces.
ERP-systemerne har typisk været de dårligste på dette punkt, da opgraderinger var dyre. I den seneste generation er der imidlertid sket meget efterhånden som de forberedes til en SaaS-virkelighed. Løsninger lægges helt uden for basis-økonomidelen via ”Extensions” og den tidligere håndbårne proces kan forenkles i betragtelig grad.
I ”OnPrem.” løsninger vil der stadigvæk være kompleksiteter at håndtere, medens vælges en SaaS løsning vil processen være automatisk. Igen er der fordele og ulemper. I førstnævnte tilfælde kan virksomheden selv bestemme, hvornår opdateringen kommer, medens dette ikke vil være tilfældet via en SaaS-løsning.
Dynamics Property Leveres både ”On Prem.” og som ”SaaS-løsning”.
Hvis en virksomhed har unikke forretningsprocesser, bør det altid overvejes om processen kan ændres så den passer til systemet og ikke omvendt.
Det er ofte muligt, men enkelte gange har procesunderstøttelsen så værdi for virksomheden og udgør måske en essentiel konkurrenceparameter. I komplekse scenarier bør det afdækkes om sådanne processer eksisterer, da eksistensen af sådanne påvirker platformsvalget.
I 2-delte specialiserede websystemer, der er samme for alle kunder, vil det ikke være en mulighed at understøtte unikke processer. I ældre systemer vil dette heller ikke være en mulighed, da IT-leverandøren har et grundsystem, der holdes ens.
Teknisk er det muligt at lave en tilpasning i systemet hos Dynamics Property, men vi anbefaler her, at ”On Prem. Versionen” vælges, men det sker på bekostning af løbende opdateringer.
Begreber som kunstig intelligens, Internet-Of-Tings & datadrevne virksomheder er størrelser som mange danske virksomheder vil stifte bekendtskab med i årene der kommer.
Det kan være svært at spå, hvornår det ud fra et konkurrencemæssigt perspektiv bliver nødvendigt at forholde sig til disse. Man kan dog forudsige at ejendomsadministration er regelbaseret, og derfor er det sandsynlig at det vil være et af de første steder hvor automatiseringer baseret på AI vil blive implementeret. Eneste bremseklods her er givetvis det danske retssystem, der har det med at bygge komplekse love inden for området.
Men for at komme godt i gang med ovenstående proces kræves det, at man rent strategisk har lagt sig på en åben inkluderende platform. Dynamics 365 er Microsofts bud på en sådan platform, der allerede nu tilbyder adgang til kunstig intelligens mv. ”Internet-Of-Things” integrationer er på vej fra Microsofts side, men udbydes i skrivende stund kun til enkelte lande.
Ejendomsadministration kanløses på mange niveauer, men uanset niveau er det en god ide at tænke åbenplatform og dernæst gøre sig sit strategiske sigte klart. Er ejendomsinvesteringerikke den centrale del af forretningen, er en forenklet tingang måske i orden,men er ambitionsniveauet højere der det en gode ide: 1) at holde alternative løsningersfunktionalitet op mod værdikæden og 2) vurderehvorledes løsningerne kan indfri fremtidens krav, hvilket igen afhænger afplatformen løsningerne er bygget på.