In dit artikel ga ik in op de valkuilen die ik ben tegengekomen bij het uitvoeren van projecten voor klanten van ORTEC. Sinds 1990 ben ik betrokken bij een heel aantal kleine en grote projecten, waarbij altijd een wiskundig modelelement in het project zat. Projecten duren soms een paar weken, soms 2 jaar. Qua onderwerpen loopt dit van routeringsproblemen voor mengvoeders, via productie- modellen voor gasvelden en netwerk-design studies voor logistieke dienstverleners naar inventory managementmodellen voor airlines. Niet alle projecten zijn uitgevoerd zoals bij het begin voorzien was, en eigenlijk zien we een beperkt aantal redenen waarom projecten anders lopen dan gepland.

Hoge ambities

De allerbelangrijkste reden hiervoor is dat de ambitie van de organisatie voor het toepassen van analytics veel hoger is dan het startpunt waarop de organisatie zich bevindt. Hierdoor worden stappen overgeslagen en besluiten we gedurende het project het ambitieniveau terug te schroeven. Voorbeelden hiervan zijn het niet beschikbaar zijn van benodigde informatie en onbetrouwbare informatie als deze wel beschikbaar is. Hiermee samenhangend zien we als reden ook de gebruikers van het ontwikkelde model. Deze zijn vaak niet gewend te werken met applicaties die beslissingen ondersteunen. De ontwikkelde rekenmodule voor het oplossen van het integrale probleem wordt niet gebruikt, maar er is veel tevredenheid over de ondersteuning in termen van meldingen van schendingen van regels en KPI-informatie. Veelal wordt de applicatie gebruikt voor handmatige planningen, waarbij als voordeel wordt gegeven dat er minder fouten worden gemaakt bij het maken van een planning. Op zich een duidelijke verbetering voor de klant, maar feitelijk niet het doel van veel van de gestarte projecten.

Enthousiast management

Naast deze omgevingsoorzaken hebben we ook te maken met het klimaat bij onze klanten. Vaak is iemand in het management enthousiast over het toepassen van OR en is daarmee een belangrijke sponsor van het project. Maar deze trekker wisselt op een gegeven moment van baan, krijgt promotie of krijgt andere verantwoordelijkheden. Als dat midden in het project gebeurt, kan dat tot gevolg hebben dat het project opeens veel minder aandacht en middelen krijgt vanuit de klantorganisatie. En dan ligt een teleurstellend resultaat op de loer. Van belang is dan ook om te zorgen voor een goede inbedding van het project in de organisatie en het betrekken van voldoende mensen bij de klant om dit soort personele wisselingen op te vangen. Projectmanagementmethodes haken hierop in, bijvoorbeeld als er agile wordt ontwikkeld. Daarbij wordt al snel in het traject bruikbare software opgeleverd en de functionaliteit wordt in korte sprints uitgebouwd tot het eindresultaat. Hiermee wordt de betrokkenheid van eindgebruikers vergroot. Daarnaast wordt het voor de sponsors van het project ook zichtbaar dat er resultaten worden geboekt.

Dynamische omgeving

Nog weer een andere valkuil is de timing waarop de inputdata beschikbaar komen. Traditioneel bouwen we modellen die voor een input dataset, de opgegeven doelstelling en alle beperkingen een oplossing opleveren. We bepalen bijvoorbeeld alle distributieroutes om de producten morgen bij de klanten af te leveren. Of we bepalen de dagplanning van servicemonteurs die controlebezoeken moeten afleggen op een aantal locaties. Deze modellen maken een goed of zelfs optimaal plan, gegeven de vaste input. Echter, in de praktijk zien we dat deze input helemaal niet vast is. Er worden opdrachten geannuleerd, hoeveelheden worden aangepast en spoedorders worden nog na de officiele deadline geplaatst. In deze omgeving is de waarde van ons algoritme niet zo groot, want alle wijzigingen zijn moeilijk in te passen in een planning die vanwege de doelstelling weinig slack bevat. In een dynamische omgeving moeten we heel goed kijken naar de werkwijze en aanpak van de planner. Hoe gaat hij om met de onzekerheid? Wanneer maakt hij zijn basisplan? Heeft hij kennis van toekomstige orders die hij al gebruikt bij zijn plan? (‘Klant x bestelt altijd voor woensdag, dus ga er maar vanuit dat die order nog komt’; ‘Klant y vindt het ook goed als we 20% meer brengen, dus daarmee benut ik die ritcapaciteit wel volledig’).

Moeten we in deze situatie met de opdrachtgever niet méér kijken naar het verkleinen van de onzekerheid, het terugdringen van de spoedorders, in plaats van met een algoritme een zich telkens wijzigend probleem heel goed oplossen? Of moeten we bij de oplossing juist een robuste oplossing nastreven? Of moet juist de planner ondersteund worden in het huidige proces van plannen met voorstellen waar een spoedorder ingepland kan worden met weinig wijzigingen op de bestaande planning? We hebben in het verleden dit aspect soms niet in de gaten gehad en bij de implementatie moeten constateren dat we een prima algoritme hadden gemaakt, maar dat het probleem van de opdrachtgever eigenlijk een ander probleem was.

Haalbaarheid

Omdat dit artikel zich concentreert op de valkuilen, kan de indruk ontstaan dat het toepassen van OR in de praktijk vaak mislukt of in elk geval slechts ten dele lukt. Dat is echter alleen zo als we OR willen toepassen als aan de voorwaarden voor een succesvolle implementatie niet is voldaan. Dit artikel moet dan ook vooral worden gezien als een aanmoediging om goed te kijken hoe het te ontwikkelen model in de organisatie gebruikt zal en kan worden. Daarvan moet een helder beeld zijn, zowel bij opdrachtgever als leverancier. Een goede methode hiervoor is het model van Davenport, waarbij op een aantal onderdelen gekeken wordt op welk level de opdrachtgever zich bevindt. Aan de hand van deze uitgangssituatie kan dan gekeken worden of de doelstellingen haalbaar zijn, dat wil zeggen zich qua ambitieniveau iets boven het huidige niveau bevinden. Als de te nemen stap groter is dan 1 niveau op een van de success factoren, moet dit als een groot risico voor het uit te voeren project worden beschouwd. Als zowel de opdrachtgever als leverancier de verschillende use cases als realistisch beschouwen, kan de focus worden gericht op de op te lossen puzzel. De grootste valkuil is dus dat we de geschetste puzzel zo interessant vinden, dat we vergeten naar de omgeving van de puzzel te kijken, de puzzel oplossen en er dan achterkomen dat we de verkeerde puzzel hebben opgelost.

Artikel informatie

STAtOR 2017 Nr.4 pagina 19-21.

Auteur informatie

Adriaan Tas studeerde bedrijfseconometrie aan de Erasmus Universiteit en is sinds 1989 werkzaam bij ORTEC. Vanaf 2015 is hij Director Operations Research bij de business unit Consulting.
E-mail: adriaan.tas@ortec.com