Intro
De diep ingewortelde gewoonten en manieren van besturen in het Angelsaksische bedrijfsleven maken de transitie naar wendbare organisaties zeer moeizaam.
Denk aan het simpele feit dat er nog zoveel afdelingen bestaan met namen als ‘IT’, ‘IV’ ‘IM’ etc. Maar ook staf afdelingen. Dat zijn starre afdelingen die los staan van de business afdelingen die vaak juist de naam hebben van de producten of diensten die een bedrijf levert.
Alleen al die klassieke scheiding levert een enorme kloof op tussen de business en de IT. En op het moment dat binnen de ‘IT’ afdeling dan met Scrum teams wordt gewerkt denkt men dat de organisatie agile en wendbaar is. Dit is verre van waar, en wordt zelfs als ‘Zombie Scrum’ aangeduid door Agile kenners.
Wat zijn de belemmeringen?
Klassieke afdelingen hebben een afdelingsmanager, die weer afdelingsplannen heeft (meestal jaarplannen), afdelingsdoelen etc etc. Op zich goed om bedrijfsdoelen te vertalen naar afdelingsdoelen, maar voor de genoemde silo’s als ‘Business’, ‘IT’, ‘IV’ en ‘IM’ blijft het sub optimaal. Waarom:
- Afdelingsplannen hebben vaak een jaarcyclus, dat is niet wendbaar
- Afdelingsplannen worden vaak te strak opgevolgd, zonder rekening te houden met veranderende omstandigheden. Dat maakt dat managers vaak genoodzaakt zijn om vreemde constructies te gebruiken.
- Vaak worden afdelings- KPI’s gebruikt die niets zeggen over hoe het bijdraagt aan kort cyclisch leveren van businesswaarde, waar iedereen zich op zou moeten richten in een wendbare organisatie.
- Afdelingsplannen bevatten vaak richtlijnen of eisen voor concrete op te leveren producten, dat moet worden overgelaten aan productmanagement, anders krijg je verstrengeling van belangen
- Afdelingen hebben eigen afdelings- overlegvormen, die overlappen of zelfs redundant zijn aan alle agile werkvormen. Dat zit elkaar dus in de weg.
- Afdelingen hebben dus eigen (als het meezit van bedrijfsstrategie afgeleide) doelen die niet persé hoeven te stroken met de doelen die de business heeft.
- Afdelingen, zoals stafafdelingen, vertegenwoordigen vaak eenzijdige disciplines zoals Architectuur, HR, JZ, Compliance, Risk. Terwijl we in een wendbare organisatie juist met multidisciplinaire teams willen werken.
- Afdelingsmanagers van afdelingen die slechts een deel van een productketen afdekken worden vaak verantwoordelijk gemaakt voor het tijdig opleveren van releases voor producten. Men wil iemand de schuld kunnen geven. Maar dit hoort in een wendbare organisatie ook bij productmanagement.
- In verschillende afdelingen die samen een productketen afdekken kunnen verschillende culturen ontstaan, onbegrip, communicatiekloven.
- Afdelingen als ‘IT’ en ‘IV’ staan vaak ver van de eindklant af. En ze hebben vaak targets van efficiency, terwijl men juist op effectiviteit zou moeten sturen. Als een Scrum team vraagt of ze een dag naar de klant mogen, dan krijgt men zelfs nog vaak te horen: ‘Dat kan niet, want dat kost ons een hele dag productie’.
- Agile teams kunnen teamleden hebben met verschillende leidinggevenden van verschillende afdelingen, dat geeft verstrengeling van belangen.
Ik kan er heus nog wel een paar bij verzinnen. Maar deze punten geven een goed beeld van wat ik bedoel. Deze punten dragen absoluut NIET bij aan het worden of zijn van een wendbare organisatie. Dit zijn symptomen van een starre, hiërarchische, Angelsaksische organisatie.
Hoe dan wel?
In agile transities zie je andere structuren. De basis structuur of ‘bouwblok’ is een multidisciplinair team. Daarna zie je teams van teams. Vaak genaamd ‘Tribes’, ‘Release Trains’, ‘Clusters’, ‘Grids’, ‘Nexus’. Deze teams van teams zijn gericht op een product of dienst en bevatten als het goed is teams die zowel de business als de IT discipline bevatten. Ik ga in deze blog: Cultuur volgt structuur nog verder en zie zelfs multidisciplinaire stafteams deel uitmaken van deze teams van teams.
Hierna zie je als voorbeeld van een nieuwe structuur een visuele weergave van hoe NeXuS als scaling framework tegen deze bouwblokken aankijkt:
(Figuur 1: Nexus fractale en dynamische team structuur)
Kun je dan zo’n team van teams een afdeling noemen in het vervolg? Ja en nee.
Waarom nee?
Afdelingen zijn vaak statisch van aard, hebben afdelingsplannen etc. zoals hierboven beschreven. In de klassieke zin is het dus geen afdeling, want deze teams van teams staan met hun productmanagement juist als business en IT samen voor 1 product of dienst. Zij hebben geen plannen, maar product visie en roadmaps met een rolling forecast. Zij kennen geen rapportages, maar Obeya ruimten waar de actuele stand van zaken elke week wordt besproken in een vast ritme. Zaken waar normaal in een afdelingsplan aparte projecten voor worden aangekondigd als upgrade van platformen, verbeteren van contractmanagement etc. worden nu als enabler epics meegenomen in de backlog en roadmaps.
Waarom ja?
In organisatorische zin en om lean budgeting mogelijk te maken kan het wel handig zijn om een team van teams als afdeling te bestempelen. Met name in het ERP systeem. Want, tenslotte, in lean budgeting zijn de (jaarlijkse, per kwartaal aanpasbare) personeelskosten van een team van teams tevens de productbudgetten! Hoe handig kan het dan zijn om de medewerkers in je systeem van één team van teams in één afdeling te plaatsen voor financieel management.
Maar daar zit wellicht een bottleneck. In mijn ervaring zijn meeste ERP systemen zo rigide samen met de managerial processen eromheen, dat het weken kan duren met goedkeuringen, en processen over afdelingen heen, voordat een medewerker van de ene afdeling naar een andere geplaatst kan worden. Maar in een wendbare organisatie moet het juist supermakkelijk zijn (ik stel me al een erp systeem voor waar je met drag en drop teams kunt verplaatsen…😉) om flexibel aanpassingen te maken hiermee (Als je al een erp systeem nodig hebt nog) Zie mijn blog: de wendbare organisatie volgens de boston matrix waar ik laat zien dat het noodzakelijk moet zijn om dit per kwartaal met gemak te doen.
Maar het is niet zo simpel. ERP systemen zijn ingevuld met functiehuizen (zie mijn blog: Functiehuizen: slopen! ) en structuren en businessregels. Dus dat moet ook allemaal simpeler en flexibeler. Dit zijn zaken waar stafafdelingen HR en Control (ja, multidisciplinair!) samen over na moeten denken.
Wie kent er een ERP systeem dat zo dynamisch is? Of maken juist de organisatie structuren en regels een erp systeem star, en zijn meeste erp systemen er wel voor geschikt in beginsel?
Epiloog
Even lijkt het over ERP systemen te gaan. Maar nee, het hoofd thema is wendbare organisaties. En dat we geen wendbare organisatie kunnen worden als we vast blijven houden aan starre organigrammen die maar eens per 5 jaar in een grote reorganisatie mogen wijzigen. En daarmee gaat het over flexibiliteit en aanpasbaarheid van organisatie structuur, besturing, management, medewerkers, en onderliggende processen en hulpmiddelen die intern de organisatie ondersteunen.
Dit alles valt natuurlijk te nuanceren. Want hoe ver moet je hierin gaan. Welk type organisatie ben je, hoe innovatief moet je zijn als organisatie enzovoort. Maar vooral commerciële bedrijven zullen deze dans niet kunnen ontspringen.
Hier als opsomming nog een tabel met in willekeurige volgorde een niet uitputtende lijst met kenmerken van een klassieke en een wendbare organisatie:
| Klassieke Angelsaksische organisatie | Wendbare organisatie |
| Statisch organigram | Dynamische netwerkview |
| Afdelingen | Waardestromen met teams van teams |
| Bouwblok: Individuele disciplines | Bouwblok: Multidisciplinaire teams |
| Stafafdelingen | Multidisciplinaire stafteams per waardestroom en één corporate multidisciplinair stafteam |
| Silo’s die op zichzelf staand geen waarde kunnen leveren | Waardestromen per product of dienst met alle teams benodigd om waarde te leveren end-to-end. |
| Management aan de top en sturend | Management vormt de achterkant en is faciliterend |
| Medewerkers vaak ver van eindklant | Medewerkers in teams dichtbij de eindklant |
| Jaarcycli | Kwartaalcycli, daarbinnen 2 wekelijkse cycli |
| Jaarplannen | Productvisie met rolling forecast roadmaps |
| Management verantwoordelijk voor inhoud | Productmanagement verantwoordelijk voor inhoud |
| Management stuurt op inhoudelijke resultaten | Management stuurt op voortdurende ontwikkeling en verbetering van de organisatie |
| Weinig tot geen autonomie | Bij volwassenheid teams veel autonomie binnen gestelde kaders |
| Innovatie door projecten | Innovatie door productmanagement in zelfde flow door MVP’s in backlogs of door opstart nieuw product team met lean start-up en innovation accounting principes |
| Rapportages en rapportagelijnen | Dashboard ruimtes (Obeya’s) met actuele informatie voor performance dialogen en besluitvorming |
| Prioriteit vaak bepaald door wie hardste schreeuwt | Prioriteit bepaald op basis van economische waarde van elk initiatief ten opzichte van elkaar |
| Overlegvormen | Werkvormen |
| Sturen op efficiency | Sturen op effectiviteit |
