Så bygger du en mognadsmodell för ditt partnernätverk

Uppdraget dyker ofta upp som en enda rad i ett styrelseunderlag: ta fram en mognadsmodell för våra partner. Någon på sekretariatet öppnar ett kalkylblad, skriver in fem rubriker från Grundläggande till Utmärkt och börjar fylla i rutorna. Veckor senare, på medlemsmötet, diskuterar ingen styrning eller digital kompetens. I stället pratar man om huruvida en medlem är ”bra” eller ”mycket bra” – och vem som bestämde det.

Det är sällan arbetsinsatsen som är problemet, utan ordningen på besluten. Den här guiden visar hur du bygger en mognadsmodell för ett partnernätverk i åtta steg, från syfte till den första revideringen. Här finns en kostnadsfri mall på fyra sidor, ett ifyllt exempel för en fiktiv federation och misstagen jag skulle undvika.

Vad är en mognadsmodell och varifrån kommer idén?

I november 1986 började Software Engineering Institute vid Carnegie Mellon University utveckla ett ramverk för processmognad. Det skedde som svar på en begäran om att ge USA:s federala regering ett sätt att bedöma kapaciteten hos dess programvaruleverantörer. År 1993 hade ramverket blivit Capability Maturity Model for Software, vars fem mognadsnivåer, med SEI:s egna ord, ”definierar en ordinalskala” [1].

Grundformen består än i dag: en följd nivåer som beskriver en förväntad, önskad eller typisk utvecklingsväg i avgränsade steg [2]. Varje nivå anger vad som måste vara uppfyllt för att nå den, så en bedömning placerar en organisation längs utvecklingsvägen och visar nästa steg. År 2005 fanns det över 150 mognadsmodeller inom områden från IT-tjänster till kunskapshantering [3]. Men när Becker, Knackstedt och Pöppelbuß granskade 51 av dem hade bara nio dokumenterat sin designprocess i detalj [2]. Här följer metoden från den forskningen, anpassad för programteam.

Så bygger du en mognadsmodell i åtta steg

Stegen följer de faser som de Bruin, Rosemann, Freeze och Kulkarni föreslog för utveckling av alla slags mognadsmodeller: avgränsa, utforma, fylla i, testa, införa och förvalta [3]. Varje beslut sätter ramarna för nästa, och pilotprojektet kommer att få dig att skriva om beskrivningarna minst en gång.

1. Bestäm vad modellen ska användas till

Innan du börjar med nivåerna ska du skriva ner vilka beslut modellen ska bidra till. Forskningen skiljer mellan tre användningsområden [3][4]: en deskriptiv modell visar var varje partner befinner sig i dag; en preskriptiv modell visar också vad partnern ska göra härnäst; en komparativ modell jämför partner eller regioner, vilket kräver många bedömningar och mycket stabila kriterier. De flesta partnernätverk behöver de två första.

Skriv också ner vem som fyller i modellen (partnern själv, tillsammans med dig eller med din bekräftelse), hur ofta det görs och vad den aldrig kommer att användas till. Enligt min erfarenhet bidrar den sista punkten mer till ärliga svar än någon instruktion. Om medlemmarna misstänker att modellen avgör deras medlemskap eller bidrag kommer de att bedöma sig själva högt, och modellen beskriver då ett nätverk som inte finns.

2. Välj dimensioner

Dimensionerna är de teman som modellen omfattar: styrning, ekonomi, digital kompetens, skydd och ungas delaktighet. Håll dem få för att begränsa komplexiteten och se till att de är fristående (de Bruin och kollegornas två modeller hade sex respektive fyra huvudkomponenter). De ska också vara ömsesidigt uteslutande och tillsammans heltäckande [3]: ingen evidens ska räknas två gånger och inget som behövs för modellens syfte får saknas. Jag siktar på fyra till sju dimensioner, uppdelade i två eller tre underdimensioner när ett tema är brett.

Innan du skriver en egen modell bör du undersöka vad som redan finns. Becker och kollegor anger jämförelser med befintliga modeller som det första kravet när man tar fram en ny modell [2]. För kapacitetsstärkande arbete är de sju delarna i McKinseys modell från 2001 för Venture Philanthropy Partners en bra utgångspunkt [5], liksom de sex områdena i vår guide till bedömning av partnerkapacitet.

3. Välj fyra eller fem nivåer

CMM använder fem nivåer [1]; McKinsey-modellen använder fyra [5]. Antalet är mindre viktigt än kravet som de Bruin och kollegor ställer: stegen ska vara tydliga och väldefinierade, följa en logisk progression och ha korta namn som signalerar vad de innebär [3].

Min tumregel kommer från operationsanalys: en nivå förtjänar sin plats bara om du kan beskriva den med evidens och skilja den från nivåerna intill. Räkna de tillstånd som du faktiskt kan observera i nätverket och stanna där. Antalet kan också öka: Becker och kollegor började med fyra steg i sin modell för IT-prestanda och utökade till sex efter intervjuer med IT-chefer, från ”obefintlig” till ”optimerad”, för att kunna skilja ut de svagare fallen [2]. Beskriv dessutom den lägsta nivån som en startpunkt, inte en dom: ”Utforskar” öppnar för samtal; ”Bristfällig” avslutar det.

4. Beskriv varje nivå som ett tillstånd du kan observera

Det är här de flesta modeller fallerar. En beskrivning är texten i en ruta i modellen. Pöppelbuß och Röglinger räknar kriterier som kan verifieras mellan bedömare bland principerna för en användbar mognadsmodell: beskrivningarna ska vara tillräckligt precisa och tydliga för att man ska kunna skilja en nivå från nästa [4]. Enkelt uttryckt: två personer som tittar på samma partner ska välja samma ruta.

Tre vanor hjälper:

• Nämn något du kan se eller hålla i: ett dokument, en rutin, en roll eller en siffra. Undvik ”bra”, ”stark”, ”tillräcklig” och ”effektiv”.
• Ändra en sak i taget. Om nivå 3 samtidigt lägger till en budget, en ansvarig och en årlig översyn har en partner som uppfyller två av tre inget självklart alternativ.
• Gör nivåerna kumulativa. Varje steg ska omfatta det som krävs på nivåerna under [3]. Ett test från mina år inom operationsanalys: försök föreställa dig en partner som uppfyller nivå 3 men inte nivå 2. Om det går är ordningen fel, eller så hör rutan till en annan dimension.

5. Definiera evidensen för varje nivå

Skriv för varje ruta vad som kan styrka den: en policy, ett protokoll, en rapport eller en siffra. Håll kraven på evidens låga på de lägre nivåerna och ställ högre krav högre upp, där anspråken är större. Ange också vem som tillhandahåller underlaget och vem som bekräftar det. Be aldrig om evidens som ingen kommer att läsa: varje dokument tar tid från partnern som i stället kunde ägnas åt verksamheten.

6. Validera modellen med partner

Visa utkastet för dem som ska använda modellen. De Bruin och kollegor använde Delfimetoden och fokusgrupper för att ta fram och kontrollera sina modeller [3]; McKinsey testade sin modell med nästan ett dussin chefer för ideella organisationer [5]; version 1.1 av CMM togs fram efter synpunkter på version 1.0 från en workshop med omkring 200 yrkesverksamma inom programvaruutveckling [1]. Börja med en workshop på två timmar för åtta till tio partner med olika förutsättningar. Fråga: Känner ni igen er? Är det här ert språk? Vad saknas? Finns det något som känns förnedrande?

7. Genomför en pilot och kalibrera

Testa modellen i praktiken med tre till fem partner. De Bruin och kollegor betonar att verktyget måste testas med avseende på validitet och reliabilitet, så att resultaten blir korrekta och upprepningsbara [3]. I praktiken innebär det att två personer bedömer samma partner oberoende av varandra, och att varje oenighet pekar på en beskrivning som behöver skrivas om. Om alla partner i pilotprojektet hamnar på nivå 2 skiljer nivåerna inte tillräckligt åt; om ingen kan föreställa sig att nå nivå 4 är modellen en önskelista. En skala som placerar alla i samma ruta förmedlar ingen information.

8. Styr ändringar och gör nya bedömningar

Becker och kollegor konstaterar att alla mognadsmodeller åldras när förutsättningar, teknik och kunskap förändras, och att nödvändiga ändringar ska göras i en ny modellversion [2]. Behandla din modell som en standard: använd versionsnummer, ha ett årligt ändringsfönster, för en ändringslogg över vad som ändrats och varför och gör inga ändringar mitt under en bedömningsomgång. När version 1.1 ändrar en ruta ska du ange hur placeringar från version 1.0 förs över, så att ingen partner tappar en nivå för att du har formulerat om en mening. Gör sedan en ny bedömning var 6:e till 12:e månad. Läs mer om hur du genomför omgångarna och varför du aldrig ska slå ihop nivåerna till ett enda genomsnitt i vår guide till bedömning av partnerkapacitet.

Mall för partnermognadsmodell (kostnadsfri nedladdning)

Mallen omvandlar de åtta stegen till fyra A4-sidor: syfte och omfattning; dimensioner och nivåer; rutnätet med beskrivningar, ett test av beskrivningarna och kalibreringsanteckningar; samt en evidensplan, valideringsplan och versionslogg.

Ladda ner mallen för att skapa en mognadsmodell (PDF, 4 sidor). Skriv ut den inför en designworkshop eller kopiera avsnitten.

Exempel: en federations digitala mognadsresa för medlemmar

Här har mallen fyllts i för Meridian Youth Federation, en fiktiv federation med 26 nationella medlemsorganisationer.

Ladda ner det ifyllda exemplet (PDF, 4 sidor). Fyra val är värda att ta efter:

• Syftet utesluter något. Modellen avgör vilka som får kamratcoachning först och vad den digitala stödfonden finansierar; den används aldrig för medlemsstatus eller rankning.
• Fyra nivåer efter att fem hade testats. Ingen kunde belägga någon skillnad mellan de två mellannivåerna i det första utkastet, så den femte nivån togs bort.
• Sex områden under tre teman. En medlem kan vara på nivån Leder när det gäller engagemang online och på nivån Utforskar när det gäller dataskydd. Det är en sådan profil federationen behöver se.
• Pilotprojektet ändrade formuleringarna. Två bedömare tolkade ”publicerar regelbundet” som både varje vecka och varje månad. Därför ändrades nivå 2 för engagemang online till ”en innehållskalender med kanaler för varje målgrupp”.

Vanliga misstag när man bygger en mognadsmodell

1. Att formulera nivåerna innan syftet är klart. Utan ett beslut att bidra till glider modellen över i en rankning, och partner börjar behandla den som en sådan.
2. Att missta frågeformuläret för modellen. SEI stötte på det här med sitt eget mognadsformulär från 1987, som människor alltför ofta behandlade som själva modellen [1]. Modellen är utvecklingsvägen; ett frågeformulär är ett sätt att mäta den.
3. Värdeord i stället för observerbara tillstånd. ”Tillräcklig” betyder olika saker för olika bedömare.
4. För många dimensioner. Fyrtio indikatorer ger en modell som ingen hinner slutföra.
5. Att utforma modellen åt partner i stället för tillsammans med dem. En nivå 1 som är en lista över misslyckanden lär partner att dölja problem.
6. Att ändra modellen mitt i en omgång. En enda ändrad beskrivning gör den här omgången ojämförbar med den förra.

Bygg din mognadsmodell i Advancer.World

Advancer.World växte fram ur den digitala omställningen av program hos organisationer som UNICEF och Airbus. Ett program i plattformen har samma struktur som en mognadsmodell: stegen är dina nivåer, ämnena och underämnena dina dimensioner och varje ruta innehåller en beskrivning.

Stegen mellan rutorna innehåller det partner behöver för att ta sig vidare: begäranden om att ladda upp dokument som evidens, enkäter, initiativ och begäranden om e-signatur. Du väljer för varje program hur partner går vidare: genom självbedömning, automatiskt när föregående steg är klart eller först när ditt team har bekräftat det. Teamet kan redigera utformningen tillsammans i realtid. Partner ser var de befinner sig och vad nästa nivå kräver, på något av 22 språk, och kan aldrig se andra partners data. Dagliga ögonblicksbilder bevarar historiken, så rapporterna visar hur nätverket har utvecklats mellan bedömningsomgångarna.

Vanliga frågor

Hur många nivåer bör en mognadsmodell ha?

Fyra eller fem för de flesta partnernätverk. Det viktiga är att varje nivå är tydligt avgränsad, väl definierad och ett logiskt steg från nivån under [3]. Om bedömarna inte kan skilja två nivåer åt under pilotprojektet bör ni slå ihop dem.

Hur lång tid tar det att ta fram en mognadsmodell?

Räkna med två till tre månader för en första version: några veckor för syftet, dimensionerna och nivåerna, ytterligare några för beskrivningar och belägg, och därefter partnerworkshopen och en pilot. Genvägar leder till en andra version som ingen har budgeterat för.

Kan vi anpassa en befintlig mognadsmodell i stället för att bygga en egen?

Ofta, ja, och det är där ni bör börja [2]. Kontrollera licensen, behåll strukturen om den passar ert syfte och skriv om beskrivningarna på ert nätverks språk.

Kan en partner ligga på olika nivåer inom olika dimensioner?

Ja, och det gör partnern oftast; den profilen är modellens mest användbara resultat. En partner bör däremot inte hoppa över nivåer inom en och samma dimension, en poäng som CMM:s upphovspersoner gjorde om sina egna nivåer [1].

Börja med syftet, inte nivåerna

Om du tar med dig en enda sak från den här guiden, låt det vara ordningsföljden. Formulera syftet på en sida, stäm av det med några partner och öppna först därefter matrisen. En modell som byggs på det sättet tar längre tid att komma igång med, men betydligt kortare tid att försvara.

Referenser

1. Mark C. Paulk, Bill Curtis, Mary Beth Chrissis och Charles V. Weber, Software Engineering Institute, Carnegie Mellon University, ”Capability Maturity Model for Software, Version 1.1” (CMU/SEI-93-TR-024), februari 1993, https://www.sei.cmu.edu/library/capability-maturity-model-for-software-version-11/ (hämtad oktober 2026).
2. Jörg Becker, Ralf Knackstedt och Jens Pöppelbuß, ”Developing Maturity Models for IT Management: A Procedure Model and its Application”, Business & Information Systems Engineering, 1(3), 2009, s. 213–222, https://doi.org/10.1007/s12599-009-0044-5 (hämtad oktober 2026).
3. Tonia de Bruin, Michael Rosemann, Ronald Freeze och 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 (hämtad oktober 2026).
4. Jens Pöppelbuß och 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), juni 2011, https://aisel.aisnet.org/ecis2011/28/ (hämtad oktober 2026).
5. McKinsey & Company för 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 (hämtad oktober 2026).

© 2026 Mourinho Solutions. Med ensamrätt.