blog

ERP maakt bureaucratisch (3)

Supply chain

Is het mogelijk ERP ook vanuit een ander perspectief te benaderen? Dat is eenvoudiger dan het bovenstaande lijkt te vermoeden, omdat ERP over een hoge mate van instelflexibiliteit beschikt (d.w.z.: meerdere situaties kunnen erin ondergebracht worden).

Belangrijk daarvoor is oog te hebben voor de variëteit in de organisatie en meer bepaald hoe daarmee – nu en in de toekomst – om te gaan [1,6]. Variëteit bevindt zich bijvoorbeeld in de product-, dienst-, klant-  en/of marktportfolio, in de levenscyclus van producten en diensten, in de processtappen, in de kwantiteit en kwaliteit van de output, in de voorspelbaarheid van de markt, in de besturing, in de keten en in het doel van een organisatie.

 

Anders omgaan met variëteit in een organisatie komt neer op de vraag: ‘wat moet vanuit bestuurlijk oogpunt samengevoegd zijn?’. Waarom is dat belangrijk? Indien men ‘alles’ onder één noemer brengt, krijgt men weliswaar één ERP-instelling maar die is wel uiterst complex. En wel, omdat alles van elkaar afhankelijk gemaakt is, ook datgene wat feitelijk niets met elkaar van doen heeft. Deze onnodige, zelf gecreëerde afhankelijkheden dienen vermeden te worden. Een voorbeeld uit de meubelindustrie kan dit verduidelijken.

 

Zelf gecreëerde afhankelijkheid: voorbeeld

De ERP-implementatie van een divisie, die voor een bepaalde groep klanten op voorraad produceerde, gold als referentie voor een andere divisie, die voor een bepaalde groep klanten op order produceerde. Waarom zouden ze twee verschillende implementaties doorvoeren als het maken en verkopen van meubels in grote lijnen tóch overeenkomt? En, zo geschiedde. Resultaat was dat beide divisies geconfronteerd werden met een onbevredigde situatie. De order-divisie kon niet uit de voeten met de instellingen van de voorraad-divisie, en de gewenste aanpassingen van de order-divisie kwam de voorraad-divisie weer niet uit. De wederzijdse aanpassingen luidde een zelf gecreëerde beheercyclus in: aanpassingen bij de ene veroorzaakten aanpassingen bij de andere, enzovoort. Dit voorbeeld laat zien, dat men zich niet moet laten (ver-)leiden door de technologische standaardisatiemogelijk­heden van ERP; dat wil zeggen ‘alles’ onder één complexe ERP-noemer samen te voegen omdat het technisch mogelijk is. Dit leidt doorgaans tot ongewenste situaties.

 

Misvatting

Het bovenstaande voorbeeld laat zien dat techniek en besturing niet verward mogen worden. En daar ligt de kern van de misvatting die de ERP-praktijk bepaald. Deze misvatting zit hem in de mening dat vergelijkbare – zelfs dezelfde – processtappen door middel van standaardiseren bestuurlijk bij elkaar te voegen zijn, en dus: bij elkaar horen. Dit is echter onjuist en kan dus niet de basis vormen voor het informatiseren en besturen van processen! Een eenvoudig voorbeeld kan dit verduidelijken. Indien de Koningin voor een nacht een hotelkamer zou willen huren, zal het proces anders bestuurd worden als dan wij dezelfde kamer zouden willen huren. In beide gevallen gaat het om betalende klanten die dezelfde product/dienst afnemen, en toch zal het proces anders bestuurd worden. Om de eenvoudige reden dat we hier te maken hebben met verschillende variëteiten (hier: omstandigheden, type klanten).

 

Hoe de alternatieve benadering toepassen?

Nu het kernprobleem beschreven is, is het tijd de in het begin geopperde vraag ‘in hoeverre is ‘tijdelijk herijken’ (‘timely adjustment’) met ERP-systemen mogelijk?’ te beantwoorden. Het uitgangspunt, de opdracht is duidelijk.

Er dient primair gefocust te worden op variëteit in plaats van op uniformiteit. De achterliggende gedachte is (1) dat alleen dezelfde variëteit, dezelfde besturing nodig heeft. En (2) dat alleen dezelfde variëteit, hetzelfde reageert op verandering (dynamiek). Om die reden moet alleen dezelfde variëteit bij elkaar gevoegd worden om het vermogen tot besturing en flexibiliteit te waarborgen.

 

Dit roept een meer algemene vraag op, namelijk hoe dit vorm te gegeven. Dit antwoord is niet in één algemene aanpak of oplossing te verwoorden. Waarom niet? Het antwoord hangt namelijk af van de concrete situatie, oftewel van de variëteit waarmee een specifieke organisatie geconfronteerd wordt en zal worden. (In het meubelvoorbeeld dus niet kiezen voor één generieke ERP-instelling, maar voor twee los van elkaar staande, specifieke ERP-instellingen met een overkoepelende managementfunctie voor de consolidatie [1].) In zijn algemeenheid kunnen strategische vragen gesteld worden die behulpzaam zijn bij de afweging. Onderstaand worden drie essentiële vragen besproken.

 

Enkele alternatieve ontwerpvragen

Hoe ver moeten we gaan met het standaardiseren van processen? Het antwoord daarop is: heel ver! Het standaardiseren van processen heeft vele voordelen; de meeste, zo niet alle, organisaties zijn ermee gebaat. Ten onrechte wordt echter gedacht dat ‘standaardiseren’ inhoudt dat er maar één standaard mag en kan zijn. Naast elkaar en in de tijd achter elkaar kunnen meerdere, andere standaarden gelden (denk aan ‘de Koningin huurt een hotelkamer’). Omdat deze standaarden betrekking hebben op dezelfde variëteit (bijv. klanttypes), is de kans dat erin veranderingen moeten worden doorgevoerd kleiner. En, als er veranderingen doorgevoerd moeten worden, is dat eenvoudiger omdat betreffende processtandaard meer op zich staan. Veelal wordt echter ten onrechte verondersteld dat standaardisatie behoort tot de wereld van routine (hetzelfde doen) en massa (veel). Niets is minder waar. Ook in incidentele gevallen is standaardisatie zeer belangrijk, denk maar eens aan rampenplannen. Zonder dergelijke – geoefende – plannen wordt het pas echt een ramp. Kortom: standaardisatie is goed, maar het nastreven van één standaard is onwenselijk.

 

Hoe ver moeten we gaan met ‘alles’ in één ERP-model af te beelden teneinde de organisatie te kunnen besturen? Het antwoord daarop is: heel ver! ERP-systemen worden onder meer gekozen omwille van de mogelijkheid managementinformatie te genereren. Ten onrechte wordt echter gedacht dat dit alleen kan als ‘alles’ in één centrale database aanwezig is; om vervolgens met ingewikkelde (complexe) autorisaties te zorgen dat gebruikers maar een beperkte toegang hebben. Men gaat ook hier voorbij waar het feitelijk om gaat, namelijk waarop moet, wil en kan ik sturen. Als men dat niet weet – hetgeen veelal het geval is – is het noodzakelijk alles in één data-bak te hebben om later in staat te zijn daaruit ‘iets’ te kunnen halen. En, dat blijkt niet eenvoudig, omdat men de bomen door het bos niet ziet en omdat men denkt dat verschillende variëteiten op dezelfde manier te besturen zijn. Citroenen zijn echter geen appels! Daarom moet eerst op basis van de aanwezige variëteiten gekeken worden wat er speelt, om deze vervolgens zo onafhankelijk als mogelijk in te richten en te besturen. Daarbij gaat het om het inzicht dat zaken die lokaal bestuurd kunnen worden, lokaal geïnformatiseerd moeten worden. Alleen de dingen die over het lokale heen gaan (de organisatie, dus) moeten in een centraal model ondergebracht worden, en dan nog zoveel mogelijk losgeweekt van andere zaken (zie vorige vraag). Kortom: processen samenvoegen in een informatiemodel is goed, maar alleen als processen bestuurlijk samenvoegbaar zijn.

 

Hoe ver moeten we gaan met infrastructuur? Het antwoord daarop is: heel ver! De antwoorden op de vorige twee vragen dienen uiteindelijk ook in een technische infrastructuur ondergebracht te worden. De voordelen die men kan behalen door dit in één infrastructuur te doen, moeten genomen worden; tenminste, zolang daarmee niet de antwoorden (uitgangspunten) op de vorige vragen ondermijnd worden. In de praktijk gebeurt niet zelden het omgekeerde; technologische afwegingen hebben een (te) grote invloed op de informatiseringsafwegingen. Uit het onderzoek van Govers [1] blijkt onder meer dat organisaties enthousiast beginnen met de “implementatie van ERP in hun organisatie” om uiteindelijk te eindigen met “de organisatie in ERP te implementeren” en daarmee dus hun specifieke omstandigheden te miskennen ten faveure van een technisch instrument dat tot doel heeft organisaties te ondersteunen. De reden voor deze ommekeer ligt veelal in de huidige ERP-benadering die alleen oog heeft voor “alles in één” in plaats van “zoveel mogelijk op zich”. Dit laatste heeft overigens niets van doen met meerdere infrastructuren; in één ERP kunnen meerdere onafhankelijke situaties vormgegeven worden. Kortom: de infrastructuur is volgend, niet leidend.

 

Afsluiting

 

Omgaan met variëteit is zowel cruciaal voor de implementatie als voor het beheer van een ERP-systeem. Zolang

men echter vanuit een technisch perspectief blijft vasthouden aan de uniformiteitsbenadering worden organisaties

als het ware bevroren met en door de gekozen ERP-instelling. De ERP-instelling is te complex en te afhankelijk

gemaakt om de consequenties van veranderingen te overzien, laat staan deze door te voeren; hetgeen een zware

hypotheek legt op de toekomstige besturing van de organisatie, te weten haar flexibiliteit.

 

Bij de alternatieve ERP-benadering is niet de mogelijkheid te uniformeren bepalend, maar de noodzaak te variëren. Het gaat niet om de vraag of men vanuit technisch oogpunt de informatisering kan, maar of men vanuit bestuurlijk oogpunt moet samenvoegen. Het antwoord van de huidige praktijk luidt overwegend: zo veel mogelijk samenvoegen omdat het technisch kan; het antwoord van de alternatieve benadering luidt: informatiekundig scheiden wat bestuurlijk gescheiden moet zijn. Voor de meeste organisaties zal dit meerdere kleinere, geïntegreerde informatiseringsmodellen betekenen (bijvoorbeeld: meerdere op zich staande ERP-instellingen dan wel -systemen). In dit verband kan erop gewezen worden dat een grotere organisatie feitelijk uit meerdere kleinere, geïntegreerde organisaties bestaan. Waarom deze organisatorische, bestuurlijke basis niet tot uitdrukking komt in de informatisering van dergelijke organisaties, is – hopelijk – ook voor u een interessante vraag (geworden). Immers, het gaat niet om de techniek maar om de besturing van de organisatie, zowel nu als in de toekomst. En, hoe meer de informatisering gericht is op de specifieke besturing hoe effectiever bestuurd en ingespeeld kan worden op veranderingen. Pas als men zich daarvan bewust is, wordt ‘timely adjustment’ ook met ERP mogelijk. De keuze is aan U!

 

Lees ook de andere delen:

Reageer op dit artikel