Dit blogartikel is geschreven door gastauteur en USM-expert Jan van Bon.
IT’ers zijn in de regel zeer gestructureerd denkende wezens. Ze kunnen de mooiste strakke programma’s schrijven, netwerken en computers bouwen en projecten managen. Maar zodra het op organiseren aankomt is het net of ze een blinddoek voordoen en het gezonde verstand laten varen. Helemaal wanneer het begrip ‘proces’ in het geding is.
Ik geef een voorbeeld. We weten allemaal dat er verschil is tussen het managen van processen en het uitvoeren van processen. Dat heet in de wandelgangen ‘proces’ versus ‘lijn’. En we weten ook dat procesgerichte organisaties beter presteren dan hiërarchische organisaties: silo’s die hun werk over de schutting mieteren naar het volgende team zonder zicht te hebben op het eindresultaat voor de klant. Waarom maken we daar dan steeds zo’n zootje van?
Een procesmanager wordt geacht zich te concentreren op het maken en onderhouden van afspraken over de manier waarop we bepaalde zaken samen procesmatig afhandelen, over de grenzen van de betrokken teams heen. Hij zorgt er bijvoorbeeld voor dat die afspraken consistent zijn, dat ze zijn vastgelegd, dat iedereen ze kent, dat iedereen er bij kan als ze nodig zijn, dat we een tool hebben waarmee de procesgang wordt ondersteund, dat we ze met rapportages kunnen bijsturen enzovoort. Dat is dus iets wezenlijk anders dan het managen van de calls waarmee die procesgang wordt uitgevoerd. Dat vindt plaats in ‘de lijn’. De uitvoering van dat werk is dan het terrein van de lijnmanager.
Procesmanagement vs. lijnmanagement.
Als ik IT’ers echter vraag om een paar gangbare procesmanagers te noemen, dan is het eerste waar ze mee komen ‘de changemanager’. Vervolgens komt dan ook nog wel ‘de incidentmanager’, ‘de configuratiemanager’, en soms ook ’de servicelevelmanager’ of ‘de problem manager’. Als ik vervolgens vraag wat die changemanager zoal doet, dan komen als eerste de volgende taken in beeld:
- hij beslist of een change doorgaat of niet
- hij zit de CAB voor
- hij stuurt de afhandeling van changes bij
- er wordt naar hem geëscaleerd of hij escaleert zelf als een change niet goed gaat
En zijn dat dan procesmanagementtaken? Ik dacht het niet. Dat zijn lijnmanagementtaken. Taken waarin de calls zelf worden gemanaged. En wat hadden we ook al weer geleerd over procesmanagement? Juist… dat we de procesmanagement- en lijnmanagementtaken niet in één hand moeten leggen. Dan zetten we die manager in een onmogelijke spagaat. Dan wint de waan van de dag namelijk iedere keer.
Doen we dat met configuratiemanagement dan beter? Volgens mij niet: de ‘configuratiemanager’ houdt zich in de praktijk vooral bezig met de definitie van het CMDB-model, de registratie van CI’s, de kwaliteit van de CMDB-inhoud, en dat soort zaken. Procesmanagement? Niks daarvan. Pure lijntaken. En de ‘servicelevelmanager’, de ‘incidentmanager’, de ‘problem manager’? Hetzelfde beeld.
Wie zijn de procesmanagers in jouw organisatie?
Meer weten? Bekijk het webinar terug over Proces Managers, door Frank Eerland, consultant van Mproof