Target Operating Model en organisatiestructuur | Postmerger interimmanagement

Target Operating Model nieuwe organisatie

 

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:

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

Die volgorde voorkomt dat bestaande functietitels de toekomst bepalen.

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 artikelen lezen over postmerger integratie en bedrijfsprocessen automatiseren?  

Wie ik ben:

Ik ben een hands-on interim-manager die strategie, mensen en operatie bij elkaar brengt. Geen dikke rapporten, maar uitvoering, grip en resultaat.

✔ 20+ jaar ervaring met complexe integraties

✔ Interim inzetbaar op directieniveau als COO, CIO of programmamanager

✔ Focus op synergie, rust, structuur en meetbaar resultaat

✔ Flexibel inzetbaar, met heldere afspraken en marktconforme tarieven

 

Meer info over Robrecht Heukers