Begin bij het probleem, niet bij het pakket
De meest voorkomende fout is starten bij een demo. Een demo toont wat een pakket kan, niet wat jij nodig hebt, en na drie demo's is de discussie verschoven naar functionaliteiten in plaats van naar je oorspronkelijke probleem.
Formuleer eerst het probleem in bedrijfstaal: offertes duren te lang, voorraad klopt niet, we kunnen niet zien welke opdracht winstgevend was. Zet er een cijfer bij en het verlies dat je vandaag lijdt. Dat cijfer bepaalt zowel het budget als het succescriterium.
Toets vervolgens of het probleem wel een softwareprobleem is. Een aanzienlijk deel van de digitaliseringsprojecten in KMO's probeert met techniek een procesprobleem op te lossen. Een slecht proces dat je digitaliseert, blijft slecht en wordt bovendien duurder om te veranderen.
De totale kost over vijf jaar
De aankoopprijs of de maandelijkse licentie is doorgaans het kleinste deel. Reken vier posten mee: licenties over vijf jaar, implementatie en configuratie, opleiding en productiviteitsverlies tijdens de overgang, en de kost van koppelingen met bestaande systemen.
Die laatste post is de meest onderschatte. Elke koppeling tussen twee systemen kost geld bij de bouw én bij elke update daarna. Een pakket dat op zich duurder is maar minder koppelingen vraagt, is over vijf jaar vaak goedkoper.
Vraag de leverancier expliciet naar de kost van datamigratie, van meerwerk buiten scope, en naar de jaarlijkse indexatie van de licentie. Die drie samen bepalen doorgaans het verschil tussen de offerte en de werkelijke factuur.
De vragen die een leverancier moet kunnen beantwoorden
Vraag naar drie referenties van bedrijven van vergelijkbare grootte in een vergelijkbare sector, en bel ze op. Vraag hen niet of ze tevreden zijn, maar hoeveel langer het duurde dan gepland, wat er tegenviel, en wat ze nu anders zouden doen.
Vraag wie er tijdens de implementatie effectief bij jou aan tafel zit, met naam. In veel projecten verkoopt een ervaren commercieel profiel en implementeert een junior. Dat is niet noodzakelijk een probleem, maar je wil het vooraf weten.
Vraag tot slot wat er gebeurt bij stopzetting: krijg je je data terug, in welk formaat, en tegen welke kost. Een leverancier die daar vaag over blijft, geeft je meteen een belangrijk signaal over de afhankelijkheid die je aangaat.
De interne eigenaar
Elk digitaliseringsproject heeft één interne eigenaar nodig met beslissingsmacht en met voldoende tijd. Niet de zaakvoerder erbij, niet een werkgroep, maar één persoon die beslissingen kan nemen over processen en over uitzonderingen.
Reken op minstens één dag per week gedurende de implementatie voor die persoon. Wordt die tijd niet vrijgemaakt, dan wordt het project met vertraging uitgevoerd door de leverancier volgens zijn eigen standaardaannames, en dat is de duurste variant.
Geef die eigenaar ook expliciet de bevoegdheid om nee te zeggen tegen uitzonderingen. Elk maatwerk dat je toestaat om één bestaande gewoonte te behouden, kost bij elke toekomstige update opnieuw geld. Die afweging hoort bij één persoon te liggen, niet bij de afdeling die de uitzondering vraagt.
Fasering en het vermijden van een big bang
Zet nooit alles tegelijk om wanneer dat vermijdbaar is. Een gefaseerde invoering — één afdeling, één proces, één vestiging — maakt fouten beheersbaar en levert leerpunten op voor de volgende fase.
Bepaal per fase een concreet resultaat en een datum, en koppel de betaling aan de leverancier daaraan. Een betalingsschema gekoppeld aan opgeleverde en aanvaarde fases verandert de dynamiek van het project meer dan om het even welke contractclausule.
Plan bovendien een terugvalscenario voor de eerste weken na livegang: hoe blijf je factureren, leveren en betalen wanneer het nieuwe systeem hapert. Bedrijven die dat scenario niet hebben, komen bij een probleem onmiddellijk in crisismodus.
Meten of het gewerkt heeft
Kies vooraf één tot drie cijfers waaraan je succes afmeet: doorlooptijd van een offerte, aantal fouten in leveringen, tijd tot facturatie, of het aantal uren administratie per week. Meet ze vóór de start, anders heb je geen vergelijkingspunt.
Meet ze opnieuw drie en twaalf maanden na livegang. Zonder die meting blijft de evaluatie steken op gevoelens, en gevoelens over nieuwe software zijn de eerste maanden per definitie negatief omdat alles nog onwennig is.
Rapporteer die cijfers aan de bestuurstafel. Een investering van deze omvang zonder nameting is een van de duidelijkste voorbeelden van uitgaven die niet worden opgevolgd omdat niemand er expliciet eigenaar van is.
Wat je niet hoeft te begrijpen
Je hoeft de technische architectuur niet te doorgronden. Wat je wél moet begrijpen, is waar je data staat, wie eraan kan, hoe je ze terugkrijgt en wat er gebeurt bij een storing of een inbreuk.
Vraag daarom naar de afspraken over beschikbaarheid, back-ups, herstel na incident en verwerking van persoonsgegevens. Dat zijn bedrijfsvragen, geen IT-vragen, en het antwoord erop hoort in het contract te staan en niet in een gesprek.
Laat dat contract nalezen door iemand die zulke contracten vaker ziet. Dat is een kleine kost tegenover een verbintenis die je vaak vijf jaar of langer bindt aan één leverancier.
Veelgestelde vragen
Hoe beoordeel je een softwarekeuze zonder IT-kennis?
Door te starten bij het bedrijfsprobleem en het cijfer waaraan je succes afmeet, de totale kost over vijf jaar door te rekenen, drie referenties op te bellen en een interne eigenaar met beslissingsmacht aan te duiden.
Wat is de grootste verborgen kost bij digitalisering?
Koppelingen met bestaande systemen en maatwerk: beide kosten geld bij de bouw en opnieuw bij elke update. Daarnaast worden opleiding en productiviteitsverlies tijdens de overgang stelselmatig onderschat.
Waarom mislukken digitaliseringsprojecten in KMO's?
Meestal niet door de techniek, maar doordat een bestaand slecht proces wordt gedigitaliseerd, of doordat er geen interne eigenaar is met voldoende tijd en beslissingsmacht om knopen door te hakken.