From 1d85656e96f99653eb434e13c7a089a5176c128c Mon Sep 17 00:00:00 2001 From: Petter Schultz Date: Wed, 27 May 2026 10:34:14 +0200 Subject: [PATCH] =?UTF-8?q?Gj=C3=B8r=20all=20dokumentasjon=20tilgjengelig?= =?UTF-8?q?=20i=20repo=20og=20fiks=20alle=20lenker?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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) --- .../motelogg-og-beslutninger.md | 4 +- 1.oppdrag-og-kontekst/oppdragsbeskrivelse.md | 2 +- .../rammer-og-avklaringer.md | 2 +- .../integrasjoner-og-flyt.md | 4 +- 3.system-og-datalandskap/systemkart-as-is.md | 4 +- 4.informasjonsarkitektur/begrepskatalog.md | 12 +- .../data-governance-prinsipper.md | 2 +- .../datakvalitet-og-avvik.md | 4 +- .../informasjonsdomener.md | 4 +- .../masterdata-og-eierskap.md | 6 +- .../standardiseringsbehov.md | 2 +- .../dataflyt-og-risiko.md | 2 +- 5.personvern-og-sikkerhet/gdpr-oversikt.md | 4 +- .../tiltak-for-innebygd-personvern.md | 2 +- 6.ai-rammeverk/ai-prinsipper.md | 12 +- 6.ai-rammeverk/datakvalitet-som-ai-premiss.md | 12 +- .../maleparametere.md | 4 +- .../prioriteringsliste.md | 2 +- .../tiltak-per-omrade.md | 2 +- .../executive-summary.md | 4 +- .../leveranseplan.md | 2 +- .../sluttrapport.md | 30 ++-- CLAUDE.md | 16 +- README.md | 26 ++-- _memories/MEMORY.md | 2 +- _memories/_template-memory.md | 2 +- _memories/project_standard-online-kontekst.md | 8 +- _metode/00-konvensjoner.md | 124 +++++++++++++++ _metode/01-startklar-sjekkliste.md | 141 ++++++++++++++++++ _metode/02-gjennomforing.md | 140 +++++++++++++++++ artefakter/domenemodell-skjema.md | 91 +++++++++++ artefakter/integrasjonslandskap.md | 66 ++++++++ artefakter/risikoregister.md | 70 +++++++++ artefakter/workshop-agenda.md | 65 ++++++++ 34 files changed, 788 insertions(+), 85 deletions(-) create mode 100644 _metode/00-konvensjoner.md create mode 100644 _metode/01-startklar-sjekkliste.md create mode 100644 _metode/02-gjennomforing.md create mode 100644 artefakter/domenemodell-skjema.md create mode 100644 artefakter/integrasjonslandskap.md create mode 100644 artefakter/risikoregister.md create mode 100644 artefakter/workshop-agenda.md diff --git a/1.oppdrag-og-kontekst/motelogg-og-beslutninger.md b/1.oppdrag-og-kontekst/motelogg-og-beslutninger.md index 00081d1..db0d1c7 100644 --- a/1.oppdrag-og-kontekst/motelogg-og-beslutninger.md +++ b/1.oppdrag-og-kontekst/motelogg-og-beslutninger.md @@ -23,14 +23,14 @@ Master-oversikt over alle møter, beslutninger (DEC), handlinger (ACT) og risiko ## Handlingsregister -Tverrgående oversikt. Se også [[../7.standardisering-og-handlingsplan/prioriteringsliste]] for prioriterte tiltak. +Tverrgående oversikt. Se også [prioriteringsliste](../7.standardisering-og-handlingsplan/prioriteringsliste.md) for prioriterte tiltak. | ID | Handling | Ansvarlig | Frist | Status | |---|---|---|---|---| ## Risikoregister -Se [[../../artefakter/risikoregister]] for fullt register med Impact × Likelihood-score. +Se [risikoregister](../artefakter/risikoregister.md) for fullt register med Impact × Likelihood-score. --- diff --git a/1.oppdrag-og-kontekst/oppdragsbeskrivelse.md b/1.oppdrag-og-kontekst/oppdragsbeskrivelse.md index f61427f..bfc81dc 100644 --- a/1.oppdrag-og-kontekst/oppdragsbeskrivelse.md +++ b/1.oppdrag-og-kontekst/oppdragsbeskrivelse.md @@ -39,7 +39,7 @@ version: 1 ## Leveranser -Se [[mal-og-leveranser]] for detaljert leveranseoversikt. +Se [mal-og-leveranser](mal-og-leveranser.md) for detaljert leveranseoversikt. ## Tidsramme diff --git a/1.oppdrag-og-kontekst/rammer-og-avklaringer.md b/1.oppdrag-og-kontekst/rammer-og-avklaringer.md index 9d8fe67..b4b5e7d 100644 --- a/1.oppdrag-og-kontekst/rammer-og-avklaringer.md +++ b/1.oppdrag-og-kontekst/rammer-og-avklaringer.md @@ -31,7 +31,7 @@ version: 1 ## Åpne avklaringspunkter -Se [[../8.kontinuerlig-laering-og-referanser/apne-sporsmal]] for løpende spørsmålsliste. +Se [apne-sporsmal](../8.kontinuerlig-laering-og-referanser/apne-sporsmal.md) for løpende spørsmålsliste. --- diff --git a/3.system-og-datalandskap/integrasjoner-og-flyt.md b/3.system-og-datalandskap/integrasjoner-og-flyt.md index f969e15..4ed5a3e 100644 --- a/3.system-og-datalandskap/integrasjoner-og-flyt.md +++ b/3.system-og-datalandskap/integrasjoner-og-flyt.md @@ -11,11 +11,11 @@ version: 1 # Integrasjoner og dataflyt -Hvordan data flyter mellom systemene som er kartlagt i [[hovedsystemer]]. +Hvordan data flyter mellom systemene som er kartlagt i [hovedsystemer](hovedsystemer.md). ## Integrasjonslandskap -Bruk strukturen fra [[../../artefakter/integrasjonslandskap]]: +Bruk strukturen fra [integrasjonslandskap](../artefakter/integrasjonslandskap.md): | System | Retning | Motpart | Mekanisme | Datatyper | Frekvens | Implikasjon | |---|---|---|---|---|---|---| diff --git a/3.system-og-datalandskap/systemkart-as-is.md b/3.system-og-datalandskap/systemkart-as-is.md index 0d399dc..eb05e67 100644 --- a/3.system-og-datalandskap/systemkart-as-is.md +++ b/3.system-og-datalandskap/systemkart-as-is.md @@ -9,7 +9,7 @@ version: 1 # Systemkart (as-is) -Visuell oversikt over dagens systemlandskap. Bygges ut i Fase B basert på [[hovedsystemer]] og [[integrasjoner-og-flyt]]. +Visuell oversikt over dagens systemlandskap. Bygges ut i Fase B basert på [hovedsystemer](hovedsystemer.md) og [integrasjoner-og-flyt](integrasjoner-og-flyt.md). ## Hovedkart @@ -49,7 +49,7 @@ graph TB ## Sammenligning med målbilde -Lenke til [[../9.leveranser-og-oppsummeringer/sluttrapport#målarkitektur]] når den er ferdig. +Lenke til [sluttrapport](../9.leveranser-og-oppsummeringer/sluttrapport.md#målarkitektur) når den er ferdig. --- diff --git a/4.informasjonsarkitektur/begrepskatalog.md b/4.informasjonsarkitektur/begrepskatalog.md index c204883..3fa237e 100644 --- a/4.informasjonsarkitektur/begrepskatalog.md +++ b/4.informasjonsarkitektur/begrepskatalog.md @@ -17,19 +17,19 @@ Felles begrepsdefinisjoner for Standard Online. Bygges ut løpende gjennom oppdr ## Hvordan bruke - **Definisjon** skal være entydig og gjenkjennelig for forretningen -- **Domene** kobler begrepet til [[informasjonsdomener]] +- **Domene** kobler begrepet til [informasjonsdomener](informasjonsdomener.md) - **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]] +- **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]] | +| 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.* diff --git a/4.informasjonsarkitektur/data-governance-prinsipper.md b/4.informasjonsarkitektur/data-governance-prinsipper.md index 9cdaae6..8f233e0 100644 --- a/4.informasjonsarkitektur/data-governance-prinsipper.md +++ b/4.informasjonsarkitektur/data-governance-prinsipper.md @@ -42,7 +42,7 @@ Formålet med Data Governance hos Standard Online: - 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]]) +- Sikre at data tilfredsstiller de 8 kriteriene (se [masterdata-og-eierskap](masterdata-og-eierskap.md#8-kriterier-for-godt-dataeierskap)) **Eksempler:** Fagavdeling kunde- og bedriftsdata, fagavdeling produktdata. diff --git a/4.informasjonsarkitektur/datakvalitet-og-avvik.md b/4.informasjonsarkitektur/datakvalitet-og-avvik.md index af561e2..52b46cd 100644 --- a/4.informasjonsarkitektur/datakvalitet-og-avvik.md +++ b/4.informasjonsarkitektur/datakvalitet-og-avvik.md @@ -43,14 +43,14 @@ Standardvurdering per dimensjon: ## Avviksliste -Konkrete observerte avvik. Også lenket fra [[../7.standardisering-og-handlingsplan/avviksliste]]. +Konkrete observerte avvik. Også lenket fra [avviksliste](../7.standardisering-og-handlingsplan/avviksliste.md). | ID | Avvik | Domene | System | Konsekvens | Foreslått tiltak | |---|---|---|---|---|---| ## Anbefalinger -*Prioriterte tiltak for datakvalitet, koblet til [[../7.standardisering-og-handlingsplan/prioriteringsliste]].* +*Prioriterte tiltak for datakvalitet, koblet til [prioriteringsliste](../7.standardisering-og-handlingsplan/prioriteringsliste.md).* --- diff --git a/4.informasjonsarkitektur/informasjonsdomener.md b/4.informasjonsarkitektur/informasjonsdomener.md index f7efa42..1c70fff 100644 --- a/4.informasjonsarkitektur/informasjonsdomener.md +++ b/4.informasjonsarkitektur/informasjonsdomener.md @@ -45,10 +45,10 @@ Hovedinndeling av informasjon hos Standard Online. Hvert domene har en eller fle *Hva mangler for at domenet skal være godt forvaltet?* **Risikoer:** -*Kobling til [[../../artefakter/risikoregister]].* +*Kobling til [risikoregister](../artefakter/risikoregister.md).* **Anbefalte tiltak:** -*Kobling til [[../7.standardisering-og-handlingsplan/prioriteringsliste]].* +*Kobling til [prioriteringsliste](../7.standardisering-og-handlingsplan/prioriteringsliste.md).* --- diff --git a/4.informasjonsarkitektur/masterdata-og-eierskap.md b/4.informasjonsarkitektur/masterdata-og-eierskap.md index e0ae949..fe67424 100644 --- a/4.informasjonsarkitektur/masterdata-og-eierskap.md +++ b/4.informasjonsarkitektur/masterdata-og-eierskap.md @@ -64,7 +64,7 @@ Skillet er kritisk — "dataeier" som ett begrep skaper diskusjon. Vi skiller de ### — eksempel: Bedrift -**Definisjon:** *Hva er en bedrift i denne sammenhengen? Lenke til [[begrepskatalog]].* +**Definisjon:** *Hva er en bedrift i denne sammenhengen? Lenke til [begrepskatalog](begrepskatalog.md).* **Master (SoR):** - **System:** @@ -79,9 +79,9 @@ Skillet er kritisk — "dataeier" som ett begrep skaper diskusjon. Vi skiller de - **Alternativer i dag:** *Hvilke ulike nøkler brukes i ulike systemer? Konfliktrisiko?* **Tilstand:** -- **Kvalitet:** +- **Kvalitet:** - **Gap:** -- **Anbefalt tiltak:** *Lenke til [[../7.standardisering-og-handlingsplan/prioriteringsliste]]* +- **Anbefalt tiltak:** *Lenke til [prioriteringsliste](../7.standardisering-og-handlingsplan/prioriteringsliste.md)* --- diff --git a/4.informasjonsarkitektur/standardiseringsbehov.md b/4.informasjonsarkitektur/standardiseringsbehov.md index 516313c..df7b178 100644 --- a/4.informasjonsarkitektur/standardiseringsbehov.md +++ b/4.informasjonsarkitektur/standardiseringsbehov.md @@ -31,7 +31,7 @@ Identifiserte behov for felles standarder, kodeverk og strukturer på tvers av s ## Anbefalinger -Lenke til [[../7.standardisering-og-handlingsplan/prioriteringsliste]] for prioriterte tiltak. +Lenke til [prioriteringsliste](../7.standardisering-og-handlingsplan/prioriteringsliste.md) for prioriterte tiltak. --- diff --git a/5.personvern-og-sikkerhet/dataflyt-og-risiko.md b/5.personvern-og-sikkerhet/dataflyt-og-risiko.md index 2f8307f..a037942 100644 --- a/5.personvern-og-sikkerhet/dataflyt-og-risiko.md +++ b/5.personvern-og-sikkerhet/dataflyt-og-risiko.md @@ -12,7 +12,7 @@ version: 1 # Dataflyt og personvernrisiko -Personvernperspektiv på dataflyten kartlagt i [[../3.system-og-datalandskap/integrasjoner-og-flyt]]. +Personvernperspektiv på dataflyten kartlagt i [integrasjoner-og-flyt](../3.system-og-datalandskap/integrasjoner-og-flyt.md). ## Risikomatrise per integrasjon diff --git a/5.personvern-og-sikkerhet/gdpr-oversikt.md b/5.personvern-og-sikkerhet/gdpr-oversikt.md index 45cb0ff..b2efd0c 100644 --- a/5.personvern-og-sikkerhet/gdpr-oversikt.md +++ b/5.personvern-og-sikkerhet/gdpr-oversikt.md @@ -57,11 +57,11 @@ Skal omfatte alle behandlinger av personopplysninger. Bygges ut i Fase B. - **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]]. +Lenke til [ai-prinsipper](../6.ai-rammeverk/ai-prinsipper.md). ## Risikoer -Lenke til [[../../artefakter/risikoregister]] for GDPR-relaterte risikoer. +Lenke til [risikoregister](../artefakter/risikoregister.md) for GDPR-relaterte risikoer. --- diff --git a/5.personvern-og-sikkerhet/tiltak-for-innebygd-personvern.md b/5.personvern-og-sikkerhet/tiltak-for-innebygd-personvern.md index 2b0b304..844faeb 100644 --- a/5.personvern-og-sikkerhet/tiltak-for-innebygd-personvern.md +++ b/5.personvern-og-sikkerhet/tiltak-for-innebygd-personvern.md @@ -62,7 +62,7 @@ Følgende tiltak mangler eller bør prioriteres hos Standard Online: ## Anbefalinger -*Lenke til [[../7.standardisering-og-handlingsplan/prioriteringsliste]] for prioriterte tiltak.* +*Lenke til [prioriteringsliste](../7.standardisering-og-handlingsplan/prioriteringsliste.md) for prioriterte tiltak.* --- diff --git a/6.ai-rammeverk/ai-prinsipper.md b/6.ai-rammeverk/ai-prinsipper.md index 2b34065..0135701 100644 --- a/6.ai-rammeverk/ai-prinsipper.md +++ b/6.ai-rammeverk/ai-prinsipper.md @@ -19,29 +19,29 @@ Operasjonelle prinsipper for AI-agenter hos Standard Online. **Dette er ikke en ## 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]]. +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å [masterdata-og-eierskap](../4.informasjonsarkitektur/masterdata-og-eierskap.md) og [data-governance-prinsipper](../4.informasjonsarkitektur/data-governance-prinsipper.md). ## 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]]. +Ingen AI-agent skal opptre under en generisk eller delt identitet. Hver agent autentiseres og autoriseres som en egen entitet. Se [identifiserbarhet-og-tilgang](identifiserbarhet-og-tilgang.md). ### 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]]. +Tilganger gis per agent, per oppgave, og kun til nødvendig data og funksjonalitet. Tilganger gjennomgås periodisk. Se [identifiserbarhet-og-tilgang](identifiserbarhet-og-tilgang.md). ### 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]]. +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](logging-og-sporbarhet.md). ### 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]]. +Beslutninger kategoriseres i tre nivåer: autonom, varslende, godkjennende. Kategoriseringen reflekterer risiko og reversibilitet. Se [human-in-the-loop](human-in-the-loop.md). ### 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]]. +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](datakvalitet-som-ai-premiss.md). ## Åpne spørsmål for kundedialog diff --git a/6.ai-rammeverk/datakvalitet-som-ai-premiss.md b/6.ai-rammeverk/datakvalitet-som-ai-premiss.md index 3ce2fce..1878017 100644 --- a/6.ai-rammeverk/datakvalitet-som-ai-premiss.md +++ b/6.ai-rammeverk/datakvalitet-som-ai-premiss.md @@ -28,12 +28,12 @@ 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]] | +| SoR tildelt | [masterdata-og-eierskap](../4.informasjonsarkitektur/masterdata-og-eierskap.md) | +| Dataforvalter utnevnt | [masterdata-og-eierskap](../4.informasjonsarkitektur/masterdata-og-eierskap.md) | +| Begrepskatalog dekker entitetene | [begrepskatalog](../4.informasjonsarkitektur/begrepskatalog.md) | +| Datakvalitet kjent (måling utført) | [datakvalitet-og-avvik](../4.informasjonsarkitektur/datakvalitet-og-avvik.md) | +| Personverntiltak på plass | [tiltak-for-innebygd-personvern](../5.personvern-og-sikkerhet/tiltak-for-innebygd-personvern.md) | +| Tilgangsstyring etablert | [identifiserbarhet-og-tilgang](identifiserbarhet-og-tilgang.md) | ## Per use case diff --git a/7.standardisering-og-handlingsplan/maleparametere.md b/7.standardisering-og-handlingsplan/maleparametere.md index fc97ad0..5175b4d 100644 --- a/7.standardisering-og-handlingsplan/maleparametere.md +++ b/7.standardisering-og-handlingsplan/maleparametere.md @@ -17,9 +17,9 @@ KPIer for å følge opp handlingsplanen og måle fremgang. | 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 tildelt SoR | % entiteter i [masterdata-og-eierskap](../4.informasjonsarkitektur/masterdata-og-eierskap.md) 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 | +| Begrepskatalog-dekning | Antall begreper i [begrepskatalog](../4.informasjonsarkitektur/begrepskatalog.md) | Månedlig | Vekst | ### Datakvalitet diff --git a/7.standardisering-og-handlingsplan/prioriteringsliste.md b/7.standardisering-og-handlingsplan/prioriteringsliste.md index ab3589b..553633f 100644 --- a/7.standardisering-og-handlingsplan/prioriteringsliste.md +++ b/7.standardisering-og-handlingsplan/prioriteringsliste.md @@ -17,7 +17,7 @@ Konkrete, prioriterte tiltak basert på funn fra kartleggingen. Faseinndelt 0-3 ## Prioriteringskriterier -- **Risiko** — hvor stor er risikoen ved å ikke gjøre dette? (lenke til [[../../artefakter/risikoregister]]) +- **Risiko** — hvor stor er risikoen ved å ikke gjøre dette? (lenke til [risikoregister](../artefakter/risikoregister.md)) - **Gevinst** — hva oppnår vi? - **Avhengighet** — hva må være på plass først? - **Innsats** — estimert ressursbehov diff --git a/7.standardisering-og-handlingsplan/tiltak-per-omrade.md b/7.standardisering-og-handlingsplan/tiltak-per-omrade.md index 8fed7de..226159b 100644 --- a/7.standardisering-og-handlingsplan/tiltak-per-omrade.md +++ b/7.standardisering-og-handlingsplan/tiltak-per-omrade.md @@ -11,7 +11,7 @@ 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. +Samme tiltakssett som [prioriteringsliste](prioriteringsliste.md), 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 diff --git a/9.leveranser-og-oppsummeringer/executive-summary.md b/9.leveranser-og-oppsummeringer/executive-summary.md index 8a5e813..77aab42 100644 --- a/9.leveranser-og-oppsummeringer/executive-summary.md +++ b/9.leveranser-og-oppsummeringer/executive-summary.md @@ -57,7 +57,7 @@ Kort om hvorfor oppdraget ble gjennomført og hva som var innenfor scope. ## 4. Risikoer -Toppen av risikoregisteret. Fullt register: [[../../artefakter/risikoregister]]. +Toppen av risikoregisteret. Fullt register: [risikoregister](../artefakter/risikoregister.md). | # | Risiko | Score | Mitigasjon | |---|---|---|---| @@ -66,7 +66,7 @@ Toppen av risikoregisteret. Fullt register: [[../../artefakter/risikoregister]]. ## 5. Anbefalinger -Hovedanbefalinger, gruppert. Detaljer i [[../7.standardisering-og-handlingsplan/prioriteringsliste]]. +Hovedanbefalinger, gruppert. Detaljer i [prioriteringsliste](../7.standardisering-og-handlingsplan/prioriteringsliste.md). ### Kortsiktig (0-3 mnd) 1. diff --git a/9.leveranser-og-oppsummeringer/leveranseplan.md b/9.leveranser-og-oppsummeringer/leveranseplan.md index c75321e..58ec000 100644 --- a/9.leveranser-og-oppsummeringer/leveranseplan.md +++ b/9.leveranser-og-oppsummeringer/leveranseplan.md @@ -11,7 +11,7 @@ version: 1 # Leveranseplan -Overordnet leveranseplan, koblet til [[../1.oppdrag-og-kontekst/mal-og-leveranser]] og [[../../02-gjennomforing]]. +Overordnet leveranseplan, koblet til [mal-og-leveranser](../1.oppdrag-og-kontekst/mal-og-leveranser.md) og [02-gjennomforing](../_metode/02-gjennomforing.md). ## Faser og milepæler diff --git a/9.leveranser-og-oppsummeringer/sluttrapport.md b/9.leveranser-og-oppsummeringer/sluttrapport.md index 1f39fba..1e955a0 100644 --- a/9.leveranser-og-oppsummeringer/sluttrapport.md +++ b/9.leveranser-og-oppsummeringer/sluttrapport.md @@ -35,7 +35,7 @@ version: 1 ### 1.2 Mål med oppdraget -*Hva skulle oppdraget oppnå? Lenke til [[../1.oppdrag-og-kontekst/mal-og-leveranser]].* +*Hva skulle oppdraget oppnå? Lenke til [mal-og-leveranser](../1.oppdrag-og-kontekst/mal-og-leveranser.md).* ### 1.3 Omfang og avgrensninger @@ -52,7 +52,7 @@ version: 1 ### 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]]. +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](../_metode/02-gjennomforing.md) og [leveranseplan](leveranseplan.md). **Gjennomførte aktiviteter:** - [x] Kickoff og scope-bekreftelse @@ -72,7 +72,7 @@ Oppdraget ble gjennomført med Fortes **Startklar-metodikk** for data readiness ### 2.1 Nåsituasjon -Sammenstilling av [[../3.system-og-datalandskap/hovedsystemer]] og [[../3.system-og-datalandskap/integrasjoner-og-flyt]]. +Sammenstilling av [hovedsystemer](../3.system-og-datalandskap/hovedsystemer.md) og [integrasjoner-og-flyt](../3.system-og-datalandskap/integrasjoner-og-flyt.md). #### 2.1.1 Systemlandskap @@ -87,11 +87,11 @@ Sammenstilling av [[../3.system-og-datalandskap/hovedsystemer]] og [[../3.system ### 2.3 Datakvalitet og governance -Sammenstilling av [[../4.informasjonsarkitektur/datakvalitet-og-avvik]] og [[../4.informasjonsarkitektur/masterdata-og-eierskap]]. +Sammenstilling av [datakvalitet-og-avvik](../4.informasjonsarkitektur/datakvalitet-og-avvik.md) og [masterdata-og-eierskap](../4.informasjonsarkitektur/masterdata-og-eierskap.md). ### 2.4 Personvern og sikkerhet -Sammenstilling av [[../5.personvern-og-sikkerhet/gdpr-oversikt]] og [[../5.personvern-og-sikkerhet/tiltak-for-innebygd-personvern]]. +Sammenstilling av [gdpr-oversikt](../5.personvern-og-sikkerhet/gdpr-oversikt.md) og [tiltak-for-innebygd-personvern](../5.personvern-og-sikkerhet/tiltak-for-innebygd-personvern.md). ### 2.5 Innsiktsoppsummering @@ -111,26 +111,26 @@ Sammenstilling av [[../5.personvern-og-sikkerhet/gdpr-oversikt]] og [[../5.perso ### 3.2 Anbefalt målarkitektur -*Skisse, integrasjonsmønster, anbefalte komponenter. Detaljer i [[../3.system-og-datalandskap/systemkart-as-is]] (sammenligning) og dedikerte arkitektur-skisser.* +*Skisse, integrasjonsmønster, anbefalte komponenter. Detaljer i [systemkart-as-is](../3.system-og-datalandskap/systemkart-as-is.md) (sammenligning) og dedikerte arkitektur-skisser.* ### 3.3 Masterdata-modell -Sammenstilling av [[../4.informasjonsarkitektur/masterdata-og-eierskap]]. +Sammenstilling av [masterdata-og-eierskap](../4.informasjonsarkitektur/masterdata-og-eierskap.md). | 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. +Sammenstilling av [ai-prinsipper](../6.ai-rammeverk/ai-prinsipper.md). Fem prinsipper: identifiserbarhet, minste privilegium, sporbarhet, HITL, datakvalitet som premiss. ### 3.5 Governance-modell -Sammenstilling av [[../4.informasjonsarkitektur/data-governance-prinsipper]]. +Sammenstilling av [data-governance-prinsipper](../4.informasjonsarkitektur/data-governance-prinsipper.md). ### 3.6 Anbefalte tiltak -Sammenstilling av [[../7.standardisering-og-handlingsplan/prioriteringsliste]]. +Sammenstilling av [prioriteringsliste](../7.standardisering-og-handlingsplan/prioriteringsliste.md). ### 3.7 Kost/nytte-vurdering @@ -139,7 +139,7 @@ Sammenstilling av [[../7.standardisering-og-handlingsplan/prioriteringsliste]]. ### 3.8 Risikovurdering -Lenke til [[../../artefakter/risikoregister]] for fullt register. +Lenke til [risikoregister](../artefakter/risikoregister.md) for fullt register. --- @@ -186,7 +186,7 @@ Fase 1: Grunnmur Fase 2: Konsolidering Fase 3: AI-aktivering ### Vedlegg A: Datakilde-inventar -Lenke til [[../3.system-og-datalandskap/hovedsystemer]]. +Lenke til [hovedsystemer](../3.system-og-datalandskap/hovedsystemer.md). ### Vedlegg B: Intervjuoversikt @@ -195,15 +195,15 @@ Lenke til [[../3.system-og-datalandskap/hovedsystemer]]. ### Vedlegg C: Risikoregister -Lenke til [[../../artefakter/risikoregister]]. +Lenke til [risikoregister](../artefakter/risikoregister.md). ### Vedlegg D: Integrasjonslandskap -Lenke til [[../../artefakter/integrasjonslandskap]] og [[../3.system-og-datalandskap/integrasjoner-og-flyt]]. +Lenke til [integrasjonslandskap](../artefakter/integrasjonslandskap.md) og [integrasjoner-og-flyt](../3.system-og-datalandskap/integrasjoner-og-flyt.md). ### Vedlegg E: Begrepskatalog -Lenke til [[../4.informasjonsarkitektur/begrepskatalog]]. +Lenke til [begrepskatalog](../4.informasjonsarkitektur/begrepskatalog.md). ### Vedlegg F: Ordliste diff --git a/CLAUDE.md b/CLAUDE.md index 1f7237f..3b6b908 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -43,7 +43,7 @@ Ragnhild driver det daglige arbeidet (kartlegging, workshops, dialog med Standar | C — Anbefalinger | 3-5 | Masterdata, arkitektur, AI, personvern | Delleveranse 2: Målbilde + masterdata (uke 5) | | D — Forankring | 6-7 | Presentasjon, overlevering | Sluttleveranse (uke 6-7) | -Detaljer i `../../Salg/_mal/startklar-malverk/02-gjennomforing.md`. +Detaljer i [_metode/02-gjennomforing.md](_metode/02-gjennomforing.md). ## Mappestruktur — 9 nummererte mapper @@ -63,7 +63,7 @@ Komplett innholdsfortegnelse: [_index.md](_index.md). ## Konvensjoner -Felles konvensjoner følger Forte sitt startklar-malverk: `../../Salg/_mal/startklar-malverk/00-konvensjoner.md`. +Felles konvensjoner er dokumentert i [_metode/00-konvensjoner.md](_metode/00-konvensjoner.md) (avledet fra Forte sitt kanoniske startklar-malverk). ### Frontmatter @@ -125,10 +125,12 @@ Når Claude oppdager noe verdt å huske som er prosjekt-spesifikt, skal det lagr ## Sentrale referansecase (metodikk og maler) -Bygger på to ferske oppdrag: +Metodikken bygger på to ferske oppdrag. Disse ligger i Forte sitt bredere arbeidsområde — **ikke i dette repoet** (de gjelder andre kunder; Kirken er konfidensielt for en annen kunde). De er nevnt her som bakgrunn for hvor mønstrene kommer fra: -- **Oras Group** (`../../Salg/Oras/`): Data Health Assessment for CRM-anskaffelse. Risikoregister-mønster, Executive Summary-struktur, integrasjonslandskap-tabell. -- **Den norske kirke / Nstat** (`../../../Kirken/`): Informasjonsarkitektur for offentlig organisasjon. 9-mappe-struktur, Begrepseier/Dataforvalter/Master-vokabular, Privacy by Design, 3-nivå governance. +- **Oras Group** — Data Health Assessment for CRM-anskaffelse. Risikoregister-mønster, Executive Summary-struktur, integrasjonslandskap-tabell. (Ligger i `Salg/Oras/` i Forte-arbeidsområdet.) +- **Den norske kirke / Nstat** — Informasjonsarkitektur for offentlig organisasjon. 9-mappe-struktur, Begrepseier/Dataforvalter/Master-vokabular, Privacy by Design, 3-nivå governance. (Eget repo/arbeidsområde.) + +Det vi faktisk trenger fra metodikken er hentet inn i dette repoet under [_metode/](_metode/) og [artefakter/](artefakter/). ## Repository-konvensjoner @@ -140,10 +142,10 @@ Bygger på to ferske oppdrag: ## Salgsmaterialet — kilden til oppdraget -`../../Salg/Standard/` inneholder: +Salgsmaterialet ligger i `Salg/Standard/` i Forte-arbeidsområdet (**ikke i dette repoet** — det er salgsfase-materiale, ikke leveranse): - Forslaget vi sendte (`Forslag - Masterdata, arkitektur og AI-klargjøring.md`) - Kundens oppdragsbeskrivelse (PDF) - Pitch-presentasjon (PPTX) - CV-er for teamet -Når du trenger å verifisere "hva vi lovet kunden" — slå opp der. +Når du trenger å verifisere "hva vi lovet kunden" — slå opp der. Det viktigste innholdet er destillert inn i [_memories/project_standard-online-kontekst.md](_memories/project_standard-online-kontekst.md), som ligger i repoet. diff --git a/README.md b/README.md index 9986844..fdd66ea 100644 --- a/README.md +++ b/README.md @@ -17,10 +17,13 @@ Arbeidsmappe for Standard Online-oppdraget: kartlegging og anbefalingsarbeid for ## 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. +9-mappe-modell fra Startklar-malverket. Se [_index.md](_index.md) for full innholdsfortegnelse. Modellen er forklart i metodikkdokumentene under [_metode/](_metode/) (kopiert inn i repoet, avledet fra Forte sitt kanoniske `startklar-malverk` i `Salg/_mal/`-arbeidsområdet). ``` Oppdrag/Standard/ +├── _metode/ # Konvensjoner, sjekkliste, gjennomføringsmodell +├── artefakter/ # Gjenbrukbare maler (risikoregister, integrasjonslandskap, ...) +├── _memories/ # Prosjektkunnskap som overlever sesjoner ├── 1.oppdrag-og-kontekst/ # Scope, leveranser, interessenter, møtelogg ├── 2.organisasjonsforstaelse/ # Roller, beslutningsveier, nøkkelpersoner ├── 3.system-og-datalandskap/ # Systemer, integrasjoner, as-is @@ -48,30 +51,29 @@ Detaljer i `1.oppdrag-og-kontekst/oppdragsbeskrivelse.md` når den fylles ut ved ## 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` +1. Petter fyller ut [_metode/01-startklar-sjekkliste.md](_metode/01-startklar-sjekkliste.md) internt +2. Oppdater [1.oppdrag-og-kontekst/oppdragsbeskrivelse.md](1.oppdrag-og-kontekst/oppdragsbeskrivelse.md) med faktiske datoer, team, scope +3. Følg fasestrukturen i [_metode/02-gjennomforing.md](_metode/02-gjennomforing.md) ## Verktøykasse -Maler og artefakter som ikke kopieres inn lokalt (forblir kanoniske i `Salg/_mal/`): +Gjenbrukbare maler ligger i [artefakter/](artefakter/) — kopier dem inn i passende undermappe når du tar dem i bruk (typisk inn i den leveransen de hører til): -- [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). +- [Risikoregister](artefakter/risikoregister.md) — Impact × Likelihood +- [Integrasjonslandskap](artefakter/integrasjonslandskap.md) +- [Workshop-agenda](artefakter/workshop-agenda.md) +- [Domenemodell-skjema](artefakter/domenemodell-skjema.md) ## Konvensjoner -Følger Forte/Startklar-konvensjonene definert i `Salg/_mal/startklar-malverk/00-konvensjoner.md`: +Følger Forte/Startklar-konvensjonene definert i [_metode/00-konvensjoner.md](_metode/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 +- **Lenker som standard markdown** (`[tekst](sti.md)`), ikke Obsidian-wikilinks — slik at de er klikkbare både i Gitea og lokalt --- diff --git a/_memories/MEMORY.md b/_memories/MEMORY.md index 4a24176..5f4b5fc 100644 --- a/_memories/MEMORY.md +++ b/_memories/MEMORY.md @@ -4,7 +4,7 @@ Prosjektspesifikke memories. Hver linje peker til en memory-fil i denne mappen. Format: `- [Tittel](fil.md) — én-linjes hook` -Hold listen kort og scannbar. Bruk `[[fil-navn]]`-lenker innen memory-filer for kryssreferanser. +Hold listen kort og scannbar. Bruk standard markdown-lenker `[tekst](fil-navn.md)` innen memory-filer for kryssreferanser — de er klikkbare både i Gitea og lokalt. --- diff --git a/_memories/_template-memory.md b/_memories/_template-memory.md index 1cede7b..c186c47 100644 --- a/_memories/_template-memory.md +++ b/_memories/_template-memory.md @@ -29,7 +29,7 @@ For **reference** memories — strukturér slik: ## Lenker til relaterte memories -Bruk wikilink-stil: `[[andre-memory-navn]]`. Det er greit å lenke til memories som ikke finnes ennå — markerer at de er verdt å skrive. +Bruk standard markdown-lenker: `[andre-memory-navn](andre-memory-navn.md)`. Det er greit å lenke til memories som ikke finnes ennå — markerer at de er verdt å skrive. (Vi bruker ikke Obsidian-wikilinks `[[...]]` her, fordi Gitea ikke rendrer dem som klikkbare.) ## Sjekkliste når du oppretter en ny memory diff --git a/_memories/project_standard-online-kontekst.md b/_memories/project_standard-online-kontekst.md index 79ca6f5..6174abd 100644 --- a/_memories/project_standard-online-kontekst.md +++ b/_memories/project_standard-online-kontekst.md @@ -99,9 +99,11 @@ Konsekvens: Vi skal IKKE replikere Oras' entity-by-entity-dybde. Vi stopper på ## Salgsmaterialet som etablerer kontekst -- `../../Salg/Standard/Forslag - Masterdata, arkitektur og AI-klargjøring.md` — fullstendig forslag -- `../../Salg/Standard/Oppdragsbeskrivelse masterdataprosjekt.pdf` — kundens RFP -- `../../Salg/Standard/Standard_Digital2.pptx` — pitch-presentasjonen +Ligger i `Salg/Standard/` i Forte-arbeidsområdet (ikke i dette repoet — salgsfase-materiale): + +- `Forslag - Masterdata, arkitektur og AI-klargjøring.md` — fullstendig forslag +- `Oppdragsbeskrivelse masterdataprosjekt.pdf` — kundens RFP +- `Standard_Digital2.pptx` — pitch-presentasjonen ## Sjekkpunkter ved oppstart diff --git a/_metode/00-konvensjoner.md b/_metode/00-konvensjoner.md new file mode 100644 index 0000000..266af05 --- /dev/null +++ b/_metode/00-konvensjoner.md @@ -0,0 +1,124 @@ +--- +title: "Konvensjoner — Startklar-malverk" +date: "2026-05-21" +tags: ["konvensjoner", "frontmatter", "metode"] +version: 1 +--- + +# Konvensjoner + +Felles konvensjoner for alle dokumenter i et oppdrag som bruker dette malverket. Arvet og generalisert fra Den norske kirke-oppdraget. + +## Frontmatter + +Alle leveranse- og analysedokumenter skal ha YAML-frontmatter: + +```yaml +--- +title: "Dokumenttittel — Kundenavn" +date: "YYYY-MM-DD" +source: "Kilder dokumentet bygger på (komma-separert)" +tags: ["tag1", "tag2"] +refs: + - "relativ/sti/til/relatert-dokument.md" +qa: + status: "draft | final-candidate | needs-fix" + reviewed_on: "YYYY-MM-DD" + reviewer: "Navn eller rolle" +version: 1 +--- +``` + +**Status-verdier:** +- `draft` — under arbeid +- `final-candidate` — klar for sluttgjennomgang +- `needs-fix` — funn å adressere + +For mindre interne arbeidsdokumenter (intervjunotater, hypoteseskisser) kan frontmatter forenkles til kun `title`, `date`, `tags`. + +## ID-system + +Strukturerte ekstrakter får IDer slik at de kan refereres på tvers av dokumenter: + +| Prefiks | Type | Eksempel | +|---|---|---| +| `DEC-YYYY-XXX` | Beslutning | DEC-2026-005 | +| `ACT-YYYY-XXX` | Handling | ACT-2026-012 | +| `RISK-YYYY-XXX` | Risiko | RISK-2026-003 | + +**Format:** ID + tittel, deretter strukturerte felter: + +```markdown +### DEC-2026-005 — Bedrift som master-entitet ligger i Business Central + +**Dato:** 2026-06-03 +**Kilde:** Kickoff med Standard Online + Standard Digital +**Status:** Bekreftet +**Konsekvens:** SuperOffice og nopCommerce konsumerer; ingen skriving direkte i CRM/nettbutikk. +``` + +ID-numre allokeres fortløpende per type per år. Sjekk eksisterende dokumenter for siste brukte nummer før nytt ID utstedes. + +## Citation-format + +Når du refererer til kildemateriale: + +| Kildetype | Format | Eksempel | +|---|---|---| +| Markdown | `sti/til/fil.md#L12-L34` | `3.system-og-datalandskap/hovedsystemer.md#L42-L58` | +| DOCX | `docx:avsnitt-N-M` eller `docx:side-N` | `oppdragsbeskrivelse.docx:avsnitt-3-5` | +| PDF | `pdf:side-N` | `Startklar.pdf:side-1` | +| Ekstern URL | Full URL i lenke | `[Tittel](https://...)` | +| Møte | Dato + tema | `Møte 2026-06-03: Kickoff` | + +Lenker til andre dokumenter i samme oppdrag bruker **standard markdown med relativ sti**: `[masterdata-og-eierskap](../4.informasjonsarkitektur/masterdata-og-eierskap.md)`. Vi bruker IKKE Obsidian-wikilinks `[[...]]` — de er klikkbare i Obsidian lokalt, men Gitea rendrer dem ikke som lenker. Standard markdown fungerer i begge. Relative stier fungerer både i Gitea-web og lokalt så lenge målet ligger inne i repoet. + +## ANTAKELSE-markering + +Når du formulerer noe basert på begrenset informasjon, marker det eksplisitt: + +``` +ANTAKELSE: Bedriftsdata i SuperOffice er kanonisk for kundetjenesten, men ikke for fakturering. conf: moderat +``` + +Confidence-nivåer: +- **lav** — gjetning basert på kontekst, må verifiseres +- **moderat** — basert på indirekte informasjon, sannsynlig korrekt +- **høy** — basert på direkte kilde, men ikke formelt bekreftet + +Bekreftede fakta trenger ingen markering. + +## Datoformat + +ISO 8601 alltid: `YYYY-MM-DD` (f.eks. `2026-05-21`). Aldri `21.05.2026` eller `21/5-26`. + +## Språk + +Norsk Bokmål er standard. Engelsk for kundefasade ved internasjonale kunder (avklares i `01-startklar-sjekkliste.md`). + +## Versjonering + +`version: N` i frontmatter inkrementeres ved hver meningsfull endring etter første ferdigstilling. Mindre rettinger trenger ikke version-bump. Bruk `endringslogg`-seksjon nederst i dokumenter som endrer seg ofte: + +```markdown +## Endringslogg + +| Versjon | Dato | Endring | Forfatter | +|---|---|---|---| +| 1 | 2026-06-03 | Første utkast | Ragnhild | +| 2 | 2026-06-10 | Lagt til SuperOffice-avhengighet | Ragnhild | +``` + +## Klassifisering + +Alle leveranser klassifiseres nederst: + +- **Åpen** — kan deles eksternt +- **Begrenset** — kun for kunden og Forte-teamet (default) +- **Konfidensiell** — kun for navngitte personer + +## Filnavn + +- Bruk bindestrek, ikke understrek: `masterdata-og-eierskap.md`, ikke `masterdata_og_eierskap.md` +- Æ/Ø/Å erstattes med ae/oe/aa i filnavn for kompatibilitet: `kontinuerlig-laering`, ikke `kontinuerlig-læring` +- Datert prefix kun når relevant: `2026-06-03-kickoff.md` for møtenotater diff --git a/_metode/01-startklar-sjekkliste.md b/_metode/01-startklar-sjekkliste.md new file mode 100644 index 0000000..e4090ec --- /dev/null +++ b/_metode/01-startklar-sjekkliste.md @@ -0,0 +1,141 @@ +--- +title: "Startklar-sjekkliste — pre-flight" +date: "YYYY-MM-DD" +tags: ["startklar", "sjekkliste", "pre-flight"] +qa: + status: "draft" +version: 1 +--- + +# Startklar — sjekkliste + +> *Du tar ikke av før laget vet hvor det skal.* + +Pre-flight før kundedialog og oppstart. Fyll ut **internt** før kickoff. Resultat: felles mandat, tydelige prioriteringer, kundedialog på riktig grunnlag. + +Strukturen følger Startklar "keep it simple"-versjonen (8 punkter). For Nivå 2/3-oppdrag, se utvidet sjekkliste i `Salg/Startklar.pdf`. + +--- + +## 01 · Retning — Hvor skal vi? + +**Spørsmål:** +- Hva er strategisk plattform/ambisjon dette oppdraget tjener? +- Hva er ønsket tilstand 1-2 år etter oppdragets slutt? +- Hvilket konkret verdibidrag skal oppdraget gi? + +**Svar:** + +--- + +## 02 · Hensikt — Hvorfor skal vi dit? + +**Spørsmål:** +- Hva er hovedproblemet vi løser? (én setning) +- For hvem løser vi det? +- Hva skjer hvis vi *ikke* gjør dette? + +**Svar:** + +--- + +## 03 · Team — Hvem er med? + +**Spørsmål:** +- Hvem fra Forte? (rolle + allokering) +- Hvem fra kunden? (rolle + tilgjengelighet) +- Hvem fra tredjepart (utviklingspartner, leverandør)? (rolle + samspillsform) + +**Svar:** + +| Person | Organisasjon | Rolle | Allokering | Kontakt | +|---|---|---|---|---| + +--- + +## 04 · Eierskap — Hvem eier beslutningene? + +**Spørsmål:** +- Hvem er primært beslutningspunkt hos kunden? +- Hvem signerer av på scope og leveranser? +- Hvem er stedfortreder ved fravær? +- Hvor i organisasjonen er mandatet forankret? (avdeling, ledergruppe, styre) + +**Svar:** + +--- + +## 05 · Scope — Hva er innenfor, og hva er ikke? + +**Spørsmål:** +- Hvilke systemer/domener er innenfor scope? +- Hvilke er eksplisitt **utenfor**? +- Hva er dybden? (oversikt, fagvurdering, dyp teknisk analyse) +- Implementering inkludert eller ikke? + +**Innenfor scope:** +- + +**Utenfor scope:** +- + +--- + +## 06 · Innsikt — Hva vet vi om problemet? + +**Spørsmål:** +- Hvilken eksisterende dokumentasjon finnes? (arkitekturskisser, dataflytdiagrammer, tidligere utredninger) +- Hvilke tidligere oppdrag eller pågående initiativer er relevante? +- Hva er kunnskapshullene? Hvem må vi snakke med for å lukke dem? + +**Tilgjengelig underlag:** +- + +**Kunnskapshull / hovedspørsmål:** +- + +--- + +## 07 · Risiko — Hvilke avhengigheter må håndteres? + +**Spørsmål:** +- Hvilke andre prosjekter er kritiske avhengigheter? (ERP-skifte, CRM-migrasjon, etc.) +- Hvilke harde tidsfrister finnes? (lisens, regulatorisk, kontraktuelt) +- Hvilke organisatoriske risikoer? (kapasitet, beslutningshastighet, motstand) + +**Avhengigheter:** +- + +**Risikoer (kort liste):** +- + +--- + +## 08 · Teknologi — Hvilke kapabiliteter trengs? + +**Spørsmål:** +- Hva er kundens teknologisk landskap i hovedtrekk? +- Hvilke kapabiliteter trenger vi (datamodellering, integrasjonsanalyse, AI-rammeverk, GDPR)? +- Hvilke verktøy bruker vi? (Neo4j for relasjoner, Mermaid for diagrammer, etc.) +- Hvilke tilganger trenger vi + +**Svar:** + +--- + +## Resultat — felles mandat + +Etter utfylling: + +- [ ] **Felles mandat** internt i Forte-teamet +- [ ] **Tydelige prioriteringer** for første ukene +- [ ] **Kundedialog på riktig grunnlag** — vi vet hva vi skal spørre om og hva vi allerede vet + +**Sign-off:** + +| Navn | Rolle | Dato | +|---|---|---| + +--- + +*Klassifisering: Begrenset — internt Forte-dokument* diff --git a/_metode/02-gjennomforing.md b/_metode/02-gjennomforing.md new file mode 100644 index 0000000..2514632 --- /dev/null +++ b/_metode/02-gjennomforing.md @@ -0,0 +1,140 @@ +--- +title: "Gjennomføring — 4-fase-modell" +date: "2026-05-21" +tags: ["gjennomføring", "metode", "faseplan"] +version: 1 +--- + +# Gjennomføring — 4 faser + +Standard gjennomføringsmodell for Nivå 1-oppdrag (6-12 uker). Følger Standards forslag (slide 11) og Fortes Startklar-metodikk. + +## Oversikt + +| Fase | Varighet | Hovedaktivitet | Delleveranse | +|---|---|---|---| +| **A — Oppstart og avgrensning** | Uke 1 | Kickoff, scope, datakilde-inventar | Bekreftet scope og plan | +| **B — Kartlegging og analyse** | Uke 2-3 | Intervjuer, workshops, datakvalitet | **Delleveranse 1**: Nåsituasjon + risiko (uke 3) | +| **C — Anbefalinger og målbilde** | Uke 3-5 | Masterdata-modell, arkitektur, AI, personvern | **Delleveranse 2**: Målbilde + masterdata (uke 5) | +| **D — Forankring og overlevering** | Uke 6-7 | Presentasjon, forankring, overlevering | **Sluttleveranse**: Handlingsplan + governance | + +## Fase A — Oppstart og avgrensning (uke 1) + +**Mål:** Bekrefte felles forståelse av scope, mandat og arbeidsform. Etablere grunnlag for kartlegging. + +**Aktiviteter:** +- Kickoff med kunden (60-90 min) — felles gjennomgang av scope, leveranser, tidslinje +- Avklare beslutningspunkter og styringspunkter +- Få tilgang til eksisterende underlag (arkitekturskisser, dataflytdiagrammer, tidligere utredninger) +- Datakilde-inventar (første utkast) — hvilke systemer, dataflyt, integrasjoner +- Sett opp møtekadens, kommunikasjonsstruktur, mappe-tilgang +- Identifiser de 8-12 personene som skal intervjues i Fase B + +**Leveranser fra Fase A:** +- `1.oppdrag-og-kontekst/oppdragsbeskrivelse.md` — bekreftet versjon +- `1.oppdrag-og-kontekst/mal-og-leveranser.md` — operasjonalisert +- `1.oppdrag-og-kontekst/interessenter-og-kontaktinfo.md` +- `1.oppdrag-og-kontekst/rammer-og-avklaringer.md` +- `3.system-og-datalandskap/hovedsystemer.md` — første utkast +- Intervjuplan for Fase B + +**Styringspunkt:** Avstemming med beslutningskontakt på slutten av uke 1 — bekreft scope og plan før Fase B starter. + +## Fase B — Kartlegging og analyse (uke 2-3) + +**Mål:** Bygge en faktabasert forståelse av nåsituasjon, datakvalitet, integrasjoner og risiko. + +**Aktiviteter:** +- **8-12 intervjuer** (1-2 timers økter) med: + - Forretningseiere per domene + - IT-ansvarlige per system + - Potensielle dataeiere + - Sluttbrukere (utvalg) +- **Workshops:** + - Dataflyt-workshop (visualiser hvordan data oppstår, dupliseres, konsumeres) + - Datakvalitet-workshop (per system: hva fungerer, hva er problematisk) +- Bygg `3.system-og-datalandskap/*` ferdig +- Start `4.informasjonsarkitektur/begrepskatalog.md` (løpende gjennom hele oppdraget) +- Bruk `artefakter/integrasjonslandskap.md` til å strukturere integrasjonsfunn +- Fyll inn `artefakter/risikoregister.md` med funn etter hvert som de identifiseres + +**Leveranser fra Fase B:** +- `3.system-og-datalandskap/integrasjoner-og-flyt.md` +- `3.system-og-datalandskap/systemkart-as-is.md` +- `3.system-og-datalandskap/teknologier-og-leverandorer.md` +- `8.kontinuerlig-laering-og-referanser/funn-og-hypoteser.md` +- `artefakter/risikoregister.md` + +**Delleveranse 1 (uke 3):** Nåsituasjon + risikobilde — sammenstilling av mappe 3 + risikoregister + funn. Presenteres i styringsmøte med beslutningskontakt. + +## Fase C — Anbefalinger og målbilde (uke 3-5) + +**Mål:** Bygge masterdata-modell, målarkitektur, AI-rammeverk, personvern-vurdering og handlingsplan basert på funnene fra Fase B. + +**Aktiviteter:** +- **Masterdata-modellering:** + - Identifiser kjernedomener (typisk 4-6 for Nivå 1) + - For hver entitet: bestem System-of-Record, Begrepseier, Dataforvalter + - Bygg `4.informasjonsarkitektur/masterdata-og-eierskap.md` + `informasjonsdomener.md` +- **Målarkitektur:** + - Skisser to-be-arkitektur basert på funn + - Identifiser anbefalte komponenter (MDM, integrasjonsplattform, datakatalog) + - Vurder hub-and-spoke der det gir mening +- **AI-rammeverk:** + - Operasjonelle prinsipper, ikke arkitektur-spec + - Fyll ut `6.ai-rammeverk/*` +- **Personvern:** + - Privacy by Design-tiltak per domene (`5.personvern-og-sikkerhet/*`) + - Identifiser mangler og foreslå tiltak +- **Workshops for validering:** + - Masterdata-workshop med potensielle dataeiere + - Målarkitektur-workshop med IT-eierskap +- Skriv `4.informasjonsarkitektur/data-governance-prinsipper.md` + +**Delleveranse 2 (uke 5):** Målbilde + masterdata-modell + AI-rammeverk + GDPR-vurdering. Sammenstilling av mappe 4, 5, 6 + arkitekturskisser. Presenteres i workshop med beslutningskontakt og dataeiere. + +## Fase D — Forankring og overlevering (uke 6-7) + +**Mål:** Forankre anbefalingene, levere handlingsplan og governance-modell, klargjøre for neste fase. + +**Aktiviteter:** +- Bygg `7.standardisering-og-handlingsplan/*` — prioritert handlingsplan basert på Fase B-C +- Sammenstill `9.leveranser-og-oppsummeringer/executive-summary.md` +- Bygg `9.leveranser-og-oppsummeringer/sluttrapport.md` +- **Presentasjon for beslutningskontakt og hennes/hans linje** (90 min) +- Bredere intern forankring hos kunden (workshop eller leder-runde) +- Overlevering av alle leveranser (Nextcloud / SharePoint / kundens valgte plattform) +- Anbefalinger for videre fase (skissér mulig implementeringsfase som egen leveranse) + +**Sluttleveranse (uke 6-7):** Komplett leveransesett, inkludert Executive Summary (standalone for ledelse) og Sluttrapport (5-delt). + +## Møtekadens + +| Møte | Frekvens | Deltakere | Varighet | +|---|---|---|---| +| Standup Forte-team | Daglig | Forte-team internt | 15 min | +| Statusmøte med beslutningskontakt | Ukentlig | + 1 fra kunden | 30 min | +| Workshop / intervju | Per behov | Forte + relevant rolle | 60-120 min | +| Styringspunkt | Fase-overgang | Forte + beslutningskontakt | 60 min | + +## Forutsetninger (jf. Standard slide 16) + +- Beslutningskontakt eller utpekt stedfortreder tilgjengelig for rask respons +- 8-12 nøkkelpersoner tilgjengelige for 1-2 timers intervju i Fase B +- Dedikert kontakt hos kundens utviklingspartner (om aktuelt) +- 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 + +## Metodisk fundament + +- **Startklar** — Fortes egen metodikk for data readiness (`Salg/Startklar.pdf`) +- **Personvern by design** — GDPR som premiss, ikke etterarbeid +- **Hub-and-spoke der det gir mening** — fra DNK-erfaring, ikke et obligatorisk valg +- **Funn først, anbefaling etterpå** — ingen tiltak uten dokumentert grunnlag diff --git a/artefakter/domenemodell-skjema.md b/artefakter/domenemodell-skjema.md new file mode 100644 index 0000000..4481eef --- /dev/null +++ b/artefakter/domenemodell-skjema.md @@ -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 + +### + +**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* diff --git a/artefakter/integrasjonslandskap.md b/artefakter/integrasjonslandskap.md new file mode 100644 index 0000000..099c992 --- /dev/null +++ b/artefakter/integrasjonslandskap.md @@ -0,0 +1,66 @@ +--- +title: "Integrasjonslandskap — " +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* diff --git a/artefakter/risikoregister.md b/artefakter/risikoregister.md new file mode 100644 index 0000000..a961b3a --- /dev/null +++ b/artefakter/risikoregister.md @@ -0,0 +1,70 @@ +--- +title: "Risikoregister — " +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* diff --git a/artefakter/workshop-agenda.md b/artefakter/workshop-agenda.md new file mode 100644 index 0000000..5198a47 --- /dev/null +++ b/artefakter/workshop-agenda.md @@ -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*