Pieter Wisse
Eind 1995 ging B.K. Brussaard met emeritaat. Ter gelegenheid daarvan verscheen onder aanvoering van oud-student H.R. Stol de bundel Organisatieverandering en informatie-architectuur. Wat hier volgt is mijn bijdrage.
Wat gebeurt er als een arts een patiënt helpt? Het blijkt dat hij1 genezing vooral bevordert met serieuze aandacht. Dat is dus zijn methode, tenminste een wezenlijk onderdeel ervan. De verantwoordelijke arts beseft echter dat hij voor zichzelf die methode als een spel speelt. De paradox luidt dat hij juist met dat spel zijn patient zo serieus mogelijk neemt. Want zodoende wordt uiteindelijk de patient beter, en dat is toch de bedoeling.
Het verschil met vele automatiseerders is opvallend. Dat heeft waarschijnlijk met jeugd te maken. Immers, de zogenaamde beroepen van informatica, informatiekunde en noem maar op zijn nog jong. Informatica bestaat circa dertig jaar. Van informatiekunde is pas zo'n vijftien jaar sprake. Met jeugd is kennelijk onlosmakelijk verbonden dat de bijbehorende specialisten voornamelijk met zichzelf bezig zijn. Zij nemen ter legitimatie hun eigen methode zo serieus. Dat wil zeggen, de methode is helaas nog een doel op zichzelf, in plaats van dat noodzakelijk middel in een spel. Deze valse oriëntatie gaat natuurlijk ten koste van aandacht voor hun opdrachtgevers en voor overige betrokkenen. Reële problemen met informatievoorziening raken door een vooropgezette oplossing(srichting) uit het zicht. Van welke methode danook als doel wordt niemand beter.
Of de vergelijking met de artspraktijk nog verder klopt of niet, doet er eigenlijk niet toe. Er zijn inderdaad ook vele slechte artsen. Waar het voor automatiseerders om gaat, is dat zij een volgend stadium van professionaliteit slechts via relativering van methoden kunnen bereiken. Dat is geen eenvoudige opgave, omdat juist specialisten hun beroeps- en levensopvatting zo nauw verweven. Wie kan over het bord voor zijn eigen kop heenkijken? Het is daarom waarschijnlijker dat pas een volgende generatie beroepsbeoefenaren speelser met methoden omgaat.
Onlangs toonden diverse informatici e.d. nogeens overduidelijk dat zij au fond vasthouden aan de absolute waarde van de methode. Nee, erger nog, verschillende personen maakten met hun afwijkende methoden ieder voor zich aanspraak op de grootste geldigheid. Dat gebeurde in het kader van een artikelenreeks in het tijdschrift Informatie. Het thema van de reeks luidde: methoden voor systeemontwikkeling. De reeks liep van eind 1993 tot in 1995. Zij was een vervolg op een serie artikelen die begin jaren tachtig in hetzelfde tijdschrift was verschenen.
Wat deden nogal wat auteurs in de nieuwe reeks? Zij verwezen naar het artikel 'De Methode Doet Het Niet'2 dat in 1982 van de hand van J.R. van Rees3 verscheen. Het was echter onthutsend om te merken dat uit de context van hun verwijzingen geen enkel begrip van dat oorspronkelijk artikel sprak. Zij hadden niet in de gaten dat Van Rees expliciet over ontwerpmethoden geschreven had. Door vermelding van de term methode ging de nuance van ontwerp ten opzichte van de overkoepelende ontwikkeling kennelijk verloren.
Het is zinloos die onbegrijpende auteurs met hun verwijzingen naar 'De Methode Doet Het Niet' gedetailleerd van repliek te dienen. Indirect deed Van Rees dat samen met mij in ons recente artikel 'Informatie-architect en Systeemaannemer: andere rol, andere methode.'4 Daarin pleiten wij ervoor om tijdens veranderingen, gericht op informatievoorziening in complexe organisaties en processen, onderscheid tussen enkele rollen aan te houden. Behalve uiteraard de opdrachtgever, benoemen wij daar analoog aan de traditionele bouw: de architect en de aannemer. De informatie-architect ontwerpt en de systeemaannemer construeert, dat is kortweg hun rolverdeling. Onze toegevoegde analyse luidt dat realisatie van informatievoorziening nog gedomineerd wordt door aannemers. Aan echte architecten, laat staan aan echt goede architecten, is een schreeuwend gebrek.
Het onderscheid tussen enerzijds architecten, anderzijds aannemers voor informatievoorziening helpt het voortdurend onbegrip over methoden in automatisering danwel informatisering te verklaren. De auteurs die ook onlangs nog naar 'De Methode Doet Het Niet' verwezen, zijn blijkbaar allemaal systeemaannemers. Dat artikel is echter geschreven door een informatiekundig architect ... en bedoeld voor informatiekundige architecten. De inhoud betreft immers nadrukkelijk ontwerpmethoden. Maar aannemers slaan blijkbaar aan op de titel annex slogan. Het is zelfs de vraag of zij het artikel überhaupt lazen en, zo ja, of zij het ook überhaupt kunnen begrijpen. Zoals uit 'Informatie-architect en Systeemaannemer' valt te lezen, is het overigens terecht wanneer aannemers de losse stelling De Methode Doet Het Niet bekritiseren. Dat is terecht als het om aannemersmethoden gaat. Van zulke methoden verlangt iedereen, en vooral de opdrachtgever, al veel meer dat de toegepaste methode het wèl doet.
Maar zo simpel ligt het met architectenmethoden niet. En de stelling De Methode Doet Het Niet stond wel degelijk en uitdrukkelijk in een ontwerpcontext geplaatst. Zomaar een slogan was en is het dus niet. Of, zoals Van Rees in 1982 schreef: "De ontwerper ontwerpt en niet de methode." Andere aspecten van systeemontwikkeling, dus ook niet van methoden ervoor, komen in dat artikel helemaal niet ter sprake.
Let wel, dat is alweer dertien jaar geleden. Is er dus een hardnekkig misverstand tussen informatiekundige architecten (informatie-architecten) en informatica-aannemers (systeemaannemers) gerezen? Ja, is ons antwoord met 'Informatie-architect en Systeemaannemer.'5 Dat is een antwoord van ontwerpers, van informatie-architecten dus. Maar tegelijk stel ik nu hier dat zo'n misverstand onvermijdelijk en zelfs onoplosbaar is voor wie vanuit de ene rol de methode wil begrijpen die bij de andere rol hoort. Het onderscheid tussen informatie-architecten en systeemaannemers is niet voor niets noodzakelijk. Er geldt immers: andere rol, àndere methode(n).
Informatie-architect en systeemaannemer kunnen het zich echter niet veroorloven aan informatievoorziening te werken in totaal onbegrip van wat de ander bijdraagt. Daarvan wordt informatievoorziening eerder slechter dan beter. Er is minimaal wederzijds begrip nodig. Daartoe moet elke partij (lees ook: speler van de overeenkomstige rol) uitleggen hoe zij werkt, wat haar referentiekader is enzovoort. Dat verduidelijkt hopelijk ook wat er misgaat, indien de ene partij zich de rol van de andere aanmatigt. Want er gaat natuurlijk veel mis als de systeemaannemer in een complexe situatie meent ook als informatie-architect te kunnen functioneren. En andersom is het precies hetzelfde; de verantwoordelijke architect onthoudt zich van aannemerswerk.
Hoe kan ik als ontwerper van informatievoorziening in complexe organisaties en processen, kortweg als informatie-architect, mijn bijdrage toelichten? Dat lukt aan de hand van de betekenis die methoden hebben voor het werk van de architect, en daarmee voor de veranderingen als geheel. Systeemaannemers moeten dan maar zien of zij hun methoden dezelfde betekenis toedichten. Of niet. Wederzijds begrip ontstaat niet alleen op grond van gelijkenis, maar tevens door erkenning van verschillen. Daarvoor bestaat in het engels de uitdrukking "to agree to disagree," en dan is al veel gewonnen.
De architect is met variëteit vertrouwd. Daarin verschilt de informatie-architect niets van de bouwkundige architect. Als hij ervaren is, heeft hij reeds allerlei opdrachten uitgevoerd. Hij heeft daarvan geleerd dat de volgende opdrachtgever totaal kan verschillen van wat hij tot dantoe meemaakte. Hetzelfde geldt voor de organisatie, het proces, de cultuur, de (andere) mensen enzovoort die allemaal voor inzicht in het probleem en realisatie van het uiteindelijk resultaat relevant zijn (lees ook: meespelen). Kortom, vertrouwdheid met onzekerheid leidt de architect ertoe a priori zekerheid juist te wantrouwen. Naarmate de situatie waarin hij komt te verkeren hem onbekender is, neemt hij niet alleen meer afstand van wat hij eerder ontwierp, maar eveneens van de methoden die hij daarvoor eerder toepaste.
Voor de ervaren architect is elke methode een stuk gereedschap. Het is mooi indien hij al over passend gereedschap beschikt. Maar zonodig, indien de opgave dat ook rechtvaardigt, dient hij nieuw gereedschap te ontwikkelen. Met andere woorden, de beroepsmatige verhouding van de architect tot diens methoden behoort vergaand los te staan van de architect als persoonlijkheid. Met behoud van zijn eigen persoonlijkheid (lees ook:stijl) wisselt hij zonodig van methode.
Vanuit deze opvatting is elke architectenmethode ooit onder bepaalde omstandigheden als gereedschap voor ontwerp ontstaan. Het is danook zonder meer logisch dat de resulterende methode die oorspronkelijke omstandigheden weerspiegelt. Slechts voorzover een nieuwe ontwerpopgave overeenstemt met die eerdere omstandigheden, is de methode opnieuw met succes toepasbaar. Anders zijn dus aanpassingen noodzakelijk, of keuze van een andere methode, of ontwikkeling van een geheel nieuwe methode.
Aangezien een methode op haar beurt ooit ontwikkeld werd, en dat middel daarom onder meer een bepaalde doelgerichtheid omvat, kent ook elke methode een architectuur.6 In termen van een structuralistische analyse7 van het verschijnsel methode zou overigens spake zijn van een systeem of een structuur. Ik gebruik hier de term architectuur om de actieve inbreng van de architect te benadrukken. Dit wil uiteraard niet zeggen dat elke methode bewust ontworpen is. Integendeel, de meeste methoden zijn niets anders dan gewoonten, ofwel in de loop der tijd bevestigde werkwijzen. Voor de architect is het met toenemende complexiteit anders. Hij hanteert een methode niet zozeer vanwege haar doelmatigheid, dat wil zeggen omdat de toepassing ervan eerder bewezen nuttig was. Voor de architect is eventuele herhaalbare toepasbaarheid van steeds ondergeschikter belang. Voor hem gaat het om een werkwijze überhaupt, om doeltreffendheid. Want hoe groter de variëteit van zijn opdrachten, des te geringer de kans om doelmatig te (kunnen) werken. Ik beweer zelfs dat het ontbreken van houvast voor doelmatigheid karakteristiek is voor de noodzaak om een aparte architect in te schakelen. Wanneer de opgave niet nieuw is danwel geen kans voor vernieuwing wordt vermoed, kan immers een aannemer direct aan de slag. De methode van de aannemer is niet geoptimaliseerd voor verkenning (doeltreffendheid), zoals dat bij de architect het geval is, maar voor exploitatie (doelmatigheid).
Het is al met al volkomen begrijpelijk dat een aannemer zich onvergelijkbaar méér identificeert met zijn methoden dan een architect dat doet met de zijne. De identificatiebehoefte gaat dikwijls zo ver, dat een aannemer zich tot één methode beperkt, waar de architect juist kiest voor diversiteit van zijn hulpmiddelen.8 De doelmatigheid van de aannemer is gebaseerd op routine, de doeltreffendheid van de architect op flexibiliteit.
De flexiblele architect, ook in het vlak van informatievoorziening, speelt als een goede huisarts met zijn opdrachtgevers. De informatie-architect is, netzoals de huisarts, trouwens niet een pure technicus. Terwijl hij altijd een ingenieur moet blijven, is hij daarnaast een organisatiekundige en een psycholoog. En veel meer dan de huisarts moet de informatiekundige architect ook een antropoloog, een socioloog enzovoort zijn. En niet te vergeten: filosoof. Wat dat is, een filosoof? Dat is iemand die in elk geval de titel van dit opstel begrijpt als speelse verwijzing naar een baanbrekende vraagstelling over objectiviteit ofwel naar de Kritik der reinen Vernunft9 van Immanuel Kant.
De informatie-architect ontwerpt relevante aspecten in hun samenhang zodat procesvoering geïntegreerd blijft of integratie zelfs toeneemt. Zijn invalshoek is informatievoorziening, maar als architect ontwerpt hij uiteindelijk méé aan die totale processen. Daarom houdt hij zich bijvoorbeeld ook bezig met de zgn organisatie van de informatievoorziening.10 Zo'n organisatie is immers voorwaarde voor informatievoorziening zèlf.
Voor pure techniek van informatica is er de aannemer, zoals de huisarts voor de uitvoering van een medische verrichting van enige omvang en complexiteit verwijst naar specialisten. Maar de goede huisarts verwijst niet automatisch. Netzo behoedt de informatie-architect zijn opdrachtgever voor zinloze automatisering. Daarin slaagt hij zolang hij zich op totale processen en betrokken mensen oriënteert ipv op een enkel aspect zoals bijvoorbeeld computerprogrammatuur.
Waarom herhaal ik dat de interventie van de informatie-architect toch vooral speels moet zijn? Dat heeft ermee te maken dat van aanwending van een methode onherroepelijk macht uitgaat. Dat is precies waarom de architect zichzelf niet al te serieus moet nemen. Wat hij altijd moet blijven relativeren, is die machtsuitoefening. Hij moet de verleiding weerstaan om bijvoorbeeld de positie van zijn opdrachtgever te vervullen. Met speels bedoel ik daarom dat de architect snapt dat hij weliswaar onvermijdelijk invloed heeft, maar dat hij er zowel de tijdelijkheid, als de dienstbaarheid van inziet. Hij oefent zijn macht immers uit bij de gratie van de uitnodiging door de opdrachtgever. De architect mag de gastvrijheid niet misbruiken. Tegelijk moet hij belangen van overige betrokkenen respecteren, zelfs wanneer de directe opdrachtgever daar (nog) niet aan toe is.
Dit kan allemaal verkeerd gaan, bijvoorbeeld met een architect die onverantwoord handelt. En natuurlijk zijn er slechte architecten, zoals er ook — wie heeft die ervaringen niet? — belabberde artsen zijn. De kans op compleet verkeerde uitkomst is zelfs groter indien een aannemer de rol van architect speelt, maar de betrekkelijkheid van zijn methode niet erkent. Een aannemer mag best vergaande geldigheid van zijn methode poneren. Dat mag hij echter uitsluitend in zijn rol als ... aannemer en onder regie van de opdrachtgever, die zich eventueel daarin door een architect laat bijstaan. Maar een aannemer die voor zijn methode zelfs absolute geldigheid opeist, heeft in de rol van architect een machtspositie verworven die gevaarlijk is. Want het is zeldzaam dat opdrachtgever en als-architect-vermomde aannemer hun verhouding zo kunnen analyseren, dat er een uitweg mogelijk is voordat ongelukken gebeurd zijn.
Nogmaals, van een architect moet een opdrachtgever verlangen dat hij zich van de relatie tussen methode en macht bewust is. Daar hoort dus terughoudendheid van de architect bij. Als een aannemer weet dat macht met methode samenhangt is dat prachtig, maar niet noodzakelijk. De terughoudendheid van de aannemer moet door regie afgedwongen zijn. Dat kan de opdrachtgever zelf doen. Als het wat ingewikkelder wordt, doet de opdrachtgever meestal verstandig er een echte architect bij te halen. Dat is met complexe informatievoorziening niet anders dan met de gebouwde omgeving.
In de praktijk is de architect vaak de enige betrokken partij die voldoende inzicht heeft in de samenhang tussen macht en methode. Dat maakt zijn positie extra moeilijk. De opdrachtgever kan waarschuwingen over de aannemer opvatten als concurrerend gedrag. Optimaal is het wanneer aannemers en architecten elkaars bijdragen aan het totale veranderingsproces waarderen en erkennen. Zulk respect is precies waarvoor ik pleit. Voor informatievoorziening betekent het dat informatica-aannemers plaats voor echte informatie-architecten inruimen. Helaas loopt het daarmee niet zo'n vaart, zoals uit voortdurend onbegrip blijkt. Ik meen dat aannemers zeker op langere termijn daarmee ook hun eigen belang frustreren.
Het is netzo twijfelachtig of opdrachtgevers de aparte rol van de architect erkennen. Als het om complexe informatievoorziening gaat, heeft besluitvorming tegenwoordig wel op de hoogste niveaus in de organisatie plaats, al is het maar omdat er veel geld mee gemoeid is. De praktijk wijst echter uit dat zittend management vaak nog onvoldoende ervaring met en/of gevoel voor dergelijke informatievoorziening heeft om een genuanceerd oordeel te vellen en vervolgens veranderingen ook passend te sturen. Meestal is het nog zo dat de voorstelling daar beperkt blijft tot het uiteindelijk gereedschap. Het resultaat van het zgn project is dan gedefinieerd in termen van computerprogrammatuur en -apparatuur. Met zo'n overzichtelijke doelstelling kan het project ook niet zo ingewikkeld zijn, blijft helaas de impliciete houding. Het is alweer een reden dat de aannemer in het allervroegste stadium zijn kans krijgt. De architect weet daarentegen dat techniek slechts één aspect bepaalt, en vaak een ondergeschikt en meestal een afgeleid aspect. Als resultaat van het veranderingsproces moet een andere organisatie, een ander proces oid gelden. Het probleem met de opdrachtgever is inderdaad dat de voorstelling van een andere organisatie met eventueel zelfs andere mensen veel moeilijker is dan wat tot een kastje met flikkerende lampjes beperkt kan blijven.
Dit probleem verklaart direct waaraan de architect de meeste aandacht moet schenken. Dat zijn de voorstelling, de beelden, de betekenissen en dergelijke die de opdrachtgever vormt. En het is niet alleen de opdrachtgever, maar iedereen die verder maar bij het veranderingsproces betrokken raakt. Mensen beginnen hun deelname aan zo´n proces met bepaalde betekenissen, gaandeweg brengen zij er verandering in. De architect stuurt het veranderingsproces, juist door invloed uit te oefenen op de ontwikkeling van betekenissen, beelden die de betrokken mensen hanteren. Hieruit volgt de primaire oriëntatie van de architect. Hij kijkt naar wie allemaal met het uiteindelijk resultaat te maken krijgt. Dat is, populair gezegd, de doelgroep. De verantwoordelijk handelende architect kan de doelgroep niet ruim genoeg zien. Wie ertoe behoort, is per definitie deelnemer aan het veranderingsproces. Waar dat door het aantal betrokken mensen onpraktisch is, zijn vertegenwoordigers nodig. Het contact met de totale doelgroep verdient echter voortdurend aandacht. Zonder minimaal contact dreigt mislukking. De informatie-architect is onder meer genoeg procesbegeleidende organisatiekundige om juist succes met betrokkenen te behalen.
De architect begeleidt zijn opdrachtgever en overige betrokkenen tijdens de ontwikkeling van relevante betekenissen, beslissingen enzovoort. Niet de architect beslist, maar bevordert de uitdrukking van wat betrokkenen in hun samenhang en -werking willen. Wat voor organisatie willen zij? Wat voor proces? Wat voor relatie met klanten? Dus, de architect nodigt op zijn beurt tot dergelijke strategische oriëntatie uit. Strategie moet het betekenissenniveau zijn waarop betrokkenen hun verschillen overwinnen. Als dat daar niet lukt, geldt per definitie dat al die betrokkenen samen een groter of tenminste een ander probleem hebben dan zij oorspronkelijk dachten. Het staat dan vast dat in eerste aanleg een andere oplossing dan verbetering van informatievoorziening nodig is. Als dat trouwens de diagnose van de informatie-architect is, moet hij niet aarzelen die over te brengen, ook al gaat dat ten koste van zijn omzet. Als de opdrachtgever de architect niet meer kan vertrouwen, wie dan wel?
De methoden die de architect hanteert, moeten de ontwikkeling van beelden, betekenissen en dergelijke bij betrokkenen ondersteunen. Sleutelwoord is hier betrokkenen, en wel allereerst in de zin van de opdrachtgever en wie verder allemaal met het resultaat moeten leven. Waar de architect zich dus niet, zeker in eerste aanleg niet, op richt zijn beelden en betekenissen van de aannemer. Alle methoden waarover de architect voor zijn communicatie met de opdrachtgever beschikt, noem ik architectenmethoden van de eerste soort.
Architectenmethoden van de tweede soort zijn er voor de communicatie — altijd namens de opdrachtgever — van de architect met de aannemer. Hier gaat het om wat gewoonlijk specificaties heten. Zulke methoden maken specificaties zo eenduidig mogelijk zichtbaar. Aan normen schort het trouwens in het vlak van geautomatiseerde informatievoorziening. Dat heeft alles te maken met ontbrekende traditie van automatisering en snelle opeenvolging van de zgn generaties hulpmiddelen. Voorts is dat gebrek aan eenduidigheid nog niet erkend als probleem met maatschappelijke proporties, zoals dat voor de bouwwereld allang geldt. Daar verschaffen voorschriften ed de opdrachtgever een waarborg voor kwaliteit en vergemakkelijken de communicatie tussen architect en aannemer(s). Tegelijk gaat door voorschriften natuurlijk dynamiek verloren. Daarom is het logisch dat voor automatisering vergaande regulering nog ontbreekt. In de huidige ontwikkeling passen mi wel wat Van Rees constructieprincipes noemt (zie ook verderop).
Maar goed, of er reeds normering voor specificaties bestaat of niet, de bedoeling van specificaties volgens architectenmethoden van de tweede soort is dat allerlei technisch specialisten aan de gang kunnen en apparatuur, programmatuur en dergelijke aanschaffen, aanpassen en/of nieuw bouwen. (Dit gaat overigens steeds verder, bijvoorbeeld waar een programmagenerator zonder menselijke tussenkomst de specificaties tot toepassingsprogrammatuur verwerkt.) Nu ondersteunt een goede architectenmethode dus communicatie in de richting van de bouwers (een mens of een ànder geautomatiseerd informatiesysteem). In het totale proces van realisatie van betere informatievoorziening zijn zulke methoden eveneens onmisbaar.
Maar nogmaals, in communicatie met technisch specialisten is de architect in eerste aanleg helemaal niet geïnteresseerd. Hij wil, nee, hij moet met zijn opdrachtgever en overige betrokkenen communiceren over wat zij wensen. Zijn eigen technisch inzicht, waarover hij wel degelijk moet beschikken, moet zoveel mogelijk op de achtergrond blijven. De architect moet vooral in de termen van zijn klanten luisteren, spreken, handelen enzovoort. Dat zijn termen en dat is, nog wezenlijker, een passend referentiekader die hij voor zulke communicatie waarschijnlijk al dan niet ingrijpend moet helpen ontwikkelen. Architectenmethoden van de tweede soort zijn daarvoor per definitie niet geschikt, laat staan dat aannemersmethoden dat zijn. (Want, waren zij dat wel, dan konden die zgn. gebruikers immers zelf probleemloos de inrichting van hun informatievoorziening direct met een informatica-aannemer regelen, respectievelijk helemaal zèlf doen.)
De architect functioneert als intermediair in communicatie. Voor zijn communicatie met klanten moet hij over methoden beschikken die naar hun aard fundamenteel verschillen van de methoden die hij gebruikt voor zijn communicatie met de aannemer.
Aannemersmethoden zijn helemaal van een andere orde. Dat zijn methoden die een aannemer gebruikt om de specificaties van de architect zonodig te detailleren, te vertalen naar constructiehandelingen. En dat zijn methoden voor de feitelijke bouw van het gespecificeerde gereedschap voor informatievoorziening. Het gaat altijd hopeloos fout als aannemersmethoden ingezet worden voor communicatie met de opdrachtgever cs. Het gaat dus fout, indien een aannemer ook de rol van architect vervult. Dan is de kans des te groter dat voor open ontwikkeling van betekenissen een methode voor gesloten beheersing van produktie toegepast wordt. De methodische macht van de aannemer blijft daar onbeteugeld met alle risico van dien.
Als het zo is, dat aannemers voor informatievoorziening via hun methode eenzijdig macht uitoefenen, waarom zijn opdrachtgevers daartegen niet in opstand gekomen? Een simpel antwoord heb ik niet. Het beeld is vooralsnog ingewikkelder. Mijn idee is dat een methode vanuit een minimale acceptatie allereerst vergelijkbaar is met een self-fulfilling prophesy. Dat is de fase van speelse toepassing. Het is de paradox dat de methode qua inhoud eigenlijk overbodig is; vanuit haar vorm alleen al volgt resultaat. Met steeds meer nadruk op de inhoud nadert een methode echter het omslagpunt. Wie de methode te absoluut propageert, wordt terecht verdacht er macht mee te willen uitoefenen. Zo roept macht tenslotte tegenmacht op. In plaats van self-fulfilling is de methode nu self-defeating.
Nu stel ik de vraag opnieuw: Waarom hebben aannemersmethoden in het vlak van de architectuur het omlagpunt naar self-defeating nog niet bereikt? Als analyse stel ik voor dat betrokkenen blijkbaar (nog) niet over middelen beschikken om realistisch tegenmacht te bieden. Want wat is hun alternatief? Is dat een andere aannemer? Met weliswaar een andere, maar toch ook een aannemersmethode zodat het (gebrek aan) resultaat hetzelfde blijft?
Het alternatief voor de opdrachtgever is naar mijn oordeel, hoe kan het anders, inschakeling van een informatie-architect. Maar dat is geen redelijk alternatief zolang opdrachtgevers van het bestaan ervan niet afweten. Of zolang over de aard en kwaliteit van de dienstverlening onduidelijkheid bestaat. En het blijft moeilijk een herkenbare positie te verwerven zolang aannemers zich tevens als architecten voor informatievoorziening aanbieden. Hoe moet een opdrachtgever het verschil uitmaken tussen een echte en een valse informatie-architect?
Hoewel er ook talloze bezwaren aan kleven, lijkt bescherming van de titel informatiekundig architect of, kortweg, informatie-architect praktisch. Of het echt helpt, althans in de huidige maatschappelijke constellatie van gevestigde belangen, betwijfel ik trouwens. Wat dan? Heel concreet werk ik bewust aan mijn eigen architectuurpraktijk. Door betere resultaten raken opdrachtgevers het meest overtuigd. Een zakelijker reden voor de opdrachtgever om een informatie-architect te vertrouwen ken ik niet.
In alle opwinding over methoden moeten specialisten nooit vergeten dat zij ... specialisten zijn. Dat geldt dus ook voor informatie-architecten. Het is de meeste klanten ronduit een zorg welke methoden hun dienstverleners toepassen. Zij moeten op kwaliteit kunnen vertrouwen. Dat vertrouwen van hun klant moeten specialisten niet verwarren met hun eigen gemis aan zelfvertrouwen. Er zou veel duidelijkheid gewonnen zijn, indien specialisten durven toegeven dat zij vooral hun eigen onzekerheid proberen te beheersen door aan een of andere methode te hangen. Vooral voor eigen parochie heeft de methode kracht van geloof. In psychoanalytische zin is er van verdringing sprake door hun klanten met al dat gedoe over methoden op te zadelen.
De informatie-architect belast zijn opdrachtgever en wie verder maar bij het veranderingsproces betrokken raken, dus ongevraagd niet met de methoden die hij hanteert. De architect probeert te communiceren. Het doel is het probleem danwel de kans van de opdrachtgever. Het doel is niet de methode van de dienstverlener. Zolang de communicatie naar de mening van deelnemers lukt, komt de methodenkwestie niet ter sprake. En zodra communicatie stokt, is het maar de vraag of discussie over de tot dusver gehanteerde methode soelaas biedt. De architect doet er meestal beter aan zijn werk met een andere (communicatie)methode te vervolgen. De methode is er altijd ten behoeve van communicatie, nooit ten behoeve van zichzelf en zeker niet als drempel tegen communicatie.
Als drempel tegen communicatie zal een integere aannemer zijn methode uiteraard nooit bedoelen. Als hij onvermoed de rol van architect vervult, en dus eigelijk architectenmethoden van de eerste soort zou moeten hanteren, pakt toepassing van een aannemersmethode echter wel verkeerd uit.
Wat wil de opdrachtgever? Wat willen overige betrokkenen? Zoals gezegd, begeleidt de informatie-architect eerst en vooral de beeldvorming bij betrokkenen omtrent hun toekomstige organisatie, hun proces, hun cultuur in de toekomst enzovoort.
In aannemerstermen — nota bene, de systeemaannemer is meestal maar één van vele aannemers en slechts uitvoerder van programmatuur — heet bijvoorbeeld de organisatie inclusief informatievoorziening die gerealiseerd gaat worden een constructie. Het is dus iets dat gemaakt, geconstrueerd gaat worden. Of op z'n minst zullen betrokkenen op grond van een ontwerp enige invloed uitoefenen. Waar de architect op let is dat zo'n constructie voor iedereen, met de opdrachtgever en vooral zgn gebruikers voorop, iets reëels betekent. Als zodanig is de architect bezig met de semantiek van de constructie.11
De constructie verwijst naar het uiteindelijk resultaat. De semantiek van die (te realiseren) constructie vormen deelnemers echter vaak al beslissend in de vroegste fasen van hun veranderingsproces. Niet in aannemerstermen, maar nu in zijn eigen architectentermen is de architect daar bezig met constructie van semantiek. In het vlak van betekenissen is de architect dus ook ... aannemer. De constructie van semantiek is evenwel van een andere orde dan de constructie van hulpmiddelen voor digitale informatieverwerking. Het eerste is informatiekunde, het tweede informatica. Vandaar dat ook voor ontwikkeling van (gereedschappen voor) informatievoorziening het onderscheid tussen architecten en aannemers onverminderd nodig blijft. En vandaar dat de architect methoden in twee soorten toepast die naar hun aard onderling wezenlijk verschillen en dan samen ook nog eens wezenlijk van aannemersmethoden.
Het dilemma voor de architect in zijn relatie tot de opdrachtgever en overige betrokkenen is dat hij zijn methoden niet tegelijk met zijn activiteiten van het communiceren kan verduidelijken. Zoals ik hierboven aangaf, laat de architect zijn (communicatie)methoden dus bij voorkeur impliciet. Dat is het spel. Ook de huisarts zegt er niet bij dat hij zijn patient serieus neemt. Dat zou het effect direct teniet doen, althans bij de meeste patiënten. Zoiets moet 'vanzelf' spreken.
De aannemer kan explicieter zijn over zijn methoden. Hij kan ermee toelichten dat de opdrachtgever en de architect kunnen vertrouwen op de kwaliteit van het resultaat en op de doelmatigheid waarmee dat bereikt wordt. Dat is niet verwarrend zolang de communicatie uitsluitend in het teken van het vestigen van dat vertrouwen staat. Als er andere beelden en betekenissen gaan mee'spelen,' gaat het mis. Dat vertroebelt onder meer het uiteindelijk beeld van de opdrachtgever.
Wie onder de noemer van de architectuur van de methode een uitputtende beschrijving van architectenmethoden verwacht, moet ik teleurstellen. De architectuur zit ´m voor ontwerpen-als-proces immers slechts minimaal binnenin de methode, dat wil zeggen in de letters van haar regels.
Dat is opnieuw vergelijkbaar met een gebouw. Daar is de architectuur van, bijvoorbeeld, een huis niet identiek aan de muren, de kozijnen en welke andere bouwelementen er allemaal verwerkt zijn. Het architectuurbegrip is ruimer. De architectuur omvat de totale belevenis van het huis. Dat variëert van de oorspronkelijke bedoeling van de opdrachtgever via de inbreng van de architect en de aannemer tot en met de zgn. interpretatie ervan en omgang ermee door allerlei betrokken personen. De aannemer bouwt muren. Voor de architect gaat het veeleer om de ruimte. Inderdaad zijn daarvoor muren nodig. Maar gelet op de ruimte vormen muren de noodzakelijke voorwaarden. Het blijven de middelen voor een ànder doel. En verder gaat het voor de bewoner/gebruiker om daadwerkelijke functies. Nota bene, daarbij speelt tevens de behoefte aan esthetische ervaringen mee.12
De verscheidenheid van methoden is enorm. Dat geldt zelfs voor alleen al architectenmethoden in het vlak van informatievoorziening. Een algemeen geldig verhaal over de interne structuur van dergelijke methoden is onhaalbaar. Ik beperk me daarom tot wat mi algemeen opgaat voor de externe structuur, dat wil zeggen voor de architectuur van methoden. Dan blijkt methode dus nauw samen te hangen met onder meer macht en communicatie, kortom met persoonlijke belevenis.
In het begin van dit artikel noemde ik dat de architect aan grote variëteit gewend is. Het is reëler te zeggen dat vooral de architect in uiteenlopende situaties kan komen te verkeren. Maar met toenemende variëteit wordt iedereen in de maatschappij geconfronteert, dus ook aannemers.
Met groeiende variëteit neemt de betekenis af van wat een methode in traditionele zin is. Onzekerheid, onvoorspelbaarheid en dergelijke noodzaken tot flexibiliteit. Daarbij past steeds minder een begrip dat een werkwijze veronderstelt die a priori vastligt. Daarentegen wijst variëteit op de behoefte aan algemeen geldige uitgangspunten, die naar concrete omstandigheden aangepast toepasbaar zijn. Een ander woord voor zulke uitgangspunten is principes.
Kernbegrippen voor de architectuurprincipes blijven uiteraard dezelfde als bij methoden. Het gaat om oriëntatie op deelnemers aan het veranderingsproces, om hun beeldvorming, om de ontwikkeling van betekenissen, om communicatie. Hiervoor is de benaming principe zelfs geschikter dan methode.
Voor aannemers gelden dan constructieprincipes. Hier belooft overgang van methode naar principe wel wezenlijke verandering. Met duidelijke principes wint de aannemer aan vrijheid tijdens zijn constructiewerkzaamheden. Zolang hij zich aan die principes houdt, is de kwaliteit van het resultaat kennelijk voldoende gewaarborgd. Hoe de aannemer die principes daadwerkelijk effectueert, al dan niet met methoden bijvoorbeeld, is verder zijn eigen zaak. De uitkomst is aan de hand van constructieprincipes voldoende controleerbaar. Een groot voordeel is voorts dat de aannemer via constructieprincipes simpeler aan de opdrachtgever kan uitleggen dat het met kwaliteit wel goed zit. Hij hoeft de opdrachtgever in zijn uitleg immers niet met details van uitvoering te vermoeien. Ook is met constructieprincipes een compacte taal gevestigd tussen architect en aannemer. Als de architect stipuleert waar de aannemer bepaalde constructieprincipes beslist moet volgen, bestaat daarmee een basis voor kwaliteitsinspectie.
Het voert tever hier architectuur- en constructieprincipes voor informatievoorziening op te sommen.13 Met het belangrijkste constructieprincipe volgens Van Rees geef ik de smaak weer: Onzichtbare koppelingen zijn verboden. De noodzaak van dit principe is uiteraard meteen helder. Alleen zichtbare koppelingen maken programmatuur (of wat danook) fatsoenlijk onderhoudbaar. De consequenties van dit constructieprincipe zijn echter verreikend. Er volgt onder meer, en dat is dan mijn eigen conclusie, een verbod tegen klakkeloze overerving met objecttechnologie uit. En overerving vinden thans vele aannemers juist zo interessant omdat zij daarmee goedkoper programmatuur kunnen ontwikkelen. Ja, initiële ontwikkeling is wellicht sneller en zodoende in dat stadium goedkoper, ook voor de opdrachtgever als die tenminste een deel van het voordeel krijgt. De rekening wordt echter tijdens onderhoud dubbel en dwars gepresenteerd. Naar verborgen koppelingen kan het lang zoeken zijn, terwijl onzekerheid over een volkomen oplossing blijft. Er zijn toepassingen waarbij zulk risico ontoelaatbaar is. De architect moet zijn opdrachtgever op zulke consequenties wijzen. Doet hij dat goed, dan zal de opdrachtgever in dergelijke opzichten niet op de opdracht aan de aannemer willen bezuinigen. Want uiteindelijk moeten de belangen van opdrachtgever, architect en aannemer natuurlijk parallel lopen.
Een kant-en-klare oplossing voor de optimale samenwerking tussen opdrachtgever, informatie-architect en systeemaannemer schets ik niet. In mijn ogen bestaat die oplossing ook niet in standaardformaat. Daarvoor is de variëteit aan opgaven voor informatievoorziening in complexe organisaties en processen te groot. Samenwerking is steeds maatwerk. Daarom kies ik er heel praktisch voor om vooral de verhouding tussen architect en aannemer te problematiseren. Zonder enige pretentie op volledigheid, volgen daaruit toch reeds allerlei concrete aanwijzingen voor verandering van de praktijk van realisatie van informatievoorziening. Dat elke methode een architectuur heeft, en dat dus vooral gezien buiten de beperktheid van de regels, bevestigt dat aannemers verder moeten kijken dan hun neus lang is. Daar zien zij hopelijk de architect staan. Als huidige aannemers voor informatievoorziening dat niet (willen) begrijpen, moet het toch aan informatiekundigen en informatici van een nieuwe generatie uit te leggen zijn.
noten
1. Waar de persoon in kwestie een vrouw of een man kan zijn, staat hier kortheidshalve slechts het mannelijk voornaamwoord vermeld.
2. In: Informatie, jaargang 24, 1982, nr 2.
3. Voor het besluit van
mijn opleiding aan de TH Delft (thans: universiteit) zijn Brussaard en Van Rees
onlosmakelijk met elkaar verbonden. Laatstgenoemde was destijds
wetenschappelijk medewerker en nam, tenminste in mijn geval, de begeleiding van
de afstudeerder tijdens de intensieve stage volledig voor zijn rekening.
Daarvan heb ik in combinatie met de 'theorie' van Brussaard veel geleerd.
Zijn toenmalige rol als wetenschappelijk medewerker verklaart waarom Organisatieverandering en informatie-architectuur geen
bijdrage van Van Rees bevat. Hij is immers niet bij Brussaard afgestudeerd. Via
deze tekst komt Van Rees echter indirect uitgebreid aan het woord. Daardoor
komt ook mijn eigen boodschap duidelijker over, dat is één. En voorts moet het
voor de architect van onze professionele relatie, voor Brussaard dus,
bevredigend zijn resultaten daarvan te zien. Of hij onze opvatting deelt, is
trouwens weer iets anders. Ikzelf vind dat er van grote verwantschap sprake
blijft.
Jaap van Rees en ik hebben dus over verdere theoretische èn praktische
ontwikkelingen samen diverse publicaties verzorgd. Verder heb ikzelf hier
enkele onderwerpen en/of stellingen verwerkt die tijdens onze gesprekken de
revue passeren. Voor zover het ideeën betreft die oorspronkelijk van Van Rees
afkomstig zijn, ben ik hem erkentelijk voor de inspiratie. Overigens zijn
gedeelten van mijn voorliggende tekst vervolgens weer bewerkt terecht gekomen
in ons beider artikel 'De Rol van de Informatie-architect' in: Informatie Management, 1995, nr 3. Zo gaat dat met
goede samenwerking.
4. In: Informatie, jaargang 37, 1995, nr 4. Het hier gepubliceerde opstel zie ik als rechtstreeks vervolg op dat artikel. Zie ook noot 3.
5. Zie ook ons boek De Informatie-architect (Kluwer Bedrijfswetenschappen, 1995).
6. Dat ook een methode op haar beurt een architectuur heeft, is zo'n stelling die Van Rees poneert. Dat hebben wij in ons boek (zie noot 5) toegelicht. Een ander voorbeeld is dat een constructie semantiek heeft (zie verderop in deze tekst). Daaraan heb ik dan dialectisch toegevoegd, zeg ook maar door omkering van de verhouding tussen begrippen, dat semantiek constructie vergt.
7. Het zgn structuralisme is bij uitstek gericht op studie van de dynamiek van een verschijnsel. Dan kent de onderzoeker aan betrekking een centrale betekenis toe. Via de betrekking zijn elementen verbonden. Voilá, een systeem.
8. Diversiteit ofwel variëteit van hulpmiddelen moet overeenstemmen met de variëteit van de te beheersen situatie. Dat volgt uit The Law of Requisite Variety van R.W. Ashby (An Introduction to Cybernetics, Methuen, 1964, oorspronkelijke editie 1956).
9. De eerste editie verscheen in 1781. Ik verwijs naar de editie van uitgeverij Felix Meiner uit 1956 (herdruk 1967).
10. Een inleiding verschaft
B.K. Brussaard met zijn collegedictaat Organisatie van
de Informatievoorziening (vak a136B, Technische Universiteit Delft). Dit
vak heeft Brussaard ruim twintig jaar gedoceerd. De recentste uitgave van zijn
dictaat is van 1995.
Uit de school van Brussaard stamt ook H.R. Stol die organisatie van
informatievoorziening schetst als onderdeel van zgn informatieplanning. Zie
zijn boek Informatieplanning in de praktijk
(Samsom, 1990) dat de ondertitel draagt grondbeginselen
voor de opzet van bestuurlijke informatiesystemen. Ikzelf wijdde in
onder meer Aspecten en Fasen (Information
Dynamics, 1991) en Het Experiment Buitenlandse Zaken
(Information Dynamics, 1991) diverse passages aan organisatie van
informatievoorziening.
Met Brussaard als promotor schreef P.A.H.M. Mantelaers het proefschrift Organisatie-ontwerp van de Informatievoorziening
(1995). Hierover past een opmerking die verband houdt met de strekking van dit
opstel. Want ondanks (of juist?) een enorme onderzoeksinspanning raakt
Mantelaers mi verstrikt in methodologische kwesties. In combinatie met de
beperkingen in zijn onderzoek (p 16) resulteren daarom slechts
haal-je-de-koekoek aanbevelingen voor de organisatie van de
informatievoorziening (vanaf p 335). Dus ook voor zgn wetenschap is — ruimte
voor — 'kritiek op de pure methode' nodig. Anders drijft zo'n discipline naar
het theoretisch isolement van methodenleer; vorm corrumpeert inhoud. Dat mag
zeker met een ingenieursvak niet gebeuren.
11. Zie noot 6 voor de bron, althans in het vlak van informatievoorziening, van de stelling dat elke constructie een (eigen) semantiek heeft.
12. In de bouw geldt het functionalisme als stroming waarmee nadruk op het doel van het gebouw ligt. Met doel is dan oorspronkelijk zoiets als zakelijkheid bedoeld. De structuralist J. Mukarovský (Kunst, Poetik, Semiotik, Suhrkamp, 1989) heeft via zijn literatuurkritiek tevens de esthetische behoeften in de sfeer van de funktionele, zakelijke bedoeling gebracht. Met behoud van de noemer functionalisme schetst hij aldus een synthese voor de architectuur.
13. Een inleiding tot architectuur- en constructieprincipes verschaft het vraaggesprek 'Van Rees over Informatiekunde en zijn Constructieprincipes' (in: OT Magazine, jaargang 1, nummer 5, 1994) dat ik hield met Jaap van Rees. Over diverse constructieprincipes publiceerde Van Rees zelf in afleveringen van zijn bedrijfsblad Infomeel. Zij zijn, samen met dat vraaggesprek, tevens in ons boek De Informatie-architect (zie noot 5) opgenomen.
© 1995, webeditie 2002.
Eerder verschenen in: Organisatieverandering en
Informatie-architectuur (Samsom Bedrijfsinformatie, 1995) en Informatiekundige ontwerpleer (Ten Hagen Stam, 1999).