Näin rakennat kumppaniverkostollesi kypsyysmallin

Pyyntö tulee usein vastaan yhtenä rivinä hallituksen asiakirjassa: kehittäkää kumppaneillemme kypsyysmalli. Joku sihteeristössä avaa taulukkolaskentaohjelman, kirjoittaa viisi otsikkoa tasoista Perustaso erinomaiseen ja alkaa täyttää soluja. Viikkoja myöhemmin jäsenkokouksessa kukaan ei keskustele hallinnosta tai digitaidoista. Keskustelu koskee sitä, onko jäsen ”hyvä” vai ”erittäin hyvä” ja kuka sen päätti.

Ongelma ei yleensä ole työmäärä vaan päätösten järjestys. Tässä oppaassa näytän, miten kumppaniverkoston kypsyysmalli rakennetaan kahdeksassa vaiheessa tavoitteesta ensimmäiseen päivitykseen. Mukana on maksuton nelisivuinen pohja, täytetty esimerkki kuvitteellisesta liitosta sekä virheet, joita itse välttäisin.

Mikä kypsyysmalli on ja mistä ajatus on peräisin

Marraskuussa 1986 Carnegie Mellon Universityn Software Engineering Institute alkoi kehittää prosessien kypsyyskehystä vastauksena pyyntöön antaa Yhdysvaltain liittovaltion hallinnolle tapa arvioida ohjelmistotoimittajiensa valmiuksia. Vuoteen 1993 mennessä siitä oli kehittynyt Capability Maturity Model for Software, jonka viisi kypsyystasoa ”määrittelevät järjestysasteikon” SEI:n omin sanoin [1].

Perusmuoto on säilynyt: tasojen sarja kuvaa ennakoitua, tavoiteltua tai tavanomaista kehityspolkua erillisinä vaiheina [2]. Kukin taso määrittää, mitä sen saavuttaminen edellyttää. Arvioinnissa organisaatio sijoitetaan polulle, ja samalla nähdään seuraava askel. Vuoteen 2005 mennessä kypsyysmalleja oli yli 150, aloilla IT-palveluista tiedonhallintaan [3]. Kun Becker, Knackstedt ja Pöppelbuß tarkastelivat niistä 51:tä, vain yhdeksässä oli kuvattu mallin suunnitteluprosessi yksityiskohtaisesti [2]. Seuraavassa esitellään kyseiseen tutkimukseen perustuva menetelmä ohjelmatiimeille sovitettuna.

Kypsyysmallin rakentaminen kahdeksassa vaiheessa

Vaiheet noudattavat vaiheistusta, jota de Bruin, Rosemann, Freeze ja Kulkarni ehdottivat kaikkien kypsyysmallien kehittämiseen: rajaus, suunnittelu, sisältöjen määrittely, testaus, käyttöönotto ja ylläpito [3]. Kukin päätös rajaa seuraavaa, ja pilotin perusteella kuvauksia on kirjoitettava uudelleen ainakin kerran.

1. Päätä, mihin mallia käytetään

Kirjaa ennen tasojen määrittelyä, mihin päätöksiin mallilla haetaan tukea. Tutkimuksessa erotetaan kolme käyttötapaa [3][4]: kuvaileva malli näyttää, missä kukin kumppani on tällä hetkellä; ohjaava malli kertoo lisäksi, mitä seuraavaksi pitäisi tehdä; vertaileva malli vertailee kumppaneita tai alueita, mikä edellyttää lukuisia arviointeja ja hyvin vakaita kriteerejä. Useimmat kumppaniverkostot tarvitsevat kaksi ensimmäistä.

Vastaa samalla sivulla myös siihen, kuka täyttää mallin (kumppani yksin, yhdessä kanssasi vai sinun vahvistuksellasi), kuinka usein ja mihin sitä ei koskaan käytetä. Kokemukseni mukaan viimeinen kohta lisää rehellisyyttä enemmän kuin mikään ohje. Jos jäsenet epäilevät mallin vaikuttavan jäsenyyteensä tai avustukseensa, he antavat itselleen korkeat arvosanat, ja malli kuvaa verkostoa, jota ei ole olemassa.

2. Valitse ulottuvuudet

Ulottuvuudet ovat mallin kattamia teemoja: hallinto, talous, digitaidot, suojelu, nuorten osallistuminen. Pidä niitä vähän, jotta monimutkaisuus pysyy hallinnassa ja ulottuvuudet riippumattomina toisistaan (de Bruinin ja kollegoiden kahdessa mallissa oli kuusi ja neljä pääkomponenttia). Tee niistä lisäksi toisensa poissulkevia ja yhdessä kattavia [3]: mitään näyttöä ei pidä laskea kahdesti, eikä mitään tarkoituksen kannalta tarpeellista saa puuttua. Itse pyrin neljään seitsemään ulottuvuuteen ja jaan laajan teeman kahteen tai kolmeen alaulottuvuuteen.

Ennen oman mallin kirjoittamista tutustu olemassa oleviin malleihin: Becker ja kollegat asettivat vertailun olemassa oleviin malleihin uuden mallin kehittämisen ensimmäiseksi vaatimukseksi [2]. Valmiuksien vahvistamiseen McKinseyn Venture Philanthropy Partnersille vuonna 2001 laatiman ruudukon seitsemän osa-aluetta ovat hyvä lähtökohta [5], samoin kuin kumppanien valmiuksien arviointioppaamme kuusi osa-aluetta.

3. Valitse neljä tai viisi tasoa

CMM-mallissa on viisi tasoa [1], McKinseyn ruudukossa neljä [5]. Lukumäärää tärkeämpi on de Bruinin ja kollegoiden esittämä vaatimus: vaiheiden on oltava erillisiä ja selkeästi määriteltyjä, niiden etenemisjärjestyksen looginen ja jokaisella vaiheella on oltava sen tarkoitusta kuvaava lyhyt nimi [3].

Oma sääntöni on peräisin operaatiotutkimuksesta: taso ansaitsee paikkansa vain, jos sen voi kuvata näytön avulla ja erottaa viereisistä tasoista. Laske ne tilat, joita verkostossasi todella voi havaita, ja lopeta siihen. Tasojen määrä voi myös kasvaa: Becker ja kollegat aloittivat IT-suorituskykymallinsa neljällä tasolla, mutta siirtyivät IT-johtajien haastattelujen jälkeen kuuteen tasoon, ”olemattomasta” ”optimoituun”, jotta heikommat tapaukset erottuisivat toisistaan [2]. Kirjoita alin taso lähtökohdaksi, älä tuomioksi: ”Tutkiminen” avaa keskustelun, ”Puutteellinen” päättää sen.

4. Kuvaa kukin taso havaittavana tilana

Tässä useimmat mallit epäonnistuvat. Kuvaus on ruudukon yhden solun teksti. Pöppelbuß ja Röglinger lukevat hyödyllisen kypsyysmallin suunnitteluperiaatteisiin kriteerit, jotka ovat eri arvioijien todennettavissa: kuvausten on oltava riittävän tarkkoja ja selkeitä, jotta yhden tason voi erottaa seuraavasta [4]. Käytännössä tämä tarkoittaa, että samaa kumppania arvioivat kaksi ihmistä valitsevat saman solun.

Kolme käytäntöä auttaa:

• Nimeä asia, jonka voi nähdä tai jota voi pitää kädessään: asiakirja, rutiini, rooli tai luku. Kiellä sanat ”hyvä”, ”vahva”, ”riittävä” ja ”tehokas”.
• Muuta yhtä asiaa kerrallaan. Jos tasolla 3 lisätään yhtä aikaa budjetti, vastuuhenkilö ja vuosittainen arviointi, kumppanille, jolla on niistä kaksi, ei löydy sopivaa tasoa.
• Tee tasoista kumulatiivisia. Kunkin vaiheen tulee sisältää myös alempien vaiheiden vaatimukset [3]. Operaatiotutkimusvuosiltani peräisin oleva testi: yritä kuvitella kumppani, jolle taso 3 sopii mutta taso 2 ei. Jos se onnistuu, järjestys on väärä tai solu kuuluu toiseen ulottuvuuteen.

5. Määrittele näyttö jokaiselle tasolle

Kirjaa jokaiselle solulle, mikä osoittaa sen toteutuvan: käytäntö, pöytäkirja, raportti tai luku. Pidä näyttövaatimukset kevyinä alemmilla tasoilla ja tiukempina ylimmillä tasoilla, joilla väitteet ovat suurempia. Määritä myös, kuka toimittaa näytön ja kuka vahvistaa sen. Älä koskaan pyydä näyttöä, jota kukaan ei lue: jokainen asiakirja vie kumppanilta aikaa, joka voisi kulua sen varsinaiseen työhön.

6. Validoi malli kumppanien kanssa

Näytä luonnos niille, jotka tulevat käyttämään mallia. De Bruin ja kollegat hyödynsivät Delphi-menetelmää ja fokusryhmiä malliensa rakentamisessa ja tarkistamisessa [3]. McKinsey testasi ruudukkoaan lähes tusinalla voittoa tavoittelemattoman organisaation johtajalla [5]. CMM:n versiota 1.1 edelsi version 1.0 työpajasta saatu palaute; työpajaan osallistui noin 200 ohjelmistoalan ammattilaista [1]. Kumppaniverkostossa kannattaa aloittaa kahden tunnin työpajalla, johon osallistuu kahdeksasta kymmeneen erilaista kumppania. Kysy: Tunnistatteko itsenne? Onko tämä teidän käyttämäänne kieltä? Mitä puuttuu? Onko jokin nöyryyttävää?

7. Pilotointi ja kalibrointi

Kokeile mallia käytännössä kolmen tai viiden kumppanin kanssa. De Bruin ja kollegat korostavat välineen validiteetin ja luotettavuuden testaamista, jotta tulokset ovat tarkkoja ja toistettavia [3]. Käytännössä tämä tarkoittaa, että kaksi ihmistä arvioi saman kumppanin itsenäisesti ja jokainen erimielisyys osoittaa kuvauksen, joka pitää kirjoittaa uudelleen. Jos jokainen pilottikumppani sijoittuu tasolle 2, tasot eivät erottele kumppaneita. Jos kukaan ei osaa kuvitella saavuttavansa tasoa 4, kyseessä on toivelista. Asteikko, joka sijoittaa kaikki samaan lokeroon, ei tuota tietoa.

8. Hallitse muutoksia ja arvioi uudelleen

Becker ja kollegat huomauttavat, että kypsyysmallit vanhenevat olosuhteiden, teknologian ja tiedon muuttuessa. Tarvittavat muutokset on vietävä mallin uuteen versioon [2]. Käsittele malliasi standardina: versiotunnus, yksi päivitysikkuna vuodessa, muutosloki, jossa kerrotaan mitä muutettiin ja miksi, eikä muutoksia kesken arviointikierroksen. Kun versiossa 1.1 muutetaan solua, kerro, miten version 1.0 mukaiset sijoitukset siirretään, jotta kumppani ei putoa tasoa alemmas lauseen uudelleenkirjoituksen vuoksi. Arvioi sitten uudelleen 6–12 kuukauden välein. Ohjeet arviointikierrosten toteutukseen ja syyt siihen, miksi tasoja ei pidä koskaan keskiarvoistaa yhdeksi pistemääräksi, löytyvät kumppanien valmiuksien arviointioppaastamme.

Kumppanien kypsyysmallin pohja (maksuton lataus)

Pohja kokoaa kahdeksan vaihetta neljälle A4-sivulle: tavoite ja rajaus; ulottuvuudet ja tasot; kuvausruudukko kuvauksen testaamiseen ja kalibrointiin tarkoitetuilla huomioilla; sekä näyttösuunnitelma, validointisuunnitelma ja versioloki.

Lataa kypsyysmallin rakennuspohja (PDF, 4 sivua). Tulosta se suunnittelutyöpajaa varten tai kopioi sen osiot.

Esimerkki: liiton jäsenten digitaalisen kypsyyden polku

Tässä pohja on täytetty Meridian Youth Federationille, kuvitteelliselle liitolle, johon kuuluu 26 kansallista jäsenjärjestöä.

Lataa täytetty esimerkki (PDF, 4 sivua). Neljästä valinnasta kannattaa ottaa mallia:

• Tavoitteessa rajataan jokin käyttötarkoitus pois. Malli ohjaa sitä, ketkä saavat ensin vertaistukea ja mihin digitaalisen tuen rahastosta myönnetään rahoitusta. Sitä ei koskaan käytetä jäsenyyden määrittämiseen tai paremmuusjärjestyksen laatimiseen.
• Neljä tasoa viiden kokeilemisen jälkeen. Ensimmäisen luonnoksen kahta keskimmäistä tasoa ei pystynyt erottamaan toisistaan näytön avulla, joten viides taso poistettiin.
• Kuusi osa-aluetta kolmen teeman alla. Jäsen voi olla verkkovuorovaikutuksessa edelläkävijä ja tietosuojassa tutkimusvaiheessa. Juuri tällaisen profiilin liitto haluaa nähdä.
• Pilotti muutti sanamuotoja. Kaksi arvioijaa tulkitsi ilmauksen ”julkaisee säännöllisesti” eri tavoin: toinen viikoittaiseksi, toinen kuukausittaiseksi. Niinpä verkkovuorovaikutuksen tason 2 kuvaukseksi tuli ”sisältökalenteri, jossa on kullekin yleisölle omat kanavat”.

Yleisiä virheitä kypsyysmallin rakentamisessa

1. Tasojen kirjoittaminen ennen käyttötarkoituksen määrittelyä. Ilman päätöstä, johon mallilla haetaan tukea, se ajautuu paremmuusjärjestykseksi, ja kumppanit alkavat käsitellä sitä sellaisena.
2. Kyselyn sekoittaminen malliin. SEI törmäsi tähän oman vuoden 1987 kypsyyskyselynsä kanssa, jota ihmiset käsittelivät liian usein itse mallina [1]. Malli on polku; kysely on yksi tapa mitata sitä.
3. Adjektiiveja havaittavien tilojen sijaan. ”Riittävä” tarkoittaa eri arvioijille eri asioita.
4. Liian monta ulottuvuutta. Neljäkymmentä indikaattoria tuottaa mallin, jota kukaan ei saa valmiiksi.
5. Mallin suunnitteleminen kumppaneille heidän kanssaan suunnittelun sijaan. Epäonnistumisten luetteloksi kirjoitettu taso 1 opettaa kumppaneita salaamaan asioita.
6. Mallin muuttaminen kesken arviointikierroksen. Yhdenkin kuvauksen muokkaaminen tekee tästä kierroksesta vertailukelvottoman edellisen kanssa.

Kypsyysmallin rakentaminen Advancer.Worldissa

Advancer.World sai alkunsa UNICEF:n ja Airbusin kaltaisten organisaatioiden ohjelmien digitaalisesta muutoksesta. Ohjelma rakentuu kypsyysmallin tavoin: vaiheet ovat tasosi, aiheet ja ala-aiheet ulottuvuuksiasi ja kukin solu sisältää kuvauksen.

Soluja yhdistävät askeleet sisältävät kaiken, mitä kumppani tarvitsee edetäkseen: näyttöä varten tehtävät asiakirjojen latauspyynnöt, kyselyt, aloitteet ja sähköisen allekirjoituksen pyynnöt. Voit valita ohjelmakohtaisesti, miten kumppanit etenevät: itsearvioinnin perusteella, automaattisesti edellisen askeleen valmistuttua tai vasta tiimisi vahvistettua sen. Tiimisi voi muokata suunnitelmaa yhdessä reaaliajassa. Kumppanit näkevät oman tilanteensa ja seuraavan tason vaatimukset millä tahansa 22 kielestä, eivätkä koskaan näe muiden kumppanien tietoja. Päivittäiset tilannekuvat säilyttävät historian, joten raporteista näkee, miten verkosto on edennyt arviointikierrosten välillä.

Usein kysytyt kysymykset

Kuinka monta tasoa kypsyysmallissa pitäisi olla?

Useimmille kumppaniverkostoille neljä tai viisi. Tärkeintä on, että jokainen taso erottuu selvästi, on määritelty hyvin ja muodostaa loogisen askeleen edeltävästä tasosta [3]. Jos arvioijat eivät pilotissa erota kahta tasoa toisistaan, yhdistä ne.

Kuinka kauan kypsyysmallin rakentaminen kestää?

Varaa ensimmäisen version laatimiseen kaksi tai kolme kuukautta: muutama viikko tarkoituksen, ulottuvuuksien ja tasojen määrittelyyn, muutama viikko lisää kuvausten ja näyttöjen laatimiseen sekä sen jälkeen kumppanityöpaja ja pilotti. Oikopolut kostautuvat toisena versiona, jolle kukaan ei ollut varannut budjettia.

Voimmeko mukauttaa olemassa olevaa kypsyysmallia sen sijaan, että rakentaisimme uuden?

Usein kyllä, ja sitä kannattaa selvittää ensin [2]. Tarkista lisenssi, säilytä rakenne, jos se sopii tarkoitukseesi, ja kirjoita kuvaukset uudelleen verkostosi kielellä.

Voiko kumppani olla eri tasolla eri ulottuvuuksissa?

Kyllä, ja yleensä onkin; tällainen profiili on mallin hyödyllisin tulos. Kumppanin ei kuitenkaan pidä hypätä tasojen yli yhden ulottuvuuden sisällä – tästä CMM:n laatijat huomauttivat puhuessaan omista tasoistaan [1].

Aloita tarkoituksesta, älä tasoista

Jos tästä oppaasta jää mieleen yksi asia, olkoon se oikea etenemisjärjestys. Kirjaa tarkoitus yhdelle sivulle, sovi siitä muutaman kumppanin kanssa ja avaa vasta sitten taulukko. Näin rakennettu malli vie enemmän aikaa käynnistää, mutta paljon vähemmän aikaa perustella.

Lähteet

1. Mark C. Paulk, Bill Curtis, Mary Beth Chrissis ja Charles V. Weber, Software Engineering Institute, Carnegie Mellon University, "Capability Maturity Model for Software, Version 1.1" (CMU/SEI-93-TR-024), helmikuu 1993, https://www.sei.cmu.edu/library/capability-maturity-model-for-software-version-11/ (käyty lokakuussa 2026).
2. Jörg Becker, Ralf Knackstedt ja 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 (käyty lokakuussa 2026).
3. Tonia de Bruin, Michael Rosemann, Ronald Freeze ja 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 (käyty lokakuussa 2026).
4. Jens Pöppelbuß ja 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), kesäkuu 2011, https://aisel.aisnet.org/ecis2011/28/ (käyty lokakuussa 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 (käyty lokakuussa 2026).

© 2026 Mourinho Solutions. Kaikki oikeudet pidätetään.