Waarom is er steeds onderzoek nodig om te bewijzen wat iedereen al lang weet.
Vrijwel iedere ERP implementatie wordt gekenmerkt door het 3x3x3 synddroom. Het wordt drie keer zo duur al beloofd, de implementatie duurt drie keer zo lang als beloofd en het systeem kan drie keer zo weinig als beloofd.
Het is dan ook een mirakel dat er nog steeds managers zijn die in de "Veel beloven, weinig geven" verhalen van de ICTers trappen.
Het is stukken beter, goedkoper en succesvoller om eerst de bedrijfsprocessen te vereenvoudigen en vervolgens door simpele systemen te laten ondersteunen. De slaagkans is dan 95% (afgezet tegen de 80% mislukking van de ERP implementaties toch heel aardig) en de kosten bedragen slechts een schijntje van de implementatie van die 7 CD's.

@ de Beer

Wat je doet is schieten vanuit de heup in de hoop dat er wel ergens iets raak zal zijn.
Mis dus.Hier maar even in de kantlijn

“. . . wat iedereen al lang weet”.
Elke 15 jaar wordt in bijna alle bedrijfsideologieën het wiel opnieuw uitgevonden. Soms omdat “we” het vergeten zijn of ter verbetering van het oude.

“3×3x3 syndroom”
Wel hééél erg overtrokken. Als je er 1,5 x 1,5 x 1,5 van maakt zit je dichter in de buurt.
De vraag waarom is interessant. Bij selectie van een ERP/CRM houdt een verstandig bedrijf eerst de processen van nu en in de toekomst tegen het licht. Dat is een iteratief proces waarbij de vraag steeds wat verandert en mogelijk groter wordt. Wat vaak niet wordt verteld is dat het huiswerk voor de selectie DE EERSTE KEER is dat een bedrijf serieus naar zijn processen kijkt. En dat verklaart een hele hoop.

“. . . verhalen van de ICTers”
Die zijn als het goed is niet leidend, maar volgend in deze exercitie. Trommelslagers zijn produktie, verkoop en mogelijk finance.

“. . . eerst de bedrijfsprocessen te vereenvoudigen”
Nee, doorlichten en doen wat gedaan moet worden. Mogelijk wordt het véél complexer, afhankelijk van het lange termijn doel van het bedrijf.

“. . . simpele systemen”
Deze rekenen we goed. In veel gevallen is het oude KanBan systeem (kaartje aan het produkt-in-wording hangen en terugbrengen naar start als het product klaar is) kan natuurlijk ook.

De slaagkans/faalkans (95% / 80%)
Niets doen is nog goedkoper (100%) en 80% is héél erg overtrokken. Praat eens met bedrijven die het traject succesvol hebben afgelegd.

Groet,
Jos Steynebrugh
Marketing & Innovatie Consulent

@ Ad
@ Jos
Zoals vaak in dit soort situaties hebben jullie allebei gelijk. Ad zet het lekker scherp en daarmee wat ongenuanceerd weg, maar het gaat niet om de vraag of het nu 3x3x3 is of 1,5x1,5x1,5, want ook met dat laatste is het punt nog steeds gemaakt.
Het slaagkans en faalkans verhaal wordt naar mijn mening in dit onderzoek redelijk aangetoond: het is eigenlijk helemaal neutraal. Alleen lijken de risico's wel veel groter te worden.

Wat mij betreft springen er 2 dingen in het oog: namelijk dat uit dit onderzoek blijkt dat je er niet beter van wordt, maar ook niet slechter. Alle inspanningen en investeringen worden dus wel precies terugverdiend, maar meer ook niet. Daarmee lijkt invoering van een ERP systeem dus meer op een werkgelegenheidsproject. Het is dan de terechte vraag of je al die tijd, geld en energie niet in iets had kunnen stoppen dat een hoger rendement oplevert.

Het tweede element is dat een organisatie complex is. Een automatiseringsoplossing gaat daar eigenlijk per definitie aan voorbij. Het is een oplossing voor een aspect van de bedrijfsvoering waarbij het geheel van het organisme (de organisatie) niet genoeg in de gaten gehouden wordt. Als je, zoals Jos stelt aan zoiets begint terwijl je daarvoor nog nooit serieus naar je processen hebt gekeken, kan ik alleen maar concluderen dat Ad gelijk heeft: kijk eerst naar de verbeter mogelijkheden in je organisatie in plaats van achter een hype aan te rennen.

Ik onderschrijf in grote mate de visie van Jos Steynebrugh.
Ik heb zelf lange tijd meegewerkt aan een ERP-implementatie bij een high-tech industrie.
Wat zich daar afspeelde 'verzin je zelf niet', maar was wel heel leerzaam. De kosten-overschrijding ten opzichte van de allereerste start was in de orde van grootte van een factor 50, hetgeen echter meer zegt over de naieve manier van planning in het begin, dan over de kwaliteit van het projectmanagement.
Deze industrie slaagde er uiteindelijk wel in om het systeem technisch te implementeren, maar het resultaat was bedroevend. Dat kwam voornamelijk door het [gelijktijdig] introduceren van een besturingsfilosofie van 'delegeren naar de werkvloer', terwijl de filosofie van het ERP-systeem geschreven was op MRP-2 (Materials Requirements Planning met doorlooptijd-berekening op basis van beschikbare capaciteiten), hetgeen juist een sterke top-down besturing vereist. Het resultaat was een peperduur ERP-systeem dat op obligate wijze gevoed werd door dozijnen Excel-spreadsheets vanuit de productie.
Deze observatie komt dus wel in de buurt van de visie van Ad de Beer, die stelt dat je beter eerst de processen kunt vereenvoudigen. Maar nog meer bij de visie van Jos Steynebrugh, die hier waarschijnlijk had geadviseerd om eerst eens diepgaand de consequenties van de nieuwe manier van productiebesturing te analyseren, vervolgens de reorganisatie door te voeren, daarna de verdere productieverbeteringen in de nieuwe constellatie door te voeren en dan pas de ERP-implementatie te onderzoeken.
Wellicht waren ze dan op een heel simpele basisvorm uitgekomen, verrijkt met features die werkelijk van belang zijn voor deze industrie.
Feitelijk mankeerde er weinig aan het ERP-systeem; er werd wel veel ophef gemaakt over functies die niet zouden passen, maar wezenlijk vertoonde het systeem 90% fit.
De meeste tijd- en kosten-overschrijdingen zaten niet in de technologie, maar in het eindeloze gepalaver in werkgroepen over de manier van werken. Het management was daar de grote afwezige, zodat groepjes 'key-users' en ICT'ers ongebreideld hun gang konden gaan. Het ontbrak het in de werkgroepen aan visie op de toekomstige manier van werken. Sterker nog, de key-users die bijeen kwamen konden voor het eerst in hun loopbaan diepgaand met elkaar over de diepere betekenis van hun werk praten.
Dat is in de praktijk wat we verstaan onder 'impact op de organisatie'.

Iedereen heeft een beetje gelijk en een beetje ongelijk...

Maar wat veel belangrijker is, is de reden waarom ERP-systemen duurder zijn en minder leveren. Maar al te vaak richt de implementatie zich op het vastleggen van gegevens en niet op het verkrijgen van output (lees: stuurinformatie). Veel gehoorde signalen uit mijn directe omgevingen (zowel Oracle E-Business Suite als SAP) hebben daarmee te maken. En vervolgens worden ingewikkelde en dure queries geschreven en/of gaat de Business zelf in Excel-achtige producten via een soort schaduwadministratie rapportages maken (die ook nog vaak onbetrouwbaar zijn).

Echter, de allerbelangrijkste reden voor de ontevredenheid over ERP-systemen zit hem in een krampachtige implementatie. De Business wil niet of nauwelijks de bestaande bedrijfsprocessen aanpassen aan de "best practices" van ERP. Nee, het ERP-pakket moet voldoen aan de uniciteit van de organisatie. "Wij zijn anders dan de rest van de wereld", is een veel gehoorde kreet binnen grote organisaties. En dat is toch vreemd als het gaat om financiële adminstraties (lees: boekhouden) ef personeelsadministratie. Hierdoor wordt (te) veel afgeweken van de standaardwerking van een ERP-systeem. En heel krampachtig wordt een bijna-maatwerkpakket gebouwd, dat men wel gewoon ERP blijft noemen. Ook zie jeveel deel-implementaties, waardoor een aantal oude traditionele systemen in stand blijft met alle interface-problematiek vandien. En ook die exploitatielasten worden op het negatieve conto van het ERP-systeem geschreven.

Ik zeg het altijd zéér kort door de bocht: géén 5-sterren businessplan? Forget it!!! No ERP today.
Uit het per product/markt combinatie doorgestoken (!!!) businessplan komen de eerste afkaderingen voor een ERP (of iets simpelers).

Daarna licht je de bedrijfsprocessen door tot op het merg en past die aan zodat ze de gewenste output naar de klant grondig maar flexibel afdekken.

Dan moet je je verdienmodel opstellen. Grof gezegd: elke pepernoot die eraan gespendeerd wordt moet met profit worden teruggehaald. Een ERP is niets anders dan een profit center. Budget neutraal is dus NIET goed genoeg.

Meten is (z)weten
Om te kunnen registreren moet je meten. Meten kost tijd, geld en capaciteit en bij overdaad een mega ergernis, vaak gevolgd door dociel uitvoeren of sabotage. Er wordt alleen gemeten aan dingen waarop je invloed hebt of minstens op kan anticiperen. Elk kengetal waarvan van de betekenis niet UNANIEM consensus bestaat, wordt gedumpt. Dus ook niet geregistreerd.

Maar het verhaal begint bij een zéér goed businessplan (minstens een 8). Weliswaar zijn op details alle bedrijven uniek (nou even niet overdrijven), maar ze hebben altijd en eeuwig steeds één ding gemeenschappelijk: gaan allemaal op dezelfde manier failliet. ERPtensoep?.

Groet,
Jos Steynebrugh
Marketing & Innovatie Consulent

Dit resultaat komt voort uit het feit dat de klant vaak niet weet wat hij nodig heeft. Vaak ontbreekt er een duidelijk doel. En dat doel mag inderdaad niet zijn het puur vervangen van IT Systemen. Het kan wel een noodzakelijke conditie zijn voor benodigde veranderingen binnen de organisatie, maar nooit het doel.
Ik ben van mening dat het doel van een onderneming het genereren van geld is nu en vooral in de toekomst. Dus, een ERP Project moet erop gericht zijn om geld te genereren. Echter, de mogelijkheid om geld te genereren wordt beperkt door bestaande belemmeringen in de bedrijfsvoering. Dus, de meerwaarde van het ERP Systeem moet komen uit het feit dat het beperkingen opheft. Echter, om meerwaarde te realiseren, een bottom-line resultaat, is technologie noodzakelijk, maar niet voldoende. Immers, de grootste belemmeringen om de prestatie van de onderneming te verhogen en dus geld te genereren, zijn regels en procedures. Deze komen vaak voort uit huidige paradigma's. Eén van de grootste paradigma's is die van de kosten orientatie en de daarmee gemoeide locale efficienty syndroom. Alle onderdelen moeten efficient verlopen volgens dit paradigma. Maar, is dat wel noodzakelijk. Een bedrijfsketen is als een ketting en de sterkte van die ketting wordt bepaald door de sterkte van de zwakste schakel. Dus, alle andere schakels hebben een grotere sterkte, oftwel overcapaciteit. Dit is het eerste type belemmering waarmee bedrijven te maken hebben; fysieke belemmeringen. De belangrijkste les hiervoor is wat Deming ons trachtte duidelijk te maken en wel dat 'optimaliseren tot op ruisniveau niet alleen zinloos is, maar zelfs schadelijk. Zolang het systeem oscilleert binnen de grenzen van de ruis, zal elke vorm van ingrijpen de fluctuaties aleen maar groter maken'. Binnen de supply chain conflicteerd dit statement bijvoorbeeld met de insteek en filosofie van MRPII, hetgeen erop gericht is om alle lokale entiteiten zo optimaal te benutten, waardoor ruis een geweldige impact heeft op de planning en executie. Met als gevolg, inderdaad een onnoemelijke hoeveelheid excel spreadsheets om het allemaal weer recht te breien.
Een project moet dus gericht zijn op de zwakke schakels en niet op alle schakels. Dit kostenparadigma leidt er ook vaak toe dat ERP Projecten niet goed gescreend en geprioritiseerd worden en veelal gericht zijn op teveel schakels in de gehele keten. Het gevolg is een te brede scope, complexiteit en teveel "configuratie" en "features".
Met betrekking tot ERP Systemen, is het helaas ook nog eens zo, dat bedrijven één op één hun oude manier van werken overzetten op het nieuwe systeem. Mijn ervaring is dat dit dus niet leidt tot optimale bedrijfsprocessen. Men moet hierbij inderdaad best practice bedrijfsprocessen overnemen indien dit geen impact heeft op de competitive advantage en daar aanpassen waar nodig. Een van de belangrijkste reden voor het één op één overnemen van bestaande methodes en werkwijzen is het feit dat er in het verleden hiermee work-arounds zijn gevonden voor toen bestaande belemmeringen. Deze belemmeringen worden vaak veroorzaakt door bestaande regels en procedures. Dit is het tweede type belemmering. Dus, indien een project succesvol wilt zijn en de onderneming er profijt van kan hebben, moet er ook gekeken worden naar alle regels en procedures en indien nodig aangepast en/of zelfs verwijderd worden. En dit gebeurt dus vaak niet, met alle nare gevolgen van dien.
Indien dan ook nog niet de goede medewerkers op een project worden gezet en/of dat de meest capabele medewerkers slechts part-time worden ingezet, dan kan men er gif op innemen dat projecten ook nog eens niet op tijd en boven budget worden opgeleverd. Dit heeft te maken met het feit dat mensen die op projecten werken niet aan multi-tasking moeten doen, omdat het gevolg hiervan is dat men alle taken uitsmeert en dus de totale doorlooptijd toeneemt.
Een project kan dan ook alleen maar succesvol uitgevoerd worden, indien de juiste mensen op de juiste manier gepland en ingezet worden. Anders, krijgt men altijd te maken met overschrijdingen in tijd en geld.