6 beruchte valkuilen in ICT-debacle Pluripharm

De Volkskrant publiceerde 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. We herkennen in het artikel zes beruchte ICT valkuilen.

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. In dit artikel komen zes beruchte valkuilen naar voren.

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 valkuil 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 het magazijn en vervolgens de orderverwerking. Zeker met moderne integratietools is het koppelen van systemen prima te doen.

2. 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.

3. 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.

4. 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 valkuil. 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.

5. 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 heeft veelal een sterke voorkeur van de ICT-afdeling.

6. Onduidelijke verantwoordelijkheden

Wie is er nou verantwoordelijk voor dit debacle? Volgens Jansen wijst iedereen naar elkaar en is het juridisch lastig om de ICT-leverancier erop aan te spreken. Ondanks dat beide partijen een succesvol project nastreven, zijn de belangen tegengesteld. De klant wenst een zo goed mogelijke ondersteuning tegen de laagste prijs, terwijl de leverancier zo min mogelijk tijd wil besteden aan 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 dit soort ‘fuck-ups’.