Capability Maturity Model (Integration) jest stosowany nie tylko przez domy software'owe, ale także przez przemysł, organizacje publiczne, firmy usługowe. Dziś widać, że nie wystarczy go po prostu wdrożyć, ale trzeba zrobić to mądrze.

Niemal 20 lat funkcjonowania CMM pokazało dwa oblicza modelu. Jedno - dojrzałych organizacji, które strukturalizują swoje działanie i wykorzystują to jako przewagę konkurencyjną. Drugie - przebiurokratyzowanych molochów, które bardziej dbają o papiery niż o klienta, a gdy przychodzi co do czego, nie są w stanie dostarczyć na czas tego, czego oczekiwał klient za cenę, którą był w stanie zapłacić. Jaka jest więc prawda? Czy następca CMM, model CMMI, to realna szansa dla polskich firm informatycznych, by stały się bardziej konkurencyjne na globalnym rynku, czy kolejny buzzword, jakich setki widziała już informatyka?

Zachód czy wschód?

Rozwój modelu CMM, a dokładniej najpopularniejszej jego odmiany, tzw. Software Capability Maturity Model (SW-CMM), został przez macierzystą organizację zakończony. Zmierzch modelu CMM miał miejsce z końcem 2003 r. i ten rozdział jest już zamknięty. Software Engineering Institute (SEI) nie certyfikuje już audytorów, ani nie prowadzi kursów CMM, doradzając przejście na któryś z modeli CMMI.

Podsumowując ten pierwszy, pionierski okres trzeba powiedzieć, że rynek nie przyjął masowo CMM jako obowiązującego standardu, tak jak przyjął np. rodzinę standardów ISO 9000 czy ostatnio ITIL. CMM - skomplikowany i postrzegany jako biurokratyczny (niezależnie od tego, czy postrzeganie takie jest uzasadnione), zyskał wiernych odbiorców tylko w dwóch grupach przedsiębiorstw. Jedną stanowiły firmy pracujące na potrzeby amerykańskiego Departamentu Obrony (DoD) - ważnego i hojnego klienta przedsiębiorstw informatycznych od początku ich historii. Do drugiej grupy zaliczały się przedsiębiorstwa z tzw. indyjskiej Krzemowej Doliny. Potrafiły one zamienić CMM w prawdziwą broń masowego rażenia. Wraz z konkurencyjnymi cenami certyfikacja CMM na poziomie 5 sprawiła, że firmy z Indii opanowały rynek rozwoju aplikacji tworzonych na potrzeby organizacji z USA, Kanady i Unii Europejskiej. Ich dominacja w sektorze przedsiębiorstw stała się już na tyle wyraźna, że realnie zagroziły pozycji przedsiębiorstw informatycznych na polskim rynku.

A skoro o rodzimym rynku mowa - nasi dostawcy systemów, mimo licznych zapowiedzi i uruchomionych projektów (np. w Comarchu), nie zastosowali szeroko CMM jako oręża walki o klienta. Być może dlatego, że klienci nie byliby w stanie docenić wysiłku, który organizacja włożyła w zdobycie odpowiednich certyfikacji.

Z punktu widzenia praktyka nową jakość przyniosło pojawienie się modelu CMMI, następcy CMM. Choć brzmi to paradoksalnie, CMMI jest bardziej szczegółowy niż CMM, a jednocześnie bardziej uniwersalny. Uniwersalność osiągnięto przygotowując różne wersje tego samego modelu, np. skrót CMMI/SE/SW/IPPD/SS oznaczał model dojrzałości dla inżynierii systemów oraz inżynierii oprogramowania wraz z zarządzaniem zamówieniami (supplier sourcing) i zintegrowanym planem rozwoju (integrated process and product development). Zaś szczegółowe wytyczne dały przedsiębiorstwom bardziej konkretny punkt odniesienia do odpowiedzi na proste pytanie: działamy w zgodzie z modelem czy nie?

Tym samym model dojrzałości stał się dostępny nie tylko dla firm wytwarzających oprogramowanie, ale również dla integratorów, a nawet organizacji nieinformatycznych. Charakterystyczne, że sam standard lub jego elementy stosuje wiele przedsiębiorstw będących dojrzałymi klientami informatyki: instytucje finansowe, przemysł, firmy telekomunikacyjne, administracja publiczna. Może więc model CMMI nie zrobił ogromnej kariery wśród wielkich przedsiębiorstw software'owych, ale z pewnością w istotny sposób pomógł przedsiębiorstwom z dużymi działami IT. A to oni właśnie, klienci, ostatecznie kształtują obraz rynku informatycznego.

Procesy w erze zwinności

Przedsiębiorstwa chętniej niż kiedykolwiek patrzą dziś na tzw. zwinne (agile) metodyki. Trend rozpoczęty przez Kenta Becka i jego fundamentalną książkę o Extreme Programming (XP) znalazł wielu naśladowców. Z XP wyewoluowało APM (Agile Project Management) - quasi-metodyka prowadzenia przedsięwzięć, koncentrująca się na adaptywności, dostarczaniu wartości klientowi i silnych interakcjach w zespole.

Wydawałoby się, że nie ma dwóch bardziej odległych światów niż agile, zwinność rozumiana jako unikanie biurokracji i adaptywność oraz ustrukturalizowany, biurokratyczny proces oparty na dokumentacji. Nic bardziej błędnego. Codzienna praktyka firm dowiodła, że można jedno pożenić z drugim z zupełnie dobrym skutkiem.

Model CMMI sam z siebie nie nakazuje bowiem wielkich i kosztownych inwestycji w narzędzia, ani nie jest przeznaczony dla biurokratycznych molochów. Mówi "zbierz wymagania użytkowników", ale nie każe w tym celu stosować drogich narzędzi informatycznych ani papierowych, opasłych formatów. Wymagania zapisane w e-mailu rozdystrybuowanym wśród klientów i potwierdzone podsumowaniem ze spotkania równie dobrze spełniają zapisy standardu, co rozbudowany, wielodostępny system za pół miliona złotych. Projekt techniczny rozwiązania może być plikiem JPEG ze zdjęciem tablicy, na której kolorowymi pisakami narysowano rozwiązanie. Jeżeli standard mówi, że przed wyborem oferty trzeba przeanalizować kilka konkurencyjnych rozwiązań, to nie trzeba od razu powoływać komisji, statutów, przetargów i regulaminów - wystarczy prosty arkusz kalkulacyjny z kryteriami, wagami i nazwą wybranego dostawcy.

Wychodząc naprzeciw oczekiwaniom praktyków z przedsiębiorstw średnich czy wręcz małych, Software Engineering Institute opublikował aż trzy wersje SCAMPI, związanej z CMMI metody oceny dojrzałości przedsiębiorstwa. SCAMPI A to wersja pełna i oficjalna - wymaga zespołu, szczegółowej analizy, twardych dowodów. Wydaje się, że przeznaczona jest dla wielkich przedsiębiorstw budujących systemy mission critical. SCAMPI B, na pierwszy rzut oka przeznaczona dla średnich firm, nieco łagodzi oczekiwania formalne, choć nadal wymaga m.in. przeszkolonego zespołu. SCAMPI C to "najlżejsza" z metod oceny. Firma nadal musi wykazać się udokumentowanymi procesami i ustrukturalizowanym działaniem, ale tak naprawdę ważniejsza jest tzw. analiza luki (gap analysis) oraz rekomendacje i program nieustającego rozwoju.

CMMI w ujęciu SCAMPI C przywraca właściwą miarę rzeczy: koncentruje się na procesie, nie na narzędziu; oczekuje praktyk, nie dokumentacji (przynajmniej na niższych poziomach); wspiera komunikację, nie biurokrację. Czy to nie brzmi jak słynny Agile Manifesto?

Model á la carte

Wydaje się, że mijają czasy, kiedy "wdraża się CMMI". Być może w Bangalore nadal będzie istnieć grupa przedsiębiorstw, które za punkt honoru oraz element przewagi konkurencyjnej będą uznawać tzw. oficjalny (czyli wyznaczony według SCAMPI A) poziom dojrzałości. Jest niemal pewne, że Departament Obrony nie "poluzuje" swoich wymagań i firmy, takie jak Northop Grunman albo General Dynamics, nadal będą musiały legitymować się formalną certyfikacją CMMI na piątym, najwyższym poziomie.

Pozostali jednak nie muszą. W szczególności nic nie muszą odbiorcy informatyki, dla których każda metodologia i ideologia warta jest tyle, ile realna korzyść biznesowa z jej zastosowania. Przedsiębiorstwa dojrzały już, by stosować model dokładnie tak jak był on pomyślany, czyli jako punkt odniesienia, według którego należy mierzyć swoją dojrzałość, nie zaś przepis na sukces. Słowem, CMMI stosowany jest jako mapa pozwalająca stwierdzić miejsce, do którego się doszło, nie zaś cel sam w sobie.

Tak rozumiany CMMI z praktycznego punktu widzenia stanowi ogromną wartość dla przedsiębiorstwa. Określa, jakie cechy powinna posiadać dojrzała organizacja IT, choć nie opisuje, jak sprawić, by te cechy się pojawiły. Pole do popisu ma samo przedsiębiorstwo, a w szczególności grupa zajmują-ca się zmianą organizacyjną.

No właśnie, jak?

Jak więc strukturalizować i systematyzować swoje działanie, aby prowadzić do poprawienia skuteczności działania, a nie do wzrostu tzw. papierologii? Najlepiej stosując słynną zasadę Pareto, tj. dobrze zidentyfikować właściwe 20%, które da 80% zysku.

Po stronie odbiorcy te 20% najczęściej związane jest z właściwym prowadzeniem przedsięwzięć informatycznych. Organizacja, która kupuje systemy informatyczne, musi przede wszystkim dobrze zdefiniować wymagania do systemu, następnie zaplanować i przeprowadzić projekt, by na jego końcu narzędzie przetestować i wdrożyć.

To implikuje rozpoczęcie od procesów związanych z wymaganiami i projektem (Requirements Management, Project Planning, Project Monitoring and Control) z poziomu 2 oraz wybranych z poziomu 3 (Requirements Development, Verification, Validation). Intensywna współpraca z dostawcą lub grupą dostawców wymusza także wzięcie pod kontrolę procesów zamawiania i odbierania produktów i usług (Supplier Management, Integrated Supplier Management) oraz zarządzania ryzykiem (Risk Management) z poziomu 3. Poziom 4 wymaga profesjonalnych narzędzi - nie sposób zbierać miar bez oparcia procesów na systemie informatycznym. Takie systemy oczywiście są dostępne, natomiast trzeba pamiętać, że kosztują dużo i wydatek ten niekoniecznie jest uzasadniony z komercyjnego punktu widzenia.

Po stronie dostawcy wdrożenie CMMI można zacząć od stabilizacji produktu wychodzącego z "fabryki". Każda firma informatyczna zna to uczucie, kiedy zbliża się kolejny termin dostarczenia oprogramowania obiecanego klientowi, a system nie chce się "poskładać" w jeden kawałek. Kiedy już zostanie dostarczony do klientów, natychmiast odmawia posłuszeństwa, wywołując lawinę telefonów i serię poprawek. Dlatego w firmach informatycznych warto zacząć od zdefiniowania procesów wytwórczych oprogramowania (np. procesy Configuration Management, Technical Solution oraz Product Integration), nie zapominając o procesach kontrolnych (Process and Product Quality Assurance. Verification). Mając ustabilizowany, szeroko rozumiany proces wytwórczy można zająć się pozostałymi obszarami. Jednak na pewno nikogo nie stać na wysiłek, jaki trzeba włożyć w pozostałe procesy, jeśli nie ma "zabezpieczonych tyłów".

Oczywiście nie da się całkowicie wybiórczo traktować standardu, np. wdrażając liczne praktyki poziomu 3 bez porządnego "przygotowania gruntu" na poziomie 2. Nie da się wdrożyć pomiarów (cały poziom 4), nie mając przygotowanego aparatu pomiarowego i analitycznego (obszar Measurement and Analysis na poziomie 2). Niemniej każde przedsięwzięcie, a takim jest strukturalizacja pracy działu informatyki, potrzebuje szybkiego i widocznego sukcesu. A właśnie wdrożenie właściwych 20% i pokazanie, że przynosi to efekty, da ów sukces zespołowi.

Najpierw decyzja

Każda droga zaczyna się od pierwszego kroku. W przypadku CMMI powinna to być decyzja podjęta na najwyższym szczeblu zarządczym. Może ona brzmieć "Jesteśmy zdeterminowani, by osiągnąć poziom 5 według standardu CMMI-DEV 1.2". Ale znacznie lepiej, gdy brzmi:

"Jesteśmy zdeterminowani, by podnieść zarządzanie działem informatyki na wyższy poziom dojrzałości. W tym celu strukturalizujemy swoje działanie, definiujemy i opisujemy procesy, wprowadzając elementarny porządek w kwestiach zakupu, rozwoju i wdrażania systemów. Jesteśmy skłonni przeznaczyć na to czas i pieniądze. Użyjemy modelu CMMI, aby określić, dokąd zmierzamy i jak dalece jesteśmy zaangażowani, ale oczekujemy też realnych wyników w wymiarze produktywności, efektywności w działaniu i większej przewidywalności".

Bo przecież o korzyść biznesową, nie o sam standard chodzi.