Dit is een hoofdstuk uit Aspecten en Fasen, in 1991 verschenen in boekvorm bij Information Dynamics.
Automatiseringsmiddelen heb ik met een apart hoofdstuk in deel IV, i.e. eveneens onder praktische onderwerpen, gerangschikt. Weliswaar kan relationeel boekhouden zonder dergelijke hulpmiddelen functioneren maar dit is in een wat complexere situatie al gauw onwerkbaar. Met hun toepassing moet standaardisatie van automatiseringsmiddelen uitgangspunt zijn. En op haar beurt wordt die bevorderd door een zogenaamde variabele of abstracte benadering. Daardoor zijn hulpmiddelen, met hun eventuele modulen, algemener toepasbaar.
De algemene(re) toepasbaarheid betekent niet dat modulen direct voor gebruik gereed zijn. Dat zijn zij juist weer niet. Iedere module is zonder toekenning van parameters als het ware onbestemd. Iedere variabele moet ingevuld zijn. Het specifiek gewenste gedrag wordt pas bereikt met relevante parameters.1
Wat dit inhoudt mag niet onderschat worden. Ik heb daarop enigszins geduid toen ik schreef over verschuiving van werkzaamheden van automatiseerders naar gewone, eigen medewerkers.2 Ik herhaal dat de hoeveelheid menselijke arbeid door zo'n verschuiving per saldo afneemt. Kàn afnemen. Maar voor eigen medewerkers komt er ten opzichte van traditionelere automatisering vooreerst werk bij. De parametrische vormgeving komt immers niet uit de lucht vallen. Daarvoor zijn verstandige keuzes nodig. De uitkomsten daarvan moeten vervolgens in de vorm van parameters opgenomen worden in de overeenkomstige modulen. Pas dan zijn modulen volledig toegerust voor specifiek gedrag.
Ik heb in hoofdstuk 6 documentaire technieken genoemd. Daarbij passen hulpmiddelen die zich bij uitstek voor parametrische vormgeving lenen. Voorbeelden zijn alom aanwezig. Eigenlijk zijn alle instelbare voorzieningen in meerdere of mindere mate te beschouwen als verschijnselen met parametrische vormgeving. Dat geldt voor een autostoel met verschillende standen, voor een schaakspel enzovoort. Gedrag is steeds mogelijk èn begrensd door de ingestelde stand. Dat wil zeggen, mede bepaald via de concrete parameters die aan variabelen toegekend zijn. Hoe meer variabelen er zijn, èn hoe omvangrijker hun betekenissenruimte, des te meer gedrag van middelen door instelling beïnvloed kan worden. En des te meer werkzaamheden van specialisten naar eigen medewerkers (kunnen) verschuiven.
Voor relationeel boekhouden heb ik voortdurend flexibiliteit beoogd. Dat heeft geleid tot instelbaarheid, en dus tot variabelen. Toegevoegde parameters bepalen vergaand het gedrag van bijbehorende (automatiserings)middelen.3 Ik heb geprobeerd deze variabele benadering niet extreem door te voeren. Er ligt steeds ergens een evenwicht. Zo maakt de bedoelde verschuiving het werk er voor eigen medewerkers niet eenvoudiger op. Maar waarom zou dat eenvoudig moeten zijn? Althans in de betekenis van stompzinnig. Dankzij toegenomen aandeel kunnen eigen medewerkers meer overzicht verkrijgen. Wat is financieel beheer als aspect van organisatie en processen? Met overzicht is het werk uiteindelijk juist niet ingewikkelder. Wanneer medewerkers begrijpen waarmee zij bezig zijn komt dat, andere factoren daargelaten, kwaliteit ten goede. Maar nogmaals, een variabele benadering moet niet zover doorgevoerd zijn dat eigen medewerkers alleen nog maar in combinaties van parameters moeten denken. Vanaf een bepaalde abstractie nemen praktische voordelen ervan weer af.4
Flexibele modulen verkrijgen dus (gedeeltelijk) door toekenning van parameters hun specifiek bedoelde gedrag. De verzameling van dat soort instelgegevens noem ik een parameterschema. Het is het meest overzichtelijk een parameterschema per module te onderscheiden. Ik richt mij hier vooral op faseboek en procedureboek. Daarmee komen karakteristieken van relationeel boekhouden het duidelijkst naar voren. Enkele opmerkingen over parameters voor andere modulen plaats ik hier onder deze twee noemers. Eigenlijk is een beschrijving van een parameterschema voor faseboeken reeds voldoende. Ik ga weer verder omdat juist procedureboeken de verwevenheid van het financiële aspect met overige schetsen.
Het is altijd de vraag of (de module voor) het procedureboek ook in de praktijk toegepast wordt. En zo ja, in hoeverre? Zonder automatiseringsmiddelen zijn dikwijls betere resultaten haalbaar. Handmatige administratie van voortgangsgegevens vereist evenwel ook een parameterschema. Maar een herkenbare verzameling ontbreekt daarvoor dikwijls. Door toepassing van procedureboeken te veronderstellen is een expliciet parameterschema onontkoombaar. In een situatie met onduidelijkheden is dat van groot belang. In een later stadium kan dan een beslissing volgen of bijbehorende automatiseringsmiddelen inderdaad operationeel gebruikt zullen worden. Anderzijds kan een proef ertoe leiden dat (bepaalde) modulen niet, of slechts voor beperkte gebeurtenissen, in operationeel gebruik genomen worden. Eén of ander parameterschema moet dan echter wel vastgesteld zijn. Automatisering of niet.
Ik begin met toelichting op (het gedeelte van) een parameterschema voor de boekhouding. Alleen financiële gegevens over definitieve transacties komen in de boekhouding terecht. Volgens relationeel boekhouden zijn er voor die aantekeningen faseboeken met rekeningen erin. Rekeningen in verschillende faseboeken kunnen door relaties verbonden zijn.
Eigenlijk heb ik de handleiding voor het opstellen van dit parameterschema al gegeven. Die had ik in een conceptversie van mijn tijdschriftartikel over de boekhoudkundige methode opgenomen. Dat gedeelte schrapte ik uit de definitieve versie maar in hoofdstuk 4 staat zij in een bewerking vermeld. Die handleiding blijft richtsnoer voor vaststelling van een parameterschema voor de boekhouding waarvoor de module voor het faseboek als automatiseringsmiddel geldt. In dat vroege stadium kende relationeel boekhouden echter het begrip dimensie nog niet. Daaraan pas ik hier de handleiding aan. Ik geef allereerst zeer beknopt de stappen weer waarlangs een parameterschema ingevuld kan worden. Vervolgens ga ik uitgebreider in op een onderdeel van dit parameterschema. Dat is het zogenaamde rekeningschema. Ik herhaal dat ik mij hier tot de boekhouding met faseboeken beperk. De module voor procedureboeken komt verderop aan de orde. De vormgeving van een parameterschema dáárvoor giet ik eveneens in de vorm van een handleiding (of procedure) met stappen waarna aanvullende toelichting volgt.
De beknopte handleiding voor de invulling van een parameterschema voor de module voor het faseboek behoeft dus nauwelijks aanpassing. Daartoe kan het volgende met de eerdere versie vergeleken worden. Inclusief vaststelling van parameters voor dimensies zijn de stappen nu:
1. Benoem de deelboekhoudingen in het netwerk. Bij iedere deelboekhouding
moet vermeld worden met welke andere verzamelingen uitwisseling van gegevens
kan geschieden.
2. Voor iedere deelboekhouding moeten dimensies aangegeven worden. Evenals deze
stap moeten alle volgende stappen per deelboekhouding gezet worden.
3. In een deelboekhouding kunnen diverse faseboeken ingericht worden. Welke
zijn dat?
4. Bepaal de verschillende sóórten relaties die tussen rekeningen mogelijk
zijn. Daarbij kan onderscheid naar horizontale en verticale relaties
aangehouden worden.
5. Benoem voor iedere deelboekhouding de gegevenswaarden van, i.e. parameters
voor, de elementen waaruit de identificaties van de rekeningen samengesteld
kunnen worden. Als onderdeel van een parameterschema noem ik dat een
rekeningschema.
6. Geef aan welke rekeningen in ieder faseboek bestaan. De unieke identificatie
van een rekening wordt opgebouwd uit de gegevens die uit de vorige stap zijn
verkregen. Vervolgens moet een rekening zonodig door relaties met andere
rekeningen verbonden worden. Dat gebeurt door de identificaties van die andere
rekeningen, in de vorm van expliciete verwijzingen, als gegevens over die ene
te beschouwen.
Het verschil met de eerdere versie van de handleiding is dat er een stap tussengevoegd is. Die is nodig om dimensies aan te geven. Voorts is de strekking van de laatste stap uitgebreid. Relationeel boekhouden kende eerder immers slechts één soort horizontale relatie. Die was impiciet een uitputtingsrelatie. Door toevoeging van dimensies kan een rekening door meer dan één horizontale relatie met andere verbonden zijn. Het aantal verticale relaties van een rekening was indertijd tot één beperkt. Ik ben in dat vlak eveneens de waarde van meervoudigheid gaan inzien. Daarom kunnen onder stap 6 van de handleiding/procedure desgewenst meerdere verticale relaties aangebracht worden.
Vergeleken met de eerdere handleiding is hetzelfde uiteraard gebleven dat naar omstandigheden parameters verwijderd, gewijzigd en/of toegevoegd moeten worden.
Als opmerking bij de eerste procedurestap geldt dat gegevensverkeer niet beperkt behoeft te zijn tussen gegevensverzamelingen in de zin van relationeel boekhouden. Dat wil zeggen, niet alleen tussen gelijksoortige faseboeken als verzamelingen. Dat is daar de bedoeling van de algemenere term (gegevens)verzameling. Daaronder vallen zonodig functionele administraties, bijzondere procesadministraties en dergelijke. Ook procedureboeken behoren daarbij gerekend te worden.
De eerste vier stappen hebben verder weinig toelichting nodig. De uitkomst van de eerste stap (benoem deelboekhoudingen) zal duidelijk zijn na mijn behandeling van delegatiepatronen in relatie tot financieel beheer in een organisatie. De keuze van dimensies, faseboeken en mogelijke relaties heb ik in deel III met voorbeelden toegelicht. Stap 2 tot en met 4 zijn meestal geholpen met het tekenen van schema's van boekencycli. Daarbij is het onverstandig voorbeelden klakkeloos over te nemen. Afgezien van wettelijke eisen moet het eigen karakter van een organisatie en haar processen zoveel mogelijk tot uitdrukking komen. Dat leidt misschien tot dimensies die ik in de voorbeelden niet heb voorzien. Hetzelfde geldt voor faseboeken en soorten relaties. Door een vrij vergaande variabele benadering is gewaarborgd dat keuzevrijheid bestaat om financieel beheer en bijbehorende informatievoorziening zo nauw mogelijk in processen als geheel te verweven.
Op de inhoud van stap 5 ga ik uitgebreider in. Daarvoor heb ik een paar redenen. In de eerste plaats overlappen bij een traditionelere benadering parameterschema en rekeningschema elkaar zo goed als geheel. Dat is in de loop der tijd weer zo'n impliciete ervaring geworden dat het mogelijke bestaan (of ontstaan?) van andere variabelen buiten het aandachtsveld bleef. In een handmatig gevoerde boekhouding staan rekeningen met hun unieke identificaties natuurlijk centraal maar dat is vaak zo gebleven. Geïnspireerd door kenmerkende eigenschappen van automatiseringsmiddelen toont relationeel boekhouden dat er talloze àndere parameters kunnen zijn. Tijdens bewerking kan ordening van gegevens diverse vormen aannemen. Daarentegen verschaft een traditioneel rekeningschema eigenlijk maar weinig mogelijkheden voor postcoördinatie.
Ik heb een tweede reden om uitgebreider op een rekeningschema in te gaan. Een veranderingsproces gericht op beter financieel beheer kan juist op invulling ervan stokken. Dat lijkt vreemd. Want zo ingewikkeld is het niet om in enkele gegevens één van de gewenste ordeningen te vertalen. Maar er ontstaat gauw een smal strijdtoneel voor perfectie. Verschillende medewerkers blijken hun eigen opvattingen over het optimale rekeningschema te koesteren. Daarvan kunnen zij dikwijls niet afwijken. Het is alsof opleiding en/of ervaring een onuitwisbare indruk hebben achtergelaten. Met hetzelfde zijn trouwens nog veel documentaire medewerkers behept als het gaat om ontsluiting. Een ware oorlog kan over alternatieve parameterschema's uitbreken. Terwijl de charme van postcoördinatie is dat uiteenlopende informatiebehoeften vergaand geëerbiedigd kunnen zijn.
Zo'n oorlog heeft uiteraard enige zin wanneer mogelijkheden van hulpmiddelen nogal beperkt zijn. Als een administratie handmatig gevoerd moet worden bepaalt het parameterschema meteen de enigst praktische toegang tot opgeslagen gegevens. Juist een documentaire benadering, nog versterkt door toepassing van automatiseringsmiddelen, leert dat die relatie losgelaten kan worden. Dat inzicht bestaat echter bij veel medewerkers nog niet. Wanneer ik pleit voor het loslaten van een parameterschema als mechanisme voor toegankelijkheid wordt dat als het preken van willekeur opgevat. De parameters, in dit geval een rekeningschema, bieden echter slechts schijn-zekerheid. Zonder ruimer inzicht komt daarvoor, met een benadering zoals ik voorsta, ogenschijnlijk onzekerheid voor in de plaats. Daar komt nog bij dat verzet tegen veranderingen vanzelfsprekend op bekend terrein georganiseerd wordt. Dat is voor financiële medewerkers hun favoriete rekeningschema. Zolang zij geen ruimer inzicht kunnen verwerven, zoals in de (grotere) vrijheid van (meer) postcoördinatie, blijft een rekeningschema altijd een lastig obstakel tijdens veranderingen. Dat was ooit een verrassing voor mij maar nu niet meer. En daarom is een proef weer zo belangrijk. Daarin kunnen medewerkers vertrouwen in een andere benadering krijgen zonder verantwoordelijkheid voor operationele resultaten. Wanneer het tijdens een proef met willekeur wel blijkt mee te vallen is deelname aan veranderingen geen keuze tussen valse indrukken van zekerheid en onzekerheid meer. Dàt vind ik de grootste betekenis van experimenten. Onzekerheid vermindert door het realiteitsgehalte van een toekomst te kunnen proeven.
Een rekeningschema beschouw ik als de verzameling parameters (voor de variabelen/elementen) waaruit identificaties van rekeningen samengesteld kunnen worden. Omdat ik relaties tussen rekeningen vertaal in verwijzingen in de vorm van hun unieke identificaties blijft een rekeningschema belangrijk. Dat belang is hierdoor echter wel degelijk gewijzigd.5
Met relaties tussen rekeningen kan (een relevant gedeelte van) het verloop van een proces op hoofdlijnen weerspiegeld worden. Maar is een rekeningschema daarvoor beslist noodzakelijk? De relaties tussen aantekeningen over definitieve transacties kunnen ook via andere gegevens gevestigd zijn. Volgens een documentaire benadering blijft met flexibele hulpmiddelen toegankelijkheid van gegevens immers zelfs met allerlei mits gemeenschappelijke gegevens gewaarborgd. Maar waarom zou ik aanvullende variabelen introduceren wanneer gangbare met een wat verschoven inhoud kunnen voldoen? Onnodige veranderingen betekenen onnodige risico's. Daarom heb ik het begrip rekeningschema gehandhaafd. Dat maakt nu evenwel onderdeel uit van een ruimer begrip, te weten dat van een parameterschema. Dankzij een rekeningschema zullen financiële medewerkers een zo vertrouwd mogelijke ordening van (financiële gegevens over) transacties blijven herkennen. In het ruimere verband van relationeel boekhouden en een meer omvattend parameterschema is daarmee de kous echter meestal niet af. Hierna volgen daarom nog meer opmerkingen over invulling van een rekeningschema.
Een boekingsregel wordt op een rekening aangetekend. Dat betekent dat de unieke identificatie van een rekening als gegeven in een boekingsregel moet voorkomen. In zijn traditionele betekenis is de identificatie van een rekening dus de noemer waaronder boekingsregels met hun overige gegevens geregistreerd zijn. De identificatie geeft daarmee de voornaamste ordening(smogelijkheden) van die aantekeningen over transacties weer. In een handmatige boekhouding zijn er tastbare rekeningkaarten, in welke vorm ook. Stel dat die opgeborgen staan op volgorde van hun identificatie, meestal een nummer. Het is dan alleen via het nummer van een rekening eenvoudig mogelijk financiële gegevens voor raportages te vinden. Dit kan door toepassing van automatiseringsmiddelen veranderen. Dan kunnen (financiële) gegevens op betrekkelijk eenvoudige wijze volgens aanvullende criteria toegankelijk zijn.6 Voor het benutten van de mogelijkheden van automatiseringsmiddelen voor financiële informatievoorziening mag daarom de samenhang tussen de rekeningidentificatie en de overige geregistreerde gegevens nooit uit het oog verloren worden. Desalniettemin beperk ik mij voorlopig tot rekeningidentificaties. De overige gegevens in een boekingsregel zijn (per definitie) geen onderdeel van een rekeningschema. Enkele daarvan kunnen als paramaters voor het procedureboek gezien worden. Zie verderop. Daarnaast besteed ik aan gegevens in een boekingsregel nogeens apart, en daar uitgebreid, aandacht in het volgende hoofdstuk.
De identificatie van een rekening, traditioneel meestal aangeduid als het rekeningnummer, zie ik praktisch uit enkele gegevenswaarden (parameters) van elementen samengesteld. Deze voorkeur volgt, evenmin als zovele andere, niet direct uit relationeel boekhouden als methode maar vergroot toepasbaarheid ervan. Want met een gelede rekeningidentificatie is flexibiliteit wederom gediend. Voor ieder element of bouwsteen volstaat een overzichtelijke (deel)verzameling parameters. Het maximale aantal identificaties en daarmee boekhoudkundige rekeningen is bepaald door combinatie: het resultaat van vermenigvuldiging van de aantallen opgegeven parameters pèr element. Met het aantal elementen loopt het maximum aantal rekeningen snel op. Voor iedere element afzonderlijk blijft de (deel)verzameling parameters echter overzichtelijk.
In theorie behoeft dat aantal elementen voor de opbouw van een rekeningidentificatie niet begrensd te zijn. In de praktijk heb ik nog geen situatie ontmoet waarin er meer dan vier nodig zijn. Hierbij wijs ik wèl nadrukkelijk op de betekenis die overige gegevens voor ordening en selectie kunnen hebben. De rekeningidentificatie behoeft niet meer als enige praktische waarborg voor toegankelijkheid van gegevens te dienen. Daarmee kan de betekenis van de identificatie inderdaad verschuiven naar het waarborgen van relaties tussen rekeningen. En dáárvoor heb ik vier elementen alleszins toereikend gevonden.
Het eerste van de vier is gereserveerd voor een aanduiding van het faseboek waarin de financiële gegevens over een definitieve transactie aangetekend worden. In de praktijk voldoen letters hiervoor prima. In voorbeelden heb ik reeds letteraanduidingen voor faseboeken genoemd. Dat zijn slechts voorstellen. Iedere organisatie kan een eigen betekenis voor wat een faseboek of, neutraler, een blok betreft aan een letter toekennen. Dan moet dezelfde letter echter wel voor het gehele netwerk van deelboekhoudingen van die organisatie dezelfde betekenis hebben. Ik beschouw dit element van de rekeningidentificatie immers als een impliciete verwijzing. Bij verschillende letters met dezelfde betekenis zijn expliciete verwijzingen nodig. Dat is onnodig gecompliceerd. Voor faseboeken vind ik standaardisatie van de betekenis van bijbehorende parameters realistisch.7 Dit eerste element van de rekeningidentificatie kent nog een nauw verband met de methode van relationeel boekhouden. Die stelt immers dat financiële gegevens over definitieve transacties in karakteristieke faseboeken horen. Door de parameter voor deze variabele is direct het specifieke faseboek bepaald.
In theorie kan een onbeperkt aantal andere elementen gelden. Hier verschaft boekhoudkundige praktijk echter vuistregels voor het optimale aantal. Vanuit de veronderstelling dat een rekeningidentificatie toch een voorname ordening van aantekeningen blijft weerspiegelen kan het aantal aanvullende elementen tot drie beperkt zijn. Dat zijn dus algemeen erkende ordeningscriteria. Ik noem ze in navolging van de gangbare praktijk van vooral bedrijfsadministraties kostensoort, kostenplaats respectievelijk kostendrager. Zij zijn strikt logisch gezien wederom algemeen bruikbare elementen waaraan naar omstandigheden een specifieke betekenis gehecht kan worden. Die komt dan in de keuze van parameters tot uitdrukking.
Een concrete rekeningidentificatie kan dus een combinatie van parameters voor fase(boek), kostensoort, kostenplaats en/of kostendrager zijn. Naar de aard van relationeel boekhouden is een parameter voor fase(boek) verplicht. Om praktische redenen stel ik dezelfde eis aan kostensoort. Kostenplaats en kostendrager kunnen facultatief ingevuld worden. Ondanks een beperkte hoeveelheid parameters voor ieder element afzonderlijk kunnen door combinatie vele rekeningidentificaties geconstrueerd worden. Of, omgekeerd, dankzij de vermenigvuldigingsfactor kan het aantal parameters pèr element zeer beperkt blijven. Dat bevordert de herkenbaarheid ervan en daarmee de kwaliteit van aantekeningen in belangrijke mate.8 En dat heeft weer een gunstige invloed op de kwaliteit van financieel beheer enzovoort.
Over de opbouw van een rekeningidentificatie uit parameters voor diverse variabelen/elementen heb ik nog twee aanvullende opmerkingen. De eerste betreft het effect van combinatie. Het aantal benodigde rekeningen met identificaties blijft in de praktijk vèr beneden wat maximaal door combinatie van beschikbare parameters mogelijk is. Dat komt omdat vele combinaties helemaal niet zinvol zijn. Enerzijds hebben sommige combinaties geen theoretische betekenis anderzijds ontbreekt van andere de praktische omdat er geen financiële gegevens op aangetekend (gaan) worden. Ik zou alleen een rekening (inclusief haar relaties met andere rekeningen) definieren indien het vrijwel zeker is dat daarop inderdaad boekingsregels zullen verschijnen. Ik heb daarover in verband met een rekeningen-generator al iets gezegd. Voor het werkelijke aantal (benodigde) rekeningen in verhouding tot het maximale aantal heb ik geen algemeen geldig kengetal. Dat is afhankelijk van omstandigheden. Ik heb wel een algemene richtlijn. Hoe meer processen in een organisatie van elkaar verschillen des te minder zinvolle combinaties van parameters er verhoudingsgewijs overblijven. Dat ligt uiteraard precies andersom bij zeer gelijksoortige processen.
Mijn tweede aanvullende opmerking over de opbouw van de rekeningidentificatie heeft betrekking op nevenschikking van kostensoort, kostenplaats en kostendrager. Ik heb begrepen dat vooral in bedrijfsadministraties deze elementen soms ná elkaar in beeld komen. Dan worden boekingsregels allereerst volgens kostensoorten geregistreerd. Aan de hand van een bepaalde sleutel volgt dan verdeling over kostenplaatsen. En vandaaruit eventueel nog een verdeling over kostendragers. Volgens mij zijn dergelijke periodieke verdelingen overbodig. Zij zijn tevens ongewenst omdat rapportages volgens kostenplaatsen en kostendragers dan niet actueel zijn. Wat is er tegen om de verdeling direct tijdens de eerste en enige registratie op operationeel niveau aan te geven? Misschien wordt het als extra werk gezien om in iedere relevante boekingsregel óók nog eens een kostenplaats en kostendrager op te geven. Dat is een redelijk argument wanneer de latere verdeling altijd dezelfde is. Dan is het inderdaad minder werk om periodiek te verdelen; het verlies aan actualiteit wordt kennelijk aanvaard. Een gelijkblijvende verdeling suggereert echter een routinematig proces. En daarvoor kunnen voorzieningen getroffen worden om de gewenste verdeling met eenmalig opgegeven parameters reeds tijdens registratie automatisch aan te geven. Daarmee komt het argument van extra werk te vervallen terwijl actualiteit van rapportages volgens aanvullende gegevens gewaarborgd is. Sommige parameters kunnen erop gericht zijn om invulling van boekingsregels te vergemakkelijken. Indien mogelijk behoeven ondermeer (bepaalde) gegevens voor elementen van een rekeningidentificatie slechts eenmalig opgegeven te worden. Die worden vervolgens steeds in voorkomende boekingsregels overgenomen. Daarmee blijft het menselijke werk inderdaad beperkt. Verderop geef ik daarop meer toelichting. Het is duidelijk dat zo'n opzet slechts opgaat voor routinematige processen. Maar dat geldt evenzo voor identieke verdeling die achteraf vanuit kostensoorten naar kostenplaatsen en tenslotte naar kostendragers geschiedt.
Ik kom weer terug op de moeilijkheid in veel organisaties om redelijk snel een nieuw rekeningschema vastgesteld te krijgen. Door betrokken medewerkers wordt vrijwel altijd nog de behoefte gesuggereerd dat zoiets als kostensoorten, kostenplaatsen en kostendragers universele betekenissen moeten dragen. Het is maar de vraag of die behoefte zinvol is. Vaak niet, vind ik. En dat die uniformiteit vrijwel overal onrealistisch is blijkt uit eindeloze discussies tussen medewerkers onderling. Hun interpretaties blijven botsen. Dat loopt vaak zo hoog op dat zonder gezichtsverlies niemand meer kan toegeven. Ik heb nogal moeten wennen aan de bijkans religieuze toewijding waarmee dergelijke interpretaties gehandhaafd blijven.
Relationeel boekhouden biedt op zichzelf geen uitweg. Door het uitlokken van een helderder zicht op enkele belangrijke begrippen kan het echter wel een dreigende impasse helpen vermijden. Het oplossen van een werkelijke impasse al alweer veel moeilijker. Dat is de zoveelste reden om zo vroeg mogelijk met een proef te beginnen waarin medewerkers zonder openlijke keuzes ervaring met andere situaties kunnen opdoen. Zo'n impasse behoeft zich, helaas, trouwens niet tot een rekeningschema te beperken. Elk gedeelte van een parameterschema biedt daarvoor een bijzondere bedreiging. Er wordt immers om expliciete keuzes gevraagd. Met traditionelere automatisering kan die verantwoordelijkheid ogenschijnlijk ontlopen worden. Is het werk van die automatiseerders niet onbegrijpelijk? De reële verantwoordelijkheid neemt daarmee echter niet af. Het specialisme van automatiseerders heeft evenwel tot zoveel begrip voor moeizame communicatie geleid dat medewerkers minder gauw aansprakelijk gesteld worden. Maar nogmaals, dat moet niet met reële verantwoordelijkheid en de noodzaak voor betrokkenheid verward worden. Een proef is een uitstekend middel om verantwoordelijkheid en aansprakelijkheid wederom bij de juiste medewerkers te laten samenkomen. Veranderkundig gezien is een proef daarom bijna een doel op zichzelf. Alles wat voor het welslagen van de proef nodig is geldt dan als middel. Dat is in dat stadium van veranderingen ook de plaats van automatiseringsmiddelen. Een pakket zoals ik in het vorige hoofdstuk bedoeld heb is direct als middel herkenbaar.
Ik vervolg met de vermeende noodzaak voor uniformiteit in een rekeningschema voor de gehele organisatie. Noodzaak ervan zie ik dus niet in. De betekenissen van kostensoorten en van eventueel benodigde kostenplaatsen en kostendragers kunnen per proces bepaald zijn. Een verder onderscheid is zelfs mogelijk naar deelboekhouding in combinatie met proces. Zo staat in hoofdstuk 26 over relaties dat de bestemming van een verantwoording als expliciete verwijzing opgegeven moet (kunnen) worden. Dat is beter omdat (financiële) informatiebehoeften per organisatorisch niveau kunnen verschillen. Door verdichting worden details weggelaten zodat de identificatie van een rekening in de hogere deelboekhouding wellicht geen parameter voor kostendrager meer bevat (of een meer omvattende betekenis heeft) terwijl in de rekeningen van een lagere als kostendrager bijvoorbeeld wordt gewerkt met aanduidingen van aparte projecten.
Voor de hand ligt het argument vóór uniformiteit dat gegevens over verschillende processen vergelijkbaar moeten zijn.9 Dat klopt mits de samenhang realistisch is. Ter bevordering van vergelijkbaarheid van financiële gegevens kunnen diverse maatregelen getroffen worden. Daarbij ga ik er bij wijze van (niet geheel willekeurig) voorbeeld vanuit dat kostendragers gebonden zijn aan een proces. Wanneer dat niet zo is gaat dezelfde redenering op maar moeten elementen van de rekeningidentificatie verwisseld worden. Indien kostensoorten en kostenplaatsen (eigenlijk netzogoed als fasen) in verschillende processen dezelfde betekenis hebben is het zeker verstandig daarvoor ook dezelfde parameters (lees ook: codes) te gebruiken. Uniformiteit kan voorts bereikt worden door verdichting als maatregel te zien. Wat in deelboekhoudingen op een lager niveau nog op verschillende rekeningen geboekt wordt kan via verdichting in een hogere deelboekhouding op één en dezelfde rekening terecht komen. Daarmee is een duidelijke verbinding gelegd.
Een extreem eenvoudige maar juist praktische aanpak voor het opstellen van een rekeningschema zie ik volgens het bovenstaande als volgt. Geef allereerst met letters aan welke faseboeken in een deelboekhouding horen. Bepaal vervolgens per (gedeelte van een) proces daarin parameters voor kostensoort, kostenplaats en/of kostendrager. Dit moet voor ieder betrokken niveau in het netwerk gebeuren. De parameters per proces en per deelboekhouding (of niveau) kunnen daarna met elkaar vergeleken worden. Zijn er geen overlappingen dan is daarmee het rekeningschema voltooid. Het is echter verstandig te kijken of dezelfde betekenis (indien dat voorkomt) van kostensoort en/of kostenplaats voor verschillende processen ook vertaald is in dezelfde parameters. Dat geldt dus ook voor kostendrager indien een ànder element de indeling van een proces weerspiegelt. Dat wil zeggen, wanneer projecten bijvoorbeeld als kostenplaatsen in plaats van als kostendragers benoemd zijn. Zijn identieke of vrijwel vergelijkbare betekenissen in dezelfde parameters voor de onderhavige elementen vertaald dan is het rekeningschema voor het gehele netwerk ècht klaar.
Zo kan het aantal elementen van de rekeningidentificatie inderdaad beperkt blijven. Door het streven naar uniformiteit ontstaan in een algemene opzet voor een rekeningidentificatie dikwijls gaten per proces. Maar wanneer geen vergelijkingen gemaakt behoeven te worden, of zelfs gemaakt kùnnen worden, kan een element van rekeningidentificatie pèr proces een eigen betekenis hebben. Het paradoxale van deze aanpak schuilt erin dat juist met onderscheid tussen processen een zo uniform mogelijk rekeningschema bereikbaar is. Ik ben geneigd dat weer als verschijnsel met algemenere geldigheid te zien. Door erkenning van verschillen komt grotere overeenstemming dichterbij. Of, omgekeerd, de kleinste verschillen kunnen zonder zicht op overeenkomsten uitgroeien tot complete verwijdering.
De eenduidigheid van betekenissen, indien toch gewenst en mogelijk, wordt bevorderd door simpelweg te inventariseren welke parameters reeds bestaan. Wanneer kostenplaatsen interne afdelingen zijn kunnen bijvoorbeeld de gestandaardiseerde afkortingen uit de interne telefoongids van een organisatie benut worden. Waarom niet? Over het algemeen verdienen herkenbare gegevens sterk de voorkeur. Wanneer die niet in andere taalgebieden begrepen moeten worden kunnen cijfermatige codes dus zoveel mogelijk achterwege blijven. Afkortingen zijn niet minder eenduidig dan cijfercodes en worden veel gemakkelijker onthouden. De kans op vergissingen is daarmee kleiner. Er is met postcoördinatie in het hoofd veel voor te zeggen bijvoorbeeld zelfs parameters voor kostensoorten niet met cijfers maar met mnemonische afkortingen te vormen. Als aanduiding van postzegels als kostensoort kan dan wellicht zoiets als PSTZ dienen. Bakstenen worden BKST. Enzovoort. Als voordeel van cijfercodes wordt veelal de mogelijkheid van samenhang daartussen gesuggereerd. Tijdens verdichting kan dan van bijvoorbeeld kostensoorten steeds het laatst overgebleven betekenisvolle cijfer vervallen. Maar er zijn andere en meer flexibele manieren om verbanden te leggen. Daarbij kan dus aan technieken gedacht worden die oorpronkelijk op het gebied van bibliotheek en documentatie ontwikkeld zijn. Het lijkt ongewoon voor financieel beheer maar een index op kostensoorten en/of allerlei andere variabelen biedt zeer praktische en interessante mogelijkheden voor aanvullende informatievoorziening. Aan de andere kant is het zo dat veel medewerkers zó vertrouwd zijn met cijfercodes voor vooral kostensoorten dat langdurige discussie hierover riskant is. Cijfercodes voor kostensoorten voldoen ook heel goed, en waarom dan niet? Teveel veranderingen tegelijk zijn niet produktief. In een later stadium kunnen altijd nog rekeningen met identificaties volgens een modernere opzet gedefineerd worden. Relationeel boekhouden is ook mogelijk met al dan niet overgeleverde cijfercodes. Ik kom hierop nog terug in toelichting op een strategie voor veranderingen en de bijzondere rol van een proef daarbij. Zie hoofdstuk 30 getiteld Overgang.
Stel dat een impasse over invulling van een rekeningschema onvermijdelijk is. Ik vermoed dat de problemen dan vooral spelen rond kostensoorten. In zo'n geval kan altijd op een klassieke indeling ervan teruggegrepen worden. Voor rijksinstellingen heb ik die evenwel niet kunnen ontdekken. Daarom heb ik daarvoor een algemene indeling afgeleid van commerciële boekhoudingen. Deze kan bij een impasse als voorstel dienen om tenminste een proef mee te beginnen. Dan gebeurt er iets praktisch; ervaring krijgt een kans. Daaruit blijkt gauw genoeg of de voorgestelde parameters financieel beheer van eigen processen geweld aandoen. Via eventuele aanpassingen kan de strijd om schijnbeginselen beslecht worden.
Om eens mee te beginnen kan voor een rijksinstelling de numerieke indeling van kostensoorten in hoofdgroepen bij een cijfermatige codering als volgt luiden:
0. vermogensbestanddelen
1. financiële rekeningen
2. derdenrekeningen
3. afschrijvingen
4. intern personeel
5. intern materieel
6. externe kosten/opbrengsten
7. idem
8. idem
9. sluit- en tussenrekeningen.
Het is raadzaam parameters voor kostensoort, kostenplaats en kostendrager te beperken tot hoofdlijnen van processen. Dat geldt natuurlijk helemaal voor fase(boeken). Zo blijft tevens een redelijke limiet voor het maximale aantal rekeningen behouden. Het is verleidelijk gedetailleerde aanwijzingen voor aantekeningen te verstrekken. Dat vertaalt zich meestal vooral in veel verschillende rekeningen. Daarop moeten fijnmazig gegevens over de veranderingen in het financiële aspect terecht komen. En dan, zo luidt de redenering, zijn exact gerichte rapportages mogelijk. Die verbeteren kwaliteit van financieel beheer en daarmee van processen in het algemeen.
Deze conclusie is bij toenemende detaillering steeds twijfelachtiger. De gedetailleerde informatiebehoeften worden doorgaans niet begrepen, of althans niet gedeeld, door registrerende medewerkers. Aan laatstbedoelde wordt gedetailleerde registratie opgelegd. Dit bevordert betrouwbaarheid allerminst. De kwaliteit van rapportages gebaseerd op (te) gedetailleerde registratie laat veel te wensen over omdat bij die registrerende medewerkers geen motivatie meer bestaat om de kwaliteit van hun registratie te waarborgen. Dergelijke rapportages lijken inzicht te verschaffen maar herbergen vaak nogal wat al dan niet opzettelijke fouten, verschrijvingen dus. Daardoor wordt het financiële aspect juist verkeerd voorgesteld.
Beperking tot hoofdlijnen stimuleert daarentegen kwaliteit van registratie, en dus van financieel beheer en bijbehorende informatievoorziening. In de gevallen dat gedetailleerd inzicht wèrkelijk vereist is, en dan gaat het bij nader inzien toch om uitzonderlijke behoeften, is meestal een statistische benadering veel waardevoller. En dat maakt financieel beheer per saldo eveneens goedkoper. Een steekproef van geringe omvang is doorgaans voldoende voor zinvolle interpretatie van financiële gegevens die oorspronkelijk slechts volgens hoofdlijnen van een proces geregistreerd zijn. Wetenschappelijke diepgang is daarvoor niet vereist. Wel kunnen andere gegevensverzamelingen, al dan niet in een computergeheugen beschikbaar, daarin een belangrijke rol spelen. Die bevatten dan andere, niet-financiële gegevens over al dan niet definitieve transacties in één of meer processen of gedeelten ervan. Dergelijke gegevens vormen dikwijls de sleutel tot gerichte en daardoor meer gedetailleerde rapportages.
Ik plaats hierbij als kanttekening dat hoofdlijnen een minimale tekening moeten laten zien. De mate van detail respectievelijk groepering in een netwerk van deelboekhoudingen moet immers mede afgestemd zijn op geldige wettelijke eisen. Een financiële verantwoording wordt (volgens die eisen!) niet op steekproeven gebaseerd. Maar op hun beurt moeten eisen voor detaillering van (finanicële) gegevens redelijk zijn. Een vraag naar teveel details wordt in de praktijk beantwoord met onbetrouwbare verantwoordingen. Het evenwicht komt in een rekeningschema tot uitdrukking. Overigens kan dàt soort evenwicht per faseboek gevarieerd worden. Betalingen zullen meer gedetailleerd aangetekend (moeten) worden dan bijvoorbeeld begrotingstoewijzingen voor jaarverplichtingen. Diverse rekeningen voor betalingen kunnen allemaal voor wat bijvoorbeeld uitputting betreft verwijzen naar één rekening voor aangegane verplichtingen. Enzovoort zodat over het algemeen detaillering van rekeningen met het temporale verloop op hoofdlijnen van een proces meegaat.
Een procedure heeft een definitieve transactie als uitkomst. Voor financieel beheer zijn uiteraard vooral procedures relevant die min of meer duurzame veranderingen in het financiële aspect betreffen. Maar niet alle definitieve transacties hebben die uitwerking. Een parameterschema voor procedureboeken moet daarom meer dan dat financiële aspect van processen kunnen weerspiegelen. Die ruime strekking moet zonodig aan de volgende handleiding gegeven worden:
1. Benoem de processen van de organisatie. Alle volgende stappen moeten voor
ieder proces doorlopen worden.
2. Bepaal de eenduidige deel-/tussenresultaten ofwel definitieve transacties in
soorten. Daarmee zijn eveneens soorten procedures bepaald. (Vergelijkbare
transacties en dus procedures behoren tot dezelfde soort.)
3. De werkverdeling in een (soort) procedure wordt in verschillende (soorten)
stappen vertaald. Welke stappen zijn er in iedere procedure? Wat is de
samenhang ertussen?
4. De werkzaamheden behorend bij één (soort) stap kunnen een gedifferentieerde
benadering vergen. Zonodig kunnen (soorten) acties per stap aangegeven worden.
Wat is de eventuele samenhang tussen acties binnen dezelfde stap? Kent een
actie verband met een actie in een andere stap, misschien in een andere
procedure?
De vertaling van het verloop van processen, en desgewenst niet alleen van het financiële aspect ervan, in parameters kan grof en eenvoudig zijn. Dit blijkt tenminste voor financieel beheer meestal voldoende. De procedures waarmee daarvoor relevante transacties tot stand komen zijn immers doorgaans gekenmerkt door achtereenvolgende stappen. Maar ik sluit een andere, lossere samenhang tussen stappen niet uit zolang de eenduidigheid van de uitkomst gewaarborgd blijft.
Bij een procedure kunnen medewerkers van diverse eenheden, zelfs op verschillende organisatorische niveaus, betrokken zijn. Ik vind echter dat een procedureboek de grenzen van een bepaalde eenheid niet mag overschrijden. Dat is te verwarrend. Het komt wel voor dat een hogere eenheid met één of meer stappen belast is. Maar het procedureboek is dan bij de lagere eenheid ondergebracht. Of omgekeerd. Hetzelfde geldt, al dan niet in combinatie hiermee, voor nevengeschikte eenheden. Voor hun eventuele stappen zijn al die andere eenheden als het ware te gast in het betrokken procedureboek van een ontvangende eenheid.10
Procedures, maar niet procedureboeken, kunnen dus verschillende organisatorische niveaus bestrijken. Dat ligt direct voor de hand voor procedures waarmee taakstellende bedragen verdeeld en vastgesteld worden. De formele toewijzing geschiedt van boven naar beneden. Op het hoogste niveau betreffen procedures begrotingen als totalen. Vervolgens wordt (zonodig) op dat hoogste niveau een eerste verdeling gemaakt. Dit mechanisme dat bij het financiële delegatiepatroon past voltrekt zich zonodig ook op lagere niveaus. Steeds volgen eenheden op overeenkomstige niveaus daarvoor benodigde procedures.
In het algemeen kan de verfijning met parameters naar omstandigheden opgevoerd worden. Bij een stap kan opgegeven worden of hij verplicht of facultatief is. In het laatste geval kan hij dus zonder bezwaar overgeslagen worden. Hetzelfde kan voor een actie bepaald worden. Acties verschaffen de module voor het procedureboek het potentieel van een centraal schakelpaneel. Een procedureboek als gegevensverzameling kan zeer beperkt blijven. Via een actie kan samenhang met andere gegevensverzamelingen bestaan en/of kan bewerking van gegevens in gang gezet worden. In haar eenvoudigste opzet betekent een actie slechts dat een betrokken medewerker enige handeling(en) bevestigt. In die zin geeft een actie aan waar een medewerker zijn paraaf moet plaatsen. Het maakt dan geen verschil of de gegevens van een procedureboek in een geautomatiseerde verzameling opgeslagen zijn of op papier. Dit laatste blijft vaak de voorkeur verdienen. Het is onzin automatiseringsmiddelen te gebruiken zonder dat er voordelen tegenover staan. En voor eenvoudige handelingen waarbij geen gegevens ontstaan die flexibel toegankelijk moeten blijven valt een handmatige aanpak altijd te prefereren. Ik herhaal daarom dat ik de module voor het procedureboek hier vooral als middel zie om een relevant parameterschema te ontdekken. Dat zicht op processen is ongeacht toepassing van automatiseringsmiddelen nodig.
Nadrukkelijk wijs ik erop dat parameters (in het algemeen) een verwachting weerspiegelen. Wat er wèrkelijk gebeurd is kan afwijken van zo'n verwachtingspatroon. Indien een afwijking waarschijnlijk geen incident is moet eventueel het parameterschema aangepast worden. Hoe danook moet aantekening over een incident, i.e. als er sprake is van een duurzame verandering van het financiële aspect, in de boekhouding volgen.
Tot dusver heb ik een wat ruimere betekenis aan procedureboeken gegeven. Zij hielden niet op bij gegevens over voortgang van gebeurtenissen. Ik veronderstelde dat procedureboeken tevens de voorlopige boekingsregels over de definitieve transactie-in-wording bevatten.
Wat een module omvat is weer een kwestie van smaak. Maar ook van flexibiliteit. Om het laatste poneer ik vèrder een aparte module voor voorlopige boekingsregels. Die extra gegevensverzameling is zonodig via procedureboeken bereikbaar. Ik licht hier toe welke parameters zoal voor specifiek gewenst gedrag van zo'n boekingsmodule nodig zijn. In de eerste plaats kunnen met de boekingsmodule de hoeveelheid werk alsmede fouten tijdens registratie beperkt worden. Dat geldt slechts voor routinematige procedures. Over bijzondere definitieve transacties zijn per definitie geen algemeen geldige (boekings)regels te verzinnen. Anders waren het geen uitzonderingen of incidenten. Wanneer een procedure vaak voorkomt, en dus dezelfde soort definitieve transactie, kan het lonen naar algemene regels of aanwijzingen voor de gegevens in bijbehorende boekingsregels te zoeken. Dat zijn dan weer parameters. Aan de hand daarvan kunnen boekingsregels zoveel mogelijk automatisch samengesteld worden. Bij ultieme routine zijn boekingsregels a priori compleet. Zelfs de bedragen van de definitieve transacties zijn blijkbaar altijd gelijk. Er zijn beslist procedures waarvoor dit geldt. Meestal dient echter tenminste het bedrag voor een afzonderlijke transactie nog opgegeven te worden. Met de procedure is vrijwel altijd wèl bekend op welke rekeningen de financiële gegevens na realisatie van de definitieve transactie aangetekend moeten worden. Dat wil zeggen, de rekeningidentificaties kunnen dikwijls als parameters voor de boekingsmodule gelden. Op eenzelfde manier kunnen andere gegevens in een boekingsregel nagelopen worden. De soort procedure respectievelijk transactie is per definitie bekend. Een belangrijk gegeven vind ik de identificatie van een zaak. Die hoort echter niet als parameter bij de boekingsmodule. Dezelfde soort procedure kan immers voor vele verschillende zaken doorlopen worden. Het is zelfs zo dat diezelfde soort procedure meervoudig in het kader van één zaak kan voorkomen. De uitkomst kan wel steeds anders zijn. Dit komt in ieder geval erop neer dat de zaakidentificatie voor een procedureboek steeds apart opgegeven moet worden. Die is daarvoor dus geen parameter, laat staan voor de boekingsmodule.
Algemeen betekent dat dat boekingsregels ook met parameters/gegevens buiten de boekingsmodule gevuld kunnen worden. Een belangrijk voorbeeld is dus een zaakidentificatie. Daaraan zijn in een aparte gegevensverzameling vaak weer àndere gegevens gekoppeld. In het bijzonder valt hierbij aan aanduidingen voor dimensies met bijhorend tijdvak te denken. Elders heb ik aangegeven dat iedere boekingsregel dergelijke gegevens moet bevatten. Welke dat zijn wordt bepaald door de dimensies van de rekening waarop de regel geboekt wordt. Onder een zaakidentificatie kunnen, indien aanwezig, parameters voor tijdvakken van relevante dimensies opgegeven zijn. Wanneer een zaakidentificatie in een boekingsregel verschijnt kunnen die gegevens uit die andere verzameling overgenomen worden. Dat verhoogt de kans dat ook over dimensies in boekingsregels consistente gegevens in faseboeken aangetekend staan. Of daarvoor benodigde parameters zèlf erin aanwezig zijn of niet, de automatische samenstelling van boekingsregels kan met zoiets als genoemde boekingsmodule geschieden.
Een tweede betekenis van de boekingsmodule heeft niets met parameters te maken. Vanwege haar belang wil ik die betekenis echter herhalen. Door toepassing van deze module zijn boekingsregels reeds in voorlopige vorm toegankelijk. Met erkenning van hun veranderlijke karakter kunnen deze gegevens belangrijk bijdragen aan de kwaliteit van financieel beheer.
Het is duidelijk dat succes van een rekeningen-generator als programma staat of valt bij variabiliteit. In het vorige hoofdstuk heb ik ook een computerprogramma voor geldtransacties genoemd als onderdeel/module van automatiseringsmiddelen voor relationeel boekhouden in wat ruimere zin. Die kan eveneens vergaand variabel opgezet zijn. Met dien verstande dat concrete betaalwijzen daaraan een duidelijke grens stellen. Voor wat die programma's betreft laat ik het hier bij deze algemene opmerkingen. Ik ga wel nog iets verder in op parameters voor het supplementenboek. In die verzameling kunnen gegevens eventueel via een procedureboek geregistreerd (en later opgehaald) worden. Registratie gebeurt dan met een actie in een stap. Bijgevolg wordt aan een supplement vormgegeven door parameters pèr (soort) actie. Dat kunnen gebruikelijke parameters zijn waarmee in een programma voor algemeen gegevensbeheer gewerkt wordt. Het verschil is dat alle bevoegde medewerkers supplementen (maar lees: gegevens in het algemeen) kunnen definiëren. Dat behoeft dus niet aan gespecialiseerde automatiseerders voorbehouden te blijven. En ik heb de dááropvolgende ontwikkelingsstap eveneens aangegeven. Een onderdeel van een bewerking kan als een gegeven gezien worden. In de vorm van een serie supplementen kunnen bevoegde medewerkers dan eveneens programma's parametrisch vormgeven.
Het resultaat van een bepaalde parameterkeuze is soms teleurstellend. Tijdens gebruik op proef moet eventueel gebrekkige werking van de automatiseringsmiddelen blijken. Dan kunnen tenminste weloverwogen keuzes gemaakt worden welke toepassingen wèl zinvol zijn. De variabiliteit van een hulpmiddel behoeft niet volledig benut te worden. Enige verkenning van mogelijkheden is daarentegen altijd nuttig. Dat versterkt vooral ook de uiteindelijke keuze van parameters en leert hoe die aan veranderende omstandigheden aangepast kunnen worden.
noten
1. Zie de paragraaf over materiaalkennis in hoofdstuk 4: "Als apparatuur en programmatuur betekenis aan dragers in het geheugen kunnen ontlenen is daardoor invloed op het gedrag van die hulpmiddelen mogelijk. Dergelijke gegevens noem ik parameters."
2. Zie de paragraaf over tegenstanders in het vorige hoofdstuk.
3. Programmatuur met haar instructies bepaalt gedrag eveneens. Enzovoort. Het gaat erom tegen welke achtergrond variabiliteit gemeten wordt. Ik meet hier ten opzichte van een gegeven pakket programmatuur. Ondermeer in noot 10 in hoofdstuk 4 wijs ik eveneens op de principiële betrekkelijkheid van variabiliteit.
4. Zoiets als een omslagpunt ligt waarschijnlijk bij ieder mens
ergens anders. Er is ook veel aan te doen om dàt punt te verschuiven. Ik vind
dat abstractie praktisch loont. Het verband met standaardisatie en modulariteit
heb ik reeds meermalen genoemd.
Een optimale verhouding, i.e. tussen gefixeerdheid en flexibiliteit, wordt bij
traditionelere automatisering vaak zelfs helemaal niet benaderd. Mijn artikel
over de exploitatie van documentaire technieken, bewerkt opgenomen in hoofdstuk
6, gaat daarover.
En ook dit is natuurlijk weer veel algemener dan automatisering. Op andere
terreinen is zoiets als (meer) variabiliteit al lang heel succesvol en dus
normaal. Maar hun commerciële succes maakt vele automatiseerders conservatief. Vruchtbare
invloeden vanuit andere terreinen worden dan niet herkend. En daarmee blijft de
kwaliteit van resultaten nog dikwijls op een te laag niveau steken.
5. En wijzigt nog meer zodra financiële gegevens op andere wijze samenhang verkrijgen. Hoelang is rekening als beeldspraak nog nodig om te verklaren wat een boekhouding is?
6. Principieel is dit verschil tussen handarbeid en automatisering natuurlijk weer niet. Dit wijst de geschiedenis van de bibliotheek duidelijk uit. Automatiseringsmiddelen verlagen echter de drempel voor bijvoorbeeld indexering, of voor letterlijk domweg dóórzoeken van een verzameling gegevens(dragers).
7. Zonder standaardisatie danwel expliciete verwijzing ontstaat verwarring wanneer aantekeningen uit een faseboek ter verantwoording (aggregatie/verdichting) aan een gelijksoortig faseboek op een hoger niveau in het netwerk doorgegeven moeten worden. En hetzelfde geldt uiteraard voor delegatie als taakstellende bedragen in omgekeerde richting doorgegeven worden.
8. Een inleiding tot het denken over vermijding van foutieve aantekeningen verschaft R.W. Bailey in Human Error in Computer Systems (Prentice-Hall, 1983).
9. Het omgekeerde argument hoor ik nooit, behalve van mijzelf. Uniformiteit van gegevensdragers suggereert dezelfde betekenissen. Een vergelijking tussen verschijnselen die niet meer als appels en peren, i.e. verschillend, herkenbaar zijn bergt juist gevaar.
10. Hiervoor kunnen automatiseringsmiddelen voor zogenaamde gespreide gegevensverwerking voorzieningen bieden.
1991, webeditie 2003 © Pieter Wisse