Standardverktøy eller egen eiendomsapp?

Dere skal få månedsrapporten ferdig. Tallene finnes, men noen må hente dem, kontrollere perioden, finne hullene og sende spørsmål til drift. Et nytt dashbord kan være relevant. Det kan også hende dere trenger en bedre rapport i verktøyet dere allerede har.

For et eiendomsselskap med omtrent 5–30 bygg er antall bygg et startpunkt, ikke en kravspesifikasjon. Før dere velger programvare, bør dere kunne beskrive hvem som skal gjøre hva, med hvilke data, og hvordan dere vil kontrollere resultatet.

Her får dere en sjekkliste som kan brukes både overfor en standardleverandør og i et utviklingsprosjekt. Egen er avsender og tilbyr kundetilpassede eiendomsapper, ikke uavhengig innkjøpsrådgivning. Eksemplene er tenkte arbeidssituasjoner, ikke kundecaser eller målte resultater. Egens produktbeskrivelse og behovsskjema ble kontrollert 31. oktober 2026.[1][2]

1. Skriv arbeidsoppgaven før funksjonslisten

«Vi trenger mer oversikt» er vanskelig å levere og vanskelig å teste. Skriv heller:

Forvalter skal kunne velge rapportperiode og bygg, se hvilke målinger som mangler, legge inn en kommentar og gi ledelsen et avklart rapportgrunnlag.

Det er et illustrerende behov, ikke en ferdig Egen-funksjon. Poenget er å beskrive en handling fra start til slutt. Dere kan da be en standardleverandør demonstrere samme oppgave og en utvikler beskrive hva som må bygges.

Fyll ut disse fem feltene:

• Bruker: Hvem gjør jobben i dag, og hvem trenger bare å lese resultatet?
• Start: Hva utløser arbeidet, og hva har brukeren tilgjengelig da?
• Handling: Hvilke valg, kontroller og godkjenninger må gjøres?
• Slutt: Hva skal være klart, og hvem overtar oppfølgingen?
• Unntak: Hva skal skje hvis data eller en ansvarlig mangler?

Ta med det dere vil beholde fra dagens løsning. Et godt eksisterende verktøy trenger ikke bli et problem bare fordi dere vurderer noe nytt.

2. Be om å få oppgaven vist, ikke bare bekreftet

Når en leverandør sier «det støtter vi», be om et konkret skille:

• Finnes funksjonen i produktet som tilbys nå?
• Krever den et tilvalg, oppsett eller kundetilpasning?
• Må den utvikles og testes før dere kan bruke den?
• Avhenger den av en tredjepart eller en tilgang dere ennå ikke har?

Merk hvert krav med én av disse statusene. Da unngår dere å sammenligne et ferdig standardprodukt med en ønskeliste for spesialutvikling som om begge er levert.

Hvis standardverktøyet kan demonstrere oppgaven med akseptabel arbeidsflyt og avklarte vilkår, er det en god grunn til å velge det. En egen app er først interessant når behovet for tilpasning er konkret nok til å rettferdiggjøre utvikling, testing og videre vedlikehold. Dette er et vurderingsprinsipp, ikke et løfte om hva som blir billigst.

3. Lag et lite datakart

En portal dere kan logge inn i, er ikke automatisk en datakilde en ny app får bruke. Be om svar per kilde:

Dere trenger ikke fylle inn hemmeligheter for å lage kartet. Ikke legg passord, API-nøkler eller sensitive personopplysninger i et åpent behovsskjema.[1]

Hvis tilgangen ikke er avklart, be om en betinget løsning eller en avgrenset teknisk avklaring. Ikke la «API finnes» bli til «koblingen er ferdig». Egens offentlige informasjon presiserer blant annet at en konkret Elhub-løsning krever kontroll av rettigheter og en støttet tilgangsvei; et skjemavalg gir ikke tilgang.[1]

4. Bestem hva som skal skje når data mangler

Et tomt måleintervall er ikke dokumentasjon på nullforbruk. Det kan være et hull som må undersøkes. Be leverandøren vise hvordan brukeren skiller en målt nullverdi fra manglende data.

En enkel, syntetisk test kan være:

• En måling har verdien 0 og status «målt».
• En annen måling har ingen verdi og status «mangler».
• En tidligere verdi blir korrigert.
• En import inneholder samme måling to ganger.

Avtal forventet visning og behandling før testen. Den manglende målingen skal ikke bli en oppdiktet nullverdi, og en duplikat skal ikke telles som et nytt forbruk. Hva appen konkret skal gjøre med korrigeringer, perioder og oppfølging, må fremgå av testgrunnlaget.

Dette er foreslåtte akseptansekriterier, ikke en påstand om en ferdig testet app. Hvis leveransen omfatter varsling, må både kjøringen og den faktiske varslingskanalen testes. En knapp eller en graf i en demo er ikke bevis på at noen blir varslet.[1]

5. Gjør eierskap praktisk

«Dere får kildekoden» er et nyttig utgangspunkt. Det svarer ikke alene på hvordan appen drives eller overtas.

Be om at tilbudet beskriver:

• hvilken kode og dokumentasjon dere får, og når;
• hvordan løsningen settes opp, bygges og oppdateres;
• hvilke tredjepartskomponenter og lisenser som inngår;
• hvem som kontrollerer kodearkiv, hosting og andre nødvendige kontoer;
• hvordan data kan tas ut, med format og relevante begrensninger;
• hvem som har ansvar for sikkerhetskopi, gjenoppretting og tilgang;
• hva en annen utvikler trenger for å videreføre løsningen.

Be gjerne om en avtalt overtakelsestest: Kan en annen ansvarlig sette opp den avtalte versjonen fra leveransen og forstå driftsoppsettet uten private muntlige forklaringer? Ikke del passord i dokumentasjonen; avtal en sikker overføring av nødvendige tilganger.

Egens leveransemodell omfatter kundens kildekode og avtalt dokumentasjon. Tredjepartskomponenter og drift avklares i tilbudet.[1] Det er ikke et løfte om eierskap til eksterne biblioteker eller gratis drift på ubestemt tid.

6. Sammenlign hele kostnaden, uten å gjette besparelsen

Be begge alternativer prise samme oppgave og samme avtalte periode. Få frem hva som inngår og hva som eventuelt kommer i tillegg:

• innføring, datakartlegging og opprydding;
• lisenser, moduler og nødvendige datatilganger;
• utvikling, konfigurering og testing;
• hosting, sikkerhetskopi, vedlikehold og support;
• endringer etter første leveranse;
• overgang eller avslutning dersom dere bytter senere;
• deres egen tid til kontroll og oppfølging.

Marker uavklarte poster som uavklarte, ikke som gratis. Ikke regn bort et eksisterende abonnement før dere vet at oppgavene og tilgangene faktisk kan flyttes.

Hvis dere vil vurdere tidsgevinst, registrer først hva den aktuelle oppgaven krever i dag, og mål den samme oppgaven med samme avgrensning etterpå. Inntil det finnes målinger, er besparelsen en antagelse. Egen har ingen publisert fastprisliste eller generell garanti for besparelse.[1]

7. Avgrens første leveranse så den kan godkjennes

En kort bestilling kan se slik ut. Dette er en mal, ikke et ferdig tilbud:

Oppgave: [hva brukeren skal fullføre]. Første omfang: [avtalt utvalg bygg, brukere og datakilder]. Datatilgang: [bekreftet tilgang og det som fortsatt er en forutsetning]. Ferdig når: [oppgaven kan gjennomføres og avtalte kontroller består]. Utenfor: [funksjoner og integrasjoner som ikke inngår nå]. Drift og videreføring: [navngitt ansvarlig, dokumentasjon og vilkår].

Avklar hvem som godkjenner resultatet, hvordan feil registreres og hvordan nye ønsker behandles. Skill feilretting innen avtalt omfang fra bestilling av nye funksjoner. En avgrenset første leveranse betyr ikke at resten av porteføljen er glemt; den gjør det mulig å vurdere et konkret resultat.

Hvilken retning passer dere?

Velg et standardverktøy når de relevante funksjonene kan vises, arbeidsflyten passer og kostnader, dataflyt og videre bruk er tilstrekkelig avklart. Undersøk tilpasning i eksisterende system før dere bestiller et nytt.

Vurder en kundetilpasset app når dere har en tydelig oppgave som krever egen utforming, og er forberedt på å avklare utvikling, test og ansvar. En separat tilleggsapp kan også undersøkes hvis det finnes en avgrenset oppgave ved siden av systemene dere vil beholde. Det er en mulig løsning, ikke en lovet integrasjon.

Vent med å bestille den dataavhengige delen hvis nødvendig tilgang eller ansvar fortsatt er uavklart. Avklar forutsetningen først; ingen av løsningstypene gjør den overflødig.

Ta med én arbeidsoppgave til behovsskjemaet

Egen bygger eiendomsapper rundt avtalte behov. Beskriv arbeidsoppgaven og få et tilbud uten salgsmøte. Skriv hva dere gjør i dag, hva dere vil kunne gjøre og hvilke systemer dere vil beholde. Dere kjøper ikke noe ved å sende inn skjemaet; behov og tilbud avklares normalt skriftlig.[1][2]

Kilder og avgrensning

[1] Egen: produktbeskrivelse og spørsmål/svar, lest 31. oktober 2026. Grunnlag for Egens modell, målgruppe, datatilgang, eierskap, drift og kommersielle avgrensninger. [2] Egen: behovsskjema, offentlig inngang lest 31. oktober 2026. Ingen innsending utført i faktakontrollen.

Sjekklistene er Egens anbefalte spørsmål og tenkte testeksempler. De er ikke en juridisk vurdering, produktsertifisering, dokumentasjon av integrasjoner eller måling av kunders resultater.