it de selectie van een (erp-)pakket: bezint voor u begint! maak de juiste keuze in vijf stappen Wanneer bedrijven vaststellen dat hun administratieve processen met draadjes aan elkaar beginnen te hangen, met alle administratieve overlast en bijhorende kosten vandien, wordt vaak gedacht aan de aanschaf van een ERP-systeem. De grote toegevoegde waarde van ERP’s ligt precies in de integratie van data en processen. Zo ontstaat een flow waarbij alle transacties meteen correct worden verwerkt, de voorraden aangepast, en de boekhouding bijgewerkt. Dit alles leidt bovendien tot adequate sturingsinformatie. Tenminste, dat is de theorie. In onze dagelijkse praktijk zien we het echter vaak verkeerd lopen en leidt een ERP-implementatie niet altijd tot het gewenste resultaat. In dit artikel gaan we in op de factoren die het succes bepalen van de eerste kritische stap, met name de keuze van het juiste pakket. Het mag hiermee meteen duidelijk zijn dat een succesvolle implementatie begint met goed voorwerk. q Het functioneel lastenboek De ultieme droom van ieder bedrijf is dat alle data geruisloos door een ERPsysteem zoemen, vanaf de captatie van transactiegegevens tot en met de productie van een relevante managementrapportering. Heel vaak is dit te hoog gegrepen, en soms ook niet wenselijk voor een eenmalig implementatietraject, omdat zowel de kost, doorlooptijd en complexiteit van een dergelijk project te hoog oplopen. Bedrijven zullen derhalve vaak opteren voor een trapsgewijze implementatie. Toch is de ontwikkeling van een visie op het eindstation een belangrijke eerste stap. Niet zelden zien we binnen bedrijven modules van verschillende ERPsystemen naast mekaar lopen, omdat er bedrijfsbreed geen visie op de langere termijn werd vastgelegd. Dat is doodzonde, omdat men op die manier per definitie een stuk van de voordelen van een ERPbenadering verliest. 24 cfo magazine september 2014 De vastlegging van een visie is een functionele oefening, en komt dus in de eerste plaats de managers van de verschillende bedrijfsonderdelen toe. Verwar deze fase dus niet met een IT-oefening. Eens de globale visie is vastgelegd, worden de concrete behoeften meestal in een functioneel lastenboek vertaald: de gewenste to be-situatie wordt hierin beschreven na een grondige procesevaluatie. Hoe duidelijker het bedrijf de gewenste situatie beschrijft, hoe beter de aangesproken kandidaten voor een eventuele implementatie hierop kunnen inspelen, en zich ook later minder zullen kunnen verschuilen achter onduidelijkheden bij de aanvang. Ì Ì Ì Ì w De Request for Proposal (RFP) Het functioneel lastenboek dat werd opgemaakt is een onderdeel van de Request for Proposal (RFP) die naar de potentiële aanbieders van de ERP soft ware wordt verstuurd. In de RFP wordt verder aangegeven welke de verwachtingen zijn ten aanzien van de leverancier. Vraag hierin op zijn minst : een helder project plan, met daarin de mijlpalen voor de realisatie van het project. een complete prijsofferte, met inbegrip van de basisprijs van de modules, de noodzakelijke aanpassingen die specifiek zijn om aan de behoeften te voldoen (‘customizations’), de middelen vereist voor de implementatie, en de licenties. Vergeet bij dit laatste zeker niet de gradatie van de licenties: welke licenties zijn er, is er onderscheid naar type gebruikers, of naargelang de gebruikte modules? een overzicht van de functionaliteiten waaraan niet standaard kan worden voldaan een lijst van referenties Het spreekt vanzelf dat hoe beter de RFP werd opgesteld, hoe beter de verschillende aanbiedingen beoordeeld zullen kunnen worden. e De eerste beoordeling van de leveranciers De belangrijkste categorieën waarop een offerte wordt getoetst zijn zeker de prijs, de invulling van de behoeften (compliance), “Verwar deze fase niet met een IT-oefening” ERP luc dekimpe trifinance en de voorgestelde aanpak. Daarnaast kunnen nog een aantal bijkomende elementen meegenomen worden. Elk van de selectiecriteria moet een weging of puntentotaal toegewezen krijgen en voor elk apart kan vervolgens een score bepaald worden. Ì Ì Ì de prijselementen: de laagste prijs krijgt de hoogste score, de andere offertes een score in verhouding (bv. 20% hogere prijs is 20% lagere score) de compliance factor: de graad van overeenstemming van de functionele standaardmogelijkheden van het pakket in overeenstemming met de vereisten van het bedrijf. Uiteraard is dit een uiterst belangrijk element in de beoordeling. het voorgestelde implementatie- en projectplan: hoe is dit opgebouwd, en welke is de voorgestelde projectmethodiek? Hoe realistisch is het projectplan? Vaak valt ook hier veel te leren door vergelijking tussen de verschillende offertes. En wat heeft iedere samenwerking als weerslag op de interne organisatie naar tijdsbesteding en expertiseopbouw? Bijkomende elementen zijn : de soliditeit en betrouwbaarheid van de implementatiepartner: welke profielen heeft men in huis? Welke projecten heeft men reeds gerealiseerd? Hoe goed kent men de voorgestelde soft ware? Hoe goed kan men zich inleven in de noden van het bedrijf ? Ì de referenties: welke referenties geeft de implementatie partner zelf op? Wat is hun feedback, en wat is hun relevantie voor het eigen project? Hoe was de ervaring tijdens de implementatie en die na een go-live? Is er een onderlinge consistentie tussen deze referenties waar te nemen of is er tegenspraak? Ì de impact op de interne resources: is dit voldoende duidelijk aangegeven, en is dit haalbaar voor de interne organisatie? Hoe groot is het risico op te veel externe afhankelijkheid na go-live? Ì Laat zeker niet na de kandidaten die u interessant lijken uit te nodigen voor een diepgaand gesprek. Niet enkel zal dit uw gevoel meer substantie geven, u zal er ook altijd wat van opsteken dat interessant is voor het verdere verloop van uw project. Voor de elementen buiten de prijs kan best eerst een waarderingsschaal worden gebruikt (bv. +++ / ++ / + / = / - / -- / ---) die daarna vertaald wordt in een score naargelang de belangrijkheid van het specifieke criterium. Ì Ì r De test van de leveranciers: de Proof of Concept Op basis van de beoordeling van het RFP proces, zal aan geloofwaardige aanbieders ook gevraagd worden een test-demo te geven van hun soft ware pakket. Niet alleen de standaard-demo, maar ook een vooraf beschreven testscenario moet door het bedrijf zelf bij de RFP gevoegd wordt. Zo’n scenario wordt in het jargon Proof of Concept (PoC) genoemd. Ook dit is niet evident, en een foute aanpak kan een struikelblok betekenen in de juiste selectie en beslissing. Om een bruikbaar resultaat te hebben zal elk van de weerhouden soft ware aanbieders een identieke PoCdemo moeten doen zodat vergelijking mogelijk is. Enkele aanbevelingen: Ì Beschrijf duidelijk en stap voor stap de transacties die je in de demo wil zien; Ì Hou de master data die je daarbij opgeeft simpel, vermijd verwarring; Ì Zorg ervoor dat je uiteindelijk een duidelijke beoordeling kan maken van de verschillende relevante processen; Ì Ì Vraag aan de verschillende aanbieders hoeveel tijd ze inschatten om de PoCdemo op een redelijke manier te kunnen doen; Maak het scenario evenwel zo op dat een tijdsbestek van ± 4 uur haalbaar is; Focus op materialiteit, niet op details; Laat de PoC-demo bijwonen door een kern van key-users. Bepaal vooraf ook duidelijk wat je wil beoordelen (de kwaliteit van de demo, de compliance met de vereisten, aangetoonde gebruiksvriendelijkheid, de getoonde functionaliteiten, bepaalde technische elementen, enzovoort). Ook aan de PoC wordt door de verschillende deelnemers best een score toegekend t De finale keuze Aan de overgebleven aanbieders wordt een definitieve offerte gevraagd (ook wel benoemd als de Best and Final Offer of BAFO) gevraagd, na een laatste onderhandeling met de overgebleven aanbieders. U bent nu klaar om een goed overwogen beslissing te nemen op basis van een duidelijk proces. Het is een eerste fundament voor het welslagen van het verdere implementatie traject. Overigens hebben veel van de elementen in dit artikel niet enkel betrekking op de selectie van een ERPpakket. Đ cfo magazine september 2014 25
© Copyright 2024 ExpyDoc