Betere ondersteuning van kenniswerk

De vorderingen van de werkgroep zijn zichtbaar op de wiki die hier voor is ingericht. Dit blog item beschrijft een tekst in wording in het boek waarin de relatie met technologie-ontwikkelingen wordt gelegd. Boodschap van dit stuk tekst is dat kenniswerkers beter ondersteund zouden moeten worden.

Op dit moment worden applicaties nog te veel gezien als mechanismen waarmee medewerkers volledig gestuurd kunnen worden. Ze zijn gebaseerd op een soort Tayloriaans model waarbij het uitgangspunt is dat elke eenheid van werk exact uitgespecificeerd moet worden, omdat mensen zelf onvoldoende in staat zijn om zelf na te denken en zich moeten vormen naar de organisatie. Bij het ontwikkelen en implementeren van applicaties wordt een gedetailleerde analyse gemaakt van processen, bedrijfsregels,  functionaliteiten en gegevens. Alle condities en uitzonderingen die kunnen optreden in processen worden in kaart gebracht en vertaald naar vastgelegde werkwijzen. Medewerkers worden gezien als een resource die een bepaalde activiteit in een proces uitvoert en die je kunt opschalen als de vraag toeneemt. Gegevens worden volledig uitgemodelleerd waarbij alle relevante relaties worden gelegd en alle mogelijke attributen worden geïnventariseerd. Het resulterende gegevensmodel wordt vertaald naar regels die verspreid zijn over allerlei plaatsen in de software en medewerkers dwingen zich aan het voorgedefinieerde model te houden.

Een dergelijke visie op applicaties is niet langer houdbaar om een aantal redenen. Het doet geen recht aan het feit dat het overgrote deel van de arbeidspopulatie bestaat uit kenniswerkers. Kenniswerkers onderscheiden zich door de kennisintensiviteit van hun werkzaamheden. Zij zijn het grootste deel van hun tijd bezig met het verzamelen, analyseren, synthetiseren en verspreiden van kennis in allerlei vormen. Dit werk vraagt vooral veel eigen kennis en inzicht van mensen en is ook in belangrijke mate onvoorspelbaar. Kenniswerkers hebben dan ook relatief veel vrijheid bij het bepalen van hun eigen werk. Werk dat niet in de categorie kenniswerk valt is in hoge mate voorspelbaar en herhaalbaar, waardoor het relatief eenvoudig te automatiseren is en ook steeds verder geautomatiseerd zal worden. Kenniswerkers worden daarentegen met name afgerekend op hun resultaat en hebben relatief veel eigen verantwoordelijkheid. Een dergelijke verantwoordelijkheid staat haaks op de ondersteuning van hun werk door applicaties die alles tot op de handeling voorschrijven. Het vraagt om applicaties die vrijheid geven daar waar de medewerker zelf verantwoordelijk is om te komen tot een resultaat.

Een belangrijk inzicht is verder dat kenniswerkers niet alleen vrijheid nodig hebben; zij moeten ook echt ondersteund worden in hun werk: het verzamelen, analyseren, synthetiseren en verspreiden van kennis. Het helpt niet om te sturen op resultaat als je vervolgens niet de juiste middelen aanreikt om dat resultaat mee te bereiken. Natuurlijk is er al wel allerlei software die samenwerking ondersteunt zoals wiki’s en sociale netwerken. In veel organisaties zijn dat soort middelen echter beperkt beschikbaar en in veel gevallen niet specifiek gericht op de ondersteuning van het primaire proces. Een visie op kennismanagement ontbreekt ook, terwijl dat de sleutel is tot een optimale ondersteuning van het kenniswerk. Ook zijn samenwerkingsfunctionaliteiten niet geïntegreerd in de huidige applicatieomgeving. Je moet als medewerker op zoek naar de juiste applicaties en bent in veel gevallen aangewezen op applicaties die in het algemeen op het Internet te vinden zijn. Samenwerkingsomgevingen binnen organisaties zijn vaak slecht ingericht en worden niet expliciet beheerd, waardoor ze uiteindelijk niet de juiste kennis bevatten en medewerkers ze al snel links laten liggen.

Een andere reden waarom “traditionele” applicaties niet meer zullen werken is omdat het gewoonweg veel te veel tijd en geld kost om ze te ontwikkelen en als ze eenmaal klaar zijn passen ze niet meer bij de eisen van dat moment. De softwarecrisis waar we ons al jarenlang in begeven lijkt wat dat betreft niet tot een eind te komen. Nog steeds worden er megaprojecten uitgevoerd die soms wel tien jaar lopen. De beweging rondom agile software-ontwikkeling heeft dit al langer erkent en ageert dan ook tegen een alomvattend ontwerp vooraf (“Big Design Up Front”). Overigens zegt dit nog steeds weinig over de complexiteit van het uiteindelijke systeem. In de gemeentelijke sector is ook erkend dat het niet wenselijk is om processen volledig uit te modelleren en te automatiseren; gemeenten hebben daar gewoonweg veel te veel producten en processen voor.

Dit alles leidt tot het principe: “applicaties bieden specifieke ondersteuning voor kenniswerk”. Een belangrijke consequentie van dit principe is dat er inzicht gecreëerd moet worden in de gewenste vrijheid alsook de noodzakelijke sturing. De vrijheid en verantwoordelijkheid van medewerkers moet maximaal worden benut, maar ook worden beperkt om te voldoen aan interne- of externe wet- en regelgeving en sturingsbehoeften. Denk bijvoorbeeld aan inzichten die managers, andere afdelingen, klanten of regelgevende instanties nodig hebben in het proces dat is gevolgd. Dit leidt tot een soort minimaal proces dat zich alleen richt op de belangrijkste statusovergangen. Dit is ook de kernboodschap van “zaakgericht werken” zoals dat wordt voorgesteld door het Kwaliteits Instituut Nederlandse Gemeenten (KING). Een zaak is gedefinieerd als "een samenhangende hoeveelheid werk met een gedefinieerde aanleiding en een gedefinieerd resultaat, waarvan kwaliteit en doorlooptijd bewaakt moeten worden". Een verzoek van een burger leidt tot een zaak; het werk dat bestuurd wordt door de organisatie. Bij de zaak wordt alle relevante informatie verzameld zoals alle relevante documenten, de status en het resultaat. Door een continu inzicht in de zaakstatus ontstaat er transparantie binnen de organisatie en richting de burger. Zaken volgen de statusovergangen die zijn aangegeven bij hun zaaktype. Voor gemeenten is er ook een standaard zaaktypecatalogus waarin alle mogelijke soorten zaken waar een gemeente mee wordt geconfronteerd in zijn beschreven.

Zaken worden afgehandeld door zaaksystemen; generieke systemen die alleen voorzien hoeven te worden van een zaaktypecatalogus en vervolgens direct inzetbaar zijn. Hierdoor is het niet meer noodzakelijk processen uit te modelleren en te implementeren in een workflowmanagementsysteem of in maatwerk programmatuur. In de meest extreme vorm wordt ook vakspecifieke procesondersteuning die normaliter deel uit maakt van een specifiek back-officesysteem ondergebracht in het zaaksysteem. Alhoewel het waarschijnlijk niet zover zal komen dat zaaksystemen alle andere soorten processystemen vervangen biedt de inzet van zaaksystemen wel een interessante visie op de inzet van applicaties. Een visie die op dit moment wordt verkondigt bij gemeenten, maar die ook in andere sectoren zeker tot interessante inzichten leidt. Al langere tijd wordt erkend dat workflowmanagement kan leiden tot verstarring van processen en dat “case management” in veel gevallen beter aansluit bij de processen. Dit is het algemene concept dat ten grondslag ligt aan “zaakgericht werken”. Het kernidee achter dit concept is dat de case (zaak) centraal staat en dat de volgorde waarin stappen worden uitgevoerd minder belangrijk is, zolang het proces maar eindigt met een goed resultaat. Er zijn wel bepaalde regels waar processen zich aan moeten houden en deze moeten expliciet worden beschreven. In de meest extreme vorm is een proces echter niet meer dan de regels zelf. Tezamen met de toestand van het proces bepalen ze de stappen die op een specifiek moment in tijd geldig zijn.

Ook op het gebied van gegevens is meer vrijheid noodzakelijk. Het is niet noodzakelijk om alle mogelijke objecten, attributen en relaties van tevoren te kennen en vast te leggen. Niet alle gegevens hoeven in gestructureerde vorm beschikbaar te zijn om ze te kunnen uitwisselen met andere applicaties of te rapporteren in enigerlei vorm. Een deel van de gegevens is alleen relevant voor de persoon of afdeling die de zaak behandelt of gedurende het behandelproces en kan weer worden verwijderd nadat dit proces is afgerond. Ook is het in een aantal gevallen voldoende om bepaalde informatie in meer vrije vorm te administreren, bijvoorbeeld omdat het vantevoren niet goed te voorspellen is welke waarden het kan aannemen. Veel gegevens zijn alleen relevant in specifieke gevallen en hoeven dus niet bij alle zaken te worden vastgelegd.

Daarnaast is een meer agile vorm van applicatie-ontwikkeling in het algemeen verstandig omdat organisaties nu eenmaal snel resultaat willen en de eisen anders inmiddels volledig zijn gewijzigd op het moment dat het systeem wordt opgeleverd. Er ontstaat meer ruimte voor opportunistische applicatie-ontwikkeling, waarbij heel snel bepaalde functionaliteit moet worden opgeleverd omdat er bijvoorbeeld behoefte is aan de uitwisseling van specifieke informatie. Steeds vaker ook wil de gebruiker dit zelf kunnen doen, zonder een IT afdeling die maanden nodig heeft om tot een resultaat te komen. In het verleden hadden gebruikers al de standaard kantoorsoftware waarmee snel bijvoorbeeld gegevens in spreadsheetvorm konden worden bijgehouden. Er is echter een nieuwe generatie kantoorsoftware gekomen die veel betere ondersteuning biedt voor samenwerking. Denk aan portaalachtige systemen waarin gebruikers heel snel zelf lijsten van gegevens en documenten kunnen aanmaken voor een specifiek doel. Semantische wiki’s zijn prima instrumenten om informatie mee te verrijken. Deze wiki’s kunnen echter ook prima gebruikt worden door gebruikers om hun eigen informatievoorziening mee in te richten, met name daar waar de nadruk ligt op kennisdeling. Door de gestructureerde gegevensopslag, gecombineerd met een formuliergenerator kan de gebruiker zelf samenwerkingsapplicaties realiseren. Het gegevensmodel hoeft vantevoren ook niet volledig bekend te zijn; het groeit met het gebruik van het systeem. Wiki pagina’s gebruiken ook alleen die objecten en attributen die ze nodig hebben, waardoor veranderingen in het gegevensmodel heel lokaal kunnen worden doorgevoerd.

Een andere belangrijke consequentie is dat samenwerking steeds verder doordringt in applicaties zelf. Vanuit het proces geredeneerd wordt beter nagedacht over de soorten interacties die betrokkenen hebben en op welke wijze deze kunnen worden ondersteund met software. Een goed voorbeeld van applicaties waarin dit idee al langere tijd wordt toegepast zijn zogenaamde “Elektronische Leeromgevingen” (ELOs). Dit zijn de kernapplicaties in het onderwijs en ondersteunen het primaire leerproces. Docenten ontwikkelen het onderwijsmateriaal in een ELO, inclusief de bijbehorende opgaven en eventuele toetsen. Lerenden (leerlingen, deelnemers, studenten) kunnen hier hun onderwijsmateriaal ophalen of zelfs on-line hun onderwijs volgen, maken hier hun toetsen en dienen hun huiswerk in via deze systemen. Het onderwijsproces zelf is een zeer interactief proces, waarbij er veel interactie is tussen docent en lerende en tussen lerenden onderling. Er zijn dan allerlei samenwerkingsfunctionaliteiten geïntegreerd in dit soort systemen om deze interacties te ondersteunen. Denk aan forumachtige functionaliteit waarmee lerenden onderling kunnen discussiëren, maar ook aan teleconferentiefunctionaliteit waarmee gebruikers direct met elkaar in contact staan en samen kunnen werken aan documenten.

Overigens levert deze rijke samenwerkingsfunctionaliteit in ELOs ook uitdagingen op voor onderwijsinstellingen. Deze overlapt namelijk met andere samenwerkingssystemen waardoor de vraag ontstaat welke samenwerking via welk systeem verloopt. Wat deze situatie niet eenvoudiger maakt is dat Microsoft en Google gratis e-mailsystemen inclusief samenwerkingsfuncties aanbieden aan onderwijsinstellingen. De lerende kan los van het ELO met deze systemen ook direct in contact komen met andere lerenden. Daarnaast zijn er in het algemeen op Internet ook al veel samenwerkingsapplicaties verkrijgbaar, in veel gevallen zonder kosten. Zo is er een groeiend aantal sociale netwerken, die in veel gevallen ook allerlei functies bieden door het uitwisselen van berichten en anderssoortige informatie. Het wordt daardoor belangrijk om goed na te denken welke vormen van samenwerking via welke applicaties ondersteund worden. Gebruikers zouden zich geen zorgen hoeven maken via welk systeem precies wordt samengewerkt, zolang de kennisuitwisseling maar effectief is.

Danny Greefhorst (dgreefhorst@archixl.nl) is principal consultant en mede-directeur bij ArchiXL.