Het opstellen van de longlist
Op basis van een algemene criteria wordt er een long list opgesteld; een lijst van leveranciers die aan de algemene eisen van de organisatie moeten voldoen zoals bijvoorbeeld implementatie door Nederlandse integrators, branche ervaring, grootte van de organisatie en passend aan het beschikbare budget. Nadat de leveranciers hierop beoordeeld zijn, moet er ook intern onderzocht worden wat de wensen en eisen van de organisatie zijn.
Het organogram en de userscenario’s
Vanuit een organogram worden de de rollen van alle (toekomstige) gebruikers vastgesteld.
Per rol worden de gewenste functionaliteiten geschetst. In plaats van een lijst van voorwaarden op te stellen waaraan de software moet gaan voldoen, worden er lijsten opgesteld van wat de gebruikers moeten kunnen doen met de software.
Aan de hand van interviews worden user scenario’s uitgewerkt en vertaald naar de eisen en wensen van die personen.
Dit heeft een aantal voordelen:
- Elke eis is te herleiden naar een of meerdere personen.
- Verder in het traject weet elke persoon welke eisen bewaakt moeten worden, in plaats van dat alle personen alle eisen moeten controleren.
- Een eis kan vanuit meerdere personen komen. Als dit niet duidelijk is wordt er wellicht later te snel een concessie gedaan.
De user scenario’s geven inzicht in de huidige werkwijze van de gebruikers. Bij het opstellen van een user scenario wordt ook duidelijk welke rol een nieuw systeem nog meer kan gaan invullen. Een voorbeeld:
“Piet werkt parttime als producttechnoloog van 8.00 tot 16.00 uur. Bij binnenkomst zet hij zijn computer aan en antwoord hij zijn emails. Nieuwe product verzoeken worden aan een Excellijst toegevoegd. Met Hans worden de productieplanning doorgenomen en Piet geeft aan dat hij deze week 3 ontwikkelrecepten wil testen… etc..etc.”
Door bovenstaand scenario te analyseren ontstaan er nieuwe requirements. Een voorbeeld: Wie neemt het werk over van Piet op de dagen dat hij niet werkt? Kan Piet deze persoon machtigen om goedkeuringen te geven op bijvoorbeeld workflows? Wilt Piet ook toegang vanuit huis als hij niet aanwezig? Hoe ziet de lijst van nieuwe productverzoeken eruit? Van wie komen deze verzoeken? Kan het nieuwe systeem Piet voorzien van een soortgelijke lijst? Welke velden moet Piet dan kunnen invullen?
Het programma van eisen
De interviews en de gebruikersscenario’s vormen de basis voor het programma van eisen (PvE). Door het PvE in beschrijvende vorm op te stellen, kunnen problemen en de huidige werkwijzen worden uitgelegd. Een PvE als opsomming kan gebruikt worden om de leveranciers beter met elkaar te kunnen vergelijken.
“Beschrijf het probleem of dilemma, niet de oplossing”
Valkuilen van een PvE
De valkuil van een PvE is dat de eisen snel te abstract worden. Een voorbeeld: de producttechnoloog wilt meerdere varianten van een specificatie kunnen vergelijken op ingrediënten en voedingswaarde, zodat op basis hiervan een uiteindelijk recept gekozen kan worden. De datamanager wilt verschillende versies van een specificatie met elkaar kunnen vergelijken, zodat snel inzichtelijk is waardoor een labeldeclaratie veranderd is.
Het gevaar is dat bovenstaande eisen geabstraheerd worden naar: Het moet mogelijk zijn alle versies en varianten van alle specificaties met elkaar te kunnen vergelijken.
Stel dat de software leverancier aangeeft dat er geen versiebeheer op verpakkingsspecificaties zit, dan kan de leverancier niet aan de gestelde eis voldoen. Echter kan het prima zo zijn, dat de leverancier voldoet aan de vooraf gestelde eisen. Een andere valkuil is dat de datamanager en producttechnoloog niet direct het verband leggen tussen hun eis en de geabstraheerde versie waardoor ze niet op tijd in actie komen.
Door de eisen vanuit rollen en user scenario’s op te stellen wordt voorkomen dat eisen te generalistisch worden en de gebruikers zich er niet meer in herkennen.
Van longlist naar shortlist
De oriënterende gesprekken met de leveranciers hebben plaatsgevonden en de behoefte van de organisatie is in kaart gebracht, het gevolgd is waarschijnlijk dat hierdoor een aantal leveranciers van de longlist kunnen worden weggehaald.. Wat overblijft is een selectie van leveranciers waarvan de organisatie acht dat zij de gewenste functionaliteiten kunnen opleveren; de shortlist.
Een afgestemde software demo
Aan de leveranciers kan gevraagd worden om een demo van de software voor te bereiden. Deze is anders dan de algemene demo die het bedrijf wellicht al eerder in het traject heeft laten zien.
Door een demoscript op te stellen, leg je vast welke zaken en in welke volgorde deze zaken door de leverancier getoond moeten worden. Een demoscript kan bestaan uit een lijst met instructies en een lijst met alle data die nodig is om het script te kunnen draaien. Die data bevat bijvoorbeeld personen, artikelen, grondstoffen of rapporten.
De leveranciers hebben dan een paar weken de tijd om met dit script de demo voor te bereiden. Alvorens de demo gegeven wordt is het belangrijk dat de demo stap voor stap is doorgenomen met de leveranciers en dat alle onduidelijkheden zijn weggenomen. Het gevolg is dat de leveranciers met demo’s komen die goed te beoordelen zijn omdat ze vergelijkbaar zijn met elkaar.
Nodig alle werknemers die betrokken zijn bij het selectietraject uit. Hierdoor wordt de betrokkenheid en acceptatie vergroot. Door iedereen een evaluatieformulier in te laten invullen, ontstaat een goed beeld van de prestatie van de leverancier.
Valkuilen van een software demo
- Leverancier toont zijn ‘keyfeatures’
- Leverancier besteedt veel tijd aan het verkooppraatje en gaat te lang in in op bedrijfsstrategie, klantportfolio en indrukwekkende statistieken.
- Leverancier interpreteert het demoscript verkeerd
- Leverancier gebruikt voorbeelden die niet aansluiten bij de organisatie. De productdata van een vliegtuig in plaats van een eierslaatje.
- Betrokkenen vragen te lang door naar ‘hun eigen stukje’.
- Alle requirements willen toetsen op basis van de demo.
- Werkwijzen 1 op 1 terug willen zien in de demo.
Eenvoudig en gebruiksvriendelijk
De functionaliteiten moeten getoetst worden op basis van het PvE. Een productdemo geeft ‘een gevoel’ bij de software. Het beantwoordt de eisen die moeilijk te toetsen zijn, zoals eenvoud, gebruiksvriendelijkheid en betrouwbaarheid; is de software snel, overzichtelijk, voelt het nieuw of oud aan, is de schermindeling logisch, is de navigatie duidelijk?
RFQ
Als de requirements verzameld en beoordeeld zijn door de organisatie kan een Request for Quotation opgesteld en verstuurd worden. Samen met de algemene en financiële eisen worden de leveranciers verzocht de requirements te beantwoorden en met een financieel voorstel te komen. Het resultaat van o.a. de ingevulde RFQ en de beoordeling van de demo is dat er een leverancier uitgekozen kan worden om verder te verdiepen.
De blueprint fase
In deze fase is er ruimte om dieper in te gaan op een aantal thema’s. Deze thema’s omvatten de bedrijfsspecifieke situaties zoals bijvoorbeeld:
- Hoe managen we meer dan 300 nieuwe producten en productmutaties?
- Hoe sluit het systeem aan op onze ERP oplossing?
- Kan het systeem omgaan met specifieke eiwit of vet berekeningen?
- Op welk niveau kunnen we onze locaties standaardiseren?
Als de uitkomst van de thema’s positief is dan kan het selectietraject worden afgesloten en begonnen worden aan de implementatiefase.
