Paradox

ERP Pakketselectie

Stappenplan

Voordat u direct begint met uw ERP pakketselectie hebben we hier de do’s en don’ts op een rij. Er is zeker wel een heus stappenplan die u dient te volgen voor een perfect fit. Het is dus meer dan alleen maar vergelijken van welk pakket heeft de meeste features beschikbaar voor mijn organisatie of het invullen van wat nu gaten zijn in de huidige implementaties.

Maak goede afspraken

Klinkt misschien als een open deur, maar er falen nog steeds een hoop implementaties doordat er eigenlijk niet goed van te voren de juiste afspraken zijn vastgelegd. Dit resulteert in veel ergernis, geld over de balk smijten of zelfs software afkeuren en zoeken naar een nieuwe oplossing. U moet bijvoorbeeld denken aan de volgende vragen die resulteert in afspraken:

  • Hoe komt het implementatieproject eruit te zien?
  • Hoe worden onze gebruikers begeleidt in het traject, wanneer de implementatie is afgerond? Op welke manier wordt het afgeleverd?
  • Worden onze gebruikers betrokken bij de functionaliteit die nodig is?

Maak dus van te voren een lijst met vragen, waarin uw potentiële implementatie partner antwoord geeft wat dient te resulteren in afspraken.

Past de leverancier bij uw organisatie

Niet geheel onbelangrijk is hoe de leverancier past binnen uw organisatie. Vaak wordt gekeken naar gelijksoortige bedrijven of bedrijven met een solide omvang. Dit is niet altijd even handig wanneer u eigenlijk flexibel of snel wilt schakelen. Sterker nog deze keuze kan behoorlijk tegenwerken. Ten tweede dient u rekening te houden met de oplossing die wordt aangeboden. Niet hoe het werkt, maar hoe het nu in de markt wordt gezet. Denk hierbij aan branchespecifieke software, of standaard oplossingen waarin ineens een hoop nadelen naar voren komen wanneer er maatwerk nodig blijkt te zijn. Sommige bedrijven zijn goed in het bouwen van standaard software, maar hebben geen idee wanneer er maatwerk om de hoek komt kijken en andersom. Bij Athena Online zien we het als onze belangrijkste taak om beide werelden bij elkaar te houden en in harmony te laten functioneren.

Pakketselectie of zelfbouw

U zoekt een pakket dat perfect binnen uw organisatie kan worden ingezet en waarin u morgen kunt beginnen. Of u zoekt een organisatie die het gehele ERP systeem voor u bouwt, zodat het perfect past binnen uw organisatie. Wij willen niet zeggen dat u het mis heeft, maar misschien is het een idee om te kijken naar Athena Online waarin beide werelden bijeenkomen. U begint met basismodules die in een standaard jasje gegoten zijn, waardoor de functionaliteit voor ieder bedrijf inzetbaar is. Vervolgens wordt het helemaal naar uw hand omgebogen, dat is de dynamiek van Athena Online. Dit geeft u een headstart van 3 tot misschien wel 5 jaar ontwikkeltijd, voor wanneer u volledig zelfbouw op het oog heeft.

Athena Online heeft nog een voordeel die veel leveranciers u niet kunnen garanderen. Dit voordeel heeft te maken met de snelheid waarop software kan worden opgeleverd. Uiteraard wordt er samen met de gebruiker gekeken naar wat er moet worden aangepast of aangebouwd en dient dit goed gedocumenteerd en geanalyseerd te worden, tot zover niets nieuws onder de zon. Maar dan komt het, wij garanderen een uitermate snelle implementatie dankzij ons uitgekristalliseerd framework. Dit framework zorgt voor de dynamiek waar de bedrijven van tegenwoordig niet meer zonder kunnen. Hoe vaak heeft uw bedrijf de boot gemist, doordat u niet in staat was snel mee te buigen met uw potentiële klanten? Laat het niet afhangen van stugge software, waarin bewegingsvrijheid ver te zoeken is.

Externe consultants

Oke u bent zover, u heeft uw leverancier gekozen en wacht tot ze weer langskomen om samen met u een planning te maken. Vervolgens komen ervan dat bedrijf consultants over de vloer die de implementatie verder gaan uitvoeren. Het is echter de taak van uw bedrijf om de consultants te begeleiden door uw organisatie. Wijs daarom key users aan per onderdeel en stel ze voor, zodat de externe consultants weten bij wie ze moeten zijn voor welk onderdeel. Er dient ook een communicatieplan te komen voor wat betreft functionele wensen, terugkerende vergaderingen, beschikbaarheid intern personeel enz.

Zorg ook dat intern personeel beschikbaar is, zodat consultants niet hun eigen plan gaan trekken. Er zit veel verschil tussen consultants en hun implementatie filosofieën. Het is ook aan u of u wilt gaan voor een “Big Bang” (in één keer) of mondjes maat (module voor module) over op het nieuwe systeem. Beide keuzen hebben hun voor en nadelen. Het is eigenlijk de afweging tussen budget en tijd ten opzichte van impact en voorzichtigheid richting de gebruiker.

Stop ERP in uw organisatie niet andersom

Een nieuwe implementatie van een ERP systeem brengt altijd verandering met zich mee, dit kan niet worden tegengehouden. Zorg er dan voor dat u hier de voordelen uithaalt. Zorg ervoor dat de organisatie en hun processen zich gaan bewegen in de filosofie van “hoe zou het moeten”. Breng in kaart hoe jullie als organisatie denken te willen gaan werken. Dit is een belangrijk punt dat duidelijk dient te zijn voordat er gekeken wordt naar het juiste pakket. U wilt immers eerst een totaal beeld van uw processen, zodat u ziet welke functionaliteit er allemaal nodig is.

MOSCOW

Hanteer het MOSCOW principe om duidelijk te classificeren hoe belangrijk bepaalde features/functionaliteit is:

M = Must Have (U kunt niet zonder functioneren als bedrijf)
S = Should Have (Hier kunt u omheen werken maar is niet handig)
C = Could Have (U zou hier eventueel gebruik van willen maken)
W = Would Have (Dit is echt nice to have, maar niet echt nodig)

Na classificatie is het uitermate eenvoudig deze te sorteren. U kunt natuurlijk ook de letters vervangen door prioriteit 1-4.

Begin met visie

Begin ook met een visie. Wat wil je bereiken met de implementatie, en welke invloed heeft dit op de cultuur van uw organisatie. Wilt u wel veranderen? En wat is het tolerantie level binnen de organisatie om dit te verwezenlijken. Vaak helpt het om een globale schets te maken van de basisprocessen in de organisatie. Dit geeft niet alleen een beeld in de vorm van een “helicopterview”, maar biedt tevens houvast in het verdere verloop van de implementatie. Wanneer gebruikers en teams de diepte in gaan wordt het grote plaatje wel eens vergeten. Hier kunt u dan ook eenvoudig op terugvallen.

Draagvlak

Oke, u heeft nu het grote plaatje in beeld, weet hoe het één en ander functioneel eruit moet komen te zien en wat de impact is op de organisatie is ook scherp in beeld gebracht. Bent u er dan helemaal klaar voor? Het antwoord is min of meer ja. Waar we het echter nog niet over hebben gehad zijn de eind gebruikers. Zij hebben ook indrukken van hoe hun werkomgeving eruit moet komen te zien. Kan ik als gebruiker nog alles doen? Kan ik alles registreren wat broodnodig is voor andere afdelingen om zaken verder op te pakken? Dit zijn belangrijke vragen die tevens moeilijk te beantwoorden zijn. Wanneer er draagvlak gecreëerd wordt bij de eindgebruikers (heeft iedereen zin in verandering) geeft dat een bepaalde rust op het implementatietraject, wat veel tijd en geld bespaard op de lange termijn.

Hier een aantal voorbeelden op een rij die bij geen draagvlak negatief werken ten opzichte van voldoende draagvlak:

  • Eindgebruiker ziet implementatie graag falen, zodat men terug kan werken met het oude systeem
  • Eindeloze implementatie en wijzigingen, omdat het niet precies doet wat het oude systeem doet
  • Niet bereid om werkwijze te veranderen, omdat de voordelen niet worden ingezien
  • Er wordt meer gestuurd op uitzonderingen dan wat regulier is
  • Assertiviteit bij eindgebruikers is niet aanwezig, externen moeten hun informatie letterlijk gaan zoeken
  • Eindgebruikers hebben geen tijd,te druk met hun dagelijkse werkzaamheden

Technische oogpunt

Vaak worden implementatie trajecten vanuit technisch oogpunt benaderd. Zijn er servers beschikbaar? Is alles veilig ingeregeld? Zijn de gebruikers gekoppeld? enz. Dit leent er zich voor om de ICT afdeling verantwoordelijk te maken voor het verdere verloop van het traject. Dit kan op het eerste gezicht behoorlijk handig zijn, totdat we komen tot de functionele wensen vanuit de gebruikersgroepen. Normaliter houdt het dan bij uw ICT afdeling op. Denk even terug aan het MOSCOW principe. U heeft alles netjes op een rijtje en heeft 50 van de 300 punten vanuit verschillende afdelingen op prio M staan (Must) en nog een 90 op S (Should). De afdeling ICT kan niet bepalen wat er eerst gebouwd moet worden door de externe consultants, dus heeft hier de input van de gebruiker nodig.

Wat we tegenwoordig gelukkig steeds vaker zien is dat er thema’s gemaakt worden van de benodigde functionaliteitswensen en dat op basis daarvan vanuit de organisatie gebruikersgroepen worden gemaakt, die samen gaan beslissen welke punten het belangrijkst zijn. Zij kanaliseren dus de stroom van wensen richting de consultants om ervoor te zorgen dat het (sub)project een grotere kans van slagen heeft.

 

 

 

0 antwoorden

Plaats een Reactie

Meepraten?
Draag gerust bij!

Geef een reactie