> For the complete documentation index, see [llms.txt](https://docs.cerrix.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cerrix.com/cerrix-documentation-no/cerrix-funksjoner/module-overview/business-improvement-management/measures-of-improvement-mois.md).
# Forbedringstiltak (MoI-er)
{% hint style="info" %}
**Videoopplæring**
Foretrekker du å se i stedet for å lese? Ta en titt på vår [Videoveiledninger](/cerrix-documentation-no/beste-praksiser-og-guider/video-tutorials.md#measures-of-improvement-mois).
{% endhint %}
MOI-modulen er utformet for å håndtere gjentakende problemer eller ineffektive kontroller ved å implementere korrigerende tiltak. Denne modulen sikrer at forbedringer blir gjennomført og vurdert effektivt.
### Introduksjon
Measures of Improvement (MoIs) er CERRIXs måte å gjøre problemer om til løsninger. Når testing avdekker svakheter i kontrollen, når avvik oppstår, eller når revisjoner finner funn, sørger MoI-er for at disse funnene fører til konkrete forbedringer i stedet for bare rapporter.
MoI-er gir strukturert oppfølging fra identifisering til løsning, med tydelig ansvar og fullstendige revisjonsspor.
#### Hvorfor MoI-er er viktige
Uten strukturert oppfølging av forbedringer blir funn og problemer dokumentert, men aldri løst. MoI-er forhindrer dette ved å:
* Skape ansvar gjennom rollefordeling
* Håndheve frister og fremdriftssporing
* Gi oversikt over forbedringsprogrammer
* Generere revisjonsbevis for korrigerende tiltak
* Lukke kretsen fra problemidentifisering til implementering av løsning
#### Hvordan MoI-er henger sammen med andre moduler
MoI-er kan for eksempel opprettes fra:
* **Risikoer** – Når risikovurderingen identifiserer nødvendige forbedringer
* **Kontroll** – Når design av kontrollen trenger forbedring
* **Avvik** – Når rotårsaksanalyse identifiserer forebyggende tiltak
* **Funnrapporter** – Når revisjoner krever korrigerende tiltak
* **MoI Workspace -** En MoI av hvilken som helst type kan opprettes, unntatt en Avvik-MoI
Denne integrasjonen betyr at problemer som identifiseres hvor som helst i CERRIX, automatisk flyter inn i strukturert oppfølging av forbedringer.
***
### Roller i forbedringsstyring
Hver MoI har tydelig definerte roller, hver med spesifikke ansvar i forbedringsprosessen.
#### Ansvarlig
Den ansvarlige eier forbedringstiltaket. Denne personen:
* Planlegger og gjennomfører forbedringen
* Oppdaterer fremdrift og status
* Laster opp bevis på fullføring
* Flytter MoI-en fra "Pågår" til "Klar for godkjenning"
* Sikrer at tiltaket overholder fristen
**Velg noen med:** Direkte operativ myndighet, nødvendige ressurser, relevant ekspertise
#### Stedfortreder
Stedfortrederen bistår den ansvarlige. De kan:
* Utføre spesifikke oppgaver som er tildelt dem
* Laste opp støttedokumentasjon
* Legge til kommentarer og oppdateringer
* Arbeide med forbedringen sammen med den ansvarlige
**Viktig:** Stedfortredere kan ikke endre MoI-status eller lukke den. Det endelige ansvaret ligger fortsatt hos den ansvarlige.
#### Reviewer
Reviewer validerer at forbedringene er riktig implementert. De:
* Gjennomgår bevis levert av den ansvarlige
* Verifiserer at forbedringene oppfyller det opprinnelige kravet
* Godkjenner tiltak ved å markere dem som "Godkjent"
* Avviser utilstrekkelige tiltak og sender dem tilbake til "Pågår"
* Sikrer kvalitet før MoI-en kan lukkes
**Velg noen med:** Uavhengighet fra gjennomføringen, teknisk kunnskap til å vurdere kvalitet, myndighet til å kreve omarbeiding
#### Revisor
Revisoren gir overordnet kontroll med hele forbedringsprosessen. De vil vanligvis:
* Opprette MoI-er basert på revisjonsfunn eller testfeil
* Overvåke fremdriften på tvers av flere forbedringer
* Lukke MoI-er etter godkjenning fra Reviewer
* Vedlikeholde revisjonssporet
* Rapportere om effektiviteten til forbedringsprogrammet
**Merk:** Ikke alle MoI-er krever en revisor. Denne rollen er mest vanlig for revisjonsdrevne forbedringer.
***
### Opprette en ny MoI
{% embed url="" %}
#### Hvor MoI-er kan opprettes
MoI-er kan opprettes fra flere steder. De vanligste er:
**Fra en Risiko:**
1. Åpne risikoen
2. Gå til **Risiko MoI** fanen
3. Klikk **Legg til MoI**
**Fra en Kontroll:**
1. Åpne kontrollen
2. Gå til **Kontrollforbedrings-MoI** fanen
3. Klikk **Legg til MoI**
**Fra et Avvik:**
1. Åpne avviket
2. Gå til **Administrer lenker** fanen via  ikonet i fanebaren:
3. Klikk **Opprett MoI**
**Fra en Funnrapport:**
1. Åpne funnrapporten
2. Gå til **Koblede forbedringstiltak** fanen
3. Klikk **Legg til MoI**
**Fra MOI Workspace:**
1. Velg "Legg til ny moi" i MoI Workspace. En popup vises.
2. Velg en av alternativene for kildetype, for eksempel Risiko eller MoI for forbedringsstyring (forbedringsstyring = Funnrapport), og velg deretter ett av elementene i listen som vises.
3. Klikk **Kildekobling**
Siden for å opprette MoI er den samme uansett hvor du starter, men kildelinken opprettes automatisk.
{% hint style="info" %}
**Avvik-MoI-er opprettes alltid fra avviket, ikke fra MoI Workspace**
Når du starter en ny MoI fra MoI Workspace, tilbyr ikke kildevalget lenger avvik som kildetype. Popup-vinduet for kildevalg viser en forklarende merknad over kildefeltet: *"MoI-er for avvik kan opprettes fra detaljsiden for avvik"*.
For å opprette en Avvik-MoI, åpne selve avviket, gå til **Administrer lenker** fanen som beskrevet ovenfor. De andre kildetypene (risiko, kontroll, Testplan og Funnrapport) påvirkes ikke.
{% endhint %}
#### Trinn for opprettelse
Når skjemaet for å opprette MoI åpnes, gå gjennom disse seksjonene:
**Kjerneinformasjon**
**Navn** – Gi MoI-en et tydelig, handlingsorientert navn som beskriver hva som skal forbedres.
**Emne** – Velg kategorien som best beskriver denne forbedringen (f.eks. tilgangskontroll, databeskyttelse, testprosess).
**Prioritet** – Vurder hvor presserende det er:
* **Høy** – Kritiske problemer, regulatoriske krav, betydelige risikoer
* **Middels** – Viktige forbedringer, moderat påvirkning
* **Lav** – Forbedringer som er fine å ha, mindre problemer
**Implementeringsscore** – Vurder nåværende implementering på en skala fra 1 til 5:
* **1** – Ikke implementert i det hele tatt
* **2** – Delvis definert, ikke operativ
* **3** – Implementert, men inkonsekvent
* **4** – I stor grad implementert og fungerer
* **5** – Fullt implementert og effektiv
> 💡 **Tips:** Implementeringsscoren hjelper deg med å følge fremdriften. Oppdater den etter hvert som arbeidet fortsetter for å vise forbedring.
**Planlegging**
**Startdato** – Når arbeidet starter. Dette hjelper med ressursplanlegging og tidslinjerapportering.
**Forfallsdato** – Frist for fullføring. Vær realistisk, men passende presis. Vurder:
* Regulatoriske frister
* Risikoens alvorlighetsgrad
* Ressurstilgjengelighet
* Avhengighet av annet arbeid
**Rollefordeling**
**Ansvarlig** – Personen som skal gjennomføre denne forbedringen. Vedkommende må ha myndighet og ressurser til å implementere tiltaket.
**Stedfortreder** – Valgfritt. Noen som skal bistå den ansvarlige. Nyttig for store forbedringer som krever flere personer.
**Reviewer** – Hvem som skal validere at forbedringen er riktig implementert. Velg noen med passende teknisk kunnskap og uavhengighet.
**Revisor** – Valgfritt. Brukes ofte når MoI-en kommer fra et revisjonsfunn. Revisoren gir overordnet kontroll og lukker MoI-en etter godkjenning.
> ⚠️ **Viktig:** Ikke tildel samme person som både ansvarlig og Reviewer. Dette skaper en interessekonflikt og svekker kvalitetskontrollen.
**Detaljer**
**Beskrivelse av funnet** – Beskriv problemet eller gapet som trenger forbedring. Vær konkret om hva som er galt og hvorfor det er viktig.
**Eksempel:** "Gjeldende passordpolicy tillater passord på bare 6 tegn uten krav til kompleksitet. Dette skaper sårbarhet for brute force-angrep og oppfyller ikke kravene i ISO 27001."
**Anbefaling** – Spesifiser nøyaktig hva som skal gjøres for å håndtere funnet.
**Eksempel:** "Oppdater passordpolicyen slik at den krever minimum 12 tegn med kompleksitetskrav (store bokstaver, små bokstaver, tall, spesialtegn). Implementer systemhåndheving og brukerinformasjon."
**Ledelsens respons** – Dokumenter ledelsens standpunkt til funnet og foreslått tiltak.
**Eksempel:** "Ledelsen er enig i anbefalingen og vil implementere den oppdaterte passordpolicyen innen utgangen av 2. kvartal. IT-sikkerhet vil lede implementeringen med støtte fra kommunikasjonsteamet for brukervarsling."
**Kommentarer** – Eventuell tilleggsinformasjon, avhengigheter eller hensyn.
**Kobling**
**Forretningsdimensjoner** – Koble MoI-en til relevante prosesser, avdelinger eller prosjekter. Dette muliggjør målrettet rapportering.
**Koblede risikoer** – Koble til risikoer som vil reduseres av denne forbedringen.
**Koblede Kontroller** – Koble til kontroller som vil bli styrket av denne forbedringen.
**Dokumenter** – Legg ved støttende bevis, analyse eller referansemateriale.
Disse koblingene skaper sporbarhet som viser hvorfor forbedringen er viktig og hva den påvirker.
#### Lagring av MoI-en
Etter at du har fylt ut alle seksjonene, klikker du på **lagrer**.
MoI-en er nå opprettet og synlig i MoI Workspace. Den ansvarlige vil motta et varsel om tildelingen sin.
***
### MoI-arbeidsflyt
{% embed url="" %}
Å forstå MoI-arbeidsflyten hjelper deg å vite hva du skal gjøre i hvert trinn og hva som skjer videre.
#### Statusprogresjon
**1. Ubekreftet**
* MoI-en er opprettet
* Tildelt den ansvarlige
* Venter på at den ansvarlige skal bekrefte at vedkommende vil utføre den
* **Handling kreves:** Den ansvarlige gjennomgår og aksepterer tildelingen
**2. Pågår**
* Den ansvarlige har akseptert tildelingen
* Arbeidet er i gang
* Bevis samles inn
* **Handling kreves:** Den ansvarlige gjennomfører forbedringen, laster opp bevis, oppdaterer fremdriften
**3. Klar for godkjenning**
* Den ansvarlige har fullført arbeidet
* Bevis er lastet opp
* Venter på validering fra Reviewer
* **Handling kreves:** Reviewer vurderer kvalitet og bevis
**4. Godkjent / Avvist**
* **Godkjent:** Reviewer bekrefter at forbedringen er tilfredsstillende
* **Avvist:** Reviewer finner at forbedringen er utilstrekkelig
* **Handling kreves (hvis avvist):** Den ansvarlige tar tak i tilbakemeldingen og sender inn på nytt
**5. Lukket**
* Forbedringen er fullført og verifisert
* Revisoren (eller systemet) har lukket MoI-en
* Tiltaket er nå en del av det permanente revisjonssporet
* **Ingen videre handling kreves**
#### Statusoverganger
Bare visse roller kan endre status:
* **Ansvarlig → Revisor/System:** Ubekreftet → Pågår
* **Ansvarlig:** Pågår → Klar for godkjenning
* **Reviewer:** Klar for godkjenning → Godkjent eller Avvist
* **Reviewer:** Avvist → Pågår
* **Revisor:** Godkjent → Lukket
Disse begrensningene sikrer riktig tilsyn og hindrer at forbedringer blir lukket for tidlig.
***
### Låsing av arbeidsflyt og obligatoriske trinn
MoI-arbeidsflyten begrenser bevisst hva som kan endres i hver status. Denne delen forklarer hvilke trinn som er obligatoriske, når en MoI blir låst, og hvordan man håndterer dokumenter som kommer inn etter godkjenning.
#### Det kreves en kommentar ved hver arbeidsflytendring
Hver arbeidsflytovergang krever en kommentar: et popup-vindu vises der du skriver inn en begrunnelse før statusendringen lagres. Dette gjelder både når den ansvarlige flytter MoI-en videre, og når Reviewer godkjenner eller avviser den. Alle kommentarer vises i kommentaroversikten for MoI-en.
I samme popup-vindu kan du valgfritt oppdatere to sammendragsindikatorer:
* **Fremdrift** — skyveknappen beveger seg i trinn på 5 %. Du kan også sette fremdriften tilbake til en lavere verdi.
* **Gjennomførbarhet** — indikerer hvor gjennomførbar anbefalingen er. De tilgjengelige alternativene (for eksempel Ingen, Lav, Middels og Høy) kan defineres av administratoren din i grunndata.
#### Hva som fortsatt kan endres i "Klar for godkjenning"
Mens MoI-en har statusen **Klar for godkjenning**, kan den ansvarlige fortsatt legge til nye kommentarer og endre eller fjerne sine egne kommentarer. MoI-en er ennå ikke låst på dette tidspunktet — den venter på Reviewers beslutning.
#### Godkjente MoI-er er låst
Når Reviewer trykker på **Godkjenn**, blir alle skrivealternativer for den ansvarlige opphevet. Kommentarer kan ikke lenger justeres og dokumenter kan ikke lenger lastes opp — dette gjelder også administratorer og den tildelte Reviewer eller Stedfortrederen. Dette er tilsiktet: statusen Godkjent betyr at MoI-en er gjennomgått, godkjent og formelt lukket i kvalitetsløpet. Låsing sikrer at MoI-en forblir en uforanderlig post over det som ble godkjent, noe som støtter revisjonsspor og etterlevelseskrav.
#### Legge til dokumenter etter godkjenning
Hvis ytterligere dokumentasjon fortsatt må vedlegges en godkjent MoI, må du først **lukke** MoI-en og deretter **gjenåpne** den, og legge til en kort kommentar som forklarer at ekstra dokumenter ble lagt til. MoI-en gjenåpnes med sin sist kjente status.
{% hint style="info" %}
Å gjenåpne og godkjenne en MoI på nytt utløser vanligvis e-postvarsler til Reviewer. For å unngå forvirring kan du midlertidig deaktivere disse: gå til **Dashboard → Administrasjonskontroller → E-postmeldinger** og under **Forbedringsarbeid**, deaktiver utløserne for **Closed**, **Gjenåpne** og **Godkjent**. Aktiver dem igjen når du er ferdig med opplastingen.
{% endhint %}
#### Fasen "Ubekreftet" kan ikke hoppes over
Den **Ubekreftet** fasen er en fast del av MoI-arbeidsflyten. Det er ikke mulig å utelate eller hoppe over den: hver MoI må først bekreftes av den ansvarlige før den kan gå til "Pågår".
### Arbeide med MoI-er
#### Som den ansvarlige
Når du er tildelt som ansvarlig:
1. **Gå gjennom tildelingen** – Forstå hva som kreves, innen når, og hvordan suksess ser ut
2. **Bekreft aksept** – Endre status fra "Ubekreftet" til "Pågår"
3. **Gjennomfør forbedringen** – Utfør arbeidet som er angitt i anbefalingen
4. **Dokumenter fremdriften** – Legg til kommentarer og last opp bevis etter hvert som du går frem
5. **Send inn for gjennomgang** – Når det er fullført, endre status til "Klar for godkjenning"
#### Som Reviewer
Når en MoI når "Klar for godkjenning":
1. **Gjennomgå bevisene** – Kontroller opplastede dokumenter og fullføringsnotater
2. **Verifiser implementeringen** – Bekreft at forbedringen faktisk adresserer det opprinnelige funnet
3. **Ta en beslutning:**
* **Godkjenn** hvis forbedringen er tilfredsstillende → Status blir "Godkjent"
* **Avvis** hvis mer arbeid er nødvendig → Status går tilbake til "Pågår" med tilbakemelding
#### Som revisor
Når en MoI er "Godkjent":
1. **Utfør endelig verifisering** – Sørg for at alle krav er oppfylt
2. **Gjennomgå revisjonssporet** – Kontroller at riktig prosess ble fulgt
3. **Lukk MoI-en** – Endre status til "Lukket"
#### Sporingshistorikk
Historikkfanen viser:
* Alle statusendringer
* Hvem som gjorde hver endring og når
* Kommentarer som er lagt til gjennom hele prosessen
* Dokumentopplastinger
* Tilbakemeldinger fra Reviewer
Dette fullstendige revisjonssporet dokumenterer aktsomhet og støtter bevis for etterlevelse.
***
### Slette, gjenopprette og koble MoI-er på nytt
MoI-er opprettes alltid fra et overordnet objekt, for eksempel en kontroll, et avvik eller en funnrapport. Denne koblingen avgjør også hvordan MoI-er slettes og gjenopprettes: disse handlingene skjer på nivået til det overordnede objektet, ikke på selve MoI-en.
#### Slette en MoI
{% hint style="info" %}
Det finnes ikke noe slettealternativ i alternativmenyen til selve MoI-en. For å slette en MoI, gå til objektet MoI-en er koblet til og slett den derfra.
{% endhint %}
**Slette en MoI for kontroll** — åpne kontrollen MoI-en er koblet til, og slett MoI-en inne i den kontrollen.
**Slette en MoI for funnrapport:**
1. Åpne funnrapporten MoI-en er knyttet til. Du kan navigere dit direkte, eller bla ned i MoI-en og åpne funnrapporten derfra.
2. Velg MoI-en(e) du vil slette.
3. Bruk **slett MoI-er** knappen for å fjerne dem.
**Andre MoI-er** — for MoI-er som ikke kan slettes gjennom det overordnede objektet deres, tilbyr CERRIX for øyeblikket ikke slettefunksjonalitet i applikasjonen. I så fall kan du **lukke** MoI-en når den ikke lenger er nødvendig, eller kontakte CERRIX-support hvis du haster med å få slettet en MoI fra miljøet ditt. Gi oss beskjed om nøyaktig hvilke MoI-er som må slettes, så kan DevOps-teamet vårt hjelpe med det.
#### Gjenopprette en slettet MoI
En slettet MoI kan gjenopprettes via oversikten over slettede elementer. Dette fungerer imidlertid bare så lenge det overordnede objektet fortsatt finnes.
{% hint style="warning" %}
Hvis kontrollen en MoI tilhører også er slettet, vil MoI-en ikke vises i oversikten over slettede elementer. Det finnes ingen mulighet til å gjenopprette MoI-en uten å gjenopprette kontrollen først.
{% endhint %}
For å gjenopprette en MoI der den overordnede kontrollen også ble slettet:
1. Gjenopprett først kontrollen fra Slettede elementer.
2. MoI-en blir deretter synlig i oversikten over slettede elementer og kan gjenopprettes.
#### Endre den koblede kontrollen eller funnrapporten
Det overordnede objektet til en eksisterende MoI kan ikke endres. Hvis en MoI er koblet til feil kontroll eller funnrapport, er løsningen å slette MoI-en og opprette en ny mot det riktige objektet:
1. Kopier innholdet i MoI-en slik at du kan gjenbruke det.
2. Slett MoI-en (se Slette en MoI ovenfor).
3. Opprett en ny MoI fra riktig kontroll eller funnrapport og skriv inn innholdet på nytt.
{% hint style="info" %}
Alternativt kan CERRIX koble MoI-er på nytt for deg som fakturerbart arbeid. Kontakt CERRIX-support hvis du ønsker å diskutere dette alternativet.
{% endhint %}
### Hva MoI-en arver fra det overordnede objektet
Hver MoI opprettes fra et overordnet objekt — en risiko, kontroll, avvik eller funnrapport — og noen av egenskapene følger direkte fra dette overordnede objektet.
#### Rammeverksdimensjon
Når en MoI opprettes fra en risiko, kontroll eller avvik, arves **Rammeverksdimensjon** Rammeverksdimensjonen fra det overordnede objektet. Feltet vises gråtonet i MoI-en fordi det gjenspeiler hva det overordnede objektet er koblet til, i stedet for å være satt på MoI-nivå — dette er tilsiktet, ikke et rettighetsspørsmål.
For å gi en MoI en bestemt Rammeverksdimensjon, kobler du denne dimensjonen til **det overordnede objektet**: det overordnede objektets Rammeverksdimensjoner følger med til MoI-ene. Hvis dimensjonen du trenger ikke allerede er på det overordnede objektet, legg den til der først og opprett deretter MoI-en.
#### Koblebare risikoer og kontroller på MoI-er for funnrapporter
En MoI opprettet fra en funnrapport kan kobles til risikoer og kontroller fra enhver Organisasjon, forutsatt at du har visningsrettigheter på disse elementene. Når du åpner koblingsskjermen, er organisasjonsfilteret forhåndsinnstilt til Organisasjonen til MoI-en (inkludert underorganisasjonene). Bruk avansert filter for å søke etter organisasjon, forretningsdimensjoner og rammeverksdimensjoner, eller etter tekst som Identifier, navn, eier eller beskrivelse, for å finne elementer i andre Organisasjoner. Koblede elementer forblir alltid synlige for brukere med visningsrettigheter på MoI-en. Hvis et element du forventer mangler fra listen, sjekk om du har visningsrettigheter på det.
### Beste praksis
#### Opprette effektive MoI-er
**Vær konkret i beskrivelsene** – Vage funn fører til vage forbedringer. "Forbedre sikkerheten" er ubrukelig. "Implementer MFA for alle privilegerte kontoer innen 2. kvartal" er handlingsorientert.
**Bruk SMART-kriterier:**
* **Spesifikt** – Nøyaktig hva som skal forbedres
* **Målbart** – Hvordan du vil vite at det er ferdig
* **Oppnåelig** – Realistisk gitt ressursene
* **Relevant** – Tar faktisk tak i Funn
* **Tidsavgrenset** – Tydelig frist
**Kobling til kilde** – Knytt alltid MoI-er til Risiko, Avvik eller Funn som utløste dem. Dette skaper sporbarhet.
**Legg til dokumentasjon tidlig og ofte** – Vent ikke til alt er ferdig. Last opp dokumenter underveis for å vise pågående arbeid.
#### Sette realistiske frister
**Vurder kompleksiteten** – Enkle prosessendringer kan ta uker. Systemimplementeringer kan ta måneder.
**Ta hensyn til avhengigheter** – Hvis du trenger budsjettgodkjenning, anskaffelse fra leverandør eller utvikling av opplæring, må du ta høyde for disse tidsrammene.
**Legg inn en buffer** – Uventede forsinkelser skjer. Legg inn en tidsbuffer.
**Respekter regulatoriske frister** – Hvis en regulator krever utbedring innen en bestemt dato, jobb bakover fra den fristen.
#### Å gi god tilbakemelding
Når du avviser et MoI, vær konstruktiv:
**Dårlig:** "Ikke godt nok, gjør det på nytt."
**Bra:** "Passordpolicy-dokumentet er oppdatert, men systemhåndhevingen er ikke implementert ennå. Vennligst samarbeid med IT for å konfigurere Active Directory slik at de nye kravene håndheves, og send deretter inn på nytt med dokumentasjon på håndhevingen."
Spesifikk tilbakemelding hjelper Ansvarlig part med å forstå nøyaktig hva som trengs.
#### Å lukke loopen
Etter at et MoI er lukket:
* Oppdater den tilhørende Risiko-scoren for å gjenspeile redusert risiko
* Oppdater vurderingene av Kontroll-effektivitet
* Dokumenter læringspunkter for fremtidige forbedringer
* Vurder om testing er nødvendig for å bekrefte varig implementering
MoI-er er ikke fullført før forbedringen er integrert i driften og verifisert gjennom testing.
***
### Rapportering og analyse
#### Bruk av MoI-data
MoI-Workspace og rapporteringsfunksjonene lar deg analysere forbedringsprogrammet ditt:
**Statusoversikt** – Hvor mange MoI-er er åpne, under arbeid eller forfalte?
**Arbeidsmengde for Ansvarlig part** – Hvem har flest tildelte forbedringer?
**Prioritetsfordeling** – Fokuserer vi på høyprioriterte saker?
**Tid til ferdigstillelse** – Hvor lang tid tar det vanligvis å lukke MoI-er?
**Avvisningsgrad** – Hvor stor andel av MoI-er krever omarbeiding?
Disse måleverdiene hjelper deg med å:
* Identifisere flaskehalser i forbedringsprosessen
* Allokere ressurser effektivt
* Forbedre tiden til løsning
* Demonstrere forbedringsprogrammets effektivitet for interessenter
#### Vanlige rapporter
**Forfalte MoI-er** – Kritisk for ledelsens oppmerksomhet
**Åpne elementer med høy prioritet** – Viser det mest presserende arbeidet
**MoI-er etter kilde** – Forstå hvilke Risikoer/Avvik/Funn som genererer flest forbedringer
**Trender for fullføringsgrad** – Blir vi bedre til å lukke forbedringer?
***
### Øvelser
#### Øvelse 1: Opprett et MoI
1. Naviger til Risiko Workspace
2. Åpne enhver Risiko som mangler tilstrekkelige Kontroller
3. Klikk på **Risiko MoI** fanen
4. Klikk **Legg til MoI**
5. Fyll ut alle obligatoriske felter:
* Navn: "Implementer kvartalsvise sikkerhetsvurderinger av leverandører"
* Prioritet: Høy
* Ansvarlig: Tildel til deg selv
* Reviewer: Tildel til en kollega
* Forfallsdato: om 90 dager
* Funnbeskrivelse: Beskriv gapet
* Anbefaling: Spesifiser forbedringen
6. Koble til forretningsdimensjoner
7. Klikk **lagrer**
#### Øvelse 2: Fremdrift gjennom Workflow
Ved å bruke MoI-et du opprettet:
1. Åpne MoI-et fra MoI-Workspace
2. Endre status fra "Ubekreftet" til "Under arbeid"
3. Legg til en kommentar som beskriver implementeringsplanen din
4. Last opp et eksempel-dokument som dokumentasjon (hvilket som helst dokument til øving)
5. Oppdater implementeringsscoren for å vise fremdrift
6. Endre status til "Klar for godkjenning"
7. (Hvis du øver med en kollega) Be dem gjennomgå og gi tilbakemelding
8. Gå gjennom Historikk-fanen for å se Revisjonssporet ditt
#### Øvelse 3: Gjennomgå MoI-rapportering
1. Gå tilbake til MoI-Workspace
2. Bruk et filter for å vise bare "Under arbeid" MoI-er
3. Sorter etter forfallsdato for å identifisere frister som nærmer seg
4. Opprett en forhåndsinnstilling kalt "Mine aktive MoI-er" som viser elementer der du er Ansvarlig
5. Eksporter den filtrerte listen til Excel
6. Gå gjennom de eksporterte dataene for å forstå hvilke felt som er tilgjengelige
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.cerrix.com/cerrix-documentation-no/cerrix-funksjoner/module-overview/business-improvement-management/measures-of-improvement-mois.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
