Van business analyse naar softwareselectie in 90 dagen

‍

Fase 1 (dag 1–30): De business analyse

‍

Begin bij de basis: wat wil je eigenlijk oplossen?

Een softwaretraject begint niet met een demo of een longlist. Het begint met een eerlijke analyse van je eigen organisatie. Welke processen lopen stroef? Waar gaat informatie verloren? Welke afdelingen werken langs elkaar heen?

‍

Zet in de eerste week een kernteam op. Betrek minimaal één vertegenwoordiger per afdeling die geraakt wordt door de toekomstige software. Dit zijn niet per se de managers, maar de mensen die dagelijks met de huidige processen werken. Zij weten waar de pijnpunten zitten.

‍

Processen in kaart brengen

Documenteer de huidige werkwijze per proces. Gebruik een eenvoudig format: wat is de input, wat zijn de stappen, wie is verantwoordelijk, wat is de output? Houd het simpel. Het gaat er niet om een perfecte proceskaart te maken, maar om inzicht te krijgen.

‍

Stel bij elk proces drie vragen:

• Wat gaat er goed?
• Wat kost onnodig veel tijd of energie?
• Wat zou anders moeten als we groeien of veranderen?

‍

Knelpunten en doelstellingen

Uit de procesanalyse komen knelpunten naar voren. Groepeer deze thematisch, want niet elk probleem is even groot of urgent. Maak onderscheid tussen problemen die direct productiviteitsverlies veroorzaken en problemen die op termijn risico's vormen.

‍

Koppel aan elk knelpunt een doelstelling. Formuleer die zo concreet mogelijk. Niet "we willen betere communicatie", maar "we willen dat klantinformatie centraal beschikbaar is voor sales en klantenservice, zonder handmatige overdracht". Dit verschil in formulering lijkt klein, maar bepaalt straks of je de juiste software selecteert.

‍

Sluit de eerste fase af met een gevalideerd document: de probleemstelling en doelstellingen, ondertekend of in elk geval goedgekeurd door de besluitvormers. Dit document vormt de basis voor alles wat volgt.

‍

Fase 2 (dag 31–60): Van analyse naar selectiecriteria

‍

Functionele en technische eisen opstellen

Nu de doelstellingen helder zijn, vertaal je die naar concrete eisen aan de software. Werk met twee categorieën:

‍

Functionele eisen beschrijven wat de software moet kunnen doen. Denk aan specifieke modules, integraties met bestaande systemen, rapportagemogelijkheden of de manier waarop gebruikers door het systeem navigeren.

‍

Technische eisen gaan over hoe de software werkt. Denk aan hosting (cloud of on-premise), beveiligingsnormen, beschikbaarheid, schaalbaarheid en ondersteuning.

‍

Maak binnen beide categorieën een onderscheid tussen must-haves en nice-to-haves. Een must-have is een eis waaraan de software sowieso moet voldoen, anders valt de leverancier af. Een nice-to-have is waardevol, maar niet doorslaggevend.

‍

De longlist samenstellen

Met de eisen op papier kun je een longlist opbouwen. Gebruik meerdere bronnen: marktonderzoeken, ervaringen van andere organisaties in jouw sector, en gesprekken met adviseurs of peers. Streef naar acht tot twaalf kandidaten.

‍

Beoordeel iedere partij op hoofdlijnen: past het type oplossing bij jullie schaal en sector? Zijn er duidelijke indicaties dat de leverancier de must-haves kan leveren? Staat de leverancier er financieel solide voor?

‍

Dit is nog geen diepgaande analyse. Het doel is om snel te filteren op relevantie.

‍

Van longlist naar shortlist

Reduceer de longlist tot drie à vier serieuze kandidaten. Stuur elke kandidaat een gestructureerde vragenlijst op basis van jullie eisen. Vraag naar concrete functionaliteiten, referenties in jouw sector, implementatietijdlijnen en totale kosten (inclusief implementatie, licenties en beheer).

‍

Beoordeel de antwoorden met het kernteam. Gebruik een eenvoudige scorekaart waarbij elk criterium een gewicht krijgt op basis van prioriteit. Zo maak je de vergelijking transparant en minder gevoelig voor persoonlijke voorkeuren.

‍

Fase 3 (dag 61–90): Leveranciersvergelijking en besluitvorming

‍

Demonstraties en referentiegesprekken

Nodig de shortlist-kandidaten uit voor een gerichte demo. Stuur vooraf een scenario toe dat gebaseerd is op jullie eigen processen, zodat de leverancier niet een standaardpresentatie geeft maar laat zien hoe het systeem werkt in jullie context. Dit is een cruciale stap binnen een zorgvuldig ingericht traject van erp selectie advies, waarbij praktijkvalidatie centraal staat.

‍

Bereid per demo dezelfde vragen voor, zodat je de kandidaten eerlijk kunt vergelijken. Betrek meerdere teamleden bij de demo's, bij voorkeur ook de toekomstige eindgebruikers. Voer daarnaast referentiegesprekken met bestaande klanten van de leverancier. Vraag specifiek naar de implementatie-ervaring, de kwaliteit van ondersteuning en eventuele tegenvallers achteraf. Dit geeft een realistischer beeld dan welk salesgesprek ook.

‍

Totale kosten en risico's in kaart brengen

Softwareselectie gaat niet alleen over functionaliteit. De totale investering over drie tot vijf jaar ook wel Total Cost of Ownership (TCO) genoemd is een belangrijk onderdeel van de beslissing.

‍

Vraag offertes op en zorg dat je vergelijkt op gelijke basis. Let op verborgen kosten zoals maatwerk, migratie van bestaande data, gebruikerstrainingen en toekomstige versie-upgrades.

‍

Breng ook risico's in kaart. Hoe afhankelijk word je van één leverancier? Hoe makkelijk is het om over te stappen als de samenwerking niet bevalt? Wat zijn de contractuele voorwaarden rondom opzegtermijnen en data-eigendom?

‍

De definitieve keuze en besluitvorming

Presenteer de resultaten van de vergelijking aan de besluitvormers. Geef een duidelijk en gestructureerd overzicht van de drie kandidaten, inclusief hun scores op de selectiecriteria, de totale eigendomskosten (TCO) en de bijbehorende risicobeoordeling. Formuleer daarnaast een onderbouwde aanbeveling.

‍

Neem vervolgens een besluit. Dat lijkt logisch, maar binnen een traject met een software implementatie consultant blijkt dit vaak een struikelpunt. Zonder een expliciet ingepland beslismoment bestaat het risico dat het proces blijft hangen in heroverwegingen. Plan daarom een concrete vergadering, leg de voorkeursoptie voor en stel een duidelijke deadline voor het definitieve besluit.

‍

Randvoorwaarden voor succes

Een strak tijdschema werkt alleen als de interne condities op orde zijn. Drie randvoorwaarden verdienen bijzondere aandacht:

‍

Sponsorschap vanuit de top. Een softwaretraject heeft een trekker nodig die beslissingen kan nemen en blokkades kan wegnemen. Zonder actieve betrokkenheid van een directielid of manager met mandaat stolt het proces.

‍

Beschikbaarheid van het kernteam. De mensen die aan dit traject werken, hebben er tijd voor nodig. Niet als bijzaak naast hun reguliere werk, maar als geprioriteerde activiteit. Maak dat expliciet en bescherm die tijd.

‍

Acceptatie van onzekerheid. Geen enkele software is perfect. Wie wacht op de ideale oplossing, wacht te lang. Het doel is een gefundeerde keuze maken op basis van de beste beschikbare informatie, niet op basis van zekerheid die nooit volledig bestaat.

‍

Zet de eerste stap

Negentig dagen is haalbaar. Maar dan moet dag één echt dag één zijn. Stel het startmoment niet uit totdat "alle neuzen dezelfde kant op staan" of de agenda's het toelaten. Begin met het kernteam dat beschikbaar is, start met de procesanalyse en bouw van daaruit.

‍

Het framework in dit artikel geeft je structuur, maar de uitvoering vraagt discipline en intern commitment. Organisaties die dit traject serieus aanpakken, maken niet alleen een betere softwarekeuze. Ze bouwen ook interne kennis op over hun eigen processen, versterken de samenwerking tussen afdelingen en leggen een stevige basis voor de implementatie die daarna volgt.

‍

Dat is de echte waarde van een goed doorlopen selectietraject: niet alleen de juiste softwareselectie kiezen, maar de organisatie klaarstomen om er ook wat mee te doen.

‍