PortvardeBe om demo

Applikasjonsregister

Fra regneark ingen stoler på til et register som tåler å bli sitert.

Portvarde gjør systemoversikten fra et regneark ingen stoler på til et register med eier, klassifisering og sporbarhet på hver eneste rad.

Kjører i deres eget Azure-abonnement. Pålogging med Entra ID.

Systemer

4 av 214 vist
Aurora LMSTier 1
Nordvik ERPTier 2
Fjordheim CRMTier 3
Saltnes HRTier 4
Kompletthet68 %

Seks grep

Det oversikten mangler er sjelden flere rader.

Den mangler et eierskap som holder, en klassifisering som er begrunnet, og en måte å se hva som henger sammen med hva. Portvarde er bygget rundt de seks.

Applikasjonsregister

Alle felt med obligatorisk kilde og verifiseringsdato per rad. Kompletthet måles per system mot et mål dere setter selv, slik at dere ser hvor grunnlaget er tynt før første intervju.

Integrasjonsregister

Én rad per dataflyt: master for dataobjektet, mekanisme, frekvens, autentisering, feilhåndtering og overvåking. Vises også som matrise system × system.

Kapabilitetskart

Et hierarki basert på en referansemodell, tilpasset virksomheten. Systemene plasseres under, hvite flekker markeres, og dublering blir synlig i stedet for å bli oppdaget under neste anskaffelse.

Tier-klassifisering

Tier 1–5 med kravsjekkliste. Foreslått tier arves fra den mest kritiske kapabiliteten systemet støtter. Avvik krever begrunnelse, og dere får varsel om tier-inflasjon.

Helsevurdering og TIME

Funksjonell og teknisk score med faste ankre. Interaktiv TIME-matrise der aksene krysser ved 3,0 og boblestørrelsen er årlig kostnad. Kalibreringsrapporten varsler når ankrene ikke er brukt.

Funn og risiko

En regelmotor flagger manglende eier, ukjent hostinglokasjon, tomt behandlingsgrunnlag, svak autentisering, avtaler som utløper, forfalt verifisering og konkurrerende mastere.

Registeret

Hver rad sier også hvor godt den er kjent.

Et felt uten kilde og uten verifiseringsdato er en påstand. Registeret skiller de to, og måler forskjellen per system i stedet for å presentere alt som like sikkert.

Applikasjonsregister
SystemEierTierKildeSist verifisertKompletthet
Aurora LMSIngrid HovdenTier 1Avtale14. mai 202692 %
Nordvik ERPKjell AasenTier 2Intervju2. apr. 202674 %
Havbris betalingMarit LøvoldTier 2Avtale1. juni 202688 %
Fjordheim CRMTor EkebergTier 3Entra ID19. mars 202681 %
Tindra datavarehusIngen eierTier 3Regneark27. feb. 2025 · forfalt47 %
Bjerkely arkivSilje BrennaTier 3Regneark8. sep. 2025 · forfalt55 %
Saltnes HROve FrantzenTier 4Intervju23. jan. 202663 %
Vardøger portalHanne RyggTier 5Regneark11. juni 2025 · forfalt44 %

Illustrasjon med oppdiktede systemer og tall. I et reelt register på 214 systemer er det kompletthetstallet – her 68 % – som forteller hvor mye av bildet som faktisk er kartlagt.

Klassifisering

Tier er noe et system arver, ikke noe det får tildelt.

Foreslått tier er den mest kritiske kapabiliteten systemet støtter. Da slipper diskusjonen å begynne på null for hvert system, og uenighet handler om noe konkret.

Tier-klassifisering
Tier 1Døgnkontinuerlig drift, testet gjenoppretting, to navngitte eiere1 systemer
Tier 2Drift i arbeidstid, dokumentert gjenoppretting, to eiere2 systemer
Tier 3Avtalt responstid, sikkerhetskopi verifisert siste år3 systemer
Tier 4Best effort, sikkerhetskopi finnes1 systemer
Tier 5Ingen driftsforpliktelse ut over det avtalen sier1 systemer

41 % av porteføljen ligger på Tier 1–2. Terskelen er 40 %, og over den er det som regel klassifiseringen som har glidd, ikke risikoen som har vokst.

Arv fra kapabilitet

Arkiv og dokumentTier 5Bjerkely arkivForeslått Tier 5

Satt til Tier 3 i stedet for Tier 5. Et avvik lagres ikke uten begrunnelse.

Illustrasjon med oppdiktede systemer og tall. Et avvik er tillatt, men krever en begrunnelse som blir stående på raden. Går andelen på Tier 1–2 over 40 %, er det som regel klassifiseringen som har glidd – og da er det den, ikke driftsbudsjettet, som bør ses på først.

Helse og TIME

Plasseringen er et resultat, ikke en mening.

Funksjonell og teknisk score settes mot faste ankre, ikke etter skjønn i øyeblikket. Da kan to personer vurdere hvert sitt system og likevel ende med tall som kan sammenlignes.

TIME-matrise
TolerateInvestEliminateMigrate1234512345Funksjonell scoreTeknisk score
  • Aurora LMSMigrate2,4 mill. kr
  • Nordvik ERPMigrate3,1 mill. kr
  • Havbris betalingInvest1,2 mill. kr
  • Fjordheim CRMInvest780k kr
  • Tindra datavarehusInvest920k kr
  • Bjerkely arkivTolerate310k kr
  • Saltnes HRTolerate540k kr
  • Vardøger portalEliminate260k kr

Illustrasjon med oppdiktede systemer og tall. Aksene krysser ved 3.0, og boblestørrelsen er årlig kostnad – et dyrt system i feil kvadrant er det som koster mest å la ligge. Kalibreringsrapporten varsler når ankrene ikke er brukt, eller når for mye klumper seg rundt midten.

Kapabiliteter

To spørsmål et regneark ikke kan svare på.

Hva dekker vi ikke, og hva dekker vi to ganger. Begge blir først synlige når systemene henges under kapabilitetene de faktisk støtter.

Kapabilitetskart

Læring og undervisningTier 1

  • Aurora LMS

Økonomi og innkjøpTier 2

  • Nordvik ERP
  • Havbris betaling

Kunde og relasjonTier 3

  • Fjordheim CRM

PersonalTier 4

  • Saltnes HR

Arkiv og dokumentTier 5

  • Bjerkely arkiv
  • Vardøger portal

Dublering – to systemer dekker det samme

Analyse og rapporteringTier 3

  • Tindra datavarehus

Identitet og tilgangTier 2

Ingen systemer

AvtaleforvaltningTier 4

Ingen systemer

2 kapabiliteter uten system, 1 med mer enn ett.

Illustrasjon med oppdiktede systemer. Hvite flekker og dublering er markert med tekst, ikke bare med farge – et kart som må forklares av noen som allerede kjenner det, er ikke et kart. Dublering er vanligst etter en fusjon, der to virksomheter kom med hvert sitt system for det samme.

Integrasjoner

Spørsmålet er ikke hvor mange, men hvem som eier sannheten.

Én rad per dataflyt, med master for dataobjektet, mekanisme, frekvens, autentisering, feilhåndtering og overvåking. Matrisen svarer på noe en liste ikke kan: hvem skriver til hvem.

Integrasjonsregister
Raden er master for dataobjektet, kolonnen er mottaker.
Fra ↓ / til →AuroraNordvikHavbrisFjordheimTindraBjerkelySaltnesVardøger
Aurora LMSAurora LMS skriver deltaker til Tindra datavarehus
Nordvik ERPNordvik ERP skriver faktura til Havbris betalingNordvik ERP skriver ansatt til Saltnes HR
Havbris betalingHavbris betaling skriver faktura til Tindra datavarehus
Fjordheim CRMFjordheim CRM skriver kunde til Tindra datavarehus
Tindra datavarehus
Bjerkely arkivBjerkely arkiv skriver dokument til Tindra datavarehus
Saltnes HRSaltnes HR skriver ansatt til Aurora LMSSaltnes HR skriver ansatt til Fjordheim CRM. Konkurrerende master: et annet system mastrer allerede dette dataobjektet.
Vardøger portal

Én markert celle: to systemer mastrer «ansatt». Da finnes det ingen kilde å slå opp i når de er uenige.

Illustrasjon med oppdiktede systemer. To systemer som mastrer samme dataobjekt er ikke en integrasjonsfeil – det er en avklaring som aldri ble tatt, og den blir først synlig når flytene settes opp mot hverandre.

Funn og risiko

Et funn som skiller fakta fra mening, tåler å bli sitert.

En regelmotor kjører over registeret og flagger forholdene som gjentar seg: manglende eier, ukjent hostinglokasjon, tomt behandlingsgrunnlag, svak autentisering, avtaler som utløper og konkurrerende mastere.

Funn og risiko
  • KritiskSystem uten eierTindra datavarehus

    Observasjon
    Tindra datavarehus har ingen registrert systemeier, og verifiseringsdatoen er over et år gammel.
    Vurdering
    Ingen kan bekrefte om opplysningene stemmer, og ingen mottar varsler om avtalen som løper.
    Anbefaling
    Tildel eier før neste attesteringsrunde. Kilden bør endres fra regneark til intervju.
  • KritiskKonkurrerende masterSaltnes HR

    Observasjon
    Saltnes HR og et annet system skriver begge dataobjektet «ansatt» til mottakersystemer.
    Vurdering
    Ved avvik finnes ingen kilde å slå opp i. Feil forplanter seg videre til begge mottakerne.
    Anbefaling
    Bestem én master for dataobjektet, og gjør den andre til mottaker.
  • ViktigSvak autentisering på integrasjonBjerkely arkiv

    Observasjon
    Integrasjonen fra Bjerkely arkiv bruker delt nøkkel uten utløpsdato.
    Vurdering
    Nøkkelen kan ikke knyttes til en person eller en tjeneste, og rulleres i praksis aldri.
    Anbefaling
    Bytt til tjenesteidentitet i Entra ID. Sett rulleringsintervall i avtalen.
  • LavAvtale utløperVardøger portal

    Observasjon
    Avtalen for Vardøger portal utløper om under 18 måneder.
    Vurdering
    Systemet ligger i Eliminate og har lav kompletthet. Fornyelse ville bundet opp midler i noe som skal ut.
    Anbefaling
    Ta avviklingsbeslutningen før fornyelsesfristen, ikke etter.

Funnene eksporteres som markdown-notat, med de tre delene hver for seg.

Illustrasjon med oppdiktede funn. Tredelingen er poenget: observasjonen kan etterprøves i registeret, vurderingen er en mening, og anbefalingen er noe noen må bestemme. Står de tre i samme setning, blir meningen lest som et faktum.

Diagrammer

Et diagram som ikke sier hva det gjetter, blir sitert som om det vet.

Ni forhåndsdefinerte visninger genereres rett fra registerdataene, som Mermaid og Structurizr DSL. Ingen tegning å holde oppdatert ved siden av registeret.

Generert arkitekturdiagram
Aurora LMSSaltnes HRBjerkely arkivNordvik ERPFjordheim CRMHavbris betalingTindra datavarehusVardøger portal

34 % av koblingene i dette diagrammet hviler på antakelser, ikke på en bekreftet kilde. Andelen står på hver eneste genererte visning.

Illustrasjon med oppdiktede systemer. Forbeholdet står på hver genererte visning, ikke bare i denne ene: et generert diagram ser like sikkert ut enten koblingene er bekreftet eller antatt, og det er nettopp derfor andelen må stå der.

Eierskap og attestering

Et register forfaller med mindre noen bekrefter det.

Brukere hentes fra Entra ID via Microsoft Graph – ingen egen brukeradministrasjon å vedlikeholde. Samme person kan ikke ha begge eierroller på et kritisk system.

Attesteringskampanje

Bekreftet av eier50 %

  • Aurora LMSIngrid HovdenBekreftet
  • Nordvik ERPKjell AasenBekreftet
  • Havbris betalingMarit LøvoldBekreftet
  • Fjordheim CRMTor EkebergKorreksjon meldt
  • Saltnes HROve FrantzenVenter
  • Bjerkely arkivSilje BrennaVenter

Bekreftelse setter «sist verifisert». Påminnelser går til eieren, ikke til en felles postkasse.

Illustrasjon med oppdiktede systemer og eiere. «Korreksjon meldt» er med fordi den er poenget: en kampanje der eneste utfall er «bekreft», måler at folk klikket, ikke at opplysningene stemmer.

Slik kommer dere i gang

Fire steg, og det siste gjentas.

Dere begynner med det dere allerede har. Ingen av stegene forutsetter at det forrige er ferdig for alle systemer.

Importer regnearket

Last opp arket dere har i dag og se en forhåndsvisning før noe lagres. Kolonner dere ikke har, blir stående tomme og talt som manglende – ikke gjettet.

Tildel eiere

Brukere hentes fra Entra ID, så det er ingen egen brukeradministrasjon å vedlikeholde. Eiersiden viser hver eier hva som mangler på deres egne systemer.

Klassifiser

Tier foreslås fra kapabilitetene systemet støtter, og helsevurderingen plasserer det i TIME-matrisen. Dere overstyrer der dere er uenige, med begrunnelsen lagret.

Attester årlig

En kampanje ber hver eier bekrefte eller melde korreksjon på sine egne rader. Bekreftelse setter sist verifisert, og neste år vet dere hva som faktisk er sjekket.

Be om demo

Se registeret med deres egne systemer i.

En gjennomgang på 30–45 minutter. Vi viser registeret, tier-stigen og TIME-matrisen, og går gjennom hvordan regnearket dere har i dag ville sett ut importert.

  • Ingen forberedelser. Dere trenger ikke ha ryddet noe først.
  • Vi svarer på hva som kan settes opp og hva som ikke kan det.
  • Vil dere prøve selv etterpå, avtaler vi en pilot på egne data.

Opplysningene brukes kun til å svare på denne henvendelsen. Du kan når som helst be om at de slettes.