Sådan opbygger du en modenhedsmodel for dit partnernetværk

Anmodningen står ofte på én linje i et bestyrelsesnotat: Udvikl en modenhedsmodel for vores partnere. En medarbejder i sekretariatet åbner et regneark, skriver fem overskrifter fra Grundlæggende til Fremragende og begynder at udfylde felterne. Uger senere taler ingen om ledelse eller digitale færdigheder på medlemsmødet. De taler om, hvorvidt et medlem er „godt“ eller „meget godt“, og hvem der har besluttet det.

Det er sjældent arbejdsindsatsen, der er problemet; det er rækkefølgen på beslutningerne. Denne guide viser, hvordan du opbygger en modenhedsmodel for et partnernetværk i otte trin, fra formål til den første revision, med en gratis skabelon på fire sider, et udfyldt eksempel for et fiktivt forbund og de fejl, jeg ville undgå.

Hvad en modenhedsmodel er, og hvor idéen kom fra

I november 1986 begyndte Software Engineering Institute ved Carnegie Mellon University at udvikle en ramme for procesmodenhed som svar på en anmodning om at give den amerikanske forbundsregering en måde at vurdere sine softwareleverandørers kapacitet på. I 1993 var den blevet til Capability Maturity Model for Software, hvis fem modenhedsniveauer med SEI’s egne ord „definerer en ordinal skala“ [1].

Grundformen er den samme: en række niveauer, der beskriver en forventet, ønsket eller typisk udviklingsvej i afgrænsede trin [2]. Hvert niveau angiver, hvad der skal være på plads for at nå det, så en vurdering placerer en organisation på vejen og viser det næste skridt. I 2005 fandtes der over 150 modenhedsmodeller inden for områder lige fra IT-tjenester til vidensstyring [3], men da Becker, Knackstedt og Pöppelbuß undersøgte 51 af dem, var det kun ni, der dokumenterede deres designproces i detaljer [2]. Det følgende er metoden fra den forskning, tilpasset programteams.

Sådan opbygger du en modenhedsmodel i otte trin

Trinnene følger de faser, de Bruin, Rosemann, Freeze og Kulkarni foreslog til udvikling af enhver modenhedsmodel: afgrænsning, design, udarbejdelse, afprøvning, implementering og vedligeholdelse [3]. Hver beslutning sætter rammerne for den næste, og pilotafprøvningen vil få dig til at omskrive beskrivelserne mindst én gang.

1. Beslut, hvad modellen skal bruges til

Før du fastlægger niveauer, skal du skrive ned, hvilke beslutninger modellen skal understøtte. Forskningen skelner mellem tre anvendelser [3][4]: En deskriptiv model viser, hvor hver partner står i dag; en præskriptiv model viser også, hvad man skal gøre som det næste; en komparativ model sammenligner partnere eller regioner, hvilket kræver mange vurderinger og meget stabile kriterier. De fleste partnernetværk har brug for de to første.

Svar på samme side på, hvem der udfylder den (partneren alene, sammen med jer eller med jeres godkendelse), hvor ofte det sker, og hvad den aldrig vil blive brugt til. Efter min erfaring bidrager den sidste linje mere til ærlige svar end nogen instruktion. Hvis medlemmerne har mistanke om, at modellen afgør deres medlemskab eller tilskud, vil de vurdere sig selv højt, og modellen vil beskrive et netværk, der ikke findes.

2. Vælg dimensionerne

Dimensioner er de temaer, modellen dækker: ledelse, økonomi, digitale færdigheder, beskyttelse og unges deltagelse. Hold antallet lavt for at begrænse kompleksiteten og holde dimensionerne uafhængige (de Bruin og kollegers to modeller havde henholdsvis seks og fire hovedkomponenter), og sørg for, at de er gensidigt udelukkende og tilsammen udtømmende [3]: Ingen dokumentation bør tælle to gange, og intet, som formålet kræver, må mangle. Jeg sigter efter fire til syv dimensioner, opdelt i to eller tre underdimensioner, hvor et tema er bredt.

Før du skriver din egen model, så se på, hvad der allerede findes: Becker og kolleger fastslog, at sammenligning med eksisterende modeller er det første krav til udviklingen af en ny [2]. Inden for kapacitetsstyrkelse er McKinseys syv elementer fra 2001-modellen for Venture Philanthropy Partners et godt udgangspunkt [5], ligesom de seks domæner i vores guide til vurdering af partnerkapacitet.

3. Vælg fire eller fem niveauer

CMM bruger fem niveauer [1]; McKinsey-modellen bruger fire [5]. Antallet er mindre vigtigt end det krav, de Bruin og kolleger formulerer: Faserne skal være forskellige og klart definerede med en logisk progression, og hver fase skal have en kort betegnelse, der signalerer dens formål [3].

Min tommelfingerregel stammer fra operationsanalyse: Et niveau fortjener kun sin plads, hvis du kan beskrive det med dokumentation og skelne det fra de tilstødende niveauer. Tæl de tilstande, du faktisk kan observere i dit netværk, og stop så. Antallet kan også stige: Becker og kolleger begyndte deres model for IT-resultater med fire faser og gik efter interviews med IT-chefer op til seks – fra „ikke-eksisterende“ til „optimeret“ – for at skelne mellem de svageste tilfælde [2]. Og beskriv det nederste niveau som et udgangspunkt, ikke som en dom: „Udforsker“ åbner en samtale; „Mangelfuld“ lukker den.

4. Beskriv hvert niveau som en tilstand, du kan observere

Det er her, de fleste modeller fejler. En beskrivelse er teksten i et felt i modellen. Pöppelbuß og Röglinger regner kriterier, der kan verificeres intersubjektivt, blandt principperne for design af en brugbar modenhedsmodel: Beskrivelserne skal være så præcise og tydelige, at man kan skelne ét niveau fra det næste [4]. Kort sagt: To personer, der ser på den samme partner, bør vælge det samme felt.

Tre gode vaner hjælper:

• Beskriv noget, du kan se eller holde i hånden: et dokument, en rutine, en rolle eller et tal. Undgå „god“, „stærk“, „tilstrækkelig“ og „effektiv“.
• Ændr én ting ad gangen. Hvis niveau 3 på én gang kræver et budget, en ansvarlig og en årlig gennemgang, har en partner med to af de tre ingen passende placering.
• Lad niveauerne bygge oven på hinanden. Hvert trin bør omfatte de krav, der gælder for niveauerne nedenunder [3]. En test fra mine dage med operationsanalyse: Prøv at forestille dig en partner, hvor niveau 3 er opfyldt, men niveau 2 ikke er. Hvis du kan det, er rækkefølgen forkert, eller feltet hører til en anden dimension.

5. Definér dokumentationen for hvert niveau

Skriv for hvert felt, hvad der kan dokumentere det: en politik, et referat, en rapport eller et tal. Kræv kun let dokumentation på de lavere niveauer og mere omfattende dokumentation på de øverste, hvor påstandene er større, og angiv, hvem der leverer den, og hvem der bekræfter den. Bed aldrig om dokumentation, ingen vil læse: Hvert dokument koster partneren tid, der ellers kunne bruges på arbejdet.

6. Validér modellen med partnere

Vis udkastet til de mennesker, der skal arbejde med modellen. De Bruin og kolleger brugte Delphi-metoden og fokusgrupper til at udvikle og kontrollere deres modeller [3]; McKinsey afprøvede sin model med næsten et dusin direktører for nonprofitorganisationer [5]; version 1.1 af CMM blev til på baggrund af feedback fra en workshop om version 1.0 med omkring 200 softwarefagfolk [1]. I et partnernetværk kan du begynde med en workshop på to timer med otte til ti forskellige partnere. Spørg: Kan I genkende jer selv? Er det jeres sprog? Hvad mangler? Er noget ydmygende?

7. Afprøv og kalibrér

Afprøv modellen i praksis med tre til fem partnere. De Bruin og kolleger understreger, at instrumentet skal testes for validitet og pålidelighed, så resultaterne er nøjagtige og kan gentages [3]. Den praktiske udgave: To personer vurderer den samme partner uafhængigt af hinanden, og enhver uenighed peger på en beskrivelse, der skal omskrives. Hvis alle pilotpartnere ender på niveau 2, skelner niveauerne ikke godt nok; hvis ingen kan forestille sig at nå niveau 4, er det en ønskeliste. En skala, der placerer alle i samme kasse, giver ingen information.

8. Styr ændringer, og foretag nye vurderinger

Becker og kolleger bemærker, at alle modenhedsmodeller bliver forældede, efterhånden som forhold, teknologi og viden udvikler sig, og at de nødvendige ændringer bør indarbejdes i en ny modelversion [2]. Behandl din model som en standard: et versionsnummer, ét årligt tidsrum for ændringer, en ændringslog med oplysninger om, hvad der er ændret og hvorfor, og ingen redigeringer midt i en vurderingsrunde. Når version 1.1 ændrer et felt, skal du forklare, hvordan placeringer fra version 1.0 videreføres, så ingen partner går et niveau ned, fordi du har omskrevet en sætning. Foretag derefter en ny vurdering hver 6. til 12. måned. Du kan læse om, hvordan du gennemfører disse runder, og hvorfor du aldrig bør beregne et gennemsnit af niveauerne til én samlet score, i vores guide til vurdering af partnerkapacitet.

Skabelon til en modenhedsmodel for partnere (gratis download)

Skabelonen omsætter de otte trin til fire A4-sider: formål og afgrænsning; dimensioner og niveauer; beskrivelsesmodellen med en test af beskrivelserne og noter om kalibrering; samt planen for dokumentation, validering og versionslog.

Download skabelonen til opbygning af en modenhedsmodel (PDF, 4 sider). Print den til en designworkshop, eller kopiér afsnittene.

Eksempel: Et forbunds digitale modenhedsforløb for medlemmer

Her er skabelonen udfyldt for Meridian Youth Federation, et fiktivt forbund med 26 nationale medlemsorganisationer.

Download det udfyldte eksempel (PDF, 4 sider). Fire valg er værd at kopiere:

• Formålet afgrænser anvendelsen. Modellen hjælper med at afgøre, hvem der først får kollegial sparring, og hvad den digitale støttefond betaler for; den bruges aldrig til at afgøre medlemsstatus eller rangordning.
• Fire niveauer efter afprøvning af fem. Ingen kunne dokumentere en forskel mellem de to mellemniveauer i det første udkast, så det femte niveau blev fjernet.
• Seks områder fordelt på tre temaer. Et medlem kan være på niveauet Går foran inden for onlineinddragelse og Udforsker inden for databeskyttelse, og det er netop den profil, forbundet har brug for at se.
• Pilotafprøvningen ændrede formuleringerne. To bedømmere fortolkede „poster regelmæssigt“ som henholdsvis hver uge og hver måned, så niveau 2 for onlineinddragelse blev ændret til „en indholdskalender med kanaler for hver målgruppe“.

Almindelige fejl, når man opbygger en modenhedsmodel

1. At skrive niveauerne før formålet. Uden en beslutning, modellen skal understøtte, glider den over i en rangordning, og partnerne behandler den sådan.
2. At forveksle spørgeskemaet med modellen. SEI erfarede det med sit eget modenhedsspørgeskema fra 1987, som folk alt for ofte opfattede som selve modellen [1]. Modellen er udviklingsvejen; et spørgeskema er én måde at måle den på.
3. Tillægsord i stedet for observerbare tilstande. „Tilstrækkelig“ betyder noget forskelligt for hver bedømmer.
4. For mange dimensioner. Fyrre indikatorer giver en model, ingen får færdig.
5. At designe modellen til partnerne i stedet for sammen med dem. Et niveau 1, der er formuleret som en liste over fejl, lærer partnerne at skjule dem.
6. At ændre modellen midt i en runde. Én redigeret beskrivelse gør denne runde usammenlignelig med den forrige.

Opbyg din modenhedsmodel i Advancer.World

Advancer.World blev skabt på baggrund af den digitale transformation af programmer hos organisationer som UNICEF og Airbus, og et program på platformen har samme grundform som en modenhedsmodel: Trinnene er dine niveauer, emnerne og underemnerne dine dimensioner, og hvert felt indeholder en beskrivelse.

Trinnene mellem felterne indeholder det, partneren skal bruge for at komme videre: anmodninger om at uploade dokumenter som dokumentation, spørgeskemaer, initiativer og anmodninger om elektronisk underskrift. Du vælger for hvert program, hvordan partnerne bevæger sig frem: gennem selvevaluering, automatisk når det foregående trin er fuldført eller først, når dit team bekræfter det. Dit team kan redigere designet sammen i realtid. Partnerne kan se, hvor de står, og hvad det næste niveau kræver af dem, på et hvilket som helst af 22 sprog, og de kan aldrig se andre partneres data. Daglige øjebliksbilleder gemmer historikken, så rapporterne viser, hvordan netværket har rykket sig fra én runde til den næste.

Ofte stillede spørgsmål

Hvor mange niveauer bør en modenhedsmodel have?

Fire eller fem for de fleste partnernetværk. Det afgørende er, at hvert niveau er særskilt, veldefineret og et logisk trin op fra niveauet nedenunder [3]. Hvis bedømmerne ikke kan skelne mellem to niveauer i pilotprojektet, så slå dem sammen.

Hvor lang tid tager det at udvikle en modenhedsmodel?

Regn med to til tre måneder på en første version: et par uger til formål, dimensioner og niveauer, nogle uger mere til beskrivelser og dokumentation og derefter partnerworkshoppen og et pilotprojekt. Genveje ender med en anden version, som ingen har afsat budget til.

Kan vi tilpasse en eksisterende modenhedsmodel i stedet for at udvikle en selv?

Ofte ja, og det bør være det første, I undersøger [2]. Tjek licensen, behold strukturen, hvis den passer til jeres formål, og omskriv beskrivelserne, så de bruger jeres netværks sprog.

Kan en partner være på forskellige niveauer inden for forskellige dimensioner?

Ja, og det er som regel tilfældet; den profil er modellens mest nyttige resultat. En partner bør dog ikke springe niveauer over inden for én dimension, hvilket CMM's ophavspersoner også fremhævede om deres egne niveauer [1].

Begynd med formålet, ikke niveauerne

Hvis du kun tager én ting med fra denne vejledning, så lad det være rækkefølgen. Beskriv formålet på én side, bliv enige om det sammen med et par partnere, og åbn først derefter skemaet. En model, der udvikles på den måde, tager længere tid at komme i gang med, men er langt nemmere at forsvare.

Referencer

1. Mark C. Paulk, Bill Curtis, Mary Beth Chrissis and Charles V. Weber, Software Engineering Institute, Carnegie Mellon University, "Capability Maturity Model for Software, Version 1.1" (CMU/SEI-93-TR-024), February 1993, https://www.sei.cmu.edu/library/capability-maturity-model-for-software-version-11/ (tilgået oktober 2026).
2. Jörg Becker, Ralf Knackstedt and Jens Pöppelbuß, "Developing Maturity Models for IT Management: A Procedure Model and its Application", Business & Information Systems Engineering, 1(3), 2009, pp. 213-222, https://doi.org/10.1007/s12599-009-0044-5 (tilgået oktober 2026).
3. Tonia de Bruin, Michael Rosemann, Ronald Freeze and Uday Kulkarni, "Understanding the Main Phases of Developing a Maturity Assessment Model", 16th Australasian Conference on Information Systems (ACIS), Sydney, 2005, https://aisel.aisnet.org/acis2005/109 (tilgået oktober 2026).
4. Jens Pöppelbuß and Maximilian Röglinger, "What Makes a Useful Maturity Model? A Framework of General Design Principles for Maturity Models and its Demonstration in Business Process Management", Proceedings of the 19th European Conference on Information Systems (ECIS 2011), June 2011, https://aisel.aisnet.org/ecis2011/28/ (tilgået oktober 2026).
5. McKinsey & Company for Venture Philanthropy Partners, "Effective Capacity Building in Nonprofit Organizations", 2001, https://www.bridgespan.org/getmedia/ef1ff943-173b-48ec-843a-b5ce85c6c807/effective-capacity-building-VPP.pdf (tilgået oktober 2026).

© 2026 Mourinho Solutions. Alle rettigheder forbeholdes.