PRM: Product Risk Management - Deel 2: kwantificeren

Mijn vorige blog 'Product Risico Analyse, een nieuwe Discipline?' ging over PRM (Product Risico Management) wat is dat en voor wie?

Daarbij ben ik tot de conclusie gekomen dat PRM van belang is voor de business, maar PRM doorgaans niet binnen de scope van een project valt en dus defacto snel over het hoofd wordt gezien.

Definitie: Product Risico = de schade, die het product de business kan aandoen.

Nu wil ik stil staan bij het kwantificeren van het Product Risico vanuit business perspectief. Let wel: er is ook een technische kijk op productrisico's, maar daar hebben wij het niet over. Deze blog beschouwt het product risico vanuit het business perspectief.

Hoe groot is de eventuele schade? De eventuele schade kan simpelweg worden onderverdeeld in drie soorten schade:

1. Directe schade Dit is de schade, die een bedrijf leidt door de effecten van het defecte product. Dit zijn onder meer de personeelskosten, waar geen productie meer tegenover staat. Ook een groter aantal support calls van klanten ten gevolge van een computerstoring (productrisico) kunnen leiden tot kosten. Uiteindelijk moet ook gedacht worden aan de kosten, die een bedrijf maakt om de schade te herstellen en de effecten (productie achterstand etc.) te compenseren. Dit alles is vrij eenvoudig in harde euro's te schatten en uit te drukken.

2. Indirecte schade Dit is de schade, die andere bedrijven of organisaties leiden ten gevolge van het defecte software product. Dat zijn bij voorbeeld toeleveranciers en afnemers, maar ook ketenpartners

in distributie ketens. Doorgaans leidt dit soort schade tot claims en die zijn zeker in euro's gekwantificeerd. Het probleem is dat bedrijven dit soort getallen niet graag vrijgeven.

3. Reputatie schade Dit is de schade aan het imago en de aantrekkelijkheid van het bedrijf. Dit leidt tot teruglopen van opdrachten of zelfs tot klanten, die een andere leverancier of ketenpartner gaan zoeken. Deze schade is weliswaar te kwantificeren, maar dat is over het algemeen niet gemakkelijk uit te voeren.

Kans Wat is eigenlijk de kans dat testen van een software product minstens een of meer serieuze bevindingen oplevert? Een serieuze bevinding, die als deze in productie zou zijn opgetreden zeker voor meer dan een dag uitvallen van het systeem tot gevolg heeft? Uit ervaring weten wij dat dit nagenoeg altijd het geval is. Daarom stel ik dat deze kans in de praktijk 100% is. De formule Risico = Effect x Kans kan dus simpelweg worden vereenvoudigd tot Risico = Effect. Het is dusnagenoegzekerdat het risicooptreedt.

Voorbeeld Laten we even wat gaan rekenen. Stel je hebt een distributiecentrum (http://en.wikipedia.org/wiki/Warehouse), waar goederen tijdelijk worden opgeslagen. Het gaat mij om de manier van denken en de manier om het product risico te berekenen en uit te drukken in geld. Directe schade: Het is vrij eenvoudig te schatten hoeveel medewerkers in het distributiecentrum werken. En je kunt gerust stellen dat bij een showstopper het systeem er uit ligt en er geen goederenbewegingen meer plaats vinden. Dat betekend dat de medewerkers geen productie leveren. Stel een gemiddeld distributiecentrum heeft 100 tot 200 orderpikkers en een orderpikker kost zo'n 50 ¼ per uur, dan komen wij op zo'n 5,000.- tot 10,000.- ¼ per uur aan directe schade, omdat tegenover deze kosten geen productie staat. Voor het gemak verwaarlozen wij in dit voorbeeld support calls en inhuur van extra personeel om de

achterstand weg te werken. Als wij stellen dat een showstopper in 8 uur gefixed is, dan komen wij op 40.000,- tot 80.000,- ¼ per showstopper aan directe schade.

Indirecte schade: Uit ervaring weet ik dat claims van ketenpartners van distributiecentra doorgaans uit komen tussen zo'n 1,000,000.- en 5,000,000.- ¼ per dag, dat het distributiecenter niet kan leveren en ook geen goederen kan opnemen. Het is een redelijke uitdaging om achter de echte bedragen te komen omdat dit door de bedrijven goed geheim gehouden wordt.

Reputatie schade: Dit is zeer lastig te kwantificeren en je kunt doorgaans met het schatten van de directe en indirecte schade al je punt maken.

Conclusie
y

De directe schade aan de business is doorgaans goed zichtbaar te maken, dan wel te schatten. Ook al neem je grote stappen en verwaarloos je het een en ander. De indirecte (keten)schade is wat lastiger te achterhalen, maar kan wel worden geschat. Het gaat niet om de exacte getallen, maar om de manier van benaderen. De Business kan dan met hun eigen cijfers het rekensommetje maken. Het loont om de schade te voorkomen door de product risico's te mitigeren.

y

y

y

Iemand, die zegt dat dit niet te schatten is, die is bezig een excuse te maken zodat hij de schade niet hoeft in te schatten. En laten wij eerlijk wezen - er staan zeker belangen op het spel voor die genen, die niet zichtbaar willen maken hoeveel risico er daadwerkelijk door de business gelopen wordt. Stel dat de business weet hoe er met hun belang wordt omgesprongen..

Mijn volgende BLOG zal gaan over hoe je Product Risico Mitigatie zou moeten beleggen en hoe je de product risico mitigatie effectief vorm kunt geven.

Sign up to vote on this title
UsefulNot useful