Samenwerking tussen organisaties en teams is erg belangrijk, maar gaat helaas ook vaak fout. Een recent rapport van Inspectie Justitie en Veiligheid concludeert bijvoorbeeld dat er grove fouten zijn gemaakt in de stalkingzaak van een jonge tiener omdat teams van “politie, Openbaar Ministerie, Veilig Thuis en de reclassering totaal niet goed hebben samengewerkt. Iedere organisatie deed zijn eigen taken, maar informatie werd niet veel uitgewisseld”.

Waarom wordt er niet beter samengewerkt in de praktijk? Veelal heeft dit te maken met onvoldoende contacten tussen teams en organisaties. Hoe kunnen deze potentiele samenwerkingsproblemen en hun oorzaken tijdig worden geïdentificeerd? Dit kan door de netwerkcontacten binnen en tussen de teams en organisaties in kaart te brengen met een zogenaamd Organizational Network Analyses (ONA). ONA is een people-analytics methode waarmee aan de hand van data over communicatie- en informatiestromingen grafische overzichten (plots) gemaakt kunnen worden van netwerkconnecties binnen en tussen teams en organisaties. In een ONA plot zijn de punten individuen en de lijnen (werk)connecties tussen deze individuen. Individuen van verschillende teams hebben vaak verschillende kleuren/vormen in ONA plots (zie bijgaande figuur).

Het bijgaande figuur geeft een (gesimplificeerde) ONA plot van een fictief softwarebedrijf met 5 teams, genaamd Software Testing, Design, Quality, Requirements, en Configuration. Uit de plot wordt duidelijk dat team “Software Testing” (in het roze) onvoldoende connecties heeft met de andere teams in de organisatie. Zoals je kunt zien is er veel connectiviteit binnen het team Software Testing, terwijl er geen connecties bestaan met andere teams in de organisatie (under-connectivity). Zonder deze externe contacten is een team onvoldoende in staat om te profiteren van de kennis en expertise van andere teams.

Het team moet daarom veel tijd investeren in het ontwikkelen van eigen expertise, omdat het geen toegang heeft tot de expertise van andere teams. Daarnaast is de kans groot dat het team niet op de hoogte is van de werkzaamheden van andere teams. Dit kan ertoe leiden dat het team dubbel werk uitvoert, wat samenwerking en prestaties negatief kan beïnvloeden.

Verder wordt duidelijk dat team “Software Requirements” (in het geel) ook een ineffectief samenwerkingsnetwerk heeft. Het probleem hier is een overvloed aan ongecoördineerde connecties met andere teams (uncoordinatedconnectivity). Verschillende teamleden onderhouden werkrelaties met collega’s uit andere teams. Het probleem is echter dat teamleden met externe connecties onderling geen contact hebben binnen het team. Eén teamlid kan daardoor bijvoorbeeld iets hebben afgesproken met bijvoorbeeld het team “Software Configuration” zonder dat zijn of haar teamleden hiervan op de hoogte zijn. Deze teamleden kunnen vervolgens onbewust andere en soms zelfs conflicterende afspraken maken met hetzelfde team, wat kan leiden tot inefficiënte en ineffectieve samenwerking. Niemand heeft de regie in deze situatie.

Het laatste type probleem ontstaat wanneer alle externe connecties door één teamlid worden onderhouden. In deze situatie is deze specifieke persoon overbelast met inter-team samenwerkingsactiviteiten, terwijl zijn of haar collega’s onderbelast zijn, omdat ze geen externe contacten onderhouden. Deze situatie is van toepassing op team “Software Design” (in het blauw) en team “Software Quality” (in het groen). Een bijkomede probleem voor Software Quality is dat de centrale persoon geen connecties onderhoudt met andere teamleden. Hoewel deze situatie niet direct tot problemen hoeft te leiden, is er wel een vergroot risico dat samenwerking wordt verstoord. Ten eerste kan de centrale persoon een bottleneck worden en samenwerking vertragen. Ten tweede is de samenwerking van dit team erg kwetsbaar. Wanneer de centrale persoon (“Campbell Rodgers” / “Alexis Chase”) het team zou verlaten zou het team geen connecties overhouden met andere teams en ontstaat het underconnectivity probleem waar Team Software Testing mee te maken heeft.

Toepassing in de praktijk

De inzet van ONA biedt potentieel om samenwerkingsproblemen tijdig te identificeren en op te lossen. Het is een flexibele methode die toepasbaar is op verschillende soorten communicatie- en informatiestromingendata. Het is ook mogelijk om met een korte vragenlijst direct aan medewerkers te vragen met wie ze samenwerken. Vervolgens kunnen deze gegevens worden gebruikt in ONAs om na te gaan hoe het complete samenwerkingsnetwerk van de organisatie eruitziet en of er interventies nodig zijn.

Tegelijkertijd zijn er een aantal uitdagingen. Ten eerste moet de privacy van medewerkers worden gewaarborgd. Het is daarom belangrijk om na te denken over hoe (en naar wie) ONA-resultaten worden gepresenteerd. Anonimiseren en aggregeren (naar clusters van personen) van data zijn vrijwel altijd noodzakelijk. Daarnaast moet er nagedacht worden over praktische vraagstukken, zoals wie er verantwoordelijk wordt gemaakt voor het uitvoeren en interpreteren van ONA netwerkplots. Meer hierover is te vinden in het boek “Driving results through social networks” (Cross & Thomas, 2008). Concrete tips hoe je ONAs kunt uitvoeren zijn beschreven in het boek “A User’s Guide to Network Analysis in R” (Luke, 2015).

Momenteel werk ik met een onderzoeksteam aan een project waarin we met ONAs uitzoeken wat voor samenwerkingsnetwerken teams van monteurs nodig hebben om snel verstoringen in het drinkwaterleidingsysteem om te kunnen lossen. Aan de hand van geanonimiseerde en aggregeerde communicatiedata vinden we dat monteurs verschillende samenwerkingsnetwerken nodig hebben voor verschillende situaties. Het lijkt erop dat complexe verstoringen vragen om gecentraliseerde samenwerkingsnetwerken, waarbij één of enkele monteurs de coördinatie tussen betrokken monteurs, bedrijven, en overheidsinstellingen organiseert als een soort tussenpersoon. Dit verkort de duur van de afhandeling van de verstoringen substantieel. Voor minder complexe verstoring is het echter sneller om zogenaamd ‘gedecentraliseerd’ samen te werken. Monteurs onderhouden dan direct contact met elkaar zonder tussenkomst van een tussenpersoon.

Thom de Vries (thom.de.vries rug.nl) is universitair docent aan de vakgroep Human Resource Management & Organizational Behavior van de Rijksuniversiteit Groningen. Hij doet onderzoek naar samenwerking binnen en tussen teams.

Identificeren van drie “typische” samenwerkingsproblemen

Er zijn drie klassieke samenwerkingsproblemen die gemakkelijk geïdentificeerd kunnen worden met een ONA plot. Het eerste probleem is under-connectivity. In dit geval heeft een team onvoldoende connecties met andere teams. Zonder deze connecties is de kans klein dat het team goed kan coördineren met andere teams binnen of buiten de organisatie omdat het onvoldoende toegang heeft tot de kennis van andere teams.

Het tweede probleem is uncoordinated connectivity. Dit ontstaat wanneer teamleden hun externe samenwerking onvoldoende coördineren binnen het team. Wanneer dit gebeurt is er weinig overzicht in het samenwerkingsproces, wat kan leiden tot conflicten, onduidelijkheden, en dubbel werk.

Het derde probleem is overloaded-connectivity. Dit ontstaat wanneer het team wel voldoende connecties heeft met andere teams, maar al deze connecties worden door één en dezelfde persoon onderhouden. Dat maakt het team kwetsbaar wanneer deze persoon zou vertrekken.