Gjør all dokumentasjon tilgjengelig i repo og fiks alle lenker

Tidligere refererte repoet til dokumentasjon som lå utenfor (i Salg/_mal/),
og brukte Obsidian-wikilinks [[...]] som ikke er klikkbare i Gitea. Begge
deler gjorde at lenker var døde i Gitea-web.

Endringer:
- Hentet inn arbeidsdokumentene som faktisk brukes under oppdraget:
  _metode/ (00-konvensjoner, 01-startklar-sjekkliste, 02-gjennomforing)
  artefakter/ (risikoregister, integrasjonslandskap, workshop-agenda,
  domenemodell-skjema)
- Konverterte 82 Obsidian-wikilinks til standard markdown-lenker med
  korrekte relative stier — klikkbare både i Gitea og lokalt
- Begrepsord i begrepskatalogen ([[Bedrift]] etc.) ble til ren tekst
  (de var aldri filer)
- Oppdaterte konvensjonsdokumentet til å foreskrive standard markdown,
  ikke wikilinks (med begrunnelse: Gitea rendrer ikke [[...]])
- Oras/Kirken/salgsmateriale er nå tydelig merket som eksterne
  arbeidsområde-referanser (andre kunder / salgsfase), ikke
  dinglende lenker som lot som de var i repoet

Verifisert: 133 ekte interne lenker resolver korrekt. De 4 gjenværende
treffene i validering er kodeeksempler i backticks (viser lenke-syntaks),
ikke faktiske lenker.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-05-27 10:34:14 +02:00
parent 46065836a6
commit 1d85656e96
34 changed files with 788 additions and 85 deletions

View File

@@ -0,0 +1,91 @@
---
title: "Domenemodell-skjema — mal"
date: "YYYY-MM-DD"
tags: ["domenemodell", "skjema", "masterdata", "artefakt"]
qa:
status: "draft"
version: 1
---
# Domenemodell-skjema
Strukturert mal for å dokumentere en domenemodell — én fil per domene. Brukes som vedlegg til [informasjonsdomener](../4.informasjonsarkitektur/informasjonsdomener.md).
## Header
**Domene:**
**Versjon:**
**Eier (Domain Data Owner):**
**Sist oppdatert:**
## Entiteter
| Entitet | Beskrivelse | Master (SoR) | Konsumenter | Begrepseier | Dataforvalter | Sensitivitet |
|---|---|---|---|---|---|---|
## ER-diagram
```mermaid
erDiagram
BEDRIFT ||--o{ KONTAKT : "har"
KONTAKT ||--o{ ORDRE : "lagt-inn"
BEDRIFT {
string OrgNr PK
string Navn
string Adresse
}
KONTAKT {
string KontaktId PK
string OrgNr FK
string Navn
string Epost
}
```
## Per entitet
### <Entitetnavn>
**Definisjon:** *Lenke til [begrepskatalog](../4.informasjonsarkitektur/begrepskatalog.md).*
**Primær identifikator:**
**Attributter (kritiske):**
| Attributt | Type | Obligatorisk | Begrepseier | Master | Validerings-regler |
|---|---|---|---|---|---|
**Relasjoner:**
| Relasjon | Til entitet | Kardinalitet | Beskrivelse |
|---|---|---|---|
**Livssyklus:**
*Opprettelse → endring → arkivering/sletting. Hvem gjør hva?*
**Tilgangskrav:**
*Hvem skal kunne lese / skrive / slette?*
**Personverntiltak:**
*Lenke til [sensitive-dataomrader](../5.personvern-og-sikkerhet/sensitive-dataomrader.md).*
---
*Repeter for hver entitet i domenet.*
## Avhengigheter til andre domener
| Domene | Type avhengighet | Konsekvens hvis brutt |
|---|---|---|
## Endringslogg
| Versjon | Dato | Endring | Forfatter |
|---|---|---|---|
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,66 @@
---
title: "Integrasjonslandskap — <KUNDE>"
date: "YYYY-MM-DD"
tags: ["integrasjon", "landskap", "artefakt"]
qa:
status: "draft"
version: 1
---
# Integrasjonslandskap
Strukturert oversikt over alle integrasjoner. Mønster fra Oras Group sin Data Health Assessment (seksjon 6).
## Per system / integrasjon
| System | Retning | Kilde / motpart | Mekanisme | Datatyper | Frekvens | Personopplysninger? | Migrasjons-/endringsimplikasjon |
|---|---|---|---|---|---|---|---|
**Retning:**
- **Inbound** — kommer inn til system
- **Outbound** — går ut fra system
- **Bidirectional** — toveis
**Mekanisme:**
- REST API
- GraphQL
- SOAP
- Event/message bus
- Filoverføring (SFTP/batch)
- Database-til-database
- Manuell (Excel-eksport, etc.)
- ETL/ELT-jobb
**Frekvens:** Real-time / Hver time / Daglig / Ukentlig / Månedlig / Ad hoc
## Kritisk-vurdering
For hver integrasjon, vurder:
| Spørsmål | Hvis ja: konsekvens |
|---|---|
| Brytes ved skifte av motpart? | Må redesignes |
| Inneholder personopplysninger? | GDPR-vurdering kreves |
| Cross-border? | DPA/SCC kreves |
| Real-time vs. batch? | Påvirker arkitekturvalg |
| Blokkerende ved feil? | Resiliens-tiltak nødvendig |
## Endringer som påvirker landskapet
*Pågående initiativer hos kunden som vil endre integrasjonsbildet. Lenke til [pagaende-initiativer](../3.system-og-datalandskap/pagaende-initiativer.md).*
## Punkt-til-punkt vs. hub-and-spoke
Antall integrasjoner i dag: **N**
Vurdering: Er antallet håndterbart, eller bør vi vurdere å konsolidere via integrasjonsplattform (hub-and-spoke)?
**Vurderingskriterier:**
- Antall punkt-til-punkt-integrasjoner (>15-20 begynner å bli vanskelig)
- Vedlikeholdskostnad
- Nye systemer som skal kobles på
- Behov for sentral logging og styring
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,70 @@
---
title: "Risikoregister — <KUNDE>"
date: "YYYY-MM-DD"
tags: ["risiko", "register", "artefakt"]
qa:
status: "draft"
version: 1
---
# Risikoregister
Sentralt register over alle identifiserte risikoer. Mønster fra Oras Group sin Data Health Assessment.
## Scoring
**Score = Impact × Likelihood**
| Impact | Beskrivelse |
|---|---|
| 5 | Kritisk — kan stoppe oppdraget eller forårsake store konsekvenser |
| 4 | Alvorlig — betydelig negativ påvirkning |
| 3 | Moderat — håndterbart, men krever oppmerksomhet |
| 2 | Lav — mindre påvirkning |
| 1 | Minimal |
| Likelihood | Beskrivelse |
|---|---|
| 5 | Sikker — vil inntreffe |
| 4 | Svært sannsynlig |
| 3 | Sannsynlig |
| 2 | Mulig |
| 1 | Usannsynlig |
**Risikonivå:**
- **20-25** — KRITISK (rød)
- **12-19** — HØY (oransje)
- **6-11** — MIDDELS (gul)
- **1-5** — LAV (grønn)
## Aktivt register
| # | Risiko | Impact | Likelihood | Score | Kategori | Kilde | Mitigasjon | Eier | Status |
|---|---|---|---|---|---|---|---|---|---|
| R1 | | | | | | | | | |
*Kategori: Teknisk / Organisatorisk / Personvern / Tidsplan / Avhengighet / Kommersielt*
*Status: Åpen / Mitigert / Akseptert / Lukket*
## Lukkede risikoer (arkiv)
| # | Risiko | Lukket dato | Begrunnelse |
|---|---|---|---|
## Risikomatrise (visualisering)
```
Likelihood
5 │ │ │ R3 (20) │ R1 (25) │
4 │ │ │ │ R2 (16) │
3 │ │ │ │ │
2 │ │ │ │ │
1 │ │ │ │ │
└────────────┴────────────┴────────────┴────────────┘
1 2 3 4 5
Impact
```
---
*Klassifisering: Begrenset*

View File

@@ -0,0 +1,65 @@
---
title: "Workshop-agenda — mal"
date: "YYYY-MM-DD"
tags: ["workshop", "agenda", "mal"]
qa:
status: "draft"
version: 1
---
# Workshop-agenda
Generell mal — tilpasses per workshop. Bruk gjerne sammen med rollebaserte intervjuguider i [intervjuguider](../8.kontinuerlig-laering-og-referanser/intervjuguider.md).
## Header
**Dato:** YYYY-MM-DD
**Tid:** HH:MM HH:MM
**Sted / kanal:**
**Workshop-tema:**
**Forberedelseunderlag:**
## Deltakere
| Navn | Rolle | Bekreftet |
|---|---|---|
## Mål
*Hva skal vi oppnå?*
1.
2.
3.
## Agenda
| Tid | Aktivitet | Eier | Format |
|---|---|---|---|
| 00:00 | Velkommen og innledning | | Plenum |
| 00:10 | Felles utgangspunkt — sammendrag og rammer | | Plenum |
| 00:20 | Tema 1 — kartlegging | | Diskusjon / gruppe |
| 01:00 | Pause | | |
| 01:10 | Tema 2 — prioritering | | Workshop-øvelse |
| 01:50 | Oppsummering og neste skritt | | Plenum |
## Forberedelse
**Fra Forte:**
- Forhåndsdelte underlag
- Whiteboard / Miro
- Notater fra forrige workshop
**Fra deltakere:**
- Eventuelle dokumenter til gjennomgang
- Konkret eksempler å bringe inn
## Etterarbeid
- [ ] Sende referat senest 48 timer etter workshop
- [ ] Logge beslutninger/handlinger/risikoer i [motelogg-og-beslutninger](../1.oppdrag-og-kontekst/motelogg-og-beslutninger.md)
- [ ] Oppdatere relevante leveransedokumenter
---
*Klassifisering: Begrenset*