Het mislukken van SAP-implementaties is vaak te wijten aan de klant zelf, constateert directeur SAP Nederland Angelique de Vries. SAP kwam verschillende keren negatief in het nieuws, onder meer door mislukte implementaties bij Free Record Shop en provincie Noord-Holland. De Vries beweert dat Free Record Shop heeft toegegeven zelf ook fouten gemaakt te hebben. Noord-Holland legt de verantwoordelijkheid volledig bij SAP en dienstverlener CTAC.
Volgens directeur Nederland van SAP Angelique de Vries realiseren bedrijven zich vaak niet voldoende wat het effect van een implementatie is op hun bedrijfsvoering. “Iedere implementatie van bijvoorbeeld een erp-systeem is ingrijpend voor de gebruikers. Dat geldt net zo goed voor ons als voor onze concurrenten. Als daaraan in de testfase onvoldoende aandacht wordt besteed, als bijvoorbeeld de key users te weinig betrokken worden, dan loop je het risico dat het misgaat.”
De Vries zegt dat Free Record Shop heeft toegegeven zelf fouten gemaakt te hebben. “De oplossingen zijn niet voldoende doorgetest.” Free Record Shop-ceo Hans Breukhoven heeft inderdaad tegen Computable gezegd dat zijn bedrijf zelf verantwoordelijk was voor de problemen rond de implementatie. De interne projectleider van de provincie Noord-Holland legt de verantwoordelijkheid echter volledig bij SAP zelf en CTAC, de dienstverlener die de implementatie begeleidde.
Monitoren
Om te voorkomen dat implementatietrajecten mislopen is SAP volgens De Vries vorig jaar gestart met het Quality Insurance Programma. “We hebben besloten om vaker de thermometer in projecten te stoppen. Door projecten continu in de gaten te houden worden eventuele problemen in de kiem gesmoord. We kijken samen met de partner steeds of de implementatie wel op de goede weg zit. En als dat niet het geval is, bedenken we hoe we kunnen helpen. Want we willen altijd graag nieuwe succesverhalen schrijven die we samen met onze partners in de markt kunnen laten horen. Het is wel waar dat je kunt leren van fouten, maar we leren liever van dingen die goed gaan.”
De Vries zegt dat “veel meer” projecten goed verlopen dan dat er mislukken. “We werken misschien wel aan duizend projecten per jaar en het overgrote deel daarvan gaat goed. Helaas is het zo dat negatief nieuws nu eenmaal meer aandacht krijgt dan positief. En dan is de kop makkelijker gemaakt dan de inhoud.”
Lees eens wat Leo Apotheker van SAP hierover zegt :
http://blogs.zdnet.com/BTL/?p=12267
“I don’t give a s**t if it’s Accenture or IBM. I care about the customer. I find it shocking people are walking around talking to customers and have no experience on [SAP]. [Consultants] get hired of people and have no clue. It’s annoying but that’s a fact.”
Het zijn dus niet de klanten, maar de mensen die zich voordoen als consultants.
Een belangrijk aspect wordt volgens mij in de discussie over het hoofd gezien: voortschrijdend inzicht. Het is, zeker in de huidige dynamische tijd, onmogelijk om van te voren te voorzien wat je op korte termijn allemaal wilt (als klant / opdrachtgever), laat staan over 1, 2 of 5 jaar. Slechts door het opdoen van ervaring in de praktijk, kom je steeds dichter bij wat je werkelijk wilt / nodig hebt. Maar de huidige (ERP) technologie vergt wel van je dat je aan het begin van het project al belangrijke keuzes maakt.
Daarnaast wordt vaak menselijke gedrag genegeerd, wordt bepaald menselijk gedrag aangenomen of wordt besloten hoe mensen zich behoren te gedragen. Om te slagen kun je je (systeem) beter aanpassen aan werkelijk menselijk gedrag, dat dus in de loop der tijd verandert, in plaats van mensen gedrag op te leggen. Tegen de menselijke natuur strijden kun je vergeten.
Wat je nodig hebt in deze omstandigheden is: Te allen tijde FLEXIBEL te zijn en blijven. De mogelijkheid hebben om:
? Elk ontwerp, algoritme, interface of tool
? Op eender welk moment voor, tijdens en na het project
? Voor zo laag mogelijke kosten
? Te kunnen wijzigen
Dit betekent in de praktijk dat je je systeem, snel, gemakkelijk, goedkoop en stapje voor stapje op je eigen tempo (geen big-bang), passend tussen en met je huidige systemen (niks weggooien wat al goed werkt), aan je proces en manier van werken kunt aanpassen, ook al staat die haaks op wat je al eerder in je systeem had ge?mplementeerd. Waarbij de klant zelf een groot gedeelte van het werk kan doen, zonder daarvoor over uitgebreide programmeerkennis te moeten beschikken of dure consultants te moeten inhuren. Zo blijf je ook in de (verre) toekomst zelfstandig met je systeem en hoef je niet periodiek een nieuw / ander systeem aan te schaffen of te updaten.
En je raadt het al: wij hebben die technologie in huis.
Jacco Hiemstra
http://www.produrion.nl
Natuurlijk hebben alle partijen schuld. SAP omdat ze zeggen dat hun product ‘alles’ kan en ze uiteraard niet gaan zeggen: “als je je organisatie en werkwijze maar aanpast”. De consultants, omdat ze al in de offertefase van een traject de directie niet voldoende ondersteunen met goede, onafhankelijke adviezen en vervolgens ook vaak te veel naar het technische implementatietraject kijken en te weinig naar de culturele – menselijke – organisatorische aspecten (die 75% van het succes bepalen).
De directie en de rest van de business omdat ze een hype achterna lopen (dan is het weer ERP, dan is het weer SOA, dan is het weer Vista, ….) en zich onvoldoende verdiepen in de consequenties van hun keuzes (waarin ze, zie boven, dan ook onvoldoende worden ondersteund door SAP en consultants). En omdat ze meestal niet in staat zijn om hun wensen en eisen in voldoende mate aan te geven. Ze vertrouwen op de consultants. Maar kennen die de bedrijfsprocessen?
Als je er pas bij het testen achterkomt dat de SAP implementatie niet helemaal voldoet aan de verwachtingen ben je wat mij betreft rijkelijk laat.
Logisch natuurlijk. De meeste bedrijven denken dat een SAP implementatie alles oplost. Echter wanneer de basis niet goed is zal SAP ook niet de oplossing bieden.
De verwachtingen zijn hierom dan te hoog en het is een belangrijke taak van SAP om deze verwachting te managen.
Sommige verwachtingen willen klanten helaas ook niet bijstellen en blijven dan liever geloven in dromen.
Suggestie voor veel bedrijven: er is nog veel te optimaliseren met je huidig aanwezige systemen, mensen andere aanwezige zaken. Siginificante omzetverhogingen cq kostenbesparingen zijn hierbij geen verrassing.
Bij http://www.brownpapercompany.nl weten ze daar alles van. Eerst je zaken voor elkaar maken intern en daarna is IT de bottleneck. De blauwdruk van wat je dan wilt optimaliseren ligt dan al klaar. Goed voor een start van een succesvolle SAP implementatie!
Wessel Berkman
http://www.brownpapercompany.nl
Goed, als enige dan maar een reactie niet ten faveure van SAP maar volledig tegen het bedrijfsleven.
Als u kennis heeft genomen van de constateringen van Gartner – in den Haag – en van (nb) Frank Buytendijk
van Hyperion/Oracle dan wordt alle inbreng van het bedrijf zelf gediskwalificeerd doordat het ontwerp van de software volledig wordt overgelaten aan software specialisten. Deze hebben echter een opleiding gehad in technisch systeemontwerp en niet in bedrijfsvoering. Dan onstaan er dus kortsluitingen zoals het niet aansluiten van verkochte aantallen bij opbrengsten; het gebruik van een machine-uurtarief waarbij het vaste kosten element helemaal wordt opgerold naar het eind van het jaar, waarna men blijf zitten met een negatieve of positieve restpost waaraan zelfs accountants kop nog staart zien; het niet controleren van de gebruikte bedragen op de facturen van parts leveranciers omdat de output daarvan is gesorteerd op crediteuren dus niet noodzakelijk op artikelniveau- een leverancier kan gewoon ongezien zijn prijs verhogen; het boeken van lopende projectkosten op een nieuw project omdat daar lekker veel ruimte op zit; totaal geen oog hebben op het verloop van kortingen: die zouden op zijn minst electronisch gescheiden moeten worden tussen tussen niet reguliere en toegestane kortingen door de omzet-tape nog eens af te draaien binnen een file die alleen de toegestane kortingen cumuleert; het tegenhouden van executives die toch maar zwichten voor een binnengedragen voorstel door het hoofd verkoop omdat er een spannend gesprek met commissarissen op de rol staat; het niet kunnen scheiden van interestresultaat en product mix op leningen, zowel aan de debet- als aan de creditzijde van de balans, door banken; een volslagen impasse op het front van delegatie van rapportages die ook op een lager niveau kunnen worden uitgevoerd door menesn die weten waarnaar ze kijken; het accepteren van ‘strategische’ plannen die als ze eerst voorgelegd zouden worden aan een extern marketing bureau volledig neergeknuppeld zouden worden ( en vergeet niet: het eerste verlies is altijd het goedkoopste)….. Ik hou er mee op. Lees Gartner’s Nigel Rayners commentaar over de (on)mogelijkheden van het delegeren (verkort weergegeven in Automatiserings Gids 23 jan 2009 en huiver). Eindconclusie: als het bedrijfsleven zo projecten uitgeeft aan automatiseerders dan moeten ze het ook maar weten.
Goeiedag zeg!
Boze reacties maar wel een kern van waarheid. Veel te vaak wordt er gesproken over IT projecten. Maar die BESTAAN NIET! Er moet altijd een goede zakelijke reden zijn voor een project. Een nieuw IT systeem is geen zakelijk reden, de vraag moet zijn: wat voegt het toe en wat hebben gebruikers nodig om waarde te kunnen toevoegen. Deze vragen kan je niet aan leveranciers overlaten; die hebben immers hun eigen belangen.
Helaas zit de wereld zo in elkaar (dat kan je ieder week in Computable lezen) dat de Business (inlc. gebruikers) IT graag aan IT overlaten, maar ook dat IT-ers zo arrogant zijn dat ze denken dat ze waarde toevoegen. Dat doen ze niet, gebruik van hun services voegt waarde toe, niet de service zelf.
De resultaten: een gat tussen IT en Business, ongeinteresserde gebruikers en een enorm gebrek aan kwaliteit.
Overigens levert de visie van PRINCE2 hier een oplossing: er zijn alleen Business projecten waarvoor de Business volledige verantwwordelijkheid neemt (Executive en Project Manager); de leverancier (IT) neemt alleen verantwoordelijkheid voor het resultaat van operationele werk (team manager, dus NIET het project management). Helaas wordt dit gezond verstand nauwelijks toegepast. Zowel klant als leverancier moeten eens de hand in eigen boezem steken!
De ervaring die SAP heeft opgedaan bij implementaties is vele malen groter dan een organisatie dat heeft. Je mag dus best van SAP – en elke andere implementatiepartner – een stuk begeleiding vragen in bv. de projectaanpak. Dit doet SAP overigens ook, en als je bereid bent naar elkaar te luisteren dan komt dit ook wel goed. Wees wel “verschillig” hierin en ga geen dingen doen die niet passen bij jouw organisatie. Schrijf een goede blauwdruk met IST/SOLL en Fit Gap beschrijving (Google maar ff …) en doe hieraan geen (of minimale) concessies tenzij er een beter alternatief in SAP voorhanden is.
Verder ben ik het eens met Nico “Zowel klant als leverancier moeten eens de hand in eigen boezem steken!”.
Het lijkt er niet op, dat de klant de schuld krijgt. De klant koopt een software pakket inclusief implementatie. De klant mag dan ook verwachten dat de leverancier de klant begeleid, omdat deze de kennis in huis heeft!!!!
Bijzondere uitspraak van SAP!
ik was midden jaren 90 betrokken bij pakketselectie in microchip industrie in USA, toen schokte me het gebrek aan inlevingsvermogen van SAP in haar klant. Kennelijk is dat nog steeds moeilijk. Formeel gelijk hebben helpt daarbij niet denk ik.
Gerard van der Wal heeft gelijk. Je heb techneuten en consultants. Echte consultants pakken juist (ook) de niet technische zaken op (cultuur, belangen, processen, planning,communicatie en financi?n). Teug naar de schoolbank, of er consultants bijzetten.
Pure techneuten als consultants neerzetten vanwege een hoger uurtarief is slecht voor de klant en ook voor de leverancier. Bij de vaak zeer complexe SAP projecten heb je goede techneuten nodig vanwege de technisch concepten van SAP, maar je hebt ook altijd consultants nodig vanwege een goede afstemming met de klant.
Je hautain opstellen als SAP leverancier en je klanten te kakken zetten, is vooral goed voor je concurrentie. Die wil een partner, geen tegenstander.