Inleiding

De selectie, de implementatie en het in beheer nemen van ERP-systemen is geen eenvoudige klus. Maar zelden lees je dat de implementatie van een ERP-systeem geheel vlekkeloos is verlopen binnen de daarvoor gestelde tijd, het beschikbare budget en de gestelde kwaliteitseisen. Uit een onderzoek van KPMG bleek dat de implementatie doorgaans als zwaar en lang wordt ervaren. Slechts vijf procent van de respondenten van het onderzoek gaf aan geen verstorende knelpunten te hebben ondervonden tijdens de implementatie van een ERP-systeem ([KPMG99]). Met name het doorvoeren van organisatorische veranderingen en afstemming van het pakket op processen werd door de rest (95 procent!) als knelpunt ervaren. Anno 2002 blijkt nog steeds dat ERP-projecten erg lastig zijn voor organisaties om goed te managen en om ervoor zorg te dragen dat deze projecten geen matige projecten worden.

De tekortkomingen naar aanleiding van het niet-gestructureerd oppakken van risicomanagement bij ERP-projecten zijn veelal bekend bij organisaties en IT-auditors.

De tekortkomingen die men zoal tegenkomt in de praktijk zijn:

• In het pakketselectietraject zijn de knock-outcriteria voor de uiteindelijke keuze van een ERP-pakket niet of onvoldoende duidelijk geformuleerd.
• De selectiecriteria en/of motieven voor de uiteindelijke keuze voor een bepaald ERP-pakket vervagen gedurende het implementatietraject en er wordt niet meer gestuurd op de eisen die zijn gesteld tijdens het selectietraject.
• Contracten zijn regelmatig eenzijdig en ten gunste van de leveranciers en/of implementatiepartners opgesteld. De structuur van de contracten en daarmee de rangorde tussen de diverse (algemene) voorwaarden is vaak onvoldoende helder.
• De aansprakelijkheid van de leverancier en/of de implementatiepartner is niet duidelijk omschreven. Bijlagen in contracten en prijslijsten voor eventueel meerwerk zijn niet actueel en niet overal eenduidig.
• Er wordt niet vooraf goed nagedacht over het opzetten en inrichten van een projectorganisatie waardoor er sprake is van onvoldoende projectmanagement.
• De verantwoordelijkheden voor het gehele implementatietraject zijn onduidelijk belegd. Is de organisatie of de implementatiepartner geheel verantwoordelijk voor de implementatie van een ERP-systeem dat aansluit op het gewenste kwaliteitsniveau van de eindgebruikers en/of de in het selectietraject opgestelde eisen en wensen?
• Eindgebruikers participeren niet of nauwelijks in de ERP-projecten.
• Er is te veel focus op de IT in plaats van op de impact van het ERP-systeem op de bedrijfsprocessen en de eindgebruikers.
• Er is gedurende de implementatietrajecten onvoldoende gestuurd op de verwachte baten. Vaak blijkt dat er uit de oude systemen toch betere of meer informatie kon worden gehaald.
• Implementatietrajecten worden niet goed afgerond waardoor direct na het in gebruik nemen van het ERP-systeem optimalisatietrajecten noodzakelijk worden.

Al deze tekortkomingen duiden erop dat Early Warnings bij ERP-projecten zeker geen overbodige luxe zijn. Onder Early Warnings worden in dit artikel signalen van mogelijke toekomstige tekortkomingen verstaan.

De IT-auditor kan vanaf het selectietraject tot en met het in beheer nemen van het ERP-systeem een belangrijke rol vervullen bij het ‘in control’ houden van de ERP-projecten door middel van gestructureerd risicomanagement.

In dit artikel wordt ingegaan op de Early Warnings en de mogelijke gevolgen (= tekortkomingen) van het niet in acht nemen van deze waarschuwingen. De Early Warnings worden toegelicht met drie casussen, waarbij al dan niet bewust Early Warnings zijn genegeerd. Er is een casus voor Early Warnings bij pakketselectietrajecten, een casus voor Early Warnings bij implementatietrajecten en een casus voor Early Warnings bij het in beheer nemen van ERP-systemen.

Doel is om organisaties die ERP-systemen implementeren en IT-auditors die daarbij een rol vervullen een aantal Early Warnings te geven bij de selectie, de implementatie en het in beheer nemen van deze systemen. Een ander doel is niet zozeer een volledig overzicht te presenteren, maar het benadrukken dat, naast het gebruiken van reeds in de praktijk bewezen selectie-, implementatie- en beheermethodieken en -technieken bij ERP-projecten, de inbreng van ervaring noodzakelijk is om gestructureerd risico’s te managen.

Bij de uitwerking hanteren wij het in figuur 1 gegeven ‘EW-model’.

Figuur 1. Early Warning-model.

Casus 1: Early Warnings bij een pakketselectietraject

Inleiding

Een pakketselectietraject kan globaal worden onderscheiden in de fasen: definitie van eisen en wensen, longlist- en shortlistfase en contractonderhandelingen. Kennis en ervaring bij het personeel van een organisatie die een ERP-systeem selecteert is veelal niet of onvoldoende aanwezig, omdat een organisatie gemiddeld eenmaal in de vijf tot tien jaar een selectietraject uitvoert voor een ERP-systeem. Bij een pakketselectie wordt vaak een strategische keuze gemaakt omdat het gekozen ERP-systeem een belangrijk middel vormt waarmee ondernemingsdoelstellingen moeten worden gerealiseerd. Verkeerde keuzen kunnen ernstige consequenties voor organisaties hebben. Het belang van het zorgvuldig uitvoeren van een pakketselectietraject dient dan niet te worden onderschat.

De casus: ‘Een goede voorbereiding is het halve werk’

Een middelgroot installatie- en onderhoudsbedrijf besluit tot vervanging van haar huidige automatisering (een mix van zelf ontwikkelde programmatuur en een verouderde versie van een standaardpakket). De directeur/grootaandeelhouder vraagt het hoofd Automatisering een pakketselectietraject op te starten. Omdat het hoofd Automatisering weinig feeling heeft met het in kaart brengen van bedrijfsprocessen en met selectietrajecten, vraagt hij de medewerkster Kwaliteitsbeheersing om samen met hem de projectgroep Pakketselectie te vormen. De directeur/grootaandeelhouder geeft de projectgroep mee dat de investering maximaal 0,9 mln euro mag bedragen. Tevens stelt hij dat het advies binnen acht weken gepresenteerd moet worden op de eerstvolgende bijeenkomst van het managementteam.

Deze punten in het achterhoofd houdende gaat het hoofd Automatisering op zoek naar kandidaatpakketten op het internet. Tegelijkertijd stelt de projectgroep een lijst met wensen en eisen op die wordt afgestemd met de proceseigenaren. Hieruit volgt slechts een beperkt aantal wijzigingen. Na een week heeft het hoofd Automatisering een longlist van negen mogelijke pakketten opgesteld. Vervolgens wordt naar alle negen leveranciers op de longlist een vragenlijst opgestuurd om aan te geven in hoeverre het pakket aan gestelde eisen voldoet (de Request for Information, RFI). In de begeleidende brief wordt vermeld dat indien de leverancier niet binnen de gestelde termijn de vragenlijst volledig ingevuld retourneert, het pakket niet meer in het verdere selectietraject wordt meegenomen. Uiteindelijk reageren niet alle leveranciers binnen de gestelde termijn.

Op basis van de terugontvangen RFI’s komt de projectgroep tot een shortlist met twee pakketten: één van de grotere ERP-pakketten en een branchespecifiek pakket. Op verzoek van het bedrijf geven beide leveranciers vervolgens een korte demonstratie van het systeem op de locatie van het bedrijf. Bij deze demonstratie, waar geen gebruik is gemaakt van een business case, waren de leden van de projectgroep en de leden van het managementteam aanwezig. Alleen de directeur/grootaandeelhouder was er niet bij. Ten slotte brengen de beide leveranciers een offerte met een kostencalculatie voor aanschaf en implementatie van hun pakket uit. Op basis van de uitkomsten van deze demo, de ingevulde RFI’s en de offertes brengt de projectgroep een advies uit aan de directeur/grootaandeelhouder en presenteert haar keuze in het managementteamoverleg. De projectgroep komt tot het advies om te kiezen voor het ERP-pakket.

Van een goede relatie heeft de directeur/grootaandeelhouder inmiddels gehoord welke inspanningen de implementatie van een dergelijk pakket vraagt van zijn bedrijf (in termen van geld en tijd). Hij heeft dan ook nog geen goed gevoel bij de uitkomst van het selectietraject en vraagt een IT-auditor een second opinion uit te voeren op het uitgevoerde selectie- en keuzetraject.

Uit het onderzoek van de IT-auditor kwam al snel naar voren dat de voorbereiding en uitvoering van het selectie- en keuzetraject niet adequaat waren uitgevoerd. De gestelde randvoorwaarden waren onduidelijk gedefinieerd en het genoemde bedrag betrof uitsluitend de investeringskosten. Bij de kosten van implementatie, kosten van beheer en mogelijke baten door kostenreductie of additionele baten was niet stilgestaan. Tevens bleek een belangrijk bedrijfsspecifiek proces niet uitgewerkt te zijn en niet te zijn meegenomen in het selectietraject. Het hoofd Automatisering heeft slechts één bron geraadpleegd en op een ongestructureerde wijze informatie verzameld voor het samenstellen van de longlist. Het pakket van één van de (andere ERP-) leveranciers die niet tijdig de RFI heeft kunnen terugsturen, blijkt achteraf het pakket te zijn dat het meest geschikt is voor het bedrijf, mede vanwege de mogelijkheden op het gebied van maatwerk en interfaces.

Een adequate voorbereiding en uitvoering van het pakketselectietraject kunnen een verkeerde keuze van een pakket voorkomen en een bedrijf veel narigheid tijdens de implementatie en na het in gebruik nemen van het pakket besparen.

Een aantal generieke Early Warnings

In tabel 1 is voor de selectiefase een aantal Early Warnings opgenomen. Tevens zijn de gevolgen opgenomen indien de Early Warnings niet worden gesignaleerd, de opvolging niet serieus wordt genomen of niet tijdig plaatsvindt.

Tabel 1. Early Warnings tijdens de selectiefase. [Klik hier voor grotere afbeelding]

Casus 2: Early Warnings bij een implementatietraject

Inleiding

Na de uiteindelijke keuze voor een ERP-systeem komt het volgende traject, namelijk de feitelijke implementatie van het ERP zelf.

Vaak heeft de organisatie al iets van het ERP-systeem gezien gedurende het selectietraject. Meestal worden er na de longlistfase ERP-leveranciers en/of implementatiepartners uit de shortlist uitgenodigd om op basis van een business case een korte demonstratie (‘proof of the pudding’) te geven van het ERP-systeem. Dat dit soms misleidend kan zijn is evident, immers de vraag is of de business case die gehanteerd wordt bij de demonstratie wel representatief is voor de organisatie als geheel en of alle gevraagde functionaliteiten ook daadwerkelijk zo eenvoudig en gemakkelijk werken in de praktijk als tijdens de demonstratie.

De casus ‘Plug and Play’

Een buitenlandse moedermaatschappij met veel vestigingen in diverse landen, waaronder Nederland, heeft na een uitgebreid selectietraject gekozen voor het ERP-systeem omdat dit hét systeem voor de gehele onderneming zou moeten zijn. Op het niveau van de moedermaatschappij is er een basis-ERP-systeem gebouwd voor alle werkmaatschappijen, waaronder een werkmaatschappij in Nederland.

De Nederlandse werkmaatschappij die te typeren is als een kleine handelsonderneming, kon in 1999 geen andere keuze maken dan het implementeren van het ERP-systeem omdat het in gebruik zijnde systeem niet Y2K- en europroof was. Doordat aanvankelijk werd gedacht dat de implementatie wel mee zou vallen omdat de moedermaatschappij immers het nodige voorwerk had gedaan, heeft het management van de Nederlandse werkmaatschappij de bedrijfsspecifieke zaken erg onderschat. Zo was bijvoorbeeld een voorraadadministratie in eenheden niet voldoende voor het volgen van de geld- en goederenbeweging. Ook bruto- en nettogewichten dienden te worden geregistreerd. Dit zat niet standaard in het basis-ERP-systeem dat geleverd werd door de moedermaatschappij. Gevolg: diverse grote voorraadverschillen die niet konden worden verklaard. Ook reeds ingerichte autorisatieprofielen voor de primaire functiescheiding tussen inkoop, administratie en verkoop waren niet werkbaar bij de werkmaatschappij, omdat er verschillende taken in de standaard-autorisatieprofielen waren opgenomen. Terwijl in Nederland juist gekozen was voor een andere inrichting van de taken en verantwoordelijkheden vanwege de beperkte omvang van de organisatie. Gevolg was het één op één overnemen van de standaard-autorisatieprofielen en meerdere autorisatieprofielen koppelen aan één functionaris, waardoor de vereiste controletechnische functiescheiding systeemtechnisch niet meer was gewaarborgd.

De uiteindelijke gevolgen van deze implementatie waren dat het management werd geconfronteerd met erg veel aanpassingen in het ERP-systeem achteraf en een erg hoog prijskaartje voor een ERP-systeem ter ondersteuning van de bedrijfsprocessen. In deze casus had het management baat gehad bij Early Warnings voordat begonnen werd met het implementatietraject. Door er echter zonder meer van uit te gaan dat ‘alles’ centraal was geregeld en dus in Nederland alleen maar sprake kon zijn van ‘plug and play’, heeft het management van deze onderneming ervaren dat een ERP-implementatie niet standaard is en dat gestructureerd risicomanagement wel degelijk toegevoegde waarde kan hebben. De IT-auditor werd in deze casus pas betrokken nadat er door de controlerend accountant onverklaarbare verschillen in de voorraadadministratie werden geconstateerd. Deze IT-auditor heeft alsnog een uitgebreide risicoanalyse uitgevoerd (op basis van het ‘EW-model’) en op grond daarvan concrete verbetermaatregelen geadviseerd.

Een aantal generieke Early Warnings

In tabel 2 is voor de implementatiefase een aantal Early Warnings opgesomd. Tevens zijn de gevolgen opgenomen indien de Early Warnings niet (tijdig) worden gesignaleerd en opgepakt.

Tabel 2. Early Warnings tijdens de implementatiefase. [Klik hier voor grotere afbeelding]

Casus 3: Early Warnings bij het in beheer nemen van een ERP-systeem

Inleiding

‘Beheert eer gij het ERP-systeem begeert’, dat is het motto voor het in beheer nemen van het ERP-systeem. De overdracht van de projectorganisatie naar de beheerorganisatie is cruciaal. In de praktijk is de scheidslijn tussen enerzijds de projectorganisatie en anderzijds de beheerorganisatie niet altijd even scherp. Met name projectleden die in de beheerorganisatie een andere rol gaan vervullen, hebben vaak moeite met het daadwerkelijk ‘beheren’ van het ERP-systeem voor de gebruikers. Was het voor hen in de projectorganisatie nog mogelijk om zonder strikte procedure in het systeem te werken, dan wordt het voor hen even wennen om in de beheerorganisatie ook te werken volgens strikte procedures (denk aan inperking van reeds toegekende autorisaties en de wijze waarop parameters in het ERP-systeem worden aangepast). Het is belangrijk voor het projectmanagement om de projectorganisatie op een gegeven moment nadat het implementatietraject is afgerond, ook te ontmantelen en formeel decharge te verlenen. Hierdoor kan de beheerorganisatie met een ‘schone lei’ beginnen aan het beheer van het ERP-systeem.

De casus ‘Beheert eer gij begeert’

Het management van een professionele dienstverlenende organisatie heeft na een implementatietraject van ruim anderhalf jaar besloten om het gekozen en ontwikkelde ERP-systeem uiteindelijk in productie te nemen, ondanks een groot aantal tekortkomingen op het gebied van onder andere rapportages en additioneel noodzakelijk maatwerk. Het ERP-systeem moest onder druk van het management (mede vanwege het reeds ontstane negatieve beeld rondom het ERP-systeem) per een bepaalde datum gaan draaien. De projectorganisatie heeft het ERP-systeem in overleg met een aantal key-users uiteindelijk in gebruik genomen. Direct na de invoering van het ERP-systeem werd de projectorganisatie overstelpt door vele telefoontjes van eindgebruikers die ineens ‘hun’ werk niet meer konden doen. De eerste weken waren hectisch en chaotisch. De projectorganisatie was voornamelijk bezig met ‘brandjes’ te blussen en kwam zo niet toe aan het oplossen van de bekende tekortkomingen, zoals het additionele maatwerk en de inrichting van de rapportagestructuur. Gevolg was dat de projectorganisatie noodgedwongen consensus deed aan de gewenste kwaliteit (o.a. op het gebied van autorisaties; zo kregen sommige functionarissen veel te ruime autorisatiebevoegdheden).

Na ruim zes maanden werd het wat rustiger en kreeg de projectorganisatie meer ruimte om verder te gaan met het ‘reguliere’ werk dat gepland stond en waarin diverse achterstanden waren ontstaan. De projectorganisatie besloot onder meer een IT-auditor in te schakelen om gevraagd en ongevraagd adviezen uit te brengen. Eén van de eerste acties was het optuigen van een beheerorganisatie naast de projectorganisatie. Dit betekende in de praktijk dat rollen en verantwoordelijkheden werden uitgewerkt voor leden van de projectorganisatie die enerzijds in de projectorganisatie en anderzijds in de beheerorganisatie zaten. Door het opzetten van de beheerorganisatie werd duidelijk wat de benodigde capaciteit was. Besloten werd om zittende leden van de projectorganisatie (veelal eigen functionarissen) over te hevelen naar de beheerorganisatie en eventuele leemten in de projectorganisatie op te vullen door het inhuren van tijdelijke externe consultants.

Doordat het management het belang van een goed werkende beheerorganisatie in deze casus had onderschat, is veel kostbare tijd verloren gegaan. Dit had voorkomen kunnen worden door vooraf goed te beseffen dat het in beheer nemen van een ERP-systeem gepaard dient te gaan met het opzetten en inrichten van een ERP-beheerorganisatie.

Het is belangrijk om tijdig te starten met het inrichten van een adequate beheerorganisatie met de daarbijbehorende taken en verantwoordelijkheden. Reeds voor de feitelijke oplevering van het ERP-systeem dient er een beheerorganisatie te zijn ingericht om na de implementatie het ERP-systeem gelijk in productie te kunnen nemen. Het niet tijdig oppakken van de beheerorganisatie leidt in de praktijk ertoe dat de projectorganisatie ‘gewoon’ doorgaat, met één groot verschil, namelijk dat je dan te maken gaat krijgen met de eindgebruikers die andere eisen en wensen zullen hebben. Met een goed opgezette beheerorganisatie zal de organisatie de ‘meerwaarde’ van het ERP-systeem ervaren ten opzichte van het oude systeem waarmee werd gewerkt.

Een aantal generieke Early Warnings

In tabel 3 zijn voor het in beheer nemen van ERP-systemen een aantal Early Warnings en mogelijke toekomstige tekortkomingen opgesomd.

Tabel 3. Early Warnings tijdens het in beheer nemen. [Klik hier voor grotere afbeedling]

Conclusie

In dit artikel is ingegaan op een aantal Early Warnings die in de verschillende fasen van selectie tot en met het in beheer nemen van een ERP-systeem kunnen worden onderkend. Geconcludeerd kan worden dat gestructureerd risicomanagement noodzakelijk is om met behulp van Early Warnings risico’s bij ERP-projecten te managen.

Doel was niet een volledig overzicht van Early Warnings te presenteren, maar het benadrukken dat, naast het gebruiken van reeds in de praktijk bewezen methodieken en technieken, de inbreng van ervaring noodzakelijk is om risico’s te managen.