Processen worden steeds complexer door uitbesteding, globalisering, verdienstelijking van producten en steeds kortere productlevenscycli. Het wordt steeds moeilijker al die processen in toeleveringsnetwerken naadloos op elkaar af te stemmen; perfect planning prevents poor performance. Daarom investeren organisaties in ERP-systemen, die beloven de planning en besturing van die processen te verbeteren. Helaas, vaak zonder resultaat. Waarom falen ERP systemen bij het plannen en besturen van processen?
Samenwerkingsverbanden, nauwe contacten met toeleveranciers, dienstverleners, afnemers en fabrieken die voor de hele wereld produceren zijn aan de orde van de dag. Bedrijven besteden niet-kernactiviteiten als ICT, call centers, administratieve processen, logistiek en soms zelfs productie, uit aa...
Hieraan wil ik nog een aspect toevoegen, waarschijnlijk de oorzaak van alle problemen. Projecten die ERP invoeren maken ook de nodige slachtoffers. Free Record Shop moest een enorm bedrag afschrijven, andere bedrijven zijn er zelfs aan failliet gegaan. Ook een groot ERP project bij het Ministerie van Defensie schijnt te maken te hebben met enorme overschrijdingen van tijd en geld, terwijl het resultaat maar niet binnen bereik lijkt te komen.
Waar ligt dit – en bovengenoemde problemen - aan? Ik denk dat in het bovenstaande stuk in een simpel zinnetje al duidelijk gemaakt is waar het probleem zit: “En, ICT moet dat ondersteunen.” En dus niet sturen!
Veel projecten in deze sector zijn ICT gedreven. Er wordt uitsluitend gefocust op de software. Er wordt onvoldoende nagedacht over hetgeen een organisatie wil bereiken met de (invoering van) de software. En daarmee wordt het middel ICT – een van de middelen - tot doel verheven.
Als wordt gevraagd waarom SAP wordt ingevoerd, krijg je meestal als antwoord niet meer dan: “dat is een standaard” of “dat doen onze concurrenten ook” of “kostenbesparing”. Zelden is er een uitspraak over wat men nu echt wil verbeteren.
En dan wordt er een project manager geworven. Alleen al aan de titel kun je zien dat het project gaat mislukken. “Gezocht: een SAP project manager”. Wederom wordt het middel tot doel verheven. Voor dit soort projecten heb je een project manager nodig die begrijpt welke processen je wilt verbeteren, geen techneut. Iemand die, ongeacht het middel, het doel voor ogen houdt.
Enige tijd geleden heeft een VP van SAP in een interview gezegd dat zoveel SAP implementaties mislukken: Coca Cola, Free Record Shop, etcetcetc. Volgens haar was de reden dat de gebruikers te weinig betrokkenheid tonen. Tja, wat wil je nou eigenlijk? Het is toch een ICT project? Dat laat je toch aan techneuten over? Het is een standaardpakket dat toch iedereen als standaardpakket invoert? Nadenken doen we pas als we dat inflexibele standaard framework zien. Maar dan is het te laat. Aanpassen is erg duur en bovendien zeggen de techneuten iedere keer dat het niet mogelijk is of erg moeilijk.
ERP implementaties zijn niet anders dan andere ICT projecten: ze zouden niet moeten bestaan! Er zouden alleen projecten moeten zijn met een goede zakelijke rechtvaardiging (waarin ICT een rol kan spelen). Geen rechtvaardiging op technische redenen of vanwege standaardisatie (tenzij dat wordt opgelegd natuurlijk).
Het doel moet voorop staan, niet het middel. Helaas hebben zeer veel organisaties dat nog lang niet door wanneer het gaat om projecten met een ICT component. Met zeer droevige gevolgen. Denk hierbij ook aan het UWV project dat verleden jaar werd gestopt en waarop bijna 90 miljoen werd afgeschreven. Geen ERP, maar wel een "ICT project". Ook een middel dat tot doel werd verheven.
Het bovenstaande artikel laat een groot aantal van deze droevige gevolgen zien binnen de ERP wereld.
ERP is gebaseerd op MRP, hetgeen 2 dingen doet: material explosion en lead-time offsetting. Met andere woorden: ERP berekent wat u moet produceren, en wanneer u eraan zou moeten beginnen - gegeven een vaste leadtime voor de verschillende operaties. Echter, capaciteiten en allerlei beperkingen worden niet meegenomen. Bovendien is een ERP traag en biedt het nauwelijks visuele ondersteuning - iets wat cruciaal is om goed te kunnen plannen.
Vandaar dat APS systemen steeds meer gebruikt worden in allerlei industrieen en andersoortige organisaties. Een APS systeem haalt meestal data uit het ERP, zoals orders, routes. En in het APS wordt het planningsproces ondersteund. Dus zowel ERP als APS hebben hun eigen plek in het functionele landschap.
De problemen komen meestal wanneer ERP leveranciers claimen dat ze APS functionaliteit kunnen bieden. Ik blijf deze situaties steeds weer tegenkomen, alhoewel er al veel mislukte projecten het gevolg zijn geweest van deze claim. En IT managers hebben vaak als primaire doel om alles met 1 ERP leverancier te realiseren, waarmee ze hun wereld wel erg sterk simplificeren.
Zodra we de IT gereedschappen gebruiken waar ze voor bedoeld en gebouwd zijn, voorspel ik een veel hogere succeskans voor projecten.
In algemene zin zou het goed zijn als we zouden weten te differentieren naar type markten en bedrijfsomgevingen. Zo kunnen we wegblijven van te generalistische meningen en uitspraken die voor iedereen en elk bedrijf geldig zou zijn.
Daarnaast zou het goed zijn als we ons meer richten op wat wel kan en werkt in plaats van op wat niet kan en niet werkt.
Situational awareness en sence and respond zijn dus de nieuwe termen. Geen idee wat het is, hoe het werkt, hoe ik eraan kom en hoe ik het implementeer in mijn bedrijfsvoering maar begrijp wel dat ik er als de kippen bij moet zijn want over een paar maanden loop ik wellicht al weer hopeloos achter.
Enerzijds is er de ICT leverancier die traditioneel denkt vanuit de de applicatie en niet vanuit de processen. Hierdoor onstaat geen consistent geheel maar een verzameling van losse functionaliteiten die met wat geluk wel consistente data oplevert. Mede debet hieraan is de angst om afscheid te nemen van bestaande systemen en door te bouwen op een architectuur die niet voorbereid is op de huidige eisen en wensen.
Anderzijds heeft de klant te hoge verwachtingen van het ERP systeem. De oplossing voor veel knelpunten wordt vertaald naar het inzetten van een stuk software waarmee het probleem KAN opgelost worden. Dat houdt niet automatisch in dat het probleem ZAL opgelost worden. Pas wanneer gebruikers voortvarend met de beschikbaar gestelde middelen aan de slag gaan, kan het doel bereikt worden. Zaken als veranderingsmanagement spelen dan ook een belangrijke, regelmatig onderschatte, rol bij een ICT implementatie.
En tot slot is daar het project management. Veelal wordt het operationeel project management uitgevoerd door een projectleider van de leverancier, die het geheel met een ICT bril op bekijkt en die gebaat is met een snelle uitvoering comform projectplan. Dan is het vaak lastig om te onderkennen dat zonder aanpassingen aan het projectplan veelal het doel niet bereikt zal worden. Het oorspronkelijke projectplan wordt daarmee het schild voor de projectleider om zich achter te verschuilen: een gevalletje "operatie geslaagd, patient overleden".
Wordt het operationeel project management uitgevoerd door een medewerker van de klant zelf, dan ontbreekt vaak inhoudelijke kennis omtrent de applicatie. In dat geval moet de projectleider gaan vertrouwen op secondanten die knelpunten en verbeterpunten tijdig moeten signaleren, waardoor het een stuk lastiger wordt om tijdig bij te sturen. Daarnaast heeft die persoon ook vaak te maken met een afweging van eigen belangen en project belangen; een afweging die niet makkelijk onafhankelijk is te maken. Wie de middelen heeft, zal ze ook (willen) gebruiken.
Het zou beter zijn wanneer eerst het doel wordt bepaald en er vervolgens vanuit de oplossing gedacht gaat worden. Voor zowel leverancier als klant is het goed om eens goed in de spiegel te kijken en te bepalen of zij zelf over zowel proces- als applicatiekennis beschikken. Is dat niet het geval, dan is het wellicht te overwegen om de operationele projectleiding bij een derde partij onder te brengen die wel deze kennis in huis heeft. Daarmee is er gelijk een mediator aanwezig die noch leverancier, noch klant vertegenwoordigd en daarmee vanuit het oogpunt van de doelstelling kan handelen.
Deze reactie is opzettelijk in lekentaal geschreven om mensen die geen kaas gegeten hebben van de complexe wereld van ICT en logistiek (maar er wel mee te maken hebben of erger nog: onderdeel van zijn) tòch mee te kunnen laten lezen.
De witte olifant en de grijze lemmingen
De meeste bedrijven gaan voor omzet. Bij een enkel bedrijf wordt hardop (hoofdstuk Visie in bizzplan) gezegd dat winst vóór omzet gaat. Da’s dapper, maar werkt niet in de praktijk.
Een simpele ABC analyse oude stijl (Pareto: 20% van de klanten die 80% van de omzet of winst leveren) is zó gemaakt. Daar zitten een paar grotere (babyfantjes) en een heleboel kleinere (Lemmingen) tussen. Maar ook periodiek terugkerende (wulp kraanvogels) of adhoc opdrachten (fladderaars). En nu ga je plannen. Dan stormt een verkoper naar binnen en legt met verhit gezicht de productiestraat stil: hij heeft een “witte olifant” (eenmalige, onvoorziene Mega opdracht). Nu moet de afweging worden gemaakt om een aantal trouwe klantjes deze keer niet op tijd te leveren omdat die dikke opdracht er tussen wordt geschoven. Hamvraag: wie heeft het lef om de beslissing te nemen om die Mega opdracht NIET te accepteren? Kijk, DAT bedoel ik.
Dat in een ziekenhuis de Röntgenfoto of MRI scan voor een patiënt op de operatietafel voorrang krijgt boven 50 mensen in de wachtkamer snapt iedereen. Toch?
Mohammed en de berg
Wie met leveranciers van het formaat “SAP” gaat praten merkt al spoedig dat daar over ZIJN branche héél veel expertise zit. Da’s logisch, als je wereldwijd al 500 implementaties met/zonder klantspecifiek maatwerk in JOUW branche hebt gedaan. Dan wéét je iets over die branche. Die kennis komt terecht in “verticale oplossingen”. Mooi. Maar nu wordt de klant voor een dilemma geplaatst: gaat hij zijn (natuurlijk héél bijzondere bedrijf met absoluut unieke (hahaha) processen aanpassen zodat “het lekker loopt” in SAP of . . . laat hij zich verleiden tot een knetterend dure klantspecifiek breiwerkje dat nog vele decennia voor trammelant en torenhoge kosten gaat opleveren bij elke versiewisseling?
De verkoper van SAP kan rustig op vakantie gaan: linksom of rechtsom zal hij gaan scoren. Hij hoeft alleen maar de voor- en nadelen te duiden en vooral geen opmerkingen maken waardoor hij aansprakelijk wordt voor de gevolgen. Hoeft ook niet: dit is een probleem voor de KLANT en niet voor de ERP leverancier.
Grof- en fijnplanning
We kennen binnen ERP (en andere planningssoftware) het probleem van de grof- en de fijnplanning. Grofplanning gebeurt meestal tegen oneindige capaciteit en als zodanig nu al van de tafel, want daar kun je geen productiestraat mee aansturen. Hoeft ook niet, want daarvoor is het niet gemaakt. Maar als je in de fijnplanning (gechargeerd voorbeeld) wil aangeven dat Jantje niet naast Pietje aan de band mag staan (Piet’s vrouw houdt het met Jan) dan is dat een probleem van een andere orde.
Domino-effect
Wat een ERP nou juist zo bijzonder maakt is de “horizontale integratie”. Anders gezegd: je probeert de wensen / prioriteiten van de toeleveranciers, je eigen bedrijf en die van de klant als keten te behandelen. Soms zelfs meerdere niveaus naar achteren of naar voren. Dat hierin zéér complexe afhankelijkheden optreden kan een kind begrijpen. Het effect van plannen of juist veranderingen daarin kan hele onvoorspelbare / ongewenste transienten (schakelverschijnselen) opleveren.
Kantelen?
Dan hebben we nog het probleem van de demand gestuurde planning. “De klant komt altijd van rechts” zei de CEO met een manische blik in de ogen op de kick-off voor dit boekjaar. Dat fragment bekijkt hij thuis nog wel 100 x stiekem. De medewerkers NIET, want die “weten wel beter”. “We gaan kantelen”, zo papagaaide hij naar het voorbeeld van de interimmer (adviseur). Ik heb altijd beelden van de Titanic bij deze kreet. Kan wel, maar moet je heel goed mee oppassen: meestal betekent het dat het glas uit het gebouw valt (ICT en processen waarmee dat niet zomaar gaat).
How to nail jelly to a tree?
De inmiddels wereldberoemde kreet uit de begintijd van de automatisering is nog altijd even spannend als toen. De ware aard van het probleem is van het type Traveling Salesman. Het is een probleemtype dat we anno 2009 slechts met grof computergeweld te lijf kunnen, met als pikant detail dat pas in de allerlaatste bewerking blijkt welke van de gevonden oplossingen de beste is. Anders gezegd: de oplossing convergeert niet. Het algoritme dat hiervoor bestaat en nog steeds niet echt verbeterd is. Ook niet nadat een Indiaase wijsneus 15 jaar geleden een shortcut vond, waardoor het probleem wèl convergeerde, en die meestal (!!!) wel werkt, maar echter nooit bewezen werd.
Samenvattend: er valt héél goed te leven met de ERP-tesoep. Maar verzuimen kennis op te bouwen en prio’s te aangeven is volgens een oud Japans gezegde “Disaster looking for place to happen”.
Groet en sterkte,
Jos Steyenebrugh
Marketing & Innovatie Consulent
www.changeenhancement.nl
van Bianca:
Het is van belang om meerdere planningsniveaus te onderscheiden. Planning op ERP niveau richt zich op effectiviteit, m.a.w. het juiste product op het juiste moment bij de juiste klant afleveren. Op het lagere niveau, b.v. binnen de muren van de fabriek, richt men zich op efficiency, kortom orders combineren of opsplitsen, rekening houden met omstellingen, reinigingen, contaminatie. Voor de informatievoorziening binnen die fabriek, en detailplanning, zijn dedicated systemen beschikbaar zoals Manufacturing Execution Systemen en APS. Laat ERP doen waar het goed in is, gebruik voor andere problemen andere systemen. ERP levert het master plan op, maar laat vervolgens een bepaalde marge over waarbinnen ruimte is voor een focus op efficiency. Zie ook mijn boek "MES Guide for Executives; Why and How to Select, Implement and Maintain a Manufacturing Execution System", voor een uitgebreidere toelichting op de grenzen van ERP.
Ik ben het met je eens met betrekking tot het falen van ERP systemen.
De vergelijking met de "bounded rationality" van de menselijke geest lijkt hier van toepassing. Systemen zijn zo intelligent als de menselijke mind van de specifiers en de builders. Als voor de menselijke mind het principe van de bounded rationality geldt heeft dit ook consequenties voor de mind van de specifiers en de builders. Waarschijnlijk botsen we daar nu tegen aan. Misschien dat een andere decompositie en recombinatie een uitweg biedt voor de beheersing. Maar eerst moet de vraag gesteld worden, kunnen we het uberhaupt beheersen en zo ja wat bereiken we daarmee in het totale na te streven concept.
Iemke
Latere versies van ERP waarbij op een hoger aggregatieniveau kan worden gepland zijn in mijn ervaring wel zinvol om capciteiten en niveau's aan te geven waarbinnen de uitvoerings planning ( JIT, KanBan, you name it) zich kan voltrekken. ERP blijft altijd een support systeem ter ondersteuning en aanvulling van en goed planning en voortgangsbewaking systeem. Ook heeft managment nog steeds de neiging via het ERP systeem meer in het HPS te zetten dan mogelijk is onder het motto "zet er druk op". Het werkt averechts.
Succes met de verdere discussie.
Henk Betlem
Integrale ERP systemen hebben geen toekomst meer als supplychain orchestrator. Netwerk ketens zullen logistiek aangestuurd worden door control towers. Deze control towers vormen het net waarin de afzonderlijk aangestuurde processen zullen worden omvat. EDI links zullen gelinkt worden aan de kleinschalige IT netwerken van de gedecentraliseerde en uitbestede processen.
Op dit moment zijn er 3 groepen industrietakken die deze control towers zouden kunnen managen. Dit zijn de grote IT bedrijven (bijv Oracle, Manhattan Associates, IBM), de consultants (Accenture, Capgemin) en grote 3PL's logistieke providers zoals DHL, K+N, Panalpina etc. Deze zullen concurreren om de control tower plaats te veroveren.
ERP systemen zullen alleen blijven om de financiele processen te integreren en te voldoen aan de steeds strenger worden Internal Control Systems.
Het is duidelijk dat ERP software beperkingen heeft als het gaat om plannen en best-of-breed voordelen biedt (als de ERP module niet voldoende ondersteuning biedt).
Je opmerking over ERP leveranciers in het algemeen is erg kort door de bocht omdat ik toevallig bij zo'n club werk die vanwege dit verhaal juist gekozen heeft voor een strategie op basis van een gecombineerde portfolio ERP / Best-of-breed.
Daarnaast spreek je over een mogelijke generatiekloof tussen de 'smarte' aanpak en wat ERP systemen kunnen. Die kloof bestaat zeker maar is bijna net zo groot als de kloof tussen al die mooie technologieen en datgene waar de gemiddelde organisatie nu mee bezig is.
Standaardisatie helpt, indien mogelijk, maar in onze huidige business omgeving waar hoge mate van flexibiliteit wordt gevraagd, is dit bijna onmogelijk.
Ik denk dat we steeds meer naar Event Management gaan, waarbij twee zaken een rol van betekenis spelen. 1: Infomatie beschikbaarheid, e2e visibilty en 2: Communikatie vaardigheden.
M vr gr Hans Mudde
Nog een leuke praktijk case over ERP systemen. Gistermiddag zat ik in het zonnetje te praten met een opleidingsmanager. We hadden het over budgetverantwoordelijkheid, verantwoordelijkheid en aansprakelijkheid. Binnen die opleidiingsinsteling heeft de primaire levensader voor de hele organisatie er 10 dagen 'uit gelegen'. Het intranet (met koppelingen naar allemaal andere applicaties) was hemeltegend traag en men kon niet vaststellen waar het probleem lag. De verantwoordelijk directeur (facilitair) mag nog steeds blijven zitten, na het leveren van een totale wanprestatie.
Nu over het ERP gedeelte. Begrotingen over inzet van docenten worden berekend in een apart planningsprogramma. Maar het ERP systeem doet dit op afdelingsniveau. Een simpel overzichtje kun je niet maken, omdat die functionaliteit niet beschikbaar is. Je draait een lijst uit, arceert je eigen docenten en gaat vervolgens in je mei vakantie met Excel je schaduw begroting maken. Dit doen 25 afdelingsmanagers. Kosten nog moeite worden gespaard......... Enorm ineffcient en volledig in lijn met jou artikel. De ERP systemen (SAP in dit geval) zijn helemaal niet ingericht op eindgebruikers. Alleen op het hoogste aggregatie niveau is er zinnige informatie uit te halen. De opleidingsmanager verzuchtte dat hier eens goed in begeleid moest worden, maar dat de sense of urgency ontbreekt.
Fijn weekend,
Richard Puyt
Iemand vroeg me de statement 'perfect planning prevents poor performance nog eens toe te lichten.... die komt van Niek Visarius, ex-Ricoh, Rockwell en Cisco.
De 5 P’s van elke supply chain manager moeten zijn: perfect preparation prevents poor performance. Dat zul je vaak als eerste horen van de logistici; wij hebben een betrouwbare vraagvoorspelling nodig en dan kunnen we de voorraad meteen verminderen. Maar, is dat echt zo? Plannen maken is nuttig en nodig. En dat gebeurt veel en vaak.
Toch komen die plannen maar zelden uit. De harde werkelijkheid is er een van grote onvoorspelbaarheid. Moeten we dan maar stoppen met plannen? Onzin, je moet toch op tijd je benodigde materialen en capaciteiten weten. Met name bottleneck capaciteiten en items met een 'long lead time' moet goede worden voorspeld. Als die een tijdje vooruit, tactisch, goede forecast (binnen een bandbreedte), dan heb je operationeel, op hele korte termijn, voldoende bewegingsruimte om de markt te volgen. Doe je dat niet, dan is je planningspolsstok te kort om nog snel op de meest actuele vraag van de markt te kunnen inspelen.
Ook kreeg ik leuk vragen binnen voor verdere uitwerking en discussie:
- Hoe kun je de hele productieketen plannen als je geen controle hebt over de uitbestede onderdelen?
- Hoe borg je flexibiliteit in je planning, als je alle marges eruit sloopt (uit zgn. kostenefficiency overweginging)?
- Waar is de 'rommelruimte' voor verkopers met ERP systemen (om toch die telefooncentrale te kunnen leveren).
- Wordt de term 'ijzeren voorraad' nog gebruikt of hoort deze term thuis in het bedrijfskunde museum?
- Welk ERP programma is succesvol geïmplementeerd (graag een wetenschappelijke referentie)?
- Wat is het alternatief voor een ERP systeem, als je er niet mee kan plannen (is dit een niche)?
- Plannen op basis historische data (forecasting) is onbetrouwbaar, welke wiskundige alternatieven zijn beschikbaar (game theory?)
- Wat is de impact van gemotiveerd en gekwalificeerd personeel tav samenwerking in de hele keten?
- Welke succesvolle opvolgers komen er aan (je noemt al een paar zaken, maar zijn er al cases)?
"Wat is de les? Voordat je kan optimaliseren moet je eerst registreren. Daarvoor is ERP nodig.
Door de complexiteit en grote reikwijdte van ERP systemen bestaat het gevaar dat het invoeren van de registratie zo lang duurt en zo duur wordt dat bedrijven niet aan optimalisatie toe komen."
De ervaringen die hierboven genoemd zijn kenden zij ook en daarom zijn hiervoor oplossingen verzonnen (APS en MES). Ik heb ervaring met zowel ERP, APS en MES oplossingen van SAP en andere leveranciers en kan vertellen dat de oplossingen van SAP vaak best of breed zijn. Deze oplossingen bieden alles wat in voorgaande reacties als tekortkomingen van ERP worden gezien:
- tactische en operationele planning (ISA95 level 3 en 2)
- CTM/CTP
- optimizers (operations research)
- event management/supply chain visibility
- detailed scheduling/ volgordeplanning (ook op basis van kleuren Walter)
- et cetera
Ditzelfde verhaal geldt ook voor andere "ERP leveranciers" als Oracle en Infor.
Voorgaande reacties en de clumn van Walter zelf zijn dus niet gebaseerd op feiten maar op "horen zeggen". Ik snap de reacties wel. Waarschijnlijk komen ze van mensen die wel logistieke kennis hebben, maar niet zijn betrokken bij de implementatie van de software. Ik begrijp dat dit frustreet.
Zo zijn we aanbeland bij de kern van het probleem.
Het probleem bij de implementatie van ERP zit in de implementatiepartner die geen logistieke of SCM kennis heeft. En ook vanuit de opdrachtgever wordt een dergelijk project vaak getrokken door de IT afdeling.
Dat is het echte probleem, en niet de kwaliteit van de software, want daar is niets mis mee.
Als je dat beseft is er niks aan de hand... mits je daarvoor bij de implementatie budget en tijd vrijhoudt om ook die oplosingen, de echt waarde opleveren, te realiseren.
De 'feiten' ervaar ik in mijn eigen organisatie dagelijks aan de lijve. In die organisatie was men dat vergeten en is er nu geen geld meer voor de echte optimalisatie.
Bedrijven met S&OP schakelen sneller. Zij zijn in staat om in een aantrekkende markt marktaandeel te vergroten door sneller op de actuele vraag te anticiperen. Toch lukt dat niet ieder bedrijf in de praktijk....
Lees erover op:
http://www.delaatstemeter.nl/checklisten/sales-operations-planning-de-vijf-domste-fouten/
En niet alle lokale optimalisatie, configuratie en features die alles complex en duur maken.
Het minste dat je kan verwachten is dat men grondige noties heeft van de business processen, hoe het in alle gebieden van de SUPPLY CHAIN reilt en zeilt.
Toen ik recent deelnam een een event, als bezoeker zonder meer , kreeg ik achteraf via mail een uitnodiging om te zien als ik eventueel een partnerschap wou overwegen. Wisten die meer dan ikzelf?.
Gezien het meer een marketingverhaal geworden is, is het geen zier beter dan de marketing voor detergenten of voedingsmiddelen die zorgen dat de was witter wordt of je gewoon gezonder wordt. ERP mag toch wat meer zijn dan business woorden over te nemen als leverancier, en toehoorders mogen zich niet zo om de tuin laten leiden.
Het moet eenvoudig zijn en gebruiksvriendelijk, akkoord, maar het moet ook de realiteit kunnen vatten, en welke business is echt eenvoudig? Want dan is het overbodig en kan iedereen het.
Alleen bij het vervullen van de aanhef, kan bij een goede Erp oplossing winst gehaald worden, er wordt echter heel wat aangeboden waarbij de vlag de lading niet dekt. Er is wat meer nodig dan cliché 's.
Hoe het wat betreft infrastructuur ook evolueert, ook de gebruikers moeten hun processen ook goed beheersen, anders helpen de beste toekomstige concepten ook niet. Onze oosterburen spraken vroeger van 'ein blechidioot' als het over een computer ging, laat er nu meer kunststof in zitten , het blijft geldig.