ERP Systemen de aanpak

ERP Systemen de aanpak

Afbeeldingsresultaat voor erp

Er is een ERP-systeem geïmplementeerd. Alles kon, alles werd beter. U hebt echter het gevoel dat er vooral energie zit in het aanpassen van de processen en de dagelijkse gang van zaken. Inmiddels werkt iedereen probleemloos met het systeem. Maar zijn er verbeteringen? Is het onderste uit de kan gehaald?

Geld is belangrijk. Bij het implementeren van een ERP-systeem wordt daarom bijzonder veel aandacht besteed aan de financiële implementatie. Voor de logistiek is minder oog. Wie heeft er tijdens een ERP-implementatie tijd voor het bepalen van optimale voorspelmethoden, bestelmethodieken en voorraadsturingen?

Het is ook niet eenvoudig om initiële keuzes te maken. Neem SAP, alleen de voorraadbesturing per artikel kent al acht basismogelijkheden met nog eens achttien opties.

 

 

Logistiek in ERP ook klaar voor optimalisatie?

Voor veel bedrijven staat de basis van het ERP-systeem. Nu is het tijd om eens kritisch naar de logistieke implementatie te kijken binnen het ERP-systeem. Veel bedrijven halen niet het onderste uit de kan. Dit beeld wordt bevestigd door recent onderzoek van IPL (zie artikel logistiek.nl: Bedrijven zoeken oorzaak ERP-problemen bij zichzelf). Hieruit blijkt dat de basismodules naar tevredenheid zijn geïmplementeerd, maar dat er nog weinig verbetering is gevonden op het logistieke vlak.

 

Kennislacune binnen de organisatie

MRP, lot sizes, ATP, consumption posting, safety stock, forecasting: heeft u iemand die het snapt? Helaas is in de eigen organisatie niet altijd voldoende kennis aanwezig om verbeterpotentieel binnen het ERP-systeem te realiseren. De logistiek manager weet op hoofdlijnen hoe het systeem werkt, maar kent niet de details. De supply chain planner kent de knoppen, maar is te weinig bekend met de mogelijkheden.

 

De kennislacune binnen de organisatie zorgt voor een hoge mate van afhankelijkheid van de ERP-leveranciers. Maar is dat in alle gevallen de juiste partner?

‘Dining hall’ vertaald… (Bron: Facebook, Samuel Osouf)

Businessperspectief ‘lost in translation’ bij IT

Hoewel de ERP-leverancier alle mogelijkheden kent van een systeem is niet altijd gegarandeerd dat ze de business snappen. Er zit een gat tussen kennis van de business, die u als geen ander heeft, en kennis van het systeem, het specialisme van de ERP-leverancier.

 

U hebt vast eens een vraag gesteld die door uw ERP-leverancier compleet anders is geïnterpreteerd dan bedoeld. De ERP-leverancier doet wat u vraagt, niet wat u denkt dat u vraagt. Uw business perspectief is ‘lost in translation’.
Drie rollen

De ervaring leert dat klant en ERP-leverancier elkaar niet altijd goed begrijpen. Er is een duidelijke rol weggelegd voor de partij die het gat tussen leverancier en business expert kan overbruggen: een ERP-kenner met een business perspectief.

 

Ieder succesvol implementatie & optimalisatie projectteam moet evenwichtige verdeling van drie rollen kennen:

  • De business expert
  • De ERP-expert
  • De ERP-kenner met een business perspectief

 

Business expert

De rol van business expert is bij uitstek weggelegd voor de klant. De klant kent haar processen als geen ander. Het is dan ook belangrijk dat deze rol wordt ingevuld door key-users met vooral veel proces / business kennis. IT kennis is een pré maar niet voorwaardelijk.

 

ERP-expert

De rol van ERP-expert vergt specialistische kennis van het te implementeren of te optimaliseren systeem. Deze rol wordt daardoor vaak door de leverancier of een aanverwant consultancybureau ingevuld.

 

ERP-kenner met een business perspectief
De functie van de derde rol, de ERP-kenner met een business perspectief, is het voortdurend in het oog houden van de business belangen en behoeften tegenover realistische oplossingsrichtingen met betrekking tot het ERP-systeem. Dat de invulling van deze rol moeizaam verloopt, blijkt uit de beschreven praktijkvoorbeelden. Wel krijgen business consultants die zich bezig houden met operations in hun dagelijkse praktijk veel te maken met ERP-systemen. De kennis die hiermee wordt opgedaan wordt steeds beter ingezet.

 

Ook universiteiten herkennen het belang van de derde rol. Een student technische bedrijfskunde krijgt tegenwoordig een vak programmeren en kan databases ontwerpen. Ook worden vakken gegeven waar kennis wordt gemaakt met ERP systemen.

 

Tips & Tricks

Een aantal tips ten aanzien van het afstemmen van business belangen / behoeften en ERP-oplossingsrichtingen:

 

  • Selecteer vooral key-users met proceskennis. IT kennis is een pré maar geen vereiste.
  • Laat kennis over eventuele oplossingen je nog niet beperken in het stadium
    van functionele specificatie. Specificeer functionele requirements vanuit de business.
  • Concentreer je bij de functionele specificatie op de huidige processen. Het introduceren van nieuwe processen bij het invoeren van een ERP-systeem vergroot de complexiteit van de implementatie drastisch.
  • Bezoek klanten of leveranciers met eenzelfde ERP-systeem en kijk hoe zij het geïmplementeerd hebben of hoe zij met een bepaald probleem omgaan.
  • Denk als business owner mee over modelkeuzes voor voorraadsturing, forecasts etc. Vanuit het systeem gezien lijkt dit een technische aangelegenheid, het heeft echter directe invloed op de dagelijkse gang van zaken. Zorg dat deze effecten duidelijk zijn.
  • Reserveer genoeg tijd na de go-live voor het optimaliseren van instellingen. Blijf niet jaren aanmodderen met beperkingen.

e Volkskrant bracht een interview met Jan Dirk Jansen, directeur van farmaceutische groothandel Pluripharm. Een mislukte ERP implementatie was er de oorzaak van dat duizenden bestellingen niet geleverd konden worden. Jeroen van den Berg – initiatiefnemer van online softwarevergelijker wms-software.eu – herkende in het artikel zes beruchte ICT ‘fuck-ups’.

Het opmerkelijke bericht in de Volkskrant heeft het over foutjes in de software-instellingen. Kleine foutjes hebben grote gevolgen in een magazijn met tienduizenden bewegingen per dag. Zelf ken ik de case van Pluripharm niet, maar het is goed dat men er open over communiceert. Het laat de enorme gevolgen van een verkeerde ICT-implementatie zien. Het heeft niet alleen impact op het bedrijf en haar klanten, maar het raakt de gehele sector. Ik zie zes beruchte ‘fuck-ups’ in dit verhaal naar voren komen.

  1. BIG BANG

Directeur Jansen stelt dat er geen andere keuze was dan een volledig nieuw ERP-softwaresysteem voor de gehele stroom van goederen en geld. Alle systemen in één big bang vervangen, is echter een beruchte ICT ‘fuck-up’ die ontegenzeggelijk risico’s met zich meebrengt. Ondanks dat men naar eigen zeggen uitvoerig getest had, bleken er toch fouten in de software te zitten. Verstandiger is om software stapsgewijs te vervangen, bijvoorbeeld eerst de orderverwerking en vervolgens het magazijn. Zeker met moderne integratietools is het koppelen van deelsystemen prima te doen.

  1. TRADITIONELE SOFTWARE

Volgens Jansen koos Pluripharm voor het gerenommeerde JD Edwards van Oracle. Traditionele software biedt uitgebreide functies door de jarenlange softwareontwikkeling. Bovendien zijn er veel klinkende namen die de software gebruiken. We zien echter een nieuwe generatie van moderne software opkomen, veelal in de cloud. Deze pakketten zijn vooralsnog minder uitgebreid en kunnen niet bogen op ellenlange referentielijsten, maar ze zijn wel flexibeler aan te passen aan de wensen van bedrijven. Dit maakt het niet alleen eenvoudiger om de software te implementeren, maar ook om het in de toekomst te blijven aanpassen aan nieuwe wensen.

  1. LANGE DOORLOOPTIJD

De implementatie bij Pluripharm heeft twee jaar geduurd. Dat is veel te lang. Het is onmogelijk om zo lang gefocust aan een project te werken. Het geheel is niet meer te overzien en de gezonde spanning verdwijnt. Bovendien zijn de uitgangspunten die aan het begin van het project golden, tegen het eind alweer achterhaald. Projecten zouden niet langer dan een jaar mogen duren, liefst een halfjaar, met een duidelijke kop en staart. Dat dwingt mensen om te focussen op de essentie en snel beslissingen te nemen. Alles wat niet binnen de scope past, komt in een vervolgproject aan bod of is wellicht toch niet zo belangrijk als gedacht.

  1. MAATWERK

Volgens Jansen is het ERP in samenwerking met ICT-experts aangepast aan het bedrijf. Als bedrijven een werkwijze willen die het softwarepakket niet ondersteunt, dan kan het aangepast worden via maatwerk dat erbij geprogrammeerd wordt. Ook dit is een beruchte ICT ‘fuck-up’. Maatwerk is risicovol, kostbaar, zorgt voor vertraging en maakt het lastig om het pakket in de toekomst nog aan te passen. Het heeft de voorkeur om software zonder maatwerk in te voeren. Pakketten bieden diverse standaardwerkwijzen. Door deze slim te combineren of door de huidige bedrijfsprocessen iets aan te passen is vaak meer mogelijk dan men vooraf denkt. Dit vraagt echter wel wat creativiteit en niet te vergeten een gezonde portie change management. En als het echt niet lukt zonder maatwerk, dan heeft men mogelijk het verkeerde pakket gekozen.

  1. INTEGRAAL PAKKET

Zoals al eerder aangehaald, Pluripharm koos één integraal pakket voor alle bedrijfsprocessen. Het lijkt erop dat het pakket goed functioneerde; behalve in het magazijn. Magazijnen met relatief grote aantallen transacties die in real-time verwerkt moeten worden, hebben doorgaans andere karakteristieken dan de overige bedrijfsprocessen. Wellicht had een gespecialiseerd WMS hier beter gefunctioneerd, dan de magazijnmodule in het ERP. Het is verstandig om vooraf te overwegen of het integrale pakket alle bedrijfsprocessen moet ondersteunen, of dat je diverse ‘best-of-breed’ pakketten aan elkaar wilt koppelen. Het doel moet zijn een zo goed mogelijke bedrijfsvoering, niet het minimaliseren van het aantal pakketten. Dat laatste is vaak het stokpaardje van ICT-afdelingen.

  1. ONDUIDELIJKE VERANTWOORDELIJKHEDEN

Wie is er nou verantwoordelijk voor deze ‘fuck-up’? Volgens Jansen wijst iedereen naar elkaar en is het juridisch lastig om de ICT-leverancier erop aan te spreken. Ondanks dat beide partijen naar een succesvol project streven, zijn de belangen in dergelijke projecten tegengesteld. De klant wenst een zo goed mogelijke ondersteuning tegen de laagste prijs, terwijl de leverancier zo min mogelijk tijd wil besteden aan de onderdelen waarvoor een vaste prijs is afgegeven en zoveel mogelijk tijd aan onderdelen (lees: maatwerk) die uurtje-factuurtje mogen worden afgerekend. Het gevolg is dat de klant telkens met aanvullende eisen komt of door voortschrijdend inzicht eerdere keuzes herziet. Op deze manier komen projecten automatisch in een maatwerkspiraal. Het is de hoogste tijd, dat leveranciers hun verantwoordelijkheid nemen en binnen een vaste tijd en tegen vaste kosten een goed werkend systeem opleveren. Voorwaarde is dat de klant de bedrijfsvoering aanpast aan het pakket en zorgt voor snelle besluitvorming. Dat klinkt op het eerste gezicht misschien niet aanlokkelijk, maar het is wel de beste remedie tegen dergelijke ‘fuck-ups’.

https://www.nrc.nl/nieuws/2017/12/01/het-systeem-is-niet-beschikbaar-a1583436