Prośba często pojawia się w jednym zdaniu dokumentu dla zarządu: opracować model dojrzałości dla naszych partnerów. Ktoś z sekretariatu otwiera arkusz kalkulacyjny, wpisuje pięć nagłówków — od Podstawowego do Doskonałego — i zaczyna wypełniać komórki. Kilka tygodni później, na spotkaniu członków, nikt nie rozmawia o zarządzaniu ani kompetencjach cyfrowych. Dyskusja dotyczy tego, czy dany członek jest „dobry”, czy „bardzo dobry” i kto o tym zdecydował.
Problemem rzadko jest sam wysiłek — chodzi o kolejność podejmowania decyzji. W tym przewodniku pokazuję, jak zbudować model dojrzałości sieci partnerów w ośmiu krokach: od określenia celu po pierwszą rewizję. Znajdziesz tu bezpłatny, czterostronicowy szablon, wypełniony przykład fikcyjnej federacji i błędy, których warto unikać.
Czym jest model dojrzałości i skąd wzięła się ta koncepcja
W listopadzie 1986 roku Software Engineering Institute na Carnegie Mellon University rozpoczął prace nad ramami dojrzałości procesów. Była to odpowiedź na prośbę o opracowanie dla rządu federalnego Stanów Zjednoczonych sposobu oceny kompetencji wykonawców oprogramowania. W 1993 roku powstał Capability Maturity Model for Software, którego pięć poziomów dojrzałości, jak określa to sam SEI, „definiuje skalę porządkową” [1].
Podstawowa struktura pozostała niezmienna: sekwencja poziomów opisujących przewidywaną, pożądaną lub typową ścieżkę rozwoju podzieloną na odrębne etapy [2]. Każdy poziom określa, co musi być spełnione, aby go osiągnąć, dzięki czemu ocena pozwala umiejscowić organizację na tej ścieżce i wskazać kolejny krok. Do 2005 roku powstało ponad 150 modeli dojrzałości z różnych dziedzin — od usług IT po zarządzanie wiedzą [3]. Jednak gdy Becker, Knackstedt i Pöppelbuß przeanalizowali 51 z nich, tylko dziewięć szczegółowo opisywało proces projektowania [2]. Poniżej przedstawiamy metodę opartą na tych badaniach, dostosowaną do potrzeb zespołów programowych.
Jak zbudować model dojrzałości w ośmiu krokach
Kroki odpowiadają fazom opracowywania dowolnego modelu dojrzałości zaproponowanym przez de Bruina, Rosemanna, Freeze’a i Kulkarni: określenie zakresu, projektowanie, opracowanie treści, testowanie, wdrożenie i utrzymanie [3]. Każda decyzja ogranicza kolejne, a pilotaż sprawi, że co najmniej raz wrócisz do poprawiania opisów.
1. Określ cel modelu
Zanim zdefiniujesz poziomy, zapisz, jakie decyzje ma wspierać model. W badaniach wyróżniono trzy zastosowania [3][4]: model opisowy pokazuje, na jakim etapie znajduje się obecnie każdy partner; model preskryptywny wskazuje również, co zrobić dalej; model porównawczy służy do porównywania partnerów lub regionów, co wymaga wielu ocen i bardzo stabilnych kryteriów. Większość sieci partnerskich potrzebuje dwóch pierwszych typów.
Na tej samej stronie odpowiedz na pytania: kto wypełnia model (sam partner, wspólnie z wami czy po waszym potwierdzeniu), jak często oraz do czego model nigdy nie będzie wykorzystywany. Z mojego doświadczenia wynika, że to ostatnie zastrzeżenie bardziej sprzyja szczerym odpowiedziom niż jakakolwiek instrukcja. Jeśli członkowie podejrzewają, że model zadecyduje o ich członkostwie lub dotacji, będą zawyżać swoje oceny, a model opisze sieć, która nie istnieje.
2. Wybierz wymiary
Wymiary to tematy objęte modelem: zarządzanie, finanse, kompetencje cyfrowe, ochrona przed krzywdą, udział młodzieży. Ogranicz ich liczbę, by zmniejszyć złożoność i zachować ich niezależność (dwa modele de Bruina i współpracowników obejmowały odpowiednio sześć i cztery główne elementy). Wymiary powinny być rozłączne i łącznie wyczerpujące [3]: te same dowody nie powinny być liczone dwukrotnie, a nic, co jest potrzebne do realizacji celu, nie powinno zostać pominięte. Zalecam od czterech do siedmiu wymiarów, z podziałem na dwa lub trzy podwymiary, jeśli dany temat jest szeroki.
Zanim opracujesz własny model, sprawdź, co już istnieje: porównanie z istniejącymi modelami to pierwszy wymóg, jaki Becker i współpracownicy stawiają przy tworzeniu nowego modelu [2]. W przypadku wzmacniania potencjału dobrym punktem wyjścia jest siedem elementów siatki McKinseya z 2001 roku, opracowanej dla Venture Philanthropy Partners [5], a także sześć obszarów opisanych w naszym przewodniku po ocenie potencjału partnerów.
3. Wybierz cztery lub pięć poziomów
CMM ma pięć poziomów [1], a siatka McKinseya — cztery [5]. Liczba ma mniejsze znaczenie niż wymóg określony przez de Bruina i współpracowników: etapy mają być odrębne i dobrze zdefiniowane, tworzyć logiczny ciąg, a każdy z nich powinien mieć krótką nazwę wskazującą jego cel [3].
| Cztery poziomy | Pięć poziomów | |
|---|---|---|
| Przykładowe nazwy | Poznawanie, Budowanie, Utrwalanie, Przewodzenie | Początkowy, Powtarzalny, Zdefiniowany, Zarządzany, Optymalizowany (nazwy z CMM) [1] |
| Sprawdza się, gdy | Możesz potwierdzić istnienie czterech odrębnych stanów — od pierwszych kroków po przewodzenie innym | Możesz wykazać różnicę między dobrym wykonywaniem działań a ich systematycznym doskonaleniem |
| Uważaj na | Połączenie dwóch różnych stanów w jeden poziom, na którym partnerzy pozostają potem przez lata | Najwyższy poziom, do którego nikt nie dochodzi, oraz środkowe poziomy, których oceniający nie potrafią odróżnić |
Moja zasada wynika z badań operacyjnych: poziom zasługuje na uwzględnienie tylko wtedy, gdy można go opisać za pomocą dowodów i odróżnić od sąsiednich poziomów. Policz stany, które rzeczywiście możesz zaobserwować w swojej sieci, i na tym poprzestań. Liczbę można też zwiększyć: Becker i współpracownicy rozpoczęli prace nad modelem wyników IT od czterech etapów, a po rozmowach z menedżerami IT zwiększyli ich liczbę do sześciu — od „nieistniejącego” do „zoptymalizowanego” — aby rozróżnić słabsze przypadki [2]. Najniższy poziom opisz jako punkt wyjścia, a nie wyrok: „Poznawanie” otwiera rozmowę, „Niedostateczny” ją kończy.
4. Opisz każdy poziom jako obserwowalny stan
To właśnie na tym etapie większość modeli zawodzi. Deskryptor to tekst w jednej komórce siatki. Pöppelbuß i Röglinger zaliczają kryteria weryfikowalne przez różne osoby do zasad projektowania użytecznego modelu dojrzałości: opisy muszą być na tyle precyzyjne i jasne, by pozwalały odróżnić jeden poziom od następnego [4]. Mówiąc prościej: dwie osoby oceniające tego samego partnera powinny wybrać tę samą komórkę.
| Nieprecyzyjny opis | Obserwowalny opis | Dowody |
|---|---|---|
| Dobra ochrona danych | Wyznaczono osobę odpowiedzialną za dane; zasady uzyskiwania zgody i przechowywania danych są spisane i stosowane | Polityka ochrony danych, formularz zgody, zasady przechowywania danych |
| Silne przywództwo cyfrowe | Zarząd zatwierdził plan cyfrowy z budżetem i wyznaczoną osobą odpowiedzialną | Protokół posiedzenia zarządu, budżet |
| Wystarczające raportowanie | Kluczowe wskaźniki są sprawdzane przez drugą osobę, a raporty przekazywane w terminie | Arkusz wskaźników, dwa ostatnie raporty |
| Angażuje młodzież w internecie | Młodzież współtworzy treści, a ich zasięg jest mierzony co kwartał | Harmonogram treści, kwartalne dane o zasięgu |
Pomogą trzy nawyki:
- Nazywaj coś, co można zobaczyć lub wziąć do ręki: dokument, rutynę, rolę, liczbę. Unikaj określeń „dobry”, „silny”, „wystarczający” i „skuteczny”.
- Zmieniaj jedną rzecz na każdym kolejnym poziomie. Jeśli poziom 3 jednocześnie wymaga budżetu, osoby odpowiedzialnej i corocznego przeglądu, partner, który spełnia dwa z tych trzech warunków, nie będzie wiedział, gdzie się zaklasyfikować.
- Ułóż poziomy kumulatywnie. Każdy kolejny etap powinien obejmować wymagania etapów niższych [3]. Test, którego nauczyłem się podczas pracy w badaniach operacyjnych: spróbuj wyobrazić sobie partnera, dla którego poziom 3 jest prawdziwy, a poziom 2 — nie. Jeśli to możliwe, kolejność jest niewłaściwa albo dana komórka należy do innego wymiaru.
5. Określ dowody dla każdego poziomu
Przy każdej komórce zapisz, co będzie potwierdzeniem spełnienia wymagań: polityka, protokół, raport lub liczba. Na niższych poziomach wymagaj niewielu dowodów, a na wyższych — więcej, bo stoją za nimi dalej idące deklaracje. Określ też, kto dostarcza dowody i kto je potwierdza. Nie proś o dowody, których nikt nie przeczyta: każdy dokument zabiera partnerowi czas, który mógłby poświęcić na jego pracę.
6. Zweryfikuj model z partnerami
Pokaż projekt osobom, które będą z niego korzystać. De Bruin i współpracownicy wykorzystali metodę delficką i grupy fokusowe do opracowania i weryfikacji swoich modeli [3]; McKinsey przetestował swoją siatkę z udziałem niemal tuzina dyrektorów wykonawczych organizacji non-profit [5]; wersja 1.1 CMM powstała na podstawie opinii zebranych podczas warsztatu poświęconego wersji 1.0, w którym wzięło udział około 200 specjalistów od oprogramowania [1]. W przypadku sieci partnerów zacznij od dwugodzinnego warsztatu z udziałem ośmiu–dziesięciu zróżnicowanych partnerów. Zapytaj: Czy rozpoznajecie w tym siebie? Czy używamy waszego języka? Czego brakuje? Czy coś jest upokarzające?
7. Przeprowadź pilotaż i kalibrację
Przetestuj model w praktyce z udziałem trzech–pięciu partnerów. De Bruin i współpracownicy podkreślają konieczność sprawdzenia trafności i rzetelności narzędzia, tak aby wyniki były dokładne i powtarzalne [3]. W praktyce oznacza to, że dwie osoby niezależnie oceniają tego samego partnera, a każda rozbieżność wskazuje opis wymagający poprawy. Jeśli wszyscy partnerzy pilotażowi trafiają na poziom 2, poziomy nie pozwalają ich rozróżnić; jeśli nikt nie wyobraża sobie osiągnięcia poziomu 4, jest to lista życzeń. Skala, która wszystkich umieszcza w tej samej kategorii, nie dostarcza żadnych informacji.
8. Zarządzaj zmianami i ponawiaj ocenę
Becker i współpracownicy zauważają, że każdy model dojrzałości z czasem się starzeje, bo zmieniają się warunki, technologia i wiedza. Konieczne zmiany powinny być wprowadzane w nowej wersji modelu [2]. Traktuj swój model jak standard: nadawaj mu numer wersji, wyznaczaj jeden okres zmian w roku, prowadź rejestr zmian z informacją, co i dlaczego zmieniono, i nie wprowadzaj poprawek w trakcie rundy oceny. Gdy w wersji 1.1 zmienia się opis, wyjaśnij, jak przenieść wyniki z wersji 1.0, aby żaden partner nie stracił poziomu tylko dlatego, że zmieniono treść zdania. Następnie ponawiaj ocenę co 6–12 miesięcy. W naszym przewodniku po ocenie potencjału partnerów opisujemy, jak prowadzić takie rundy i dlaczego nie należy sprowadzać poziomów do jednej średniej oceny.
Szablon modelu dojrzałości partnerów (bezpłatne pobranie)
Szablon przekłada osiem kroków na cztery strony A4: cel i zakres; wymiary i poziomy; siatkę opisów wraz z testem opisu i notatkami z kalibracji; oraz plan dowodów, plan walidacji i rejestr wersji.
Pobierz szablon do budowania modelu dojrzałości (PDF, 4 strony). Wydrukuj go na warsztaty projektowe lub skopiuj poszczególne sekcje.
Chcesz przekształcić siatkę w program, nad którym partnerzy mogą pracować? W Advancer.World twoje wymiary stają się tematami, poziomy — etapami, a każdy opis — komórką, z prośbami o dostarczenie dowodów na krokach prowadzących między poziomami. Każdy partner widzi, na jakim jest etapie. Rozpoczęcie jest bezpłatne.
Przykład: ścieżka dojrzałości cyfrowej członków federacji
Oto szablon wypełniony dla Meridian Youth Federation — fikcyjnej federacji zrzeszającej 26 krajowych organizacji członkowskich.
Pobierz wypełniony przykład (PDF, 4 strony). Warto skopiować cztery rozwiązania:
- Cel modelu wyraźnie coś wyklucza. Model pomaga ustalić, kto jako pierwszy otrzyma wsparcie mentorskie od innych członków i na co można przeznaczyć fundusz wsparcia cyfrowego; nigdy nie służy do oceny statusu członkostwa ani tworzenia rankingów.
- Cztery poziomy zamiast pięciu — po przetestowaniu obu wariantów. Nie dało się potwierdzić różnicy między dwoma środkowymi poziomami w pierwszej wersji, więc zrezygnowano z piątego.
- Sześć obszarów w ramach trzech tematów. Członek może osiągać poziom Przewodzenia w zakresie zaangażowania w internecie, a zarazem być na poziomie Poznawania w zakresie ochrony danych. Taki profil jest tym, co federacja chce zobaczyć.
- Pilotaż doprowadził do zmiany sformułowań. Dwie osoby oceniające różnie rozumiały określenie „regularnie publikuje” — jako publikowanie co tydzień lub co miesiąc — dlatego poziom 2 w zakresie zaangażowania w internecie zmieniono na „kalendarz treści z kanałami dla poszczególnych odbiorców”.
Najczęstsze błędy przy tworzeniu modelu dojrzałości
- Opisywanie poziomów przed określeniem celu. Bez decyzji, którą model ma wspierać, łatwo przekształca się on w ranking, a partnerzy zaczynają go tak traktować.
- Mylenie kwestionariusza z modelem. SEI zetknął się z tym problemem w przypadku własnego kwestionariusza dojrzałości z 1987 roku, który zbyt często uznawano za sam model [1]. Model to ścieżka; kwestionariusz jest jednym ze sposobów jej pomiaru.
- Przymiotniki zamiast obserwowalnych stanów. Dla każdej osoby oceniającej „wystarczający” oznacza coś innego.
- Zbyt wiele wymiarów. Czterdzieści wskaźników oznacza model, którego nikt nie ukończy.
- Projektowanie dla partnerów, a nie wspólnie z nimi. Poziom 1 opisany jako lista niepowodzeń uczy partnerów, by ukrywać problemy.
- Wprowadzanie zmian w trakcie rundy oceny. Zmiana choćby jednego opisu sprawia, że wyników z tej rundy nie można porównać z poprzednimi.
Tworzenie modelu dojrzałości w Advancer.World
Advancer.World powstał w wyniku cyfrowej transformacji programów w organizacjach takich jak UNICEF i Airbus. Program w Advancer.World ma strukturę modelu dojrzałości: etapy odpowiadają poziomom, tematy i podtematy — wymiarom, a każda komórka zawiera opis.
Kroki między komórkami obejmują działania potrzebne partnerowi do przejścia na wyższy poziom: prośby o przesłanie dokumentów stanowiących dowody, ankiety, inicjatywy i prośby o podpis elektroniczny. W każdym programie możesz wybrać sposób przechodzenia partnerów między etapami: samoocenę, automatyczne przejście po wykonaniu poprzedniego kroku albo przejście dopiero po zatwierdzeniu przez twój zespół. Twój zespół może wspólnie edytować projekt w czasie rzeczywistym. Partnerzy widzą, na jakim są etapie i jakie wymagania stawia przed nimi kolejny poziom. Mogą korzystać z dowolnego z 22 języków i nigdy nie widzą danych innych partnerów. Codzienne migawki zachowują historię, dzięki czemu raporty pokazują, jak zmieniała się sytuacja sieci między kolejnymi rundami.
FAQ
Ile poziomów powinien mieć model dojrzałości?
W większości sieci partnerskich wystarczą cztery lub pięć. Najważniejsze, by każdy poziom był odrębny, jasno zdefiniowany i stanowił logiczny krok w stosunku do poprzedniego [3]. Jeśli podczas pilotażu osoby oceniające nie potrafią odróżnić dwóch poziomów, połącz je.
Ile czasu zajmuje opracowanie modelu dojrzałości?
Przygotowanie pierwszej wersji zajmuje zwykle od dwóch do trzech miesięcy: kilka tygodni na określenie celu, wymiarów i poziomów, kolejne tygodnie na opracowanie opisów i dowodów, a następnie warsztat z partnerami i pilotaż. Pójście na skróty skutkuje koniecznością przygotowania drugiej wersji, na którą nikt nie zaplanował budżetu.
Czy możemy dostosować istniejący model dojrzałości zamiast tworzyć własny?
Często tak — i warto najpierw sprawdzić tę możliwość [2]. Zweryfikuj licencję, zachowaj strukturę, jeśli odpowiada Twojemu celowi, a opisy przeredaguj tak, by pasowały do języka używanego w Twojej sieci.
Czy partner może mieć różne poziomy w różnych wymiarach?
Tak — i zwykle tak właśnie jest. Taki profil to najbardziej użyteczny rezultat modelu. Partner nie powinien natomiast pomijać poziomów w obrębie jednego wymiaru — na tę kwestię zwracali uwagę autorzy CMM, opisując własne poziomy [1].
Zacznij od celu, nie od poziomów
Jeśli masz zapamiętać jedną rzecz z tego poradnika, niech będzie nią właściwa kolejność działań. Opisz cel na jednej stronie, uzgodnij go z kilkoma partnerami i dopiero wtedy przejdź do siatki. Model opracowany w ten sposób wymaga więcej czasu na początku, ale znacznie mniej wysiłku, by go później uzasadnić.
Opracuj model dojrzałości raz i stosuj go wobec każdego partnera. Zaprojektuj siatkę ze swoim zespołem, zaproś partnerów i sprawdzaj, na jakim etapie znajduje się każdy z nich — runda po rundzie. Rozpoczęcie jest bezpłatne.
Źródła
- Mark C. Paulk, Bill Curtis, Mary Beth Chrissis i Charles V. Weber, Software Engineering Institute, Carnegie Mellon University, „Capability Maturity Model for Software, Version 1.1” (CMU/SEI-93-TR-024), luty 1993, https://www.sei.cmu.edu/library/capability-maturity-model-for-software-version-11/ (dostęp: październik 2026).
- Jörg Becker, Ralf Knackstedt i 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 (dostęp: październik 2026).
- Tonia de Bruin, Michael Rosemann, Ronald Freeze i 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 (dostęp: październik 2026).
- Jens Pöppelbuß i 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), czerwiec 2011, https://aisel.aisnet.org/ecis2011/28/ (dostęp: październik 2026).
- McKinsey & Company dla 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 (dostęp: październik 2026).
© 2026 Mourinho Solutions. Wszelkie prawa zastrzeżone.