een beknopte plaatsbepaling
Pieter Wisse
Wat is infrastructuur? In dit geval, wat is infrastructuur voor geautomatiseerde informatievoorziening? Een redelijk, begrijpelijk antwoord op deze vraag is belangrijk om optimaal mogelijkheden van automatisering te benutten en beperkingen ervan te vermijden.
Iedere vergelijking is gevaarlijk. Maar zolang de aandacht op hoofdlijnen gericht blijft, kan de voorstelling van een bekend verschijnsel licht werpen op wat voorheen nog ònbekend was.
Neem het verschijnsel: verkeer. Wie is daarmee niet vertrouwd? En stel dat er een unieke behoefte bestaat om bepaalde goederen niet op lokatie a, maar in plaats daarvan op lokatie b beschikbaar te hebben. Wie die behoefte éénmalig heeft, kan speciaal dáárvoor verkeer inrichten. Dat wil zeggen, er moet een vervoermiddel komen. En een weg moet aangelegd worden (of slechts gebaand?) waarover het vervoermiddel bewogen kan worden. Voorts zijn op a en b los-, respectievelijk laadmiddelen nodig. Wie de behoefte nijpend ervaart, heeft er al die moeite voor over. Daar zijn voorbeelden genoeg van.
Voor zo'n unieke behoefte is het niet zinvol om de gezamelijke verkeersmiddelen infrastructuur te noemen. De hulpmiddelen worden eenmalig gebruik, vèrbruikt dus, en daarmee is de kous af.
Een zinvol begrip 'infrastructuur' komt in beeld zodra hulpmiddelen hèrgebruikt kunnen worden. Misschien is de bestemming een volgende keer niet b, maar c. Desondanks zouden weleens dezelfde laadmiddelen en hetzelfde vervoermiddel toepasbaar kunnen zijn. Wat nog ontbreekt, zijn dan de weg tussen a en c alsmede de middelen om de lading op c te lossen.
Naarmate dezelfde voorzieningen steeds weer ingezet kunnen worden, is er zinvoller sprake van infrastructuur. Op enig moment bestaat infrastructuur (dus) uit de voorzieningen voor verkeer die op dàt moment a priori beschikbaar zijn. Bijvoorbeeld, een brug betekent dat voor een auto met zeker gewicht en zekere maten een voorheen bestaande hindernis (water, kloof of iets dergelijks) opgehouden heeft te bestaan.
De paragraaf hierboven maakt duidelijk dat infrastructuur altijd tussenstand binnen een ontwikkeling van voorzieningen/hulpmiddelen is. Wat voor verkeer nog niet a priori aanwezig is, moet per definitie aangevuld worden. Wat als aanvulling geldt, blijkt nu sterk afhankelijk van het gezichtspunt.
Het individu dat met zijn auto van a naar b wil reizen, zal ongetwijfeld wegen, stoplichten enzovoort als infrastructuur voor verkeer erkennen. Het is de vraag of hij zijn 'eigen' voertuig ook daartoe rekent. Waarschijnlijk niet. Als hij met de trein reist, luidt zijn antwoord alweer ànders. Daar hoort meteen bij dat eigenschappen van de trein-als-infrastructuur als beperkingen ervaren worden.
De burger hecht aan 'zijn' auto. De planoloog heeft een wat andere kijk, tenminste als hij verkeer in het algemeen beschouwt. Zijn aandacht gaat uit naar voorzieningen voor mobiliteit. In die visie verschijnen nu ook de particuliere auto's als behorend tot infrastructuur. Het is een kwestie van beschouwingsniveau. Wat door allerlei individuen als variaties tussen merken en typen auto's opgevat wordt, beweegt zich voor de planoloog immer tussen strakke grenzen van vooral maten en gewichten zodat de auto-als-infrastructuur op andere onderdelen van de infrastructuur (zoals wegen, bruggen enzovoort) afgestemd blijft.
Het is tijd met het voorbeeld van verkeer op te houden, althans als een expliciete verwijzing. Zoals iedere, gaat ook deze vergelijking èrgens mank lopen.
Wat de vergelijking hopelijk blijvend meedeelt, is (1) dat infrastructuur een dynamisch begrip is en (2) dat overeenstemming over de inhoud van infrastructuur weleens moeilijk is omdat er evenzovele gezichtspunten kunnen zijn als er betrokken partijen zijn. Dergelijke algemene conclusies gelden eveneens voor het bijzondere geval van infrastructuur voor geautomatiseerde informatievoorziening.
Een gebruiker stelt zijn particuliere behoeften vóórop. Hieruit volgt dat hij in eerste aanleg nauwelijks 'infrastructuur' ziet. Hij herkent vooral bijzondere hulpmiddelen die 'zijn' behoeften vervullen.
Verkeerd hoeft zo'n houding beslist niet te zijn. Als zijn behoefte inderdaad bijzonder is en/of er is geld genoeg om aparte voorzieningen te treffen, waarom zou er dan een (gemeenschappelijke) infrastructuur moeten zijn?
Anders ligt de zaak wanneer diverse gebruikers elkaar met hun bijzondere voorzieningen in de wielen rijden. De lage autobrug belemmert scheepvaart. En dan is er altijd het feit dat geld slechts één maal uitgegeven kan worden. Door schaarste zijn gebruikers eveneens op elkaar aangewezen, hoewel zij dat niet altijd (willen) beseffen.
Iemand die coördineert neigt vaak tot een omgekeerde benadering. Dan moet infrastructuur zovéél mogelijk voorzieningen omvatten. En natuurlijk botst hij met zo'n opvatting met gebruikers indien hun behoeften inderdaad bijzonder blijken.
De verstandige coördinator probeert op de hoogte te geraken èn te blijven van de behoeften van àlle gebruikers waarvoor hij meent dat een (gemeenschappelijke) infrastructuur zinvol is. Het is het probleem van de coördinator, en niet van de diverse gebruikers, dat betrokken partijen verschillend over de inhoud van infrastructuur (kunnen) denken. Daarom moet de coördinator vóórlichten, moet aangeven waar reeds aanwezige voorzieningen een gebruiker helpen zijn behoefte te vervullen. En dit laatste dan eenvoudiger, sneller, goedkoper enzovoort. Infrastructuur moet per saldo toegevoegde waarde voor iedere gebruiker hebben. Het gaat om het saldo zodat alle gebruikers eventuele nadelen accepteren; er staan immers grotere voordelen tegenover.
Vele coördinatoren handelen niet verstandig wanneer zij in strijd met hierboven afgeleide conclusies over (de aard van) infrastructuur handelen. Zij ontkennen vaak dat infrastructuur steeds ontwikkelt. In plaats daarvan gaan zij uit van maximale inhoud die zij volgens de stand der techniek mogelijk achten. Het probleem daarmee is niet eens zozeer dat hun ontwerp weleens niet uitvoerbaar zou kunnen zijn, maar dat gebruikers er niets van snappen. Vele coördinatoren ontkennen dus, en dat is dan de tweede grote fout, dat zijzèlf verantwoordelijk zijn om het verschil in opvattingen over infrastructuur te overbruggen. Dat lukt niet met een eenzijdig voorstel en mobilisatie van hiërarchische steun. De wèrkelijke steun komt altijd van gebruikers die hùn belangen reëel erkend zien. Dat is immers de bedoeling van infrastructuur.
De enige manier om realisatie van infrastructuur vooruit te laten lopen op acceptatie ervan door gebruikers, is onafhankelijke financiering. Een visionaire chef wil zo'n weg weleens bewandelen. Een gemachtigd coördinator mag hiervan echter niet afleiden dat contacten met gebruikers overbodig geworden zijn. Integendeel. Als infrastructuur aangelegd wordt om daadwerkelijk te gebruiken, zijn en blijven het de gebruikers waarom het gaat.
De verstandige coördinator definieert een infrastructuur als dynamisch. Hij probeert dan met de (stand van de) infrastructuur steeds voorzieningen aan te bieden die invariant zijn ten opzichte van de eventuele aanvullingen van gebruikers. In gewoon nederlands betekent dit dat een gebruiker (1) enkele voorzieningen kant-en-klaar aantreft, (2) van voorzieningen die hij niet gebruikt ook geen last heeft en (3) minimale inspanningen aan zijn bijzondere, aanvullende voorzieningen behoeft te besteden. Vooral het tweede punt moet de coördinator erop attent maken met infrastructuur niet dóór te schieten.
Afhankelijk van de behoefte van een gebruiker heeft de aanwezige infrastructuur hem nog niets te bieden of juist àlles, maar waarschijnlijk iets ertussenin. Naarmate de infrastructuur zich gunstig ontwikkelt verschuiven de mogelijkheden voor de gebruiker zich van helemaal niets naar alles. Erdoorheen (tegenin?) speelt uiteraard de ontwikkeling van de behoeften van de gebruiker. Wie méér wil, vindt niet langer alles kant-en-klaar aanwezig.
Twee voorbeelden kunnen het begrip invariantie toelichten. In de eerste plaats, stel dat er behoefte bestaat om een bijzondere berekening door een centraal opgestelde computer te laten maken. Er is een beeldschermstation en verbinding met die computer. Deze behoefte is invariant ten opzichte van de aanwezige infrastructuur, maar inspanningen voor aanvullende voorzieningen (nota bene het rekenprogramma) kunnen aanzienlijk zijn. Stel ten tweede dat een medewerker automatiseringsmiddelen voor tekstverwerking en electronsche post wil gaan gebruiken. Hij beschikt reeds over de benodigde computer met aansluiting op een netwerk. Zijn behoefte is evenzo invariant als de behoefte uit het eerste voorbeeld. Het verschil zit 'm in de inspanningen die nodig zijn om het effect te bereiken. Invariantie zegt niet dat geen aanvullingen nodig zijn, maar wèl dat ze gelet op de stand van de infrastructuur onvermijdelijk en minimaal (derde punt van invariantie) zijn en dat (tweede punt van invariantie) infrastructuur tenminste niet contra-produktief is. In het gunstigste geval blijft, zoals gezegd, een gebruiker met het aanbod uit de infrastructuur niets te wensen over. In jargon wil dit zeggen dat hij blijkbaar niets dan (enkele) basisdiensten gebruikt. De dynamische kijk op infrastructuur wijst erop dat steeds uitgebreid kan worden wat dergelijke basisdiensten zijn. Nu gaat het om tekstverwerking, electronische post, programmatuur voor zgn. spread-sheets en dergelijke. Als de berekening uit het eerste voorbeeld in een spread-sheet past is er de situatie dat de behoefte eveneens geheel door reeds aanwezige infrastructuur gedekt is.
Een begin van infrastructuur blijkt vaak achteraf benoembaar. Dat is een begin om èrgens in lokale behoeften te voorzien. In een later stadium van ontwikkeling draait de oriëntatie om. In plaats van een agglomeraat van afzonderlijk gegroeide voorzieningen wordt infrastructuur qua opzet eerst gecoördineerd en ontworpen en pas vervolgens gerealiseerd.
Omdat het begrip infrastructuur meestal ná zo'n heroriëntatie ter spake komt, wordt het geassocieerd met centralisatie. Het woord coördinatie zegt het reeds; een volwassen infrastructuur heeft centralistische trekjes. Dat is onvermijdelijk omdat belangen van diverse gebruikers afgewogen (moeten) zijn. Centralisatie vermindert wanneer de gebruikers zèlf de afwegingen maken of tenminste erover beslissen. Dit is soms moeilijk te realiseren omdat gebruikers denken dat infrastructuur een 'technisch' onderwerp is en dat zij 'het' beter aan specialisten kunnen overlaten. Dat is een drogreden. Hun eigen belang loopt gevaar als zij afzijdig blijven. In zoverre is het nodig dat gebruikers op de hoogte zijn van de basisfouten die coördinatoren met infrastructuur kunnen begaan. Zij moeten er terdege op letten dat infrastructuur op hùn eigen (ontwikkelende) behoeften afgestemd is en blijft. Dat is evenwicht, te weten het resultaat van àlle nodige inbreng.
Er dreigt nog een derde fout die coördinatoren dikwijls maken. Zij menen dat een infrastructuur slechts aangelegd behoeft te worden. Daarmee zou alles klaar zijn. Ook nu is niets minder waar. Aanleggen is één, functioneren is twee.
Gebruikers ondervinden pas toegevoegde waarde van een infrastructuur als het functionerende voorzieningen zijn. Er is onderhoud, beheer nodig om infrastructuur functionerend te houden.
Geheel in lijn met centralistische ideeën over infrastructuur geven vele coördinatoren de voorkeur aan een centrale beheerorganisatie. Dáár kan de nodige expertise gewaarborgd zijn, is de redenering. Welnu, dat is een beetje waar. Maar óók waar is dat gebruikers vervreemd raken van helpers die er misschien wel zijn, maar die niemand weet te vinden en die evenmin zèlf op hun 'rondjes' gebruikers opzoeken. Evenwichtig beheer betekent voor ieder onderdeel van infrastructuur een aangepaste keuze tussen noodzakelijke expertise en optimale contactmogelijkheid met gebruikers. Voor vele, zo niet de meeste onderdelen van infrastructuur geldt dan dat beheerders/helpers niet centraal, maar juist decentraal opgesteld moeten zijn. Interessant is dat belangrijke decentralisatie van beheer absoluut niet inhoudt dat er méér medewerkers voor nodig zijn. Want zoals overal geldt ook voor geautomatiseerde informatievoorziening dat oplossing het minste werk vergt wanneer het probleem zo vroeg mogelijk gesignaleerd is. Zelfs vele problemen kunnen überhaupt vermeden worden met preventieve aandacht, en dat is aandacht op de plek waar problemen eventueel zouden kunnen optreden. Voor problemen die gebruikers veroorzaken is die plek dus .... bij de gebruikers.
Een voordeel van decentrale beheerders is voorts dat dynamiek van infrastructuur tot gelding kan komen. De gebruiker die 'zijn' beheerder vertrouwd, laat zich door hem voorlichten èn, omgekeerd, deelt hem eerder mee hoe hij over informatievoorziening van a tot z denkt. Dit laatste is onmisbare informatie voor coördinatie. De enige nuttige plaats van infrastructuur bestaat er immers uit in reële behoeften van gebruikers te voorzien.
© januari 1992, webeditie 2002.