Amefa, een internationale groothandel in bestek, zoekt bedrijven die slachtoffer zijn geworden van een erp-implementatie. Het bedrijf voerde zelf een erp-systeem in dat vele malen duurder uitviel dan begroot en waarvan de oplevering langer duurde dan gepland. De Apeldoornse groothandel wil in contact komen met lotgenoten. Naast uitwisseling van informatie en ervaringen wordt mogelijk gezamenlijk actie ondernomen tegen leveranciers.
De oproep vindt plaats via een advertentie in Computable en het Financieele Dagblad. Financieel directeur Barend Quant licht toe: 'Het lijkt kenmerkend voor de erp-branche dat keer op keer niet wordt nagekomen wat is beloofd. Wij hebben het gevoel dat een erp-implementatie standaard drie keer langer duurt dan gepland en vijf keer meer kost dan begroot.'
Amefa ('Apeldoornse messenfabriek') hoopt door te raden te gaan bij andere gedupeerden, meer informatie in te winnen over de aanpak van de problemen met de implementatiepartner en de leverancier.
Het bedrijf hoopt gezamenlijk sterker te staan. Quant: 'Het is moeilijk om stelling te nemen tegen bedrijven als Atos Origin en IFS. Bovendien zit je tussen twee partijen in die constant naar elkaar wijzen.'
Rechtzaak tegen Atos Origin
Het bedrijf heeft al juridische stappen gezet tegen Atos Origin. Er lopen gerechtelijke procedures tegen de dienstverlener die de erp-implementatie bij Amefa begeleidde.
Amefa koos in 2006 voor de invoering van een erp-systeem van de Zweedse leverancier IFS. Die implementatie liep volgens het bedrijf problematisch.
Computable beschreef de aanloop naar de selectie van dat erp-pakket in 2006. In komende artikelen willen we aandacht besteden aan wat er misging tijdens de erp-implementatie bij Amefa.
Ben benieuwd wie er gaan reageren op de oproep. En nog benieuwder ben ik naar de grootste gemene deler- ik vrees dat een ERP implementatie in een groot aantal gevallen wordt beschouwd en aangepakt als IT project terwijl het dat uitdrukkelijk niet is. Als in een dergelijke implementatie de ‘business’ niet in de lead is en sterk stuurt is de kans op falen groot. Uiteraard ken ik de achtergrond niet van dit project maar het zou zo maar kunnen dat er ook een hand in eigen boezem zou moeten verdwijnen…
Ik ben ook zeer benieuwd naar de reacties. Weinigen staan te dringen om falende projecten te etaleren, en dat is logisch. Hugo heeft zeker een punt, als het gaat om IT-project benadering van ERP projecten. Al ben ik zelf van mening dat er nauwelijks meer pure IT projecten bestaan, succes van alle projecten moet worden afgedwongen in samenwerking met de business. Een grote leverancier riep ooit, dat falende ERP projecten de schuld zijn van de klant zelf. Dat is veel te kort door de bocht en niet waar. Maar business betrokkenheid is wel een issue. Zeker ERP projecten zijn complex, en het is niet eenvoudig om als business owner je opdrachtgeversrol zoveel inhoud te kunnen geven dat de uitkomsten van het project je echt gaan helpen. Die betrokkenheid begint ver voor de start, maar gaat ook tijdnes het project vol gas door. Onze job als professionals is om daar de handvatten voor te creëren, en aan bedrijven duidelijk te maken hoe ze hun rol kunnen invullen om het succes af te dwingen. Het kan, als 50% van de projecten niet succesvol zijn (grootste gemene deler uit een paar onderzoeken die ik gezien heb) dan is 50% het wel. Daar hoor je niet vanzelf bij, maar het is ook niet onbereikbaar.
Altijd weer boeiend te zien hoe met precies dezelfde technologie bedrijf A een fantastische ROI weet te halen en bedrijf B bijna de afgrond in lazert.
Het geheime recept: sturing voldoende hoog in de organisatie leggen zodat alle typen besluiten en aanpassingen kunnen worden doorgevoerd; zowel qua organisatie, proces als techniek.
Google voor de aardigheid maar eens op SAP en dan defenie en dan Proctor en gamble.
Jaja totaal onvergelijkbaar en appels met peren zal de azijnpisser dan zeggen. Ik zeg dan: verglijkbare omvang en complexiteit. Grote verschil: sturing, invloeden en politiek. Kortom Polderen Vs beslissen. Sturen vs. compromissen sluiten. etc
Ja Atos Origin Weten mensen nog steeds niet dat dat een grote bak middelmatige consultants is?
Als bedrijf moet je doen aan cherry-picking. Van meerdere leveranciers de beste consultants (10 jaar+ ervaring) en daarbovenop een top projectmanager met resultaatverplichting.
Off-topic
@ Harry;
Jij zit zeker thuis werkloos te wezen?
—-
On-topic
Ik vind het een goede ontwikkeling. Laat maar eens wat transparantie komen bij dergelijke implementaties. Mijn beeldvorming zegt, dat er nog aardig wat reacties kan komen uit het MKB op deze oproep.
Mocht dit ooit een succes worden, dan zal het waarschijnlijk ook wel opgezet worden voor andere (mislukte) concepten/implementaties zoals SOA..
De automatiseerder voert de implementatie uit in opdracht van de klant. Bij de complexere projecten, zoals een ERP implementatie komen er eerst een hele batterij consultants langs om te kijken en af te stemmen hoe en wat.
Hoe kun je dan achteraf nog de klant de schuld geven? Dan hebben de consultants er toch gewoon een zootje van gemaakt, of niet dan???
Daarnaast geloof ik niet dat sturing van bovenaf de critische factor is. Draagvlak en ondersteuning is nodig, maar ik heb pakketten naar binnen gekruid zien worden, van bovenaf gestuurd en opgelegd, waar we op de werkvloer meer last dan profijt van hadden.
Oorzaak: de consultants hadden hoog in de organisatie met mensen gepraat, die dachten te weten hoe wij werkten…
Een standaard pakket gaat uit van gelijke aanpak binnen verschillende organisaties. Men gaat er van uit (en verkoopt dit ook zo) dat het pakket de ideale (standaard) oplossing biedt. Echter, geen enkele organisatie is gelijk aan de standaard. En wat niet gelijk is aan de standaard kun je niet op voorhand met die standaard bedienen. Wil je dat wel dan geldt in de meeste gevallen dat de organisatie meer aangepast moet worden aan de standaard dan dat de standaard aangepast moet (of kan) worden aan de organisatie. Wie daar onvoldoende op anticipeert, gaat al gauw de mist in. Dit wordt versterkt, zoals PaVaKe terecht opmerkt, als het management denkt te weten hoe de uitvoerende processen lopen en er door “ervaren” consultants uitsluitend op hoog niveau met de organisatie wordt afgestemd.
Overigens geldt voor alle verandertrajecten: Zet in vredesnaam eerst de processen op de kaart. Als je weet hoe je werkt, weet je waar, wat, hoe, in welke mate, met behulp van wie en waarom je moet veranderen.
Er wordt altijd gesproken over de kwaliteit van de consultants en de projectleiding. Ik zou ook even kijken naar de kwaliteit van de medewerkers in het project en de bijdrage van het (hoger) management. Polderen in een ERP implementatie in deze tijd is pokeren met geld van de aandeelhouder.
Vervolgens is de zwakste schakel bepalend in een hele lange ketting. Een stuk transparantie is niet slecht voor de industrie. Maar dan objectieve transparantie dus een actieve rol voor journalisten en geen overschrijf acties.
Off-topic
@ Badgast
Nee ik ben na 18 jaar SAP ervaring iets anders gaan doen!
Ben zelf jaren werkzaam geweest in de ERP business en ook betrokken bij projecten waar partijen als Atos bij betrokken waren. Het probleem vind ik is meestal niet het ERP pakket. Atos in deze wil graag consultants leveren dat is hun vak, echter deze consultants hebben geen baat bij een vlotte en snelle implementatie want dan kunnen ze minder uren schrijven. Daarnaast missen ze vaak de kennis van de specifieke pakketten en ja dan heb je al een belangrijk deel van het probleem. Daarnaast is in deze ook Amefa zelf beetje schuldig om via Atos, IFS erp aan te schaffen, wie heeft de beslissing genomen binnen Amefa om dit via Atos te doen en waarop niet rechtstreeks? Als een opdrachtgever nu eerst eens gaat nadenken wat de kern activiteiten van bv. Atos zijn, consultancy leveren, men noemt dat kennis, ik noem dat nu even uurtje factuurtje.
Heeft de opdrachtgever ook bedacht wat voor Atos de win is als de implementatie goed en snel zou zijn verlopen? Dus de schuld ligt niet bij IFS de leverancier van het pakket maar bij Amefa die kiest voor aankoop via Atos en bij Atos die graag maximaal aantal uren willen factureren.
Ik besef dat dit hard klinkt maar ben realistisch het is in elk project zichtbaar.