Initial oppdragsstruktur for Standard Online

Etablerer 9-mappe-arbeidsstruktur basert på Forte sitt
startklar-malverk (Salg/_mal/startklar-malverk/), kalibrert
for Nivå 1 (avgrenset strategisk, 6-8 uker).

Inkluderer skeletter for:
- 1. Oppdrag og kontekst (oppdragsbeskrivelse, leveranser, rammer,
  interessenter, møtelogg, møtenotat-mal)
- 2. Organisasjonsforståelse (struktur, roller, nøkkelpersoner)
- 3. System- og datalandskap (SuperOffice, Business Central,
  nopCommerce — fylles ut i Fase A-B)
- 4. Informasjonsarkitektur (begrepskatalog, masterdata-og-eierskap,
  Data Governance prinsipper) — kjernen for leveranse 03 og 07
- 5. Personvern og sikkerhet (GDPR, Privacy by Design)
- 6. AI-rammeverk (operasjonelle prinsipper — ny for Standard,
  bygger på Forte AI Accelerator)
- 7. Standardisering og handlingsplan (avvik, prioritering, tiltak)
- 8. Kontinuerlig læring (intervjuguider, åpne spørsmål, funn)
- 9. Leveranser (Executive Summary, sluttrapport, leveranseplan)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-05-21 12:22:56 +02:00
commit 0c6bcb7782
46 changed files with 2773 additions and 0 deletions

22
.gitignore vendored Normal file
View File

@@ -0,0 +1,22 @@
# macOS
.DS_Store
._*
.AppleDouble
.LSOverride
# Nextcloud
.nextcloudsync.log
# Editor
.vscode/
.idea/
*.swp
*~
# Arkiv (normalisering av møtenotater og lignende — opprinnelige filer)
_archive/
**/_archive/
*.bak.*
# Templates fra malverk — beholdes ikke i repo
.work/

View File

@@ -0,0 +1,63 @@
---
title: "<YYYY-MM-DD> — <Møtetema>"
date: "YYYY-MM-DD"
source: "Møtenotater"
tags: ["møtenotat"]
participants:
- "Navn (rolle, organisasjon)"
refs:
-
qa:
status: "draft"
version: 1
---
# <YYYY-MM-DD> — <Møtetema>
## Sammendrag
*1-2 setninger om hva møtet handlet om og hovedutfall.*
## Diskusjon
*Strukturerte notater. Bruk underseksjoner per tema.*
## Beslutninger
### DEC-YYYY-XXX — <Kort tittel>
**Beslutning:** <Hva ble besluttet>
**Begrunnelse:** <Hvorfor>
**Konsekvens:** <Hva må gjøres som følge>
**Eier:** <Navn>
## Handlinger
### ACT-YYYY-XXX — <Kort tittel>
**Handling:** <Hva skal gjøres>
**Ansvarlig:** <Navn>
**Frist:** YYYY-MM-DD
**Status:** Åpen / Pågår / Fullført
## Risikoer
### RISK-YYYY-XXX — <Kort tittel>
**Risiko:** <Beskrivelse>
**Impact:** 1-5
**Likelihood:** 1-5
**Score:** I×L
**Tiltak:** <Foreslått eller bekreftet tiltak>
## Åpne spørsmål
-
## Neste skritt
-
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,40 @@
---
title: "Interessenter og kontaktinfo — Standard Online"
date: "YYYY-MM-DD"
tags: ["interessenter", "kontakt", "stakeholder"]
qa:
status: "draft"
version: 1
---
# Interessenter og kontaktinfo
## Hovedkontakter hos Standard Online
| Navn | Rolle | E-post | Telefon | Beslutningsmandat |
|---|---|---|---|---|
## Nøkkelpersoner for intervju
| Navn | Rolle | Domene | Intervju planlagt | Status |
|---|---|---|---|---|
## Eksterne parter
*Utviklingspartner, leverandører, samarbeidende konsulenter.*
| Navn | Organisasjon | Rolle | Relevans |
|---|---|---|---|
## Forte-team
| Navn | Rolle | Allokering | E-post | Mobil |
|---|---|---|---|---|
## Interessentkart
*Visuell oversikt — påvirkning vs. interesse, eller domene-tilhørighet. Bygges ut i Fase B.*
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,47 @@
---
title: "Mål og leveranser — Standard Online"
date: "YYYY-MM-DD"
tags: ["leveranser", "milepæler", "plan"]
qa:
status: "draft"
version: 1
---
# Mål og leveranser
## Hovedmål
1.
2.
3.
## Leveranseoversikt
| # | Leveranse | Innhold | Mappe i oppdragsstruktur | Frist |
|---|---|---|---|---|
| 01 | Nåsituasjon, gap og risiko | Datakildeinventar, dataflyt, risikomatrise, GAP mot målbilde | `3.system-og-datalandskap/` + `artefakter/risikoregister.md` | Uke 3 |
| 02 | Arkitekturskisser (as-is + to-be) | Visuelle skisser, integrasjonsmønster, anbefalte komponenter | `3.system-og-datalandskap/systemkart-as-is.md` + målarkitektur | Uke 5 |
| 03 | Masterdata-modell med System-of-Record | Domenemodeller, SoR per entitet, dataeier-tildeling | `4.informasjonsarkitektur/` | Uke 5 |
| 04 | Operasjonelt rammeverk for AI-agenter | Identifiserbarhet, tilgang, logging, HITL | `6.ai-rammeverk/` | Uke 5 |
| 05 | Personvern og compliance | GDPR-vurdering, Privacy by Design, behandlingsgrunnlag | `5.personvern-og-sikkerhet/` | Uke 5-6 |
| 06 | Handlingsplan (prioritert og faset) | Tiltak per domene, faseinndelt 0-3 / 3-12 / 12+ mnd | `7.standardisering-og-handlingsplan/prioriteringsliste.md` | Uke 6-7 |
| 07 | Governance-modell med dataeiere | 3-nivå modell, roller per domene | `4.informasjonsarkitektur/data-governance-prinsipper.md` + masterdata | Uke 6-7 |
Sammenstilling: `9.leveranser-og-oppsummeringer/executive-summary.md` + `sluttrapport.md`.
## Milepæler
| Milepæl | Uke | Forventet utfall |
|---|---|---|
| Kickoff | 1 | Bekreftet scope og plan |
| Delleveranse 1 — Nåsituasjon + risiko | 3 | Forretningssiden ser sin egen situasjon dokumentert |
| Delleveranse 2 — Målbilde + masterdata | 5 | Tydelig retning for arkitektur og dataeierskap |
| Sluttleveranse — Handlingsplan + governance | 6-7 | Konkrete neste skritt, forankret |
## Avhengigheter
*Kritiske eksterne avhengigheter — andre prosjekter, leverandører, frister.*
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,37 @@
---
title: "Møtelogg og beslutninger — Standard Online"
date: "YYYY-MM-DD"
tags: ["møtelogg", "beslutninger", "DEC"]
qa:
status: "draft"
version: 1
---
# Møtelogg og beslutninger
Master-oversikt over alle møter, beslutninger (DEC), handlinger (ACT) og risikoer (RISK). Detaljerte referater i `Motenotater/`.
## Møteoversikt
| Dato | Tema | Deltakere | Referat | Status |
|---|---|---|---|---|
## Beslutningsregister
| ID | Beslutning | Dato | Kilde | Status |
|---|---|---|---|---|
## Handlingsregister
Tverrgående oversikt. Se også [[../7.standardisering-og-handlingsplan/prioriteringsliste]] for prioriterte tiltak.
| ID | Handling | Ansvarlig | Frist | Status |
|---|---|---|---|---|
## Risikoregister
Se [[../../artefakter/risikoregister]] for fullt register med Impact × Likelihood-score.
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,66 @@
---
title: "Oppdragsbeskrivelse — Standard Online"
date: "YYYY-MM-DD"
tags: ["oppdrag", "kontekst", "scope"]
qa:
status: "draft"
version: 1
---
# Oppdragsbeskrivelse
## Kunde
**Selskap:** Standard Online
**Bransje:**
**Geografi:**
**Hovedkontakt hos kunden:**
## Bakgrunn
*Hva er kundens situasjon, og hvorfor er oppdraget aktuelt nå?*
## Problem og mål
**Hovedproblem:**
**Mål med oppdraget:**
1.
2.
3.
## Scope
**Innenfor:**
-
**Utenfor:**
-
## Leveranser
Se [[mal-og-leveranser]] for detaljert leveranseoversikt.
## Tidsramme
**Start:** YYYY-MM-DD
**Slutt:** YYYY-MM-DD
**Total varighet:** N uker
## Team fra Forte
| Person | Rolle | Allokering |
|---|---|---|
## Kommersiell modell
*Time & materials / fastpris / hybrid — kort beskrivelse.*
---
## Endringslogg
| Versjon | Dato | Endring | Forfatter |
|---|---|---|---|
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,38 @@
---
title: "Rammer og avklaringer — Standard Online"
date: "YYYY-MM-DD"
tags: ["rammer", "forutsetninger", "avgrensninger"]
qa:
status: "draft"
version: 1
---
# Rammer og avklaringer
## Forutsetninger
- Beslutningskontakt eller utpekt stedfortreder tilgjengelig for rask respons
- N nøkkelpersoner tilgjengelige for 1-2 timers intervju i Fase B
- Dedikert kontakt hos <ev. utviklingspartner>
- Eksisterende underlag (arkitekturskisser, dataflyt) tilgjengelig fra Fase A
- Potensielle dataeiere deltar i workshops og validering
## Avgrensninger
- Dette er kartlegging og anbefaling — **implementering er ikke inkludert**
- Endelige beslutninger om systemvalg og arkitektur ligger hos kunden
- Detaljert teknisk implementeringsdesign er utenfor scope
- Eventuell implementeringsfase prises som egen leveranse
## Avtalte avklaringer
| Tema | Avklaring | Dato | Bekreftet av |
|---|---|---|---|
## Åpne avklaringspunkter
Se [[../8.kontinuerlig-laering-og-referanser/apne-sporsmal]] for løpende spørsmålsliste.
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,36 @@
---
title: "Nøkkelpersoner for informasjon — Standard Online"
date: "YYYY-MM-DD"
tags: ["interessenter", "kompetanse", "kunnskap"]
qa:
status: "draft"
version: 1
---
# Nøkkelpersoner for informasjon
Hvem vet hva — kunnskapsoversikt for å vite hvem man skal spørre om hva.
## Per system
| System | Hovedressurs | Backup | Type kunnskap (forretning/teknisk) |
|---|---|---|---|
## Per domene
| Datadomene | Hovedressurs | Begrepseier-kandidat | Dataforvalter-kandidat |
|---|---|---|---|
## Per tema
| Tema | Ressurs(er) | Tilgjengelighet |
|---|---|---|
| Historiske beslutninger | | |
| Integrasjoner | | |
| Datakvalitet | | |
| GDPR-praksis | | |
| AI-initiativ | | |
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,39 @@
---
title: "Overordnet organisasjonsstruktur — Standard Online"
date: "YYYY-MM-DD"
tags: ["organisasjon", "struktur"]
qa:
status: "draft"
version: 1
---
# Overordnet organisasjonsstruktur
## Selskap
**Juridisk navn:**
**Eierskap:**
**Søster-/datterselskaper relevant for oppdraget:**
## Hovedstruktur
*Organisasjonshierarki — avdelinger og funksjoner.*
```mermaid
graph TD
A[CEO] --> B[Avdeling 1]
A --> C[Avdeling 2]
```
## Relevante avdelinger for oppdraget
| Avdeling | Antall personer | Hovedansvar | Relevans for oppdraget |
|---|---|---|---|
## Geografisk fordeling
*Lokasjon, distribuerte team, eventuelle utenlandske underavdelinger.*
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,37 @@
---
title: "Roller og beslutningsveier — Standard Online"
date: "YYYY-MM-DD"
tags: ["roller", "beslutning", "governance"]
qa:
status: "draft"
version: 1
---
# Roller og beslutningsveier
## Beslutningsmandat
| Beslutningstype | Hvem beslutter | Hvem konsulterer | Stedfortreder |
|---|---|---|---|
Eksempler på beslutningstyper: systemvalg, dataeierskap, arkitekturprinsipper, leverandørvalg, kostnadsforpliktelser.
## Faglige roller relevant for masterdata og governance
| Rolle | Navn | Avdeling | Ansvar |
|---|---|---|---|
| Systemeier (CRM) | | | |
| Systemeier (ERP) | | | |
| Systemeier (E-handel) | | | |
| Forretningseier kunde-/bedriftsdata | | | |
| IT-ansvarlig | | | |
| Personvernombud / DPO | | | |
| Datakvalitet/MDM | | | |
## Beslutningsvei for governance
*Hvordan tas beslutninger om felles dataeierskap, kodeverk, integrasjonsmønstre på tvers av domener? Beskriv som-er og foreslå om-bør hvis aktuelt.*
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,47 @@
---
title: "Hovedsystemer — Standard Online"
date: "YYYY-MM-DD"
tags: ["systemer", "landskap", "as-is"]
qa:
status: "draft"
version: 1
---
# Hovedsystemer
Komplett oversikt over alle systemer i scope for oppdraget. Bygges ut i Fase A-B.
## Oversikt
| System | Type | Leverandør | Eier (hos kunde) | Forretningskritisk | Status |
|---|---|---|---|---|---|
| | CRM / ERP / E-handel / MDM / Analytics / Identity / Annet | | | Ja/Nei | Aktiv / Under utfasing / Planlagt |
## Detaljer per system
### <Systemnavn>
**Type:** <CRM / ERP / E-handel / etc.>
**Leverandør:**
**Versjon / instans:**
**Hostet:** SaaS / on-prem / hybrid
**Hovedfunksjoner:**
**Primære brukere:** <antall, roller>
**Eier hos kunde:**
**Datamaster for:** <hvilke entiteter er dette systemet master for>
**Datakonsument av:** <hvilke entiteter konsumeres herfra>
**Sentrale integrasjoner:** <ut/inn>
**Datakvalitet — overordnet:** <vurdering, se 4.informasjonsarkitektur/datakvalitet-og-avvik for detaljer>
**Begrensninger / kjente problemer:**
---
*Repeter strukturen for hvert system i scope.*
## Utenfor scope
*Systemer som er bevisst utelatt. Hvorfor og hva impliserer det.*
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,58 @@
---
title: "Integrasjoner og dataflyt — Standard Online"
date: "YYYY-MM-DD"
tags: ["integrasjoner", "dataflyt", "as-is"]
refs:
- "../../artefakter/integrasjonslandskap.md"
qa:
status: "draft"
version: 1
---
# Integrasjoner og dataflyt
Hvordan data flyter mellom systemene som er kartlagt i [[hovedsystemer]].
## Integrasjonslandskap
Bruk strukturen fra [[../../artefakter/integrasjonslandskap]]:
| System | Retning | Motpart | Mekanisme | Datatyper | Frekvens | Implikasjon |
|---|---|---|---|---|---|---|
*Retning: Inbound / Outbound / Bidirectional*
*Mekanisme: API (REST/GraphQL/SOAP), filoverføring, event-bus, manuell, DB-til-DB*
## Dataflyt per entitet
For hver kjerneentitet (Bedrift, Kontakt, Bruker, Ordre, etc.) — beskriv hvor den oppstår, dupliseres og konsumeres.
### Bedrift / Kunde
**Oppstår i:**
**Dupliseres i:**
**Konsumeres av:**
**Master (foreslått):**
**Konflikter / risikomomenter:**
### <Neste entitet>
...
## Visualisering
*Lenke til Mermaid-diagram eller skjermbilde av Neo4j-graf.*
```mermaid
graph LR
A[System A] -->|Bedrift| B[System B]
B -->|Kontakt| C[System C]
```
## Punkt-til-punkt vs. hub-and-spoke
*Vurdering — er dagens arkitektur punkt-til-punkt? Hva er fordeler/ulemper med hub-and-spoke for denne kunden?*
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,40 @@
---
title: "Pågående initiativer — Standard Online"
date: "YYYY-MM-DD"
tags: ["initiativer", "prosjekter", "avhengigheter"]
qa:
status: "draft"
version: 1
---
# Pågående initiativer
Aktive eller planlagte prosjekter hos kunden som er relevante for vårt oppdrag. Påvirker scope, prioritering og rekkefølge for handlingsplanen.
## Oversikt
| Initiativ | Eier | Status | Tidshorisont | Påvirkning på vårt oppdrag |
|---|---|---|---|---|
## Detaljer
### <Initiativnavn>
**Hva:**
**Mål:**
**Status:**
**Eier:**
**Avhengighet til vårt oppdrag:** <leverer input til oss / mottar output / parallell uten direkte kobling>
**Risiko hvis ikke koordinert:**
---
*Repeter for hvert relevant initiativ.*
## Koordineringspunkter
*Konkrete avstemmingsbehov vi må sikre — møter, sjekkpunkter, gjensidige leveranser.*
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,56 @@
---
title: "Systemkart as-is — Standard Online"
date: "YYYY-MM-DD"
tags: ["systemkart", "as-is", "arkitektur"]
qa:
status: "draft"
version: 1
---
# Systemkart (as-is)
Visuell oversikt over dagens systemlandskap. Bygges ut i Fase B basert på [[hovedsystemer]] og [[integrasjoner-og-flyt]].
## Hovedkart
```mermaid
graph TB
subgraph Kundeflate
Web[Nettbutikk]
end
subgraph CRM-lag
CRM[CRM]
end
subgraph ERP-lag
ERP[ERP]
end
subgraph Identitet
IAM[Identity Provider]
end
Web --> CRM
CRM <--> ERP
IAM --> Web
IAM --> CRM
```
*Erstatt med faktisk systemkart for kunden.*
## Detaljkart per domene
*Per kjernedomene (Bedrift, Kontakt, Bruker, Ordre, Abonnement) — eget diagram som viser hvilke systemer som er involvert og hvordan dataflyt går.*
## Observasjoner
*Hovedfunn fra systemkartleggingen: redundans, gap, single points of failure, "skygge-systemer".*
## Sammenligning med målbilde
Lenke til [[../9.leveranser-og-oppsummeringer/sluttrapport#målarkitektur]] når den er ferdig.
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,39 @@
---
title: "Teknologier og leverandører — Standard Online"
date: "YYYY-MM-DD"
tags: ["teknologi", "leverandører", "lock-in"]
qa:
status: "draft"
version: 1
---
# Teknologier og leverandører
## Teknologistack
| Område | Teknologi | Versjon | Vurdering |
|---|---|---|---|
| Cloud | | | |
| Database(r) | | | |
| Integrasjonsplattform | | | |
| Identitet/IAM | | | |
| Analytics/BI | | | |
| AI/ML | | | |
| CI/CD og DevOps | | | |
## Leverandører
| Leverandør | Hva de leverer | Avtaletype | Kontrakt utløper | Innlåsing? |
|---|---|---|---|---|
## Lock-in og strategiske vurderinger
*Hvor er det proprietære teknologivalg som låser kunden? Hva er konsekvensen for fremtidig fleksibilitet?*
## Avhengighet til eksterne tjenester
*SaaS, API-er, externt hostet — hva er kritisk?*
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,45 @@
---
title: "Begrepskatalog — Standard Online"
date: "YYYY-MM-DD"
tags: ["begrepskatalog", "terminologi", "informasjonsarkitektur"]
refs:
- "informasjonsdomener.md"
- "masterdata-og-eierskap.md"
qa:
status: "draft"
version: 1
---
# Begrepskatalog
Felles begrepsdefinisjoner for Standard Online. Bygges ut løpende gjennom oppdraget — start enkelt og utvid etter hvert som diskusjoner avdekker uklarheter.
## Hvordan bruke
- **Definisjon** skal være entydig og gjenkjennelig for forretningen
- **Domene** kobler begrepet til [[informasjonsdomener]]
- **Begrepseier** er den som har semantisk eierskap (definerer hva begrepet betyr)
- **System-of-Record** er det systemet som er autoritativ kilde for data om dette begrepet
- **Relaterte begreper** lenkes med [[term]]
## Katalog
| Term | Definisjon | Domene | Begrepseier | System-of-Record | Relaterte |
|---|---|---|---|---|---|
| Bedrift | En juridisk enhet som vi har et kunde-, leverandør- eller partnerforhold til | Bedrift | | | [[Kontakt]], [[Avtale]] |
| Kontakt | Person tilknyttet en bedrift, identifisert med navn og kontaktinformasjon | Person | | | [[Bedrift]], [[Bruker]] |
| Bruker | Person med autentisert tilgang til en av våre tjenester | Person | | | [[Kontakt]], [[Rolle]] |
| Ordre | Bestilling av varer eller tjenester med kobling til [[Bedrift]] og [[Bruker]] | Ordre | | | [[Produkt]], [[Faktura]] |
*Disse er eksempler — bytt ut, slett eller utvid basert på kunden.*
## Avklaringer og uenigheter
*Begreper hvor det er aktiv diskusjon eller uavklart terminologi. Logg her før det rettes opp.*
| Term | Uavklart aspekt | Status |
|---|---|---|
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,85 @@
---
title: "Data Governance prinsipper — Standard Online"
date: "YYYY-MM-DD"
tags: ["governance", "prinsipper", "dataeierskap"]
refs:
- "masterdata-og-eierskap.md"
- "informasjonsdomener.md"
qa:
status: "draft"
version: 1
---
# Data Governance prinsipper
Formålet med Data Governance hos Standard Online:
- Sikre tillit til data på tvers av organisasjonen
- Avklare roller og ansvar for dataforvaltning
- Balansere ulike behov for data mellom organisatoriske enheter
- Sikre datakvalitet og etterlevelse av krav
## Tre nivåer av dataeierskap
### 1. Dataforvalter (Data Steward) — operativt nivå
**Rolle:** De som registrerer og oppdaterer data daglig i operative systemer.
**Ansvar:**
- Registrere og oppdatere data i henhold til forretningsprosesser
- Sikre korrekthet, fullstendighet og aktualitet i data
- Følge standarder og kodeverk etablert av domeneeier
- Rapportere datakvalitetsproblemer
**Eksempler:** Saksbehandler i CRM, kundebehandler, lagerarbeider.
### 2. Domain Data Owner — taktisk nivå
**Rolle:** Representerer databehov og bruk innenfor et domene/område.
**Ansvar:**
- Definere hvordan domenet forholder seg til felles kjernebegreper
- Definere hvordan data blir tilgjengelig for konsumenter
- Etablere og forvalte kodeverk for domenet
- Godkjenne endringer i datamodellen
- Sikre at data tilfredsstiller de 8 kriteriene (se [[masterdata-og-eierskap#8-kriterier-for-godt-dataeierskap]])
**Eksempler:** Fagavdeling kunde- og bedriftsdata, fagavdeling produktdata.
### 3. Strategisk dataeier (Steering Committee) — strategisk nivå
**Rolle:** Beslutter på tvers av domener — investeringer, prinsipper, prioriteringer.
**Ansvar:**
- Etablere overordnet datastrategi
- Beslutte konflikter mellom domener
- Allokere ressurser til governance-arbeid
- Sikre at GDPR og andre regulatoriske krav etterleves på tvers
**Typisk:** Digitaliseringsdirektør, CIO, CDO.
## Prinsipper
Foreslåtte prinsipper for Standard Online — kalibrer og bytt ut etter behov:
1. **Tydelig System-of-Record per entitet** — én autoritativ kilde per masterdata-entitet
2. **Skille semantisk og operasjonelt eierskap** — Begrepseier ≠ Dataforvalter
3. **Privacy by Design** — GDPR som premiss i alle nye løsninger, ikke etterarbeid
4. **API-først for dataflyt** — felles tilgang via API, ikke direkte DB-integrasjoner
5. **Felles kodeverk** — bytt anarki med kontrollerte kodeverk per domene
6. **Datakvalitet måles og rapporteres** — KPIer per masterdata-entitet
7. **Endringer i datamodell går gjennom Domain Data Owner**
8. **Dataportal med metadata** — gjør data oppdagbar (Discoverable)
9. **Logging og sporbarhet** — hvem endret hva, når, hvorfor
10. **Konsumenter er kjent og styrt** — Domain Data Owner vet hvem som bruker hva
## Avvik fra prinsipper
*Prinsipper kan fravikes hvis andre hensyn krever det. Logg avvik her med begrunnelse.*
| Prinsipp | Avvik | Begrunnelse | Eier av avviket | Plan for opprydding |
|---|---|---|---|---|
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,41 @@
---
title: "Datakilder per domene — Standard Online"
date: "YYYY-MM-DD"
tags: ["datakilder", "domener"]
refs:
- "informasjonsdomener.md"
- "../3.system-og-datalandskap/hovedsystemer.md"
qa:
status: "draft"
version: 1
---
# Datakilder per domene
Mapping mellom kjernedomener og hvilke systemer som leverer/forvalter data per domene.
## Matrise
| Domene | Primær kilde (SoR) | Sekundære kilder | Avledet data (rapport/analyse) |
|---|---|---|---|
## Detaljer
### <Domene>
**SoR-system:**
**Andre systemer med samme entitet:** *Hvorfor? Synkronisering eller egen kopi?*
**Hvilke felter mangler i SoR?** *Vurder om sekundære kilder kompletterer SoR.*
**Hvilke felter er duplisert?** *Risiko for konflikt.*
---
*Repeter for hvert domene.*
## Foreldede / utgående kilder
*Systemer som fortsatt forvalter data, men som er planlagt utfaset. Implikasjoner.*
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,57 @@
---
title: "Datakvalitet og avvik — Standard Online"
date: "YYYY-MM-DD"
tags: ["datakvalitet", "avvik", "DQ"]
qa:
status: "draft"
version: 1
---
# Datakvalitet og avvik
Vurdering av datakvalitet per domene og per system. Bygges ut i Fase B basert på intervjuer og evt. dataprofileringer.
## Datakvalitet-dimensjoner
Standardvurdering per dimensjon:
| Dimensjon | Beskrivelse |
|---|---|
| Fullstendighet | Andel obligatoriske felter som er fylt ut |
| Korrekthet | Andel verdier som er gyldige |
| Konsistens | Samme data på tvers av systemer |
| Aktualitet | Hvor oppdatert data er |
| Entydighet | Mangel på duplikater |
| Integritet | Refererende integritet mellom relaterte data |
## Vurdering per masterdata-entitet
### <Entitet>
| Dimensjon | Vurdering | Tall/funn | Risiko hvis ikke fikset |
|---|---|---|---|
| Fullstendighet | Lav/Middels/Høy | f.eks. "75% mangler e-post" | |
| Korrekthet | | | |
| Konsistens | | | |
| Aktualitet | | | |
| Entydighet | | | |
| Integritet | | | |
---
*Repeter for hver masterdata-entitet.*
## Avviksliste
Konkrete observerte avvik. Også lenket fra [[../7.standardisering-og-handlingsplan/avviksliste]].
| ID | Avvik | Domene | System | Konsekvens | Foreslått tiltak |
|---|---|---|---|---|---|
## Anbefalinger
*Prioriterte tiltak for datakvalitet, koblet til [[../7.standardisering-og-handlingsplan/prioriteringsliste]].*
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,71 @@
---
title: "Informasjonsdomener — Standard Online"
date: "YYYY-MM-DD"
tags: ["domener", "informasjonsarkitektur", "masterdata"]
refs:
- "masterdata-og-eierskap.md"
- "begrepskatalog.md"
qa:
status: "draft"
version: 1
---
# Informasjonsdomener
Hovedinndeling av informasjon hos Standard Online. Hvert domene har en eller flere kjerneentiteter, et tildelt System-of-Record, og en domain data owner.
## Domeneoversikt
| Domene | Kjerneentiteter | Master (SoR) | Status | Modenhet |
|---|---|---|---|---|
*Status: **KRITISK** (fragmentert/uten eierskap) / **VIKTIG** (etablert, men forbedringspotensial) / **OK** (godt forvaltet)*
*Modenhet: 0=Anarki, 1=Reaktiv, 2=Definert, 3=Forvaltet, 4=Optimalisert*
## Detaljer per domene
### <Domenenavn> — eksempel: Bedrift
**Definisjon:** *Hva omfatter domenet?*
**Kjerneentiteter:**
- <Entitet 1>
- <Entitet 2>
**Master (System-of-Record):** *Hvilket system er autoritativ kilde?*
**Konsumenter:** *Hvilke systemer leser/synkroniserer fra master?*
**Domain Data Owner-kandidat:** *Hvem er foreslått som domeneier?*
**Nåsituasjon:**
*Hvordan er domenet forvaltet i dag? Funn fra Fase B.*
**Gap mot ideal:**
*Hva mangler for at domenet skal være godt forvaltet?*
**Risikoer:**
*Kobling til [[../../artefakter/risikoregister]].*
**Anbefalte tiltak:**
*Kobling til [[../7.standardisering-og-handlingsplan/prioriteringsliste]].*
---
*Repeter strukturen for hvert kjernedomene.*
## Domene-relasjoner
*Visualisering — hvilke domener avhenger av eller refererer til hverandre?*
```mermaid
graph LR
Bedrift --> Kontakt
Kontakt --> Bruker
Bedrift --> Ordre
Bruker --> Ordre
```
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,107 @@
---
title: "Masterdata og eierskap — Standard Online"
date: "YYYY-MM-DD"
tags: ["masterdata", "eierskap", "governance", "MDM"]
refs:
- "informasjonsdomener.md"
- "data-governance-prinsipper.md"
- "begrepskatalog.md"
qa:
status: "draft"
version: 1
---
# Masterdata og eierskap
Dette dokumentet definerer:
- Hva som er masterdata hos Standard Online
- Hvem som er master (System-of-Record) for hver dataentitet
- Hvem som er begrepseier (semantisk eierskap)
- Hvem som er dataforvalter (operativt ansvar)
## Definisjoner
### Masterdata
**Kjernedata som er kritisk for virksomheten og deles på tvers av systemer.** Masterdata er:
- **Stabil** — endres sjelden (ikke transaksjonsdata)
- **Delt** — brukes av flere systemer
- **Kritisk** — nødvendig for virksomhetsprosesser
- **Autoritativ** — har en tydelig master (System-of-Record)
**Eksempler på masterdata (typisk):**
- Bedrift / Kunde
- Kontakt / Person
- Bruker
- Produkt
- Organisasjonsenhet
**IKKE masterdata:**
- Transaksjonsdata (ordre, fakturalinjer)
- Rapporter og statistikk
- Dokumenter og filer
### Tre roller — semantikk, operasjon, system
Skillet er kritisk — "dataeier" som ett begrep skaper diskusjon. Vi skiller derfor:
| Rolle | Engelsk | Hva | Typisk rolle |
|---|---|---|---|
| **Begrepseier** | Semantic Owner | Definerer hva begrepet betyr | Fagavdeling, domain owner |
| **Dataforvalter** | Data Steward | Operativt ansvar for datakvalitet | Systemeier, produkteier, tech lead |
| **Master / System-of-Record** | System of Record | Autoritativ kilde, andre synkroniserer fra denne | Konkret system |
## Masterdata-oversikt
| Entitet | Master (SoR) | Begrepseier | Dataforvalter | Konsumenter | Sensitivitet |
|---|---|---|---|---|---|
*Sensitivitet: Ikke-sensitiv / Personopplysning / Spesielt sensitiv (særskilt kategori)*
## Per entitet
### <Entitet> — eksempel: Bedrift
**Definisjon:** *Hva er en bedrift i denne sammenhengen? Lenke til [[begrepskatalog]].*
**Master (SoR):**
- **System:**
- **Begrunnelse:** *Hvorfor er dette riktig master?*
- **Konsekvens:** *Andre systemer skriver IKKE direkte; de mottar og konsumerer*
**Begrepseier:** <rolle/avdeling>
**Dataforvalter:** <rolle/avdeling>
**Identifikator:**
- **Primær:** *Hvilket attributt unikt identifiserer entiteten? (Org.nr., e-post, intern ID)*
- **Alternativer i dag:** *Hvilke ulike nøkler brukes i ulike systemer? Konfliktrisiko?*
**Tilstand:**
- **Kvalitet:** <vurdering — lenke til [[datakvalitet-og-avvik]]>
- **Gap:**
- **Anbefalt tiltak:** *Lenke til [[../7.standardisering-og-handlingsplan/prioriteringsliste]]*
---
*Repeter for hver masterdata-entitet.*
## 8 kriterier for godt dataeierskap
Data Governance-prinsipper (fra DNK / "Orden i eget hus"). Dataforvalter skal sikre at data tilfredsstiller:
1. **Discoverable** — kan finnes/oppdages (datakatalog)
2. **Addressable** — kan adresseres entydig
3. **Understandable** — forståelig (dokumentert begrep og struktur)
4. **Trustworthy** — troverdig (kjent kvalitet, kjent kilde)
5. **Interoperable** — interoperabel (kan kombineres med annen data)
6. **Accessible** — aksesserbar (gjennom dataportal/marked)
7. **Secure** — sikker (tilgangsstyring, kryptering der nødvendig)
8. **Valuable** — verdi og effekt (faktisk brukt og nyttig)
For hver masterdata-entitet kan disse 8 kriteriene vurderes som en modenhetscheck.
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,38 @@
---
title: "Standardiseringsbehov — Standard Online"
date: "YYYY-MM-DD"
tags: ["standardisering", "kodeverk", "felles-strukturer"]
qa:
status: "draft"
version: 1
---
# Standardiseringsbehov
Identifiserte behov for felles standarder, kodeverk og strukturer på tvers av systemene.
## Kodeverk
| Kodeverk | Beskrivelse | Forvaltes i | Brukes av | Status | Anbefalt tiltak |
|---|---|---|---|---|---|
*Status: Eksisterer / Delvis / Mangler / Anarki (ulike verdier per system)*
## Felles strukturer
*Adresse-format, navn-strukturer, identifikatorer, statuser. Hvor er felles strukturer mangelfulle?*
| Struktur | Dagens praksis | Forslag | Avhengighet |
|---|---|---|---|
## Naming og terminologi
*Forskjellige navn på samme ting på tvers av systemer. Konflikter mellom forretning og teknologi.*
## Anbefalinger
Lenke til [[../7.standardisering-og-handlingsplan/prioriteringsliste]] for prioriterte tiltak.
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,47 @@
---
title: "Dataflyt og personvernrisiko — Standard Online"
date: "YYYY-MM-DD"
tags: ["dataflyt", "personvern", "risiko"]
refs:
- "../3.system-og-datalandskap/integrasjoner-og-flyt.md"
- "sensitive-dataomrader.md"
qa:
status: "draft"
version: 1
---
# Dataflyt og personvernrisiko
Personvernperspektiv på dataflyten kartlagt i [[../3.system-og-datalandskap/integrasjoner-og-flyt]].
## Risikomatrise per integrasjon
| Integrasjon | Personopplysninger? | Særskilt kategori? | Cross-border? | Logget? | Risikonivå | Tiltak |
|---|---|---|---|---|---|---|
*Risikonivå: Lav / Middels / Høy / Kritisk*
## Spesielle risikopunkter
### Cross-org dataoverføring
*Hvis data deles med søsterselskap, partnere, eller eksterne leverandører — DPA på plass?*
### Anonymisering / pseudonymisering
*Hvor brukes anonymisering for å redusere risiko? Hvor burde det innføres?*
### Skyggekopier og uplanlagt deling
*Data som havner i Excel, BI-verktøy, e-postvedlegg — hvor er kontrolltap størst?*
## DPIA-vurdering
*Hvor er det behov for Data Protection Impact Assessment? Krav når behandling sannsynligvis medfører høy risiko (art. 35).*
| Behandling | DPIA påkrevd? | Status | Plan |
|---|---|---|---|
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,68 @@
---
title: "GDPR-oversikt — Standard Online"
date: "YYYY-MM-DD"
tags: ["gdpr", "personvern", "compliance"]
refs:
- "../4.informasjonsarkitektur/masterdata-og-eierskap.md"
- "tiltak-for-innebygd-personvern.md"
qa:
status: "draft"
version: 1
---
# GDPR-oversikt
Overordnet vurdering av GDPR-etterlevelse hos Standard Online. Detaljer i de andre filene i denne mappen.
## Rolledefinisjon
| Rolle | Hvem hos Standard Online | Ansvar |
|---|---|---|
| Behandlingsansvarlig | | Bestemmer formål og midler for behandling |
| Databehandler | | Behandler personopplysninger på vegne av behandlingsansvarlig |
| Personvernombud (DPO) | | Rådgiver og kontaktpunkt for tilsyn |
## Behandlingsoversikt
Skal omfatte alle behandlinger av personopplysninger. Bygges ut i Fase B.
| Behandling | Behandlingsgrunnlag | Formål | Kategorier personopplysninger | Mottakere | Lagringstid |
|---|---|---|---|---|---|
*Behandlingsgrunnlag: Samtykke / Avtale / Rettslig forpliktelse / Vitale interesser / Allmenn interesse / Berettiget interesse*
## Sentrale GDPR-krav
| Krav | Status | Kommentar |
|---|---|---|
| Behandlingsgrunnlag dokumentert | | |
| Personvernerklæring publisert | | |
| Databehandleravtaler (DPA) på plass | | |
| Innsynsrett-prosess etablert | | |
| Sletting/rettelse-prosess etablert | | |
| Dataminimering vurdert | | |
| Lagringstid definert per kategori | | |
| Sikkerhetstiltak dokumentert | | |
| Avvikshåndtering etablert (72-timersregel) | | |
| DPIA gjennomført for høyrisiko-behandling | | |
## Cross-border data transfers
*Overføring av personopplysninger ut av EØS — er det relevant? Standard-/SCC-grunnlag på plass?*
## AI-spesifikke aspekter
- **Automatiserte beslutninger (art. 22):** Hvilke beslutninger tas helt eller delvis automatisert? Krever explicit consent eller annet grunnlag?
- **Treningsdata:** Hvis AI-modeller trenes på persondata — hva er behandlingsgrunnlaget?
- **Forklarbarhet:** Kan vi forklare hvordan en AI-beslutning er tatt? (jf. art. 13/14)
- **Sletting:** Kan persondata slettes fra både operative systemer og trente modeller?
Lenke til [[../6.ai-rammeverk/ai-prinsipper]].
## Risikoer
Lenke til [[../../artefakter/risikoregister]] for GDPR-relaterte risikoer.
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,41 @@
---
title: "Personvernroller og -ansvar — Standard Online"
date: "YYYY-MM-DD"
tags: ["roller", "personvern", "ansvar"]
qa:
status: "draft"
version: 1
---
# Personvernroller og -ansvar
## Hovedroller
| Rolle | Person/funksjon | Hva omfatter ansvaret |
|---|---|---|
| Behandlingsansvarlig | | Bestemmer formål og midler |
| Personvernombud (DPO) | | Uavhengig rådgiver, kontakt mot tilsyn |
| Sikkerhetsleder / CISO | | Informasjonssikkerhet |
| Systemeier per system | | Praktisk personvernforvaltning |
| Domain Data Owner | | Per domene — personvernhensyn i datamodell |
## Databehandlere
| Databehandler | Hva de behandler | DPA på plass? | Underbehandlere godkjent? |
|---|---|---|---|
## RACI-matrise for personvern-aktiviteter
| Aktivitet | DPO | CISO | Systemeier | Forretningseier |
|---|---|---|---|---|
| Behandlingsoversikt | R/A | C | R | I |
| DPIA | A | C | R | C |
| Avvikshåndtering | C | A | R | I |
| Innsynsbegjæring | A | I | R | C |
| Sletting | A | I | R | C |
*R=Responsible, A=Accountable, C=Consulted, I=Informed*
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,59 @@
---
title: "Sensitive dataområder — Standard Online"
date: "YYYY-MM-DD"
tags: ["sensitivitet", "personvern", "særskilte-kategorier"]
qa:
status: "draft"
version: 1
---
# Sensitive dataområder
Kartlegging av hvor sensitive personopplysninger befinner seg hos Standard Online.
## Sensitivitetsnivåer
Vi opererer med tre nivåer:
| Nivå | Beskrivelse | Eksempler |
|---|---|---|
| Ikke-sensitiv | Generelle forretningsdata | Bedriftsnavn, leveranseadresse |
| Personopplysning (alminnelig) | Identifiserer person uten å være særskilt sensitivt | Navn, e-post, telefon, kjøpshistorikk |
| Spesielt sensitiv (særskilt kategori) | Art. 9-data — krever ekstra grunnlag | Helse, etnisitet, religion, fagforening, politisk syn, seksuell orientering |
## Oversikt per system
| System | Personopplysninger? | Særskilte kategorier? | Antall berørte personer | Lagringstid | Risiko |
|---|---|---|---|---|---|
## Per domene
### <Domene>
**Hvilke felter er personopplysninger?**
**Hvilke felter er særskilte kategorier?** (Hvis noen — krever særlig grunnlag)
**Sletteplikt:** Når slettes/anonymiseres data?
**Aggregert vs. individnivå:** Brukes data også aggregert (mindre risiko)?
---
*Repeter for relevante domener.*
## Datakart for personopplysninger
*Visualisering — hvor flyter personopplysninger? Hvor lagres de? Hvor kopieres de?*
```mermaid
graph LR
Kunde[Kunde fyller ut skjema] --> Web[Nettbutikk]
Web --> CRM
CRM --> ERP
CRM --> Analyse[Analytics]
```
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,69 @@
---
title: "Tiltak for innebygd personvern — Standard Online"
date: "YYYY-MM-DD"
tags: ["privacy-by-design", "gdpr", "tiltak"]
refs:
- "gdpr-oversikt.md"
- "../4.informasjonsarkitektur/masterdata-og-eierskap.md"
qa:
status: "draft"
version: 1
---
# Tiltak for innebygd personvern
GDPR artikkel 25 krever **innebygd personvern (Privacy by Design)** og **personvern som standardinnstilling (Privacy by Default)**.
## Privacy by Design — implementerte og pågående tiltak
Struktur (basert på DNK-mønster):
### 1. Identitet og tilgangsstyring (IAM)
*Hvilket IAM-system brukes? Token-basert? Single sign-on? Hvordan styres tilganger til personopplysninger?*
### 2. API-sikkerhet
*Krever nye API-er autentisering? Hvilke gamle integrasjoner bruker basic auth eller åpne endepunkter?*
### 3. Dataminimering
*Hvilke API-er/views har versjoner med redusert personinformasjon for konsumenter som ikke trenger fullstendig data?*
### 4. Tilgangsstyring per dataområde
*Rollebasert? Per system? Per datadomene?*
### 5. Logging og sporbarhet
*Hva logges av hvem-gjorde-hva-når? Hvor lagres logger? Hvor lenge?*
## Privacy by Default
*Standardinnstillinger som beskytter personvern uten at brukeren må gjøre noe:*
- **Identifikatorbruk:** Brukes personnummer kun der lov krever det? Bruk Person-ID/intern-ID som integrasjonsnøkkel.
- **Innsamling:** Samles kun nødvendige opplysninger inn?
- **Lagring:** Hva er standard lagringstid? Slettes automatisk når formålet opphører?
- **Deling:** Er deling med tredjeparter opt-in?
## Mangler og planlagte tiltak
Følgende tiltak mangler eller bør prioriteres hos Standard Online:
| Tiltak | Status | Begrunnelse | Prioritet |
|---|---|---|---|
| Samtykkeforvaltning | | | |
| Dataportal med personvernklassifisering | | | |
| DPIA-prosess for nye integrasjoner | | | |
| Offboarding-rutiner for tilganger | | | |
| Avvikshåndteringsprosess (72-timersregel) | | | |
| Behandlingsoversikt | | | |
## Anbefalinger
*Lenke til [[../7.standardisering-og-handlingsplan/prioriteringsliste]] for prioriterte tiltak.*
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,59 @@
---
title: "AI-prinsipper — Standard Online"
date: "YYYY-MM-DD"
tags: ["ai", "prinsipper", "rammeverk"]
refs:
- "../4.informasjonsarkitektur/masterdata-og-eierskap.md"
- "../5.personvern-og-sikkerhet/gdpr-oversikt.md"
- "identifiserbarhet-og-tilgang.md"
- "logging-og-sporbarhet.md"
- "human-in-the-loop.md"
qa:
status: "draft"
version: 1
---
# AI-prinsipper
Operasjonelle prinsipper for AI-agenter hos Standard Online. **Dette er ikke en arkitektur-spec** — det er et sett premisser som arkitekturen må respektere. Konkret implementering avklares i en senere fase.
## Grunnpremiss
AI-agenter blir bare så pålitelige som dataene under dem. Kontroll og eierskap til data er fundamentet for å kunne sette agenter i produksjon. AI-fundamentet er bygget på [[../4.informasjonsarkitektur/masterdata-og-eierskap]] og [[../4.informasjonsarkitektur/data-governance-prinsipper]].
## Fem prinsipper
### 1. Identifiserbarhet — hver agent har egen identitet
Ingen AI-agent skal opptre under en generisk eller delt identitet. Hver agent autentiseres og autoriseres som en egen entitet. Se [[identifiserbarhet-og-tilgang]].
### 2. Minste privilegium — agenter får kun det de trenger
Tilganger gis per agent, per oppgave, og kun til nødvendig data og funksjonalitet. Tilganger gjennomgås periodisk. Se [[identifiserbarhet-og-tilgang]].
### 3. Sporbarhet — hver handling logges
Hver handling utført av en agent logges med agent-ID, tidspunkt, input, output og berørt data. Logger er tilgjengelige for dataeier. Se [[logging-og-sporbarhet]].
### 4. Human-in-the-loop for kritiske beslutninger
Beslutninger kategoriseres i tre nivåer: autonom, varslende, godkjennende. Kategoriseringen reflekterer risiko og reversibilitet. Se [[human-in-the-loop]].
### 5. Datakvalitet som premiss
En agent settes ikke i produksjon mot et domene før domenet har tydelig System-of-Record, definert Dataforvalter og minimum akseptabel datakvalitet. Se [[datakvalitet-som-ai-premiss]].
## Åpne spørsmål for kundedialog
Disse spørsmålene bør avklares før konkret AI-arkitektur designes:
- Hva er kundens akseptable risikonivå for autonome handlinger?
- Hvilke domener er "high-stakes" hvor menneskelig godkjenning alltid kreves?
- Hvilke ansatte/roller skal kunne sette opp og endre agenter?
- Hvordan håndteres feil og avvik fra agenter — incident response?
- Hvilke åpne kilder/LLM-leverandører er akseptable? Hva er GDPR-grunnlaget for treningsdata?
- Hva er kundens posisjon på AI-baserte beslutninger overfor sluttbrukere (transparens, klagerett)?
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,63 @@
---
title: "Datakvalitet som AI-premiss — Standard Online"
date: "YYYY-MM-DD"
tags: ["ai", "datakvalitet", "premiss"]
refs:
- "ai-prinsipper.md"
- "../4.informasjonsarkitektur/masterdata-og-eierskap.md"
- "../4.informasjonsarkitektur/datakvalitet-og-avvik.md"
qa:
status: "draft"
version: 1
---
# Datakvalitet som AI-premiss
## Prinsipp
**AI-agenter blir bare så pålitelige som dataene under dem.** En agent settes ikke i produksjon mot et domene før domenet har:
1. Tydelig **System-of-Record**
2. Definert **Dataforvalter**
3. Minimum akseptabel **datakvalitet** for use casen
4. Sporbar **datakilde** for treningsdata (hvis aktuelt)
## Modenhets-gate per domene
Per masterdata-domene må følgende være på plass før AI-agenter slippes inn:
| Krav | Lenke |
|---|---|
| SoR tildelt | [[../4.informasjonsarkitektur/masterdata-og-eierskap]] |
| Dataforvalter utnevnt | [[../4.informasjonsarkitektur/masterdata-og-eierskap]] |
| Begrepskatalog dekker entitetene | [[../4.informasjonsarkitektur/begrepskatalog]] |
| Datakvalitet kjent (måling utført) | [[../4.informasjonsarkitektur/datakvalitet-og-avvik]] |
| Personverntiltak på plass | [[../5.personvern-og-sikkerhet/tiltak-for-innebygd-personvern]] |
| Tilgangsstyring etablert | [[identifiserbarhet-og-tilgang]] |
## Per use case
| AI-use case | Domene(r) | Modenhet | Klar for produksjon? |
|---|---|---|---|
## Garbage in, garbage out
Konkrete risikoer hvis datakvalitet ikke er på plass:
- **Hallusinasjon-amplifisering:** LLM-er bygger på data — dårlig data gir feilaktige svar med høy konfidens
- **Skjevhet (bias):** Manglende eller skjev data gir diskriminerende output
- **Reproduserbarhet:** Uten kjent kilde kan man ikke reprodusere eller fikse feil
- **Ansvar:** Hvem svarer for feil hvis dataeier ikke er utpekt?
## AI-treningsdata
Hvis modeller trenes på Standard Onlines data:
- **Behandlingsgrunnlag:** Hva er GDPR-grunnlaget for å bruke persondata til trening?
- **Anonymisering:** Kan data anonymiseres før trening?
- **Sletting:** Hvordan håndteres sletteforespørsler — må modellen retrenes?
- **Versjonering:** Hvilken datasnapshot trente vi på?
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,81 @@
---
title: "Human-in-the-loop — AI-agenter hos Standard Online"
date: "YYYY-MM-DD"
tags: ["ai", "hitl", "godkjenning", "kontroll"]
refs:
- "ai-prinsipper.md"
qa:
status: "draft"
version: 1
---
# Human-in-the-loop
## Prinsipp
Ikke alle AI-handlinger krever menneskelig godkjenning, men noen gjør det. Kategoriseringen reflekterer risiko, reversibilitet og regulatoriske krav (jf. GDPR art. 22 om automatiserte beslutninger).
## Tre nivåer
### Nivå 1 — Autonom
Agenten handler uten å varsle menneske. Loggene er etterspørrbar, men ingen aktiv kontroll.
**Brukes når:**
- Handlingen er lett reversibel
- Risiko ved feil er lav
- Volumet gjør manuell kontroll umulig (f.eks. innholdsklassifisering)
**Eksempler:** Kategorisering av e-post for ruting, generering av interne sammendrag, automatisk merking av produkter.
### Nivå 2 — Varslende
Agenten handler, men varsler menneske som kan korrigere innen rimelig tid. Handling utføres ikke automatisk hvis konfidens er under en terskel.
**Brukes når:**
- Handlingen kan reverseres, men korrigering har en kostnad
- Risiko ved feil er moderat
- Modell-konfidens kan brukes som filter
**Eksempler:** Foreslå svar til kunde med menneskelig review før utsendelse, oppdatere kundedata med flagg for verifisering.
### Nivå 3 — Godkjennende
Agenten foreslår, menneske godkjenner aktivt før handling utføres.
**Brukes når:**
- Handlingen er vanskelig/umulig å reversere
- Risiko ved feil er høy
- Regulatoriske krav (f.eks. GDPR art. 22 for beslutninger med rettsvirkning)
- Beslutningen har stor økonomisk konsekvens
**Eksempler:** Prising over en terskel, kredittsjekk-baserte avslag, automatiserte kommunikasjon med juridisk konsekvens.
## Kategorisering per use case
Bygges ut for konkrete AI-initiativ hos Standard Online:
| Use case | Nivå | Begrunnelse | Konfidens-terskel for Nivå 2 |
|---|---|---|---|
## GDPR art. 22
Automatiserte beslutninger med rettslige eller tilsvarende virkninger krever **explicit consent** eller annet grunnlag. Slike beslutninger må:
- Inneholde menneskelig vurdering på begjæring (rett til menneskelig inngripen)
- Være forklarbare (meningsfull informasjon om logikken)
- Kunne klages på
Disse use casene er **alltid Nivå 3** og må DPIA-vurderes.
## Åpne avklaringer
| Spørsmål | Status |
|---|---|
| Hvem fastsetter HITL-nivå per use case? | |
| Hvilke konfidens-terskler brukes? | |
| Hvem reviewer Nivå 2-handlinger som ikke blir korrigert? | |
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,56 @@
---
title: "Identifiserbarhet og tilgang — AI-agenter hos Standard Online"
date: "YYYY-MM-DD"
tags: ["ai", "identitet", "tilgang", "iam"]
refs:
- "ai-prinsipper.md"
- "../5.personvern-og-sikkerhet/tiltak-for-innebygd-personvern.md"
qa:
status: "draft"
version: 1
---
# Identifiserbarhet og tilgang for AI-agenter
## Prinsipp
Hver AI-agent skal være identifiserbar og autoriseres som egen entitet — på samme måte som mennesker eller systemer. Generisk eller delt agent-identitet er ikke akseptabelt.
## Agent som identitet
| Element | Krav |
|---|---|
| Unik identifikator | Hver agent-instans har egen ID |
| Autentisering | Token-basert (f.eks. EntraID, OIDC client credentials) |
| Eier | En menneskelig eller organisatorisk eier per agent |
| Levetidssyklus | Opprettelse, endring, dekommisjonering dokumentert |
| Synlighet | Agenter er listet i et register tilgjengelig for systemeiere |
## Tilgangsstyring
### Minste privilegium
Agenten gis kun tilgang til:
- De data den faktisk trenger for sin oppgave
- De funksjoner (skriving, lesing, ekstern integrasjon) som er nødvendige
- Den tidsperioden tilgangen behøves
### Skille les vs. skriv
Lese-tilganger gis lettere. Skrive-tilganger krever eksplisitt godkjenning fra Dataforvalter for berørt domene.
### Tilgangsreview
Tilganger gjennomgås minst hvert kvartal, eller når en agent endres betydelig.
## Åpne avklaringer
| Spørsmål | Status |
|---|---|
| Hvilket IAM-system administrerer agent-identiteter? | |
| Hvem godkjenner ny agent-tilgang per domene? | |
| Hvordan håndteres roterte tokens / hemmeligheter? | |
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,55 @@
---
title: "Logging og sporbarhet — AI-agenter hos Standard Online"
date: "YYYY-MM-DD"
tags: ["ai", "logging", "sporbarhet", "audit"]
refs:
- "ai-prinsipper.md"
qa:
status: "draft"
version: 1
---
# Logging og sporbarhet for AI-agenter
## Prinsipp
Hver handling utført av en AI-agent skal være sporbar — hvem (hvilken agent), hva (input/output), når, og hvilke data ble berørt.
## Hva skal logges
| Element | Hvorfor |
|---|---|
| Agent-ID + agent-versjon | Identifisere kilden |
| Tidspunkt (UTC, millisekunder) | Rekonstruere hendelsesforløp |
| Input/prompt | Forstå hva agenten ble bedt om |
| Output/handling | Forstå hva agenten gjorde |
| Berørte dataentiteter | Kobling til SoR for sletteforpliktelse |
| Konfidens / modellscore | Forstå usikkerhet i beslutning |
| Eskaleringspunkter | Når ble HITL utløst, av hva |
## Hvor logges det
Sentral loggplattform tilgjengelig for:
- **Systemeier** for agent-instansen
- **Dataforvalter** for berørt domene
- **DPO** ved personverninnsyn eller sletteforespørsler
- **Sikkerhetsleder** ved incident-respons
Logger lagres med samme krav som andre systemlogger (typisk 12-24 måneder, kortere for personopplysninger der formålet er oppfylt).
## Sporbarhet på tvers av agentkjeder
Hvis en agent kaller en annen agent eller et eksternt API, skal sammenhengen være sporbar via correlation-ID. End-to-end-spor må kunne rekonstrueres.
## Åpne avklaringer
| Spørsmål | Status |
|---|---|
| Eksisterer en sentral loggplattform i dag, eller skal en velges? | |
| Hva er retensjonstid for agent-logger? Forskjellig per datatype? | |
| Hvem har innsynsrett i logger? | |
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,40 @@
---
title: "Avviksliste — Standard Online"
date: "YYYY-MM-DD"
tags: ["avvik", "funn", "standardisering"]
refs:
- "../4.informasjonsarkitektur/datakvalitet-og-avvik.md"
- "prioriteringsliste.md"
qa:
status: "draft"
version: 1
---
# Avviksliste
Konkrete avvik observert under kartleggingen. Råmateriale for prioriteringslisten.
## Avvik
| ID | Avvik | Domene | System | Type | Konsekvens | Foreslått tiltak | Status |
|---|---|---|---|---|---|---|---|
*Type: Manglende SoR / Datakvalitet / Integrasjon / Governance / Personvern / Tilgangskontroll / Annet*
## Per type
### Manglende System-of-Record
### Datakvalitet
### Integrasjon
### Governance
### Personvern
### Tilgangskontroll
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,51 @@
---
title: "Måleparametere — Standard Online"
date: "YYYY-MM-DD"
tags: ["kpi", "måleparametere", "oppfølging"]
qa:
status: "draft"
version: 1
---
# Måleparametere
KPIer for å følge opp handlingsplanen og måle fremgang.
## Forslag til KPIer
### Masterdata-modenhet
| KPI | Definisjon | Frekvens | Mål |
|---|---|---|---|
| Andel masterdata-entiteter med tildelt SoR | % entiteter i [[../4.informasjonsarkitektur/masterdata-og-eierskap]] med master | Kvartalsvis | 100% innen 12 mnd |
| Andel masterdata-entiteter med Dataforvalter | % entiteter med navngitt forvalter | Kvartalsvis | 100% innen 12 mnd |
| Begrepskatalog-dekning | Antall begreper i [[../4.informasjonsarkitektur/begrepskatalog]] | Månedlig | Vekst |
### Datakvalitet
| KPI | Definisjon | Frekvens | Mål |
|---|---|---|---|
| Fullstendighet per masterdata-entitet | % obligatoriske felter fylt ut | Månedlig | >95% |
| Duplikater per masterdata-entitet | Antall identifiserte duplikater | Månedlig | Synkende |
### AI-modenhet
| KPI | Definisjon | Frekvens | Mål |
|---|---|---|---|
| Antall AI-agenter med tildelt eier | | Per agent | 100% |
| Andel agent-handlinger med fullstendig logg | | Månedlig | 100% |
### Personvern
| KPI | Definisjon | Frekvens | Mål |
|---|---|---|---|
| Behandlingsoversikt oppdatert | Antall behandlinger registrert vs. faktiske | Halvårlig | 100% dekning |
| DPIA-prosenten | Andel høyrisiko-behandlinger med DPIA | Per ny behandling | 100% |
## Rapporteringsstruktur
*Hvem rapporterer hva til hvem? Månedlig dashboard? Kvartalsvis statusmøte med ledergruppen?*
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,60 @@
---
title: "Prioriteringsliste — handlingsplan for Standard Online"
date: "YYYY-MM-DD"
tags: ["handlingsplan", "prioritering", "tiltak"]
refs:
- "avviksliste.md"
- "tiltak-per-omrade.md"
- "../../artefakter/risikoregister.md"
qa:
status: "draft"
version: 1
---
# Prioriteringsliste — handlingsplan
Konkrete, prioriterte tiltak basert på funn fra kartleggingen. Faseinndelt 0-3 / 3-12 / 12+ måneder.
## Prioriteringskriterier
- **Risiko** — hvor stor er risikoen ved å ikke gjøre dette? (lenke til [[../../artefakter/risikoregister]])
- **Gevinst** — hva oppnår vi?
- **Avhengighet** — hva må være på plass først?
- **Innsats** — estimert ressursbehov
## Fase 1 — Kortsiktige tiltak (0-3 måneder)
| ID | Tiltak | Domene | Prioritet | Avhengighet | Ansvar | Forventet uttak | Estimert kostnad |
|---|---|---|---|---|---|---|---|
## Fase 2 — Mellomlangsiktige tiltak (3-12 måneder)
| ID | Tiltak | Domene | Prioritet | Avhengighet | Ansvar | Forventet uttak | Estimert kostnad |
|---|---|---|---|---|---|---|---|
## Fase 3 — Langsiktige tiltak (12+ måneder)
| ID | Tiltak | Domene | Prioritet | Avhengighet | Ansvar | Forventet uttak | Estimert kostnad |
|---|---|---|---|---|---|---|---|
## Avhengighetsgraf
*Visualisering — hvilke tiltak må komme før andre? Bygges når listen er stabil.*
```mermaid
graph LR
T1[Tildel SoR per masterdata-entitet] --> T2[Etabler dataforvaltere]
T2 --> T3[Datakvalitetsmåling per domene]
T3 --> T4[AI-piloter mot modne domener]
```
## Sekvenseringsprinsipper
1. **Grunnmur først** — SoR, dataeierskap, governance på plass før integrasjonsrydding og AI
2. **Lav-risiko tidlig** — bygg tillit gjennom synlige seier
3. **Avhengigheter respekteres** — ikke start steg N+1 før steg N har tilstrekkelig fremdrift
4. **GDPR-grunnlag på plass** — før vi behandler nye data eller deler på nye måter
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,48 @@
---
title: "Tiltak per område — Standard Online"
date: "YYYY-MM-DD"
tags: ["tiltak", "områder", "handlingsplan"]
refs:
- "prioriteringsliste.md"
qa:
status: "draft"
version: 1
---
# Tiltak per område
Samme tiltakssett som [[prioriteringsliste]], men gruppert per fagområde i stedet for tidsfase. Gjør det enklere for ulike eierskap å se hva som angår dem.
## Masterdata og governance
| Tiltak | Fase | Ansvar |
|---|---|---|
## Arkitektur og integrasjoner
| Tiltak | Fase | Ansvar |
|---|---|---|
## AI og automatisering
| Tiltak | Fase | Ansvar |
|---|---|---|
## Personvern og sikkerhet
| Tiltak | Fase | Ansvar |
|---|---|---|
## Datakvalitet
| Tiltak | Fase | Ansvar |
|---|---|---|
## Organisasjon og kompetanse
| Tiltak | Fase | Ansvar |
|---|---|---|
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,35 @@
---
title: "Åpne spørsmål — Standard Online"
date: "YYYY-MM-DD"
tags: ["spørsmål", "uavklart", "oppfølging"]
qa:
status: "draft"
version: 1
---
# Åpne spørsmål
Ubesvarte spørsmål som må adresseres for å lukke kunnskapshull eller bekrefte antakelser.
## Aktive spørsmål
| ID | Spørsmål | Eier | Mottaker | Status | Frist | Svar |
|---|---|---|---|---|---|---|
*Status: Åpen / Avventer / Besvart / Lukket*
## Lukkede spørsmål (arkiv)
| ID | Spørsmål | Svar | Lukket dato |
|---|---|---|---|
## Antakelser som krever bekreftelse
Lenke til ANTAKELSE-markeringer i andre dokumenter. Bygges ut løpende.
| Antakelse | Kilde | Confidence | Hvordan bekrefte |
|---|---|---|---|
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,41 @@
---
title: "Dokumenter og lenker — Standard Online"
date: "YYYY-MM-DD"
tags: ["referanser", "dokumenter", "lenker"]
qa:
status: "draft"
version: 1
---
# Dokumenter og lenker
Eksterne ressurser som er relevante for oppdraget.
## Kundens dokumenter
| Dokument | Type | Plassering | Eier | Brukt i |
|---|---|---|---|---|
## Standarder og rammeverk
| Ressurs | Lenke | Relevans |
|---|---|---|
| GDPR (EU 2016/679) | https://eur-lex.europa.eu/eli/reg/2016/679/oj | Personvern |
| DIGDIR — Orden i eget hus | https://www.digdir.no/informasjonsforvaltning/hva-er-orden-i-eget-hus/2792 | Informasjonsforvaltning |
| ISO 27001 | | Informasjonssikkerhet (hvis relevant) |
| Fortes Startklar-rammeverk | `Salg/Startklar.pdf` | Metodikk |
## Referansecase fra Forte
| Case | Plassering | Hva som er overførbart |
|---|---|---|
| Oras Group | `Salg/Oras/` | Risikoregister, Executive Summary, integrasjonslandskap |
| Den norske kirke (Nstat) | `Jobb/Kirken/` | 9-mappe-struktur, masterdata-vokabular, Privacy by Design |
## Faglige referanser
*Bøker, artikler, kursmateriell relevant for oppdraget.*
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,34 @@
---
title: "Funn og hypoteser — Standard Online"
date: "YYYY-MM-DD"
tags: ["funn", "hypoteser", "innsikt"]
qa:
status: "draft"
version: 1
---
# Funn og hypoteser
Råmaterialet — observasjoner fra intervjuer, workshops og dokumentanalyse. Disse blir grunnlag for anbefalinger i mappe 4-7.
## Bekreftede funn
| ID | Funn | Kilde(r) | Konsekvens for oppdraget |
|---|---|---|---|
## Hypoteser (krever bekreftelse)
| ID | Hypotese | Hvorfor vi tror dette | Hvordan vi kan bekrefte | Confidence |
|---|---|---|---|---|
## Mønstre
*Tematiske observasjoner som dukker opp på tvers av intervjuer.*
## Avvik fra forventning
*Ting vi trodde, men som viste seg å være annerledes — viktig for å justere kurs.*
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,135 @@
---
title: "Intervjuguider — Standard Online"
date: "YYYY-MM-DD"
tags: ["intervju", "guide", "metode"]
qa:
status: "draft"
version: 1
---
# Intervjuguider
Maler for strukturerte intervjuer i Fase B. Tilpasses per person og rolle.
## Generell ramme (alle intervjuer)
**Varighet:** 60-90 minutter
**Form:** Halvstrukturert — guide som sikrer dekning, men åpent for utdyping
**Åpning (5 min):**
- Presentasjon av Forte og oppdraget
- Avklare hva intervjuet brukes til (kartlegging, ikke evaluering)
- Notattaking og konfidensialitet
**Avslutning (5 min):**
- Oppsummering av nøkkelpunkter
- Hva blir neste skritt?
- Hvem andre bør vi snakke med?
---
## Rollebaserte guider
### Forretningseier / domenekjenner
**Mål:** Forstå forretningsmessig kontekst, behov, smertepunkter.
**Spørsmål:**
1. **Rollen din** — hva er ditt ansvar i organisasjonen?
2. **Domenet ditt** — hvilke data er kritisk for deg/dine prosesser?
3. **Smertepunkter i dag** — hva fungerer dårlig? Hva slik du må omgå?
4. **Datakvalitet** — hvor mye stoler du på dataene du jobber med? Hvor er problemene?
5. **Eierskap** — vet du hvem som "eier" datene du bruker? Hvem skulle du klagd til ved feil?
6. **Integrasjoner** — hvilke systemer henter dere data fra/til? Fungerer det?
7. **Endringer** — hva har endret seg det siste året? Hva er på vei?
8. **Ønsker** — hva ville gjort jobben din enklere?
9. **AI-tanker** — hvilke områder ser du for deg at AI kan hjelpe? Hvor er du skeptisk?
### IT-ansvarlig / systemeier
**Mål:** Forstå teknisk arkitektur, integrasjoner, tekniske gjeld.
**Spørsmål:**
1. **Systemoversikt** — hvilke systemer eier du/dere?
2. **Teknologistack** — hva kjører hvor? Versjoner? Sky/on-prem?
3. **Integrasjoner** — kart over inn- og utgående integrasjoner. Frekvens, mekanisme.
4. **Brukerantall** — aktive brukere per system, vekst, sesong.
5. **Datavolum** — hvor mye data, hvor mye vokser det?
6. **Datakvalitet** — hva er kjente problemer? Hva er gjort med dem?
7. **Tilgang** — hvem har tilgang til hva? Hvordan styres det?
8. **Logging** — hva logges? Hvor lagres? Hvor lenge?
9. **Endringer** — hva er på vei (oppgradering, ERP-skifte, migrasjon)?
10. **Teknisk gjeld** — hva ville du fjernet hvis du fikk velge?
### Potensiell dataeier (Domain Data Owner)
**Mål:** Vurdere kandidat for dataeierskap; forstå hva personen tenker om rollen.
**Spørsmål:**
1. **Domenet ditt** — hvilket fagområde er du ekspert på?
2. **Datakjennskap** — hvor godt kjenner du dataene i ditt domene? Hvilke felter, kodeverk, regler?
3. **Beslutninger i dag** — hvem tar beslutninger om struktur/innhold i dette domenet?
4. **Ansvar** — hva vil det innebære for deg å være "dataeier" for dette domenet? Tid, mandat, ressurser?
5. **Konflikter** — hvor er det vanlig uenighet om begreper eller verdier?
6. **Konsumenter** — vet du hvem som bruker data fra ditt domene? Hva trenger de?
7. **Forutsetninger** — hva må være på plass for at du skal kunne ta dette ansvaret?
8. **Bekymringer** — hva ville du være mest bekymret for å miste kontroll over?
### Sluttbruker
**Mål:** Forstå hvordan systemer brukes i praksis, hva som ikke fungerer.
**Spørsmål:**
1. **Daglig arbeid** — hva gjør du i de relevante systemene en typisk dag?
2. **Verktøy** — hvilke systemer bruker du? Hvor mye tid per dag?
3. **Frustrasjoner** — hva tar lengre tid enn det burde?
4. **Omgåelser** — hvor må du dobbeltsjekke eller registrere på flere steder?
5. **Excel/skygge** — bruker du Excel eller andre verktøy "ved siden av"? Hvorfor?
6. **Endringer** — hva har endret seg det siste året? Til det bedre/verre?
7. **Drømmescenario** — hvis du fikk velge, hva ville du endret?
---
## Tematiske guider
### Datakvalitet-workshop (gruppe)
**Mål:** Få kollektivt bilde av datakvalitet per domene.
**Format:** 90 min workshop med 5-8 personer.
**Agenda:**
1. Felles introduksjon (10 min)
2. Per domene: hvilke felter er kritiske? Hvilke er problematiske? (40 min, roterende)
3. Dyptlodding på 2-3 verste områder (30 min)
4. Oppsummering og neste skritt (10 min)
### Integrasjons-workshop
**Mål:** Bygge eller verifisere integrasjonslandskap-kart.
**Format:** 90 min med IT-ansvarlige og systemeiere.
**Agenda:**
1. Gjennomgang av nåværende kart (15 min)
2. Per integrasjon: bekreft retning, mekanisme, data, frekvens (45 min)
3. Identifiser gaps og duplikater (20 min)
4. Avtal neste skritt (10 min)
---
## Oppfølgingsspørsmål (kan brukes på tvers)
- "Kan du gi et konkret eksempel?"
- "Når skjedde dette sist?"
- "Hvem andre bør jeg snakke med om dette?"
- "Finnes det dokumentasjon på dette?"
- "Hva tror du blir konsekvensen hvis dette ikke blir adressert?"
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,97 @@
---
title: "Executive Summary — Standard Online"
date: "YYYY-MM-DD"
tags: ["executive-summary", "ledelse", "sluttleveranse"]
qa:
status: "draft"
version: 1
---
# Executive Summary
> *Standalone management-dokument. Skal kunne leses uten å åpne andre dokumenter.*
**Forfattere:** <Forte-team>
**Klassifisering:** Begrenset
---
## 1. Formål og scope
Kort om hvorfor oppdraget ble gjennomført og hva som var innenfor scope.
**Innenfor scope:**
-
**Utenfor scope:**
-
**Datatilgang:** *Asymmetrisk visibilitet skal nevnes eksplisitt — hvor var analysen sterk, hvor var den mer overflatisk.*
---
## 2. Nåsituasjon — hovedtrekk
3-5 setninger om dagens situasjon, basert på funn fra mappe 3-5.
**Systemlandskap:** <kort>
**Datamodenhet:** <kort — typisk Nivå 0-2 av 4>
**Hovedutfordringer:**
1.
2.
3.
---
## 3. Hovedfunn
5-10 punkter — det viktigste lederen trenger å vite.
1.
2.
3.
---
## 4. Risikoer
Toppen av risikoregisteret. Fullt register: [[../../artefakter/risikoregister]].
| # | Risiko | Score | Mitigasjon |
|---|---|---|---|
---
## 5. Anbefalinger
Hovedanbefalinger, gruppert. Detaljer i [[../7.standardisering-og-handlingsplan/prioriteringsliste]].
### Kortsiktig (0-3 mnd)
1.
2.
### Mellomlangsiktig (3-12 mnd)
1.
2.
### Langsiktig (12+ mnd)
1.
2.
---
## 6. Åpne spørsmål og forutsetninger
Beslutninger som må tas av kunden før neste fase, og forutsetninger som handlingsplanen bygger på.
**Beslutninger som trengs:**
-
**Forutsetninger:**
-
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,96 @@
---
title: "Faseoppsummeringer — Standard Online"
date: "YYYY-MM-DD"
tags: ["faseoppsummering", "milepæler"]
qa:
status: "draft"
version: 1
---
# Faseoppsummeringer
Korte statusoppsummeringer per fase. Skrives ved hver fase-overgang. Brukes som grunnlag for styringsmøter.
## Fase A — Oppstart og avgrensning
**Tidsrom:** YYYY-MM-DD YYYY-MM-DD
**Hovedaktiviteter gjennomført:**
-
**Funn / observasjoner:**
-
**Beslutninger:**
-
**Risikoer som har dukket opp:**
-
**Justeringer av plan:**
-
**Neste fase:**
---
## Fase B — Kartlegging og analyse
**Tidsrom:** YYYY-MM-DD YYYY-MM-DD
**Hovedaktiviteter gjennomført:**
-
**Funn / observasjoner:**
-
**Delleveranse 1 — status:**
**Beslutninger:**
-
**Justeringer av plan:**
-
**Neste fase:**
---
## Fase C — Anbefalinger og målbilde
**Tidsrom:** YYYY-MM-DD YYYY-MM-DD
**Hovedaktiviteter gjennomført:**
-
**Funn / observasjoner:**
-
**Delleveranse 2 — status:**
**Beslutninger:**
-
**Justeringer av plan:**
-
**Neste fase:**
---
## Fase D — Forankring og overlevering
**Tidsrom:** YYYY-MM-DD YYYY-MM-DD
**Hovedaktiviteter gjennomført:**
-
**Sluttleveranse — status:**
**Forankring:**
**Anbefalinger for neste fase (post-overlevering):**
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,37 @@
---
title: "Leveranseplan — Standard Online"
date: "YYYY-MM-DD"
tags: ["leveranseplan", "milepæler"]
refs:
- "../1.oppdrag-og-kontekst/mal-og-leveranser.md"
qa:
status: "draft"
version: 1
---
# Leveranseplan
Overordnet leveranseplan, koblet til [[../1.oppdrag-og-kontekst/mal-og-leveranser]] og [[../../02-gjennomforing]].
## Faser og milepæler
| Fase | Uker | Delleveranse | Status |
|---|---|---|---|
| A — Oppstart og avgrensning | 1 | Bekreftet scope og plan | |
| B — Kartlegging og analyse | 2-3 | **Delleveranse 1**: Nåsituasjon + risiko (uke 3) | |
| C — Anbefalinger og målbilde | 3-5 | **Delleveranse 2**: Målbilde + masterdata (uke 5) | |
| D — Forankring og overlevering | 6-7 | **Sluttleveranse**: Handlingsplan + governance | |
## Statusoppfølging
| Dato | Fase | Fremdrift | Risiko/blokkere | Neste skritt |
|---|---|---|---|---|
## Endringer i scope
| Dato | Endring | Begrunnelse | Konsekvens for plan |
|---|---|---|---|
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,222 @@
---
title: "Sluttrapport — Standard Online"
date: "YYYY-MM-DD"
tags: ["sluttrapport", "leveranse"]
refs:
- "executive-summary.md"
qa:
status: "draft"
version: 1
---
# Sluttrapport — <Oppdragsnavn>
**Kunde:** Standard Online
**Periode:** YYYY-MM-DD YYYY-MM-DD
**Forfattere:** <Forte-team>
---
## Innholdsfortegnelse
1. [Bakgrunn](#1-bakgrunn)
2. [Analyse](#2-analyse)
3. [Fremtidig mulighetsrom](#3-fremtidig-mulighetsrom)
4. [Veikart](#4-veikart)
5. [Vedlegg](#5-vedlegg)
---
## 1. Bakgrunn
### 1.1 Problembeskrivelse
*Hvorfor ble oppdraget gjennomført? Hvilke utfordringer hadde kunden?*
### 1.2 Mål med oppdraget
*Hva skulle oppdraget oppnå? Lenke til [[../1.oppdrag-og-kontekst/mal-og-leveranser]].*
### 1.3 Omfang og avgrensninger
**Innenfor scope:**
**Utenfor scope:**
### 1.4 Organisering
| Navn | Rolle | Organisasjon |
|---|---|---|
**Styringsgruppe / oppdragsgiver:**
### 1.5 Tilnærming og metode
Oppdraget ble gjennomført med Fortes **Startklar-metodikk** for data readiness (`Salg/Startklar.pdf`), tilpasset Nivå 1 (avgrenset strategisk). Gjennomføringsmodellen følger 4 faser — se [[../../02-gjennomforing]] og [[leveranseplan]].
**Gjennomførte aktiviteter:**
- [x] Kickoff og scope-bekreftelse
- [x] N intervjuer med nøkkelpersoner
- [x] N workshops
- [x] Datakilde-inventar
- [x] Datakvalitet-analyse på domene-nivå
- [x] Integrasjonslandskap-kartlegging
- [x] Masterdata-modellering
- [x] GDPR-vurdering
- [x] AI-rammeverk
- [x] Handlingsplan
---
## 2. Analyse
### 2.1 Nåsituasjon
Sammenstilling av [[../3.system-og-datalandskap/hovedsystemer]] og [[../3.system-og-datalandskap/integrasjoner-og-flyt]].
#### 2.1.1 Systemlandskap
#### 2.1.2 Dataflyt og integrasjoner
#### 2.1.3 Pågående initiativer
### 2.2 Interessenter og behov
| Interessent | Hovedbehov | Prioritet |
|---|---|---|
### 2.3 Datakvalitet og governance
Sammenstilling av [[../4.informasjonsarkitektur/datakvalitet-og-avvik]] og [[../4.informasjonsarkitektur/masterdata-og-eierskap]].
### 2.4 Personvern og sikkerhet
Sammenstilling av [[../5.personvern-og-sikkerhet/gdpr-oversikt]] og [[../5.personvern-og-sikkerhet/tiltak-for-innebygd-personvern]].
### 2.5 Innsiktsoppsummering
**Hovedfunn:**
1.
2.
3.
---
## 3. Fremtidig mulighetsrom
### 3.1 Visjon og målbilde
*Hvor skal kunden? Hvilken tilstand vil vi gjøre mulig med dette grunnlaget?*
### 3.2 Anbefalt målarkitektur
*Skisse, integrasjonsmønster, anbefalte komponenter. Detaljer i [[../3.system-og-datalandskap/systemkart-as-is]] (sammenligning) og dedikerte arkitektur-skisser.*
### 3.3 Masterdata-modell
Sammenstilling av [[../4.informasjonsarkitektur/masterdata-og-eierskap]].
| Entitet | Master (SoR) | Begrepseier | Dataforvalter |
|---|---|---|---|
### 3.4 AI-rammeverk
Sammenstilling av [[../6.ai-rammeverk/ai-prinsipper]]. Fem prinsipper: identifiserbarhet, minste privilegium, sporbarhet, HITL, datakvalitet som premiss.
### 3.5 Governance-modell
Sammenstilling av [[../4.informasjonsarkitektur/data-governance-prinsipper]].
### 3.6 Anbefalte tiltak
Sammenstilling av [[../7.standardisering-og-handlingsplan/prioriteringsliste]].
### 3.7 Kost/nytte-vurdering
| Tiltak | Estimert kostnad | Forventet nytte | Anbefaling |
|---|---|---|---|
### 3.8 Risikovurdering
Lenke til [[../../artefakter/risikoregister]] for fullt register.
---
## 4. Veikart
### 4.1 Overordnet plan
*Faser, milepæler, sekvenseringsprinsipper.*
```
Fase 1: Grunnmur Fase 2: Konsolidering Fase 3: AI-aktivering
[0-3 mnd] [3-12 mnd] [12+ mnd]
├── SoR per ├── Integrasjonsrydding ├── AI-piloter
├── Dataforvaltere ├── MDM-løsning ├── Skalering
└── Governance └── Personvern └── Optimalisering
```
### 4.2 Kortsiktige tiltak (0-3 måneder)
### 4.3 Mellomlangsiktige tiltak (3-12 måneder)
### 4.4 Langsiktige tiltak (12+ måneder)
### 4.5 Forutsetninger og avhengigheter
**Forutsetninger:**
-
**Avhengigheter:**
-
### 4.6 Ressursbehov
| Rolle | Kapasitet | Periode |
|---|---|---|
### 4.7 Anbefaling om videre arbeid
*Konkret anbefaling — hva er neste fase? Hva må kunden beslutte først?*
---
## 5. Vedlegg
### Vedlegg A: Datakilde-inventar
Lenke til [[../3.system-og-datalandskap/hovedsystemer]].
### Vedlegg B: Intervjuoversikt
| Dato | Deltakere | Tema |
|---|---|---|
### Vedlegg C: Risikoregister
Lenke til [[../../artefakter/risikoregister]].
### Vedlegg D: Integrasjonslandskap
Lenke til [[../../artefakter/integrasjonslandskap]] og [[../3.system-og-datalandskap/integrasjoner-og-flyt]].
### Vedlegg E: Begrepskatalog
Lenke til [[../4.informasjonsarkitektur/begrepskatalog]].
### Vedlegg F: Ordliste
| Begrep | Definisjon |
|---|---|
---
## Dokumenthistorikk
| Versjon | Dato | Endring | Forfatter |
|---|---|---|---|
---
*Klassifisering: Begrenset*

78
README.md Normal file
View File

@@ -0,0 +1,78 @@
# Standard Online — oppdragsmappe
Arbeidsmappe for Standard Online-oppdraget: kartlegging og anbefalingsarbeid for masterdata, arkitektur og AI-rammeverk på tvers av SuperOffice, Business Central og nopCommerce.
## Status
**Per 2026-05-21:** Forslag under utarbeidelse, ikke startet ennå. Strukturen er pre-allokert basert på det vi vet fra oppdragsbeskrivelsen og vårt forslag. Datoer fylles ut når oppdraget starter.
## Hvor ting henger sammen
| Hva | Plassering | Status |
|---|---|---|
| Forslag og salgsmateriale | `Salg/Standard/` | Ferdig — pitch og oppdragsbeskrivelse |
| Kanonisk malverk | `Salg/_mal/startklar-malverk/` | Ferdig — generisk for alle masterdata-oppdrag |
| Denne mappen | `Oppdrag/Standard/` | Tilpasset kopi for Standard-oppdraget |
| Møtenotat-mal | `Oppdrag/_mal/motereferat.md` | Felles for alle Forte-oppdrag |
## Struktur
9-mappe-modell fra Startklar-malverket. Se [_index.md](_index.md) for full innholdsfortegnelse, eller [Salg/_mal/startklar-malverk/README.md](../../Salg/_mal/startklar-malverk/README.md) for forklaring av modellen.
```
Oppdrag/Standard/
├── 1.oppdrag-og-kontekst/ # Scope, leveranser, interessenter, møtelogg
├── 2.organisasjonsforstaelse/ # Roller, beslutningsveier, nøkkelpersoner
├── 3.system-og-datalandskap/ # Systemer, integrasjoner, as-is
├── 4.informasjonsarkitektur/ # Masterdata, begrepskatalog, governance ⭐
├── 5.personvern-og-sikkerhet/ # GDPR, Privacy by Design
├── 6.ai-rammeverk/ # Operasjonelle AI-prinsipper
├── 7.standardisering-og-handlingsplan/ # Avvik, prioritering, tiltak
├── 8.kontinuerlig-laering-og-referanser/ # Intervjuguider, funn, åpne spørsmål
└── 9.leveranser-og-oppsummeringer/ # Executive Summary, sluttrapport
```
⭐ = kjernen for masterdata-leveransen
## Standard-spesifikke aspekter
Det som gjør dette oppdraget særpreget vs. en generisk malverkskopi:
- **Tre systemer i scope:** SuperOffice (CRM), Business Central (ERP), nopCommerce (nettbutikk)
- **AI-rammeverk er en eksplisitt leveranse** (mappe 6) — ikke alle masterdata-oppdrag har dette
- **Standard Digital (Riga)** er sentral samarbeidspart — egen kontakt og workshops
- **Beslutningskontakt:** Direktør produkt og kundeopplevelse hos Standard Online
- **Forte-team:** Ragnhild Aaraas Hånde (ledende, 80%) + Petter Schultz (senior rådgiver, 20%)
Detaljer i `1.oppdrag-og-kontekst/oppdragsbeskrivelse.md` når den fylles ut ved oppstart.
## Når oppdraget starter
1. Petter fyller ut `Salg/_mal/startklar-malverk/01-startklar-sjekkliste.md` internt (kopier inn i `1.oppdrag-og-kontekst/` om ønskelig)
2. Oppdater `1.oppdrag-og-kontekst/oppdragsbeskrivelse.md` med faktiske datoer, team, scope
3. Følg fasestrukturen i `Salg/_mal/startklar-malverk/02-gjennomforing.md`
## Verktøykasse
Maler og artefakter som ikke kopieres inn lokalt (forblir kanoniske i `Salg/_mal/`):
- [Risikoregister](../../Salg/_mal/startklar-malverk/artefakter/risikoregister.md) — Impact × Likelihood
- [Integrasjonslandskap](../../Salg/_mal/startklar-malverk/artefakter/integrasjonslandskap.md)
- [Workshop-agenda](../../Salg/_mal/startklar-malverk/artefakter/workshop-agenda.md)
- [Domenemodell-skjema](../../Salg/_mal/startklar-malverk/artefakter/domenemodell-skjema.md)
Når du trenger en av disse for Standard, kopier dem inn i passende undermappe (typisk `8.kontinuerlig-laering-og-referanser/` for sjekklister, eller direkte i den leveransen den hører til).
## Konvensjoner
Følger Forte/Startklar-konvensjonene definert i `Salg/_mal/startklar-malverk/00-konvensjoner.md`:
- Frontmatter med `qa.status`
- DEC/ACT/RISK-YYYY-XXX-IDer for beslutninger/handlinger/risikoer
- ANTAKELSE-markering med confidence-nivå
- ISO-datoformat
- Norsk Bokmål
---
*Klassifisering: Begrenset*

92
_index.md Normal file
View File

@@ -0,0 +1,92 @@
# Innholdsfortegnelse — Standard Online
Oppdragsmappe for Standard Online-oppdraget. Startet <YYYY-MM-DD>. Sist oppdatert <YYYY-MM-DD>.
---
## 1. Oppdrag og kontekst
| Fil | Beskrivelse |
|---|---|
| [Oppdragsbeskrivelse](1.oppdrag-og-kontekst/oppdragsbeskrivelse.md) | Hovedoppdrag: scope, mål, leveranser |
| [Mål og leveranser](1.oppdrag-og-kontekst/mal-og-leveranser.md) | Leveranseoversikt med tidsplan |
| [Rammer og avklaringer](1.oppdrag-og-kontekst/rammer-og-avklaringer.md) | Forutsetninger og avgrensninger |
| [Interessenter](1.oppdrag-og-kontekst/interessenter-og-kontaktinfo.md) | Nøkkelpersoner og kontaktinfo |
| [Møtelogg](1.oppdrag-og-kontekst/motelogg-og-beslutninger.md) | Møter, beslutninger og referater |
## 2. Organisasjonsforståelse
| Fil | Beskrivelse |
|---|---|
| [Overordnet struktur](2.organisasjonsforstaelse/overordnet-struktur.md) | Organisasjonshierarki og enheter |
| [Roller og beslutningsveier](2.organisasjonsforstaelse/roller-og-beslutningsveier.md) | Beslutningsmyndighet og roller |
| [Nøkkelpersoner](2.organisasjonsforstaelse/nokkelpersoner-for-informasjon.md) | Hvem som vet hva |
## 3. System- og datalandskap
| Fil | Beskrivelse |
|---|---|
| [Hovedsystemer](3.system-og-datalandskap/hovedsystemer.md) | Komplett systemoversikt |
| [Integrasjoner og flyt](3.system-og-datalandskap/integrasjoner-og-flyt.md) | Dataflyt mellom systemer |
| [Systemkart as-is](3.system-og-datalandskap/systemkart-as-is.md) | Visuelt systemkart |
| [Teknologier og leverandører](3.system-og-datalandskap/teknologier-og-leverandorer.md) | Teknologivalg og leverandørforhold |
| [Pågående initiativer](3.system-og-datalandskap/pagaende-initiativer.md) | Aktive prosjekter |
## 4. Informasjonsarkitektur
| Fil | Beskrivelse |
|---|---|
| [Begrepskatalog](4.informasjonsarkitektur/begrepskatalog.md) | Felles begrepsdefinisjoner |
| [Informasjonsdomener](4.informasjonsarkitektur/informasjonsdomener.md) | Domeneinndeling med master-tildeling |
| [Masterdata og eierskap](4.informasjonsarkitektur/masterdata-og-eierskap.md) | Begrepseier / Dataforvalter / Master |
| [Data Governance prinsipper](4.informasjonsarkitektur/data-governance-prinsipper.md) | Prinsipper + 3-nivå-modell |
| [Datakilder per domene](4.informasjonsarkitektur/datakilder-per-domene.md) | Datakilder mappet til domener |
| [Datakvalitet og avvik](4.informasjonsarkitektur/datakvalitet-og-avvik.md) | Datakvalitetsvurderinger |
| [Standardiseringsbehov](4.informasjonsarkitektur/standardiseringsbehov.md) | Identifiserte standardiseringsbehov |
## 5. Personvern og sikkerhet
| Fil | Beskrivelse |
|---|---|
| [GDPR-oversikt](5.personvern-og-sikkerhet/gdpr-oversikt.md) | GDPR-krav og etterlevelse |
| [Sensitive dataområder](5.personvern-og-sikkerhet/sensitive-dataomrader.md) | Kartlegging av sensitiv data |
| [Dataflyt og risiko](5.personvern-og-sikkerhet/dataflyt-og-risiko.md) | Personvernrisiko i dataflyt |
| [Roller og ansvar](5.personvern-og-sikkerhet/roller-og-ansvar.md) | Personvernansvar |
| [Tiltak for innebygd personvern](5.personvern-og-sikkerhet/tiltak-for-innebygd-personvern.md) | Privacy by Design + Default |
## 6. AI-rammeverk
| Fil | Beskrivelse |
|---|---|
| [AI-prinsipper](6.ai-rammeverk/ai-prinsipper.md) | Operasjonelle prinsipper |
| [Identifiserbarhet og tilgang](6.ai-rammeverk/identifiserbarhet-og-tilgang.md) | Hver agent har egen identitet |
| [Logging og sporbarhet](6.ai-rammeverk/logging-og-sporbarhet.md) | Handlinger logges og spores |
| [Human-in-the-loop](6.ai-rammeverk/human-in-the-loop.md) | Når kreves menneskelig godkjenning |
| [Datakvalitet som AI-premiss](6.ai-rammeverk/datakvalitet-som-ai-premiss.md) | Kobling til masterdata-modell |
## 7. Standardisering og handlingsplan
| Fil | Beskrivelse |
|---|---|
| [Avviksliste](7.standardisering-og-handlingsplan/avviksliste.md) | Registrerte avvik |
| [Prioriteringsliste](7.standardisering-og-handlingsplan/prioriteringsliste.md) | Prioriterte tiltak |
| [Tiltak per område](7.standardisering-og-handlingsplan/tiltak-per-omrade.md) | Tiltak gruppert per fagområde |
| [Måleparametere](7.standardisering-og-handlingsplan/maleparametere.md) | KPIer for oppfølging |
## 8. Kontinuerlig læring og referanser
| Fil | Beskrivelse |
|---|---|
| [Intervjuguider](8.kontinuerlig-laering-og-referanser/intervjuguider.md) | Rollebaserte intervjumaler |
| [Åpne spørsmål](8.kontinuerlig-laering-og-referanser/apne-sporsmal.md) | Ubesvarte spørsmål |
| [Funn og hypoteser](8.kontinuerlig-laering-og-referanser/funn-og-hypoteser.md) | Observasjoner og antakelser |
| [Dokumenter og lenker](8.kontinuerlig-laering-og-referanser/dokumenter-og-lenker.md) | Eksterne ressurser |
## 9. Leveranser og oppsummeringer
| Fil | Beskrivelse |
|---|---|
| [Leveranseplan](9.leveranser-og-oppsummeringer/leveranseplan.md) | Overordnet leveranseplan |
| [Executive Summary](9.leveranser-og-oppsummeringer/executive-summary.md) | Standalone management-dokument |
| [Sluttrapport](9.leveranser-og-oppsummeringer/sluttrapport.md) | Komplett sluttrapport (5-delt) |
| [Faseoppsummeringer](9.leveranser-og-oppsummeringer/faseoppsummeringer.md) | Oppsummeringer per fase |