De pagina over het structuurmodel van RPM is in bewerking en de tekst hieronder is een kladversie. Illustraties zijn alleen nog schetsen. De pagina wordt later opgeknipt. Commentaar graag onderaan toevoegen.

Samenvatting

Van een methode voor organisatieontwikkeling mag je een structuurmodel verwachten dat aangeeft welke soorten formele verantwoordingsrelaties in een organisatie kunnen bestaan. Van oudsher gebruiken we een hiërarchisch model waarbij vanuit een enkelvoudige positie deelverantwoordelijkheden trapsgewijs gedelegeerd worden. In dat model bestaat bijvoorbeeld een onderscheid tussen lijn en staf, en het fenomeen van functionele lijnen. Het hiërarchische model voldoet in de praktijk echter steeds minder, omdat veel samenwerking en verantwoording niet langs verticale maar langs horizontale (proces)lijnen verloopt.

Voor RPM is daarom een nieuw structuurmodel ontwikkeld. Dat model vult de enkelvoudige hiërarchische organisatiestructuur aan tot een duale structuur. De hoofdbestanddelen in de duale structuur zijn de hiërarchie zoals we die kennen en het nieuwe element "teamnetwerk". Verder is er een rolmodel dat fungeert als bindmiddel tussen hiërarchie en teamnetwerk. Hiërarchie behoudt hierin zijn functie en kan ook in de praktijk ongewijzigd blijven, al heeft aanpassing vaak voordelen. Het teamnetwerk bestaat uit teams die naast hun primaire taken ook regeltaken en managementtaken hebben, en die horizontale en verticale relaties onderhouden met elkaar en met externe partijen.

Het model schrijft niet voor hoe een organisatiestructuur moet zijn, maar reikt bouwstenen en vuistregels aan. Daarmee kan, gegeven een procesmodel en een werkvolume, een teamnetwerk en een hiërarchie tot ontwikkeling komen. Eindverantwoordelijkheid voor processen wordt daarbij niet rechtstreeks ingevuld, maar via de tussenstap van het teamnetwerk. De onderdelen en de opzet van het model bieden daarbij voldoende vrijheidsgraden om op alle niveaus van een organisatie efficiënt en trefzeker tot een consistente toepassing te komen. Met een enkelvoudige hiërarchische structuur kan dat niet.

De introductie van een nieuw element in de formele structuur van organisaties (het teamnetwerk) is natuurlijk een risico. Er zijn voorbeelden van organisaties die zich dit eigen hebben gemaakt, maar ook van organisaties waar het op een zijspoor terecht is gekomen. Het risico lijkt beheersbaar als er initieel voldoende is geïnvesteerd in condities, communicatie en brede implementatie. Is een brede acceptatie bereikt dan blijkt terugval ook op lange termijn uit te kunnen blijven.

Het model is in de praktijk ontstaan en wordt sinds 1994 toegepast als beschrijftaal en ontwerptaal bij RPM-implementaties. Het is in de loop van de tijd getoetst en bijgesteld. Het aantal implementaties is echter nog beperkt. Het model is bovendien theoretisch nog maar beperkt onderbouwd, en dat geldt ook voor de RPM methode als geheel. Er is voornamelijk ontwikkeld op basis van praktijkervaring en algemene organisatiekundige kennis. Gericht literatuuronderzoek moet nog plaatsvinden.

Doel van het structuurmodel

Op de pagina's over het teammodel van RPM is een nog heel algemeen beeld geschetst van een team dat naast uitvoerende taken ook regeltaken heeft en managementtaken kan hebben. Een 'winkeltje' zou je kunnen zeggen, waarin naast de verkoop ook het beheer wordt gedaan. De vraag hoe de verbinding met het hoger management nu precies is, en hoe het bijvoorbeeld zit met afdelingsoverschrijdende teams, is daarbij nog even in het midden gelaten.

Als vervolg hierop zoomen we nu uit naar de organisatie als geheel. We schetsen een model van een organisatiestructuur waarin teams een duidelijke plaats hebben. Daarbij vegen we opnieuw de hiërarchische eenheden en de afdelingsoverschrijdend teams op één hoop. Dat heeft twee redenen.

De eerste reden is om te kunnen komen tot één beschrijftaal voor organisaties waarmee zowel de klassieke hiërarchische structuur kan worden beschreven als het meer hedendaagse beeld van een minder hiërarchisch netwerk. En bovendien alle tussenvormen. Het praktische nut daarvan is dat die beschrijftaal een drempel in organisatieontwikkeling wegneemt: om richting netwerk te ontwikkelen hoeft er dan geen 'knop om', er hoeft geen nieuw paradigma omarmd te worden. In plaats daarvan wordt het mogelijk om eerst maar eens de bestaande hiërarchische organisatie opnieuw te beschrijven (zonder deze aan te passen), en vervolgens in (kleine) stappen flexibel door te ontwikkelen. Nog een belangrijk voordeel van een beschrijftaal die binnen de context van een organisatie universeel is, is dat deze boven de discussies kan komen te staan en gemakkelijker onderdeel kan worden van de bedrijfscultuur. En bijgevolg met veel minder inspanning 'levend' gehouden kan worden.

Het tweede doel dat we nastreven bij het opstellen van een structuurmodel, is een rem te kunnen zetten op de neiging om bij toenemende veranderdruk ook vaker te gaan reorganiseren. Dat geeft namelijk altijd onrust, het leidt af van klanten en innovaties, en het bovendien valt het resultaat vaak tegen.

De route die we hier kiezen is ontkoppeling tussen hiërarchie en teamnetwerk. Je krijgt dan een duale structuur met enerzijds een relatief stabiele hiërarchie, en anderzijds een teamnetwerk dat de veranderingen opvangt door oprichten, opheffen, splitsen, samenvoegen, uitbreiden en inkrimpen van teams. Dat werkt natuurlijk alleen als het niet zoveel uitmaakt of een team afdelingsgebonden of afdelingsoverschrijdend is. Aan de andere kant moeten beide soorten teams helder en eenduidige verantwoordingslijnen hebben naar een eindverantwoordelijke positie in de hiërarchie. Anders heb je op voorhand de hiërarchie uitgekleed en ontneem je managers op hiërarchische posities de kans om verantwoordelijkheden te delegeren. Die verbinding mag echter niet inhouden dat teams binnen een afdeling moeten vallen.

Het introduceren en formaliseren van een duale structuur in de praktijk van een organisatie is geen sinecure. Het lijkt op het eerste gezicht de organisatie complexer te maken, en wie zit daar nou op te wachten. De keuze voor een duale structuur is echter juist ingegeven vanuit de praktijk, die altijd al complexer was dan de hiërarchische structuur. De toegenomen aandacht voor horizontale samenwerking (bedrijfsprocessen, verantwoording) vraagt als het ware om een aanvulling op de voornamelijk verticale structuren van de hiërarchie. Blijft staan dat het willen vervangen van de enkelvoudige formele hiërarchische structuur door een formele duale structuur vele vragen oproept. We zien dat als onvermijdelijk en zullen in de navolgende tekst onderzoeken welke vragen dat zijn en of die bevredigend beantwoord kunnen worden.

De structuurvorm van projectmanagement in lijnorganisaties, de matrix, lijkt misschien aangewezen, met procesmanagers op de plaats van projectmanagers. De aansturing van projecten en de aansturing van de lijn zijn echter vaak twee verschillende onderwerpen, terwijl procesmanagement zich juist met de core business van de lijn bemoeit. Dat is een fundamenteel verschil. Een matrix zet wel de vraag op scherp wie nu eigenlijk de baas is, maar reikt in zijn basisvorm geen model aan om die spanning om te zetten in een werkverdeling tussen managers.

Samenvattend: de uitdaging is om een structuurmodel te ontwerpen waarin 1) de klassieke hiërarchie een onderdeel is en zijn functie van verantwoordelijkheidsverdeling niet verliest, 2) waarin horizontale samenwerking en werken in teamverbanden zichtbaar wordt, en 3) waarmee het in de praktijk gemakkelijk wordt om verantwooordingsrelaties te leggen tussen het horizontale en het verticale.

Compatibel rolmodel voor koppelingen tussen hiërarchie en teamnetwerk

Om aan de voorwaarden (verticaal, horizontaal en verbonden) te voldoen, ontwerpen we een eenvoudig rolmodel met enkele bijbehorende vuistregels (zie ook de congrespaper Backward compatible management systems: linking process networks to formal hierarchy). De bedoeling is dat in de termen van dit rolmodel van ieder team in de organisatie beschreven kan worden hoe de hiërarchieverbinding is. Het moet dus universeel toepasbaar zijn, ook op teams die niet afdelingsoverschrijdend zijn.

De twee hoofdrollen in het rolmodel zijn ‘eindverantwoordelijke’ en ‘teamvoorzitter’ (dit zijn organisatiespecifieke benamingen die per toepassing anders gekozen kunnen worden). De eindverantwoordelijke heeft een positie in de formele hiërarchie. De vuistregel daarbij is dat hij of zij altijd de manager is waar alle verticale, hiërarchische lijnen vanuit het team samenkomen, ongeacht hoe hoog dat is. De teamvoorzitter is altijd een teamlid, maar is niet per definitie de hiërarchisch leidinggevende van de teamleden. De teamvoorzitter is altijd verantwoordelijk voor de communicatie in en rond het team. De eindverantwoordelijke en de teamvoorzitter zijn nooit dezelfde persoon. Als een team toevallig ook een hiërarchische afdeling is, en de afdelingschef teamvoorzitter is, dan zegt deze vuistregel dus dat de baas van die chef eindverantwoordelijk is en niet de chef zelf.

In het rolmodel wordt verder onderscheid gemaakt tussen drie soorten beslissingen die een eindverantwoordelijke zelf neemt òf delegeert aan andere managers òf aan de teamvoorzitter. Dat betreft beslissingen over 1) de samenstelling van het team ('wie', personeelsmanagement); 2) de resultaten die het team nastreeft ('wat', resultaatmanagement) en 3) de werkwijze ('hoe', procesmanagement). Of de eindverantwoordelijke de verantwoordelijkheid voor deze beslissingen delegeert hangt onder meer af van de mate van zelfsturing die bij het team past. Het enige wat een eindverantwoordelijke in dit rolmodel niet kan delegeren zijn specifieke taken die aan zijn hiërarchische positie verbonden zijn zoals inspireren van de betrokken managers en medewerkers, delegeren, en arbitreren als die managers en medewerkers met elkaar in conflict raken.

Samengevat:

Neem bijvoorbeeld een afdelingsoverschrijdend bedrijfsproces dat door de hele organisatie loopt. Het bijbehorende team heeft daardoor een zeer brede samenstelling. Wie is dan eindverantwoordelijk? Waarschijnlijk de directeur. Die beschikt waarschijnlijk niet over tijd en bijvoorbeeld niet over expertise om directe aansturing van het team op zich te nemen. Hij of zij delegeert dus alle drie beslistaken, overeenkomstig de bovenstaande vuistregels. De enige taken die overblijven zijn: inspireren, delegeren, arbitrage. Daar is hij in enkele uren per jaar mee klaar zodat het niet bezwaarlijk is om als directeur een pet als 'eindverantwoordelijke' voor dit team op te hebben. Of sterker, daardoor is er een goede 'stok achter de deur' voor alle andere betrokkenen: het proces mag dan afdelingsoverschrijdend zijn, het is beslist niet onbestuurd en krijgt serieuze aandacht van het management.

Met dit rolmodel kunnen zodoende vrijwel alle in de praktijk voorkomende varianten van zelfsturing bij teams globaal beschreven worden, van minimale zelfsturing (geen van de drie beslistaken gedelegeerd aan het team) tot vrijwel volledige autonomie (alle drie beslistaken gedelegeerd aan het team). Bovendien werkt dat ook bij 'klassieke' hiërarchische teams. Ook daar is immers sprake van een eindverantwoordelijke (de baas van de chef) die beslissingen al dan niet delegeert.

Teamnetwerk

Nu we in staat zijn om hiërarchie en teamnetwerk flexibel met elkaar te verbinden, kunnen we het structuurmodel aan beide kanten (hiërarchie en teamnetwerk) verder aanscherpen.

Om te beginnen zeggen we in het model nu dat alle primaire en ondersteunende werkzaamheden, alle management- en coördinatietaken en alle projecten altijd bij het werkpakket van één of meerdere teams horen. In de hiërarchische structuur wordt dan dus geen werk verricht, de hiërarchie is alleen een verdeling van verantwoordelijkheden. Managers maken hun uren in dit beeld als lid van een team, bijvoorbeeld het MT. Het voordeel van deze aangescherpte zienswijze is opnieuw dat we uitzonderingen kunnen vermijden. Bovendien wordt het structuurmodel er eenvoudiger van: ook MT's, CvB's, RvB's en directies zijn nu teams zoals alle andere.

Het teamnetwerk kan in meerdere opzichten flexibel zijn. Medewerkers mogen in principe lid zijn van meerdere teams, en teams mogen zijn samengesteld uit medewerkers uit verschillende takken van de hiërarchie. Teams kunnen ontstaan en opgeheven worden zonder veranderingen in de hiërarchie. Processen kunnen parallel of serieel over meerdere teams verdeeld zijn, afhankelijk van economische schaal, afstembehoefte, werkklimaat, geografische spreiding, etc. Het resulterende teamnetwerk kan zich met deze vrijheidsgraden gemakkelijker voegen naar behoeften en altijd veranderen omstandigheden.

Zodoende ontstaat een beeld van een relatief stabiele hiërarchie, die met een relatief grote span of control ook platter kan zijn dan voorheen. Daarmee verbonden zien we dan een flexibel en voortdurend veranderend netwerk van teams.

Visualisatie

Visualisatie [verplaatsen naar forum] van deze duale structuur is een vraagstuk apart. Een organogram is nu onvoldoende geworden. In het verband van RPM is geëxperimenteerd met enkele beeldtechnieken voor het in beeld brengen van een teamnetwerk.

- Een voorbeeld is te zien in de illustratie. Daarin is als uitgangspunt genomen dat grotere bedrijfsprocessen een hiërarchie van teams kennen. Die wordt afgebeeld door een hoger team om de deelteams heen te tekenen. Om de aandacht te richten op het bedrijfsproces krijgt het vierkante of de rechthoek van een team een pijlpunt zoals gebruikeljk in processchema's. Er worden echter geen verbindende lijnen getekend, dat zou het schema onnodig complex en onderhoudsgevoelig maken. Deelteams mogen in meerdere overkoepelende teams worden getekend. Een voordeel van deze tekentechniek is dat er relatief weinig netwerkinformatie in verwerkt wordt en een schema dus vrij snel te maken is en redelijk stabiel zal zijn. Het is zelfs mogelijk om net als met een organogram de hele organisatie in één keer af te beelden, maar dan kunnen sommige teams dus op meerdere plaatsten zichtbaar worden. Een nadeel is dat het echte netwerkkarakter (de horizontale werkrelaties tussen teams) niet goed te zien is.

- Een andere tekentechniek is om per team de relaties naar belanghebbenden in beeld te brengen met een sterdiagram (niet afgebeeld). Een voordeel daarvan is dat het netwerkkarakter dan zichtbaar wordt: het team is een knooppunt in het netwerk. Een nadeel is dat het volledige netwerk hiermee niet te visualiseren is, daarvoor zijn er te veel onderlinge relaties.

- Een derde tekentechniek is de metrokaart (niet afgebeeld). Daarmee een kluwen van bedrijfsprocessen nog redelijk ordelijk vertoond worden, terwijl ook het relatienetwerk vanuit een team herkenbaar wordt. Zie ook de RPM Winkel.

Bedrijfsprocessen

Als de kern van het structuurmodel bestaat uit hiërarchie en teamnetwerk, hoe zit het dan met de bedrijfsprocessen? Om deze vraag in het structuurmodel van RPM te kunnen beantwoorden nemen we de praktijk als uitgangspunt: hoe gaan organisaties om met bedrijfsprocessen, en is van daaruit een verbinding te leggen met ons structuurmodel?

In de praktijk zien we een onderscheid tussen twee manieren van ontwikkelen van bedrijfsprocessen. De eerste manier is maatwerk, en komt voort uit de wens om maatwerk aan klanten te leveren. Op basis van specifieke eisen aan de producten of diensten komt een procesontwerp tot stand, en dat wordt voortdurend bijgesteld om de gap tussen verwachtingen en prestatie dicht te houden.

De tweede manier van ontwikkelen van bedrijfsprocessen is het volgen van een standaard procesmodel. Dat gebeurt in toenemende mate in de vorm van procesblauwdrukken: normatieve modellen die voor een categorie van organisaties zeggen welke processen er moeten zijn en aan welke eisen ze moeten voldoen. Soms zijn ze voorgeschreven door de branche of de wetgever, soms zijn het best practices zonder formele status, soms zitten ze verpakt in ERP-software. Procesblauwdrukken zijn populair omdat ze procesontwikkeling goedkoper en trefzekerder kunnen maken, je hoeft het wiel niet uit te vinden en je benut de leereffecten van anderen.

Linksom of rechtsom, er ontstaat voor de interne communicatie meestal een schema met een overzicht van (hoofd)processen. Daarin staan vaak de onderlinge relaties voor input, output, aansturing en ondersteuning. Het schema geldt vaak als uitgangspunt voor stroomschema's, procedures, instructies, specificaties, functiebeschrijvingen etc.

De verbinding tussen dit overzicht van processen en de hiërarchie en teams is gevarieerd. Soms valt een proces binnen een afdeling, soms doorsnijdt het de hele organisatie. Soms is er een eindverantwoordelijke, soms niet. Soms is de eindverantwoordelijke een 'eigenaar' met hiërarchische bevoegdheden, soms is die verantwoordelijkheid beperkt tot coördinatie. De processtructuur benoemt soms hoeveel teams of medewerkers parallel hetzelfde werk doen in het proces, soms zie je dat pas als je de organisatiestructuur er bij pakt. Soms is de coördinatie- en overlegstructuur onderdeel van een proces, soms valt die ergens anders onder.

Wat betekent deze variëteit voor ons structuurmodel? In ieder geval dat de verbinding daarin tussen processen enerzijds en hiërarchie en teamnetwerk anderzijds niet het karakter kan hebben van een blauwdruk, dat zou het toepassingsgebied van ons model ernstig beperken. Variëteit betekent dat er keuzes gemaakt kunnen worden. Een standaard ligt dan niet in de uitkomsten maar in het keuzeproces zelf, in de ontwerp- en afstemprocessen waar het beeld van de bedrijfsprocessen en de verbindingen met posities en teams uit voortkomen. Ook die processen zijn gevarieerd, maar er kunnen enkele essentiële algemene vragen in gevonden worden:

1. Welk procesbeleid kiest een organisatie en waarom? Bijvoorbeeld: implementeren van een standaard procesmodel en voldoen aan de bijbehorende eisen, of zelfstandig realiseren van maatwerk in procesontwerp op basis van specificaties die met klanten zijn overeengekomen. In de waarom-vraag ligt de verbinding met de missie, strategie, omstandigheden en omgeving van de organisatie. Als antwoord op deze vraag willen we een argumentatie zie, bijvoorbeeld in een beleidsnotitie.

2. Wat zijn de (hoofd)processen van de organisatie? Deze vraag brengt ons bij de concrete uitkomst van het procesbeleid. We willen nu een globaal schema zien.

3. Hoe zijn deze processen verdeeld over de teams van de organisatie? Bijvoorbeeld: Proces 1 wordt door team A gedaan; proces 2 wordt parallel door de teams B, C, D en E gedaan en gecoördineerd door team F. Nu komen we dus aan bij de koppeling tussen processen en organisatiestructuur. We vragen daarbij eerst naar de verdeling van het werk over teams, en niet naar de eindverantwoordelijkheid. Dat geeft de mogelijkheid om de eindverantwoordelijke positie later af te leiden van de verdeling van het werk in de organisatie. zodat zeker gesteld kan worden dat alle delen van het proces binnen de hiërarchische eindverantwoordelijkheid vallen.

Het is niet ongebruikelijk om de processen van een organisatie los van de uitvoerende teams in kaart te brengen. Een processchema laat dan wel zien welke processen er zijn en hoe ze aan elkaar geschakeld zijn, maar niet hoeveel teams er parallel nodig zijn om een bepaalde processtap uit te voeren, en evenmin hoe de samenwerking tussen meerdere teams gecoördineerd wordt. Deze ontkoppeling is bijvoorbeeld zichtbaaar bij de procesblauwdrukken die veel gebruikt worden in management van IT-diensten. Een helpdesk wordt daarin vaak aangeduid als één proces, ongeacht hoeveel teams er een uitvoerende taak in hebben.

Als antwoord op de vraag hoe de processen verdeeld zijn over de teams willen we een tabel of een matrix zien. Eigenlijk is dat jammer. In theorie zou het teamnetwerk namelijk een exacte afspiegeling kunnen zijn van de bedrijfsprocessen. Een tabel of een matrix voor de onderlinge verbindingen is dan niet nodig, processen en teams passen dan één op één op elkaar. Dat vraagt dan echter wel dat alle managementprocessen in het procesmodel afzonderlijk benoemd worden, maar goed, dat zou kunnen, zeker als we flexibele verbindingen hebben tussen teams en hiërarchie. Toch heeft het geen zin om volledige congruentie tussen processen en teamnetwerk in een structuurmodel in te bouwen. De belangrijkste reden is dat schaalgrootte en paralleliteit in veel procesmodellen niet benoemd zijn. In de koppeling tussen procesmodel en teamnetwerk moet dus de vraag beantwoord worden hoeveel teams een bepaald proces implementeren en welk dat dan zijn. Verder kunnen er overgangssituaties zijn waarbij het teamnetwerk vooralsnog veel op de hiërarchie lijkt en pas later in de pas gaat lopen met het procesmodel.

4. Wie is eindverantwoordelijk voor een proces? Goed beschouwd zijn er nu drie structuren die we meer of minder tot de formele organisatiestructuur rekenen en die op een of andere wijze met elkaar in verband staan: hiërarchie, teamnetwerk en procesmodel. Voor het overzicht van die verbanden brengen we ze in een schema samen. De vraag wie eindverantwoordelijk is voor een proces (blauwe pijl) wordt niet rechtstreeks beantwoord. In plaats daarvan wordt eerst in kaart gebracht hoe het uitvoerende werk en de managementtaken van de processen over de aanwezige teams verdeeld zijn. Een proces kan daarbij samenvallen met een team of over meerdere teams verdeeld zijn. In het laatste geval is er altijd één team dat het proces coördineert. Vervolgens is van ieder team via de vuistregels van het rolmodel bekend op welke hiërarchische positie de eindverantwoordelijke te vinden is. Als een proces over meerdere teams loopt, komen we uit bij de eindverantwoordelijke van het coördinatieteam.

Laten we het procesmodel nu deel uitmaken van het structuurmodel van RPM? De keuze is om dat niet te doen. Een proces is geen deel van de organisatiestructuur maar een werkstroom die door de organisatiestructuur in stand wordt gehouden. Organisatiestructuur blijft dus duaal: hiërarchie plus teamnetwerk, onderling verbonden door een rolmodel. Het teamnetwerk kan daarbij in hoge mate aangepast worden aan het procesmodel, de hiërarchie in mindere mate. Bij een voortdurend variërend procesmodel hoort dus een flexibel teamnetwerk en een relatief stabiele hiërarchie.

Overlegstructuur

De meeste organisaties hebben een vergadercircuit. In allerlei verbanden wordt met wisselende intensiteit en frequentie vergaderd, over alle mogelijke onderwerpen van missie en strategie via organisatie, processen, projecten en incidenten tot de spreekwoordelijke inrichting van de fietsenstalling. Sommige vergaderingen zijn er voor de afstemming tussen hiërarchische posities, bijvoorbeeld een directievergadering of een afdelingsvergadering. Andere overlegvormen zijn verbonden aan processen, bijvoorbeeld verbeterteams of klantenpanels. Van de vergaderingen waarbij de voorzitter niet de directe leidinggevende is van de deelnemers, is er meestal een deel aan te wijzen dat zodanig structureel is dat het eigenlijk teams zijn. Dat wil zeggen: ze voeren een proces of een deelproces uit en doen ook de bijbehorende regeltaken of managementtaken. De vraag is nu hoe dit soort van structurele overlegsituaties aansluiten bij de duale organisatiestructuur die hiervoor geschetst is.

Net als bij processen willen we eigenlijk voorkomen dat we een uitbreiding moeten doen op het structuurmodel. Dat is al van enkelvoudig naar duaal gegaan en een derde element in de vorm van de overlegstructuur vinden we niet wenselijk. We onderzoeken daarom of we vergaderingen kunnen 'onderbrengen' bij de structuren die we al hebben.

Een manier om dat te doen is te stellen dat het organiseren en leiden van een vergadering gewoon werk is, werk dat deel uitmaakt van het werkpakket van een team. Zo bekeken kunnen alle vergaderingen die plaats vinden aan teams worden toegerekend, die doen immers volgens de hiervoor aangescherpte zienswijze al het werk in de organisatie. Het bijeenroepen en voorzitten van een afstemteam, bijvoorbeeld, hoort dan bij het werkpakket van het coördinatieteam van het proces in kwestie, net als de organisatie van een intern of extern klantenpanel.

Er blijft nu echter een categorie van vergaderingen over die wel wat zwaar zijn om aan een team toe te rekenen. Denk aan permanente commissies, raden, verbeterteams, vaste werkgroepen. Voor deze categorie kan overwogen worden om ze als een zelfstandig team door het leven te laten gaan. Dat betekent dat ze een eindverantwoordelijke krijgen, en dat deze met hulp van het rolmodel een aantal beslisrollen uitdeelt. Of dit praktische voordelen heeft, hangt af van de vraag hoeveel voltijdequivalenten (fte) het team telt, en hoeveel 'overhead' de status van team met zich mee brengt.

Een rekenvoorbeeld: een standaardisatiecommissie met leden uit drie verschillende afdelingen. De direct leidinggevenden van de commissieleden verdelen dan onderling de rol van procesveranwoordelijke en die van procesbeheerder. Ze komen 2 of 1 keer per jaar bijeen om de vorderingen van de commissie te bespreken. Met 3 betrokken afdelingen en 8 uur per vergadering (inclusief alle voor- en nawerk), dat zou dus circa 3 x 1,5 x 8 = 36 uur per jaar zijn, ofwel 36/1600 = 0,023 fte. De teamvoorzitter heeft er ook werk van: organiseren van overleg met de beslissers en opstellen/bijhouden van minimale teamdocumentatie op het intranet, bijvoorbeeld 8 uren overleg + 8 uren documentatie per jaar = 16 uur per jaar, ofwel 0,01 fte. Bij elkaar dus 0,033 fte. De commissie vergadert eens per maand en dat kost de deelnemers telkens een dag. Daar komt nog bij drie dagen per jaar congresbezoek, studiebezoeken en andere bezigheden buiten de deur. Totaal (10+3)*3*8 = 312 uur per jaar = 312/1600 = 0,195 fte. De extra overhead vanwege de teamstatus is dan 0,033/0,195 = 17%. Om te beoordelen of dat acceptabel is willen we weten wat de voordelen zijn van de teamstatus, wat schiet de commissie er mee op en wat heeft de organisatie er aan? Dat is lastiger in uren uit te drukken. Men komt bijvoorbeeld op:
- meer status in de organisatie, het onderwerp standaardisatie krijgt gewicht, de mensen kunnen de commissie gemakkelijker vinden;
- beter resultaatmanagement en betere kostenbeheersing omdat er systematisch naar voortgang gekeken wordt;
- meer aandacht van het management voor het onderwerp;
- betere organisatie van het werk, meer in lijn met de andere teams in de organisatie, daardoor soepeler samenwerking met andere teams en gemakkelijker inwerken van nieuwe commissieleden.
Over de vraag of dit opweegt tegen de 16 uur per jaar ofwel 17% extra overhead kunnen de betrokken managers aan de hand van deze gegevens wel een oordeel vormen. Vanuit de RPM methode doen we dat niet, omdat dan de grens tussen een methode en een ontwerp overschreden zou worden, en dat is niet de bedoeling.

De vraag was hoe structurele overlegsituaties aansluiten bij een duale organisatiestructuur. Het antwoord zou samengevat kunnen luiden: iedere reguliere overlegsituatie hoort bij het werk van een bepaald team OF het is een team op zich, waarbij de keuze afhangt van de omvang van het team in fte en de overhead vanwege de teamstatus. De overlegstructuur is dus een wezenlijk onderdeel van de organisatie, ook omdat het mede invulling geeft aan het teamnetwerk. Maar het is geen onderdeel van het formele en nog steeds duale structuurmodel.

Projectstructuur

[nog uitschrijven]

Aansluiting bij andere concepten

Wat betekent een duale organisatiestructuur voor andere structuurconcepten? We lopen er een aantal langs en proberen de vraag te beantwoorden welke voor- of nadelen een duale organisatiestructuur met zich mee brengt voor die concepten en hoe de aansluiting praktisch geregeld kan worden.

- Competentieprofielen
- Functiebeschrijvingen
- Reorganisaties, kantelen
- BPR
- RVE's, zelfsturende teams

Operationalisatie

[nog uitschrijven]

- methode voor ontwerpen van het teamnetwerk, uitgaande van benoemde bedrijfsprocessen
- checklist per standardproces, als aanvulling op de RPM-vragenset

werkwijze is: h=gegeven, p inventariseren, opsplitsen naar afdelingen, per afdeling teams formeren, interfaces tussen seriegeschakelde teams managen. Evt hierarchie kantelen.

werkwijze wordt: h=gegeven, p inventariseren, opsplitsen naar teams (TEAMS INDELEN), teams verbinden met hierarchie (ROLMODEL), interfaces tussen seriegeschakelde teams managen (DIALOOG). Evt hierarchie beperkt aanpassen (HIER ONTWERP).