Hoe weet je wanneer je klaar bent om software te kiezen?
Software dwingt besluiten af die je bedrijf jarenlang kon uitstellen. Zo weet je of die besluiten genomen zijn voordat je belt.
In dit artikel:
Je bent klaar om software te kiezen als drie besluiten intern genomen zijn: wie de knoop doorhakt, welk probleem het systeem moet oplossen, en van wie je de tijd weghaalt. Niet als je budget hebt of de markt kent. Die drie besluiten hebben niets met software te maken, en juist daarom worden ze overgeslagen.
Dit artikel is voor de ondernemer die nog geen leverancier heeft gebeld. Sta je al met voorstellen op tafel, dan is je eigen meetlat neerleggen de stap die je nu nodig hebt.
Een ondernemer in de logistiek belde me vorig jaar. Drie leveranciers gezien, twee demo's achter de rug, een shortlist van twee. Hij wilde weten welke van de twee ik zou kiezen.
Ik stelde hem één vraag: "Wie beslist als jullie intern niet uitkomen?"
Het was even stil. "Dat regelen we dan wel," zei hij.
Drie maanden later lag het traject stil. Niet op de software. Op precies die vraag, die inmiddels niet meer intern gesteld werd maar aan tafel met de leverancier erbij.
Klaar zijn gaat niet over kennis
Een softwaretraject maakt geen nieuwe besluiten. Het int de besluiten die je bedrijf al jaren heeft kunnen uitstellen.
Dat klinkt abstract tot je ziet hoe het werkt. Jarenlang kon verkoop de leverdatum noteren die de klant wilde en productie de datum die haalbaar was. Twee waarheden naast elkaar, en niemand die hoefde te kiezen. Een systeem heeft één veld. Dus moet er iemand beslissen welke van de twee erin komt.
Zo gaat het met tientallen dingen tegelijk. Wie mag korting geven en tot hoever. Wanneer is een order af. Welk adres is het juiste. Stuk voor stuk vragen die je bedrijf functioneerde zonder te beantwoorden.
Ze komen er alleen niet op een handig moment uit. Ze komen tijdens de implementatie, allemaal tegelijk, met consultants aan tafel die per uur factureren. Dan heet het meerwerk.
Klaar zijn betekent dus: weten welke uitgestelde besluiten er liggen, en wie ze mag nemen. Er zijn er drie die zonder uitzondering terugkomen.
Uitgesteld besluit 1: wie hakt de knoop door?
Iemand trekt het project, maar mag niets beslissen zonder terug te gaan naar de directeur of het MT.
Dat is geen tekortkoming van die persoon. Het is een structuurvraag die nooit is gesteld, omdat hij nooit gesteld hoefde te worden. Zolang er niets groters op tafel lag, werkte "we overleggen even" prima.
In een selectietraject werkt het niet. De leverancier wacht op groen licht dat nooit formeel wordt gegeven. Beslissingen verschuiven, de planning schuift mee, en op enig moment neemt iemand anders ze. Meestal degene die er belang bij heeft dat er iets gebeurt.
De vraag die je vooraf beantwoordt: wie tekent uiteindelijk, en wie mag tijdens het traject beslissen zonder steeds terug te hoeven?
Uitgesteld besluit 2: welk probleem lossen we op?
In veel bedrijven heeft de directeur een ander beeld van het probleem dan de mensen die er dagelijks mee werken. Dat is logisch, en zolang niemand het hoeft op te schrijven valt het niet op.
Bij het eerste leveranciersgesprek valt het wel op, alleen niet bij jullie. De verkoper hoort twee verschillende wensen en speelt daar handig op in. Hij is niet oneerlijk, hij doet zijn werk. Maar de keuze die volgt is een compromis dat niemand echt wilde.
Het gaat hier om overeenstemming over het probleem, niet over het pakket. Dat verschil is groter dan het lijkt. Twee mensen kunnen hetzelfde pakket willen om totaal verschillende redenen, en dat merk je pas bij de inrichting.
Blijkt onderweg dat je probleem helemaal geen softwareprobleem is, dan staat hier hoe je dat herkent.








