Eenheidsprijzen (PxQ): niet de heilige graal in prijsmodellen
Het prijsmodel is een belangrijke factor in outsourcingcontracten. De algemene trend in prijsmodellen gaat richting eenheidsprijzen waarbij gestandaardiseerde diensten een vaste prijs hebben. Dan wordt de totale prijs van een set diensten berekend door P(rijs) maal Q(uantiteit). Typisch verwijzen we naar dit model als PxQ. Het vergemakkelijkt aanzienlijk het vergelijken van meerdere leveranciers in een aanbestedingssituatie, wat het wijdverspreide gebruik in selectieprocessen verklaart. Het is echter mogelijk niet het beste model voor het besturen van de levering.
Op het eerste gezicht heeft PxQ de charme van de eenvoud en het adresseert de gebruikelijke vereisten die klanten hebben ten aanzien van prijsmodellen. Het is voorspelbaar, transparant en het biedt kostenflexibiliteit. Het weerspiegelt echter geenszins de kostenstructuur van een leverancier. Om die reden komen partijen vaak overeen op aanvullende beperkingen. Het model is alleen toepasbaar binnen bepaalde bandbreedtes en zelfs dan zijn volumekortingen van toepassing. Nog erger, ze voegen een hele reeks boetes toe (effectief kwaliteit in de vergelijking brengend) en incentive schema’s. Eenvoud is dan het eerste slachtoffer. In scenario’s waar diensten niet volledig gestandaardiseerd zijn, geldt de wet van behoud van complexiteit. Het verminderen van complexiteit in het prijsmodel verhoogt de complexiteit in de beschrijving van de diensten.
In sommige gevallen werkt PxQ eigenlijk contraproductief
Bijvoorbeeld bij het opstellen van een prijsmodel voor applicatiediensten kan men streven naar eenheidsprijzen. In veel van deze pogingen ben ik getuige geweest van en heb deelgenomen aan brede academische discussies. Vele keren heb ik de haalbaarheid van Function Points, Story Points en Complexity Points met klanten en leveranciers overwogen. Uiteraard compliceerden de toepasselijke ontwikkelmethoden (Waterfall vs. Agile), technologie, de fase van applicaties in hun levenscyclus en onderlinge afhankelijkheden tussen klant en leverancier de modellen verder. Flexibele versnellingsfactoren, gemiddelde resourcepiramides met veranderende offshore ratio’s en over de tijd verbeterende productiviteitsdoelen voegden nog meer complexiteit toe. In al deze gevallen was de oorspronkelijke intentie om een eenvoudig PxQ-model voor het engagement te creëren.
Wanneer je aanzienlijke extra complexiteit nodig hebt om een berekening in een eenheidsprijs te passen, zijn de kansen groot dat PxQ niet het juiste model is. In die gevallen zouden partijen terug moeten gaan naar de tekentafel en hun uitgangspunten opnieuw moeten bekijken.
Voor commoditydiensten is PxQ een uitstekend model. Maar dat maakt eenheidsprijzen geen heilige graal voor elk type engagement. Vooral bij het contracteren van applicatiediensten zijn veel aannames, gemiddelden van uiteenlopende servicedelen en complexe berekeningen nodig om diensten telbaar te laten lijken. Wanneer contractonderhandelingen uit de hand lopen in steeds grotere complexiteit van servicebeschrijvingen, kan het loslaten van het eenvoudigste van alle prijsmodellen het kleinere kwaad zijn.
Ik waardeer elke feedback op kandidaten voor het allereenvoudigste prijsmodel voor applicatiediensten zeer!
