Transcript Roll Out Analysis

Best Practices in ERP
Pakket Selectie
Een effectieve benadering van ERP selectie uit de praktijk
Pakketselectie
Page 1 / 9
Inhoud
1
Inleiding ................................................................................................... 3
2
Een klassiek ERP selectietraject ........................................................... 3
2.1
2.2
2.3
3
ERP pakketselectie - een alternatieve aanpak en best practices ....... 6
3.1
3.2
3.3
3.4
4
ERP vragenlijsten - de vragen ..................................................................... 3
ERP vragenlijsten - de antwoorden ............................................................. 4
Demonstratie van het ERP systeem ............................................................ 5
Waarom een ERP-implementatie? .............................................................. 6
Knock out criteria ........................................................................................ 6
Eigen organisatie ........................................................................................ 8
Proof of Concept ......................................................................................... 8
Conclusie................................................................................................. 9
Pakketselectie
Page 2 / 9
1
Inleiding
Sinds er ERP pakketten bestaan wordt enorm veel tijd besteed aan het selecteren van het
juiste ERP pakket. Sterker nog, er is een hele industrie ontstaan rond het begeleiden van
bedrijven in dit keuzetraject. Er is immers veel keuze op het gebied van ERP software, de
processen binnen het eigen bedrijf zijn veelvoudig en complex en last maar zeker niet least,
het invoeren van een ERP pakket is een tijdrovende en kostbare zaak.
In dit artikel gaan we in op het selecteren van een ERP pakket, gebaseerd op jarenlange
ervaring opgedaan zowel als begeleider van dergelijke trajecten, als in de rol van leverancier
van een ERP pakket.
2
Een klassiek ERP selectietraject
Een klassiek ERP selectietraject bestaat uit een aantal stappen waarin een bedrijf een keuze
probeert te maken uit een veelheid van ERP software aanbieders. Hoewel de details soms
verschillen bestaat dit traject vaak uit de volgende 3 stappen:
1. Door middel van een globale vragenlijst, de RFI (Request for Information) die aan
een groot aantal leveranciers wordt gestuurd, wordt een voorselectie ofwel een
‘long list’ van potentiële leveranciers gemaakt.
Soms staan op deze lijst nog een vrij groot aantal leveranciers. Het komt voor dat er
een long list wordt gemaakt met wel 10 verschillende ERP leveranciers.
2. Door middel van een zeer gedetailleerde vragenlijst, de RFQ (Request for Quote) die
aan alle leveranciers op de long list wordt gestuurd, wordt vervolgens een selectie
gemaakt voor een zogenaamde ‘short list’.
Een short list bestaat meestal uit niet meer dan 3 leveranciers.
3. Een uiteindelijke selectie wordt gemaakt door middel van een demonstratie: De drie
leveranciers geven – meestal op basis van door het bedrijf voorgeschreven
scenario’s – een demonstratie van een dag, uitlopend tot soms meerdere dagen.
Uiteraard speelt de uiteindelijke aanbieding van de leverancier ook een rol, maar we
nemen hier aan dat op basis van een demonstratie de beste kandidaat wordt
gekozen.
2.1
ERP vragenlijsten - de vragen
Zowel gedurende de RFI-selectie als de RFQ-selectie wordt de basis voor het afwegen van de
toepasbaarheid van een pakket gelegd in het beantwoorden van vragen. Deze vragen zijn
soms opgesteld door een partij gespecialiseerd in het begeleiden van selectietrajecten, maar
Pakketselectie
Page 3 / 9
vaak ook door het bedrijf zelf. Medewerkers van het bedrijf steken er veel tijd en moeite in
om de eisen en wensen rond het eigen proces in een vragenlijst te vatten.
Of de vragen nu door een externe partij of door medewerkers van het bedrijf zelf worden
opgesteld, gevalideerd of geselecteerd, het is vaak zo dat deze activiteit plaatsvindt op grote
afstand van het daadwerkelijke bedrijfsproces. De mensen die echt op de hoogte zijn van het
dagelijkse proces worden hier niet bij betrokken: zij hebben het immers druk met de
dagelijkse gang van zaken.
Daarnaast is een bedrijf dat een nieuw pakket selecteert altijd bevooroordeeld door huidige
werkwijzen of beperkingen in de huidige software bij het opstellen van de vragenlijsten. Dit
leidt vaak tot het toevoegen van vereisten en wensen die de kern van de zaak niet raken,
maar ingegeven zijn door de angst om in de toekomst (weer) met een frustrerend proces
geconfronteerd te worden.
Tenslotte bestaat het gevaar dat een vragenlijst vooral ingaat op vereisten rond de te
ondersteunen bedrijfsprocessen en -activiteiten, en dat voorbij gegaan wordt aan criteria als
een eenvoudige implementatie en aanpasbaarheid aan toekomstige situaties.
2.2
ERP vragenlijsten - de antwoorden
De meeste vragenlijsten zijn zo opgesteld dat de leverancier alleen maar hoeft op te geven
of de gevraagde functie al dan niet beschikbaar is. In wat uitgebreidere lijsten kan de
leverancier voor de gevraagde functies vermelden wat de mate van afdekking is en of er een
eventuele ‘work around’ beschikbaar is. Dat is gemakkelijk, want op deze manier kan de
leverancier voor ieder gebied een bepaalde mate van afdekking berekenen. Dit leidt tot
mooie overzichten en scorelijsten op basis waarvan het bedrijf zich een mening kan vormen
over de toepasbaarheid van het pakket.
Maar is dat werkelijk zo? Niet zelden worden vragen zodanig opgesteld dat het voor iedere
leverancier simpel is volmondig ‘ja’ te antwoorden, wat ze dan ook graag doen. Complexe
functionaliteit is echter bijna nooit in een simpel ‘ja’ of ‘nee’ te vervatten.
Om een simpel voorbeeld te geven, een vraag zou kunnen luiden of het mogelijk is een
voorraad te blokkeren voor verscheping (omdat de goederen bijvoorbeeld in quarantaine
liggen). Hoewel de meeste leveranciers volmondig zullen beamen dat dit mogelijk is met de
door hun geboden software, schiet het bedrijf hier niet veel mee op: wellicht is het
noodzakelijk partijenregistratie te voeren voor dergelijke functionaliteit, of is een veelheid
aan transacties noodzakelijk om dit voor elkaar te krijgen of heeft het bijwerkingen op
andere processen die niet wenselijk zijn. Dat blijft echter allemaal onzichtbaar achter het
simpele antwoord in de lijst.
Pakketselectie
Page 4 / 9
2.3
Demonstratie van het ERP systeem
Het hierboven geschetste probleem zou eventueel in een demonstratie aan het licht kunnen
komen, maar vaak beslaat een demonstratie niet het hele bedrijfsproces. Omwille van de
tijd toont de leverancier uitsluitend een paar sleutelscenario’s aan het bedrijf.
Is een demonstratie werkelijk de beste manier om vast te stellen of de software in de
praktijk zal werken voor een klant? Ga je bij het uitzoeken van een nieuwe auto naast een
verkoper in de auto zitten?
Het voorbereiden van een demonstratie op maat kost vaak erg veel tijd: de leverancier
probeert uiteraard om zoveel mogelijk aan te sluiten bij de belevingswereld van de
potentiële klant. Tijdens de demonstratie is er meestal geen tijd om het bedrijfsproces te
bespreken of na te gaan of de beschreven proces-stappen wel de beste zijn, ook in de
software van de leverancier.
Het bedrijf besteedt dus veel tijd aan het samenstellen van de scenario’s die getoond moeten worden en de aanbiedende partijen besteden veel tijd aan het zo naadloos mogelijk
toepassen van die scenario’s in hun software.
Is het pakket van de leverancier die er als beste in slaagt het beeld te scheppen dat alle
processen die door het bedrijf beschreven zijn ook precies zo in zijn software verwerkt
kunnen worden, echt de beste optie voor het bedrijf?
Er is uiteraard veel meer te zeggen over de stappen in een selectietraject en er gebeurt vaak
veel meer dan het opstellen en invullen van vragenlijsten en het kijken naar een
demonstratie, maar deze activiteiten vormen wel de grootste tijdsbesteding in ieder traject,
zowel van het bedrijf als de potentiële leveranciers. Het grootste probleem van deze
werkwijze is dat bedrijf en leverancier niet in een echte dialoog zijn, maar geïsoleerd van
elkaar – vaak ook expliciet afgedwongen door een selectiepartij – heel druk bezig zijn met de
beoordeling over en weer.
Daarnaast kost het selectietraject op deze manier enorm veel tijd. Het is niet ongebruikelijk
dat een dergelijk traject wel een jaar duurt. Maar eigenlijk is een tijdsduur van meer dan drie
maanden sowieso niet acceptabel: de
vereisten aan het begin van het
selectietraject en die aan het begin van
de daadwerkelijke implementatie liggen
anders veel te ver uit elkaar: De wereld
waarmee het bedrijf interacteert en het
bedrijf zelf staan immers niet stil.
Pakketselectie
Page 5 / 9
3
ERP pakketselectie - een alternatieve aanpak en best
practices
De oplossing voor dit probleem is om alleen met vragenlijsten te werken met vragen die
echt ondubbelzinnig te beantwoorden zijn (waarbij een ‘ja’ of ‘nee’ ook echt wat betekent)
en die discriminerend genoeg zijn om veel sneller een shortlist op te stellen van pakketten
die waarschijnlijk werken voor het bedrijf. Daarnaast is het goed om sneller in dialoog te
gaan met een leverancier en gezamenlijk de beste oplossingen voor sleutelprocessen in het
bedrijf te bepalen. Dat kan immers alleen maar door samen te werken. Het is dus belangrijk
snel in te zien met welk pakket dat wel en niet de moeite waard is.
Het volgende stappenplan voorziet daarin.
3.1
Waarom een ERP-implementatie?
Hoewel iedere implementatiemethode aangeeft dat ‘top level management buy in’ enorm belangrijk is, en elke analyse naar falende ERP implementatie trouw diezelfde reden op
nummer 1 zet, blijkt het in de praktijk vaak lastig hier handen en voeten aan te geven.
Een manier om dit te doen is de CEO of Managing Director van het bedrijf te vragen in een
zin aan te geven waarom dit implementatietraject nodig is. Neem geen genoegen met het
obligate ”Om alle processen te harmoniseren” of “Om toekomstige groei te faciliteren”,
maar wacht tot hij of zij met een goede visie komt. Deze visie moet meegenomen worden in
zowel het selectietraject (“is deze eis werkelijk belangrijk, in het licht van het uiteindelijke
doel?”) als het uiteindelijke implementatie traject (”is deze change request werkelijk zo
belangrijk in het licht van het uiteindelijke doel?”).
Ook is het van niet te onderschatten belang te begrijpen dat ERP uiteindelijk processen
automatiseert die dwars door de organisatie – die vaak in afdelingen is georganiseerd – heen
gaan. Wanneer het bedrijf niet in staat is helder aan te geven waar het eigenaarschap van
processen ligt is het configureren van om het even welk afdeling overschrijdend proces dan
ook eigenlijk bij voorbaat gedoemd te mislukken. De uitdaging is om binnen de bestaande
organisatie helder eigenaarschap te beleggen van deze processen.
3.2
Knock out criteria
De meeste ERP leveranciers die vandaag de dag nog een gezond bestaan leiden leveren
prima producten. Meestal zijn er meerdere ERP pakketten waarmee bedrijven hun
bedrijfsprocessen zouden kunnen ondersteunen. De vraag welke precies het beste van
toepassing is, is niet zo eenvoudig te beantwoorden en vergt echte aandacht in de verdere
selectie. Als eerste is het zaak geschikte pakketten te identificeren. Dat kan vaak prima aan
de hand van een zeer overzichtelijk aantal criteria, waarvoor hieronder een aanzet wordt
gegeven:
Pakketselectie
Page 6 / 9
Technisch
Wat is het technische platform van de oplossing in termen van mogelijke
virtualisatie, operating systems, databases en applicatieservers?
Is het mogelijk de software ‘as a service’ helemaal gehost af te nemen?
Wat is het platform voor de cliënt: is er een webgebaseerde klant, is er een Citrix of
terminal server-achtige oplossing nodig of moet er een echte klant worden
geïnstalleerd? Zo ja, zijn er beperkingen in het besturingssysteem?
Hoe zit het met de ondersteuning van tablets, smartphones en dergelijke?
Wat is de ondersteuning op het gebied van meertaligheid, zowel voor de eigen
gebruikers als klanten en leveranciers?
Is een gemakkelijke tool voor het maken van operationele rapportage beschikbaar
voor het ERP platform?
Financieel
Is het mogelijk meerdere administraties naast elkaar te voeren?
Is consolidatie van deze administraties mogelijk, ook zonder dat de daadwerkelijke
grootboekrekeningen gelijk zijn?
Worden statutaire rapporten van meerdere landen (in Europa) ondersteund?
Is het mogelijk de administratie in meerdere valuta te voeren, afhankelijk van het
land waarvoor deze administratie wordt gevoerd?
Logistiek
Worden directe leveringen naar klanten van zusterbedrijven ondersteund?
Hoe zit het met de administratie van voorraad in consignatie, vendor managed
inventory, maar ook geblokkeerde voorraad en voorraad bij een 3PL?
In welke mate worden EDI transacties ondersteund?
Hoe zit het met de ondersteuning van value added logistics (ompakken, verpakken,
kitting, etc)?
Productie
Worden meerdere productie strategieën, eventueel naast elkaar, ondersteund
(klantorder gestuurd, voorraad gestuurd, rate gebaseerd, etc)?
Is het mogelijk ERP te integreren met Shop Floor Control systemen?
Hoe wordt invulling gegeven aan capaciteitsplanning en scheduling?
Deze lijst pretendeert in geen geval compleet te zijn, maar breekt een lans voor een aanpak
waarbij op basis van vrij simpele vragen er een zeer beperkte lijst van potentiële aanbieders
kan worden gedaan.
Pakketselectie
Page 7 / 9
3.3
Eigen organisatie
Naast de vragen die het bedrijf kan stellen aan de ERP leverancier, moet ieder bedrijf dat
overweegt ERP te implementeren ook heel kritisch durven kijken naar de eigen organisatie.
ERP automatiseert bedrijfsprocessen die worden uitgevoerd door verschillende afdelingen.
Deze zullen expliciet moeten samenwerken en consensus bereiken over hoe de processen
door de organisatie en afdelingen zullen gaan lopen. Is er een helder beeld van die
bedrijfsprocessen? Invoering van ERP grijpt diep in, waarbij processen wellicht aangepast
moeten worden. Is het duidelijk waar de autorisatie voor het veranderen en ontwerpen van
processen ligt? Vooral wanneer meerdere bedrijven deel uitmaken van de implementatie is
dit een boeiende vraag, die een eenduidig antwoord behoeft. Zonder helder eigenaarschap
van processen zal een ERP pakket niet voldoen aan de verwachtingen en leiden tot
teleurstellingen.
Een illustratie van het probleem dat hierboven wordt geschetst is de verantwoordelijkheid
voor de stamgegevens. Ieder ERP systeem is afhankelijk van de stamgegevens (artikelen,
klanten, leveranciers, recepturen, etc.) om transacties te kunnen doen. Is het duidelijk wie
verantwoordelijk is voor beslissingen over die data – afkomstig van alle afdelingen en / of
bedrijven die deel uitmaken van de implementatie – bijvoorbeeld over de wijze van
coderen? Denk hierbij aan artikel nummering, grootboek nummers, leveranciersnummers,
klanten nummers, etc. Wanneer beslissingen hieromtrent lang duren is dat vaak een
indicatie dat er gewerkt moet worden aan de eigen organisatie om succes op het invoeren
van een bedrijfsbreed ERP systeem te garanderen.
3.4
Proof of Concept
In de proof of concept fase breekt aan wanneer de eigen organisatie gereed is en gekozen
moet worden uit een shortlist van maximaal 3 pakketten. In deze fase wordt gecontroleerd
of het ERP pakket daadwerkelijk zal voldoen aan de hooggespannen verwachtingen.
Hierbij wordt niet alleen om een demo gevraagd, maar in nauwe samenwerking met de
potentiële leverancier worden een aantal kritische processen compleet uitgewerkt in een
demonstratie omgeving. Dat gaat veel verder dan een demonstratie en zal tijd vragen van
zowel de leverancier als het bedrijf. Vier of vijf kritische bedrijfsprocessen worden end-toend uitgewerkt in een demonstratie systeem in sessies waarin de leverancier en het bedrijf
zij aan zij samenwerken om de beste configuratie te vinden voor specifieke problemen. Niet
alleen wordt zo het proces daadwerkelijk optimaal afgebeeld in de ERP software, maar
tevens wordt duidelijk of er sprake is van een goede samenwerking in een eventueel
implementatie traject.
Pakketselectie
Page 8 / 9
Het is niet onlogisch wanneer het bedrijf daarvoor een rekening betaald aan de leverancier:
Er wordt immers veel waarde geleverd gedurende dergelijke stoom configuratie sessies. Er
valt vervolgens vast te onderhandelen over een credit wanneer het project gegund wordt
aan de leverancier. De processen kunnen tenslotte in een demonstratie worden getoond aan
en beoordeeld door de organisatie, die dan niet kijkt naar een systeem dat optimaal voor
een demonstratie is getuned, maar optimaal is ingesteld voor het daadwerkelijk kunnen
verwerken van bedrijfstransacties.
4
Conclusie
De geschetste aanpak (Knock out vragen, Proof of
Concept, Contract) versnelt het beslissingstraject
uiteraard enorm. De schatting van 6 maanden uit de
figuur hiernaast is aan de conservatieve kant, maar een
halvering is zeker mogelijk.
De tijdswinst is echter niet het grootste voordeel van
deze aanpak. Door deze strategie worden de grootste
faalfactoren van ERP implementaties in een zo vroeg mogelijk stadium zichtbaar en kunnen
worden aangepakt. Van het bedrijf wordt gevraagd inzicht te geven in processen waar het in
het bedrijf om draait, deze goed om te kunnen zetten in een configuratie en eventuele
organisatorische – en proces veranderingen te begrijpen en te initiëren. De kiem voor
excellent proces eigenaarschap is daarmee gelegd. Daarnaast wordt het pakket beoordeeld
op de manier waarop die processen daadwerkelijk worden afgebeeld in een potentieel
systeem. Dat maakt het onmogelijk voor de leverancier om de zaken mooier voor te stellen
dan ze wellicht zijn: er wordt immers geen demonstratie gegeven maar er wordt een proof
of concept beoordeeld. Last maar zeker niet least wordt duidelijk hoe gedurende een ERP
implementatie kan worden samengewerkt met de leverancier gedurende een intensief
traject: Een ERP implementatie is tenslotte een ‘contact sport’.
5
Next Step
Wilt u meer weten over ERP Selectie? Kijk dan gerust verder op het kennisplatform
www.enterpriseresource.nl,
of neem contact op met een van de partners voor een advies op
✓
maat.
http://www.enterpriseresource.nl/partners/
Pakketselectie
Page 9 / 9