Voorkom een ERP-implementatie mislukking. Deel 2: De Stip en het oude denken
Hoofdstuk 1: HET PROBLEEM
Tja, hebben we daar een duidelijk antwoord op? Ofwel hebben we nu werkelijk voor ogen waarom we een zo alles omvattend traject opstarten?We horen: verouderde software. Zou zomaar kunnen zijn. Er zijn best een aantal voorbeelden te noemen van bedrijven die “aan de voorkant” bijzonder succesvol opereren maar “aan de achterkant” met werkelijk oude software werken. AS400 systemen, ja zelfs Cobol software draait her en der nog.
Is software dan werkelijk het probleem? De vraag stellen is hem eigenlijk al beantwoorden, het antwoord luidt dat het niet zo hoeft te zijn. Wat je vaak ziet is dat software ooit in het verleden is aangekocht/geïnstalleerd en dat gedurende de jaren telkens wat is geoptimaliseerd, uitgebreid en verder ontwikkeld. Dit door dure consultants of (zelfs) programmeurs in dienst.
Je krijgt dan een bloemkoolachtige omgeving waarbij daarnaast een omgeving aanwezig dient te zijn die deze bloemkool ook nog in leven moet houden. In het voorbeeld van hierboven; zijn er nog Cobol programmeurs te vinden? Of hebben we nog een overvloed aan AS400 programmeurs? Als ze er al zijn hangt daar een behoorlijk prijskaartje aan vast of hebben ze een dermate leeftijd bereikt (met alle respect hè!!) die hen, zeer begrijpelijk overigens, net niet die drive geeft om zo vooruitstrevend te zijn om zo’n “gedateerde auto” dermate op te kalefateren om met hun moderne soortgenoten mee te kunnen gaan.
Is dat wel de werkelijke reden?
De geïnstalleerde software heeft een bepaalde manier van werken teweeggebracht. De werknemers zijn gewend op die manier te werken. Dit kan niet anders.
Sterker nog, vaak zie je ook organisatiestructuren dusdanig opgezet, of in de loop der jaren ontwikkeld, om die manier van werken zogenaamd optimaal te ondersteunen. Er ontstaan op deze wijze ook zelfstandige eilandjes met als achterliggende gedachte (soms ook zo uitgesproken) dat “die anderen snappen toch niet hoe het werkt”.
Ook de IT-afdeling heeft zijn eigen status bereikt.
Kortom, er is een eilandjesorganisatie ontstaan waar op ieder eilandje op een bepaalde manier wordt gewerkt en gedacht, vaak behoorlijk onafhankelijk van de andere bedrijfsonderdelen. Er is een bepaalde interne machtsstructuur ontwikkeld.
Zo’n organisatie ontwikkelt zich in de loop der jaren en laat zich niet zo heel makkelijk meer van koers veranderen. Het begrip olietanker komt hierbij in gedachte.
Is dat niet veel meer richting een antwoord op de vraag van wat het probleem is?
De vraag stellen is hem ook in dit geval eigenlijk beantwoorden. Dit zogenaamde “oude denken” houdt vaak een organisatie in een bepaalde (wurg)greep. Want oh oh, wat zal het een consternatie geven om dat te veranderen. Catastrofes worden beloofd. “Ja hé, onze leveranciers gaan hier niet mee akkoord hè”, of “Hoe houd ik dan nog overzicht over de voorraden die ik moet beheren?”, of “Ik weet zo toch niet meer precies wat en wanneer ik moet produceren.” en de grote dooddoener: “We gaan echt heel veel omzet verliezen.”. We hebben ze allemaal voorbij horen komen. Het is niets meer of minder dan vasthouden aan het oude stramien. Begrip, gedrag, redengeving, allemaal begrippen die hier direct op ingrijpen. Daar zijn boeken vol over geschreven in het kader van Verandermanagement.
Dat is nu precies de uitdaging voor u als CEO of dga: Hoe krijg ik het voor elkaar om dit oude denken om te buigen naar nieuw denken, zodanig dat we nu wel de goede keuzes maken in nieuw te implementeren software?
In mijn optiek kan een IT-implementatie daarom niet helemaal los worden gezien van Verandermanagement. Sterker nog, ik denk dat het zelfs onlosmakelijk is. Daarover later meer.
In het overgrote deel van startende projecten zie je als startpunt de huidige manier van werken. Ofwel het oude denken. Er worden processen en procedures geschreven (als ze er al niet zijn) en dat moet het dan worden.
Wat ben je dan aan het doen? Nou, simpel gezegd een oud IT-systeem aan het vervangen voor een nieuw IT-systeem wat (nagenoeg) hetzelfde doet. Je hebt dan substantieel geld uitgegeven maar ben je er beter van geworden? Nee.
Dit is een van de grootste valkuilen die er zijn en waar vaak wordt ingetrapt. Werkelijk. Want je kunt aan het begin van een project wel zeggen: We gaan iets nieuws implementeren met nieuwe werkwijzen die zoveel mogelijk de nieuwe standaard worden, maar als de sleutelpersonen in het project vastgeroest zitten - en belangrijker nog blijven zitten - in dit oude denken, dan zal er gedurende het project zich langzaam maar heel zeker een voorspelbare slow motion car crash volgen.
Ofwel de car crash in slow motion
Bijna altijd zie je in ERP projecten dezelfde stappen genomen worden. Die in principe ook juist zijn. Maar toch gaat het fout. Hierbij een korte beschrijving:
1. Pakketselectie
a. Projectteam wordt samengesteld; Business Process Owners (BPO-ers), key-users (KU-ers) , IT-application experts.
b. Procesbeschrijvingen worden gemaakt. Knelpunten beschreven, verbeterpunten benoemd.
c. Huidige applicatielandschap wordt beschreven, inclusief allerlei interfaces,
d. Eisen en wensenlijst wordt opgesteld
e. Mogelijke leveranciers worden uitgenodigd op basis van RFI’s als resultaat van bovenstaand.
f. Er wordt een Proof of Concept (PoC) gedaan.
g. Er wordt een offerte gevraagd.
Met dit proces ben je een maand of 4 tot 6 verder.
2. Contractafsluiting
CEO sluit aan en na onderhandeling wordt contract getekend
3. Blueprinting
a. Consultants komen zich in uw organisatie verdiepen, gaan in conclaaf met BPO-ers en KU-ers over aangeleverde processen en verdere aangeleverde stukken.
b. Zij sluiten deze fase af door het aanleveren van de Blueprint document; hoe zij zien hoe de nieuwe software zou moeten gaan functioneren.
c. Deze wordt, soms na wat wijzigingen, goedgekeurd door de BPO-ers en KU-ers.
4. Bouwen
a. Leverancier begint met bouwen en configureren van de software en interfaces
b. Testscenario’s worden geschreven
c. Masterdata wordt vervolmaakt en conversieprogramma’s worden geschreven.
5. Testen en acceptatie
a. De KU-ers krijgen, vaak voor de eerste keer, in het nieuwe systeem (in test uiteraard) te zien wat het resultaat is van wat er is afgesproken en gebouwd.
b. Natuurlijk moet er her en der nog een en ander worden aangepast.
c. Maar hier komen de eerste grote haarscheuren: “Zo hadden we het niet bedoeld” of nog sterker “zo werken we hier niet”.
Kortom, geen acceptatie.
6. En dan?
In de normale projectaanpak wordt zulks bij de Stuurgroep meetings al gerapporteerd.
a. Dus, de projecteigenaar wordt “erbij gehaald”. In uw geval: de CEO wordt ingelicht.
b. Een cruciaal besluit dient genomen te worden:
- De stuurgroep (hierna: SG) steunt de leverancier en dus moet de gehele organisatie accepteren wat er is geprogrammeerd; of
- De SG steunt de KU-ers en derhalve moet de leverancier programmatuur aanpassen. Hetgeen dus meerwerk gaat betekenen; of
- De SG beëindigt het project.
In ieder geval betekent dit budgetoverschrijding, uitloop t.o.v. de planning, stress/onbegrip/onwelwillendheid binnen het projectteam, kortom ontevredenheid alom.
c. Uiteindelijk komt er een “GO” indien het project niet wordt geannuleerd, tenminste als de aanpassingen acceptabel zijn in performance zowel functioneel als technisch. Anders volgt alsnog een “NO-GO” en volgt wederom datzelfde beslissingspad.
d. Als uiteindelijk toch LIVE gegaan wordt zal het de eerste 3-5 maanden alle hens aan dek zijn om een en ander toch of alsnog op de juiste manier te laten werken. Bijgevolg zul je in de toekomst bij upgrades of andere aanpassingen altijd tegen dat maatwerk aan blijven lopen.
Wat heb je dan eigenlijk geïmplementeerd? Inderdaad, een nieuwe bloemkool.
Het allerbelangrijkste: Het begin.
Een ERP-implementatie is een IT-project en geen software vervanging, maar het gaat (1) om processen en procedures en het gaat (2) over mensen.
De aansturing moet dus komen vanuit de processen. De BPO-ers zijn de baas om het maar plat uit te drukken.
Daarnaast heeft het oude denken erg veel invloed gehad. Niet direct maar sluipend (de slowmotion car crash).
Te late confrontatie; je komt pas op een laat moment tot de ontdekking dat je uitgangspunten zijn verlaten. Bedoeld om nieuwe processen te ontwikkelen, niet om hetzelfde in een nieuw jasje te krijgen.
Niet vasthouden aan vooraf vastgelegde uitgangspunten en relatief en waarschijnlijk onbewust vrijheid geven daaraan te sleutelen.
Het momentum is gemist; Op het moment van eerste testen (hierboven punt 5 testen en acceptatie) bent u als CEO eigenlijk al te laat. De “confrontatie” is te hard, het negativisme (sterk verwoord) slaat toe en uw organisatie gaat niet helemaal, of helemaal niet mee om.
Daarnaast hebt u op datzelfde moment een issue met uw leverancier. Immers hij heeft gedaan wat is afgesproken. En wil daarvoor wel betaald worden. Alle extra’s dienen ook te worden betaald. (de budgetoverschrijding).
Maar we zitten op een rijdende voortrazende trein. Dus moeten er pijnlijke afwegingen en beslissingen genomen worden.
Kan ik überhaupt nog wel de stekker eruit trekken? Wat zijn daarvan de consequenties? In ieder geval veel geld weggegooid en teruggeworpen in de tijd. En hoe ga ik dan zorgen dat bij een re-start wel de juiste uitgangspunten worden gekozen en vooral gehandhaafd?
Zo nee, wat zijn dan de consequenties? Immers door de toch wel aanwassende hoeveelheid maatwerk raak je steeds meer gebonden aan de leverancier (zogenaamd: vendor lock-in)
Je bent dus een gevangene geworden van je eigen project.
Dat kan zeker, maar wel “aan de voorkant”.
Je zult draagvlak moeten creëren bij de BPO-ers, KU-ers en natuurlijk MT als die niet in deze groep zijn vertegenwoordigd. Zij zullen de nieuwe manier van werken moeten aanvaarden en ervan overtuigd raken dat dit de toekomst is. Er zal dan ook een nieuwe organisatie gaan ontstaan. Met nieuwe processen, met nieuwe informele circuits etc. Precies hierom is een ERP -implementatie, of welke naam je er ook wilt geven aan zo een project, verre van een IT-project maar heeft alles met mensen te maken.
En dus, zoals al eerder aangegeven, is zo’n proces een Verandermanagementproces met een hele grote en belangrijke IT-component. Dat geeft de beste voorwaarde om zo’n traject tot een succes te laten komen.
Die IT-tool, een ERP-systeem, zal moeten voldoen aan de eisen, wensen en richtingen die afgeleid worden van “die stip op de horizon”. Derhalve ondersteunend aan de strategie met al zijn facetten.
In het volgende deel gaan we hierop verder.