Why the Dutch didn’t invent Holacracy

Actually, the Germans did……..

A fundamental concept of Holacracy is that it rejects consensus-finding;

… such impractical quantities of time and energy are required to reach a decision that the system gets bypassed more often than not. (..) Even when consensus is achieved, the result is often a watered-down group decision that becomes very difficult to change, saddling would-be innovators with less-than-ideal entrenched structures to navigate.

Brian Robertson in Holacracy – the new management system for a rapidly changing world, 2015.

In Holacracy meetings, people are brutally interrupted when the facilitator smells just a whiff of consensus-finding. What do YOU need? What is YOUR proposal? Whether or not framed within provocative oneliners like “Be selfish” and “Dare not to care”. For those who have been jaded for years with endless discussions and half-hearted decisions, this sounds like music to the ears. Of course, we all recognize the importance of broad support, but can this also be done in a less tiring way and a little faster? It is therefore very striking that this model is popular in countries that have pretty much invented consensus (f.e. in the Netherlands and Germany) The Dutch language even has a verb for this; polderen (the origin of this word has to do with land reclamation, the conquest of land from the water) As a Dutchman I’m aware of our directness and we do not mind hierarchy – we just ignore it.

So, why didn’t we, the Dutch, invented Holacracy? Frankly, I have to admit that the answer came before this question. And that was when I read a case study of a merger between a German and an American company in Erin Meyer’s book The Culture Map. Although both countries are egalitarian, they’re different in decision-making. The Germans are spending a lot of time and energy in the process towards a decision (consensus finding) and when a decision is made, the implementation plan moves expeditiously forward (because everybody is ‘on board’).

The Americans have a more top-down approach; one person makes the decision, and the energy and time is spent after the decision is made in rethinking, optimizing and adjusting the plan. For them, a decision is just a moment in time and perceived as the most suitable solution on that specific moment or in that specific circumstance. If more information becomes available, decisions can be reconsidered, and plans will change. This is in line with the characteristics of Holacracy; autocratic decision-making, striving for workability instead of perfection and focus on moving forward (knowing that after the first step things are different).

And the Dutch? We postpone the decision just that far until the moment we have to. And from that moment on, we will discuss everything again. I’m exaggerating, but …. yeah, we like to do both.

Erin Meyer writes;

Like other cultural characteristics, these different decision-making styles have historical roots. American pioneers who had fled from the hierarchical structures of their native lands in large numbers, valued speed and individualism. As the pioneers spread westward across the American plains, those who arrived first and worked the hardest were the most successful. Errors were seen as an unavoidable and ultimately insignificant side effect of speed. Because of this, Americans developed an aversion to too much discussion; in their view that only slowed them down. They preferred to make decisions quickly, often based on limited information, either through the leader or by voting.

The Culture Map, 2019

So, it is not surprising that an American ‘inventented’ Holacracy. In addition to his Scottish historical roots, Brian Robertson must have been inspired by a fellow American; Patrick Lencioni (with Italian ancestors).  Lencioni disdains consensus;

Consensus is horrible. I mean, if everyone really agrees on something and consensus comes about quickly and naturally, well that’s terrific. But that isn’t how it usually works, and so consensus becomes an attempt to please everyone.

The Five Dysfunctions of a Team, 2002.

But, as with so many things in America, its origins are in Europe. Holacracy is not an American invention either! (Yep, it’s of German origin)


Between 1850 and 1945 the Prussian/German army developed a form of agility and self-organization after they lost the battle of Jena against Napoleon in 1806 (more than 300,000 casualties) They started to drastically decentralize and place responsibilities and powers at the lowest level in the front line. They called this Auftragstaktik. Soldiers were given a specific assignment with a goal (Auftrag) but had to decide for themselves how to achieve the goal within the boundaries of the doctrine (the agreements on how we do certain things). The Prussians assumed that, if properly trained, their soldiers were professionals who themselves knew all too well what they could and could not do.

This Auftragstaktik resulted in the fact that in WWII the Allies needed a minimum of three divisions and air superiority to defeat one German division. Simply because the Germans had given more thought to what it is like to risk your life in the front line, what role your team plays in it, how important your manager is, how you can learn and innovate quickly, what role staff services play and what your organization has to arrange to increase the chances of survival of your people.

Notice the parallels with Holacracy:

  • Battlefield or the ‘work’ as the place where operations have to take place;
  • Combat unit or circle as an operating unit;
  • Goal or purpose as a desired outcome and reason of being;
  • Doctrine or constitution, domain & policies for smooth and effective operations;
  • Decentralization or autonomy in how to achieve the purpose through doing what’s necessary – even if it’s not your role;
  • Officer in the frontline or Lead Link as ‘an operational role’, holding the purpose of the circle;

Nevertheless, the Allies persisted in a completely centralized control of their army, with everything being worked out in advance through master plans, plans and sub-plans. To put it gently: it didn’t work that way on the battlefield (F.e. 5.2 million casualties among the Allies and 1.7 million among the Germans in WWI) nor is it working on the battlefields of business.

Jaap Jan Brouwer wrote a book about the history and concept of Auftragstaktik (Auftragstaktik en het Pruisische/Duitse leger 1850 – 1945 (Dutch) 2017). But this book has largely been described from a military perspective. The similarities with modern management perspectives are better reflected in the various articles you can find on this subject on the internet. In one of these articles you’ll also find that Auftragstaktik is (again) a hot topic within NATO military circles. The only country that continues to oppose this is … nope, not the Dutch but our former allies the United States.

This article is also published on Linkedin

Ik wil Uptime!

Iets meer dan honderd jaar geleden hadden fabrieken een eigen energie- en watervoorziening. Vervolgens zijn die voorzieningen overgenomen door utiliteitsbedrijven. Tot ongeveer tien jaar geleden hadden de meeste organisaties hun eigen datacenter. Nu hebben veel organisaties deze infrastructuur gemigreerd naar de ‘Cloud’ en is een trend zichtbaar waarbij organisatorische IT-functies geoutsourcet wordt. Dit betekent dat ook de lokale kennis van bedrijfsprocessen en daaraan gerelateerde IT-kennis ‘buiten de deur’ geplaatst wordt.

De services waarmee wij als IT dienstverlener deze trend binnen organisaties ondersteunen noemen wij Business Service Support. In een aantal artikelen worden het ‘waarom’, het ‘wat’ en het ‘hoe’ van Business Services uitgelegd.

Maar laat ik beginnen met de aanleiding.

Een ochtend in december..

Voor hem liggen de verschillende documenten keurig gerangschikt op tafel. Alle processen zijn doorgenomen, verantwoordelijkheden en processtappen zijn vastgelegd, servicelevels en KPI’s bepaald. Kortom, resteert nu nog het zetten van de handtekening.  

Hij kucht, neemt een slokje water: ‘Kijk, als jurist kan ik hier natuurlijk van alles van vinden.’ Even lijkt de eindstreep verder te liggen als hij vervolgt: ‘We hebben veel woorden besteed aan hoe jullie ons de diensten gaan verlenen en aan welke normenkaders en standaarden jullie je committeren.’ De documenten liggen nog geduldig op de tafel, maar ik vrees op ieder moment een brute armbeweging waarmee alle documenten op een hoop worden geveegd en als huiswerk aangeboden gaan worden. Maar dat gebeurt niet. Hij leunt achterover, kromt zijn vingers om het plastic bekertje met water. ‘Eigenlijk ben ik maar in één ding geïnteresseerd; uptime.’  

Op dat moment voelt het alsof de zorgvuldig opgestelde documenten en contracten plotsklaps in het niets verdwijnen. ‘Uptime’ als een zuigend zwart gat waaraan niets kan ontsnappen; al onze afspraken en procedures, uitleg over processen, alle gespecificeerde serviceniveaus en indicatoren. Op dat moment realiseer ik mij des te meer hoe wij, als IT-dienstverlener, ons identificeren met technisch jargon, ons koesteren met certificaten en audits, ons nestelen in best practises en normenkaders en verleidelijk kijken in de spiegel van indicatoren en metrics. Alsof ik in Andersens sprookje: ‘De nieuwe kleren van de keizer’ ben beland.  

ICT is als water uit de kraan; overal beschikbaar, toegankelijk en betrouwbaar. Net als het water uit de kraan en de stroom uit het stopcontact, wil ik mij niet druk maken over hoe dit mijn huishouden bereikt. Ik weet dat daar een hele industrie achter zit, met allerlei processen en technologieën. Maar uiteindelijk ben ik voornamelijk geïnteresseerd in de beschikbaarheid en de kosten van het verbruik. En voor menigeen is, met het oog op de klimaatproblematiek, de keuzemogelijkheid voor groene energie ook van belang.  

Eigenlijk is het raar dat de uitspraak ‘uptime’ mij enigszins uit evenwicht bracht. Hij is niet geïnteresseerd in welke processen wij allemaal hebben ingericht en hoe wij dat hebben ingericht, hij wil ‘gewoon’ dat het werkt. Hoe ongewoon kun je dat vinden?  

Doet ‘ie het of doet ‘ie het niet?

Wat water betekent voor leven, is IT dat voor werken. In nagenoeg elk beroep is men in meer of mindere mate afhankelijk van IT middelen. IT-dienstverleners gaan steeds meer de eindgebruiker ondersteunen in plaats van alleen de interne ICT-afdeling; het gaat meer over functionaliteit dan alleen over techniek. Dit heeft ook gevolgen voor de communicatie met klanten; heldere en begrijpelijke taal met minder, en het liefst geen technisch jargon. IT wordt hiermee als het ware ook voor de eindgebruiker een ‘binaire’ aangelegenheid; ‘hij doet het of hij doet het niet’.

En net als in het voorgenoemde voorbeeld van de nutsbedrijven, schuilt achter die binaire uitkomst een complexe wereld. Deze complexiteit wordt veroorzaakt door een grote diversiteit aan (cloud-)services en (hybride) datastructuren die op de fysieke IT middelen (Hardware, CI’s) gelaagd worden; de mobiel als een fantasmagorisch instrument waarmee alle denkbare functionaliteit letterlijk onder handbereik komt.

Het traditionele CMDB, het informatiesysteem waar het configuratie management alle informatie over configuratie items beheert, voldoet niet meer. Het zijn niet meer primair de CI’s die ‘de kracht van ICT’ bepalen. De uitdaging zit in het onderhouden van acurate informatie over alle relaties tussen CI’s en hierop ‘gelaagde’ services; een service-aware CMDB.


Een service-aware CMDB is de ‘eenhoorn’ in de wereld van servicemanagement – iedereen heeft er wel eens van gehoord, velen denken te weten wat het is, maar niemand heeft het echt gezien. Daarin willen wij van B&C verandering brengen.

Eerst wordt stilgestaan bij het contextgevoelige begrip ‘service’. Vervolgens wordt een framework beschreven voor het typeren van de verschillende services dat als basis dient voor het Service Data model (SDM). Van dit SDM wordt een praktijkvoorbeeld gegeven waarmee tevens een idee gegeven wordt van hoe ‘die eenhoorn’ – het servicegerichte of service-aware CMDB – eruit ziet.

Dit artikel besluit met de wijze waarop wij in samenwerking met klanten invulling geven aan een service-gerichte architectuur; Projectaanpak voor Business Services Support op basis van een service-aware CMDB.

Wat is een Service?

In het dagelijks taalgebruik wordt het woord service gebruikt als een beoordeling van hoe je de hulpvaardigheid van een ander ervaren hebt. Bijvoorbeeld, ze bieden daar een uitstekende service. Naast het product, is ook de interactie tussen aanbieder en afnemer en de omgeving, met alle vereisten die de interactie en het aanbieden mogelijk maken (het zogenaamde servicesysteem) van belang. 

Ook in het IT-jargon is service een veelgebruikte term. De formele definitie volgens ITIL luidt; ‘Een service is een manier om waarde te leveren aan klanten door klanten in staat te stellen de door hen gewenste resultaten te realiseren zonder zelf eigenaar te zijn van de specifieke kosten en/of risico’s die verbonden zijn aan de service’.  

De trend is dat steeds meer producten als een service aangeboden worden waarbij de risico’s zoveel mogelijk bij de aanbieder blijven. Veel jongeren kopen geen fiets, maar gebruiken een fiets tegen een vast maandtarief en als het licht het niet meer doet of de band lek is, wordt deze terplekke geswapt voor een andere fiets. 

Met betrekking tot IT-middelen is een vergelijkbare ontwikkeling zichtbaar; bijvoorbeeld het afnemen van een complete IT-infrastructuur bij een of meerdere Cloudproviders (Azure, IBM Cloud, Amazon) waarbij afgerekend wordt op basis van verbruik (bijvoorbeeld de hoeveelheid data die verbruikt is, het aantal transacties tussen systemen ed.) 

Kortom, een service verwijst naar een gebruiksrecht van een afnemer, terwijl het eigendomsrecht bij de aanbieder blijft. Een optimale exploitatie van het eigendomsrecht is afhankelijk van de mate waarin de afnemer het gemak, genot en gewin ervaart (de drie G’s), niet eenmalig maar continue.  

Sneller dan je schaduw..

Hoe houd je als IT-dienstverlener continue vinger aan de pols van de eindgebruiker? Hoe zorg je ervoor dat problemen sneller opgelost zijn dan de eindgebruiker er hinder van ondervindt? Hoe ben je de eindgebruiker steeds een stap voor? Kortom, hoe overtref je, steeds weer, de verwachtingen? 

Hoe beter onze kennis en inzicht in de doelen, processen en wensen van de organisatie en haar medewerkers, des te sneller en gerichter wij dit kunnen relateren aan de mogelijkheden van de onderliggende technologie. Een gemeenschappelijke ‘taal’ draagt bij aan een beter begrip waardoor oplossingen effectiever en efficiënter geboden kunnen worden. Het Service Data Model is zo’n gemeenschappelijke taal. 

Service Data Model

Het Service Data Model (SDM) vertegenwoordigt een gestandaardiseerde set van service-gerelateerde definities en is afgeleid van het Common Service Data Model van Servicenow. Het is een framework waarmee wij de informatie over technologie, diensten en dienstverlening vastleggen in ons IT Service Managementsysteem en in het CMDB modelleren en monitoren. Tevens dient het SDM als basis voor de communicatie met en rapportage aan klanten. 

De belangrijkste relevante onderdelen van het B&C SDM zijn; 

  • Business Capabilities
  • Business Services
  • Application & Technical Services
  • Configuration Items (CI’s)

Een Business Capability heeft betrekking op het ‘vermogen’ (mogelijkheden) en kwaliteiten die de organisatie nodig heeft om toegevoegde waarde te leveren aan haar afnemers. Een Business Capability bestaat uit mensen, kennis en processen. Binnen een organisatie kun je onderscheid maken in verschillende categorieën capabilities, bijvoorbeeld;

  • Producten en diensten die consumenten in staat stellen om iets te kopen;
  • Producten en diensten die consumenten in staat stellen om iets te zien en zich te abonneren; 
  • Producten en diensten die consumenten in staat stellen om iets te doen; 
  • Et cetera 

Voor elke categorie of type dienst/product zijn meerdere capabilities betrokken. Bijvoorbeeld, een webshop vraagt om capabilities op het gebied van klantondersteuning, verkoop, logistiek en IT. Kortom, business capabilities hebben betrekking op wat de organisatie ‘doet’ c.q. wat mensen ‘doen’ voor en in hun organisatie. 

Veel van deze capabilities worden in meer of mindere mate ondersteund door IT-functionaliteit. Dit zijn de zogenaamde Business Services; het IT-gereedschap’ van de eindgebruikers. Een Business Service wordt daarom ook uitgedrukt vanuit het perspectief en in de taal van de gebruiker! Een business service kan betrekking hebben op een enkelvoudige functionaliteit, bijvoorbeeld e-mail, maar ook op een functionaliteit waaraan meerdere services of functies ten grondslag liggen (bijvoorbeeld ‘authenticatie’). 

Een belangrijk aspect van een business service is de mate waarin deze bedrijfskritisch is; wat is de impact op de bedrijfsvoering wanneer de eindgebruiker geen of een verminderde beschikking over deze functie heeft? 

De Operationeel Manager van bedrijf X neemt contact met de servicedesk van B&C en meldt dat de printer het niet doet. De servicedesk medewerker registreert de melding en selecteert de business service ‘printing’. Met het inregelen van het contract is destijds de ‘criticality’ als laag bepaald (omdat er voldoende alternatieven zijn, bijvoorbeeld een andere printer selecteren). Een half uur later belt de desbetreffende manager weer en vraagt naar de status. Het gehele productieproces stokt omdat er geen productie- en orderformulieren geprint kunnen worden. De business service ‘printing’ heeft betrekking op kantoorprinters (waar er meerdere van zijn), met deze specifieke printer in de productiehal is, destijds bij de inventarisatie en analyse van de business services, geen rekening gehouden. In overleg met de servicemanager worden de volgende maatregelen genomen;  

  • Toevoegen van een nieuwe business service ‘production printing’ met de hoogste criticality (dit betekent dat bij de volgende melding meteen actie ondernomen wordt); 
  • Organiseren en implementeren van een workaround; in dit geval een extra productie printer (redundant) waar men in geval van een storing op kan overschakelen; 
  • Plannen van een periodieke failover test (maandelijks);   
  • Wijzigen van de bestaande business service ‘printing’ in ‘Office printing’ met ongewijzigde criticality;   

Business Services slaan een brug tussen de doelen/bedrijfsprocessen van een organisatie en de onderliggende technologie. In de hiervoor geschetste situatie wordt de onderliggende technologie gevormd door configuratie items zoals de productie printer, applicaties zoals Microsoft AX en meerdere technische/infrastructurele services, bijvoorbeeld de in CIM-omgeving geïntegreerde network services.  

In filosofische zin zorgt de business service voor een ‘dubbele verwijdering’; je hoeft de precieze werking niet te begrijpen om er mee te kunnen werken, en je hoeft het niet te bezitten om het te kunnen gebruiken. Kortom, achter de Business Service schuilt het technisch domein, met haar eigen vocabulaire (jargon) en gebruiken (best practises). 

Technisch domein

Binnen dit technisch domein heeft het begrip ‘services’ een andere context; de interactie tussen systemen dat volgens vooraf afgesproken protocollen verloopt. Het meest klassieke voorbeeld is het client/server model waar “services listen on open ports for clients to call” (C. Pitt & J. Wieland, Essential Information Security, 2013) 

Met het oog op die gemeenschappelijke taal tussen IT-dienstverlener en de eindgebruiker zijn de volgende ‘services’ relevant; 

Applicaties & Application Services

Een applicatie is een geïnstalleerd softwareprogramma dat specifieke functionaliteiten biedt. Deze applicatie kan geïnstalleerd zijn op een client, op een server binnen het bedrijf of in een extern datacenter. De wijze waarop die applicatie functionaliteit wordt aangeboden, noemen we een ‘Application Service’.  Zo is Microsoft Word wanneer als applicatie geïnstalleerd op een werkplek een applicatie en wanneer Word wordt aangeboden binnen Office 365 (online) dan wordt dit gezien als een Application Service.

Omdat eindgebruikers hun meldingen vaak relateren aan de applicatienaam (‘Word doet het niet’), vallen in die gevallen het perspectief van het technische domein (de applicaties en application services) samen met de business service (het perspectief van de gebruikersorganisatie) Het onderscheid tussen business services en application services is vooral van belang in het kader van het monitoren van de performance en het tijdig identificeren van gezondheids-issues van de application services (het zogenaamde event management proces). 

Technische Services

Waar application services zich middels de business service manifesteert aan de eindgebruikers, manifesteert een technische service zich aan de zogenaamde ‘service owner’ (de persoon/afdeling die verantwoordelijk is voor het leveren van specifieke technologie aan de business). Indien deze persoon of afdeling deel uitmaakt van de klantorganisatie, dan valt ook hier de technische service samen met de business service. 

Klantorganisatie Y heeft een eigen IT-afdeling die onder andere de netwerkinfrastructuur monitort. Hiertoe maakt men gebruik van de monitoring applicaties van B&C en van Cisco. Tevens zijn er afspraken gemaakt over de uptime van deze services en incident management. De technische service ‘network monitoring’ wordt ondersteund door twee application services (respectievelijk die van B&C en die van Cisco). Omdat deze technische services direct aan de klantorganisatie wordt aangeboden, is ‘network monitoring’ ook als business service geregistreerd. 

De meeste Technical Services ondersteunen één of meer Business Services of Application Services. Hieronder volgt een voorbeeld.

De Business Service ‘Werkplek’ heeft als doel om de eindgebruiker een veilige, beschikbare en goed presterende virtuele werkplek te bieden. Hiertoe wordt deze Business Service door meerdere Technical Services ondersteund, onder andere;

  • Anti-virus
  • Spamfiltering
  • Multi-factor authenticatie (MFA)

De verantwoordelijkheid voor het functioneren van deze Technical Services is toegewezen aan daarvoor in het leven geroepen rollen (vergelijk dit met functioneel applicatie beheer) binnen B&C. Omdat MFA optioneel is, maakt MFA deel uit van een zogenaamde Technical Service Offering dat in dit geval correspondeert met een Business Service Offering, namelijk ‘Werkplek Standaard (zonder MFA) en Werkplek Plus (incl. MFA).

Configuratie Items

Infrastructuurconfiguratie-items (CI) zijn fysieke en logische componenten van een infrastructuur die onder configuratiebeheer vallen. CI’s kunnen een enkele module zijn, zoals een server, database, router of complexere items zoals een compleet systeem (bijvoorbeeld webserver, database, infrastructuur). De meeste CMDB’s beperken zich tot het beheren van informatie en data over de CI’s. 

Wellicht dat de onderliggende infrastructuurcomponenten of CI’s bij de meeste organisaties bekend zijn, maar de complexiteit wordt veroorzaakt door de services en de grote diversiteit aan datastructuren die op de fysieke CI’s gelaagd worden; de application services, technical services en global business services. Een servicegericht CMDB maakt deze complexe structuren transparant en inzichtelijk. 

Business Service Support – een praktijkvoorbeeld

Een ziekenhuis wil haar bezoekers en patiënten informeren via digitale schermen die verspreid door het gebouw op relevante plekken geplaatst zijn. Zo worden o.a. bij de poli’s de gemiddelde wachttijden getoond en nieuwsberichten, en in de centrale hal informatie over waar zich wat bevindt en de vertrek- en aankomsttijden van het openbaar vervoer. De informatie op de schermen wordt door medewerkers van de afdeling communicatie onderhouden. 

Bij de Servicedesk komt een melding binnen van een medewerker van de informatiebalie: “Het scherm doet het niet!” De Servicedesk medewerker selecteert de Business Service ‘Narrowcasting’, checkt op vergelijkbare meldingen en werpt een blik op het monitoring dashboard van het narrowcasting platform. Wanneer er geen vergelijkbare meldingen gedaan zijn en het dashboard een ‘groen licht’ geeft voor beschikbaarheid en performance, weet de Servicedesk medewerker dat de oorzaak van het probleem waarschijnlijk ‘lokaal’ is; of het scherm staat uit of de lokale client heeft problemen. In de Known Error database staan een aantal maatregelen gedocumenteerd waarmee het probleem snel opgelost kan worden. 

Business Service: Narrowcasting

Een Business Service is een set onderling verbonden componenten (apparaten of CI’s, applicaties, technische services en/of infrastructurele services) die zijn geconfigureerd om een dienst (service) aan de organisatie te bieden.  

In dit voorbeeld bestaat de Business Service “Narrowcasting” uit;  

  • Applicatie services: content delivery is de functionaliteit die ervoor zorgt dat informatie op de schermen getoond wordt, terwijl met de functionaliteit content management de informatie onderhouden wordt;  
  • Een Global infrastructure service (de ‘clouddienst’: het centrale narrowcasting platform) en  
  • Configuratie items waarbij een onderscheid gemaakt wordt tussen hardware die lokaal aanwezig is (in het ziekenhuis: scherm en lokale client) en in het datacenter (servers) 
  •  Informatie object: het type content (data) dat gepubliceerd wordt (bijv. Video, foto’s, tekst ed). 

Servicegericht CMDB

In een CMDB (Configuratie Management DataBase) wordt informatie over de ‘configuratie’ opgeslagen en bijgehouden. Waar doorgaans de meeste CMDB’s vooral technische informatie over configuratie items en hun onderlinge relaties vastleggen, gaat het servicegerichte CMDB verder; het plaatst functionele en zakelijke betekenis om de technologie (CI’s, applicaties ed.) heen. Bijvoorbeeld in de vorm van relaties en zogenaamde ‘nodes’ tussen een bepaald bedrijfsproces en de onderliggende technologie. De weergave van een servicegericht CMDB komt dan ook grotendeels overeen met het hierboven geschetste model.  

Van reactief naar proactief

Een dergelijke service-gerichte architectuur biedt de volgende voordelen; 

  • Het pro-actief monitoren van de uptime en performance van business services; 
  • Het automatisch toepassen van maatregelen bij verminderde performance of dreigend falen van de business service; Orchestration. 
  • De Servicedesk krijgt sneller inzicht in de impact van een bepaalde storing (kortom, de eindgebruiker wordt sneller begrepen en daardoor geholpen); 
  • Door het monitoren van business services worden storingen sneller opgemerkt dan dat de eindgebruiker er last van krijgt (en biedt dit mogelijkheden voor pro-actieve incidentenbehandeling); 
  • Voor bedrijfskritische business services kunnen vooraf workarounds aangelegd worden waardoor de continuïteit van dergelijke processen gewaarborgd is. 
  • Risico- en impactanalyses van wijzigingen zijn nauwkeuriger in te schatten. 

Crawl, Walk, Run & Fly

Op welke wijze wordt in samenwerking met klanten inhoud gegeven aan een service-gerichte architectuur en borg je dat deze blijft aansluiten bij de business van klanten? 

Fase 1: Crawl

In deze fase werken we toe naar; 

  • Overzicht van de Business Capabilities (een ‘hoog-over’ beschrijving van de belangrijkste activiteiten van de organisatie, indien nodig gespecificeerd naar organisatie-onderdelen).
  • Overzicht van de initiële business services. Hierbij inventariseren en analyseren wij de incidenten en requests over de afgelopen periode (bijv. Een half jaar). Indien deze brongegevens ontbreken, gaan we in eerste instantie uit van ‘unknown business services’. Deze ‘onbekende’ Business Services worden in de beheerfase geïdentificeerd op basis van de meldingen (incidenten, requests) die bij de servicedesk binnenkomen. 
  • In overleg met de klant wordt bepaald hoe kritisch een business service is voor de bedrijfsvoering.  
  • Overzicht van de infrastructuur en CI’s die in beheer genomen worden; een schematisch overzicht van de infrastructuur; servers, firewalls, switches, verbindingen etc. Zodra de verschillende CI’s zijn geïdentificeerd gaat een periodieke Discovery Service de gegevens over die items verzamelen (en onderhouden). De Discovery Service is een geautomatiseerd proces dat periodiek (dagelijks, wekelijks) de gehele infrastructuur scant en de betrouwbaarheid en integriteit van de informatie over die infrastructuur en CI’s controleert. 

Fase 2: Walk

In deze fase werken we toe naar;  

  • Overzicht van het applicatielandschap en de wijze waarop het functioneel en technisch beheer is georganiseerd. Applicaties en/of Application Services zijn een belangrijke indicator voor een business service (en in veel gevallen is dit dé Business Service) 
  • Het expliciteren van de verantwoordelijkheden voor het beheer van de Applicaties en/of Application Services.  
  • Het inventariseren en analyseren van de Technische Services.
  • Bepalen van Technical Service Offerings

Fase 3: Run

Deze fase staat in het teken van Service Mapping 

  • Met Service Mapping worden de relaties tussen Business Services, Application Services, Technische Services en CI’s in het servicegerichte CMDB vastgelegd. De informatie over deze services, CI’s en hun onderlinge relaties worden middels een geautomatiseerde Discovery Service beheerd. 

Fase 4: Fly

In deze fase worden twee belangrijke processen ingericht; Event Management en het Service Level Management.  

  • Met Eventmanagement worden betekenisvolle meldingen over de status van alle relevante services (Business Services, Application Services, Technische Services en CI’s) gegenereerd en opgespoord. Het inregelen van deze events met bijbehorende triggers is belangrijk om vroegtijdig storingen te detecteren en allerlei (geautomatiseerde) activiteiten te bewaken. 
  • Nadat het service-aware CMDB grotendeels ingericht is, wordt het Service Level Management ingericht; het expliciteren van verwachtingen met betrekking tot de uptime van (business) services en adequate dienstverlening op het gebied van adaptief, correctief en preventief beheer. De SLA parameters worden geconfigureerd in het IT Service Managementsysteem. 

Na de projectoplevering vindt er periodiek (veelal maandelijks) een service-overleg plaats waarbij de performance en uptime van alle services en dienstverlening worden geëvalueerd (en waar nodig bijgesteld) 

Maanden later…

Ooit las ik ergens: ‘You need a Sparkle to start a Fire’. Achteraf was die uitspraak ‘Ik wil uptime’ de vonk die onze klassieke benadering van IT grotendeels in as heeft gelegd en zien wij een vruchtbare bodem voor dienstverlening op basis van business services.  

Governance take aways

Als een organisatie niet aangestuurd wordt door een baas of managers, hoe moet het werk dan geregeld en aangestuurd worden? Dit is het vraagstuk van Governance waarover ik een workshop volgde van Energized (gegeven door Koen Bunders), of zoals Koen het formuleerde; Hoe maak je governance waar iedereen van opknapt! En niet alleen een baas, manager of een organisatie-ontwerper.

Governance is een balanceer-act; zoveel als mogelijk én zo min als nodig! Omschrijf alleen die verantwoordelijkheden die anderen van je verwachten (spanning-gedreven) in plaats van een uitgebreide lijst van werkzaamheden die exact weergeven wat je doet. En vraag je regelmatig af of die verantwoordelijkheden nog nodig zijn.


In dit artikel wil ik een aantal van mijn ‘take-aways’ van de workshop delen. Maar eerst een paar opmerkingen vooraf (zie dit als een check-in). Onlangs kreeg ik een reactie van iemand die deze blog ‘pretentieus’ vond. “Je hebt alleen maar wat cursussen* gevolgd dus…….”.

*Ik heb in 2017 de Holacracy Practitioner Training gevolgd en in 2018 de Holacracy Coach Training, beide verzorgd door HolacracyOne o.l.v. Brian Robertson.

Enfin, laat ik deze gelegenheid (jouw/uw leestijd) gebruiken om mijn intenties te verhelderen (en dan laat ik het aan de lezer of hij/zij dit pretentieus vindt.

  1. Ik ben enthousiast over Holacracy. Ik heb veel verschillende organisaties van binnen gezien, er zelfs een aantal opgericht en ik heb nog geen alternatief gezien dat een organisatie zo wendbaar en responsief maakt en waarin de mens alles uit zich kan halen wat hij/zij in zich heeft.
  2. Ik vind Holacracy moeilijk en uitdagend. Als bedrijfskundige moet ik heel veel afleren (het what-if denken, het streven naar perfectie). Als persoon moet ik nog meer afleren (het directieve, de ‘held’ spelen) en veel leren (luisteren, reflexie, geduld, timing). Kortom, naast de spelregels (de grondwet) is Holacracy ook een ‘ervarings-leer’ en biedt het mogelijkheden voor persoonlijke groei en ontwikkeling.
  3. Schrijven is voor mij een manier om mijn gedachten te structureren. En als ik die tijd toch al investeer, waarom dit dan niet delen? En net als spreken, kan het zijn dat de toon je niet aanstaat.

Wil je (ook) de mening van ‘ervaren’ coaches, ga dan naar websites en blogs van HolacracyOne (waarbij ik je in het bijzonder wil wijzen op de blogs van Chris Cowan) en Energized.

Ok, dat was dan mijn check-in. En nu mijn vijf take-aways.

Take-away No.1: Verantwoordelijkheden

Het hebben van een verantwoordelijkheid betekent niet dat je het alleenrecht hebt op die verantwoordelijkheid! Een ieder mag die verantwoordelijkheid uitvoeren. Het grote verschil is dat het van de rol waaraan die verantwoordelijkheid is toegekend, wordt verwacht dat hij/zij die verantwoordelijkheid uitvoert.

Take-away No.2: domein(afspraken)

Als je van mening bent dat het op een of andere wijze schadelijk is dat die verantwoordelijkheid ook door anderen uitgevoerd kan worden (zonder dat ze die rol hebben), dan stel je in governance een domein en/of domeinafspraak voor. Met een domein en domeinafspraken kun je restricties opleggen.

Ik was gewend om een domeinafspraak als een ‘if-then’ statement te formuleren. “Als je de bedrijfsauto gebruikt, dan registreer je de gereden kilometers”. In deze workshop kreeg ik het advies om de domeinafspraak dwingender te formuleren; “Als je de bedrijfsauto gebruikt, dan moet je de kilometers registreren”.

Take-away No.3: Purpose (ordening)

‘Purpose’ is het eerste belangrijke ordeningsprincipe. Bij het opzetten van een initiële cirkelstructuur is er de neiging om bestaande afdelingen om te zetten in cirkels. In mijn rol als lead link heb ik dit destijds ook gedaan onder het mom van dat het de introductie van Holacracy vergemakkelijkte….integendeel! Naarmate je meer en meer zelf-organiseert, wordt dit juist iets wat voortgang in de weg zit. Afdelingen zijn teams van mensen (en als ze allemaal hetzelfde doen, dan zou je het een gilde kunnen noemen) en daar kan Holacracy in termen van besturing helemaal niets mee. Hiermee wil ik niet zeggen dat teams en mensen niet belangrijk zijn, maar in een Holacracy heeft governance alleen betrekking op rollen en de onderlinge relatie tussen rollen. Menszaken op een Holacratische manier verwerken? Niet doen!

Take-away 4: Purpose (zodat…)

Wat is een goede purpose en hoe kom je tot een goede purpose? In de workshop kregen we de handige tip om eerst naar alle verantwoordelijkheden van de rol te kijken en vervolgens de volgende vraag te beantwoorden; “Deze rol doet al deze dingen, zodat…..”. En als je dan een antwoord hebt, laat je dit weer volgen met de zodat-vraag. Je zult merken dat je die ‘zodat-vraag’ heel vaak kunt stellen. Om te voorkomen dat alle rollen uitkomen op een purpose als ‘vrede voor iedereen’ of ‘hemel op aarde’, zijn er een aantal criteria waarmee je die zoektocht (voorlopig) kunt beëindigen;

  • Je hebt de richting en betekenis die je aan het werk van je rol wilt toekennen
  • Je hebt het ultieme resultaat waar je in je rol naartoe werkt
  • Het activeert (je krijgt er energie van en je wilt hier helemaal voor gaan)
  • Het geeft duidelijk de scope van het werk aan

Take-away 5: domeinen

Mijn laatste take-away gaat over domeinen. Een domein is een dusdanig belangrijk iets van de organisatie, dat het een centrale aansturing van een rol nodig heeft. Op basis van de eerste take-away zou je verwachten dat de organisatie wordt overspoeld door een tsunami van domeinen. Zeker in de beginfase van de Holacracy adoptie is de roep om domeinen groot. Je hoeft maar naar een ‘iets’ te wijzen of ergens ‘aan’ te zitten en er wordt al snel voorgesteld om dit te ‘beveiligen’ met een domein. Net als bij verantwoordelijkheden betekent een domein niet dat de controlerende rol het alleen-recht heeft. Een ieder mag het domein gebruiken (de grondwet spreekt van ‘beïnvloeden’), echter je hebt wel toestemming nodig, en deze kan alleen geweigerd worden wanneer het gebruik er van tot schade leidt (bijv. de auto willen gebruiken zonder dat je een rijbewijs hebt).

Adviezen over wanneer wel/geen domein:

  • Principe: “Zo veel als nodig, zo min als mogelijk”.
  • Probeer domeinen zoveel mogelijk te voorkomen door eerste na te gaan of de gewenste governance ook middels een verantwoordelijkheid geregeld kan worden. Als dit niet mogelijk is;
  • Probeer het in een domeinafspraak (op de cirkel) te regelen.
  • Als een domein onvermijdbaar is, evalueer dan regelmatig of dit nog nuttig/nodig is. “Een domein is een paardenmiddel”

Meer uitleg over domeinen en domeinafspraken lees je in een van de vorige blogposts.


Ook al denk je dat je de Holacracy materie goed begrijpt, er valt nog zoveel te leren. Niet alle ‘wijsheid’ en ‘best practises’ staan in de Grondwet, maar ontstaan in de praktijk door het toepassen van de spelregels en de intentie om volgens deze regels te werken. Workshops zoals deze, maar ook de regionale Holacracy meet-ups zijn mooie gelegenheden om hierover met elkaar van gedachten te wissen en ervaringen te delen.

Dit jaar organiseert Energized een ‘Summerschool’ met diverse workshops (ook op het scheidsvlak Holacracy en ‘menszaken’ (zoals HR, Teamontwikkeling).

Model voor metrics

Een kritische analyse van het Holacracy ontwikkelingsmodel dat uitermate geschikt is als basis voor metrics inzake zelforganisatie.

De adaptatie van holacracy is een proces waarin mens en organisatie zich ontwikkelen naar hogere vormen van zelforganisatie (volwassenheid); een systeem waarbinnen autoriteit volledig gedistribueerd is. Het model dat HolacracyOne van dit proces gemaakt heeft, onderscheidt een viertal stadia; pre-launch, early practice, full practice en tot slot een mature practice waarin de zelforganiserende praktijk zich blijft ontwikkelen (evolving practice), bijvoorbeeld middels zogenaamde ‘apps’ die specifieke zaken adresseren zoals performance management, budgettering en HR zaken als compensatie en ontslag. Kortom, de besturing richt zich niet alleen op zorgen dat het werk gebeurd, maar adresseert ook allerlei ‘mens-zaken’ (key agreements including people processen have been translated into governance)

Onlangs ontving ik van Energized een uitgebreide Nederlandse versie van dit adoptieproces. In plaats van stadia gebruikt men hier het begrip ‘niveaus’;

  1. Zelforganisatie wordt ondermijnd
  2. Zelforganisatie stabiliseert
  3. Zelforganisatie verdiept
  4. Zelforganisatie in continue evolutie

De vertaling is niet geheel waardevrij (niveau 1) en persoonlijk zou ik de eerste fase iets positiever uitdrukken (‘Zelforganisatie staat op’ o.i.d.) Maar goed, we hebben te maken met een radicaal ander managementsysteem en daar hoort nu eenmaal provocerende taal bij. Maar de beschrijving van hoe de organisatorische praktijk zich op de verschillende niveaus manifesteert, c.q. hoe het systeem toegepast wordt, is zeer bruikbaar.

Alvorens ik inga op een bruikbare toepassing van dit model, wil ik eerst mijn spanningen met dit model toelichten.

Beleg mens-zaken elders

De premisse van holacracy is dat het werk beter en sneller gedaan wordt binnen een systeem van gedistribueerde autoriteit en dat daarmee de organisatie meer wendbaar en sneller kan reageren op dat wat nodig is.

Maar daar waar het ‘werk’ het domein is van de organisatie of het bedrijf, is de ‘mens’ dat niet. Een holacracy of zelforganisatie stuurt om die reden geen mensen aan. Het werk wordt gedaan in rollen die binnen een stelsel van regels (grondwet), domeinafspraken (beleid) en strategieën (prioritering) gericht op een bepaalde ambitie (purpose) acteren.

Het doet mij daarom al de wenkbrauwen fronsen dat in het model mens-zaken als salarissen, ontslag en aanname zijn opgenomen. In een vorige post heb ik al mijn mening gegeven over het holacratisch verwerken van mensgerelateerde spanningen; niet mee beginnen!

Salarissen (model niveau 4); Salariëring komt voort uit een peer-to-peer of markt-gebaseerd proces of iets wat daarop lijkt, zonder een eenvoudig te identificeren besluit over salarissen van anderen door een groep (bijvoorbeeld het Uber-achtige vergoedingen-systeem van Zappos voor het werken in shifts of de badge-based compensation app van HolacracyOne).

Salaris is onderdeel van een contract tussen een natuurlijke persoon en een rechtspersoon. In veel gevallen zijn ook wijzigingen van het salaris contractueel vastgesteld (bijv. indexatie) of wordt er een herzieningsproces/termijn vastgesteld (bijv. jaarlijks). Daarnaast zijn er externe omstandigheden die van invloed zijn op salariëring (bijv. krapte op de arbeidsmarkt) en wetgeving (arbeidsrecht).

Zowel door HolacracyOne zelf, als tijdens de trainingen en op discussiefora wordt gewaarschuwd voor de koppeling tussen rollen en salariëring;

  • rollen zijn dynamisch; ze komen en gaan
  • van rollen moet vrijwillig afstand genomen kunnen worden
  • rollen zijn transcendent; streven naar dat de rol niet meer nodig is

Waarom zijn deze systeemtoepassingen dan toch in het model opgenomen, terwijl je het tegelijkertijd uitsluit?

De genoemde voorbeelden (Uber, Zappos, HolacracyOne) zijn Amerikaanse bedrijven waar het arbeidsrecht significant verschilt met die van Nederland.

Ontslag (model niveau 4): Ontslagen ontstaan als een mogelijk resultaat van een peer-to-peer of markt-gebaseerd proces om de geschiktheid te toetsen, welke in veel gevallen vooraf voldoende signalering van mogelijke problemen biedt. In de praktijk zijn ontslagen zeldzaam.

Zo op het oog verschilt deze formulering nauwelijks van hoe binnen conventionele organisaties met ontslag wordt omgegaan. Maar wat wordt hier bedoeld? Ontslag van een werknemer (c.q. ontbinden van het arbeidscontract) of het ontslaan van mensen uit hun rol? En waar komt de conclusie vandaan dat ontslagen in de praktijk zeldzaam zijn? In beide interpretaties is dat gewoonweg niet waar.

Aanname (model niveau 4): De trigger om mensen aan te nemen wordt gedreven door een proces of formule dat behoeften door de organisatie heen integreert. Er wordt gebruik gemaakt van een screening-proces dat uniek en op maat is en deze blijft zich mogelijk ontwikkelen. Het voelt als ‘het zoeken naar business partners’ in plaats van ‘het aannemen van werknemers’.

Ook hier is het onderscheid met conventionele organisaties onduidelijk en heeft de formulering meer weg van ‘oude wijn in nieuwe zakken’. Het zoeken naar business partners en het aannemen van werknemers zijn geen activiteiten die elkaar uitsluiten, maar sluiten juist op elkaar aan. En ook hier is de vraag wat er bedoeld wordt; het zoeken en vinden van de juiste persoon voor een specifieke rol (role fit) of het contracteren van nieuwe personen voor de organisatie?

Mijn advies is om de systeemtoepassingen als ‘salarissen’, ‘ontslag’ en ‘aanname’ buiten beschouwing te laten. Het levert veel verwarring, onduidelijkheid en als je niet oppast ben je onwettig, onrechtmatig bezig. Mijn voorstel zou zijn om deze systeemtoepassingen in het kader van rollen te herdefiniëren zodat het meer in lijn komt met de oorspronkelijke premisse van Holacracy.

Bruikbaarheid model

In werkelijkheid verloopt de adaptatie van holacracy niet fasegewijs maar functioneren de verschillende systeemtoepassingen op verschillende niveaus. Zo is het heel goed mogelijk dat het werkoverleg op niveau 3 (zelforganisatie verdiept) functioneert, budgetten door één persoon worden bepaald (niveau 1) en Lead Links het verschil met management wel begrijpen, maar hun autoriteit in andere rollen laten gelden (niveau 2). En om nog meer aan de realiteit tegemoet te komen; dit lees kan per cirkel verschillen. Vandaar dat ik meer gecharmeerd ben van de duiding in niveaus dan in fasen.

Door de voorgenoemde systeemtoepassingen te schrappen – zie dit als een verwerking van mijn spanningen met het model – behoudt je een zeer bruikbaar model als basis voor metrics die de voortgang/performance van de Holacracy adaptatie in cijfers kan uitdrukken.

Over wat een metric is of moet zijn, bestaan veel meningen. Metrics is een ‘samenstelling’ van strategie (doel/purpose), Objectieve Key Results (OKR’s) en Key Performance Indicators (KPI’s). Doel van een metric is tweeërlei; het zegt iets over de voortgang richting een doel én het dient als trigger voor relevante spanningen.

Voor de rol Holacracy Coach ben ik bezig met het ontwikkelen van metrics op basis dit ontwikkelingsmodel.


In dit geval kun je Objectives relateren aan de typering die HolacracyOne gebruikt in haar model ‘Stages of Adoption’. Dit zou er dan als volgt uit kunnen zien;

  1. Pre-launch (setting the stage)
  2. Early Practice (getting mechanics)
  3. Full Practice (getting powershift)
  4. Mature Practice (evolving)

Een OKR markeert de overgang van de ene fase naar de andere fase (of van het ene naar het andere niveau). HolacracyOne spreekt per fase van ‘Phase Completion Markers‘, bijvoorbeeld;

  1. Stage set: grondwet getekend, eerste overleggen gepland en initiële structuur gedefinieerd en geïmplementeerd.
  2. Mechanics implemented: Significant minder time-outs (tijdens vergaderingen), vaardige interne facilitators, productief tempo in vergaderingen, spelregels worden goed opgevolgd.
  3. Power shifted: rol-gebaseerde communicatie ook buiten vergaderingen, effectief gebruik van domeinen en domeinafspraken, autocratische besluitvorming is de norm.


De KPI’s vormen feitelijk het dashboard dat de prestatie/voortgang richting objectives (de ‘O’ van OKR’s) monitort. Deze KPI’s zijn gelijk aan de verschillende systeemtoepassingen uit het model;

  • Lead Links
  • Werkoverleg
  • Roloverleg
  • Budgetten
  • Besluitvorming en leiderschap
  • Roltoewijzing
  • Functietitels
  • Informatiestromen
  • Performance management
  • Focus op purpose
  • Onboarding en training

So, the question is…..

Kortom, KPI’s zijn onderdeel van OKR’s. Maar niet alle KPI’s zijn van belang voor een overgang naar een volgende fase of niveau. Vergelijk dit met als je op de snelweg rijdt waar een maximum snelheid geldt met trajectcontrole. Je let dan vooral op de KPI snelheidsmeter. Dit betekent overigens niet dat de andere KPI’s niet belangrijk zijn zoals de brandstofmeter en de toerenteller. Echter de snelheidsmeter is ten opzichte van het doel (maximale snelheid niet overtreden) belangrijker.

Dus de vraag moet zijn; welke systeemtoepassingen zijn belangrijk (key) voor de overgang naar een volgende fase of niveau? En welk gedrag (performance) van die belangrijke systeemtoepassing is een indicator dat richting het beoogde resultaat (key results) bewogen wordt.

Lekker belangrijk

Onlangs stuitte ik op Youtube op het onderwerp Motiverende Gespreksvoering (een presentatie van Sergio van der Pluijm). Hierin worden drie vormen van motivatie genoemd;

  • Intrinsieke motivatie
  • Extrinsieke motivatie
  • Autonome motivatie

Er is sprake van autonome motivatie als je iets belangrijk vindt, ongeacht of je het leuk/interessant vindt (intrinsiek) of dat je daartoe gedwongen wordt (extrinsiek).

Purpose: Wat is belangrijk?

‘Wat is belangrijk’ is een vraag waar we in de waan van de dag vaak aan voorbij gaan. Ga bij jezelf na; hoe vaak leg jij je prioriteiten op basis van wat adhoc op je bord komt? Je prioriteiten liggen dan meestal niet op die zaken die ‘echt’ belangrijk zijn.

Wat belangrijk is doet mij denken aan purpose (kerndoel);

  • Wat vind je als mens belangrijk?
  • Wat vind je als professional belangrijk?
  • Wat vind ik in mijn rol(-len) belangrijk?
  • Welke projecten (gewenste resultaten) zijn belangrijk?
  • Wat is (vind ik) binnen mijn project belangrijk? Welke eerstvolgende actie is belangrijk om voortgang te maken?

In purpose zit een gelaagdheid en de verschillende kerndoelen kunnen elkaars afgeleide zijn. Zo is bijvoorbeeld mijn professionele purpose; ‘impact door wegen/structuren te ontwikkelen waarop individuen, teams of organisaties succesvol hun doelen kunnen nastreven’. Wanneer ik mijn persoonlijke professionele purpose vertaal naar mijn rol als Holacracy Coach is dat ‘ondernemen in je rol‘. Deze kerndoelen helpen mij om te bepalen wat belangrijk is in mijn werk. Welke projecten hebben, gezien mijn purpose, een hogere prioriteit?

Als je meerdere rollen hebt, kunnen projecten met elkaar concurreren om jouw aandacht. De prioriteit wordt dan meestal bepaald door de ‘functionele context’ waarbinnen je die rol(len) vervult. In mijn geval de cirkel, maar dat kan ook je team, afdeling of organisatie zijn (vaak ook in deze volgorde).

Kortom, je hebt meerdere kerndoelen die, als het goed is een hiërarchische verhouding met elkaar hebben (het ene kerndoel komt voort of is afgeleid van het andere) Uiteindelijk kom je uit bij de existentiële vraag; Wat vind je persoonlijk belangrijk?

Purpose voelen

Op 12 juni jl. was er een webinar over purpose van Brains Robertson (HolacracyOne) en Tim Kelley (TheRealPurposeInstitute). Deze webinar maakte mij duidelijk hoe belangrijk purpose is in het stellen van prioriteiten. Tot voor kort maakte ik mij niet erg druk als een rol geen purpose had; “Dan hanteer je de purpose van de cirkel waarin je rol is geplaatst” of “Dat komt vanzelf”. Dat laatste is al helemaal niet waar – de juiste purpose formuleren is moeilijk.

De juiste purpose voel je! Je voelt het als je de purpose uitspreekt! Je voelt het wanneer je in een situatie bent dat je je purpose kunt nastreven, ook als je dit niet (meer) kunt. Dit laatste ondervond ik recent.

Mijn purpose

De situatie was dat het coachen van één van de subcirkels niet de gewenste resultaten opleverde. Niet alleen voor mij in mijn rol als Holacracy Coach, maar ook niet voor de cirkel. Er waren meer spanningen met het proces dan met de inhoud (het werk). Uiteindelijk werd ik de personificatie van de spanningen omdat het mij als coach niet lukte om de cirkel te laten ervaren dat ‘vertrouwen op het proces’ juist meer ruimte biedt voor het werk zelf en voor ondernemerschap in rollen.

In een artikel schreef Chris Cowan treffend; It’s easy to mess it up because a coach walks a fine line between supporting Holacracy practice and violating it.[…] Too often coaches blur the boundaries between their own felt Holacracy-practice-related tensions and the tensions of those they are coaching. In the end, the way we intervene probably teaches more than the content ever could.

Ik voelde mij zwaar miserabel dat ik binnen deze cirkel mijn (professionele) purpose en de purpose van mijn rol niet heb kunnen realiseren.

Maar het was juist deze situatie die mijn persoonlijke purpose openbaarde; een antwoord op de existentiële vraag wat ik als persoon belangrijk vind – in mijn werk en daar buiten – ‘oprecht zijn en mijzelf niet al te serieus nemen’ (sincere, not too serious). Vooral dat laatste!

Metrics, OKR’s & KPI’s

Dit artikel is onderdeel van een reeks artikelen over het toepassen van generieke beheersmaatregelen uit het NOREA normenkader op zelforganisaties.


In dit artikel wordt de generieke control ‘Kwaliteit & Prestatie’ van het NOREA normenkader behandeld.

Eerst wordt de oorspronkelijke NOREA formulering gegeven en in het gekleurde blok de ‘formulering’ van deze generieke maatregel die beter aansluit bij het managementparadigma van een zelforganisatie (specifiek Holacracy)

In de toelichting wordt een brug geslagen tussen de twee paradigma’s. 

Tot slot wordt voor elke generieke beheersmaatregel een suggestie gedaan voor bewijsvoering.

GEN-5: Kwaliteit en prestatie

Oorspronkelijke NOREA formulering:

Management van de serviceorganisatie heeft kwaliteits– en prestatiedoelstellingen vastgesteld voor het proces.

Aangepaste formulering:

De Lead Link rol heeft indicatoren/metrics voor de cirkel vastgesteld die een kwantitatief beeld geven van de mate waarin de doelen van en binnen de cirkel gerealiseerd worden. 

Binnen de cirkel zijn checklist-items opgesteld om vast te stellen dat verantwoordelijkheden worden waargenomen.


ITIL heeft voor elk proces kritieke succesfactoren met bijbehorende metrics gedefinieerd. Samen vormen ze de zogenaamde Key Performance Indicator (KPI). Op basis van een door de organisatie vastgestelde norm wordt de prestatie van een proces beoordeeld.

Binnen een zelforganisatie worden kwaliteits- en prestatiedoelstellingen samengevat onder de noemer ‘de gezondheid van de cirkel’. Een cirkel is in feite ook een rol die zich heeft onderverdeeld in meerdere rollen om haar doelstellingen (purpose) te realiseren. Om er voor te zorgen dat cirkelleden kunnen ondernemen in hun rol (zonder elkaar te belemmeren in het realiseren van de purpose), is er een supersnel forum om met het werk op elkaar af te stemmen en te synchroniseren; het werkoverleg (tweewekelijks, waarin cirkelleden elkaar informeren over belangrijke zaken die de cirkel aangaan, activiteiten op elkaar afstemmen en belemmeringen wegnemen). De structuur van het werkoverleg heeft een aantal vaste onderdelen;

Checklist-items: hiermee controleert de cirkel of de verantwoordelijkheden (ook wel doorlopende activiteiten genoemd) van de cirkel, door de verschillende verantwoordelijke rollen zijn uitgevoerd (resultaat: check of no-check).

Metrics: Om met de deur in huis te vallen; een metric is niet hetzelfde als een KPI. Metrics zijn het beste te vergelijken met OKR’s: Objectives & Key Results. Hierbij komt de objective overeen met de purpose (van een cirkel of van een rol). Voorbeeld:

Stel, de rol Incident Coach heeft als purpose: storingsvrije IT. Dit is een behoorlijk ambitieus doel en dat is ook de intentie van een Objective. Een Key Result is dan bijvoorbeeld; 70% van de storingen opgelost voordat de klant het merkt. Daarnaast is het gewoon om voor een objective meerdere key results te definiëren.

Een KPI meet in welke mate een activiteit een doel gehaald heeft. Het doel is haalbaar en de indicator geeft aan in welke mate je dat doel gehaald hebt. Voorbeeld:

Het doel van het proces van Incident Management is dat de gebruikersorganisatie zo spoedig mogelijk weer de beschikking heeft over IT functionaliteit (en dit weer kan gaan gebruiken). Meest wordt dit doel uitgedrukt in een KPI: minstens 90% van alle incidenten worden binnen de afgesproken functieherstelgarantie opgelost. De performance wordt dus beoordeeld op basis van de norm.

In het kader van metrics (zelforganisatie) en performance (NOREA, ITIL) zijn KPI en OKR zijdes van dezelfde munt. Met een KPI meet je de performance van een proces. Met een OKR meet je de performance van een rol. Om de kwaliteit van een proces te beoordelen heb je zowel KPI’s (bestuurd systeem) als OKR’s (besturend orgaan) nodig.

Maar als kwaliteit en performance synoniem zijn van de ‘gezondheid van de cirkel’ dan is meer nodig;

Projectstatus: rollen ondernemen ‘eerstvolgende acties’ en werken toe naar gewenste resultaten. Een gewenst resultaat noemen we binnen een zelforganisatie een ‘project’. In het werkoverleg geeft elk cirkellid een update van haar projecten. De eerstvolgende acties worden in het werkoverleg niet gemonitord, maar bijgehouden in een voor een ieder inzichtelijk systeem (bijv. Holaspirit of Glassfrog).

Verwerken van spanningen: ‘Waar gewerkt wordt, zijn spanningen’ (en een spanning is elk verschil tussen IST en SOLL, het potentieel van een situatie) anders geformuleerd; waar geen spanningen zijn, wordt niet gewerkt (althans niet in de betekenis van ondernemen in je rol) Het aantal spanningen dat de rol inbrengt en de voorstellen om die spanningen te verwerken, zeggen iets over de performance van de roluitvoering.

Samenvattend: Kwaliteit en prestatie uit het NOREA normenkader is in een zelforganisatie synoniem aan ‘de gezondheid van de cirkel/rol’. De gezondheid wordt door meerdere zaken bepaald;

  • Je verantwoordelijkheden nemen en uitvoeren (checklist-items);
  • Gebruik maken van je autoriteit die je middels je rol hebt toegewezen gekregen;
  • Verwerken van spanningen;
  • Uitvoeren van processen en monitoren van verwachtingen (KPI’s);
  • Werken aan je purpose en monitoren van de voortgang en performance (OKR’s);
  • Transparant zijn in waar je aan werkt (projectstatus, eerstvolgende acties, prioriteren ed.)

Feitelijk allemaal zaken die bijdragen aan de kwaliteit van je werk, je rol, de cirkel en dus de organisatie.

Bewijsvoering voor GEN-5:

  • Dashboard met KPI’s voor de verschillende processen
  • Dashboard met ORK’s voor de verschillende rollen/cirkels
  • Verslagen van Werkoverleggen
  • Verslagen van Governanceoverleggen
  • Gebruikersstatistieken uit Holaspirit/Glassfrog
  • Projectenoverzicht met statusrapportage


Dit artikel is onderdeel van een reeks artikelen over het toepassen van generieke beheersmaatregelen uit het NOREA normenkader op zelforganisaties.


In dit artikel wordt de generieke control ‘Middelen, Capaciteit en Deskundigheid’ van het NOREA normenkader behandeld.

Eerst wordt de oorspronkelijke NOREA formulering gegeven en in het gekleurde blok de ‘formulering’ van deze generieke maatregel die beter aansluit bij het managementparadigma van een zelforganisatie (specifiek Holacracy

In de toelichting wordt een brug geslagen tussen de twee paradigma’s.

Tot slot wordt voor elke generieke beheersmaatregel een suggestie gedaan voor bewijsvoering.

GEN-4: Middelen & Deskundigheid

Oorspronkelijke NOREA formulering:

De serviceorganisatie beschikt over voldoende middelen, deskundigheid en capaciteit (door intern personeel en/of externe dienstverleners, inclusief vervangend personeel in geval van tijdelijke afwezigheid) om het proces uit te voeren.

Aangepaste formulering:

De serviceorganisatie beschikt over voldoende assets, deskundigheid en capaciteit (door interne rolvervullers en/of externe dienstverleners, inclusief vervangende partners in geval van tijdelijke afwezigheid) om de verantwoordelijkheden uit te voeren.


Wat er met middelen binnen een zelforganisatie bedoeld wordt is afhankelijk van de context waarin dit begrip gebruikt wordt. In de context van verantwoordelijkheden (Grondwet artikelen 1.2.5, 4.1.1, 4.1.3c, 5.2.3) betekent middelen; geld (en niets anders). In het kader van de norm is het begrip middelen ruimer gedefinieerd; bijvoorbeeld instrumenten, applicaties (tooling). Vandaar dat ik voor de term ‘assets’ kies: een (bedrijfs-)eigendom dat waarde vertegenwoordigt.

Het uitvoeren van een proces staat gelijk aan het uitvoeren van verantwoordelijkheden rekening houdend met domeinen (processen) en geldende domeinafspraken (beleid, richtlijnen).

Mochten assets, capaciteit of deskundigheid tekortschieten, dan is dit een spanning van de desbetreffende persoon die dit tekort in één van zijn rollen ervaart. En het is ook de verantwoordelijkheid van de rolvervuller (persoon) om deze spanningen te verwerken (artikel 1.2.1).


  • Roosterplanning van medewerkers (bijv. capaciteitsplanning Servicedesk);
  • Profielpagina’s van medewerkers met zogenaamde ‘kennistags’ (bijvoorbeeld de technische, functionele of proceskennis die personen hebben);
  • Domeinafspraken of andere wijze van vastlegging hoe de afwezigheid van een rol wordt opgevangen;
  • Een rol die de status en behoefte aan deskundigheid en expertise bijhoudt (en voorbeelden van ‘spanningen’ die ten aanzien van dit onderwerp verwerkt zijn of worden);

Wanneer je in de procesdocumenten verwijst naar (artikelen in) de Grondwet, dan is het handig om ook die toe te voegen aan de sectie 3 van het auditrapport (veelal onder de noemer ‘User Considerations’)

Next: Metrics


Dit artikel is onderdeel van een reeks artikelen over het toepassen van generieke beheersmaatregelen uit het NOREA normenkader op zelforganisaties.


In dit artikel wordt de generieke control ‘Verantwoordelijkheden’ van het NOREA normenkader behandeld.

Eerst wordt de oorspronkelijke NOREA formulering gegeven en in het gekleurde blok de ‘formulering’ van deze generieke maatregel die beter aansluit bij het managementparadigma van een zelforganisatie (specifiek Holacracy

In de toelichting wordt een brug geslagen tussen de twee paradigma’s.

Tot slot wordt voor elke generieke beheersmaatregel een suggestie gedaan voor bewijsvoering.

GEN-3: Verantwoordelijkheden

Oorspronkelijke formulering:

De verantwoordelijkheden voor het proces zijn toegewezen.

Aangepaste formulering:

De verantwoordelijkheden voor domeinen, functies en processen binnen de cirkel zijn toegewezen (aan rollen, en rollen zijn toegewezen aan personen/cirkelleden)


Verantwoordelijkheden zijn doorlopende werkzaamheden die van een bepaalde rol verwacht worden. Rollen en daarbij behorende verantwoordelijkheden ontstaan door spanningen die verwerkt worden in het rollenoverleg (governance). Zodra een rol in het leven geroepen is kan de Lead Link van de desbetreffende cirkel deze rol toewijzen aan een cirkellid. Rollen die niet zijn toegewezen daarvan worden de verantwoordelijkheden door de Lead Link waargenomen.

ITIL maakt gebruik van het RACI-model (Responsible, Accountable, Consulted en Informed). Per processtap wordt aangegeven wie eindverantwoordelijk is (accountable) en wie de werkzaamheden uitvoert (responsible). Binnen een zelforganisatie zal er veelal sprake zijn van een ‘responsible’ rol die een proces (= domein) beheerst en waarbij middels domeinafspraken de werkzaamheden (= invloed/impact) van ‘accountable’ rollen zijn vastgelegd.

Alhoewel ITIL ook een expliciete structuur en duidelijkheid nastreeft, is mijn mening dat een zelforganisatie daar beter in slaagt.

Bewijsvoering GEN-3:

  • Administratie en vastlegging cirkel- en rollenstructuur in bijv. Glassfrog/Holaspirit.
  • Procesbeschrijvingen inclusief expliciete toewijzing van verantwoordelijkheden.

Next: capaciteit(en)

Vastleggen & informeren

Dit artikel is onderdeel van een reeks artikelen over het toepassen van generieke beheersmaatregelen uit het NOREA normenkader op zelforganisaties.


In dit artikel wordt de generieke control ‘Documentatie, bekendmaking en goedkeuring’ van het NOREA normenkader behandeld.

Eerst wordt de oorspronkelijke NOREA formulering gegeven en in het gekleurde blok de ‘formulering’ van deze generieke maatregel die beter aansluit bij het managementparadigma van een zelforganisatie (specifiek Holacracy

In de toelichting wordt een brug geslagen tussen de twee paradigma’s.

Tot slot wordt voor elke generieke beheersmaatregel een suggestie gedaan voor bewijsvoering.

GEN-2: Proces gedocumenteerd, geaccordeerd en bekendgemaakt

Oorspronkelijke NOREA formulering:

Het proces, waaronder de procesgang en rollen, is gedocumenteerd, geaccordeerd door management en bekend gemaakt bij alle betrokkenen.

Aangepaste formulering:

Het domein en de daarmee samenhangende domeinafspraken, rollen en strategieën, is gedocumenteerd, middels het governanceproces bekrachtigd en bekend gemaakt aan alle betrokkenen.


Rollen: ITIL definieert een rol als ‘een verzameling verantwoordelijk-heden, activiteiten en bevoegdheden die zijn toegekend aan een persoon of team. Een rol wordt vastgelegd in een proces of functie. Een persoon of team kan meerdere rollen hebben‘. Deze definitie vertoont veel overeenkomsten met de roldefinitie binnen een zelforganisatie. ‘Een rol vastgelegd in een proces’ verwijst naar domein(en) die aan de rol is toegekend.

Procesgang: ITIL biedt ingrediënten om de procesgang van IT-serviceprocessen (bijv. Incident Management) te beschrijven;

  • Stroomdiagrammen;
  • Triggers, input en output van het proces;
  • Interfaces met andere operationele processen;
  • Kritieke succesfactoren

Met deze ingrediënten kan binnen een zelforganisatie een domein gedefinieerd en nader gespecificeerd worden. Overigens moet procesgang binnen een zelforganisatie breder opgevat worden: het gaat hierbij niet alleen om de operationele procesflow maar ook om de besturing van het proces (c.q. domein) hetgeen tot uitdrukking komt in bijvoorbeeld domeinafspraken en strategieën.

Bekend gemaakt: Een belangrijk basisprincipe binnen een zelforganisatie is dat impliciete verwachtingen niet bestaan. De meeste zelforganisaties maken gebruik van specifieke software (zoals Glassfrog, Holaspirit) waarmee cirkels en rollen hun administratie bijhouden en waarin je alles kunt vinden/nalezen over domeinen, domeinafspraken, wie verantwoordelijk is, wat die verantwoordelijkheden inhouden etc.

Bewijsvoering GEN-2:

  • Systeem waarin de processen zijn beschreven (document-managementsysteem bijv. Knowledge binnen Servicenow)
  • Systeem waarin de processen zijn geconfigureerd (IT Servicemanagementsysteem zoals bijv. Servicenow)
  • Verslagen van Governance overleggen (c.q. Administratie van de cirkel in bijv. Glassfrog/Holaspirit)

Next: Verantwoordelijkheden


In mei 2017 kwam ik enthousiast terug van de Holacracy Practitioner Training. Ik dacht eindelijk een vorm te hebben gevonden dat een organisatie in staat stelt om voortdurend te reorganiseren, zonder de stress en pijn waar een reorganisatie doorgaans mee geassocieerd wordt. Veranderen als een natuurlijke gewoonte. Ok, voor dat je zover bent, moet je eerst wel door veel pijn heen. Maar als je daar dan doorheen bent, dan ervaar je dat dingen beter en sneller gaan – the real powershift.

Nu, tweeënhalf jaar later, ben ik nog steeds enthousiast over Holacracy. Mede omdat ik mij steeds meer bewust wordt van de beperkingen en grenzen van dit managementsysteem.

Als je ergens enthousiast over bent, heb je al snel de neiging dit als een oplossing voor alles te zien. Echter, Holacracy is geen Zwitsers zakmes. Holacracy is een systeem voor het managen van werk en ongeschikt voor het managen van mensen. Dit om de doodeenvoudige reden dat de mens een irrationeel en complex wezen is binnen diverse complexe en dynamische (sociale) systemen. Een theorie die dit alles ‘plat slaat’ tot rationele reducties, is heel verleidelijk en aantrekkelijk, maar is vergelijkbaar met het ontkennen van de zwaartekracht.

Je bent mens, tenzij anders aangegeven

Waar mensen in een Holacracy moeten leren om in hun rol (of rollen) te acteren, komt het omgekeerde ook veel voor: de premisse dat je alles in een rol doet of moet doen. Voorbeeld: Onlangs uitte ik mijn zorg over iemand aan een collega en sprak ik het voornemen uit om met diegene een gesprek aan te gaan. Waarop de collega vroeg vanuit welke rol ik dat ging doen? Ik betrapte mijzelf op het snel scannen van mijn rollen en welke passend zou zijn om deze ‘eerstvolgende actie’ te verantwoorden. Dit is natuurlijk ridicuul. Je vraagt ook niet in welke rol de ander naar jouw vakantie informeert.

Het wordt echter een ander verhaal wanneer werkgerelateerde zaken onderwerp van gesprek worden. Verwacht de ander iets van mij? Zo ja, van mij als persoon (een mening) of van mij in één van mijn rollen? Petje af, petje op.


Ook adviesorganisaties maken bij de implementatie van Holacracy een onderscheid in werkzaken en menszaken door gelijktijdig én aan zelforganisatie én aan teamontwikkeling te werken. Waarbij voor teamontwikkeling gebruik gemaakt wordt van andere theorieën, systemen en modellen (zo maakt het bureau Energized gebruik van SCT voor teamontwikkeling).

Holacracy ziet de grondwet als, en ik citeer: een onderliggend platform, een set kernregels met behulp waarvan je al je bedrijfsprocessen in de loop van de tijd kunt definiëren, ontplooien en uitvoeren’ (p.171, Holacracy, Brian Robertson, 2017). Dit citaat herbergt een belangrijk advies;

Met de bouwstenen (purpose, rollen, verantwoordelijkheden, domeinen, domeinafspraken, strategieën) van Holacracy kun je veel bedrijfsprocessen vormgeven (definiëren). En de grondwet biedt regels waarmee je deze processen kunt updaten naar een optimale fit tussen rol en werk (uitvoering) enerzijds en tussen rol en purpose (ontplooien) anderzijds.

Maar het belangrijkste advies zit ‘m in de zinsnede ‘in de loop van de tijd’:

Voor veel menszaken (zoals bijvoorbeeld; compensatie/beloning, persoonlijke ontwikkeling, team building, communicatie ed.) is het verstandiger om Holacracy in eerste instantie buiten beschouwing te laten en je door andere modellen en theorieën te laten inspireren.

Het voortdurend openstaan voor nieuwe ideeën is een belangrijke houding om spanningen (verschil tussen IST en SOLL) te signaleren en te verwerken. Frederic Laloux geeft in zijn boek Reinventing organizations tal van voorbeelden en verwijzingen hoe ‘zelf-organisaties’ omgaan met menszaken. Zoek je vooral concrete voorbeelden van holacratische organisaties, dan is de Holacracy Community of Practise een waardevolle bron.

En als je denkt dat zo’n systeem of proces zou kunnen werken (save enough to try), ga dan onderzoeken hoe je dit kunt implementeren op de onderlaag van Holacracy. Dit betekent meestal dat het geselecteerde model/systeem of theorie naar de structuurvariabelen en parameters van een Holacracy vertaald moet worden;

Het definiëren van het proces (domein en/of domeinafspraken), de proceseigenaar (cirkel, rol) en wat een ieder van het proces en de eigenaar mag verwachten (purpose en verantwoordelijkheden). Mooie voorbeelden waarbij ‘andere’ theorieën of modellen gebruikt zijn;

Role transcendence

Op basis van de behoeftenmatrix van Maslow (yep, ook een ‘ander’ model/theorie) is een hiërarchie van rolbehoeften opgesteld waarbij de rol zich van een probleemgerichte focus (survival) naar een ontplooiingsgerichte focus ontwikkelt; role transcendence. In dit finale stadium heeft de rol zichzelf overbodig gemaakt. Het proces heeft geen rol meer nodig voor aansturing. Feitelijk is hiermee het proces, dat aanvankelijk de aansturing van een rol nodig had, een ‘gewoonte’ geworden en integraal onderdeel van de bedrijfscultuur.

Onlangs hoorde ik een mooie definitie van ‘bedrijfscultuur’; gedrag dat mensen vertonen wanneer de baas er niet is. Zover ik weet, is Holacracy het enige model dat dit als uitgangspunt neemt voor cultuurverandering.