Najpopularniejsza rada dotycząca CMMI w zarządzaniu danymi brzmi: zacznijcie od udokumentowania polityk, określenia własności i przygotowania dowodów na potrzeby oceny. Ta rada jest niepełna. Polityka mówiąca „monitorujcie jakość danych” nie ochroni pulpitu, gdy źródło doda kolumnę, zmieni typ danych, dostarczy plik z opóźnieniem albo złamie regułę biznesową. Dojrzałe zarządzanie danymi musi dowodzić, że kontrole działają w całym cyklu życia, a nie tylko że ktoś je spisał.

CMMI staje się użyteczniejsze, gdy zespoły traktują je jako model operacyjny dla obserwowalnych, powtarzalnych i ulepszalnych procesów danych. Dokumentacja wciąż ma znaczenie, zwłaszcza w środowiskach regulowanych, ale powinna opisywać kontrole generujące dowody operacyjne. Praktyczne pytanie nie brzmi już tylko, czy proces governance istnieje. Brzmi ono, czy organizacja potrafi wykryć awarię, wyjaśnić jej skutki, przypisać odpowiedzialność i wykazać, że wyniki się poprawiają.

Spis treści

• Zrozumieć CMMI w zarządzaniu danymi

  • Od procesu wytwarzania oprogramowania do zdolności danych

• Pięć poziomów dojrzałości i kryteria oceny

  • Co poziomy oznaczają operacyjnie

  • Dlaczego 25 obszarów procesowych ma znaczenie

• Odwzorowanie praktyk frameworku na nowoczesny operacyjny obszar danych

  • Zamiana języka procesu w zachowanie kontrolne

  • Wbudowanie dowodów w przepływ pracy

• Wyjście poza statyczne artefakty governance

  • Luka cyklu życia

• Budowa mapy wdrożenia dojrzałości danych

  • Podejście fazowe

  • KPI dojrzałości według fazy wdrożenia

• Przyspieszenie dojrzałości z platformą digna

  • Dopasowanie modułów do dowodów dojrzałości

  • Porównanie opcji wdrożenia

• Zapewnienie długotrwałej niezawodności i zaufania do danych

Zrozumieć CMMI w zarządzaniu danymi

Historia CMMI tłumaczy zarówno jego wartość, jak i reputację. Szersza oś czasu doskonalenia procesów zaczęła się od prac nad Software CMM w 1987 roku, po których w 1991 ukazało się pierwsze wydanie SW-CMM. Zintegrowany pakiet CMMI opublikowano po raz pierwszy w 2000 roku, tworząc szerszą podstawę do oceny zdolności organizacyjnej zamiast skupiania się wyłącznie na pojedynczych zadaniach technicznych. Historię tę dokumentuje materiał referencyjny CMMI for Development.

Framework zyskał też wiarygodność na rynkach, gdzie powtarzalność i audytowalność nie były opcjonalne. Memorandum Ganslera z 1999 roku wymagało ocen oprogramowania DoD dla programów ACAT I i stwierdzało, że pełna zgodność z poziomem 3 CMMI Capability Maturity Model albo równoważna zatwierdzona ocena jest celem Departamentu. CMMI for Acquisition pojawiło się w 2007, CMMI for Services w 2009, a trzy główne warianty ujednolicono w wersji 1.3 w listopadzie 2010 roku, zgodnie z CMMI Acquisition Handbook.

Od procesu wytwarzania oprogramowania do zdolności danych

Dedykowany model Data Management Maturity, czyli DMM, przeniósł tę logikę dojrzałości na korporacyjne praktyki danych. Wydano go w sierpniu 2014 roku, po około 3,5 roku prac, i przedstawiono jako uporządkowany sposób oceny zarządzania danymi od utworzenia lub pozyskania aż po wycofanie. Ta perspektywa cyklu życia czyni model istotnym dla organizacji prowadzących hurtownie, jeziora, systemy operacyjne, platformy raportowe i pipeline'y AI.

Model DMM zawiera pięć poziomów dojrzałości i 25 obszarów procesowych obejmujących strategię, jakość, operacje, platformy i architekturę, governance oraz procesy wspierające. Jego wartością jest dekompozycja. „Poprawcie data governance” to zbyt szerokie polecenie, by dało się nim zarządzać; widok obszarów procesowych pozwala ustalić, czy słabość leży we własności, kontrolach jakości, praktykach platformowych, operacjach cyklu życia czy pomiarze. Materiał modelu DMM opisuje framework jako sposób oceny zdolności, wzmocnienia programu zarządzania danymi i stworzenia mapy usprawnień zgodnej z celami biznesowymi.

Zasada praktyczna: traktujcie każdą deklarację dojrzałości jako niepełną, dopóki nie da się jej powiązać z powtarzalnym dowodem z systemów przetwarzających dane.

Ta zasada zmienia sposób, w jaki zespoły korporacyjne korzystają z frameworków zarządzania danymi. CMMI nie jest ani przestarzałą listą kontrolną z inżynierii oprogramowania, ani użyteczne jako ćwiczenie papierkowe. To uporządkowany sposób zestrojenia strategii danych, kontroli, zachowania operacyjnego i wyników biznesowych, o ile ocena obejmuje to, co dzieje się na produkcji.

Pięć poziomów dojrzałości i kryteria oceny

Poziom dojrzałości opisuje, jak konsekwentnie organizacja wykonuje i doskonali swoje procesy. Pięciostopniowa progresja prowadzi od reaktywnej pracy na poziomie projektu ku mierzonej i optymalizowanej zdolności korporacyjnej. Poziomów nie należy traktować jak etykiet na slajd. Każdy wymaga dowodu, że organizacja zarządza danymi z większą konsekwencją, widocznością i kontrolą.

Co poziomy oznaczają operacyjnie

Poziom 1, Początkowy, opisuje pracę nieprzewidywalną i reaktywną. Zespoły zależą od wiedzy pojedynczych osób, ręcznych interwencji i reakcji wywołanych incydentami. Dane mogą wciąż docierać do użytkowników, ale organizacja nie potrafi wiarygodnie wyjaśnić, jak kontrole działają w poszczególnych produktach czy domenach.

Poziom 2, Zarządzany, wprowadza planowanie i kontrolę na poziomie projektu lub zespołu. Zespół pipeline'u może śledzić problemy jakości i harmonogramy dostaw, ale praktyki bywają różne w różnych działach. Dowody istnieją, lecz pozostają rozproszone i często zależą od lokalnych konwencji.

Poziom 3, Zdefiniowany, to moment, w którym standaryzacja w skali organizacji staje się widoczna. Zespoły stosują wspólne definicje procesów, wspólne pojęcia danych, udokumentowane odpowiedzialności i spójne wzorce kontroli. W operacjach danych powinno to obejmować wspólne oczekiwania wobec walidacji, obsługi incydentów, zarządzania zmianami schematu i monitoringu dostaw.

Poziom 4, Zarządzany ilościowo, wymaga czegoś więcej niż pulpitu pełnego wskaźników statusu. Zespoły używają miar ilościowych, by rozumieć zachowanie procesu, ustalać linie bazowe, wykrywać zmienność i zarządzać wynikami wobec jawnych celów. Dojrzały zespół odróżni pojedynczy defekt od istotnego przesunięcia w Timeliness, wolumenie, kompletności czy innej monitorowanej właściwości.

Poziom 5, Optymalizujący, stosuje zdyscyplinowane doskonalenie ciągłe. Zespoły wykorzystują dowody operacyjne, aby dopracowywać kontrole, usuwać powracające tryby awarii i poprawiać działanie procesów danych. Optymalizacja to nie dokładanie alertów. To nauka, które sygnały mają znaczenie, ograniczanie zbędnego szumu i zmienianie procesów na podstawie zaobserwowanego zachowania.

Dlaczego 25 obszarów procesowych ma znaczenie

25 obszarów procesowych dzieli zarządzanie danymi na oceniane zdolności obejmujące strategię, jakość danych, operacje, platformy i architekturę, governance oraz procesy wspierające. Taka granularność pomaga uniknąć mylącej średniej dla całej organizacji. Firma może mieć mocne kontrole platformowe i słabą strategię danych albo dobrze zdefiniowane polityki przy kiepskim monitoringu cyklu życia.

Model DMM może wspierać ocenę według modelu dojrzałości data governance, który przekłada luki zdolności na praktyczne działania naprawcze. Ocena powinna pytać, jakie dowody istnieją dla każdego istotnego obszaru:

• Zdefiniowana własność: czy organizacja potrafi wskazać odpowiedzialnych właścicieli krytycznych danych i kontroli?

• Powtarzalne wykonanie: czy zespoły stosują ten sam proces do porównywalnych zbiorów danych?

• Mierzone wyniki: czy miary jakości, Timeliness, zmian strukturalnych i incydentów zbierane są konsekwentnie?

• Reakcja kierownictwa: czy zespoły używają tych miar do priorytetyzacji napraw?

• Zachowanie doskonalące: czy liderzy potrafią wykazać, że powtarzalne problemy prowadzą do zmian procesu?

Aktualizacja warsztatowa opisała bardziej szczegółową strukturę 6 kategorii, 15 obszarów składowych, 36 obszarów procesów biznesowych, 18 polityk i procedur oraz 200 miar zdolności w materiale warsztatowym NDIA. Ten poziom szczegółowości wzmacnia ważną tezę: jakość oceny zależy od odtwarzalnych dowodów, a nie od tego, jak dopracowana wygląda dokumentacja governance.

Odwzorowanie praktyk frameworku na nowoczesny operacyjny obszar danych

Obszar procesowy CMMI staje się użyteczny dla inżynierów, gdy przekłada się na zachowanie, które da się obserwować i którym da się zarządzać. Odwzorowanie powinno zaczynać się od ryzyka biznesowego, a potem wskazywać sygnał danych ujawniający awarię, reagującą kontrolę i dowód zachowany do przeglądu.

Zamiana języka procesu w zachowanie kontrolne

Zacznijcie od zarządzania schematem. Dodane kolumny, usunięte kolumny i zmiany typów potrafią zepsuć odbiorców, zwłaszcza gdy pipeline'y opierają się na strukturze domyślnej. Spisana polityka zmian sama nie wykryje awarii. Ciągłe śledzenie schematu powinno zapisywać poprzednią strukturę, zaobserwowaną zmianę, dotknięte zasoby i właściciela odpowiedzialnego za przegląd. Problem dryfu schematu opisuje to porównanie korporacyjnej data observability.

Następnie oprzyrządujcie Timeliness. Dane docierające z opóźnieniem potrafią szkodzić tak samo jak dane z nieprawidłowymi wartościami. Kontrola dostaw powinna uczyć się lub korzystać z oczekiwanych harmonogramów, wykrywać brakujące ładowania, sygnalizować opóźnienia i wcześniejsze dostawy oraz w miarę możliwości wyliczać oczekiwany czas dostarczenia. To tworzy dowód konsekwencji operacyjnej zamiast polegania na tym, że ktoś zauważy nieodświeżony raport.

Potem zastosujcie walidację na poziomie rekordu do pól, w których liczy się logika deterministyczna. Dane regulowane lub o dużym wpływie często wymagają wersjonowanych katalogów reguł biznesowych, akceptowalnych progów i SLA świeżości. Nieudana walidacja powinna zachować wersję reguły, dotknięte rekordy lub zakres, czas wykonania, wynik i status naprawy. Poradnik zarządzania jakością danych opisuje to podejście jako sposób egzekwowania spójnej przydatności danych i wspierania audytowalności.

Wbudowanie dowodów w przepływ pracy

Praktyczne wdrożenie obejmuje cztery kroki:

1. Wybierzcie zasoby krytyczne: priorytetyzujcie zbiory wspierające raportowanie regulacyjne, decyzje finansowe, operacje kliniczne, zobowiązania wobec klientów albo obciążenia AI.

2. Zdefiniujcie obserwowalne oczekiwania: określcie poprawne struktury, reguły biznesowe, zachowanie dostaw i akceptowalne wzorce miar.

3. Zautomatyzujcie wykrywanie: uruchamiajcie kontrole tam, gdzie dane już są, i zapisujcie wyniki we wspólnym rejestrze incydentów i historii.

4. Powiążcie reakcję z governance: przypisujcie właścicieli, zapisujcie decyzje, dokumentujcie wyjątki i śledźcie trend powtarzalnych awarii.

Framework observability dla danych staje się wtedy czymś więcej niż pulpitem monitoringu. Dostarcza warstwy operacyjnej łączącej oczekiwania CMMI z zachowaniem pipeline'ów. Inżynierowie dostają sygnały awarii, na które można zareagować, zespoły governance dowody możliwe do prześledzenia, a właściciele biznesowi widzą, czy krytyczne dane pozostają przydatne.

Dojrzała kontrola nie ogranicza się do stwierdzenia, że zbiór danych podlega governance. Pokazuje, co się zmieniło, kiedy zmiana nastąpiła, kto ją przejrzał i czy wpływ biznesowy został ograniczony.

Wyjście poza statyczne artefakty governance

Spisane polityki są potrzebne, ale nie dowodzą odporności. Zespół może utrzymywać dokładny katalog reguł i jednocześnie przeoczyć stopniowe przesunięcie wolumenu, spóźnioną dostawę u źródła albo zmianę strukturalną, która zostawia tabele odbiorcze technicznie dostępne, lecz semantycznie błędne.

Dane benchmarkowe wskazują na szerszy problem organizacyjny. EDM Council podaje, że strategia danych, strategia zarządzania danymi i uzasadnienie biznesowe pozostają wśród najmniej dojrzałych zdolności strategicznych we wszystkich branżach, przy czym mniej niż jedna trzecia respondentów osiąga w tym obszarze zaawansowany postęp, jak pokazują jego benchmarki branżowe. Wniosek nie brzmi, że potrzeba więcej dokumentów. Potrzeba trwałego finansowania, priorytetyzacji i akceptacji w inżynierii, governance, analityce, ryzyku i biznesie.

Luka cyklu życia

Przegląd naukowy z 2026 roku wskazał 11 głównych braków w dotychczasowej literaturze o dojrzałości zarządzania danymi, w tym niewystarczające pokrycie pełnego cyklu życia, brak praktycznych schematów samooceny i słabe ujęcie zgodności prawnej oraz ISO. Te ustalenia wspierają niewygodny wniosek: programy dojrzałości często przeceniają statyczne artefakty, a niedoceniają dowodów operacyjnych. Przegląd jest dostępny przez IEEE Computer Society.

Statyczne kontrole zawodzą w przewidywalny sposób:

• Ręczne utrzymanie reguł: reguły dezaktualizują się wraz ze zmianami schematów, źródeł i definicji biznesowych.

• Ocena punktowa: audyt może potwierdzić, że proces istniał, nie pokazując, jak zachowywał się między przeglądami.

• Własność w silosach: governance może posiadać politykę, a inżynieria wykonanie, bez wspólnego obrazu awarii.

• Niemierzone wyjątki: zespoły zatwierdzają wyjątki, nie śledząc, czy stają się trwałym stanem operacyjnym.

Ciągły monitoring adresuje te słabości, rejestrując zachowanie w czasie. Observability w bazie danych trzyma dane w środowisku klienta i liczy miary tam, gdzie dane już są, wspierając wykrywanie anomalii, śledzenie schematu, monitoring Timeliness i walidację na poziomie rekordu. Przegląd observability w bazie danych tłumaczy, dlaczego taka konstrukcja ogranicza zbędne przenoszenie danych, nie rezygnując z kontroli operacyjnych.

Celem nie jest likwidacja dokumentacji. Celem jest to, by dokumentacja opisywała kontrole, które działają, generują dowody i uruchamiają odpowiedzialne działanie.

Budowa mapy wdrożenia dojrzałości danych

Mapa dojrzałości powinna zaczynać się od ryzyka operacyjnego, a nie od poziomu, który zarząd chciałby ogłosić. Oceńcie krytyczne produkty danych, wskażcie tryby awarii tworzące największą ekspozycję biznesową, a potem sfinansujcie najpierw te obszary procesowe, które tę ekspozycję zmniejszają.

Podejście fazowe

Faza pierwsza tworzy wiarygodną linię bazową. Zbudujcie praktyczny inwentarz krytycznych zbiorów, właścicieli, lineage, definicji biznesowych, polityk i znanych odbiorców. Nie próbujcie skatalogować każdego zasobu przed startem. Pierwszym celem jest ustalenie, gdzie awaria dotknęłaby raportowania, zgodności, operacji albo AI.

Faza druga czyni kontrole powtarzalnymi. Ustandaryzujcie wzorce walidacji, własność incydentów, przegląd schematu i oczekiwania dostaw. Zespoły powinny zbierać dowody automatycznie, zamiast prosić inżynierów o kompletowanie zrzutów ekranu i arkuszy podczas oceny.

Faza trzecia wprowadza zarządzanie ilościowe. Śledźcie trend zachowania krytycznych zbiorów, odróżniajcie normalną zmienność od istotnych anomalii i wiążcie incydenty z oczekiwaniami serwisowymi. Miary powinny pomagać menedżerom decydować, gdzie inwestować, a nie tylko zdobić raport statusu.

Faza czwarta optymalizuje model operacyjny. Usuńcie hałaśliwe kontrole, dopracujcie progi, poprawcie ścieżki eskalacji i wykorzystajcie dowody historyczne, by zapobiegać powtarzalnym awariom. Optymalizacja powinna ograniczać pracę ręczną i jednocześnie zwiększać zaufanie do otrzymywanych sygnałów.

KPI dojrzałości według fazy wdrożenia

Zespoły mogą wykorzystać ukierunkowane wdrożenie jakości danych, aby zamienić mapę w pracę wspólną dla inżynierów i liderów governance. Utrzymujcie prostą macierz decyzyjną: priorytetyzujcie kontrole tam, gdzie wpływ jest wysoki, wykrywanie obecnie słabe, a naprawa wykonalna przy dostępnej własności.

Zasada decyzyjna: usuwajcie martwe pola, które mogą po cichu unieważnić ważne decyzje, zanim dołożycie kontrole do danych o niskim ryzyku.

Mapa odnosi sukces, gdy każda faza wytwarza użyteczne dowody i widoczne ograniczenie ryzyka. Zawodzi, gdy organizacja traktuje dojrzałość jako projekt certyfikacyjny oderwany od codziennej pracy pipeline'ów.

Przyspieszenie dojrzałości z platformą digna

Wybór technologii powinien wynikać z wymogu dowodowego. Zespoły mogą łączyć osobne narzędzia monitoringu, budować kontrole wewnętrzne albo sięgnąć po platformę modułową, która zbiera sygnały strukturalne, behawioralne, dostawcze i rekordowe w jednym widoku operacyjnym. Kompromis jest prosty. Kontrole własne dają precyzję, lecz wymagają stałej własności inżynierskiej, a rozłączne narzędzia tworzą rozdrobnione incydenty i niespójne dowody.

Dopasowanie modułów do dowodów dojrzałości

Na wczesnym etapie dojrzałości Schema Tracker dostarcza widocznego zapisu zmian strukturalnych, w tym dodanych lub usuniętych kolumn i zmian typów danych. Wspiera to zdefiniowany proces przeglądu bez zmuszania inżynierów do odkrywania każdej zmiany przez awarię u odbiorcy.

Do monitoringu behawioralnego Data Anomalies stosuje uczenie linii bazowej z użyciem AI i ciągłe wykrywanie anomalii, nie wymagając ręcznych reguł dla każdego oczekiwanego wzorca. Data Analytics dodaje analizę historyczną, dzięki czemu zespoły badają trendy, zmienność i zachowanie statystyczne, zamiast reagować wyłącznie na najnowszy alert.

Timeliness odpowiada za niezawodność dostaw. Monitoruje zachowanie napływu, sygnalizuje opóźnienia, brakujące ładowania i wcześniejsze dostawy oraz wylicza oczekiwany czas dostarczenia. Data Validation obsługuje deterministyczne kontrole na poziomie rekordu wobec reguł biznesowych, co czyni ją odpowiednią dla pól regulowanych, wymogów audytowych i ukierunkowanych kontroli jakości.

Porównanie opcji wdrożenia

Model wykonania w bazie danych liczy i analizuje miary wewnątrz baz klienta, więc dane produkcyjne pozostają na miejscu. Opcje chmury prywatnej i on-premises pozwalają uruchomić system we własnej chmurze, VPC lub centrum danych, co odpowiada surowym wymogom bezpieczeństwa, governance i rezydencji danych.

Wspólny pulpit daje inżynierom danych, analitykom i interesariuszom jedno miejsce do przeglądania incydentów, trendów i statusu. System zawiera też scheduler, katalog danych, integracje i funkcje współpracy już od pierwszego wyboru modułów. Licencjonowanie modułowe pozwala zacząć od jednego modułu i rozszerzać zakres, a wycena opiera się na opłacie bazowej plus aktywnych tabelach na moduł.

Czyni to rozwiązanie digna do zarządzania jakością danych praktyczną opcją dla zespołów, które chcą powiązać dowody CMMI z zachowaniem produkcyjnym bez mnożenia narzędzi. Nie zastępuje własności, decyzji politycznych ani dyscypliny naprawczej. Automatyzuje obserwację i zbieranie dowodów, których te praktyki wymagają.

Zapewnienie długotrwałej niezawodności i zaufania do danych

CMMI w zarządzaniu danymi należy prowadzić jako ciągłą dyscyplinę operacyjną, a nie okresowe ćwiczenie dokumentacyjne. Dojrzała organizacja łączy wymogi governance z obserwowalnym zachowaniem w zakresie struktury, dostaw, reguł biznesowych i wzorców danych. Takie podejście daje liderom dowód, że kontrole działają na produkcji, a inżynierom sygnały, na które mogą zareagować, zanim awarie dotrą do odbiorców.

Pierwsze trzy działania są praktyczne:

1. Zapewnijcie sponsoring zarządu: powiążcie ocenę z konkretnymi ryzykami w raportowaniu, zgodności, operacjach i AI.

2. Oceńcie krytyczne procesy danych: odwzorujcie własność, jakość, operacje, platformy, governance i procesy wspierające na model pięciu poziomów.

3. Wybierzcie zautomatyzowany monitoring: oprzyrządujcie zmiany schematu, Timeliness, anomalie i walidację na poziomie rekordu wewnątrz środowiska klienta.

Wyższa dojrzałość nie bierze się z gromadzenia kolejnych dokumentów polityki. Bierze się z uczynienia istotnego zachowania danych widocznym, mierzalnym i poddanym zdyscyplinowanemu doskonaleniu. Taki fundament wspiera szybszą reakcję na incydenty, mocniejsze dowody zgodności i trwałe zaufanie do korporacyjnych zasobów danych.

digna dostarcza platformę jakości danych i observability działającą w Waszym środowisku, obejmującą wykrywanie anomalii, monitoring Timeliness, walidację na poziomie rekordu i śledzenie schematu. Odwiedźcie digna, aby powiązać cele dojrzałości CMMI z ciągłymi dowodami operacyjnymi w całym krytycznym zasobie danych.

Spojrzenie na dojrzałość zbudowane wokół samej jakości danych, a nie obszarów procesowych, oferuje model dojrzałości jakości danych.

Najczęściej zadawane pytania

Czym jest CMMI w zarządzaniu danymi?

CMMI to model doskonalenia procesów opisujący, jak konsekwentnie organizacja wykonuje zdefiniowane praktyki, tu zastosowany do pracy z danymi. Ocenia dojrzałość według tego, czy procesy są powtarzalne i ulepszalne, a nie według posiadanych narzędzi, dlatego sama dokumentacja nigdy nie podnosi poziomu.

Co poziomy dojrzałości CMMI oznaczają w praktyce?

Poziomy opisują zachowanie, nie papierologię. Na niższych poziomach praca z danymi udaje się, bo konkretne osoby doprowadzają ją do skutku; wyższe poziomy oznaczają, że ten sam efekt powstaje niezależnie od tego, kto ma dyżur, bo proces jest zdefiniowany, mierzony i świadomie doskonalony.

Dlaczego 25 obszarów procesowych jest istotnych?

Zapobiegają temu, by dojrzałość była jedną mglistą oceną. Każdy obszar nazywa odrębną zdolność, więc ocena może pokazać, że Wasza praktyka pomiarowa jest mocna, a zarządzanie konfiguracją nie, co jest znacznie bardziej użyteczne niż ocena ogólna.

Jak wytworzyć dowody na potrzeby oceny CMMI?

Wbudujcie je w przepływ pracy, zamiast kompletować wcześniej. Kontrole działające na bieżąco — wyniki walidacji, zapisy Timeliness, historia zmian schematu — wytwarzają dowody jako produkt uboczny, co jest tańsze i trudniejsze do zakwestionowania niż dokument napisany pod audyt.

Czym CMMI różni się od modelu dojrzałości jakości danych?

CMMI ocenia dyscyplinę procesową w całym zarządzaniu danymi, łącznie z obszarami niezwiązanymi z jakością. Model dojrzałości jakości danych wchodzi głębiej wyłącznie w jakość. Zespoły często używają CMMI do oceny organizacyjnej, a modelu jakości do szczegółu operacyjnego.