Na een overname komt vroeg of laat dezelfde vraag op tafel:

Hoe moet de nieuwe organisatie straks daadwerkelijk functioneren?

Dat is iets anders dan:

Hoe ziet het nieuwe organigram eruit?

Een organigram laat zien wie waar zit.

Een Target Operating Model laat zien hoe de organisatie werkt.

Voor mij is dat het belangrijkste verschil.

Na een fusie of overname moet namelijk veel opnieuw op elkaar aansluiten:

strategie;
verantwoordelijkheden;
teams;
besluitvorming;
processen;
managementlagen;
data;
systemen;
KPI’s;
governance.

Als die onderdelen niet op elkaar aansluiten, blijft de organisatie ingewikkeld.

Ook wanneer het nieuwe organigram er op papier logisch uitziet.

Mijn ervaring als interim-manager is daarom dat een Target Operating Model vooral één doel moet hebben:

de nieuwe organisatie werkbaar maken.

Begin niet bij de twee bestaande organisaties

Een veelgemaakte fout is om organisatie A en organisatie B als uitgangspunt te nemen.

Dan begint de discussie bijvoorbeeld met:

wie krijgt welke functie?
welk team valt waaronder?
welke directeur blijft verantwoordelijk?
welke afdeling wordt samengevoegd?
welke managementlaag blijft bestaan?

Dat voelt logisch.

Maar het risico is groot dat je dan vooral twee historische structuren probeert te combineren.

Mijn voorkeur is anders.

Ik begin liever met:

Welke organisatie hebben we nodig om de strategie van de gecombineerde onderneming uit te voeren?

Pas daarna kijk ik naar de bestaande structuren.

Mijn volgorde bij organisatieontwerp

Ik probeer ongeveer deze volgorde aan te houden:

Wat moet de nieuwe onderneming bereiken?
Welke capabilities zijn daarvoor nodig?
Welke activiteiten moeten centraal?
Welke activiteiten moeten dicht bij klant of operatie blijven?
Welke verantwoordelijkheden horen waar?
Welke besluiten moeten op welk niveau worden genomen?
Welke processen moeten over functies heen werken?
Welke technologie ondersteunt dat model?
Welke functies en managementlagen zijn daarna nodig?

Die volgorde voorkomt dat bestaande functietitels de toekomst bepalen.

Mijn praktische aanpak van een Design Framework dat zou kunnen worden toegepast bij het bepalen van het Target Operating Model (TOM)

Van strategie naar een werkende organisatie

Ontwerplaag	Centrale vraag	Wat moet worden vastgesteld?	Typisch risico wanneer dit onduidelijk blijft
1. Strategie & waardecreatie	Wat moet de gecombineerde onderneming beter kunnen dan vóór de transactie?	Strategische doelen, deal rationale, klantbelofte, synergie en gewenste capabilities	Bestaande structuren bepalen de toekomst
2. Capabilities	Welke organisatorische vermogens zijn nodig om die strategie uit te voeren?	Kritieke commerciële, operationele en ondersteunende capabilities	Alles wordt even belangrijk behandeld
3. Operating principles	Volgens welke principes willen we de organisatie inrichten?	Schaal versus autonomie, standaardisatie versus flexibiliteit, klantnabijheid, control en snelheid	Iedere ontwerpdiscussie wordt opnieuw gevoerd
4. Verdeling centraal/decentraal	Waar hoort iedere capability het beste thuis?	Groepsniveau, businessunit, regio, shared service of hybride model	Overcentralisatie of juist blijvende duplicatie
5. Accountability & decision rights	Wie is verantwoordelijk en welke beslissingen horen daarbij?	Resultaatverantwoordelijkheid, bevoegdheden, escalaties en interfaces	Verantwoordelijkheid zonder bevoegdheid
6. End-to-end processen	Hoe loopt het werk door de nieuwe organisatie?	Procesownership, overdrachten, uitzonderingen, servicelevels en samenwerking tussen functies	Nieuw organigram, oude manier van werken
7. Organisatiestructuur	Welke teams, functies en managementlagen zijn vervolgens nodig?	Structuur, spans of control, managementlagen en rollen	Functies worden ontworpen voordat het werk duidelijk is
8. Data, KPI’s & governance	Hoe weten we of het model werkt en hoe wordt het bestuurd?	KPI’s, managementinformatie, governance, data ownership en performancecyclus	Veel overleg maar weinig bestuurbaarheid
9. Technologie	Welke technologie moet dit operating model ondersteunen?	Applicaties, workflows, autorisaties, architectuur en data	De organisatie moet zich aanpassen aan oude systemen
10. Implementatie & borging	Hoe wordt het nieuwe model dagelijkse werkelijkheid?	Transitie, benoemingen, proceswijzigingen, systeemaanpassingen en gedragsverandering	TOM blijft een PowerPoint-ontwerp

De volgorde is bewust. Ik ontwerp eerst hoe de onderneming moet functioneren en pas daarna welke functies en systemen daarvoor nodig zijn.

Mijn eerste ontwerpbeslissing: wat moet centraal, decentraal of hybride?

Een van de lastigste discussies na een overname is vaak:

Moeten we dit centraliseren?

Ik vind dat meestal de verkeerde eerste vraag. De betere vraag is:

Welke organisatorische inrichting creëert voor deze specifieke capability de meeste waarde?

Daarbij beoordeel ik iedere belangrijke capability langs dezelfde criteria.

Centralisatie- en decentralisatiematrix

Criterium	Meer reden om te centraliseren	Meer reden om te decentraliseren
Schaalvoordeel	Grote voordelen door volume, bundeling of gedeelde capaciteit	Beperkt schaalvoordeel
Standaardisatie	Eén werkwijze levert kwaliteit of efficiency op	Lokale verschillen creëren juist waarde
Risico & control	Sterke centrale beheersing of compliance nodig	Risico kan goed lokaal worden beheerst
Klantnabijheid	Beperkte lokale klantdifferentiatie	Klantkennis en lokale respons zijn cruciaal
Beslissnelheid	Besluiten kunnen efficiënt centraal worden genomen	Centrale besluitvorming zou vertragen
Schaarse expertise	Specialistische kennis is schaars en kan beter worden gebundeld	Expertise moet dagelijks dicht bij operatie zitten
Data & technologie	Eén platform of dataset is belangrijk	Lokale technologie ondersteunt een onderscheidend proces
Procesafhankelijkheid	Activiteiten zijn sterk gemeenschappelijk of ketenbreed	Activiteiten zijn grotendeels zelfstandig
Kosten	Duplicatie is substantieel	Centralisatie creëert juist extra coördinatiekosten
Ondernemerschap	Consistentie is belangrijker dan lokale vrijheid	Lokale innovatie en marktrespons zijn belangrijk

Dit betekent dat ik zelden voor de gehele onderneming één antwoord geef op de vraag centraal of decentraal. Procurement kan bijvoorbeeld sterk centraal georganiseerd worden terwijl klantverantwoordelijkheid lokaal blijft. Cybersecurity kan centrale standaarden en governance hebben terwijl operationele IT-capaciteit dicht bij de business georganiseerd blijft. Een capability kan bovendien hybride worden ingericht: centrale kaders + lokale uitvoering. Daarom ontwerp ik een operating model capability voor capability.

De tweede test: verantwoordelijkheid en bevoegdheid moeten bij elkaar passen

Een veelvoorkomend probleem in organisaties is dat iemand formeel verantwoordelijk is voor een resultaat, maar niet voldoende beslissingsbevoegdheid heeft om dat resultaat te beïnvloeden. Daarom test ik belangrijke verantwoordelijkheden met vijf vragen:

Vraag	Wat ik wil kunnen beantwoorden
Wie is accountable?	Eén herkenbare eigenaar van het resultaat
Welke besluiten mag deze persoon nemen?	Expliciete decision rights
Welke middelen kan hij of zij beïnvloeden?	Budget, mensen, capaciteit, prijs, systemen enzovoort
Van wie is deze rol afhankelijk?	Belangrijkste interfaces
Wanneer is escalatie nodig?	Duidelijke uitzonderingen en escalatieniveaus

Wanneer iemand bijvoorbeeld verantwoordelijk is voor commerciële performance terwijl pricing, capaciteit, product en uitzonderingen allemaal elders worden besloten, is accountability vooral theoretisch. Mijn regel is daarom:

Verantwoordelijkheid zonder voldoende beslissingsbevoegdheid creëert overleg; verantwoordelijkheid mét duidelijke decision rights creëert bestuurbaarheid.

De derde test: wat gebeurt er met het werk?

Na een reorganisatie stel ik vrijwel altijd dezelfde vraag:

Welk proces gaat door deze organisatiewijziging daadwerkelijk anders lopen?

Dat is een eenvoudige maar krachtige test. Stel dat Finance wordt gecentraliseerd. Dan wil ik niet alleen weten waar medewerkers straks rapporteren. Ik wil weten:

welke werkzaamheden centraal worden uitgevoerd;
wat lokaal blijft;
wie eigenaar is van Record-to-Report;
waar overdrachtsmomenten ontstaan;
welke uitzonderingen mogelijk zijn;
welke servicelevels gelden;
welke beslissingen lokaal blijven;
welke data nodig is;
en welke systemen dit ondersteunen.

Wanneer het organigram verandert maar het werk niet, is vaak alleen de rapportagelijn veranderd. Een Target Operating Model moet daarom altijd zichtbaar worden in processen.

Mijn TOM Design Decision Matrix

Bij belangrijke ontwerpkeuzes gebruik ik in de praktijk een bredere afweging. Bijvoorbeeld:

Ontwerpoptie	Strategische bijdrage	Klantimpact	Schaalvoordeel	Beslissnelheid	Control	Kostenpotentieel	Implementatiecomplexiteit	Afhankelijkheden
Volledig centraal	Hoog	Middel	Zeer hoog	Middel	Zeer hoog	Hoog	Hoog	Hoog
Volledig decentraal	Middel	Zeer hoog	Laag	Zeer hoog	Middel	Laag	Laag	Laag
Hybride model	Zeer hoog	Hoog	Hoog	Hoog	Hoog	Hoog	Zeer hoog	Zeer hoog

De bedoeling is niet om automatisch cijfers bij elkaar op te tellen. Het gesprek erachter is belangrijker. Een hybride model kan op papier bijvoorbeeld op bijna ieder criterium aantrekkelijk lijken, maar tegelijkertijd zoveel interfaces en governance nodig hebben dat het in de praktijk complexer wordt dan beide uitersten. Daarom vraag ik altijd: Welke complexiteit creëren we zelf met deze ontwerpkeuze?

Een praktisch voorbeeld: procurement

Stel dat na een overname twee ondernemingen ieder hun eigen procurementfunctie hebben. De eerste reactie kan zijn:

Eén procurementorganisatie is goedkoper, dus centraliseren.

Ik zou eerst de criteria bekijken.

Strategische vraag

Waar zit de waarde?

groter inkoopvolume;
gezamenlijke leveranciers;
uniforme voorwaarden;
betere spend visibility.

Dat wijst richting centralisatie. Maar vervolgens:

Klant- en operationele context

Zijn er lokale leveranciers die essentieel zijn voor specifieke locaties?

Expertise

Zijn categorie-experts centraal schaalbaar?

Beslissnelheid

Kan een lokale operatie nog snel inkopen wanneer dat nodig is?

Control

Welke spend moet centraal worden beheerst? Daaruit kan bijvoorbeeld ontstaan: centrale category management en contractering + lokale operationele bestelmogelijkheid binnen kaders. Dat is iets anders dan simpelweg twee procurementafdelingen samenvoegen.

Vier ontwerpopties die ik expliciet naast elkaar zet

Bij een integratie wil ik voorkomen dat de discussie automatisch wordt: A of B? Daarom zet ik bij belangrijke onderdelen minimaal vier mogelijkheden naast elkaar:

1. Model A behouden

De werkwijze van de ene organisatie wordt leidend.

2. Model B behouden

De andere organisatie wordt leidend.

3. Best of both

Onderdelen van beide modellen worden gecombineerd.

4. Nieuw model C

Beide bestaande modellen worden losgelaten en er wordt ontworpen vanuit de toekomstige strategie. Die vierde optie wordt naar mijn ervaring gemakkelijk vergeten. Maar een fusie of overname kan juist het moment zijn om historische beperkingen uit beide organisaties niet mee te nemen. Mijn voorkeursvraag is daarom:

Als we deze onderneming vandaag opnieuw zouden mogen ontwerpen, zouden we dan werkelijk voor model A of B kiezen?

Als het antwoord nee is, verdient model C serieuze aandacht.

Van ontwerp naar implementatie: mijn TOM Reality Check

Een Target Operating Model is voor mij pas geslaagd wanneer het zichtbaar wordt in het dagelijkse functioneren. Daarom toets ik het ontwerp uiteindelijk langs een tweede set criteria.

Reality check	Vraag
Ownership	Weten mensen waarvoor zij werkelijk verantwoordelijk zijn?
Decision rights	Worden besluiten genomen op het bedoelde niveau?
Snelheid	Zijn belangrijke besluiten sneller dan vóór de verandering?
Escalaties	Zijn minder escalaties nodig om normaal werk gedaan te krijgen?
Processen	Lopen end-to-end processen zoals ontworpen?
Interfaces	Is duidelijk waar verantwoordelijkheden tussen teams overgaan?
Managementlagen	Voegt iedere managementlaag aantoonbaar waarde toe?
KPI’s	Sturen teams op de resultaten waarvoor zij verantwoordelijk zijn?
Data	Is voor besluitvorming dezelfde betrouwbare informatie beschikbaar?
Technologie	Ondersteunen systemen de nieuwe rollen en processen?
Kosten	Zijn verwachte schaal- of efficiencyvoordelen werkelijk gerealiseerd?
Klant	Merkt de klant minder interne complexiteit in plaats van meer?

Een groen organigram betekent dus niet automatisch een groen operating model.

Signalen dat het TOM op papier wel klopt, maar in de praktijk niet

Ik let vooral op terugkerende symptomen:

dezelfde beslissingen worden meerdere keren besproken;
verantwoordelijkheden worden steeds naar andere functies doorgeschoven;
uitzonderingen gaan structureel via directie;
centraal en lokaal discussiëren voortdurend over bevoegdheden;
teams creëren workarounds buiten formele processen;
oude rapportages blijven naast nieuwe bestaan;
systemen ondersteunen nog de oude verantwoordelijkheden;
medewerkers weten formeel waar ze horen, maar niet wie over het werk beslist;
management besteedt veel tijd aan interne afstemming;
de beoogde kosten- of schaalvoordelen blijven uit.

Dit zijn voor mij geen losse operationele problemen. Het zijn signalen dat een onderdeel van het operating model nog niet goed ontworpen of geïmplementeerd is.

Mijn volgorde van afhankelijkheden

Een Target Operating Model raakt bijna iedere andere integratiewerkstroom. Daarom hanteer ik waar mogelijk deze ontwerpvolgorde: Strategie en deal rationale ↓ Capabilities ↓ Operating principles ↓ Centraal / decentraal / hybride ↓ Accountability en decision rights ↓ End-to-end processen ↓ Organisatiestructuur en rollen ↓ Data en KPI’s ↓ Technologie ↓ Implementatie en gedrag De pijlen zijn belangrijk. Een keuze bovenin creëert namelijk randvoorwaarden voor keuzes daaronder. Wanneer je bijvoorbeeld systemen selecteert voordat procesownership en verantwoordelijkheden duidelijk zijn, bestaat het risico dat technologie het toekomstige operating model gaat dicteren. Andersom kan een helder operating model richting geven aan processen, data en systeemkeuzes.

Wanneer is een TOM-besluit rijp?

Niet ieder onderdeel hoeft tegelijkertijd definitief te worden gemaakt. Bij iedere belangrijke ontwerpkeuze kijk ik daarom ook naar beslisrijpheid.

Status	Betekenis
Hypothese	Dit lijkt de beste richting, maar cruciale informatie ontbreekt nog
Ontwerpprincipe	We hebben bepaald volgens welke regel we willen organiseren
Voorkeursmodel	Alternatieven zijn beoordeeld en één model heeft de voorkeur
Besloten	Governance heeft de keuze formeel gemaakt
Ontworpen	Rollen, processen, interfaces en consequenties zijn uitgewerkt
Geïmplementeerd	Organisatie werkt daadwerkelijk volgens het nieuwe model
Bewezen	KPI’s en dagelijkse praktijk laten zien dat het model beter functioneert

Dit onderscheid vind ik belangrijk. Een managementteam kan namelijk zeggen:

“Het TOM is klaar.”

terwijl alleen een organisatiestructuur is goedgekeurd. Dat is voor mij hooguit één onderdeel van het ontwerp.

Mijn belangrijkste TOM-principe

Mijn belangrijkste ontwerpregel is uiteindelijk eenvoudig:

Ontwerp niet twee bestaande organisaties aan elkaar. Ontwerp eerst hoe de gecombineerde onderneming moet werken en bepaal daarna welke structuur, processen, mensen, data en technologie daarvoor nodig zijn.

Daarmee verschuift de discussie van historische posities naar toekomstige prestaties. En dat is precies wat een Target Operating Model na een overname volgens mij moet doen. Niet beschrijven hoe de organisatie eruitziet. Maar expliciet maken hoe zij haar strategie gaat uitvoeren.

Een nieuw Target Operating Model moet problemen oplossen

Ik vind een TOM pas interessant wanneer het concreet iets beter maakt.

Bijvoorbeeld:

minder onduidelijkheid over ownership;
snellere besluitvorming;
minder escalaties;
minder dubbele verantwoordelijkheden;
duidelijkere processen;
betere samenwerking tussen functies;
lagere overhead;
meer schaalvoordeel;
meer ruimte voor lokaal ondernemerschap;
betere aansluiting tussen business en IT.

Daarmee wordt organisatieontwerp veel concreter.

De vraag is niet:

“Hebben we straks een mooi operating model?”

De vraag is:

“Kan de organisatie hierdoor beter werken?”

Mijn eerste test: weet iedereen wie waarover gaat?

Na een overname zie ik regelmatig dat verantwoordelijkheden formeel zijn verdeeld, maar in de praktijk niet duidelijk zijn.

Bijvoorbeeld:

Sales is verantwoordelijk voor omzet;
Pricing zit centraal;
Operations bepaalt capaciteit;
Product bepaalt aanbod;
Finance bepaalt uitzonderingen.

Dan is één functie formeel eigenaar van het resultaat, maar heeft zij niet alle knoppen om dat resultaat te beïnvloeden.

Dat leidt vaak tot:

veel overleg;
escalaties;
vertraging;
frustratie;
lokaal gedrag;
onduidelijk eigenaarschap.

Een goed Target Operating Model moet dit oplossen.

Mijn praktische tip

Vraag bij ieder belangrijk resultaat:

Wie is werkelijk accountable?

Daarna:

Welke besluiten mag die persoon zelf nemen?
Welke besluiten liggen elders?
Welke informatie is nodig?
Welke andere functies zijn afhankelijk?
Wanneer is escalatie nodig?

Als verantwoordelijkheid en bevoegdheid niet bij elkaar passen, is het model nog niet goed ontworpen.

Centraal of decentraal? Stel de vraag per capability

Na een overname ontstaat vaak snel de discussie:

Gaan we centraliseren of decentraliseren?

Ik vind dat meestal een te grove vraag.

Per onderdeel kan het antwoord anders zijn.

Bijvoorbeeld:

Mogelijk centraal

procurement;
financiële rapportage;
cybersecurity;
infrastructuur;
bepaalde HR-processen;
data governance.

Mogelijk decentraal

klantrelaties;
lokale commerciële keuzes;
operationele uitvoering;
productbeslissingen dicht bij specifieke markten.

De juiste keuze hangt af van wat je wilt bereiken.

Denk bijvoorbeeld aan:

schaal;
snelheid;
klantnabijheid;
innovatie;
controle;
flexibiliteit;
kosten.

Mijn regel

Centraliseer waar schaal en consistentie waarde creëren.

Decentraliseer waar snelheid, klantkennis of ondernemerschap belangrijker zijn.

Niet alles hoeft hetzelfde georganiseerd te worden.

Een TOM moet besluitvorming eenvoudiger maken

Een organisatie kan op papier heel duidelijk zijn en toch traag functioneren.

Dat gebeurt vaak wanneer beslissingen over meerdere functies worden verdeeld.

Bijvoorbeeld:

businessunit wil investeren;
Finance moet goedkeuren;
IT moet toetsen;
Procurement moet selecteren;
directie moet uiteindelijk besluiten.

Dat kan terecht zijn.

Maar het kan ook betekenen dat niemand meer weet waar een besluit werkelijk thuishoort.

Daarom vind ik decision rights een essentieel onderdeel van een Target Operating Model.

Ik wil weten:

wie beslist;
wie adviseert;
wie wordt geraadpleegd;
wie wordt geïnformeerd;
wanneer escalatie nodig is.

Mijn praktische tip

Pak de tien meest terugkerende managementbesluiten.

Vraag per besluit:

Waarom duurt dit nu zo lang?

Vaak wordt daarmee snel zichtbaar waar het nieuwe operating model moet worden aangescherpt.

Managementlagen moeten waarde toevoegen

Spans of control en managementlagen krijgen bij reorganisaties veel aandacht.

Vaak vanuit kosten.

Dat begrijp ik.

Maar alleen managementlagen verwijderen maakt een organisatie niet automatisch beter.

Ik kijk liever naar de functie van iedere laag.

Vraag bijvoorbeeld:

Welke besluiten worden hier genomen?
Welke problemen worden hier opgelost?
Welke coaching wordt geleverd?
Welke expertise wordt toegevoegd?
Welke afstemming zou verdwijnen als deze laag niet bestond?

Als daar geen duidelijk antwoord op komt, kan de laag mogelijk weg.

Maar als verantwoordelijkheden niet opnieuw worden ingericht, ontstaat er vaak een nieuw probleem.

Dan krijgen managers bijvoorbeeld:

te veel directe reports;
te veel operationele beslissingen;
te weinig tijd voor klanten;
te weinig tijd voor performance;
meer escalaties.

Mijn uitgangspunt is daarom:

niet minder management om het aantal managers te verlagen, maar minder management waar het geen waarde toevoegt.

Een nieuwe structuur is pas werkbaar als processen ook kloppen

Een Target Operating Model kan niet los worden ontworpen van processen.

Stel dat je een nieuwe centrale afdeling creëert.

Dan moet duidelijk worden:

welk werk daar terechtkomt;
wat lokaal blijft;
wie procesowner is;
waar overdrachten plaatsvinden;
welke servicelevels gelden;
welke uitzonderingen mogelijk zijn.

Anders verandert alleen het organigram.

Het werk blijft hetzelfde.

Dat zie ik in integraties regelmatig gebeuren.

Een functie wordt gecentraliseerd, maar oude lokale processen blijven bestaan.

Het gevolg:

meer overdracht;
dubbel werk;
onduidelijkheid;
uitzonderingen;
frustratie tussen centraal en lokaal.

Mijn tip

Vraag na iedere organisatiewijziging:

Welk proces moet hierdoor anders gaan lopen?

Als het antwoord “geen” is, vraag ik me af of de wijziging werkelijk iets verbetert.

Een TOM moet ook door IT ondersteund kunnen worden

Organisatieontwerp en technologie worden soms los van elkaar behandeld.

Dat werkt zelden goed.

Een nieuw operating model creëert bijvoorbeeld andere:

rollen;
autorisaties;
workflows;
rapportagelijnen;
data ownership;
managementinformatie.

Dat heeft gevolgen voor systemen.

Daarom hanteer ik graag deze volgorde:

strategie → operating model → processen → verantwoordelijkheden → data → systemen.

Niet andersom.

Mijn ervaring

Wanneer IT te vroeg wordt vastgezet, moet de organisatie zich later aanpassen aan technologie die eigenlijk bij het oude model hoorde.

Dat levert vaak onnodig maatwerk en workarounds op.

Managers ontwerpen ook hun eigen toekomst

Dit is een van de lastigste kanten van een Target Operating Model na een overname.

De mensen met de meeste kennis over de organisatie hebben vaak ook persoonlijk belang bij de uitkomst.

Dat is menselijk.

Denk aan discussies over:

managementlagen;
centralisatie;
verantwoordelijkheden;
budget;
functies;
teams;
rapportagelijnen.

Een manager kan inhoudelijk goede argumenten hebben.

Tegelijk kan een andere keuze gevolgen hebben voor zijn eigen rol.

Daarom duren TOM-discussies soms lang.

Er komen uitzonderingen.

Alternatieven worden opnieuw geopend.

Bestaande verantwoordelijkheden worden zoveel mogelijk behouden.

En uiteindelijk ontstaat soms een compromis waarin beide oude organisaties herkenbaar blijven.

Dat is politiek begrijpelijk.

Maar het levert niet altijd de beste nieuwe organisatie op.

Mijn praktische tip: werk met ontwerpprincipes vóór je over functies praat

Voordat personen en functietitels worden besproken, probeer ik duidelijke ontwerpprincipes vast te leggen.

Bijvoorbeeld:

maximaal X managementlagen;
klantverantwoordelijkheid blijft lokaal;
specialistische expertise wordt centraal gebundeld;
één owner per end-to-end proces;
financiële rapportage wordt gestandaardiseerd;
decision rights worden zo laag mogelijk gelegd;
ondersteunende functies worden waar mogelijk gedeeld.

Daarmee verandert de discussie.

Niet:

“Wie krijgt welke functie?”

Maar:

“Welk ontwerp past bij de principes die we samen hebben afgesproken?”

Dat maakt gesprekken objectiever.

“Best of both” is niet altijd de beste oplossing

Bij integraties hoor je vaak:

“We nemen het beste van beide organisaties.”

Dat klinkt aantrekkelijk.

Maar soms is geen van beide modellen geschikt voor de toekomst.

Organisatie A kan bijvoorbeeld te centraal zijn.

Organisatie B te decentraal.

De oplossing is dan niet:

A of B.

Maar:

C.

Een nieuw model dat beter past bij:

strategie;
schaal;
klantbehoefte;
technologie;
toekomstige groei.

Dat is voor mij een belangrijke TOM-les.

Een Target Operating Model is niet het compromis tussen twee oude organisaties.

Het is het ontwerp van de organisatie die je straks nodig hebt.

Een TOM moet in de dagelijkse praktijk zichtbaar worden

Een nieuw organigram communiceren is relatief eenvoudig.

Een nieuwe organisatie laten werken is veel moeilijker.

Na de aankondiging moeten namelijk nog veel dingen veranderen:

verantwoordelijkheden;
overlegstructuren;
besluitvorming;
KPI’s;
escalaties;
processen;
managementgedrag;
systemen;
rapportages.

Zonder die veranderingen blijft het oude operating model vaak bestaan.

Dan krijg je bijvoorbeeld:

nieuw organigram + oude besluitvorming

of:

nieuwe teams + oude verantwoordelijkheden

of:

centrale functie + lokaal gedrag

Daarom beschouw ik implementatie als onderdeel van het Target Operating Model.

Niet als iets wat daarna vanzelf gebeurt.

Mijn TOM-implementatiecheck

Na invoering van een nieuw model kijk ik vooral naar deze vragen:

Weten mensen waarvoor zij verantwoordelijk zijn?
Weten zij waarover zij zelf mogen beslissen?
Zijn er minder escalaties?
Worden besluiten sneller genomen?
Is duidelijk wie eigenaar is van end-to-end processen?
Werken centrale en lokale teams goed samen?
Zijn oude overlegstructuren verdwenen?
Sluiten KPI’s aan op nieuwe verantwoordelijkheden?
Ondersteunen systemen het nieuwe model?
Wordt de strategie aantoonbaar beter uitvoerbaar?

Als veel van die vragen nog met “nee” worden beantwoord, is het TOM nog niet geïmplementeerd.

Ook wanneer het organigram formeel al live staat.

Tijdelijke oplossingen zijn soms verstandig

Niet ieder onderdeel van het nieuwe operating model hoeft direct definitief te zijn.

Soms is een tijdelijke oplossing beter.

Bijvoorbeeld:

interim-management;
tijdelijke governance;
tijdelijke procesowner;
tijdelijke rapportage;
tijdelijke centrale functie.

Dat geeft tijd om ervaring op te doen.

Maar alleen als duidelijk is:

waarom het tijdelijk is;
wanneer het wordt geëvalueerd;
wie eigenaar is;
wat het uiteindelijke doelmodel is.

Anders worden tijdelijke oplossingen ongemerkt permanent.

Wanneer werkt een Target Operating Model goed?

Voor mij is het nieuwe operating model geslaagd wanneer medewerkers minder tijd kwijt zijn aan de organisatie zelf.

Dat merk je bijvoorbeeld doordat:

ownership duidelijk is;
besluiten sneller vallen;
minder escalaties nodig zijn;
managers minder intern hoeven af te stemmen;
processen eenvoudiger lopen;
centrale en lokale verantwoordelijkheden duidelijk zijn;
IT beter aansluit;
managementinformatie bruikbaarder wordt;
klanten minder last hebben van interne complexiteit.

Dat is uiteindelijk waar organisatieontwerp voor bedoeld is.

Niet een mooier PowerPoint-schema.

Maar een organisatie die werkbaar is.

Mijn belangrijkste lessen bij het ontwerpen van een Target Operating Model

1. Begin bij strategie

Niet bij bestaande functies.

2. Ontwerp eerst het werk, daarna de hokjes

Verantwoordelijkheden en processen zijn belangrijker dan titels.

3. Leg decision rights expliciet vast

Onduidelijke besluitvorming maakt vrijwel ieder model traag.

4. Centraliseer niet automatisch

Bepaal per capability waar de meeste waarde ontstaat.

5. Managementlagen moeten aantoonbaar iets toevoegen

Niet iedere historische laag hoeft terug te komen.

6. Organisatie en processen horen bij elkaar

Een nieuwe structuur zonder aangepaste processen verandert weinig.

7. IT volgt het operating model

Niet andersom.

8. Maak belangen bespreekbaar

Organisatieontwerp raakt vrijwel altijd persoonlijke posities.

9. Implementatie hoort bij het ontwerp

Een TOM op papier is nog geen nieuwe organisatie.

10. Test het model in het dagelijkse werk

De echte vraag is:

wordt het makkelijker om de organisatie te besturen en resultaten te realiseren?

De echte test van een Target Operating Model

Ik beoordeel een Target Operating Model uiteindelijk niet aan de hand van het organigram.

Ik kijk naar het dagelijkse werk.

Kunnen mensen sneller beslissen?

Is ownership duidelijk?

Zijn minder escalaties nodig?

Kunnen teams zelfstandig handelen?

Werken functies beter samen?

Kan management meer tijd besteden aan:

klanten;
medewerkers;
performance;
groei;

in plaats van aan interne afstemming?

Als dat gebeurt, wordt de nieuwe organisatie werkelijk werkbaar.

En dat is voor mij het doel van een Target Operating Model na een overname.

Niet twee bestaande organisaties zo netjes mogelijk samenvoegen.

Maar een organisatie bouwen die beter in staat is om de strategie uit te voeren en de waarde van de overname daadwerkelijk te realiseren.

De vraag waarmee ik zo’n ontwerp daarom graag begin, blijft eenvoudig:

Als we vandaag met de gecombineerde onderneming opnieuw zouden beginnen, zouden we haar dan werkelijk zo organiseren? Meer lezen over HR integratie na overname Meer artikelen lezen over postmerger integratie en bedrijfsprocessen automatiseren?