ERP – Selectie traject

De selectie van een nieuw ERP systeem.

In gesprekken met prospects is dit vaak een gespreksonderwerp. Men probeert hiermee aan te geven dat dit onderwerp prioriteit heeft boven mijn favoriete onderwerp, namelijk: Applicatie Integratie. Beide maken deel uit van een applicatie architectuur waarbij afhankelijk van de keuzes deze applicatie architectuur wel of niet toekomstbestendig is.

De logische keuze
Het is heel gebruikelijk om een pakket te selecteren dat het best de bedrijfsprocessen van het bedrijf ondersteunt. Als dit het enige selectiecriterium is zal de uitkomst vaak zijn dat geen van de overwogen pakketten de perfect match is; anders gezegd een 100% dekkingsgraad heeft. Een traditionele manier om de ontbrekende functionaliteit alsnog te realiseren is… maatwerk. Als het zou gaan om de ontbrekende 5% is dit best acceptabel.

De harde praktijk
In werkelijkheid kan de ontbrekende functionaliteit tussen de 50 en 99 % bedragen. Als we de leverancier vervolgens vragen dit gat te dichten met maatwerk zullen we (onaangenaam) verrast worden met een kostenpost en een doorlooptijd die de implementatie van het pakket niet bevordert. Als de doorlooptijd van het maatwerk extreme vormen aanneemt (denk hierbij aan jaren) kan het zomaar zijn dat door voortschrijdend inzicht het maatwerk al achterhaald is vóór het is geïmplementeerd. Daarnaast is het nog de vraag of de leverancier hiervoor capaciteit kan en wil leveren. Een neveneffect is dat bij een nieuwe release van het pakket al het gerealiseerde maatwerk tegen het licht moet worden gehouden en waar van toepassing opnieuw moet worden geïmplementeerd.

Andere scenario’s

Zijn er ander mogelijkheden om tot een 100% dekkende oplossing te komen zonder de hierboven beschreven nadelen? Laten we eens uitgaan (hypothetisch) van een pakket met een 60% dekkingsgraad.

Stap 1
Als eerste kan worden nagedacht of een deel van de werkwijze van het bedrijf kan worden ondergebracht in hoe het pakket dit voorschrijft. Dit kan rekenen op weerstand binnen de organisatie. Maar anderzijds accepteren we een nieuwe Windows versie waarin de interface en werkwijze verandert als vanzelfsprekend. Stel dat we hiermee 10% ontbrekende functionaliteit alsnog binnen de standaard van het pakket kunnen oplossen?

Stap 2
Nog 30% te gaan. Als we in plaats van meteen weer aan maatwerk te denken de markt verder verkennen naar bestaande oplossingen in andere pakketten? Zo kan bijvoorbeeld een planning module die beter aansluit bij de specifieke wensen worden geselecteerd en naast het ERP systeem worden geïmplementeerd. Voorwaarde is dan wel dat deze gevoed moet worden met gegevens die deels uit het ERP en mogelijk andere systemen komen en eventueel verrijkt via een user interface. Hier komt dan onze expertise om de hoek namelijk applicatie integratie. We doen even de aanname dat bovenstaand scenario nog 15% van de ontbrekende functionaliteit oplost.

Stap 3
Nog 15% te gaan. De in stap 2 genoemde aanpak kan tevens gelden voor overige ontbrekende functionaliteit en daarmee de dekkingsgraad van de totale oplossing verhogen naar 90%

Stap 4
Nog 10% te gaan. In onze casus is de constatering dat de ontbrekende 10% in geen enkele (standaard) oplossing op de markt verkrijgbaar is en we dus niet ontkomen aan maatwerk. Vervolgens dient zich de vraag aan waar en waarmee we dit maatwerk gaan realiseren. Met “waar” bedoel ik Ín het ERP pakket of er naast. Bij een keuze om het in het pakket te realiseren blijft er bij nieuwe versies van het pakket de eerder beschreven situatie van het opnieuw implementeren van het maatwerk. Wellicht niet onoverkomelijk. Optie 2 is het maatwerk naast het pakket te ontwikkelen met bijvoorbeeld een Low-Code platform. Uiteraard geldt ook hier dat er data uitwisseling nodig zal zijn tussen systemen.

Conclusie & aanbeveling

Bovenstaande laat zien hoe je ook een 100% dekkende oplossing kan creëren zonder de erfenis van het ERP systeem mee te slepen. Heroverweging en stapsgewijs herbouwen en implementeren lijkt een betere gang van zaken dan iedere update en maatwerk opnieuw te moeten aanbrengen. In feite spreken we hier van een “best-of-breed” strategie en een SOA infrastructuur.

Bij deze aanpak is het uitgangspunt dat voor elke gewenste functionaliteit de oplossing uit de markt wordt geselecteerd (of in maatwerk wordt gerealiseerd) die het best past bij de functionele vraag. Tegelijkertijd wordt gewerkt aan voorzieningen om de gekozen oplossingen te integreren: een Enterprise Servicebus.

Last but not least: Het is erg belangrijk dat het te selecteren ERP mogelijkheden in zich heeft om te koppelen via bijvoorbeeld Web services. Rest API’s JMS etc.

Veel succes met uw selectietraject !