25 Vermenigvuldiging

Pieter Wisse

Dit is een hoofdstuk uit Informatiekundige Ontwerpleer, in 1999 verschenen in boekvorm bij Ten Hagen Stam.

Het model van objecten-in-context is flexibel, maar functioneert uiteraard slechts in handen van een geschikte gebruiker. Zo is het met ieder gereedschap. De eenvoud bedriegt wanneer andere voorwaarden voor passende variëteit miskend blijven. De integere ontwerper van eenvoud — van structuur — in gereedschap probeert ermee niet te bedriegen, maar juist die ontwikkeling van betrokken mensen in hun milieu te stimuleren.¹

Een obstakel voor bewuste eenvoud is vaak dat de ontwerper niet snapt dat, en ook hoe, abstractie en verbijzondering een versterkende invloed op elkaar hebben. Hij blijft dan steken in verbijzondering zònder abstractie. Het resultaat is een model en later een gereedschap met een evenzo complexe structuur als de ontwerper diverse verschijnselen herkende.

Behalve te ingewikkeld, is dergelijk gereedschap dikwijls tegelijk te eenvoudig. Dat gebeurt wanneer de ontwerper zijn aannames omtrent structuur niet toetst in het licht van variëteit van het milieu en daarbij passende variëteit voor beïnvloeding.

Het valt mij op dat in nogal wat literatuur over toepassing van objectgerichte informatietechnologie onomwonden staat dat informatievoorziening ermee zo eenvoudig is. Maar vaak zijn de gepresenteerde modellen van de organisatorische processen te eenvoudig gebleven. Komt dat omdat de enthousiaste uitvinders en voorstanders van die technologie (nog) onvoldoende ervaring met complexe processen en organisaties hebben? Een gereedschap is natuurlijk pas levensvatbaar indien het bijdraagt aan informatievoorziening over en besturing van relevante aspecten.²

In een versimpelde kijk op processen staat meestal slechts één object centraal. Het is dan als het ware de definitie van een proces dat zo´n object weliswaar diverse bewerkingen ondergaat, maar in essentie ongewijzigd blijft. Met andere woorden, dat object verandert vooral van status.

Inderdaad, als er behalve de status vrijwel niets wijzigt, behoudt zo´n object gedurende een proces een eigen identiteit. Het gevolg is echter dat niet meer traceerbaar is wat er verder aan het object veranderde (tenzij dat voor alle objecten van dezelfde klasse altijd hetzelfde is; dan is er via abstractie weer een structuur).

Nu zijn er meestal zwaarwegende redenen om veranderingen wèl te kunnen naspeuren. Zo is er omtrent allerlei verschijnselen waarop invloed uitgeoefend wordt, een plicht tot verantwoording. En dan is er de behoefte om van kennis over het verleden te leren voor de toekomst. Als zulke redenen tellen, kan er weliswaar sprake van veranderingen van status zijn, maar volstaat dat ene object met zijn meest actuele status niet meer voor adequate informatievoorziening. In plaats daarvan moet nu bij iedere relevante statuswisseling een nieuw object gevormd worden, opdat tevens het object waaruit het voortkomt bewaard blijft. Op deze manier vermenigvuldigt het aantal object(klassen) zich overeenkomstig informatiebehoeften van èchte betrokkenen.³

Ik begin een voorbeeld met de veronderstelling van eenvoudig proces. Als het zgn centrale object neem ik een transactie. Stel dat het gaat om inkoop van goederen.

Meteen bij aanvraag van een offerte wordt voor informatievoorziening dan het transactie-object gevormd. Dat krijgt de overeenkomstige status van: aanvraag.

Zodra de offerte binnenkomt, kan de status van het transactie-object gewijzigd worden. De consequentie hiervan is echter dat informatie over de aanvraag verdwenen is. Als er geen reden bestaat om die informatie beschikbaar te houden, is die verwijdering overigens niet ernstig.

Stel echter dat er wèl een gegronde reden is om informatie over de aanvraag te behouden. Daaruit volgt dat de transactie niet meer hèt centrale object is. Nu zijn er al twee verschillende objecten nodig. Dat zijn aanvraag èn offerte. Hierbij neem ik vooralsnog aan dat daarom ook twee verschillende overkoepelende klassen voor aanvragen en offertes zijn.

Zo gaat de analyse van het inkoopproces verder. Als de inkoper met de offerte accoord gaat, volgt de bestelling. Wederom moet de vraag luiden, of omtrent de offerte informatie apart bewaard moet blijven. Zo nee, dan volstaan een wijziging van de status. Zo ja, dan is vermenigvuldiging van de informatie noodzakelijk.

Na bestelling komen de goederen binnen. Is die ontvangst aanleiding voor een nieuwe status of moet er een object van een àndere klasse bijkomen?

En de leverancier wenst betaling voor de goederen. Is de faktuur een object van nòg een klasse? En uiteindelijk wordt de betaling geconsolideerd in het grootboek. Blijft de aanduiding van de journalisering tot een — definitieve — status beperkt, of is het raadzaam er een object in alweer een andere klasse voor te vormen?

Zelfs wanneer er sprake is van de vermenigvuldiging vanuit statussen van één object naar verschillende objecten uit evenzovele klassen, pretendeer ik met de beschrijving hierboven nog geen volledigheid. Het is geheel afhankelijk van de geldige procedure. Welke stappen moeten er concreet doorlopen worden? Zijn er in het milieu in kwestie méér nodig, of juist minder en/of andere stappen? Zo kan het aanbeveling verdienen om ook het financiële aspect van de bestelling in het grootboek te consolideren.⁴ Maar dan moet er eerder ook zoiets als een begroting geregistreerd zijn. Confrontatie van zulke informatie verschaft inzicht in het verloop — van het financiële aspect — van een proces.

De noodzaak om een simpel statusmechanisme te verlaten wordt nog duidelijker wanneer de stappen in een procedure niet consequent in dezelfde volgorde gebeuren. In een spoedgeval kunnen de goederen langs informele weg eerder geleverd worden dan de formele bestelling ervoor uitgaat. Is dat verkeerd? Dat hangt alweer van de situatie af? Ikzelf vind trouwens niet zo gauw iets verkeerd. Voor informatievoorziening geldt algemeen dat er passende variëteit moet zijn. En wat past, is sterk afhankelijk van heersende onzekerheid. Dus, wat is realistisch? Met strakke procedures valt die onzekerheid niet weg te poetsen. Wie dat probeert, lokt slechts extra problemen uit.

Een zijn nog andere vormen van vermenigvuldiging herkenbaar, dwz vormen die niet zozeer voortkomen uit de noodzaak voor inzicht in procesverloop. Eén zo´n vorm betreft de detaillering die ik eerder behandeld heb. Zie ook het gelijknamige hoofdstuk 20.

Wat ik bedoel is dat bijvoorbeeld een aanvraag allerlei details omvat die niet in dat ene object passen. De gebruikelijke, en vaak voldoende, oplossing is om een totale aanvraag in één zgn kop en één of meer zgn regels in te delen. Een aparte regel is een nieuw, apart object en bevat ten opzichte van de kop nadere informatie. Als in de kop bijvoorbeeld de leverancier vermeld staat waaraan de aanvraag gericht is, is er in een aparte regel ruimte voor de vraag naar een bepaalde hoeveelheid van een bepaald produkt.

Het is uiteraard weer denkbaar om van zo´n regel een centraal object in de zin van een algemeen toepasbaar transactiedeel te maken. Dan zou de status ervan veranderen van aanvraag naar offerte naar bestelling enzovoort. Dat verdient meestal eveneens geen voorkeur. Dus is er op de niveaus van kop èn regels vermenigvuldiging van de klassen met hun objecten nodig.

Het voordeel van aparte regels pèr aangegeven stap in een procedure is vanuit heersende onzekerheid hopelijk meteen evident. Het komt immers voor dat een offerte niet overeenstemt met de aanvraag. Of wat de inkoper bestelt, is niet precies wat de offerte aangaf. Heel duidelijk is dat goederen vaak niet voor ontvangst binnenkomen in exact dezelfde groeperingen waarin ze besteld zijn. En waarom zouden betalingen precies de fakturen moeten volgen?

Met eigen regels voor detaillering tijdens elke relevante procedurestap blijft verloop en eventuele verschillen analyseerbaar.

Nòg een vorm van vermenigvuldiging waarop ik hier wijs, heeft met meervoudigheid van contacten te maken. Concreet gezegd, kan de inkoper een offerte-aanvraag aan diverse leveranciers richten. En, wie weet, dient één leverancier wel diverse offertes in als reactie op dezelfde aanvraag. Indien zulk gedrag in het milieu in kwestie reëel is, rijst de vraag of het gereedschap voor geautomatiseerde informatievoorziening daarvoor binnen zijn eigen grenzen over passende variëteit moet beschikken. Als dat zo is, volstaat echter het versimpelde model met dat ene centrale object niet meer.⁵ Elke vrijheidsgraad voor gedrag draagt het potentieel van vermenigvuldiging. De ontwerper kan dat via abstractie zoveel mogelijk proberen te beheersen. Maar reële informatiebehoeften kan hij nooit ontkennen.

Het voorafgaande maakt duidelijk dat een aanleiding voor vermenigvuldiging dikwijls de — eisen voor — functiescheidingen binnen en buiten de eigen organisatie⁶ zijn. Er zijn allerlei mensen bij processen betrokken en zij voeren daarin vaak slechts specifieke activiteiten uit. Of, wat ook gebeurt, een activiteit is vanuit de behoefte aan controleerbaarheid zo specifiek gemáákt.

In hoofdstuk 21, Analogie, heb ik verteld over mijn pogingen om in die verscheidenheid tòch een gemeenschappelijke structuur te herkennen. Dat leidt inderdaad tot compacter gereedschap voor onderdelen van de geautomatiseerde informatievoorziening. Voor meer toelichting op dat infrastructureel bedoelde model verwijs ik naar dat hoofdstuk terùg. Ik voeg er hier aan toe dat de ontwerper, indien hij zich confronteert weet met vermenigvuldigende complexiteit, zich steeds het volgende kan afvragen. Hij weet dus dat er diverse objecten in informatievoorziening moeten ontstaan. Maar is het ècht nodig om daarvoor allemaal verschillende klassen te ontwerpen? Ja, is het antwoord, indien de informatie over wat ik hier bij wijze van voorbeeld de verschillende procedurestappen noem, sterk vanelkaar afwijkt. En dan is voor zulke afwijking niet zozeer de betekenis, maar de vòrm van de informatie relevant alsmede het gedrag op basis van de betekenis die elk object vervolgens aan die vorm kan toekennen. Er is dus, bijvoorbeeld, behoefte aan aparte klassen voor aanvragen en offertes wanneer er sprake is van in de eerste plaats een àndere vorm van de informatie over een aanvraag, respectievelijk een offerte. Een tweede reden om aparte klassen met hun objecten te stichten is dat het gedrag van een aanvraag, dat volgens objectgerichtheid mede bepaald wordt door zijn eigen informatie, verschilt van het gedrag van een offerte. Dergelijk verschil moet tot uitdrukking komen in afwijkende, zeg maar, gedragsregels of, zoals het in termen van objectgerichtheid heet, methoden.

Als er voldoende gelijkvormigheid in informatie en gedragsregels/methoden bestaat, kan de ontwerper de vermenigvuldiging van concrete klassen terugdraaien. Het verschil dat bijvoorbeeld betrekking heeft op de stap in een procedure, krijgt dan binnen de gemeenschappelijke klasse een plaats als waarde van een variabele, dat wil zeggen als een expliciete parameter voor gedrag van het object.

Mits gelijkvormigheid inderdaad realistisch is, komt er aldus een minimaal aantal klassen tevoorschijn. Er is echter niet meer dat zgn centrale object. Want aan het ontwerp ligt nu een bewuste abstractie ten grondslag. Daarmee is noodzakelijke verbijzondering in de vorm van een gerichte variabele erkend. Dit kan leiden tot eenvoudiger gereedschap. Het is waarschijnlijk ook altijd flexibeler, omdat met een nieuwe waarde van zo´n variabele simpeler te manipuleren valt dan met een hele nieuwe klasse. Zo is het de moeite waard om de totale inkoopprocedure te onderzoeken op mogelijkheden voor reductie van vermenigvuldiging via variabiliteit van een nieuwe, overkoepelende klasse. En dit is ook precies mijn ontwerp voor geautomatiseerde informatievoorziening volgens de methode van relationeel boekhouden. Mijn stelling luidt dat informatie in verschillende zgn fasen weliswaar uiteenlopende rollen vervult, maar dat wat abstracter beschouwd de vorm ervan en het gedrag van de objecten vergaand gelijk zijn. Ongeacht de fase geldt daarom één klasse voor objecten met de boekhoudkundige aantekeningen. Het blijkt dat via de ogenschijnlijke omweg van vermenigvuldiging uiteindelijk sterk vereenvoudigd gereedschap mogelijk is. Op vermenigvuldiging moet de ontwerper dan natuurlijk wel de reductie toepassen volgens de hier geschetste invalshoek van gelijkvormigheid.

Ik zei hiervoor, aan het begin van dit hoofdstuk, dat voorstanders van objectgerichte informatietechnologie (nog) te simpele voorstellingen van relevante milieus geven. Heb ik via mijn nuanceringen het nut van die technologie ondermijnd? Ik denk van niet, maar ik zie wel andere voordelen dan welke zoal in de modieuze presentaties voorgespiegeld worden. Omdat vele ontwerpers de noodzaak van vermenigvuldiging helaas niet erkennen, komen zij niet toe aan reductie die daarop kan volgen.

noten

1. Zie ook noot 10 in het vorige hoofdstuk.
2. Een heldere, algemene inleiding in toepassing van objectgerichte informatietechnologie geeft D.A. Taylor in zijn boeken Object-Oriented Technology: A Manager's Guide en Object-Oriented Information Systems: Planning and Implementation.
3. De nederlandse rijksdienst kampt met het probleem van onbeheerste vermenigvuldiging van informatie. Naar aanleiding van een kritische rapportage van de Algemene Rekenkamer, die overigens slechts papieren documenten had onderzocht, ondernamen het Ministerie van Binnenlandse Zaken en de Rijksarchiefdienst (destijds onderdeel van het Ministerie van Welzijn, Volksgezondheid en Cultuur, thans van het Ministerie van Onderwijs, Cultuur en Wetenschappen) van begin 1989 tot eind 1991 een project. Ik was als adviseur bij dat project archiefbeheer betrokken en stelde eveneens het boek Omslag in Opslag samen dat het gewijzigde beleid verklaart. Zie ook noot 1 in hoofdstuk 4, Ontwerper.
Het project was bijzonder interessant omdat een kleine projectgroep ruimte kon maken om de gesignaleerde problemen te ... problematiseren. De reflex van méér regels en voorschriften, waar toch niemand zich aan houdt, bleef daarom gelukkig achterwege. In plaats daarvan kreeg de vraag aandacht waarom informatie überhaupt opgeslagen, en zo ja, hoelang, danwel vernietigd, en zo ja, wanneer, zou moeten worden. Deze benadering leidde tot het inzicht dat er erkende belangen moeten zijn voor informatiebeheer. Over welke belangen relevant zijn alsmede hoe zwaar ze ten opzichte van elkaar wegen, bestaat altijd slechts voor een bepaalde situatie met haar processen (lees ook: milieu) een concrete uitkomst. Als voorzet geldt dat in vele overheidsprocessen voor informatievoorziening tenminste de volgende, elkaar overigens soms weer deels overlappende, belangen afgewogen moeten zijn:
— interne bedrijfsvoering
— externe verantwoording
— in- en voorlichting aan derden
— historisch onderzoek.
Dit beleid van pluriformiteit wijkt sterk af van dat van de eerdere uniforme regels voor archiefbeheer. Er is ten opzichte van de oude praktijk veeleer sprake van metaregels.
Omdat gaandeweg niemand aan de archiefzijde de zin van die uniforme regels meer ter discussie stelde, was de vermenigvuldiging van informatie doorgeschoten; er werd klakkeloos informatie bewaard zonder dat daarvoor een erkend belang aanwijsbaar was. Via betrokkenen in een bepaald milieu moet vermenigvuldiging binnen de grenzen blijven die door hun wèl erkende belangen gesteld worden. Het duurt natuurlijk nog lang voordat overal in de rijksdienst — en waarom niet ook elders? — mensen in hun praktijk daadwerkelijk informatiebeheer volgens de geschetste theorie inrichten. Een begin is echter gemaakt.
4. Dit is volgens de Comptabiliteitswet zelfs verplicht voor de nederlandse rijksdienst. (Het financiële aspect van) een bestelling en dergelijke heet een aangegane verplichting.
5. Hoewel de suggestie wellicht sterk is, meen ik dat ik mijzelf niet tegenspreek. Het model van objecten-in-context uit het vorige hoofdstuk voldoet mi eveneens voor een complex inkoopproces zoals ik dat hier als voorbeeld ontwikkel. Weliswaar is mijn uitwerking van objecten-in-context in het technische vlak extreem door het gebruik van slechts één klasse. Maar juist daardoor moet de gebruiker zijn, zeg maar, logische klassen expliciet definiëren. Dat moet hij via aanduidingen van — aanvullingen van de — context doen.
Hier toont zich dus een eventueel probleem in communicatie over wat een klasse met zijn objecten is.
6. Grote verbeteringen zijn haalbaar indien organisaties meer in termen van processen opgevat worden. Dat blijkt echter niet eenvoudig. Mensen identificeren zich gaarne met iets waaromheen zij ter vermeende bescherming een grens trekken. Als ontwerper van informatievoorziening kies ik ervoor om gereedschap zo open mogelijk te maken. Wie ooit een grens wil overwinnen, heeft dan tenminste niet zijn gereedschap als obstakel.