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.