September 1999: Architectuurdiscussie: ERP

Zie ook dit Word document

Veranderen is de tegenwoordige manier van leven. Vooral in de informatisering en de automatisering is dit de orde van de dag. In deze column wordt vanuit het zich vormende vakgebied rond informatie-architecturen ingegaan op aangedragen stellingen. De bedoeling is dat hierop gereageerd wordt, zodat discussies ontstaan over en rond informatisering en automatisering.

De eerste stelling in de reeks luidt:

Wanneer goed over architectuur nagedacht is, dan is de beruchte Enterprise Resource Planning (ERP)-inflexibiliteit (die onder meer verzonken ligt in de onoverzichtelijke en ingewikkelde parametrisering van bedrijfsprocessen en producten) geen probleem meer.

Allereerst een opmerking over de stelling zelf. Je zou eruit kunnen lezen dat, mits maar voldoende over (informatie-)architectuur nagedacht is, ERP-software toepasbaar is. Dit is wel erg kort door de bocht. Als we de steeds breder (en steeds vaker te breed en zelfs verkeerd) gebruikte term 'enterprise' negeren, dan hebben we het hier over 'resource planning'. Ofwel, het op de juiste plaats beschikbaar krijgen of hebben van resources, zoals personeel en materiaal. Je kunt dit breed interpreteren en stellen dat heel veel in organisaties (enterprises enzovoort) te maken heeft met resources, en dat ERP-software daar dus kan ondersteunen. ERP-software wordt dan wel haast synoniem voor het begrip standaardsoftware in het algemeen. Ik denk dat dit niet helemaal terecht is. Resource planning kan deel uitmaken van wat een organisatie doet, maar daarmee kan alles nog niet naar resource planning 'vertaald' worden. (Met als kennelijk doel het verkopen van ERP-software.) Het is immers maar de vraag of een organisatie zich wil aanpassen aan een manier van werken die met ERP-software ondersteund kan worden. En of dat kan wordt, onder meer, in een informatie-architectuur vastgesteld.

Een tweede opmerking naar aanleiding van de stelling gaat over het begrip architectuur. Er zijn vele architecturen. Je zou hier kunnen spreken over de architectuur van de informatie-infrastructuur. Die architectuur geeft een beeld van de ondersteuning die een organisatie krijgt van haar bestaande of toekomstige informatiehuishouding. De IT- of ICT-architectuur is daar een onderdeel van. Andere architecturen zijn fiscale, personele, communicatie-, logistieke, informatie-, economische enzovoort. Alle geven een beeld vanuit een bepaald gezichtspunt.

Gezien de strekking van de stelling zal in dit geval sprake zijn van informatie-architectuur. In het vervolg van dit betoog wordt daar vanuit gegaan.

Wat de stelling zegt, is dat, mits je maar goed uitzoekt hoe een organisatie werkt, ERP-software erbij zal passen, of passend gemaakt kan worden. Zo simpel is dit mijns inziens niet. Zeer bepalend is hier bijvoorbeeld de opzet van de ERP-software zelf.

Een organisatie is vaak gegroeid op basis van macht, inzet, kennis, gewoonte en dergelijke. ERP-software is gebouwd op basis van standaardmodellen. Het is te verwachten dat dit niet, of niet geheel, bij elkaar past. Als je dan de organisatie in lijn met het model van de software gaat aanpassen, is het de vraag of de organisatie op die manier wil of kan werken. En als de werkwijze van de organisatie gelijk gehouden wordt, dan is het maar de vraag of je de ERP-software voldoende kunt aanpassen (het aantal softwarewijzigingen is soms enkele tientallen, maar er zijn ook gevallen van (veel) meer dan duizend bekend). En als het veel wijzigingen zijn, hoe krijg je die dan doorgevoerd in nieuwe versies van die ERP-software?

Met architecturen kunnen gedegen, goed onderbouwde beslissingen genomen worden ten aanzien van de inzet van ERP-software. Zo kan bijvoorbeeld orde geschapen worden in het vaak schijnbaar onontwarbare kluwen van tienduizenden producten in een geparametriseerde productdatabase. Je kunt ook zien hoe de ERP-software past bij de organisatie. Ook kun je zien wat de gevolgen zijn van het instellen van de ERP-parameters. Daarmee wordt een en ander inzichtelijk, maar of het daarmee gemakkelijker wordt, is zeer de vraag. Je kunt immers, generaliserend, niet zeggen dat met het weten hoe het zou moeten werken, de softwareparameters die deze werking veroorzaken, ook bestaan.

Wat een architectuur kan doen, is onderkennen hoe het werk in een organisatie uitgevoerd wordt. En welke ondersteuning daarbij past. Bovendien is bekend welke eisen, wensen, uitgangspunten en randvoorwaarden er gesteld worden. De stelling 'wanneer goed over architectuur nagedacht is, dan is de beruchte ERP-inflexibiliteit geen probleem' is daarmee niet juist. Je kent het probleem en kunt er misschien beter iets aan doen, maar daarmee is het probleem nog niet uit de wereld.

Er bestaat een tendens waarbij ERP-software op een steeds hoger niveau 'geparameteriseerd' wordt. Er zijn gedachten om een soort upper-CASE-hulpmiddel in te zetten om ERP-software al of niet volledig te genereren. Natuurlijk wordt daarmee de kans dat passende ERP-software ontstaat groter. En die kans zal nog groter worden als we steeds minder rekening hoeven te houden met binnen deze generatoren voorgedefinieerde modellen.

We bereiken hier echter snel de grens van wat we nog ERP mogen noemen. Optimaal passend zou zijn als er in het geheel geen modellen meer in die generatoren gehanteerd hoeven te worden. Maar dan verliezen we wel het principe van resource planning. De verschillen met de algemene upper-CASE-hulpmiddelen, zoals we die de laatste 10 à 15 jaar kennen, vallen immers weg. We komen dan weer in de buurt van brede conceptuele modellen. En op zich zouden deze modellen uit een informatie-architectuur afgeleid kunnen worden. Maar gezien de problemen met dit soort hulpmiddelen is het de vraag of hier een oplossing, of juist een nieuw probleem ontstaat.

We bereiken hier echter snel de grens van wat we nog ERP mogen noemen. Optimaal passend zou zijn als er in het geheel geen modellen meer in die generatoren gehanteerd hoeven te worden. Maar dan verliezen we wel het principe van resource planning. De verschillen met de algemene upper-CASE-hulpmiddelen, zoals we die de laatste 10 à 15 jaar kennen, vallen immers weg. We komen dan weer in de buurt van brede conceptuele modellen. En op zich zouden deze modellen uit een informatie-architectuur afgeleid kunnen worden. Maar gezien de problemen met dit soort hulpmiddelen is het de vraag of hier een oplossing, of juist een nieuw probleem ontstaat.