Joris is 15 jaar geleden gestart met een ICT-bedrijf dat maatwerkapplicaties ontwikkelt. Joris wil zijn klanten kwaliteit bieden en natuurlijk ook wat verdienen. Tot op heden gaan de zaken goed. Maar toch,… er zijn nogal wat incidenten. Daarvan wordt Joris niet vrolijk.
Zo zijn er heel wat klanten die klagen over te late opleveringen. En als de software is opgeleverd en de klant de applicatie gaat gebruiken, dan zijn er geregeld discussies over hoe het systeem werkt. De klanten hebben het over fouten in het systeem.
Joris stelt vast dat de oorzaken heel divers zijn. Soms heeft de klant verkeerde informatie gegeven, soms ligt het aan de manier waarop het systeem wordt gebruikt, soms is het gebrekkige kennis bij de gebruikers van het systeem, en regelmatig is het een fout in het ontwerp of in de programmacode. Joris heeft al veel geïnvesteerd in het testproces en in opleidingen van zijn medewerkers. Eigenlijk vindt hij dat het testen wel heel veel tijd kost en vooral ook het oplossen van de gevonden fouten is erg tijdrovend. Dit kost hem een groot deel van de begrote winst. en daarnaast extra doorlooptijd. Dat leidt dan weer tot telefoontjes van ontevreden opdrachtgevers.
Joris besluit deze problemen aan te pakken en zich te onderscheiden van zijn concurrenten door wel altijd op tijd op te leveren en te streven naar een 8 van zijn klanten voor de producten die hij oplevert. De vragen die hij zich stelt zijn: Welke kwaliteit willen mijn klanten? Hoe spreek ik dat af? En vooral: Hoe zorg ik ervoor dat mijn organisatie die kwaliteit dan ook levert? Joris gaat op onderzoek uit en vindt informatie op internet, in de literatuur en bij collega’s.
Kwaliteitsbeleving is heel subjectief. Wat de één belangrijk vindt, is voor de ander irrelevant. Hetzelfde product wordt door de ene consument als heel goed ervaren, terwijl een ander het volstrekt waardeloos vindt. Kwaliteit is geen eenduidig begrip. Er zijn volgens Garvin vijf soorten definities van kwaliteit te onderscheiden:
Praten over kwaliteit gaat dan ook nergens over zolang je het begrip kwaliteit geen handen en voeten hebt gegeven.
Nou, dat helpt, maar niet heus. Als Joris erover gaat nadenken komt hij erachter, dat zijn klanten heel divers zijn in hun eisen- en wensenpakket. De één vindt het essentieel dat de nieuwe applicatie op tijd wordt opgeleverd, omdat die nodig is voor een groot verandertraject. Een ander wil dat het systeem heel gemakkelijk te gebruiken is, omdat er veel met flexwerkers wordt gewerkt. Daarnaast is het zo dat alle klanten verwachten dat het systeem het “gewoon doet”, dat alles een beetje snel werkt en dat het dezelfde “look & feel” heeft als gangbare marktproducten. Joris komt tot de conclusie dat hij “de” kwaliteit vooral ook zelf moet definiëren; als leverancier wil hij kunnen instaan voor zijn producten. Verder zijn er klantspecifieke kwaliteitseisen. Wellicht is het zinvol daarvan een checklist te maken om ze te inventariseren. Dan is de kans dat er wat wordt vergeten een stuk kleiner.
Hoe kun je er als organisatie voor zorgen dat je producten en diensten de gewenste kwaliteit hebben? Er zijn twee benaderingen denkbaar:
Het huidige kwaliteitsdenken stimuleert een procesbenadering. De gedachte is dat als een organisatie het proces beheerst, de resultaten van dat proces betrouwbaar zijn. Dit denken komt voort uit de systeemtheorie (zie figuur).
In de figuur wordt de organisatie afgebeeld als een proces dat input (van leveranciers) transformeert naar output (voor klanten). Het proces wordt bestuurd met behulp van informatie over de input, het proces en de output. Het besturend orgaan regelt dat het proces wordt bijgestuurd als dat nodig is.
ISO 9001:2008 is een voorbeeld van een kwaliteitsnorm die het procesdenken sterk stimuleert. De norm stelt dat de vele onderling verbonden activiteiten bestuurd moeten worden. Een kwaliteitsmanagementsysteem dat gebaseerd is op de procesbenadering verhoogt de klanttevredenheid door op een efficiënte wijze te voldoen aan de eisen.
Meestal is er sprake van een combinatie van productcontrole en procesbeheersing. De optimale mix is sterk afhankelijk van:
Joris denkt diep na. Hij heeft zich gespecialiseerd in maatwerkapplicaties. Elk product dat hij maakt is uniek. Door middel van gestructureerde testen stelt hij bij elk product opnieuw vast of de applicatie doet wat ze doen moet. Een aantal jaren geleden heeft hij met behulp van TMap zijn testprocessen verbeterd. Probleem is nog wel dat niet van te voren altijd goed is afgesproken aan welke kwaliteitseisen elke applicatie moet voldoen. Daar valt nog wel wat te verbeteren.
En Joris vraagt zich af of hij ook niet meer moet doen aan procesbeheersing. Immers de kosten van het testen, en zeker de herstelkosten daarna, zijn een bron van zorg. Joris gaat verder op zoek. Met succes.
Dezelfde Garvin die de perspectieven van het begrip Kwaliteit heeft beschreven, heeft ook een model opgesteld om productkwaliteit te beschrijven. Hij kiest hiervoor acht dimensies.
Per bedrijfstak kun je productkwaliteit specifieker rubriceren. Als voorbeeld het product “software”. Velen hebben moeite het begrip software überhaupt te definiëren (gaat het om de executable, is het inclusief broncode, hoort documentatie erbij, moet het ook werken, etc.). Nog lastiger is het om de kwaliteit te definiëren: de ISO 9126 norm bevat een model voor het definiëren van softwareproductkwaliteit. Deze norm onderscheidt 6 hoofdeigenschappen, verder uitgewerkt tot 32 eigenschappen in het extended ISO 9126 model.
Mooi, denkt Joris, hiermee heb ik een checklist om onze eigen kwaliteitsstandaard te definiëren en om de klantspecifieke kwaliteitseisen te bespreken. En hij zoekt weer door en vindt.
Alleen eindcontroles uitvoeren is erg duur. Veel producten worden afgekeurd en worden weggegooid of hersteld. Vaak is het veel effectiever om tussentijdse productcontroles uit te voeren. Herstelkosten nemen exponentieel toe naarmate een fout later wordt ontdekt.
Böhm heeft ICT-projecten onderzocht en gemeten hoeveel goedkoper het is om in een vroegtijdig stadium fouten op te sporen en te herstellen dan tijdens het gebruik, Zo blijkt het een factor 40 tot 100 goedkoper te zijn om tijdens de requirementsanalyse een fout te herstellen dan tijdens productie.
Een veel gebruikte manier om de kwaliteit van tussenproducten te verbeteren bij software ontwikkeling is de reviewtechniek. Er zijn verschillende redenen om reviews toe te passen. De voornaamste is evalueren van opgeleverde tussen- of eindproducten. Daarnaast worden reviews ook gehouden om ideeën uit te wisselen en om consensus (draagvlak) te verkrijgen voor deze ideeën. Nog een andere reden is anderen informeren over een bepaald product, eventuele problemen bloot leggen en mogelijke oplossingen bespreken.
Voor reviews op specificerende documenten (zoals bij voorbeeld requirements, architecturen en ontwerpen) bestaan diverse reviewtechnieken. De meest uiteenlopende zijn:
Dit spreekt Joris aan. Veel problemen bleken achteraf te liggen aan onduidelijke afspraken met de klant. Joris besluit direct om elke uitgevoerde requirements analyse te laten reviewen door 2 senior medewerkers.
De bedoeling van proceskwaliteit is om op consistente wijze goede producten en diensten te maken, door een goede beheersing van de werking van de processen. Hoe ”goed” is het proces:
Het centrale paradigma is, dat productkwaliteit niet bepaald wordt door de eindcontrole (bij voorbeeld de acceptatietest), maar door het gehele voorgaande proces. Veel kwaliteitsliteratuur gaat dan ook over de inrichting van processen.
De ISO 9001 norm beschrijft aan welke minimale normen de processen in een organisatie dienen te voldoen om een gegarandeerde kwaliteit te kunnen leveren. Dit blijft redelijk basaal. De processen dienen beschreven te zijn, de procedures moeten geaccordeerd zijn en de processen moeten aantoonbaar geïmplementeerd zijn. Je hoeft vaak geen grote organisatorische veranderingen door te voeren om hieraan te voldoen. Een belangrijke eis in ISO 9001:2008 is om continu met verbetering bezig te zijn.
Voor de IT-sector is een CMMi een goede standaard voor proceskwaliteit. Het primaire doel hiervan is de processen te identificeren en te definiëren die essentieel zijn voor software engineering, en die daarom geëvalueerd moeten worden om de volwassenheid van de organisatie vast te stellen.
Inmiddels is het 1 jaar later. Joris heeft de plan do check act cyclus een aantal keren doorlopen. Het requirements management proces loopt nu uitstekend. Joris heeft hiervoor gebruik gemaakt van het CMMi model en wel het onderdeel Requirements Management (REQM). Vooral het managen van de requirements tijdens het project is in het verleden niet goed gebeurd. Wijzigingen van de eisen van de klant werden wel afgesproken maar niet goed beoordeeld op de impact. Dit gebeurt nu wel goed.
Het effect van het verbeteren van het requirements management proces is dat de laatste opleveringen perfect naar de zin van de klanten waren. Zij vertellen nu zelfs aan andere organisaties hierover. Dat schiet tenminste op.
Ben je nog niet zover? Joris denkt intussen alweer na over een volgende stap. Want wat hij nu heeft bereikt wil hij natuurlijk ook zo houden.