Vormen van samenwerken en gewenste ondersteuning

Er wordt er steeds meer samengewerkt over de grenzen van de organisatie en landen heen. Steeds meer projecten worden bemenst door projectleden van verschillende organisaties. Zo wordt binnen het hoger onderwijs samenwerking steeds meer een noodzaak gegeven de toegenomen druk op de kwaliteit en focus van het onderwijs en onderzoek. Ook gemeenten hebben te maken met een toenemende noodzaak om te gaan samenwerken, ondermeer doordat hun budgetten onder druk staan maar ook door de decentralisaties in het sociale domein.

Deze brede ontwikkeling maakt het belangrijk om beter te begrijpen wat samenwerking precies betekent voor organisaties en hoe samenwerking middels informatievoorziening ondersteund kan worden. Samenwerking is nogal een containerwoord en het is dan ook belangrijk dit verder te ontleden. In het bijzonder is het belangrijk om te beseffen dat samenwerken en interactie in allerlei contexten en op allerlei niveau's speelt. 

In de context van een universiteit heb ik de volgende indeling van samenwerkingscontexten opgesteld (zie ook figuur):

  • Berichtuitwisseling tussen vrienden - dit gaat over het maken van vrienden en het in contact staan met vrienden, los van de context van een specifieke organisatie. In deze context spelen sociale netwerken zoals Twitter, Facebook en LinkedIn.
  • Organisatiebrede informatieuitwisseling - hier wisselen mensen informatie uit binnen een organisatie, maar los van een specifieke community, proces, project of vak. Het gaat dus vooral om meer algemene informatieuitwisseling en het leggen van contacten binnen de organisatie. Het begrip "enterpise social" moet vooral in deze context worden gepositioneerd.
  • Samenwerking in (keten)proces - deze vorm van samenwerking speelt zich af in de context van een formeel proces, dat afdelings- en organisatiegrenzen kan overschrijden. De deelnemers in de samenwerking zijn er gezamenlijk voor verantwoordelijk dat het proces werkt en tot de juiste resultaten komt. Denk bijvoorbeeld aan de studiefinancieringsketen, waarin zowel DUO als de instellingen een rol spelen.
  • Kennisdeling in community - bij deze samenwerkingsvorm staat de community centraal en is het hoofddoel het uitwisselen van kennis tussen de deelnemers in de community. Deze community kan zich binnen de organisatie bevinden, maar ook organisatiegrenzen overschrijden. 
  • Samenwerken aan producten in project - in deze context staat een project centraal. Projectmedewerkers hebben een gemeenschappelijk (project)doel en werken gemeenschappelijk aan producten die in het project moeten worden opgeleverd.
  • Samenwerken rondom een vak (leren) - hier staat een vak in het onderwijs (onderwijseenheid) centraal. Het gaat over de interacties die studenten en docenten hebben met elkaar bij het verzorgen/volgen van het vak, het maken van opdrachten en het beoordelen van werk. Didactiek speelt een belangrijke rol in deze samenwerkingsvorm.

Een belangrijke constatering is dat al deze samenwerkingscontexten een andere behoeften hebben aan ondersteuning middels functionaliteiten en gegevens. Om meer begrip te krijgen op de relatie tussen samenwerkingscontexten en functionaliteiten heb ik daarom de volgende tabel (in eerste concept) opgesteld. Deze tabel zal een leidraad zijn bij het inrichten van het enterprise portaal van de universiteit waarbij al deze vormen van samenwerking en interactie ondersteund dienen te worden. In meer algemene zin kun je de tabel zien als een informatielandschap, waarop de huidige en gewenste IV-ondersteuning zou kunnen plotten. Vanuit dat perspectief vormt de tabel een informatie-architectuur voor samenwerking. Overigens besef ik me dat ik ook nog relatief grofmazig kijk. Zo is er bijvoorbeeld voor de laatstgenoemde samenwerkingscontext (leren) een apart raamwerk opgesteld door de Sheffield Hallam universiteit (zie: http://t.co/mpkLBBZcGK).

Ik ben benieuwd of jullie de beschreven samenwerkingscontexten en de relatie met de functionaliteiten herkennen. Ook ben ik geïnteresseerd in jullie aanvullingen en verbeteringen op de tabel. 

Weergaven: 709

Reactie van Alcedo Coenen op 3 November 2014 op 16.47

Hoi Danny,

Mooi overzicht! Goeie taxonomie van samenwerkingsverbanden, heel bruikbaar in verschillende contexten denk ik.

Zo wat dingen die ik er niet in zie staan, maar wel associeer met samenwerken:

  • media delen (denk aan foto's, afbeeldingen, muziek, video's). Past bij vrienden, maar kan, afhankelijk van de professionele context, ook bij community en vak voorkomen.
  • samenwerken aan document (online). Zie ik vooral in projectverband gebeuren.
  • videogesprek zou ik ook bij "vrienden" verwachten
  • ik mis de hele categorie "publiceren", daarmee bedoel ik het maken en verspreiden van blaadjes, mailings, video's. Wordt vaak organisatiebreed gedaan, maar ook in projectverband. Je zou kunnen zeggen dat publiceren niet bij samenwerken hoort, maar in de praktijk is publiceren vaak een noodzakelijk onderdeel om mensen aan het samenwerken te krijgen.
  • online vergaderen en video conferencing. Bij project.

groet,

Alcedo

Reactie van Danny Greefhorst op 3 November 2014 op 16.53

Hi Alcedo,

Bedankt voor de feedback. Even korte terugkoppeling:

  • Delen media zie ik als onderdeel van "delen berichten"
  • Samenwerken aan documenten zit in "delen documenten" en "co-creëren kennis"
  • Videogesprekken met vrienden lijkt me inderdaad wel van toepassing
  • Publiceren is wat mij betreft inderdaad een andere categorie
  • Online vergaderen en video conferencing zit in "voeren videogesprek"

Groeten,

Danny

Reactie van Danny Greefhorst op 4 November 2014 op 7.44

Wellicht is "delen informatie" beter dan "delen berichten"; laat zien dat informatie meerdere vormen aan kan nemen en hint naar een vorm van publiceren (alhoewel "content publicatie" wat mij betreft geen samenwerkingsfunctionaliteit is). Plaatje heb ik er op aangepast...

Reactie van Wouter A. Blokdijk op 9 November 2014 op 15.24

Hoi Danny,

Zoals beloofd (op Twitter via @H2OTweets) hier mijn reactie.

Ik ben de afgelopen jaren wat mentaal aan het stoeien geweest over samenwerkingsverbanden (in een andere context dan 'het leren'). Ik vermoed dat er een bepaald paradigma is waar mijn ideeen vast al een keer zijn  uitgelegd, maar dit heb ik er van gebakken:

Ik zie vier lagen waarin  'jouw' samenwerkingsverbanden zich zullen uiten.

  • Inrichtings-laag (Factory layer)
  • Afspraak/Contract-laag (Contract layer)
  • Gebruik-laag (Usage layer)
  • Data aggregatie-laag (Aggragate/Analytical layer).

In elk van deze lagen komen de samenwerkingsverbanden voor als objecten, maar hebben een ander karakter en andere levenscyclus. Het geheel maakt dat deze bedrijfsobjecten goed met elkaar samenwerken (pun intended) over de lagen heen.

Belangrijkste twee lagen zijn de 'afspraak'/'contractlaag' en de gebruikslaag, de meeste informatiesystemen worden alleen ingericht voor deze twee lagen.

In de afspraak-laag regel je welke vorm van samenwerking er gaat komen en wordt de groep samengesteld en aan het eind weer 'ontmanteld'. Daarnaast is de gebruiks-laag natuurlijk heel belangrijk, want daar ben je gewoon aan het samenwerken.

Analyse en ontwerp blijft vaak bij deze twee lagen hangen, want de belangrijkste user-stories / use cases / customer journeys (of hoe men het tegenwoordig graag noemt) zullen zich hier uiten bij de productowners/stakeholders/opdrachtgevers.

Ik heb echter gemerkt dat het hebben van een goede Inrichtingslaag of factory-laag (omdat ik deze laag ) een heel andere kijk op de twee belangrijke lagen geeft en de contractlaag heel erg versimpelt. Immers dan ga je goed nadenken over de flexibiliteit in het samenwerken (vereist wel abstract denken van stakeholders). In deze laag bepaal je immers juist welke samenwerkingscombinaties en middelen (met ranges), je gaat toestaan binnen je systeem, die je vervolgens als prefab-opties kan aanbieden. En mocht je het willen kan je hier direct nieuwe samenwerkingscontexten inrichten (voor een nu nog niet bekend medium - hoor ik Internet of Things?), die je dan heel snel kan doorvoeren.

De laatste laag, met steeds grotere importantie is de data aggregatielaag. Dit is de laag waar meetgegevens over de samenwerkingsobjecten in de drie andere lagen bij elkaar komen. In de wereld van big data is dit steeds makkelijker te realiseren, maar ook hier komen dit soort gedachtes vaak pas na de inrichting van de andere lagen. Dat is natuurlijk jammer, want er zitten vaak andere (besturende) stakeholders op elke laag in de samenwerkingsverbanden. Maar we kennen allemaal wel de steeds weer op de backlog wegzakkende rapportage requirements. Toch is dit de feedback motor van het systeem (wat is populair, voldoet het nieuwe samenwerkingsverband, wat zijn populaire groepsgroottes en hoe succesvol zijn die).

Als je nu kijkt naar jouw invulling van het schema van de Sheffield Hallam universiteit, zie je dat je bij een paar van de voorbeelden bij een bepaalde laag horen, maar dat is niet helder. Ook zie je dat er lifecycle-achtige gedachten in schurken, maar ze zijn incompleet.

En om Alcedo ook nog te prikkelen. Ik denk dat bedrijfsregels op dezelfde wijze door deze lagen zouden moeten bewegen.

Ben benieuwd wat jullie er van vinden. :-)

Reactie van Danny Greefhorst op 9 November 2014 op 15.52

Hi Wouter,

Ik herken je lagen doordat ik recentelijk bezig ben met het opstellen van een bedrijfsfunctiemodel voor gemeenten waarin we samenwerking expliciet hebben gemaakt. Jouw lagen mappen daar redelijk goed op de functies die we hebben benoemd (zie hieronder, is in ontwikkeling). 

In het model onderscheiden we het vormen van een samenwerkingsverband, het bewaken van een samenwerkingsverband en het regisseren van een samenwerkingsverband. De samenwerkingsvormen die ik in mijn originele blog beschreef zitten in het domein "uitvoering".

Er wordt overigens in de context van de NL overheid veel over samenwerking beschreven zoals het katern ketensturing in NORA (http://www.noraonline.nl/wiki/Ketensturing). Dat gaat vooral met name over formele samenwerkingsvormen (samenwerkingscontext ketenproces).

Reactie van Alcedo Coenen op 9 November 2014 op 21.14
Hoi Wouter,
Vooral het onderscheid tussen Contract Layer en Usage Layer is bij business rules of, breder gezien, bij operational decision management(je uitdaging neem ik aan ;-) van bijzondere betekenis. Want een beslissing ontwerp je op twee niveaus: als soort beslissing of (mensen met een voldoende laag inkomen hebben recht op een uitkering van de gemeente) en als feitelijke beslissing (gemeente A kent mevrouw Jansen een uitkering x toe). Als ik jouw lagen goed interpreteer, behoort de eerste tot de Contract Layer, de tweede tot de Usage Layer. De eerste is de regel zoals die in de wet staat, de tweede is de juridische beschikking. De wet behoort tot de Contract Layer, de uitvoering tot de Usage layer.
Het verwarrende is nu wel, dat de "fabricage" (Factory layer) zowel kan slaan op het maken van de wet (wetgeving) als op het ontwerpen van de mogelijkheid om de wet uit te voeren (inrichting van de uitvoerende instantie). Daar zit, vanuit het perspectief van decision management, dus nog een laag tussen. Misschien is dat dan wel het onderscheid dat @Danny maakt tussen Sturing en Ontwikkeling.

Opmerking

Je moet lid zijn van Via Nova Architectura om reacties te kunnen toevoegen!

Wordt lid van Via Nova Architectura

Sponsoren

Advertenties

Je kunt hier adverteren

© 2019   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden