Aan tafel zitten de directie en de business process owners van het transportbedrijf. Daarnaast zitten management en teams van het softwarebedrijf dat voor hen bouwt. Iedereen denkt dat hij over hetzelfde project praat. Dat is zelden zo. Elke partij kijkt vanuit een eigen wereld.
Elke rol een eigen visie
De directie van de vervoerder denkt in netwerk, vloot, klanten en risico, en vooral in geld. CapEx, kosten en besparing bepalen of iets doorgaat. Wat kost het, en wat bespaar ik ermee? Een planningstool is voor hen geen product. Het is de belofte dat ritten slimmer lopen, dat de operatie minder afhangt van een paar planners en dat de investering zich terugverdient.
De business process owners kennen het echte proces: hoe een order binnenkomt, waar een terminal vastloopt, wie er belt als een container de boot mist. Zij moeten die werkelijkheid omzetten in scope en wensen. Dat is veel gevraagd.
Bij de softwareleverancier praat management in roadmap, capaciteit en scope. De teams kijken elk vanuit hun eigen vak. UX denkt aan de planner onder tijdsdruk. Analisten denken in regels en datavelden, het platformteam in koppelingen en nachtelijke batches.
Development heeft een eigen werkelijkheid die aan tafel vaak onzichtbaar blijft: technical debt en complexiteit. Elke uitzondering die er snel bij komt, maakt het systeem zwaarder. Wat vandaag een kleine wens lijkt, kost morgen tijd in onderhoud, testen en risico. Een snelle oplossing nu wordt later een rem op alles wat daarna komt.
Dezelfde woorden, iets anders bedoeld
Iedereen zegt planning, automatisering, AI. Niemand bedoelt hetzelfde. Voor de directie betekent “we automatiseren de planning” grip op de keten en lagere kosten. Voor de business process owner is het zijn eigen proces, met alle uitzonderingen die niet op de slide stonden. Voor de leverancier is het een deliverable in een contract. Voor development is het een stuk complexiteit dat erbij komt, bovenop wat er al ligt.
Zo gaat het mis. De directie knikt, de business process owner levert details en de leverancier plant. Wat overblijft is een backlog vol tickets zonder de bedoeling erachter: minder late ritten, minder handwerk, geen verrassingen. Ondertussen groeit de technical debt. In transport merk je dat meteen.
Een container die de boot mist is geen increment. Het is een klant die belt.
De product owner als vertaler
Daarom hoort er iemand tussen te staan die al die talen spreekt en mag beslissen. Dat is de rol van de product owner. Hij vertaalt de bedoeling van de directie naar een productkeuze. Hij zegt nee tegen wat niet in de scope past. Hij weegt elke wens af tegen de complexiteit die het toevoegt. En hij vertaalt het werk van de teams terug naar een uitkomst die de vervoerder herkent, ook in euro’s. Zonder dat mandaat wordt de product owner een doorgeefluik: ambities gaan naar beneden, tickets naar boven en niemand zegt nee.
Wat werkt
Begin klein. Vertaal de bedoeling van de directie naar één proces, één gebruiker en één meetbare uitkomst. Leg dat vast en bescherm het tegen nieuwe wensen. Pas daarna wordt het werk voor de teams: wat bouwen we, wat kost het aan complexiteit, waar beslist een mens en wat doet het systeem nooit zelf. En toets het simpel: kan iedereen aan tafel de bedoeling in zijn eigen woorden navertellen? Pas dan werk je echt samen.