software CMMI ontwikkeling
i
CMMI voor acquisitie
Volwassenheids
Tot voor kort was er geen methodische aanpak om outsourcing-
model garandeert
processen in de praktijk op een gestructureerde manier te verbe-
goed opdracht
teren. Sinds kort is er echter een specifiek volwassenheidsmodel
geverschap
voor outsourcing: CMMI voor acquisitie. De auteurs zetten uiteen hoe dit model helpt bij het beheersen van outsourcing.
informatie / juni 2009
Jan Jaap Cannegieter, Wouter Raemaekers en Rini van Solingen
46
In de afgelopen jaren hebben veel organisaties ervaring opgedaan met het outsourcen van systeemontwikkeling, -testen en -beheer. Deze ervaringen zijn in diverse publicaties aan de hand van succes- en faalfactoren vastgelegd. Helaas geven deze publicaties geen methodische aanpak om outsourcingprocessen in de praktijk op een gestructureerde manier te verbeteren. Sinds kort is er echter een specifiek volwassenheidsmodel voor outsourcing vrijgegeven binnen de verzameling van CMMI-modellen: CMMI voor acquisitie (Software Engineering Institute, 2007). De eerste praktijkervaringen met dit model zijn positief. Het CMMI voor acquisitie is een goed hulpmiddel bij het inrichten van goed opdrachtgeverschap. Voordat we ingaan op het ontstaan van het CMMI voor acquisitie kort iets over de naam en de toepasbaarheid van het CMMI voor acquisitie. ‘Acquisition’ in de Amerikaanse betekenis heeft betrekking op twee activiteiten: beheersing van outsourcing en aanschaf van standaardpakketten. De achterliggende gedachte is dat organisaties bij acquisitie besluiten niet zelf de gewenste oplossing te realiseren maar de oplossing te betrekken van een derde partij. De auteurs hebben ervaring met de aanschaf en implementatie van standaardpakketten en met de uitbesteding van systeemontwikkeling en naar hun mening is het CMMI voor acquisitie in beide situaties te gebruiken. Hier is een parallel te trekken met het CMMI voor ontwikkeling, dat bruikbaar is voor zowel softwareontwikkeling, systeemontwikke-
ling als hardwareontwikkeling. Zo is het CMMI voor acquisitie bruikbaar voor zowel de aanschaf van standaardpakketten als het beheersen van de uitbesteding van systeemontwikkeling. We gaan hier specifiek in op de bruikbaarheid voor het beheersen van outsourcing.
Inhoud CMMI voor acquisitie Het CMMI voor acquisitie bestaat uit 22 procesgebieden: 16 kernprocesgebieden en 6 procesgebieden die specifiek zijn voor acquisitie. We kijken hier naar de procesgebieden die specifiek zijn voor het CMMI voor acquisitie: • Acquisitie eisenontwikkeling; • Leveranciersselectie en overeenkomstontwikkeling; • Overeenkomstmanagement; • Acquisitie technisch management; • Acquisitie validatie; • Acquisitie verificatie. Alle procesgebieden, onderverdeeld naar volwassenheidsniveau, zijn opgenomen in het kader ‘CMMI voor acquisitie: stapsgewijze representatie’. De inhoud en het gebruik van de specifieke procesgebieden van het CMMI voor acquisitie worden toegelicht aan de hand van de outsourcingactiviteiten: definitie, beheersing en acceptatie (zie figuur 1, Cannegieter e.a., 2009). De definitiefase omvat de procesgebieden Acquisitie eisenontwikkeling en Leveranciersselectie
Samenvatting Het CMMI voor acquisitie benoemt de verantwoordelijkheden van de opdrachtgever in een outsourcingrelatie helder en eenduidig. Daardoor is het een goed hulpmiddel om opdrachtgeverschap in te vullen. In tegenstelling tot enkele andere methoden voor het beheersen van outsourcing beslaat het model het hele traject van outsourcing en is onafhankelijk van de fase waarin de outsourcing zich bevindt.
Beheersing: • Overeenkomstmanagement • Acquisitie technisch management
Figuur 1. CMMI voor acquisitie: procesgebieden in outsourcingproces en overeenkomstontwikkeling. Het doel van Acquisitie eisenontwikkeling is het ontwikkelen en analyseren van klanteisen en contractuele eisen. Met uitzondering van het uitwerken van de eisen in contractuele eisen is dit procesgebied identiek aan het procesgebied Eisenontwikkeling in het CMMI voor ontwikkeling. Het doel van Leveranciersselectie en overeen komstontwikkeling is het opstellen van selectieeisen, het selecteren van een of meer leveranciers voor het leveren van het product of de dienst en het vaststellen, gebruiken en onderhouden van de leveranciersovereenkomst. Selectie dient dus te gebeuren op basis van een pakket van selectieeisen, dat ter beschikking wordt gesteld aan de potentiële leveranciers. De leveranciers worden geselecteerd op basis van een formele evaluatie, waarna de leveranciersovereenkomst wordt opgesteld. Een sterk punt hierbij is dat het CMMI voor acquisitie expliciet vereist dat zowel de opdrachtgever als de leverancier aantoont dat deze de inhoud van de overeenkomst ook daadwerkelijk begrijpt. Dat lijkt wellicht een open deur, maar de praktijk laat maar al te vaak zien dat betrokkenen elkaar niet goed begrijpen, waardoor ontevredenheid in de relatie ontstaat.
Volwassenheidsniveau 1 – Initieel Niveau 1 bevat zoals gebruikelijk geen procesgebieden. Volwassenheidsniveau 2 – Beheerst • Overeenkomstmanagement • Acquisitie eisenontwikkeling • Leveranciersselectie en overeenkomstontwikkeling • Eisenmanagement • Projectplanning • Projectmonitoring en projectbeheersing • Meting en analyse • Proces- en productkwaliteitsborging • Configuratiemanagement Volwassenheidsniveau 3 – Gedefinieerd • Acquisitie technisch management • Acquisitie verificatie • Acquisitie validatie • Alternatievenanalyse en oplossingskeuze • Geïntegreerd projectmanagement • Organisatiebrede procesfocus • Organisatiebrede procesdefinitie • Organisatiebrede training • Risicomanagement Volwassenheidsniveau 4 – Kwantitatief beheerst • Organisatiebrede procesprestatie • Kwantitatief projectmanagement Volwassenheidsniveau 5 – Optimaliserend • Organisatiebrede innovatie en borging • Causale probleemanalyse en probleemoplossing
informatie / juni 2009
Acceptatie: • Acquisitie validatie • Acquisitie verificatie
Definitie: • Acquisitie eisenontwikkeling • Leveranciersselectie en overeenkomstontwikkeling
Te acquireren product of uit te besteden ontwikkeling
CMMI voor acquisitie: stapsgewijze representatie
47
CMMI
i
informatie / juni 2009
De evolutie van het CMMI
48
Begin jaren negentig publiceerde het Software Engineering Institute (SEI) van de Carnegie Mellon University in Pittsburgh het Capability Maturity Model for Software (Software CMM). Dit volwassenheidsmodel voor sofwareontwikkeling werd in de jaren negentig de de-facto standaard voor het optimaliseren van softwareontwikkelprocessen. Vele organisaties hebben het geïmplementeerd en hebben daarmee grote voordelen behaald. Het succes van het CMM is te verklaren door onder meer de volgende drie factoren. Ten eerste is de opzet met vijf volwassenheidsniveaus eenvoudig en duidelijk. De volwassenheidsniveaus zijn logisch geordend en bieden een goede basis om meetbare doelstellingen te formuleren en zodoende stapsgewijs te verbeteren. Ten tweede biedt het model generieke eisen voor ‘goede’ systeemontwikkelprocessen, in het CMM verwoord in de vorm van uit te voeren activiteiten en algemene kenmerken. Door eisen te formuleren in plaats van gedetailleerde processen voor te schrijven biedt het CMM organisaties de mogelijkheid zelf hun werkwijzen te definiëren, binnen de grenzen van de best practices die verwoord zijn in het model. De eisen zijn zodanig algemeen van aard dat ze op alle software ontwikkelende organisaties van toepassing moeten zijn; de onderscheidende kenmerken van de organisatie komen tot uitdrukking in de invulling die de organisatie zelf bepaalt. De derde factor is de onafhankelijkheid van methoden, tools of leveranciers. Het CMM staat boven de diverse marktpartijen en of je nu DSDM, RUP, PRINCE2, SCRUM of een zelf ontwikkelde aanpak of een combinatie van methoden gebruikt, het CMM biedt in alle gevallen hulp. Immers, het biedt een referentie waaraan de eigen werkwijze gespiegeld kan worden en waarmee verbeterpunten gevonden kunnen worden. Als gevolg van het succes van het softwareCMM zijn er diverse andere CMM’s ontstaan, zoals CMM’s voor hardwareontwikkeling,
systeemontwikkeling, productontwikkeling en zelfs personeelsmanagement. Lang niet alle CMM’s hadden een officiële status of waren gepubliceerd door het SEI. Voorbeelden hiervan zijn het Testing Maturity Model en het IT-Service CMM. Het laatste model is in Nederland ontwikkeld aan de Vrije Universiteit (Niessink e.a., 2005). Na tien jaar ervaring opgedaan te hebben en om de wildgroei van CMM’s tegen te gaan heeft het SEI in 2001 het CMMI voor systeemontwikkeling, softwareontwikkeling en geïntegreerde product- en procesontwikkeling versie 1.1 gepubliceerd. CMMI staat voor CMM Integration. In de naam zit een van de doelstellingen van het CMMI: het integreren van verschillende CMM’s. De achterliggende gedachte is dat de eisen aan bijvoorbeeld het ontwikkelen van software, hardware en systemen feitelijk op veel onderdelen hetzelfde zijn en er dus geen volledig aparte modellen voor nodig zijn. Zo worden voor al deze disciplines requirements opgesteld waar het uiteindelijke product aan voldoet, maak je een ontwerp en stel je vast dat het product aan de eisen voldoet. Het op redelijk abstract niveau formuleren van eisen maakte het mogelijk de CMM’s voor software, hardware en systemen te integreren. De tweede doelstelling van het uitbrengen van het CMMI is het vereenvoudigen van de onderliggende structuur. Hoewel de hoofdstructuur met procesgebieden (clusters van gerelateerde activiteiten) en volwassenheidsniveaus van het CMM eenvoudig is, is de onderliggende structuur van het CMM complex en eigenlijk alleen voor specialisten begrijpelijk. De structuur van het CMMI is een stuk eenvoudiger. Zo zijn de eisen aan volwassen processen in het CMMI verwoord in de vorm van doelen (goals) en praktijken (practices). Hierbij wordt onderscheid gemaakt tussen doelen en praktijken die specifiek zijn voor een procesgebied en doelen en praktijken die voor alle procesgebieden hetzelfde zijn.
De beheersingsfase bestaat uit Overeenkomstmanagement en Acquisitie technisch management. Het doel van Overeenkomstmanagement is zeker te stellen dat de leverancier en de opdrachtgever presteren conform de voorwaarden van de leveringsovereenkomst. De leveranciersovereenkomst staat weliswaar centraal, maar er dient ook vastgesteld te worden dat aan de leveringsovereenkomst wordt voldaan voordat het product kan worden geaccepteerd. Het doel van Acquisitie technisch management is het evalueren van de technische oplossing van de leverancier en het beheersen van de interfaces van die oplossing. Ook in technisch opzicht dient de opdrachtgever dus betrokken te blijven bij het project. In de praktijk gaat het daar vaak mis: opdrachtgevers gaan er nogal eens van uit dat een leverancier zonder meer de beste oplossing oplevert. Ondanks diens professionaliteit is nooit gegarandeerd dat een leverancier die technische oplossing kiest die optimaal passend is voor de opdrachtgever, eenvoudigweg omdat de leverancier noch op technisch gebied, noch op inhoudelijk gebied zoveel specifieke kennis heeft als de opdrachtgever. Bovendien hebben leveranciers ook een commercieel belang, waardoor snellere en goedkopere oplossingen de voorkeur krijgen zolang dit binnen de afgesproken kaders valt. De acceptatiefase bestaat uit Acquisitie validatie en Acquisitie verificatie. Het doel van Acquisitie validatie is om aan te tonen dat een aangeschaft product of service de bedoelde functie vervult wanneer het in zijn bedoelde omgeving wordt geplaatst. Het doel van Acquisitie verificatie is zeker te stellen dat geselecteerde (tussen)producten voldoen aan hun gespecificeerde eisen. In de praktijk worden deze procesgebieden nogal eens gecombineerd. De reviews en tests die worden uitgevoerd hebben dan twee doelen: ten eerste aantonen dat aan de gespecificeerde eisen is voldaan en daarbovenop aantonen dat het systeem de bedoelde functie vervult. Figuur 1 is omwille van de eenvoud zodanig getekend dat het lijkt
In 2006 is een verbeterde versie van het CMMI voor ontwikkeling gepubliceerd, versie 1.2, met een aantal verbeteringen ten opzichte van versie 1.1. Voor meer informatie over het CMMI voor ontwikkeling wordt verwezen naar De kleine CMMI voor ontwikkeling (Cannegieter & Van Solingen, 2007) en de laatste versie van het CMMI voor ontwikkeling (Software Engineering Institute, 2006).
of Acquisitie validatie en Acquisitie verificatie pas beginnen als het systeem is opgeleverd. In de praktijk beginnen de Acquisitie validatie- en Acquisitie verificatie-activiteiten echter al eerder in de vorm van tussentijdse reviews. Feitelijk hoort de acceptatie al onderdeel te zijn van de beheersing en begint een goede acceptatie eigenlijk al bij een goede definitie. Naast de zes specifieke acquisitieprocesgebieden bestaat het CMMI voor acquisitie zoals gezegd ook uit kernprocesgebieden. Hiermee kunnen onder andere projecten worden beheerst met behulp van bijvoorbeeld Projectplanning en Projectmonitoring en -beheersing. Ook kunnen de processen organisatiebreed worden gedefinieerd en verbeterd met onder andere Organisatiebrede procesdefinitie en Organisatiebrede procesfocus. Daarnaast zijn ook de relevante ondersteunende procesgebieden opgenomen in het CMMI voor acquisitie, zoals Configuratiemanagement, Proces- en productkwaliteitsborging, en Meting en analyse.
Ervaringen in de praktijk Er is in Nederland de afgelopen tijd ervaring opgedaan met het CMMI voor acquisitie in de vorm van assessments die betrekking hebben outsourcing van systeemontwikkeling. Uit deze assessments komt naar voren dat met behulp van het CMMI voor acquisitie heel goed de vinger op de zere plek gelegd wordt in opdrachtgeverprocessen. Zo komt uit de uitgevoerde assessments naar voren dat er in de praktijk wel vaak aandacht is voor de juridische kant van contracten, maar dat inhoudelijke overeenstemming nogal eens ontbreekt. De focus van het procesgebied Acquisitie eisenontwikkeling op de inhoudelijke kant voorkomt dit. Uit de praktijk blijkt ook dat de leveranciersselectie vaak wel redelijk tot zeer professioneel is ingericht, maar dat de aandacht daarna echter lijkt te verslappen. Het nakomen van de overeenkomst en het technisch management vanuit de opdrachtge-
informatie / juni 2009
De derde doelstelling van het CMMI was om naast het aanbieden van een stapsgewijze representatie die de volgorde voorschrijft waarin procesgebieden moeten worden geïmplementeerd, een flexibele representatie toe te voegen waarmee organisaties zelf een volgorde kunnen bepalen. Hiermee werd voldaan aan de ISO-norm 15504 voor Software Process Assessments.
49
CMMI
i
CMMI-framework Het CMMI voor ontwikkeling is een hele verbetering ten opzichte van het Software CMM. Dat blijkt onder andere uit het gebruik van het CMMI ten opzichte van het CMM. In 2006 bleek uit onderzoek dat 85 procent van de organisaties die gebruikmaken van een volwassenheidsmodel, gebruikmaakt van het CMMI (Cannegieter, 2006). De toepasbaarheid van het CMMI voor ontwikkeling is echter wel beperkt tot softwareontwikkeling, hardwareontwikkeling en systeemontwikkeling. Voor bijvoorbeeld outsourcing en servicemanagement is het niet goed bruikbaar. Om dit mogelijk te maken diende het CMMI uitgebreid te worden of moesten er nieuwe varianten ontwikkeld worden. Het SEI koos ervoor nieuwe varianten, zogenaamde constellaties, te gaan ontwikkelen. Bij het ontstaan van nieuwe CMM’s had men
gezien dat de structuur van het model bij nieuwe CMM’s niet consequent werd toegepast. Dit kwam de begrijpelijkheid en bruikbaarheid van nieuwe varianten niet ten goede. Om dit te ondervangen heeft het SEI eerst het CMMI-framework ontwikkeld. Het CMMIframework definieert de structuur van officiële CMMI-constellaties; hiermee wordt het gebruik van verschillende CMMI-modellen naast elkaar of in combinatie met elkaar vereenvoudigd. Naast de beschrijving van de structuur van CMMI-constellaties bevat het framework ook kernprocesgebieden, procesgebieden die voor alle constellaties hetzelfde zijn en derhalve onafhankelijk van het toepassingsgebied van de betreffende constellatie. De kernprocesgebieden, procesgebieden van het CMMI voor acquisitie en de procesgebieden van het CMMI voor ontwikkeling zijn weergegeven in figuur 2.
kernprocesgebieden CMMI-framework
speficieke procesgebieden CMMI voor acquisitie
speficieke procesgebieden CMMI voor ontwikkeling
Causale probleemanalyse en probleemoplossing
Acquisitie eisenontwikkeling
Eisenontwikkeling
Configuratiemanagement
Leveranciersselectie en overeenkomstontwikkeling
Leveranciersmanagement
Alternatievenanalyse en oplossingskeuze
Overeenkomstmanagement
Technische oplossing
Geïntegreerd projectmanagement
Acquisitie technisch management
Productintegratie
Meting en analyse
Acquisitie validatie
Verificatie
Organisatiebrede innovatie en borging
Acquisitie verificatie
Validatie
Organisatiebrede procesdefinitie Organisatiebrede procesfocus Organisatiebrede procesprestatie Organisatiebrede training Projectmonitoring en projectbeheersing
informatie / juni 2009
Projectplanning
50
Proces- en productkwaliteitsborging Kwantitatief projectmanagement Eisenmanagement Risicomanagement
Figuur 2. Kernprocesgebieden van het CMMI-framework
»In tegenstelling tot enkele andere methoden beslaat het CMMI voor acquisitie het hele traject van outsourcing
«
Reviewer Jan Willem Rietdijk
Literatuur Cannegieter, H.J.J. (2006). CMMI, de stand van zaken. Presentatie tijdens symposium over ‘De kleine CMMI’, 9 februari 2006. Cannegieter, H.J.J., W.L.D. Raemaekers & R. van Solingen (2009). De kleine CMMI voor acquisitie. Den Haag: Academic Service. Cannegieter, H.J.J.& R. van Solingen (2007). De kleine CMMI voor ontwikkeling. Den Haag: Academic Service. Niessink, F., e.a. (2005). The IT Service Capability Maturity Model. Software Engineering Institute (2006). CMMI for Development,Version 1.2, CMU/SEI-2006-TR-008. Software Engineering Institute (2007). CMMI for Acquisition, Version 1.2, CMU/SEI-2007-TR-017. Jan Jaap Cannegieter is adjunct-directeur van SYSQA B.V., een onafhankelijke organisatie gespecialiseerd in het testen van informatiesystemen, bewaken van de kwaliteit in ICT-projecten en verbeteren van de prestaties van ICT-organisaties. E-mail:
[email protected]. Wouter Raemaekers is consultant bij DNV-CIBIT, een onafhankelijk adviesbureau dat zich richt op het analyseren en oplossen van strategische, organisatorische én technische ICT-vraagstukken, en het introduceren van duurzame verbeteringen in ICT-organisaties. E-mail:
[email protected]. Rini van Solingen is chief technical officer bij Mavim, een leverancier van softwareproducten voor Business Process Communication, en is tevens deeltijdhoofddocent aan de Technische Universiteit Delft op het vakgebied van Globally Distributed Software Engineering. E-mail:
[email protected]. De drie auteurs hebben gezamenlijk De kleine CMMI voor acquisitie (2009) uitgebracht, waarin het model uitgebreider beschreven wordt.
informatie / juni 2009
ver zijn voor verbetering vatbaar. Het CMMI voor acquisitie benoemt deze zaken. Daarnaast gaan opdrachtgevers er in de praktijk vaak van uit dat de leverancier alle noodzakelijke reviews en tests uitvoert. Omdat de opdrachtgever verantwoordelijk blijft voor het soepel verlopen van de eigen businessprocessen, is dezelfde opdrachtgever ook verantwoordelijk voor een deel van de verificatie en validatie. Kortom, het CMMI voor acquisitie benoemt de verantwoordelijkheden van de opdrachtgever in een outsourcingrelatie helder en eenduidig. Daardoor is het een goed hulpmiddel om goed opdrachtgeverschap in te vullen. In tegenstelling tot enkele andere methoden voor het beheersen van outsourcing of het aanpakken van leveranciers beslaat het CMMI voor acquisitie het hele traject van outsourcing. Sterker nog, het is onafhankelijk van de fase waar de outsourcing zich op een moment in bevindt. Daarbij behoudt het de sterke punten van volwassenheidsmodellen zoals verwoord in het begin van dit artikel. Het CMMI voor acquisitie kan derhalve worden gezien als een volwassenheidsmodel voor opdrachtgevers, het CMMI voor ontwikkeling als een volwassenheidsmodel voor leveranciers. In die zin voegt het CMMI voor acquisitie veel toe aan wat er al is aan volwassenheidsmodellen.
51
