7 valkuilen van ERP-implementaties

André van Hooidonk heeft uiteindelijk de verhalen gecombineerd in onderliggend stuk. Hoewel dit vaak betrekking heeft op SAP, ligt de oorzaak veelal bij mensen en komen deze valkuilen deels ook voor bij MS Dynamics Navision, Axapta en Ax, bij Baan en  bij andere ERP's. Dat is zeker het geval met de implementatie van BI bij een logistiek dienstverlener.

1. Implementatie Business Intelligence met (te) lange doorlooptijd

Proloog
Aangezien aan een manager niet direct een antwoord mogelijk was met betrekking tot doorlooptijden van een specifiek product, besloot de directie van een logistiek bedrijf om integraal SAP-BW in te voeren. Hoewel dit een ad-hoc vraag betrof, besefte de directie, dat er geen gestructureerde management informatie was. Opdracht werd gegeven voor invoering van SAP-BW, aangezien alle logistieke en financiële zaken reeds door SAP werden ondersteund.

Probleemstelling
Na een rondje bij de logistiek managers werd duidelijk, dat zij allemaal een -eigen- rapportage hadden gebouwd in MS-Excel en dat zij allemaal stuurden op verschillende criteria. Hoewel dit geen probleem hoeft te zijn, werd besloten om een standaard rapportage voor alle logistieke afdelingen in te voeren. Om dit te kunnen bereiken diende eerst te worden onderzocht welke rapportages er nu werden gebruikt en hoe die konden worden aangepast om ze algemeen bruikbaar te maken. De BI-architect kreeg dit als opdracht mee.

Uitwerking
Onnodig veel tijd is verloren gegaan door deze opdracht. De BI-specialist kon wel de inventarisatieslag maken om een totaaloverzicht te krijgen over de bestaande rapportages, maar kreeg niet voldoende overwicht om tot een standaard rapportage te komen. Na maanden touwtrekken en bemoeienis van het senior management kwam uiteindelijk het voorstel rond. Hierna bleken een aantal van de benodigde rubrieken (nog) niet te zijn geïmplementeerd in SAP. Aangezien het ERP meerdere bestemmingen diende, is besloten om deze omissie tijdelijk aan te vullen met MS-Excel bestanden. De uiteindelijke doorlooptijd van ca 9 maanden als BW-project had in 3 maanden doorlopen kunnen zijn, als het  vooronderzoek buiten het aanbestede project was gehouden.

Lessons learned
Het managementrapport is aanvankelijk veel te licht ingeschat. Het management had eerst duidelijkheid moeten scheppen middels een programma van eisen alvorens een gerichte opdracht aan ICT te geven, dan was ca € 200.000 bespaard gebleven.

2. Problemen door consequent niet af te rekenen

Proloog
De woningcorporatie ging zijn financiële administratie afhandelen in SAP FI/CO. Hiertoe zijn rapportages in SAP en in SAP-BW gemaakt en zijn de begrotingen per kostenplaats ingevoerd. Leidinggevenden zijn opgeleid om de rapportages op te vragen en juist te interpreteren.

Probleemstelling
Doordat er niet regulier werd afgerekend bleven de saldi op de verschillende rekeningen behouden. Dat kwam goed uit, want hierdoor was een vergelijk mogelijk met de begroting. Er waren echter klachten over de kwaliteit van de BW-rapportages. Er zaten merkwaardige, onverklaarbare cijfers in. Bij het reguliere afrekenen had tevens een kwaliteitscontrole op de boekingen moeten plaats vinden en zouden fouten zijn gecorrigeerd. Echter door het afrekenen in te voeren zou het onmogelijk worden om de actuele kosten/opbrengsten te vergelijken met de begrotingen op dezelfde rekeningen. Een vervelende patstelling en de afwijkingen werden steeds groter.

Uitwerking
Na onderzoek bleek, dat er al meer dan een jaar niet was afgerekend. Uiteindelijk werd begonnen met terugwerkende kracht, per maand af te rekenen. Hierdoor kwam zicht op verkeerde boekingen die en-passant werden gecorrigeerd. Voor de afgesloten maanden was het niet langer mogelijk om een vergelijk te maken met de begroting. Daarop is het afrekenen aangepast om niet langer op de oorspronkelijke kostenrekening af te boeken, maar om dit op speciale rekeningen te doen. Hierdoor bleven de saldi op de oorspronkelijke rekeningen in stand, waardoor vergelijk met de begroting weer mogelijk was. Al met al heeft het ruim een jaar geduurd voordat de oplossing in zicht kwam. Al die tijd is met foutieve gegevens gewerkt, waardoor de rapportages onbetrouwbaar waren en is er veel tijd gaan zitten in het vinden van oplossingen voor het vergelijk Actueel – Begroting.

Lessons learned
De ERP-implementator had bij de overdracht aan de Beheerafdeling op de risico's moeten wijzen van het niet-afrekenen. Dan zou het probleem van de vergelijking Begroting versus Actueel eerder zijn besproken en opgelost. Ondertussen had het management nog maar weinig vertrouwen in BW en zij wilde de eigen Excel-rapportages handhaven.

3. De verantwoordelijkheden werden lager in de organisatie gelegd

Proloog
De woningcorporatie wilde verantwoordelijkheden lager in de organisatie beleggen. Hiertoe is een nieuwe kostenplaatsstructuur ontworpen, zijn rapportages in SAP en in SAP-BW aangepast en zijn de begrotingen op het juiste niveau gebracht. Leidinggevenden zijn opgeleid om met de nieuwe kostenplaatsen en profitcenters te werken.

Probleemstelling
Bij de training bleek al, dat leidinggevenden niet zelf hun rapportages oproepen, maar dat laten doen door hun ondergeschikten. Hierdoor moest het autorisatiemodel worden aangepast. De leidinggevenden waren niet echt geïnteresseerd in de rapportages, aangezien zij nooit ter verantwoording werden geroepen.

Uitwerking
Correcte en gerichte rapportages  waren enkele van de succesfactoren van het project. Uiteindelijk heeft de directie het op zich genomen om de leidinggevenden op hun verantwoordelijkheden te wijzen, zodat het project kon worden afgesloten.

Lessons learned
Het is de taak van de controllers om de vergelijking actueel versus begroot te maken en daarover te rapporteren. De verantwoordelijke directieleden moeten dit oppakken en de kritische vragen gaan stellen, ook als het bedrijf de wind in de zeilen heeft. Als dit niet gebeurt, gaan de kosten stilaan oplopen en verliezen de budgethouders hun verantwoordelijkheidsgevoel.

4. Grote doorlooptijd door onvoldoende vooronderzoek naar de benodigde interfaces

Proloog
Het telecombedrijf was toe aan vervanging van hard- en software voor één van zijn platvormen. De software bestond uit ruim 40 applicaties, verdeeld over verschillende applicatie- en database-servers. Het OrderManagement Systeem werd als eerste applicatie vervangen door MS Dynamics AX. (het vroegere Axapta) De opdracht werd gegeven aan een partij, die z'n sporen verdiend had met AX-implementaties.

Probleemstelling
De ruim 40 applicaties communiceerden onderling op verschillende manieren. Één van die applicaties bestond uit Java maatwerk en had als doel om elektronische schakelingen grafisch te kunnen opbouwen en weergeven. Er waren geen interfaces. Orders moesten in dit systeem separaat van het OMS worden onderhouden. Het was echter de bedoeling om AX te laten communiceren met dit Java-systeem. De functionaliteit is onderzocht, maar er werd niet gekeken naar de methode van communiceren. De leverancier had geen kennis en ervaring om met AX te kunnen communiceren. De communicatie tussen AX en de Billing applicatie kende ook dergelijke problemen. Hierbij was sprake van directe communicatie vanuit AX met een verouderde Oracle Database. Ook hier was gebrek aan expertise.

Uitwerking
Er moest worden gecommuniceerd met AX via het MS Authentication Protocol. Dit was onbekend bij de leverancier van de Java-applicatie. Ook bij de AX-implementator was niet de juiste expertise voorhanden. Op de markt is gezocht naar de juiste expertise en die is uiteindelijk gevonden. Dit alleen leverde al 2 maanden vertraging op. Interfacing met het billing systeem ontwikkelde uiterst moeizaam. Er waren legio berichten die heen en weer werden gezonden en elk bericht bracht zijn eigen complexiteit. De ontwikkeling duurde vele maanden.

Lessons learned
Dit betrof een fixed-price project, waarbij de leverancier uiteindelijk grote risico's liep. Als het vooronderzoek afdoende had plaats gevonden, dan was het financiële risico aanzienlijk beter in te schatten geweest en dan waren de juiste expertises op de juiste tijd gereserveerd en ingepland.

5. Pakket van eisen en wensen niet “smart” opgezet, waardoor leverancier vrij spel had

Proloog
Het telecombedrijf had zijn best gedaan en een eisen en wensenpakket samengesteld. Dit was aan de AX-implementator als input gegeven.

Probleemstelling
Het eisen en wensenpakket was “smart” opgezet. Smart staat hierbij voor:
– Specifiek
– Meetbaar
– Acceptabel
– Realistisch
– Tijdgebonden
In werkelijkheid was er in de verste verte geen sprake van een -smart- eisenpakket. De AX-implementator kon er alle kanten mee uit.

Uitwerking
Tijdens de walk-through en het testen werd duidelijk, dat aan lang niet alle eisen en wensen was voldaan. Met de leverancier werd door het pakket eisen en wensen gelopen en helderheid verkregen over wat wel en niet werd gebouwd. In een aantal gevallen waren de eisen zo onhandig opgesteld, dat de leverancier hier niet op kon worden aangesproken. Betreffende eisen werden als meerwerk aangeduid waardoor sprake was van een langere doorlooptijd en hogere kosten.

Lessons learned
Het kan lastig zijn om een pakket eisen en wensen ondubbelzinnig samen te stellen. Dan wordt het belangrijk om van de leverancier vooraf gegarandeerd te krijgen wat hij wel en wat hij niet gaat bouwen, zodat er geen verkeerde verwachtingen zijn. Maar ook als u denkt, dat het pakket eisen en wensen wel smart is opgezet, dan is het nog steeds belangrijk om de details met de leverancier te bespreken, waarbij van de leverancier duidelijke ondubbelzinnige uitspraken moeten worden verwacht.

6. Leverancier komt bij herhaling zijn afspraken niet na

Proloog
De implementatie van MS-Dynamics AX zou de 1e week van december plaats vinden. De geplande testen in november bleven echter uit.

Probleemstelling
De projectleider van de implementator was te onervaren om al dan niet in overleg met de achterban tot juiste afspraken te komen. Door de initiële vertraging waren essentiële resources niet langer beschikbaar.

Uitwerking
In goed overleg is besloten de live-gang te verplaatsen naar de 1e week van februari. Er is nog even geroepen dat medio februari haalbaar was, maar uiteindelijk werd afgesproken, dat de 1e week van april de oplevering zou plaats vinden. Gedurende deze periode werd er voortdurend een beroep gedaan op de kerngebruikers, waardoor dezen in de problemen kwamen met hun reguliere werkzaamheden. Uiteindelijk bleek ook april niet haalbaar. De implementator had hulp nodig bij de bouw van de verschillende interfaces en bij het vervolmaken van de gevraagde functionaliteit. Hoewel het een fixed-price project betrof, probeerde de leverancier op allerlei manieren om de extra kosten op de opdrachtgever te verhalen. Na veel touwtrekken met de leverancier, zou het project bijna 1 1/2 jaar te laat worden opgeleverd. De oorspronkelijke doorlooptijd was geschat op ca 9 maanden!

Lessons learned
Accepteer geen enkele tijdsoverschrijding van de milestones. Het is de taak van  de projectleider en de leverancier om zaken op tijd te leveren. Nieuwe, of onvoorziene functionaliteit wordt ten alle tijde bij de stuurgroep aangemeld. Dit orgaan beslist over het al dan niet accepteren van deze functionaliteit en de consequenties daar van. Bij herhaald in gebreke blijven is direct overleg nodig tussen de projectmanagers van de betrokken partijen.

7. Implementatie vertaalproblemen

Proloog
De gap-analyse tussen de huidige situatie op het legacy-systeem en de gewenste situatie in SAP was uitgevoerd op hoofdpunten. Er waren geen onoverkomelijke problemen en de hoeveelheid maatwerk bleef beperkt. De -eigen- ICT-mensen zouden on-the-job worden getraind.

Probleemstelling
Er waren geen functionele beschrijvingen van het huidige systeem, kennis zat tussen de oren. De Abap(SAP)-programmeurs van de leverancier moesten in overleg met de eigen ICT-ers tot een juiste inrichting van SAP komen. Dat was een taak die eigenlijk niet bij hen thuis hoorde.

Uitwerking
Er kwamen signalen van de eigen ICT-club, dat de vertaalslag naar SAP niet te  maken was. De leverancier verwachtte kennis van SAP, die (nog) niet aanwezig was. De opdrachtgever verwachtte dat de Abap'rs middels interviews wel achter de waarheid zouden komen, maar dat was een utopie. Het project is op dat moment gestopt en business analists hebben interviews gehouden om tot functionele ontwerpen te komen.

Lessons learned
De gekozen oplossing was op dat moment de juiste, maar dit had een aparte stap in het plan van aanpak moeten zijn, zodat op het juiste moment de juiste expertise aanwezig was en er geen stagnatie en frustratie zou optreden.