Hoe kun je als arrangeur je vraagprijzen verklaren?

Eerder introduceerde ik een model om op een gestructureerde manier je vraagprijzen als arrangeur te bepalen en te berekenen.

Hierbij ging het nadrukkelijk om een wensmodel, een SOLL-model. Maar hoe zit het met het IST-model: kun je op basis van het model dat toen uit de doeken is gedaan uitvogelen hoe het met je huidige tarieven zit? En kan het model misschien zelfs voorspellen wat een opdrachtgever verwacht dat je gaat vragen voor een nieuwe klus, op basis van het verleden?

Dat kan! In dit artikel wordt uitgelegd hoe je het model zo goed mogelijk kunt afstellen op de werkelijkheid.

Opfrisser
Eerst even terug naar dat model van de vorige keer om de vraagprijs te berekenen. Als je dat artikel nog niet hebt geraadpleegd, raad ik je sterk aan om nog een keer de intuïtie bij ieder onderdeel tot je te nemen. Dan vallen de elementen ook weer wat beter op hun plek.

Dat model zag er als volgt uit (ik geef nu even meteen alle elementen):

= de functie om de vraagprijs te berekenen
= eersteopdrachttoeslag
starttarief
= loonsverhoging per jaar
= aantal jaren werkervaring
= toeslag grote bezetting
= grote bezetting (dichotoom)
toeslagpercentage per extra versie
= aantal gemaakte versies
= verdeelsleutel vaker gemaakt arrangement*
= vaker gemaakt arrangement (dichotoom)
= mate waarin het bedrag afneemt bij
= aantal eerdere opdrachten voor afnemer

Het doel dat we nu voor ogen hebben is tweeledig: (1) het model zo afstellen dat hij de huidige situatie zo goed mogelijk verklaart, en (2) het vergroten van de voorspellende waarde van het model voor toekomstige opdrachten.

Om dat doel te bereiken moet het model eerst nog even wat verder worden ontleed. Als we goed kijken naar alle onderdelen, dan zien we een aantal elementen die voor iedere waarneming constant blijven:

= eersteopdrachttoeslag
starttarief
= loonsverhoging per jaar
= toeslag grote bezetting
toeslagpercentage per extra versie
= verdeelsleutel vaker gemaakt arrangement
= mate waarin het bedrag afneemt bij het aantal eerdere opdrachten voor afnemer

Onderzoekende geesten weten het al: als er bepaalde factoren in een hypothetisch model zijn die constant kunnen worden gehouden voor iedere waarneming, dan zijn dat de knoppen waar je aan kunt gaan draaien om te kijken of je het model kunt verbeteren.

En dat is precies wat we nu gaan doen.

Detlef
In dit Excelbestand** vind je de arrangementen die een fictieve arrangeur in het vorige decennium maakte. Laten we hem Detlef noemen. Detlef maakte in de periode tussen 1 januari 2000 en 8 juli 2009 precies 100 arrangementen en verzamelde daar de volgende gegevens voor:

Opdrachtgever
Opleverdatum
Daadwerkelijke vraagprijs
Duur (minuten + seconden)
Aantal versies
Eerder gezet
Grote bezetting

Een riedeltje dat je ondertussen waarschijnlijk bekend voor zal komen.

Als we naar het Excelbestand kijken, dan zien we dit:

Laten we er even doorheen wandelen:

Bovenaan zien we een rijtje met de elementen uit het model die constant worden gehouden. Daarover later meer.
Onderaan dit rijtje staat een bijzondere: de determinatiecoëfficiënt R². Dit is de gekwadrateerde correlatiecoëfficiënt, oftewel de mate waarin het model en de werkelijkheid met elkaar samenhangen.
In de kolommen aan het begin zien we de data die Detlef zelf heeft ingevoerd:
- Naam arrangement
- Opdrachtgever
- Opleverdatum
- Daadwerkelijke vraagprijs (in de gele kolom)
- Duur (minuten en seconden los ingevoerd, dit wordt verderop samengevoegd tot een makkelijker te verwerken getal)
- Aantal versies
- Eerder gezet
- Grote bezetting
In de grijze kolommen zien we data die automatisch worden berekend op basis van wat hiervoor is ingegeven:
- Hoeveel eerdere opdrachten heeft Detlef voor deze opdrachtgever gemaakt
- Hoeveel jaren werkervaring heeft hij op de opleverdatum van het arrangement
- Hoe lang duurt het stuk (de eerder aangekondigde machine-readable samenvoeging van minuten + seconden)
Daarna wordt het interessant: het rijtje met IST-berekeningen, oftewel de invoer van ons model .
De allerlaatste grijze rij is de vraagprijs die op basis van het model is berekend. De groene kolom daarna is diezelfde vraagprijs afgerond op 25-tallen, om tot een rond bedrag te komen. Een vraagprijs van € 504,48 klinkt immers zo gek.
De laatste witte kolom is IST_SQ: het gekwadrateerde verschil tussen de daadwerkelijke vraagprijs die voor het arrangement is afgesproken (geel) en de voorspelling van het model (de laatste grijze rij) . Hierover later meer.

Gewicht
Bovenaan het bestand staan dus de gewichten die aan ieder element in het model worden gehangen. In het beginstadium zijn die als volgt door Detlef gedefinieerd:

Voor iedere extra versie komt er 5% bovenop de vraagprijs (oftewel 1.05), dus 1.05.
Als een arrangement eerder gezet is, dan wordt het tarief gedeeld door 1 + 1 = 2, dus = 1 .
Als het een arrangement voor een grote bezetting betreft, dan komt er € 8,- bovenop het tarief, dus = 8.
Voor ieder jaar werkervaring komt er € 4,- bovenop het tarief, dus = 4.
Het starttarief per minuut is € 24, dus 24.
Voor iedere nieuwe opdrachtgever wordt een eersteopdrachttoeslag van € 50,- gerekend, dus = 50.
De curve log is de mate waarin het bedrag afneemt bij meerdere opdrachten voor dezelfde opdrachtgever. Die is nu bepaald op 1, dus = 1.

Dan nog even over die R². Het lijkt erop dat Detlef het model behoorlijk solide heeft ingericht. Nu verklaart het 78% van de variantie bij de arrangementen. Als we de daadwerkelijke vraagprijs voor alle arrangementen afzetten tegen de afgeronde voorspellingen van het model, leidt dat tot het volgende beeld:

Niet slecht. Maar Detlef wil het model nog beter aan laten sluiten bij zijn dagelijkse praktijk. Daartoe kan hij zelf gaan rommelen met de gewichten die hij aan ieder onderdeel heeft gehangen, bovenaan in het bestand.

Makkelijker zou het zijn om de computer het werk te laten doen en gewichten te laten zoeken, zodat het model een nog betere fit heeft met de daadwerkelijke vraagprijzen.

Maar hoe?

Solver
Daartoe gebruikt Detlef de Solver-toepassing die standaard in Excel is ingebouwd. Hij moet wel nog wat stappen zetten vooraleer de toepassing geactiveerd is, maar gelukkig voor hem worden die op plekken zoals deze prima beschreven.

Waar komt Solver ineens vandaan? Dit is een toepassing die is ontworpen om optimalisatieproblemen in Excel in alle soorten en maten op te lossen. En laten we wel zijn, ook hier kunnen we spreken van een optimalisatieprobleem: we willen immers dat het model optimaal aansluit bij de werkelijkheid van Detlefs vraagprijzen.

Hoe kunnen we Solver aan het werk zetten? Als volgt. Als we het schermpje met parameters openen voor Detlefs bestand, dan voeren we de volgende gegevens in:

Het einddoel (Set Objective) is om cel S111 te minimaliseren. Cel S111 is de optelsom van alle gekwadrateerde verschillen tussen de voorspellingen van het model en de werkelijkheid. Aangezien het model zo sterk mogelijk moet worden, is het logisch om als doel te hebben dat de foutmarge wordt geminimaliseerd.
Dat moet Solver doen door te sleutelen aan de gewichten (By Changing Variable Cells): de waarden die nu staan ingegeven in de cellen B1 tot en met B7, bovenaan in het bestand.
Tot slot worden er nog wat beperkingen (Subject To The Constraints) ingebouwd. Beperkingen die in dit geval er vooral voor dienen om de gewichten leesbaar te houden, en geen bizarre uitschieters te krijgen. Het wil namelijk nog wel eens voorkomen dat het algoritme overenthousiast wordt en gewichten de miljoentallen in schieten. Als dat een goede voorspellende waarde heeft is dat op zichzelf prima, maar het interpreteert vooral niet zo lekker.
We vertellen Solver tot slot om een oplossing te zoeken (Select A Solving Method) met behulp van een evolutionair algoritme. (Het strekt wat ver om de werking hiervan hier toe te lichten.)

Nu is het moment om Solver aan de slag te zetten. Leun achterover en kijk hoe de rekenkracht van de computer op volle toeren draait en duizenden berekeningen doet zoals deze:

Dan heeft Solver een oplossing gevonden. Wellicht niet de aller-allerbeste, maar daarvoor zijn genetische algoritmen ook ongeschikt***:

De oplettende kijker ziet nu een R² van 100%. De gewichten die in het model zitten zijn dus nagenoeg optimaal: het model verklaart alle variantie in de vraagprijzen. Als we de daadwerkelijke vraagprijs voor alle 100 arrangementen nogmaals afzetten tegen de voorspellingen van het model, dan leidt dat tot het volgende, volmaakte beeld:

Het genetische algoritme heeft zijn werk dus uitstekend gedaan.

Als we de nieuwe gewichten naast de originele gewichten zetten, dan vallen een aantal dingen op:

Aan het gewicht dat bepaalt dat voor iedere versie 5% bovenop de vraagprijs komt ( 1.05) is vrijwel niets veranderd. Dat heeft Detlef dus goed voorzien.
Ditzelfde geldt voor als een arrangement al eerder gemaakt is () en als het voor een grote bezetting is ().
De werkervaring is echter flink geslonken: van 4 naar 0.4 in het nieuwe model. Effectief stijgt Detlefs tarief dus met een schamele 40 eurocent per jaar, en is hij blijkbaar op hetzelfde tarief blijven hangen in die negen productieve jaren.
Daarentegen is het starttarief per minuut enorm gestegen: van € 24 naar ruim € 93 per minuut (93). Die hoge constantheid compenseert voor het verlies bij de werkervaringvariabele.
Dit nieuwe hoge bedrag zorgt ervoor dat de eersteopdrachttoeslag nagenoeg is verdwenen. Blijkbaar is die toeslag toch niet zo belangrijk als Detlef aanvankelijk dacht. De manipulatie van de curve is hiermee ook verwaarloosbaar geworden.

Spiegel
Enerzijds biedt het aangepaste model een nieuwe feitelijke onderbouwing bij de vraagprijzen van de arrangeur. Anderzijds geeft het een goede spiegel ten opzichte van de situatie zoals Detlef hem aanvankelijk voor zich zag: de jaren werkervaring blijken er voor zijn gehanteerde vraagprijzen helemaal niet zo veel toe te doen. Op die manier kan het voor hem ook een aanleiding zijn om zijn prijsbepaling zo bij te stellen dat hij niet over tien jaar nog steeds op hetzelfde tarief is blijven hangen.

Intussen is natuurlijk ook het waarheidsgetrouwe karakter van Detlef in duigen gevallen: geen enkele arrangeur is zo consistent in haar of zijn vraagprijzen dat dit altijd strookt met een model, en andersom valt de echte wereld uiteraard niet altijd te voorspellen.

Desondanks kunnen de suggesties uit dit artikel een volgende stap zijn in het waarheidsgetrouw en consistent krijgen van waar je vraagprijzen vandaan komen, en wat er – uitgaande van hoe je in het verleden hebt beprijsd – van jou verwacht wordt bij een nieuwe klus. Bovendien kun je nu de uitkomsten uit je IST– en SOLL-modellen met elkaar gaan vergelijken, om te kijken hoeveel ruimte er nog is te winnen tussen de huidige en de gewenste situatie.

* In het vorige artikel was de verdeelsleutel reeds bepaald op 1.

** Voel je vrij om het Excelbestand te hergebruiken, om ermee te experimenteren en wellicht op den duur te vullen met je eigen gegevens.

*** Als je niet tevreden bent met de voorspellende waarde van je model, dan kun je altijd het procedé nog een keer herhalen: de werking van een genetisch algoritme kan namelijk iedere keer net even anders uitpakken. Nog een mogelijkheid is om een ander algoritme te pakken, zoals GRG nonlinear.