Toen mijn kinderen 1, 5 en 7 waren, kregen we onze eerste vaatwasser. Pas toen het niet meer hoefde, besefte ik hoe belastend dat half uur werk in de avondspits eigenlijk was. Jarenlang hadden we het gedaan, zonder erbij stil te staan dat het niet nodig was. Op dezelfde manier verzet elke burger een flinke hoeveelheid informatiewerk – omdat onze ‘cyberspace’ niet goed in elkaar is gezet. In dit stuk laten we zien wat dat is en hoe het anders kan.
Een werknemer van Emkabé koopt een boek bij Bol en declareert de kosten. Hij draait daartoe de factuur uit die Bol op zijn website beschikbaar maakt en uploadt die in het declaratiesysteem van Emkabé. Hij tikt aankoopdatum, bedrag en titel over en aan het eind van de maand keert het systeem de gemaakte onkosten uit – als zijn directe baas de aankoop goedkeurt.
De werknemer speelt een rol in twee gescheiden IT systemen: dat van Bol en dat van Emkabé. Hij heeft in beiden een account waarop hij kan inloggen. Eén en dezelfde gebeurtenis – de aankoop van een boek – laat een gegevensspoor achter in beide systemen. Diezelfde gebeurtenis moest dus twéémaal worden gerepresenteerd. De eenheid in de echte wereld is gedupliceerd èn gefragmenteerd vastgelegd in cyberspace. Gefragmenteerd, want geen van beide systemen geeft de werknemer inzicht in alle relevante gegevens (hij kan niet bij Bol zien of de aankoop vergoed werd en hij kan niet bij zijn werkgever zien waar het boek bezorgd werd).
Het zou handig zijn, als de werknemer al bij zijn aankoop bij Bol kon aangeven dat hij zijn werkgever verzoekt het bedrag te vergoeden. Dan kunnen we dubbele invoer voorkomen. Maar dat zou vereisen dat
- de werkgever óók een account had bij Bol (maar een ander soort account: niet als klant, maar als vergoeder);
- het vergoedingssysteem gegevens kan overnemen uit het systeem van Bol;
- en dat de vorm van die gegevens geschikt was voor beide systemen.
Bovendien moest het vergoedingssysteem periodiek inloggen op het systeem van Bol om alle aankopen waarvoor zijn werknemers vergoeding aangevraagd hebben, te downloaden. Maar het probleem is natuurlijk dat werknemers van Emkabé bij allerlei online boekhandels boeken aan kunnen schaffen. En ze tanken ook benzine. En ze vragen vergoeding van lunchkosten. En van telefoonkosten. Enzovoort, en zo verder. Om dat systeem te kunnen laten werken, moet Emkabé accounts nemen bij àl die bedrijven. En moeten àl die verkoopsystemen hun overdrachtsgegevens afstemmen op het vergoedingssysteem van Emkabé.
Zou het misschien beter andersom kunnen werken? Zou Bol niet beter automatisch de gegevens van zo’n aanschaf kunnen versturen aan het vergoedingssysteem van Emkabé? Maar ja, dan krijg je hetzelfde probleem omgekeerd terug. Want nu moet Bol inloggen bij Emkabé. En Bol heeft niet alleen te maken met Emkabé! Er zijn honderden, duizenden bedrijven wier werknemers bestellingen doen bij Bol en daar vergoeding voor van hun werkgever ontvangen.
Een fundamentele weeffout
Stijg in gedachten op en kijk naar het landschap onder je. Je ziet honderden, duizenden, honderdduizenden bedrijven als stippen in het landschap, elk met hun eigen verkoop- of onkostendeclaratiesysteem. Tussen die systemen bestaan verbindingen. Zo’n verbinding bestaat uit werknemers. Zij zijn de koppelstukken. Zij nemen met de hand informatie over uit het ene systeem en voeren het in het andere systeem in. Dat moet, in termen van uren, een ontzaglijke arbeid zijn. Er moeten ook lawines van fouten ontstaan.
De diepe oorzaak van dit verschijnsel is dat elk bedrijf automatiseert vanuit zijn eigen perspectief en dat bij elk bedrijf een aparte silo van informatie ontstaat.
Het belangrijkste probleem is niet de vorm van de gegevens. Dit voorbeeld – onkostendeclaratie – is tamelijk eenvoudig. Zelfs zonder een standaard zullen de meeste systemen al zijn uitgekomen op ongeveer dezelfde gegevensstructuur.
Het probleem is dat de verbinding via wederzijdse accounts tussen bedrijven onderling moet ontstaan – terwijl die bedrijven onderling niet handelen! Dat is cruciaal. Het is niet zo dat Emkabé interacteert met Bol. Een werknemer, die een rol speelt bij zowèl Bol àls Emkabé is de linking pin. De bedrijven hebben geen direct motief om te verbinden. Het zou een service zijn aan de werknemer, of aan de klant. Maar een service die veel moeite en hoofdbrekens zou kosten en daarom niet verleend wordt.
Dit patroon schetst de akelige situatie waarin wij, als burgers, ons bevinden. Want dit gaat niet alleen over onkostenvergoeding. Het gaat ook over verzekeringen, over scholen, gemeentes en andere overheden, schoorsteenvegers, glazenwassers, aannemers, enzovoort en zo verder. Alle organisaties waar een burger mee te maken heeft, die een rol spelen bij dezelfde zaak of gebeurtenis in het leven van de burger hebben zo’n indirecte relatie met elkaar. Nog wat voorbeelden: de bouw van een dakkapel (gemeente: vergunning; aannemer: uitvoering), het vegen van de schoorsteen (schoorsteenveger: vegen, verzekeraar: vergoeding bij brand), buitenschoolse opvang (BSO: opvang, overheid/werkgever: vergoeding), enzovoort.
Perspectives lost dit probleem geheel op.
Vanzelfsprekend Geïnformeerd
Het is niet moeilijk om te begrijpen waarom dat zo is, als je bereid bent om één van de geloofsartikelen van Perspectives te accepteren. Dat is: “elke gebruiker beschikt automatisch over alle gegevens op zijn eigen computer over een bepaalde context, die hij nodig heeft om zijn rol te kunnen spelen”. We noemen dit het principe van “Vanzelfsprekend Geïnformeerd” zijn.
Ga maar na. Beschouw de aankoop van een boek als een context (we noemen ‘m de Aankoop). Bij een Aankoop spelen een Koper en een Verkoper, alsmede een Artikel een rol. De Gebruiker-Rollen delen veel van de gegevens die een rol spelen bij een Aankoop. Toch zijn er verschillen: de Koper bijvoorbeeld, zal, als het een duur boek is, met een schuin oog naar zijn rekeningstand kijken. Die kan de Verkoper natuurlijk niet zien! En de Verkoper zal rekening moeten houden met de voorraad. De Koper hoeft niet te weten hoeveel exemplaren er nog in het magazijn liggen; te weten dat het op voorraad ìs, is voldoende.
Nu blijkt er nog een nuttige Gebruiker-Rol te zijn in deze context: de Vergoeder. Die rol hoeft niet te worden gevuld, maar het kàn wel. De Vergoeder heeft een beperkte hoeveelheid gegevens nodig: de prijs, de datum, de koper en de titel. Hij hoeft bijvoorbeeld niet te weten wie de Verkoper is. Evenmin hoeft hij, om zijn rol te spelen, te weten waar het boek afgeleverd moet worden, of wanneer.
Zodra de Koper zijn werkgever de rol van de Vergoeder geeft, beschikt die werkgever automatisch precies over alle informatie die hij nodig heeft om te besluiten of hij inderdaad zal vergoeden en dan aansluitend dat te doen. Dus:
- de werkgever hoeft geen ‘account’ te hebben bij de winkel, en
- hij hoeft geen proces in te richten om periodiek in te loggen op het winkelsysteem en vergoedingaanvragen te downloaden.
Sterker nog, zoals gezegd, de werkgever krijgt niet eens te weten in welke winkel er is gekocht!
Hoe gebruikt de werkgever die informatie dan? Hoe doet die zich aan hem voor? De werkgever speelt een rol in een context OnkostenVergoeding, waarin ook zijn werknemer een rol speelt. Bovendien heeft deze context een berekende rol VergoedingAanvragen. De berekening is tamelijk simpel: vind elke Aankoop
- waarbij de Koper de werknemer is;
- en die nog niet vergoed is.
Vergeten we hier niet het criterium dat de werkgever de Vergoeder is? Nee, want de werkgever beschikt alleen maar over Aankopen waarin hij die rol speelt – van andere Aankopen krijgt hij geen informatie!
Dit is in Perspectives een eenvoudige query, die wordt uitgevoerd op alle gegevens op de computer van de werkgever (merk op dat we hier tamelijk simpel over ‘de werkgever’ denken als één persoon. Een werkgever heeft vaak een rijke interne structuur, waarin er b.v. een functionaris is die over de onkostenadministratie gaat. Het verhaal blijft hetzelfde, zolang er een vertegenwoordiger van de werkgever is die de rol van Vergoeder speelt).
Elke Aankoop is een context, zoals we hebben gezien. Zo’n Aankoop vult een VergoedingAanvraag-rol in de context van de OnkostenVergoeding. De VergoedingAanvraag rol heeft één belangrijke ja/nee Property: vergoeden? Als de werkgever toestemt in de aanvraag, maakt hij deze Property gelijk aan ‘ja’.
De som van alle goedgekeurde VergoedingAanvragen is een (berekende) Property van de OnkostenVergoeding. Na screenen van de aanvragen voert de werkgever de Actie Uitbetalen uit. Uiteraard maakt deze Actie gebruik van het rekeningnummer van de Werknemer (waar de Werkgever natuurlijk al over beschikte).
De magie zit in automatische distributie
Hier valt geen speld tussen te krijgen – zolang je maar instemt met het aangehaalde principe van Vanzelfsprekend Geïnformeerd zijn. Stel dat je dat niet klakkeloos aanneemt, laat je dan overtuigen door onderstaande uitleg.
De Verkoper, Koper en Werkgever gebruiken allemaal Perspectives. Dat wil zeggen dat zij de Perspectives Distributed Runtime (PDR) op hun computers draaien (verderop leg ik uit dat dat geen eis is; maar het maakt de uitleg eenvoudiger).
Zodra de werknemer een boek gaat bestellen bij Bol, neemt hij de rol Koper op zich in een nieuwe Aankoop context die de PDR van Bol aanmaakt. De (webshop van de) winkel beschikt immers over alle gegevens van het boek. Dus de PDR van Bol maakt een context aan waarin de Verkoper, het Artikel en de Koper zijn ingevuld. Omdat de Koper een rol in die context speelt, stuurt de PDR van Bol die context op aan de PDR van de werknemer. Merk op dat Bol de identiteit en het adres van de werknemer moet kennen om de Koper-rol te vullen. Betekent dat dat de werknemer een account moet hebben bij Bol? Neen. Identiteit en Adres zijn voldoende en die worden door de (browser van de) PDR ingevuld in het formulier op de website.
Waarom moet de werknemer geen account nemen? Bol moet toch over betalingsgegevens en adresgegevens beschikken? Ja. Het model van de Aankoop beschrijft dat de Verkoper over die gegevens moet beschikken. Daarom verstuurt de PDR van de werknemer deze gegevens automatisch naar de PDR van Bol. Einde verhaal.
In principe kan hiermee de koop gesloten zijn. Een realistische inrichting van de Aankoop zaak zou waarschijnlijk nog een Actie aan de Koper aanbieden waarmee hij zijn aankoop definitief maakt (denk ook aan combinatie met andere aankopen, enz.). Dat zijn echter slechts versieringen.
Nu vult de werknemer zijn werkgever in bij de Vergoeder-Rol. Dat doet hij dus met een scherm op zijn eigen PDR. Hij heeft de identiteit van zijn werkgever al ergens beschikbaar (hij kan b.v. de context van zijn arbeidscontract opzoeken: daar speelt Emkabé de rol van Werkgever. De gebruiker kan die rol daar uit slepen). Zodra hij dat doet, bepaalt zijn PDR dat de PDR van Emkabé over de vergoedings-gegevens met betrekking tot de Aankoop moet beschikken en verstuurt die. Automatisch. En Bol? Die heeft met die vergoeding niets te maken en krijgt daar dus geen gegevens over. Daarmee is alle noodzakelijke gegevensoverdracht verricht en is het principe van Vanzelfsprekend Geïnformeerd zijn waargemaakt.
Het mag vreemd voorkomen dat Bol geen account van de werknemer (als koper) vereist. Maar – nemen we even aan dat Bol het geld incasseert – dat heeft hij niet nodig. Hij beschikt over alle gegevens om de bestelling te voltooien en zijn vergoeding te incasseren. Bij gebruik van Ideal is het verhaal iets anders. De koper treedt met de aankoopgegevens automatisch uit zijn context (verlaat de PDR) en begeeft zich naar de website van Ideal. Daar voltrekt hij de betaling en de webshop van Bol ontvangt de betaling. Bol registreert in de Aankoop dat er is betaald. Uiteraard stuurt de PDR van Bol dit gegeven door naar de Koper. Einde verhaal.
Deze situatie benadert kopen in een fysieke winkel veel dichter dan de traditionele webshops waar je een account moet nemen. Wie in een boekhandel staat, hoeft zijn naam enzovoort niet kenbaar te maken, als hij contant betaalt. In een fysieke winkel heb je geen ‘account’ nodig.
Zonder de Perspectives Distributed Runtime kan het ook
Bol heeft uiteraard al een webshop. Dat is een groot en goed functionerend systeem. Hoe verhoudt zich dat tot de PDR? Zoals boven aangegeven is het niet vereist dat Bol de Perspectives Distributed Runtime gebruikt. Zolang het webshop-programma het Perspectives Exchange Protocol (PEP) gebruikt, kan het communiceren met de PDR van de koper. Gebruik van PEP in een context als de Aankoop is eenvoudig. Waar de PDR het geldige model runtime, dus tijdens de interactie, interpreteert, moeten de webshop-bouwers het interpreteren terwijl ze een uitbreiding aan de webshop bouwen.
Perspectives: een kwantumsprong in kwaliteit
Kortom. Perspectives kan enorm bijdragen aan de kwaliteit van online dienstverlening door bedrijven en overheden, tegen een geringe inspanning van hun kant. Sterker nog, voor de organisaties is er een bijzonder groot voordeel te behalen en dat is veel hogere kwaliteit van klantgegevens. Ga maar na. Stel dat een klant van Bol een ander emailadres neemt (Bol gebruikt dat adres om promotiemails te versturen – uiteraard alleen als de klant daarmee akkoord is gegaan). De klant wijzigt zijn emailadres lokaal, in zijn eigen PDR. Alle gebruikers die een rol spelen die toegang geeft tot dat adres, worden automatisch door zijn PDR op de hoogte gesteld! Weg is het probleem van vervuilde klantgegevens. Uiteraard is het voor de burger óók een groot voordeel: hij hoeft niet bij al zijn accounts deze gegevens aan te passen!
Het huidige internet – de huidige cyberspace – is een verbrokkeld land met duizenden hekjes en gebiedjes. Door het dominante client-server model aan te vullen met het inherent gedistribueerde Perspectives, kan in korte tijd een enorme kwaliteitsslag gemaakt worden die zowel burgers als bedrijfsleven als overheid grote voordelen biedt.
Die vaatwasser scheelde een half uur quality time met mijn kinderen. Het was de beste investering ooit.