Iedereen de beste wensen voor 2009 en dat het maar een beheersbaar jaar mag worden. Mijn ervaring met het opzetten van beheer is dat er heel moeilijk kan worden gedaan over iets dat op het eerste gezicht een eenvoudige zaak lijkt: het inrichten van helpdeskprocessen. Waarom is dit zo moeilijk? De klant heeft een helpdesk met bepaalde processen. Indien een beheersgedeelte daarvan wordt uitbesteed moeten twee dingen duidelijk zijn: wat is de SLA en wie is er verantwoordelijk voor welke activiteiten in een proces. Als dat duidelijk is: opzetten en runnen. Doel: continuïteit voor eindgebruikers.
Ik vind dat je in dit geval het probleem moet neerleggen bij diegene die er verstand van heeft en beschikt over de juiste resources; dus mensen en middelen. Ervaring leert dat indien de communicatie tussen partijen goed verloopt, bijvoorbeeld met behulp van de middelen, en de correcte informatie wordt uitgewisseld tussen de juiste verantwoordelijken, dit een ontlasting en ontzorging oplevert voor de klant/eindgebruiker.
Gelukkig werkt het bij veel bedrijven ook zo (betrekkelijk eenvoudig). Regelmatig kom ik echter bij grote bedrijven die al veel hebben uitbesteed en/of taken over (te veel) verschillende afdelingen hebben verdeeld. Hierbij is de verantwoording van wie wat doet en hoe er wordt gecommuniceerd ‘killing' voor het uitvoeren van adequaat beheer.
Maar ja, die verantwoordelijkheden in een stap in een proces in een groter bedrijf met (te) veel verschillende partijen is de grootste uitdaging. Break/fix, supplies, MACD, escalaties, noem het proces maar op. Ieder helpdeskproces heeft verschillende afdelingen die erbij betrokken kunnen zijn. Iedereen wil zijn ‘levensvatbaarheid' aantonen en iedereen wil belangrijk zijn door zijn stempel op een proces drukken. Want o jee, als je eens een incident zonder ze oplost. Ze willen ook allemaal een incident oplossen en velen hebben een eigen systeem voor bijvoorbeeld registratie. Voor het gemak heeft het bedrijf ook nog andere stappen in het proces uitbesteed: ict, telefonie, postkamer, repro, de helpdesk. Ook met hun eigen registratiesystemen.
Dan komt er een niet standaard probleem en niemand is opeens meer verantwoordelijk (of belangrijk genoeg). Kosten gaan voor de baten (zeker bij derden). Iedereen is druk. En dan?Afschuiven! Maar wel registreren ten behoeve van de SLA.
Ik maak het mee dat processen, die zijn bedoeld om de eindgebruikers zo veel mogelijk te ontlasten en problemen op te lossen, vooraf stranden door discussies tussen partijen. Partij A voelt zich aangevallen door tussenkomst van een partij B, want hé, ze zijn belangrijk. Helaas zijn de eindgebruikers de dupe. Resultaat van alles: processen in kaart, maar met veel te veel tussenstappen en verantwoordelijkheden bij diverse partijen. En verwarring over de verantwoordelijkheid van de SLA. Bureaucratie.
Om voor de klant, de eindgebruikers, het beheer optimaal uit te voeren, moeten ze indien er iets plaatsvindt weten bij wie ze moeten zijn om het te melden. Na het melden hebben ze alleen nog baat bij een snelle afhandeling. Maar wie regelt het dat de processen en de bijbehorende SLA's tussen deze afdelingen, derde partijen en derde partijen onderling eenduidig worden afgestemd op de gebruiker? Welk registratiesysteem is leading?
Met een goede samenwerking en afspraken die vooraf zijn gemaakt (en vastgelegd) zijn veel ‘uitdagingen' snel op te lossen. Maar met zoveel partijen, waar ligt dan nog de eindverantwoording voor de SLA's?
Uitbesteden is prima. Communicatie is essentieel. Einddoel is een tevreden eindgebruiker. Dus spreek duidelijk vooraf af wie verantwoordelijk is en met welke SLA. Maak dus een afhankelijkheidstabel ten behoeve van de SLA's. Welke SLA is afhankelijk van welke partij(en) en wie is de eindverantwoordelijke? Laat iedereen deze goedkeuren en het schept al wat meer duidelijkheid. Maar wie regelt dat dan? Wie heeft dat mandaat? Wie is eindverantwoordelijke voor deze tabel?
Beste Martin,
Een sla komt te voet en gaat te paard! Ik zou nog (minimaal) twee dingen willen toevoegen aan de door jou genoemde SLA en duidelijkheid over wie waarvoor verantwoordelijk is. En dat is (1) het vertrouwen en de wederzijdse wil om een zakelijke relatie tot een succes te maken, en (2) het continu managen van de wederzijdse verwachtingen. Voor beide punten moet je soms juist een sla durven negeren / overstijgen.
Als een organisatie al moeite heeft met het inrichten van ?helpdeskprocessen?, hoe goed / snel zal die organisatie dan een SLA-afhankelijkheidstabel adopteren? Dit blijft een stuk papier, en papier is geduldig. Je blijft dan zitten met de ook door jou gestelde vraag, namelijk hoe je de regiefunctie van een organisatie inricht.
Het lijkt mij raadzaam voor een organisatie om te investeren in ?ABC? (Attitude, Behaviour, Culture). Als de houding en gedrag van mensen invulling geven aan samenwerking en het managen van verwachtingen kun je prima die tabel invullen maar dan heb je hem waarschijnlijk maar zelden nodig.
Je hebt het over het neerleggen van ?het probleem?. Maar wat is dan dat probleem? Ik kan me een heleboel verschillende problemen voorstellen, maar over welke (problemen) heb jij het? Er zijn genoeg organisaties die al hard moeten werken aan hun ?helpdeskprocessen? zonder dat er sprake is van uitbesteding. Het hebben van verschillende registratiesystemen is lastig en soms ongewenst (ze kunnen zorgen voor ontevredenheid en ongemak) maar het samenvoegen van die systemen zal op zichzelf nooit leiden tot een oplossing of (klant)tevredenheid.
Je opmerking over de gewenste betrokkenheid van ?iedere afdeling? vind ik suggestief. In veel organisaties waar ik binnenkom zijn de meeste teams druk genoeg met hun eigen workload. Ik zou wensen dat die teams juist eens wat vaker naar andere teams kijken en voor zichzelf een beeld vormen van wat er bij de buren speelt. Dat maakt het samen werken aan de dienstverlening voor de klant doorgaans een stuk gemakkelijker.
Met vriendelijke groet,
Michiel Croon
Getronics Consulting