Slik bygger du en modenhetsmodell for partnernettverket ditt

Forespørselen dukker ofte opp som én linje i et saksdokument til styret: utvikle en modenhetsmodell for partnerne våre. Noen i sekretariatet åpner et regneark, skriver inn fem overskrifter, fra Grunnleggende til Fremragende, og begynner å fylle ut cellene. Flere uker senere, på medlemsmøtet, diskuterer ingen styring eller digitale ferdigheter. De diskuterer om et medlem er «godt» eller «svært godt», og hvem som har bestemt det.

Det er sjelden arbeidsmengden som er problemet; det er rekkefølgen på beslutningene. Denne veiledningen viser hvordan du bygger en modenhetsmodell for et partnernettverk i åtte trinn, fra formål til første revisjon, med en gratis mal på fire sider, et utfylt eksempel for et fiktivt forbund og feilene jeg ville unngått.

Hva en modenhetsmodell er, og hvor ideen kom fra

I november 1986 begynte Software Engineering Institute ved Carnegie Mellon University å utvikle et rammeverk for prosessmodenhet, som svar på en forespørsel om å gi amerikanske føderale myndigheter en metode for å vurdere programvareleverandørenes kapasitet. I 1993 var rammeverket blitt Capability Maturity Model for Software, der de fem modenhetsnivåene, med SEIs egne ord, «definerer en ordinal skala» [1].

Grunnformen er den samme: en rekke nivåer som beskriver en forventet, ønsket eller typisk utviklingsvei, i avgrensede trinn [2]. Hvert nivå sier hva som må være på plass for å nå det, slik at en vurdering plasserer en organisasjon på veien og viser neste trinn. I 2005 fantes det over 150 modenhetsmodeller, på områder fra IT-tjenester til kunnskapsforvaltning [3]. Men da Becker, Knackstedt og Pöppelbuß undersøkte 51 av dem, var det bare ni som dokumenterte designprosessen i detalj [2]. Metoden fra denne forskningen, tilpasset programteam, er beskrevet nedenfor.

Slik bygger du en modenhetsmodell i åtte trinn

Trinnene følger fasene de Bruin, Rosemann, Freeze og Kulkarni foreslo for utvikling av alle typer modenhetsmodeller: avgrensing, design, utfylling, testing, innføring og vedlikehold [3]. Hver beslutning legger føringer for den neste, og piloteringen vil få deg til å skrive om beskrivelsene minst én gang.

1. Bestem hva modellen skal brukes til

Før du definerer nivåer, bør du skrive ned hvilke beslutninger modellen skal danne grunnlag for. Forskningen skiller mellom tre bruksområder [3][4]: en beskrivende modell viser hvor hver partner står i dag; en normativ modell viser også hva de bør gjøre videre; en sammenlignende modell sammenligner partnere eller regioner, noe som krever mange vurderinger og svært stabile kriterier. De fleste partnernettverk har behov for de to første.

Skriv også ned hvem som fyller ut modellen (partneren alene, sammen med dere eller med deres godkjenning), hvor ofte den fylles ut, og hva den aldri skal brukes til. Min erfaring er at den siste linjen bidrar mer til ærlige svar enn noen instruksjon. Hvis medlemmene mistenker at modellen avgjør medlemskapet eller tilskuddet deres, vil de gi seg selv høy vurdering, og modellen vil beskrive et nettverk som ikke finnes.

2. Velg dimensjonene

Dimensjoner er temaene modellen dekker: styring, økonomi, digitale ferdigheter, beskyttelse mot overgrep og skade, ungdomsmedvirkning. Begrens antallet for å holde kompleksiteten nede og dimensjonene uavhengige (de Bruin og kollegene brukte seks og fire hovedkomponenter i sine to modeller), og sørg for at de er gjensidig utelukkende og samlet sett uttømmende [3]: Ingen dokumentasjon bør telles to ganger, og ingenting som formålet krever, bør mangle. Jeg sikter mot fire til sju dimensjoner, delt inn i to eller tre underdimensjoner når et tema er bredt.

Før du skriver din egen modell, bør du undersøke hva som allerede finnes: Becker og kollegenes første krav til utvikling av en ny modell er å sammenligne med eksisterende modeller [2]. For kapasitetsstyrking er de sju elementene i McKinseys modell fra 2001 for Venture Philanthropy Partners et godt utgangspunkt [5], og det samme gjelder de seks områdene i vår veiledning for vurdering av partnerkapasitet.

3. Velg fire eller fem nivåer

CMM bruker fem nivåer [1]; McKinsey-modellen bruker fire [5]. Antallet er mindre viktig enn kravet de Bruin og kollegene beskriver: trinnene må være tydelige og veldefinerte, ha en logisk progresjon og hver ha en kort etikett som signaliserer hensikten [3].

Min regel bygger på operasjonsanalyse: Et nivå fortjener bare en plass hvis du kan beskrive det med dokumentasjon og skille det fra nabonivåene. Tell tilstandene du faktisk kan observere i nettverket ditt, og stopp der. Antallet kan også øke: Becker og kollegene startet modellen for IT-ytelse med fire trinn, men utvidet den til seks etter intervjuer med IT-ledere, fra «ikke-eksisterende» til «optimalisert», for å skille mellom svakere tilfeller [2]. Og beskriv det nederste nivået som et utgangspunkt, ikke en dom: «Utforsker» åpner for en samtale; «Mangelfull» avslutter den.

4. Beskriv hvert nivå som en observerbar tilstand

Det er her de fleste modeller mislykkes. En nivåbeskrivelse er teksten i én celle i modellen. Pöppelbuß og Röglinger regner kriterier som kan verifiseres på tvers av personer, blant designprinsippene for en nyttig modenhetsmodell: Beskrivelsene må være presise og tydelige nok til å skille ett nivå fra det neste [4]. Enkelt sagt: To personer som ser på den samme partneren, bør velge den samme cellen.

Tre gode vaner er til hjelp:

• Beskriv noe du kan se eller ta på: et dokument, en rutine, en rolle, et tall. Unngå «god», «sterk», «tilstrekkelig» og «effektiv».
• Endre én ting om gangen. Hvis nivå 3 samtidig legger til et budsjett, en ansvarlig person og en årlig gjennomgang, har ikke en partner som oppfyller to av de tre, noe naturlig nivå.
• La nivåene bygge på hverandre. Hvert trinn bør omfatte det kravene på lavere nivåer innebærer [3]. En test fra tiden min med operasjonsanalyse: Se for deg en partner som oppfyller nivå 3, men ikke nivå 2. Hvis det går, er rekkefølgen feil, eller så hører cellen til en annen dimensjon.

5. Definer dokumentasjonen for hvert nivå

Skriv for hver celle hva som kan dokumentere at kravet er oppfylt: en policy, et referat, en rapport, et tall. Be om lite dokumentasjon på de lavere nivåene og mer på toppen, der kravene er større, og angi hvem som skal levere den og hvem som skal bekrefte den. Ikke be om dokumentasjon ingen kommer til å lese: Hvert dokument tar tid fra partneren, tid som kunne vært brukt på arbeidet deres.

6. Valider modellen med partnerne

Vis utkastet til dem som skal bruke modellen. De Bruin og kollegene brukte Delphi-metoden og fokusgrupper til å utvikle og kvalitetssikre modellene sine [3]; McKinsey testet sin modell med nesten et dusin daglige ledere i ideelle organisasjoner [5]; versjon 1.1 av CMM ble til etter tilbakemeldinger fra en workshop om versjon 1.0, med rundt 200 programvarefagfolk [1]. For et partnernettverk kan du begynne med en to timer lang workshop med åtte til ti ulike partnere. Spør: Kjenner dere dere igjen? Er dette deres språk? Hva mangler? Er noe nedverdigende?

7. Pilotér og kalibrer

Bruk modellen i praksis med tre til fem partnere. De Bruin og kollegene understreker at verktøyet må testes for validitet og reliabilitet, slik at resultatene er nøyaktige og kan gjentas [3]. I praksis betyr det at to personer vurderer samme partner uavhengig av hverandre, og at hver uenighet peker på en beskrivelse som bør skrives om. Hvis alle partnerne i piloteringen havner på nivå 2, skiller ikke nivåene godt nok; hvis ingen kan se for seg å nå nivå 4, er det en ønskeliste. En skala som plasserer alle i samme boks, gir ingen informasjon.

8. Styr endringer og vurder på nytt

Becker og kollegene påpeker at alle modenhetsmodeller blir utdaterte når forhold, teknologi og kunnskap endrer seg, og at nødvendige endringer bør innarbeides i en ny versjon av modellen [2]. Behandle modellen som en standard: Bruk et versjonsnummer, åpne for endringer én gang i året, før en endringslogg med hva som er endret og hvorfor, og ikke gjør endringer midt i en vurderingsrunde. Når versjon 1.1 endrer en celle, bør du forklare hvordan plasseringer fra versjon 1.0 overføres, slik at ingen partner går ned et nivå fordi du har skrevet om en setning. Gjennomfør deretter en ny vurdering hver 6. til 12. måned. Du finner en veiledning til gjennomføringen av disse rundene, og en forklaring på hvorfor du aldri bør slå nivåene sammen til én poengsum, i vår veiledning for vurdering av partnerkapasitet.

Mal for modenhetsmodell for partnere (gratis nedlasting)

Malen gjør de åtte trinnene om til fire A4-sider: formål og avgrensing; dimensjoner og nivåer; rutenettet med nivåbeskrivelser, en test av beskrivelsene og kalibreringsnotater; samt en plan for dokumentasjon og validering og en versjonslogg.

Last ned malen for å bygge en modenhetsmodell (PDF, 4 sider). Skriv den ut til en designworkshop, eller kopier delene.

Eksempel: Medlemmenes digitale modenhetsløp i et forbund

Her er malen utfylt for Meridian Youth Federation, et fiktivt forbund med 26 nasjonale medlemsorganisasjoner.

Last ned det utfylte eksemplet (PDF, 4 sider). Fire valg er verdt å kopiere:

• Formålet utelukker noe. Modellen brukes til å avgjøre hvem som først får kollegaveiledning, og hva fondet for digital støtte finansierer; den brukes aldri til å fastsette medlemsstatus eller rangeringer.
• Fire nivåer etter at fem ble prøvd. Ingen kunne dokumentere forskjellen mellom de to mellomnivåene i det første utkastet, så det femte nivået ble fjernet.
• Seks områder under tre temaer. Et medlem kan være Ledende innen engasjement på nett og Utforsker innen personvern, og det er nettopp en slik profil forbundet trenger å se.
• Piloteringen endret ordlyden. To vurderere tolket «publiserer jevnlig» som henholdsvis ukentlig og månedlig, så nivå 2 for engasjement på nett ble endret til «en innholdskalender med kanaler for hvert publikum».

Vanlige feil når du bygger en modenhetsmodell

1. Å skrive nivåene før du har definert formålet. Uten en beslutning modellen skal danne grunnlag for, glir den over i en rangering, og partnerne behandler den som en.
2. Å forveksle spørreskjemaet med modellen. SEI erfarte dette med sitt eget modenhetsspørreskjema fra 1987, som folk altfor ofte behandlet som selve modellen [1]. Modellen er utviklingsveien; spørreskjemaet er én måte å måle den på.
3. Adjektiver i stedet for observerbare tilstander. «Tilstrekkelig» betyr noe forskjellig for hver vurderer.
4. For mange dimensjoner. Førti indikatorer gir en modell ingen fullfører.
5. Å utforme modellen for partnerne i stedet for sammen med dem. Et nivå 1 som er skrevet som en liste over feil, lærer partnerne å skjule dem.
6. Å endre modellen midt i en runde. Én redigert beskrivelse gjør denne runden umulig å sammenligne med den forrige.

Bygg modenhetsmodellen din i Advancer.World

Advancer.World oppsto gjennom den digitale transformasjonen av programmer i organisasjoner som UNICEF og Airbus, og et program i plattformen har samme struktur som en modenhetsmodell: Trinnene er nivåene dine, temaene og undertemaene er dimensjonene dine, og hver celle inneholder en beskrivelse.

Trinnene mellom cellene inneholder det en partner trenger for å komme videre: forespørsler om å laste opp dokumentasjon, spørreundersøkelser, tiltak og forespørsler om e-signatur. Du velger for hvert program hvordan partnerne går videre: gjennom egenvurdering, automatisk når forrige trinn er fullført, eller først når teamet ditt bekrefter det. Teamet ditt kan redigere utformingen sammen i sanntid. Partnerne ser hvor de står og hva neste nivå krever av dem, på ett av 22 språk, og får aldri se data fra andre partnere. Daglige øyeblikksbilder bevarer historikken, slik at rapportene viser hvordan nettverket har utviklet seg mellom rundene.

Ofte stilte spørsmål

Hvor mange nivåer bør en modenhetsmodell ha?

Fire eller fem for de fleste partnernettverk. Det viktige er at hvert nivå er tydelig atskilt, godt definert og et logisk steg opp fra nivået under [3]. Hvis de som vurderer ikke klarer å skille mellom to nivåer i pilotprosjektet, bør dere slå dem sammen.

Hvor lang tid tar det å utvikle en modenhetsmodell?

Sett av to til tre måneder til en første versjon: noen uker til formål, dimensjoner og nivåer, noen uker til beskrivelser og dokumentasjon, og deretter partnerworkshop og pilot. Snarveier fører til en versjon nummer to som ingen har satt av budsjett til.

Kan vi tilpasse en eksisterende modenhetsmodell i stedet for å utvikle en selv?

Ofte, ja, og det bør være det første dere undersøker [2]. Sjekk lisensen, behold strukturen hvis den passer formålet, og skriv om beskrivelsene slik at de bruker språket i nettverket deres.

Kan en partner være på ulike nivåer i forskjellige dimensjoner?

Ja, og det er som regel tilfelle; denne profilen er det mest nyttige resultatet av modellen. En partner bør imidlertid ikke hoppe over nivåer innenfor én dimensjon, et poeng CMM-forfatterne trakk fram om sine egne nivåer [1].

Begynn med formålet, ikke nivåene

Hvis du bare tar med deg én ting fra denne veiledningen, la det være rekkefølgen. Beskriv formålet på én side, bli enige om det sammen med noen partnere, og åpne først deretter matrisen. En modell som bygges på denne måten, tar lengre tid å komme i gang med, men langt kortere tid å forsvare.

Referanser

1. Mark C. Paulk, Bill Curtis, Mary Beth Chrissis og Charles V. Weber, Software Engineering Institute, Carnegie Mellon University, «Modenhetsmodell for programvare, versjon 1.1» (CMU/SEI-93-TR-024), februar 1993, https://www.sei.cmu.edu/library/capability-maturity-model-for-software-version-11/ (hentet oktober 2026).
2. Jörg Becker, Ralf Knackstedt og Jens Pöppelbuß, «Utvikling av modenhetsmodeller for IT-styring: En prosedyremodell og dens anvendelse», Business & Information Systems Engineering, 1(3), 2009, s. 213–222, https://doi.org/10.1007/s12599-009-0044-5 (hentet oktober 2026).
3. Tonia de Bruin, Michael Rosemann, Ronald Freeze og Uday Kulkarni, «Forstå de viktigste fasene i utviklingen av en modell for modenhetsvurdering», 16th Australasian Conference on Information Systems (ACIS), Sydney, 2005, https://aisel.aisnet.org/acis2005/109 (hentet oktober 2026).
4. Jens Pöppelbuß og Maximilian Röglinger, «Hva kjennetegner en nyttig modenhetsmodell? Et rammeverk med generelle designprinsipper for modenhetsmodeller og en demonstrasjon innen forretningsprosessledelse», Proceedings of the 19th European Conference on Information Systems (ECIS 2011), juni 2011, https://aisel.aisnet.org/ecis2011/28/ (hentet oktober 2026).
5. McKinsey & Company for Venture Philanthropy Partners, «Effektiv kapasitetsbygging i ideelle organisasjoner», 2001, https://www.bridgespan.org/getmedia/ef1ff943-173b-48ec-843a-b5ce85c6c807/effective-capacity-building-VPP.pdf (hentet oktober 2026).

© 2026 Mourinho Solutions. Med enerett.