Miljoenenstrop LeasePlan na stop SAP-implementatie

LeasePlan trekt een stekker uit de internationale uitrol van een Core Leasing System. Het mislukte it-project kostte de Nederlandse autoleasemaatschappij al 92 miljoen euro. Dat blijkt uit de kwartaalcijfers van het bedrijf. Volgens het Financieele Dagblad (FD) gaat het om SAP-software.

Uit de cijfers van het tweede kwartaal blijkt dat de nettowinst uitkomt op 32 miljoen euro. Dat is een flinke daling ten opzichte van hetzelfde kwartaal in 2018. Toen bedroeg de winst 152 miljoen euro. De kostendaling schrijft de organisatie toe aan het stopzetten van de ontwikkeling van een zogeheten core leasing-systeem. Dit kostte de organisatie tot nu toe bijna een miljard euro.

Algemeen directeur Tex Gunning vertelt dat LeasePlan naar een bedrijfsmodel toewerkt dat volledig digitaal is. ‘We willen digitale diensten leveren tegen digitale kostenniveaus en waarde uit onze data halen via kunstmatige intelligentie. Hier is een flexibele en schaalbare it-architectuur voor nodig en de traditionele it-architecturen voldoen niet aan onze deze wensen.’ Volgens hem zijn de gewenste productverbeteringen technologisch niet snel genoeg door te voeren.

De ceo heeft daarom de strategische beslissing genomen om de ontwikkeling van hun core leasing-systeem stop te zetten, dat volgens het FD is gebouwd op basis van SAP-software. ‘De organisatie begon eind vorig jaar te twijfelen aan de it-infrastrucuur op basis van SAP’, schrijft de krant. In maart schreef LeasePlan nog druk bezig te zijn met de uitrol van SAP en dat dit vertraagd is omdat de verwachte voordelen (vooral op gebied van efficiëntie) lager uitvallen of helemaal wegvallen.

Digitale architectuur

LeasePlan gaat nu over op een ‘next generation digital architecture’. ‘Hoewel dit beluit dit kwartaal leidt tot minder winst, stelt deze architectuur ons in de toekomst in staat een ​​nieuwe reeks slimme vlootproducten en -diensten aan onze klanten aan te bieden. Dit moet efficiëntievoordelen opleveren’, aldus Gunning.

De nieuwe architectuur bestaat ​​uit verschillende modules, bijvoorbeeld voor voorspellend onderhoud, verzekeringsclaims, contractbeheer. Dit wordt gebouwd op basis van bestaande LeasePlan-producten en componenten van derden. Gunning: ‘Alle modules worden schaalbaar ontworpen zodat we tegen lagere kosten meer auto's aan onze platformen kunnen toevoegen, productimplementaties en updates kunnen toepassen en via api’s kunnen integreren met systemen van derden.’

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

Poeh! Da's een fikse strategische misser. Daar gaan koppen rollen...

Forse afschrijving in dit stadium. Riskante nieuwe strategie ook.

't Is wat met die SAP-implementaties...
https://www.computable.nl/artikel/nieuws/erp/6464719/250449/lidl-neemt-verlies-van-half-miljard-op-sap-project.html

@Robert: Het is een nogal prijzig falen van SAP! Ik zou me wel tien keer bedenken voor ik als organisatie nog met SAP voor een groot project in zee ging. Maar ach, de overheid heeft er ook een handje van het ene mega-project na het andere te laten mislukken met andere softwarehuizen. Ik vraag me soms wel eens af of we niet aan het einde van de 'rek' van de IT zijn gekomen. Worden de projecten zo veelomvattend, zo mega-complex, dat het gewoon niet meer te implementeren valt?
Al vraag ik me wel af hoe je duizenden mensen aan het werk kan houden met het ombouwen van retailprijzen naar inkoopprijzen... Maar daarvoor zal mijn kennis van de materie wel simpelweg tekortschieten...

@Robert van Weersch | 15 augustus 2019 14:05
Dergelijke fundamentele modificaties van SAP zijn zonder uitzondering een heel erg slecht idee. Elke CIO zou dat inmiddels moeten weten. Een dergelijke eigenwijze "wir-schaffen-das" houding wordt dan ook genadeloos afgestraft in de IT praktijk.

Misschien moet ook hier de vraag gesteld worden of het wel een puur it-probleem is?

Ik snap niet helemaal waarom je voor een boekhoudkundig pakket SAP zou nemen.
SAP is toch meer voor fabrieken?
Je verhuurt auto's en krijgt ze na een tijdje weer terug en moet ze dan verkopen.
En een portaal om het te regelen.
Belastingregelingen per land.zal nog verschillen.
Voor dit soort bedragen kan je beter iets anders als uitgangspunt nemen. Want bij SAP betaal je ook nog elk jaar een fors bedrag aan licenties.

@R.J.Tuynman: uw vraag : einde van de rek in IT, is terecht. Niet dat de experts van bv. SAP dommer geworden zijn, maar voor veel gebruikers zijn de grenzen al overschreden. Door de complexiteit, ook door het gebrek aan inzicht , waardoor gebruikers foute dingen gaan doen, en AI kan niet alles opvangen, maar ook onlogische verwachtingen krijgen door de nieuwe buzz-words. Johan Kruyff wist het al voor de IT revolutie: je ziet maar dat wat je door hebt. En juist dit 'doorhebben' wordt blijkbaar steeds moeilijker.

Da's duur leergeld. Hoop wel dat ze door hebben dat die nieuwe manier van werken nog meer afhankelijk is van het ingezette personeel. Als je een blik kneusjes open trekt dan zal het net zo eindigen als bij de SAP implementatie.

@Jos: “Je gaat het pas zien, als je het door hebt” zei ene Johan Cruijff. Wat ik probeerde aan te geven was dat die rek er vooral in de complexiteit en performance van nieuwe en vooral de grote systemen, uit is.
Doordat systemen alsmaar verder aan elkaar gekoppeld worden, ieder met een flinke portie eigen legacy, ontstaan er megaconstructies die al een soort 'torentje-torentje-bussekruit' op elkaar en aan elkaar geknoopt worden. Daarbij moeten die systemen dan ook nog eens zwaar bevraagd kunnen worden door vele honderden gebruikers tegelijk, met query's die over verschillende servers en databases lopen. Die rek is er denk ik wel uit en dat manifesteert zich in overheidsprojecten en megaprojecten bij multi-nationals omdat die de grootste gebruikersgroepen en de meest complexe infrastructuren kennen.

"LeasePlan kondigt nu aan zelf een softwaresysteem te zullen ontwikkelen dat uit verschillende onderdelen bestaat. De topman verwacht dat de bouw drie tot vijf jaar in beslag zal nemen. 'We bouwen het zelf, waarbij we de modules deels elders inkopen', zegt Gunning."

Dit lijkt me de juiste strategie, passend bij deze tijd. Door één grote oplossing op te delen in kleinere delen:
- Spreid je risico
- Ontwikkel je sneller en kun je sneller testen bij de doelgroep
- Heb je eenvoudiger onderhoud (sommige onderdelen moet je misschien vaker aanpassingen in doen dan andere)
- Geen vendor lock-in
- Ben je toekomstbestendig doordat je veel makkelijker nieuwe technieken kan toepassen
- Heb je flexibeler release-management
- Kan je eenvoudiger werk verdelen en parallel ontwikkelen

Zo kan ik nog wel even doorgaan. Tuurlijk zijn er ook nadelen te noemen en is SAP een grote naam wat veel vertrouwen uitstraalt, maar hoe groter en complexer de software is, des te meer heb je aan een decentraal landschap.

Het wordt eens tijd dat men developers en IT architecten eens meenemen in dit soort strategische beslissingen.

@Sven Haveman: inderdaad: dit soort strategische beslissingen wordt vaak tijdens en na copieuze diners genomen door managers die vaak meer verstand van de geserveerde wijn hebben dan van de servers in kwestie... :-)
Ik roep wel eens wanhopig dat al die op onkunde en onwetendheid gestoelde strategische IT-beslissingen wel leuk bedacht zijn, maar dat het MIJN telefoon is die als eerste is overgaat als de zaak in het honderd loopt...
Het blijft een spanningsveld tussen management en werkvloer...

@Sven Haveman
Ik denk dat je de zaak enigzins onderschat. SAP systemen hebben een evolutie van bijna 50 jaar achter de rug. Dagelijks wordt er nieuwe code ontworpen door de 20.000 man in Waldorf en tienduizenden anderen in de USA en India. De business processen die in de code en customizing versleuteld zijn, zijn tot stand gekomen na jarenlange analyse van de best-practices in elk soort industrietype.

Om te denken dat je dergelijke systemen met een team binnen 3-5 jaar zelf kan bouwen is uiteraard complete waanzin. De complixiteit blijft hetzelfde of je nu centraal of decentraal werkt. Bij een decentraal systeem komt het accent alleen veel meer op integratie te leggen. Ook de inspanningen voor softwaredistributie (dev-test-prod) en -versioning binnen zo'n project plus de afhankelijkheden tussen de verschillende decentrale componenten is veel te complex voor een dergelijk project.

@KJ: Ik denk dat je niet treffender mijn stelling had kunnen onderschrijven dat de IT uit zijn krachten aan het groeien is qua complexiteit en dataomvang...
Bijna 100.000 man die SAP aan het coderen zijn, verdeeld over de VS, Duitsland en India dat valt toch niet meer te coördineren, zeker niet als India om de hoek komt kijken: goedkope codekloppers met een gebrekkige kennis van het Engels, communiceer daar maar eens mee...

@R.J. TUIJNMAN | 22 AUGUSTUS 2019 09:55
Ik werk al zo'n 20 jaar met SAP als freelancer en weet wat de kracht en zwakheden zijn van deze software. SAP is qua grootte het 3e software bedrijf in de wereld (na Microsoft en Oracle). SAP heeft honderden software produkten in de portfolio en niet uitsluitend ERP. Vooralsnog slagen zij er uitstekend in om hun marktpositie te handhaven zonder al teveel consessies te doen aan kwaliteit.

Je kan het allemaal enorm complex vinden, maar het idee dat je een multinational kan runnen op wat Python scriptjes en no-SQL DB's is op z'n minst ronduit naief te noemen.

@KJ Ik denk ook niet dat de bedoeling is om een tweede SAP te maken.
Volgens mij is het de bedoeling om een oplossing te maken voor Leaseplan.
Het nadeel van een SAP systeem is dat er vaak heel veel extra's bij zit waar je wel iets mee moet doen terwijl je dat niet gebruikt.

Vooral de laatste 10 jaar zijn er veel losse oplossingen gekomen die je kan integreren in je eigen oplossing zonder de erfenis van 50 jaar ontwikkeling mee te nemen (SAP). Ik weet niet precies wat de jaarlijkse licentie kosten zullen zijn voor SAP bij Leaseplan maar mogelijk kan je daar een groot ontwikkelteam voor in dienst nemen.

@ Corne Smiesing | 22 augustus 2019 10:10
SAP maakt veel emoties los bij mensen omdat er vaak enorme bedragen geassocieerd zijn met de aanschaf, onderhoud en licenties van deze software. Ik kan mij dan ook niet helemaal onttrekken aan de indruk dat LeasePlan een emotionele beslissing heeft genomen om voor zelfbouw te kiezen, wellicht door frustratie en gebrek aan voortgang binnen hun SAP project.

Uiteraard besef ik dat het nieuwe systeem een maatwerk produkt voor specifiek Leaseplan moet gaan worden. Maar voor een globale organisatie als LeasePlan zijn ook daar behoorlijke risico's aan gekoppeld. Wat je bij SAP out of the box hebt, zal nu in een deeloplossing al aanwezig moeten zijn of expliciet geprogrammeerd moeten worden.

Voor de hand ligt het dat LeasePlan voor een combinatie van betaalbare best-of-breed deeloplossingen gaat, bijvoorbeeld een combinatie van Fleet-management, ERP, HR en CRM. Dan komt het accent op integratie te liggen. Verdere cruciale punten zijn: GoLive, onderhoud, capaciteit en scalability.

@KJ: Het was geen aanval op SAP specifiek of zo, hoor, het is mijn indruk van veel megaprojecten die falen - ongeacht of SAP daar bij betrokken is of niet - waarbij de complexiteit en omvang dermate uit hun krachten zijn gegroeid dat het gewoon niet meer door normale stervelingen te behappen valt.
Waar je het idee vandaan haalt dat ik multinationals met Python en SQL-scriptjes zou willen voorzien is mij een raadsel, dat stel ik namelijk nergens. Python is ook helemaal mijn taal (nog) niet en ik ben me nadrukkelijk bewust van mijn beperkingen in kennis van projecten van deze omvang. Maar als ik lees dat er bijna 100.000 mensen druk aan het ontwikkelen zijn aan SAP en zijn projecten, features en mogelijkheden, dan gaat dat mijn bevattingsvermogen absoluut te boven hoe dat fatsoenlijk 'gemanaged' kan worden...

Bij SAP werkten in 2018 minder dan 100.000 mensen, en aangezien er ook nog management, HR, sales, etc. moet zijn, denk ik niet dat dus al die (bijna) 100.000 mensen aan het programmeren zijn :)

@Robert van Weersch: Ik ging uit van de informatie die me hierboven verstrekt werd: 20.000 werknemers in Duitsland, tienduizenden in de VS en India... Als ik lieg, dan is het in commissie... ;-)

Er staat niet hoeveel tienduizenden.
20.000 in DE, 10.000 in US en 10.000 in IN voldoet ook aan "tienduizenden".

Prima Robert, wat jij wil... Meer dan honderd programmeurs aansturen is overigens in mijn optiek al een heidens karwei...

@R.J. Tuijnman | 22 augustus 2019 11:29
Sorry dat ik wat bot overkwam. Uiteraard begrijp ik het verlangen naar simpeler en meer transparantere oplossingen. Echter in deze markt (grote internationale bedrijven) is complexiteit nu eenmaal een gegeven.

SAP's software management capaciteit is inderdaad enorm en de product portfolio is gigantisch. Van mensen die daar wel eens in de keuken hebben gekeken, hoorde ik ooit dat er developers bestaan die gespecialiseerd zijn op een piepklein stukje van het ERP product, en hun verdere leven weinig anders doen. Dat moet welhaast een Kafka-achtige organisatie zijn, zou je denken.

Maar wie het produkt van dichtbij kent en met mensen uit Waldorf heeft gewerkt, weet ook, dat het geen lichtgewicht consultants zijn. Het is een oerdegelijk Duits product en bedrijf dat tegelijkertijd heel wendbaar en flexibel is.

@KJ: No hard feelings: ik begrijp dat als je veel met SAP werkt dat het frustrerend is hier de goegemeente los te zien gaan op SAP.
Dat complexiteit een gegeven is, dat stel ik feitelijk ook, alleen wel met de toevoeging dat het inmiddels haast niet meer te behappen is voor mensen die minder dan een autistisch genie zijn...;-) De mislukkende projecten bij de overheid en nu dan ook bij Lidl en Leaseplan zijn daar de exponenten van...

Weer even terug naar de kern van de zaak.
Waarbij ik nog even het verschil benadruk tussen 'gecompliceerd' en 'complex'.

Iemand heeft de keuze gemaakt voor SAP als oplossing. Vraag is wie.
Vraag is ook of betreffende besluitvormer zélf voldoende inhoudelijke kennis heeft/had om deze keuze valide te maken, cq. hiertoe voldoende deskundig advies heeft gehad.

Vervolgvraag is of betreffende besluitvormer de kennis en capaciteiten heeft/had om de Opdrachtgevers-rol naar behoren te kunnen invullen. Het onderscheid tussen 'gecompliceerd' en 'complex' is hier cruciaal.

Het besluit om het project te heroverwegen en vervolgens stop te zetten getuigt vooralsnog van lef en kunde.

Uw reactie

LET OP: U bent niet ingelogd. U kunt als gast reageren maar dan wordt uw reactie pas zichtbaar na goedkeuring door de redactie. Om uw reactie direct geplaatst te krijgen moet u eerst rechtsboven inloggen of u registreren

Vul uw naam in
Vult u een geldig e-mailadres in
Vult u een reactie in
Jaarbeurs b.v. gaat zorgvuldig en veilig om met uw persoonsgegevens. Meer informatie over hoe we omgaan met je data lees je in het privacybeleid
Als u een reactie wilt plaatsen moet u akkoord gaan met de voorwaarden
Vacatures Smart Logistics

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
article 2019-08-15T11:24:00.000Z Suzanne Martens
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.