Jak zbudować model dojrzałości sieci partnerów

Model dojrzałości to zadanie projektowe, nie pisarskie. Osiem kroków — od określenia celu po wersję 1.0 — bezpłatny, czterostronicowy szablon, wypełniony przykład fikcyjnej federacji i błędy, których warto unikać.

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.

Schemat ośmiu kroków budowania modelu dojrzałości: cel i zastosowanie, wymiary, poziomy, opisy, dowody, walidacja z partnerami, pilotaż i kalibracja, zarządzanie i ponowna ocena; przy każdym kroku wskazano fazę opracowywania
Osiem kroków i faza opracowywania, do której należy każdy z nich.

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 czy pięć poziomów?
  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ę.

Od przymiotników do obserwowalnych stanów (przykłady z opisu fikcyjnej federacji poniżej)
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.

Strona 1 pustego szablonu do budowania modelu dojrzałości: informacje o modelu, osiem kroków metody, zastosowania modelu i pięć pytań o jego cel
Strona 1 szablonu: określ cel modelu, zanim zaczniesz opisywać poziomy.

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.

Zarejestruj się teraz

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.

Wypełniony przykład, strona 3: sześć obszarów dojrzałości cyfrowej opisanych na czterech poziomach, od Poznawania do Przewodzenia, wraz z testem opisu i notatkami z kalibracji po pilotażu
Strona 3 przykładu (fikcyjna federacja): siatka opisów, test i zmiany wprowadzone po pilotażu.

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

  1. 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ć.
  2. 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.
  3. Przymiotniki zamiast obserwowalnych stanów. Dla każdej osoby oceniającej „wystarczający” oznacza coś innego.
  4. Zbyt wiele wymiarów. Czterdzieści wskaźników oznacza model, którego nikt nie ukończy.
  5. Projektowanie dla partnerów, a nie wspólnie z nimi. Poziom 1 opisany jako lista niepowodzeń uczy partnerów, by ukrywać problemy.
  6. 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.

Projekt programu w Advancer.World: ścieżka dojrzałości cyfrowej członków z czterema etapami, od Poznawania do Przewodzenia, w obszarach strategii, działań i ludzi
Model z przykładu przedstawiony jako program w Advancer.World (przykładowe dane, fikcyjna federacja): cztery etapy, sześć obszarów w ramach trzech tematów.

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.

Zarejestruj się teraz

Źródła

  1. 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).
  2. 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).
  3. 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).
  4. 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).
  5. 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.

Udostępnij LinkedIn X E-mail

← Powrót do bloga