Archive by Author

Hoe houd je grip op multisourcing?

Multisourcing is een wijdverbreid fenomeen geworden. Dramadriehoeken leiden daarbij echter veelvuldig tot ongewenste effecten. Met een methodische aanpak zijn tegenmaatregelen echter eenvoudig en effectief in te zetten.

Het aantal partijen dat tegenwoordig betrokken is bij de uitvoering van de werkzaamheden van een organisatie, neemt als gevolg van verregaande verbijzondering van taken sterk toe. Multisourcing is daarmee aan de orde van de dag.

Een dramadriehoek is een relatie tussen drie partijen, waarbij het in de samenwerking mis gaat. Elk van de drie partijen heeft eigen belangen, waardoor het stelsel (de driehoek) faalt.

Multisourcing leidt tot vele dramadriehoeken.

Een voorbeeld van een dramadriehoek in sourcing.

De figuur hiernaast illustreert een dramadriehoek bij outsourcing. De rood gestippelde pijl duidt de relatie aan waar het mis gaat. De zwarte schaduwrand duidt op de noodzakelijke regietaak van de opdrachtgever.

Voor een voorbeeld: zie de blog over dramadriehoeken

Pingpong

Als de afspraken tussen de opdrachtgever en beide toeleveranciers/oplosgroepen niet voorzien in een effectieve samenwerkingsrelatie, dan hoef je vaak niet lang te wachten op problemen. Zodra de demarcatielijn tussen de uitvoerende partijen voor minimaal één van beide niet meer helemaal helder is, en er doet zich een situatie voor waarin een issue ‘tussen wal en schip valt’, dan gaat die issue pingpongen tussen de beide uitvoerders:

“Je moet bij de één zijn.”
“Nee, je moet bij de ander zijn.”

De opdrachtgever is dan de dupe van zijn eigen (gebrekkige) afsprakenstelsel.

Omdat de verschillende uitvoerders sturen op verschillende optimalisatiedoelen, sluit het resultaat niet meer aan op de belangen van de opdrachtgever.

Multisourcing = multidrama

Het aantal dramarelaties neemt sneller toe dan het aantal toeleveranciers

Als het al lastig is om sluitende afspraken over twee deelopdrachten te maken, dan mag duidelijk zijn dat dit bij drie deelopdrachten nog veel lastiger is. Het linkerschema in de figuur hiernaast illustreert dat het aantal potentiële drama-relaties dan zelfs van één naar drie springt.

Bij vier deelopdrachten verdubbelt het aantal potentiële drama-relaties zelfs van drie naar zes. Bij vijf deelopdrachten springt dat vervolgens naar tien. En dan te bedenken dat veel opdrachtgevers tegenwoordig nog aanzienlijk méér dan vijf toeleveranciers hebben. Zolang dat deeltaken zijn die weinig met elkaar te maken hebben is dat niet zo erg, maar wát, als die deeltaken binnen één en hetzelfde taakgebied vallen? In de informatievoorziening leidt die situatie inmiddels dagelijks tot problemen… 

Regie

Het mag duidelijk zijn dat het aantal drama-relaties (de rode lijnen) veel sneller toeneemt dan het aantal partijen dat in een multisourcing-situatie wordt betrokken. Dat legt een steeds zwaardere last op de regievaardigheden van de opdrachtgever. Het aansturen van drie, vier of vijf toeleveranciers wil nog wel lukken, maar als ze allemaal naar elkaar wijzen, dan is er veel coördinatiegeweld nodig om de zaak aan de praat te houden. Het resultaat is een reactieve organisatie die al z’n energie kwijt is aan het herstellen van wat er mis gaat.

Het is niet moeilijk in te zien dat het blussen van al die brandjes dan snel een dagtaak wordt.

Oorzaken

Voor deze situaties zijn verschillende oorzaken aan te wijzen. Ik noem er vijf, en ik geef bij elk meteen de tegenmaatregelen aan.

1: Slecht opdrachtgeverschap

Een opdrachtgever die geen inzicht in, en overzicht over de uit te besteden diensten heeft, is ook niet in staat een sluitend stelsel van afspraken te maken waarin de toeleveranciers goed aangestuurd worden.

  • De opdrachtgever dient dus meer inzicht en overzicht te hebben – echter zonder daarbij net zo veel van de uitvoering te hoeven weten als de toeleverancier. De denk- en zienswijze van USM levert het inzicht in die dienstverlening. Met USM leert een opdrachtgever in eenvoudige termen de dienstverlening te reduceren tot een leerbare, systematische benadering, op basis van een gestandaardiseerd managementsysteem.

2: Zwakke overeenkomsten

Overeenkomsten (SLA’s) worden vaak voor een belangrijk deel bepaald door de toeleverancier, en opgesteld in de technologische termen van die (toe)leverancier. Die SLA’s zijn daardoor onderling vaak niet goed integreerbaar en maken voor de opdrachtgever niet duidelijk wat de impact op de business is.

  • USM hanteert een SMART definitie van een service, die ook goed operationaliseerbaar is. Toepassing van USM leidt daarmee tot heldere en betekenisvolle afspraken. Organisaties die worstelen met een bestaande set SLA’s kunnen baat hebben bij een gestructureerde SLA-revisie.

3: Overlappende services

Zodra SLA’s en services meerdere toeleveranciers verantwoordelijk maken voor eenzelfde prestatiekenmerk, is het afschuiven van verantwoordelijkheden eerder regel dan uitzondering. Een toeleverancier wil niet het werk doen waar een ander – in zijn ogen – voor betaald wordt.

  • Een opdrachtgever die de systematische en methodische USM-werkwijze heeft leren toepassen, stelt veel gemakkelijker de specificaties van services vast. De SMART definitie van een service ondersteunt een heldere service-tree, en voorkomt overlap en de bijbehorende ellende.

4: Concurrerende toeleveranciers

Als SLA’s voor deelservices worden belegd bij toeleveranciers die ook het deel van het werk van een andere toeleverancier hadden kunnen leveren, dan ontstaat concurrentie tussen die toeleveranciers: en wie werkt er nou graag samen met een concurrent?

Een variant op de eerste figuur, maar nu met toeleveranciers die een bredere portfolio hebben.

  • Een opdrachtgever die heeft geleerd USM toe te passen heeft het gemakkelijker om complementaire toeleveranciers te selecteren. In de onderhandelingen met toeleveranciers bepaal je sneller wat hun kerncompetenties zijn, waardoor je concurrentie voorkomt.Bij de selectie verminder je op die manier het aantal Minder toeleveranciers betekent onmiddellijk minder drama-relaties, zie de figuur hieronder. Als je de dienstverlening op deze manier onderbrengt bij leveranciers met bredere portfolio’s, dan zijn er ook minder conflicterende belangen. Uitgangspunt hierbij is de verwachting dat interne teams minder onderlinge tegenstellingen kennen dan concurrerende toeleveranciers (met onderling strijdige belangen). Deze aanpak is overigens niet oneindig, omdat ook ‘alles-kunners’ zo hun eigen problemen hebben (vendor lock-in, integratieproblemen, etc.). En pas op: externe service integrators verplaatsen slechts het probleem…

5: Slecht afgestemde werkwijzen

Als de ene toeleverancier zijn bijdragen anders structureert en daar anders over communiceert dan de vorige en de volgende, dan leidt de daaruit resulterende verwarring als snel tot meerdere dramadriehoeken.

  • Heb je als opdrachtgever meer inzicht in de dienstverlening, dan is het vervolgens stukken eenvoudiger om de samenwerking met meerdere toeleveranciers te uniformeren: standaardiseer de werkwijzen met USM. Dat kún je beperken tot de interfacing tussen de verschillende partijen: alleen die gestandaardiseerde USM-interface leidt al tot aanzienlijke verbeteringen van het stelsel. Wie echter één of meer toeleveranciers kan verleiden om – in hun eigen belang – dezelfde methodische USM-werkwijzen ook intern als standaard te gaan hanteren, haalt nog meer winst uit deze aanpak.

Conclusie: gebruik universele bouwblokken voor een servicemanagementarchitectuur

De USM-bouwblokken maken een servicemanagementarchitectuur mogelijk

Met de standaard werkwijzen die je met een servicemanagementarchitectuur kunt realiseren ontstaat het beeld van LEGO: een aantal bouwblokken om alle denkbare constructies op te zetten, maar wel op één gemeenschappelijke grondslag: de nokjes van het ene blokje passen altijd in de gaatjes van het andere blokje.

Dat LEGO-effect is mogelijk met de USM-servicemanagementarchitectuur: USM levert de bouwblokken van elk denkbaar ‘gebouw’. In de figuur hierboven is dan ook – voor het maximale LEGO-effect – bij iedere ‘speler’ in het netwerk de USM-werkwijze als verbeterstrategie aangegeven.

Hoe meer spelers het spel met dezelfde spelregels spelen, hoe beter het resultaat van het spel.

Hoe kom je van die dramadriehoeken af?

Dramadriehoeken leiden tot gebrekkige samenwerking tussen partijen. De klant c.q. de gebruikersorganisatie is daarvan de dupe. Een methodische aanpak helpt je om dat effect te voorkomen.

Een dramadriehoek is een relatie tussen drie partijen, waarbij het in de samenwerking mis gaat. Elk van die drie partijen heeft eigen belangen, waardoor het stelsel (de driehoek) faalt.

De oorzaak van een dramadriehoek is te vinden in slecht afgestemde relaties tussen in ieder geval twee van die drie partijen. Het falen van de samenwerking uit zich dan in communicatie- en coördinatieproblemen, die leiden tot slechte prestaties.

Outsourcing

Onderstaande figuur illustreert een dramadriehoek bij outsourcing. De rood gestippelde pijl duidt de relatie aan waar het mis gaat. De zwarte schaduwrand duidt op de noodzakelijke regietaak van de opdrachtgever.

Als de afspraken tussen de opdrachtgever en beide toeleveranciers/oplosgroepen niet voorzien in een effectieve samenwerkingsrelatie, dan hoef je vaak niet lang te wachten op problemen. Zodra de demarcatielijn tussen de uitvoerende partijen voor minimaal één van beide niet meer helemaal helder is, en er doet zich een situatie voor waarin een issue ‘tussen wal en schip valt’, dan gaat die issue pingpongen tussen de beide uitvoerders:

“Je moet bij de één zijn.”

“Nee, je moet bij de ander zijn.”

De opdrachtgever is dan de dupe van zijn eigen (gebrekkige) afsprakenstelsel.

Omdat de verschillende uitvoerders sturen op verschillende belangen en doelen, ontstaat een integrale service (prestatie) die niet goed past op de belangen van de opdrachtgever c.q. de gebruikersorganisatie.

Voorbeeld. Een opdrachtgever heeft een deelservice “cloud hosting” uitbesteed aan leverancier 1. Deze leverancier heeft de overeenkomst afgestemd op een optimale dienstverlening vanuit zijn eigen verdienmodel, waarbij volume en onderhoudskosten de belangrijkste drivers zijn.

Een tweede deelservice “applicatiebeheer” is uitbesteed aan leverancier 2. Deze leverancier heeft de overeenkomst geoptimaliseerd naar het aspect “urenbesteding”.

Er ontstaat een belangenconflict tussen beide leveranciers als er een issue ontstaat over de cloud-omstandigheden van leverancier 1, waarbij er een effect optreedt op de urenbesteding van leverancier 2. De opdrachtgever wordt daarvan dan de dupe.

Dramadriehoeken komen ook in andere situaties voor, niet alleen buiten maar ook binnen organisaties.

Leverancier en gebruikers

Er kan bijvoorbeeld een belangentegenstelling ontstaan tussen de klant/opdrachtgever en z’n eigen gebruikers. De rood gestippelde pijl duidt weer de relatie aan waar het mis gaat.,

Een voorbeeld: De klant besteedt een service uit op basis van kosten, en verklaart dat naar de gebruikers toe met de mededeling dat ze de dienstverlening nu ‘eindelijk’ eens goed gaan regelen.

De leverancier levert de service inderdaad tegen lagere kosten, om aan de overeenkomst te voldoen. Hij dient daarmee het belang van de klant, maar snijdt daarvoor wel in de overeengekomen functionaliteiten.

De gebruikers verliezen functionaliteiten waar ze nou juist belang bij hadden.

Functioneel beheer en IT-beheer

Belangentegenstellingen ontstaan ook tussen domeinen/taakgebieden binnen een organisatie. Een bekend voorbeeld uit de IT-wereld is de tegenstelling tussen functioneel beheer en IT-beheer.

Functioneel beheerders voelen zich vaak “onderdeel van de gebruikersorganisatie”, terwijl ze ook gewoon interne dienstverleners zijn, met een eigen bijdrage aan het facilitaire taakgebied ‘informatievoorziening’. Probeer hen daar echter maar eens op af te rekenen…

De IT-beheerders stellen zich veel meer op als dienstverleners, maar zijn veelal meer ‘op afstand’ gezet en deels geoutsourcet. Hoewel de functiescheiding die de grondslag voor dit onderscheid levert, op zich een waardevolle interventie is, levert de praktijk nogal eens problemen. Functioneel beheerders proberen zich regelmatig te bemoeien met de keuzes die binnen het domein IT-beheer vallen, en ze hebben nogal eens de neiging “om het zelf te doen”. Probeer maar eens alle functioneel beheerders de toegang tot de productieomgeving te ontzeggen… Omgekeerd, IT-beheerders die zélf de specificaties voor hun IT-voorzieningen opstellen veroorzaken vergelijkbare problemen.

Applicatiebeheer en systeembeheer

Hetzelfde geldt in de IT voor de dramadriehoek tussen applicatiebeheer en systeembeheer. Applicatiebeheer is gewoon een onderdeel van IT-beheer, net als de rest van het infrastructuurbeheer, maar mede door de opkomst van ASL en BiSL naast ITIL is toch vooral de tegenstelling tussen deze domeinen onderstreept.

Moderne technieken zoals agile en DevOps dragen weliswaar hier en daar bij aan een beter samenwerkingsverband, maar er is nog steeds sprake van een stevige kloof tussen deze domeinen.

Een oplossing o.b.v. universele bouwblokken: LEGO met USM

Dramadriehoeken zijn illustraties van eiland-denken. Elk van de betrokken partijen beschouwt de wereld vanuit een eigen belang en perspectief, en de aansturende partij is niet in staat de spelers voldoende bij elkaar te brengen.

De oplossing voor deze problematiek is te vinden bij de oorzaak: een combinatie van gebrekkige aansturing en geïsoleerde oplossingen. De USM-methode levert een eenvoudig leerbaar en effectief instrument om dit probleem aan te pakken. De opdrachtgever krijgt met de denk- en zienswijze van USM meer inzicht in, en grip op de dienstverlening, en kan de werkwijzen van de ‘spelers’ eenvoudig standaardiseren met de toepassing van USM.

Op die manier ontstaat het beeld van LEGO: een aantal bouwblokken om alle denkbare constructies op te zetten, maar wel op één gemeenschappelijke grondslag: de nokjes van het ene blokje passen altijd in de gaatjes van het andere blokje.

Dat LEGO-effect is mogelijk met de USM-servicemanagementarchitectuur: USM levert de bouwblokken voor het managementsysteem van elke serviceorganisatie. In de laatste figuur is dan ook – voor het maximale LEGO-effect – bij iedere ‘speler’ in het netwerk de USM-werkwijze als verbeterstrategie aangegeven.

Hoe meer spelers het spel met dezelfde spelregels spelen, hoe beter het resultaat van het spel.

Weg met CIO Office en PMO – leve het SMO…

Een Project Management Office (PMO) is een bekende organisatorische constructie voor het managen van projecten. De laatste jaren zijn echter ook Service Management Offices (SMO’s) in opkomst. Wat is het verschil? Wat is de overeenkomst? En kan de één wel naast de ander bestaan? En wat doet een CIO Office dan nog?

Het managen van dienstverlening vergt overzicht over die dienstverlening en toezicht op de manier waarop die diensten worden geleverd. Een Service Management Office (SMO) is een team dat zich met dat overzicht en toezicht bezig houdt en zorg draagt voor de optimale afstemming tussen de behoeften van de klant en de prestatie van de serviceorganisatie (‘business IT alignment’, BITA). Het SMO fungeert daarbij als een staf-orgaan of een Center of Excellence (zie de figuur boven deze blog).

Taken van een SMO

In het SMO staat governance centraal, maar het team houdt zich ook bezig met het managen van de dienstverlening. Een SMO kan een strategische focus hebben, maar ook de operationele contacten van bijvoorbeeld de Servicedesk omvatten. Het SMO treedt bij verregaande outsourcing op als regieorganisatie.

Het SMO brengt dus de verantwoordelijkheid voor de dienstverlening vanuit verschillende perspectieven en op verschillende niveaus bijeen. In die zin is het SMO de bindende factor voor het samenhangend managen van die dienstverlening, op strategisch, tactisch en operationeel niveau.

Daarmee is het SMO een kruispunt van governance en management.

Zo’n kruispunt bestaat al in de vorm van de hoogste in rang in de IT-serviceorganisatie: de IT-directeur of de CIO die in principe eindverantwoordelijk (accountable) is voor alle taken en prestaties van de serviceorganisatie. Met het SMO krijgt deze een apparaat ter beschikking dat handen en voeten geeft aan het besturen van de dienstverlening. Het SMO neemt daardoor een deel van die eindverantwoordelijkheid (accountability) over. Een RACI demonstreert dan in detail in hoeverre en waarvóór het SMO accountable is.

Ieder taakgebied in een organisatie kan een eigen SMO instellen. De combinatie van meerdere taakgebieden in één SMO is dan de volgende stap naar Enterprise Service Management.

De taken van het SMO omvatten daarmee potentieel een breed spectrum van activiteiten:

  • de servicemanagemenstrategie
  • de servicemanagementarchitectuur
  • het toezien op het opleiden van alle medewerkers t.a.v. hun kennis van de werkwijzen
  • het beheren van de functionaliteit van de workflowtool
  • het initiëren van verbeteringen in de dienstverlening en in het managementsysteem
  • tot aan een hele reeks meer operationele taken uit de koker van de servicemanager, de kwaliteitsmanager en de Servicedesk…

De mate waarin een SMO daadwerkelijk in ál deze taken voorziet varieert per organisatie. Een SMO kan dus ook best een beperkte taakstelling hebben, met slechts een deel van de opgesomde taken.

Voorbeeld. Het proces Contract Management (CTM) omvat het maken van de afspraken met klanten en toeleveranciers, en het onderhouden daarvan. Het belangrijkste profiel dat deze taken uitvoert is servicemanager. Dat profiel kan worden ‘opgedeeld’ in deelprofielen, die bijdragen aan de uitvoering van deze taken. Denk aan het profiel van inkoper. Een breed SMO omvat al deze profielen. In een wat smaller gedefinieerd SMO vallen de profielen van de inkopers onder een separaat team.

CIO Office

Een deel van de servicemanagementtaken is vaak al ondergebracht in een CIO Office, en dan vooral het strategische deel. Eén van de grootste problemen van deze CIO Offices is de afstand tot de werkvloer. Een CIO Office heeft nogal eens de neiging zich vooral met ‘belangrijke’ (strategische) zaken te bemoeien. Dat zijn dan vaak zaken die onder ‘programmamanagement’ of ‘portfoliomanagement’ vallen. Of nog fraaier: onder ‘de digitalisering van de business’ of een ander modeverschijnsel. Zo’n focus op het veranderen van de technologische voorzieningen gaat vaak ten koste van de kerntaak van de IT: het duurzaam ondersteunen van bedrijfstaken met behulp van een passende informatievoorziening.

Een organisatie die de taken van zo’n CIO Office onderbrengt in een SMO brengt daarmee de verbinding aan tussen de strategische en de tactisch/operationele taken van de dienstverlener. Het gevolg is dat die organisatie meer met beide voeten op de grond komt te staan, en daarmee beter aansluit bij de praktische behoeften van de business.

Bij zo’n combinatie hoort een waarschuwing: vanuit het oogpunt van functiescheiding is het van belang om bepaalde taken niet in één hand te leggen. Binnen een SMO moet worden gewaakt voor het vermengen van specificeren en realiseren (de essentie van functiescheiding). Die regel gold echter ook al voor alle andere situaties en organisatievormen, dus daarmee is er niets nieuws onder de zon.

Project Management Office (PMO)

Procesmatig werkende organisaties die een Project Management Office (PMO) hebben en een SMO willen inrichten, kunnen de taken van het PMO integreren in de nieuwe werkwijze en organisatiestructuur.

Projecten volgen immers processen (of liever gezegd workflows). Dat betekent dat het hanteren van een projectmatige werkwijze onderdeel is van de reguliere, procesmatige werkwijze. Projecten bestaan dus niet naast processen, maar zijn werkwijzen die het uitvoeren van activiteiten in processen mogelijk maken. Voor die situaties moet dan wel gelden dat de projectmatige uitvoering tot meerwaarde leidt, en tegelijkertijd geen afbreuk doet aan de afgesproken dienstverlening…

Voor het leeuwendeel van de activiteiten van een serviceorganisatie geldt dat ze niet projectmatig worden uitgevoerd.

Er is dus blijkbaar sprake van criteria, waarvoor geldt dat activiteiten die daaraan voldoen projectmatig worden uitgevoerd. Iedereen weet wel welke criteria dat zijn:

  • hoge kosten
  • veel complexiteit
  • er zijn veel organisatorische eenheden bij betrokken
  • etc.

Elke organisatie bepaalt voor zichzelf wáár ze de grens legt om te beslissen of een activiteit projectmatig wordt uitgevoerd. Projecten bestaan dus niet naast processen, maar zijn manieren om activiteiten in processen uit te voeren.

Alle projecten passen dus in het procesmatige besturingsmodel van de organisatie. Het SMO borgt dat de prestaties van de organisatie optimaal ten dienste staan van de afgesproken ondersteuning van de business. Projectmanagers maken dan deel uit van de bestaande teams. Een organisatie die veelvuldig gebruik maakt van projectmatige werkwijzen, kan dan eventueel de gekwalificeerde resources nog in één team in de lijnorganisaties onderbrengen.

De noodzaak van een PMO verdwijnt.

Een procesmatig werkende organisatie die een SMO inricht, heeft dus geen behoefte meer aan een PMO. Sterker nog: de focus op services reduceert het begrip project tot een nuttig instrument – om de dienstverlening mee te ondersteunen. Maar de klant en de dienstverlening staan dan wel centraal, en niet de verandering via projecten.

Deze aanpak is een standaard onderdeel van de methode USM – Universeel Service Management, die snel aan belangstelling wint en al onderdeel is van hbo- en mbo-opleidingen. Met die methode zijn nog veel meer van dit soort misverstanden op een eenvoudige en consistente manier te lossen. USM helpt procesmatig werkende organisaties aan gestandaardiseerde werkwijzen en een standaard servicemanagementsysteem.

Een uitgebreidere beschrijving van het inrichten van een SMO, met inbegrip van de traditionele PMO-functies, is onderdeel van de middelen die Stichting SURVUZ gratis aan USM-gebruikers beschikbaar stelt.

[aanvulling 2-9-2019: Ik kreeg zojuist een artikel onder ogen van een partij die het instellen van een BRMO – een Business Relationship Management Office – promoot, en daar een reeks prijzige trainingen voor aanbiedt. Het lijkt me logisch dat bovenstaande blog nog een kleine uitbreiding kan gebruiken…. En mochten er nog meer aanbieders van versplintering en complexiteit worden gevonden, dan zou ik zeggen: “gewoon toevoegen aan de strekking van de blog”]

Misverstanden rond de rol “Proceseigenaar”​

Op GEMMA online is een artikel te vinden over dit thema. Dat artikel vraagt om een reactie: het illustreert de veelvuldige misinterpretaties van begrippen zoals proceseigenaar, procesmanager en procescoördinator.

Het onderwerp van het genoemde artikel is proceseigenaarschap. De uitwerking daarvan demonstreert twee opvallende, gangbare invalshoeken:

  1. Het artikel gaat helemaal niet over processen maar over practices: de praktische handelingen die een gemeentelijke organisatie voor bepaalde doelen op een bepaalde manier uitvoert. De verantwoordelijkheid voor de aansturing van die activiteiten (in de vorm van een gemeentelijk ‘proces’) is onderwerp van de analyse.
  2. De aansturing van die handelingen valt volgens de auteur onder proces-eigenaarschap, terwijl het gaat over het aansturen van de uitvoering. De auteur heeft het dus in feite over procescoördinatie: de (procesmatige) aansturing van de uitvoering van de activiteiten die – in dit geval – in de practice beschreven zijn.

Het artikel demonstreert daarmee een gangbare misinterpretatie van het begrip proces in combinatie met het begrip management. De conflicten die de auteur in het artikel aan de orde stelt zijn de gangbare gevolgen daarvan: wie is nou de baas, de proceseigenaar of de lijnmanager? En is er wel verschil tussen die twee rollen? En wie escaleert er nou naar wie?

Spraakverwarring

De spraakverwarring over de gehanteerde begrippen is gelukkig eenvoudig te repareren als je een eenduidige definitie hanteert. Neem de volgende zaken maar eens in overweging:

  1. Eigenaarschap duidt eerder op accountability dan op responsibility. Eigenaarschap heeft dus niet per definitie iets te maken met de hiërarchische aansturing (het coördineren), ook al heet een (proces)eigenaar in de praktijk vaak wel (proces)manager. Je mág de verantwoordelijkheid voor eigenaarschap en coördinatie wel in één persoon combineren, maar het verdient de voorkeur (vanwege de voordelen van functiescheiding) om dat juist niet te doen.
  2. Coördinatie kan langs twee wegen plaatsvinden: langs de logica van de organisatorische hiërarchie of langs de logica van de samenhang van activiteiten (fundamentele processen, of daarvan afgeleide practices).

Een conflict in de zin van hiërarchische aansturing vindt altijd plaats tussen coördinatoren. En daar kun je onderscheid maken tussen teamcoördinatoren en procescoördinatoren. Die twee staan echter geheel los van de rol van proceseigenaar. Het is zelfs uiterst onverstandig om één van die rollen te combineren met de rol van proceseigenaar. De waan van de dag wint het dan namelijk altijd.

De meeste “procesmanagers” zijn vooral (en vaak alléén) managers van de uitvoering. Denk maar aan de gangbare “changemanager”, de “incidentmanager”, de “problemmanager”: zij coördineren de afhandeling van changes, incidenten, problems…

Wie is dan de baas?

De vraag wie ‘de baas’ is, is nu teruggebracht tot de vraag: welke coördinator heeft de meeste aansturende bevoegdheden over het werk van uitvoerders?

Elke organisatie kan daarin z’n eigen keus maken, afhankelijk van de mate waarin die organisatie met het begrip ‘proces’ om kan gaan. Veruit de meeste organisaties kunnen dat nog niet, en kiezen dus voor lijnmanagement bóven procescoördinatie.

En de proceseigenaar dan?

En als de procescoördinator en de teamcoördinator uitmaken wie de baas is, wat doet een proceseigenaar dan nog? Dat is eenvoudig: die rol zorgt voor de kwaliteit van het ‘proces’. Dat houdt concreet de volgende zaken in:

  • De proceseigenaar stimuleert de awareness in de organisatie t.a.v. de betekenis van het proces.
  • De proceseigenaar maakt afspraken met (coördinatoren van) uitvoerders over de te volgen werkwijzen.
  • De proceseigenaar ziet toe op het naleven van die afspraken.
  • De proceseigenaar rapporteert over de prestaties van het proces.
  • De proceseigenaar stelt verbetervoorstellen op en ziet toe op de uitvoering daarvan.
  • De proceseigenaar zorgt voor de ondersteuning van de medewerkers die het proces uitvoeren (tooling, opleiding, etc.).
  • De proceseigenaar legt verantwoording op stafniveau, over de bijdragen van het proces aan de prestaties van de organisatie.

Daar heeft zo’n proceseigenaar de handen wel vol aan. En als die functionaris dat gemakkelijk aan kan, dan is er vast nog wel een tweede proces dat ook nog ‘gemanaged’ moet worden… (en dan bedoel ik dus niet ‘gecoördineerd’).

Hiermee is een heel andere rol voor proceseigenaar gedefinieerd, dan de aansturende lijnmanagement-rol die in het genoemde artikel aan de orde kwam. Bovendien geeft deze definitie concrete inhoud aan de niet te onderschatten betekenis van proceseigenaarschap, terwijl meteen de voordelen van functiescheiding worden verzilverd.

Iedere organisatie moet dus kiezen

Een organisatie die procesmatig wil werken moet dus een paar dingen regelen:

  1. Stel voor ieder proces een proceseigenaar aan die zich niet bemoeit met de hiërarchische aansturing van de uitvoering, maar juist met de functionele ondersteuning van die uitvoering. Noem dat desgewenst een ‘faciliterende manager’ of een ‘procesmanager’, maar maak duidelijk dat die persoon alleen de specificatie van het proces managet en niet de uitvoering daarvan coördineert.
  2. Bepaal de machtsverhouding tussen de managers die de uitvoering van dat proces coördineren. Maak daarbij onderscheid tussen teamcoördinatoren en procescoördinatoren. Bepaal vervolgens wie van beide ‘de macht heeft’, oftewel: naar wie de operator moet luisteren als beide coördinatoren (‘managers’) het niet met elkaar eens zijn over de prioritering van werkzaamheden. Daarmee zijn meteen de escalatiepatronen bepaald.

Iedere organisatie die op de één of andere manier gebruik wil maken van de voordelen van procesmatig werken zal de keus over die machtsverhouding moeten maken. Er is daarbij sprake van een kantelpunt (zie figuur). Van oudsher beginnen organisaties ergens in het rechter segment, als een hiërarchische organisatie. Organisaties die de voordelen van procesmatig werken willen benutten schuiven stapje voor stapje op naar het linker segment.

Deze aanpak is een standaard onderdeel van de methode USM – Universeel Service Management, die snel aan belangstelling wint en al onderdeel is van moderne hbo- en mbo-opleidingen. Met die methode zijn nog veel meer van dit soort misverstanden op een eenvoudige en consistente manier te lossen. Had de auteur van het genoemde artikel de kans gehad om zich daar eerst in te verdiepen, dan had dat artikel er ongetwijfeld heel anders uitgezien. De auteur had zich dan niet hoeven te beperken tot het beschrijven van problemen, maar hij had een eenvoudige oplossing kunnen aanreiken…