Over advocaten, automonteurs en systeembeheerders

Afgelopen week gaf mijn auto tijdens het rijden op de snelweg een alarmerende melding: de motor liep warm en of ik z.s.m. de auto wilde stoppen. Bij zo’n melding begrijp je dat er wat aan de hand is, daar valt niet omheen te werken, dus stop je de auto en laat je gelaten over je heen komen wat volgt. Wat volgt is het eerste advies van de monteur van de pechhulpdienst: sorry mevrouw, ik weet niet waar het aan ligt, dus voor de zekerheid nemen we hem mee.

Maar: wat meld je dan?

Een uitgebreide terugkoppeling naar de garage en uren onderzoek van hun kant volgde. Die onderzoekskosten lopen hoger op naarmate de informatie die je de garage verstrekt vager zijn. En dat is lastig want qua autotechniek ben ik een leek dus kan ik dan wel de juiste informatie geven?
Natuurlijk wel! Ik was er toch bij?!
Door goed na te denken over (1) wat er nou precies gebeurde, (2) welke melding ik toen kreeg en (3) wat mij verder nog opviel, had de garage toch al snel een denkrichting te pakken.

In de praktijk zie je de meest abstracte meldingen voorbij komen als helpdeskmedewerker van een advocatenkantoor. ‘Mijn computer doet het niet’ terwijl alleen Outlook niet opstart is daar een flauw voorbeeld van, maar dit soort dingen gebeuren in de praktijk. Gebruikers kunnen lang niet altijd goed uitleggen wat er nou precies niet werkt. En dat is met applicaties die allemaal met elkaar samenwerken ook lang niet altijd eenvoudig te achterhalen (als een document niet opgeslagen wordt, ligt dat dan aan het DMS of aan de Office applicatie?).

• Wat wel iedereen zou moeten kunnen doen is de volgende stappen onthouden en doorgeven aan de helpdeskmedewerker:
  Ik wilde dit gaan doen (openen document, opslaan bijlage, etc.)
• Wat ik wilde gebeurde niet en in plaats daarvan gebeurde er het volgende….(de boel liep vast, er gebeurde niets, ik kreeg een foutmelding, etc.) 
• Ik kreeg de volgende melding of dit beeld te zien (en aarzel vooral niet om daar print screen voor in te zetten) 
• En dat is nog nooit eerder gebeurd (of: en dat is de laatste tijd wel vaker gebeurd toen ik dit of dat deed) 

Met zo’n verhaal stuur je een helpdeskmedewerker meteen het goede pad op en hoef je je ook niet meer door alle standaardvragen uit het helpdeskscript te worstelen (‘heeft u de computer al eens opnieuw opgestart’)?

Wil je weten wat een enorme ‘time saver’ is? Wat je maar 3 minuten werk kost en je zeker 10 minuten nutteloze conversatie scheelt met de helpdesk en een heleboel ergernis aan beide kanten van de telefoonlijn 😉: Probeer de foutmelding te reproduceren door de handelingen te herhalen en dan overal print screens van te maken. Daarmee help je degene die jou wil helpen enorm.

Vervangend vervoer?

Al die tijd dat de garagehouder bezig is met je auto kan je niet rijden. Dat is evident. Tenzij je een regeling hebt voor vervangend vervoer, een reserve-auto hebt staan of transport anderszins tot de mogelijkheden behoort.

Ook dit wordt in de praktijk vaak vergeten. Het feit dat ‘we in de cloud zitten’ betekent niet dat een systeembeheerder zonder jouw pc over te nemen het probleem kan oplossen. Het probleem zit namelijk niet per definitie in ‘de cloud’ of op de server. Het kan ook iets zijn in jouw pc. Bovendien helpt het overnemen van de pc je in de communicatie: ‘laat eens zien wat je deed’, ‘wat gebeurde er toen precies’ etc. Dat kost tijd. En daarbij heeft een systeembeheerder jou als gebruiker wel nodig. Hoe beter hij vooraf geïnformeerd is (door een gedocumenteerde klacht) hoe sneller hij tot de kern kan komen, maar hij zal altijd naar je pc/laptop moeten kijken. En dus kan je dan even niet op je pc werken. Bij een auto vinden we dat evident, bij een pc niet altijd. Sterker nog, het is voor veel advocaten reden om dan maar niet te bellen en om het probleem heen te werken als dat mogelijk is. In de hoop dat het probleem zich dan vanzelf oplost… (of dat een ander hetzelfde probleem heeft en wel het geduld heeft dat te melden bij de helpsdesk).

Met je garage maak je een afspraak over wanneer hij je auto repareert en weet je wanneer je hem waarschijnlijk weer op kan halen. Daar hou je rekening mee in je planning. Probeer dat met computerproblemen ook te doen. Meldt het probleem aan de helpdesk en maak een afspraak over wanneer ze je pc over kunnen nemen. Ga dan zelf tijdelijk wat anders doen maar zorg wel dat je bereikbaar bent voor overleg. Op die manier kan de helpdeskmedewerker het probleem proberen te fixen zonder een ongeduldige gebruiker die in zijn nek zit te hijgen en krijg jij ook je werk gedaan. Andersom zou een servicedeskmedewerker die in de advocatuur werkt zich ook moeten realiseren dat tijd nou eenmaal geld is bij advocaten. Wellicht dat hij zich dan eerst een beetje inleest in de materie (alleen mogelijk als hij een goed gedocumenteerde hulpvraag heeft gekregen) en misschien zelf al de suggestie van de hand doet om een afspraak te maken om het probleem uit te zoeken.

Techneuten en leken…spreken ze dezelfde taal?

Ik behoor tot de categorie mensen die na een reparatie de auto komt ophalen en de neiging heeft genoegen te nemen met de mededeling ‘hij rijdt weer als een zonnetje’. Ik moet mezelf dwingen om nog wat semi-geïnteresseerde vragen te stellen over het hoe en waarom. Daarnaast heb je mensen – zoals mijn vriend – die precies willen weten wat het probleem veroorzaakt heeft en of de kans bestaat dat het nog eens gaat gebeuren. Dan wordt het uitdagend voor een monteur want dan moet hij uit gaan leggen aan een leek wat hij gedaan heeft.
Nou liggen autotechniek en de advocatuur ver genoeg uit elkaar om snel te ontdekken dat je elkaar niet begrijpt, maar bij ICT is dat anders. Want iedereen heeft thuis een computer met Word erop en gebruikt een smartphone waar hij zijn mail op leest, waardoor de indruk kan ontstaan dat je elkaar wel begrijpt. Terwijl dat lang niet altijd het geval is.

Waar komt dat dan door, is de vraag. Zijn de verwachtingen over en weer niet goed of spreken IT’ers en advocaten een andere taal? Met name dat laatste, is mijn ervaring. Waardoor het eerste – een mismatch aan verwachtingen – het resultaat is. 

Een voorbeeld: voor een systeembeheerder is een Prio 1 melding, een melding waarbij het complete kantoor plat ligt. Voor een advocaat is een niet goed werkende e-mailapplicatie een prio1 melding want hij kan niet werken. En voor een notaris een niet functionerende printer een prio 1 melding want hij kan zo geen aktes laten passeren. Als je dat niet uitspreekt als gebruiker en daarover geen (goede) afspraken maakt in de Service Level Agreement met je beheerpartij, dan ontstaan er geheid problemen. Want dan handelt de servicedeskmedewerker een dergelijke melding af volgens de interne normen (binnen 12 uur wordt de call opgepakt bijvoorbeeld) en begrijpt hij oprecht niet waarom de klant toch niet tevreden is over zijn dienstverlening.

Vooraf goede afspraken maken over prioritering en weging van meldingen is daarom van groot belang. Ook moet je als kantoor nadenken over de vraag of je een contract wil voor alle vragen (een retainer) of dat er betaald wordt voor sec de bestede tijd door de servicedeskmedewerkers? Moet een systeembeheerder daarbij alle vragen afvangen of moeten de gebruikers telkens zelf de afweging maken of iets op de weg van systeembeheer ligt of neergelegd moet worden bij een van de applicatieleveranciers? En hoe om te gaan met meldingen in de avonduren en weekenden? Niet zelden hoor ik advocaten klagen over de slechte bereikbaarheid van de servicedesk terwijl het kantoor een heel helder contract heeft afgesloten voor ondersteuning tijdens kantooruren (en de kantooruren van een advocaat zijn anders dan die van een servicedesk). Denk daar dus vooraf over na en communiceer binnen je organisatie wat die gemaakte afspraken zijn met betrekking tot bereikbaarheid, type vragen, etc. Dan weet iedereen wat hij kan verwachten en zal het aantal communicatiestoringen afnemen.

Wat komt er op de factuur? 

Met mijn garage heb ik de afspraak dat als een reparatie boven een bepaald bedrag uit dreigt te komen, dat hij me dan even belt. Dan ben ik voorbereid en kan ik daar eventueel nog invloed op uitoefenen.

Met een servicecontract met je dienstverlener is dat vaak getackeld in een retainer. Daarbij moet dan wel helder zijn wat er onder die retainer valt. Wat gebeurt er met vragen over een bepaalde applicatie, bijvoorbeeld het documentmanagementsysteem? Lopen die ook via de helpdesk van systeembeheer of moet daarvoor naar de helpdesk van de desbetreffende leverancier gebeld worden? Het eerste is vanuit gebruikersperspectief het prettigste (vaak weet iemand ook niet of het niet kunnen opslaan van een document aan het DMS ligt of aan de Office-applicatie) maar als systeembeheerder ben je dan wel vaak de gebeten hond, ook als het niet aan jouw werk ligt. En in zekere zin betaal je als kantoor dubbel, tenzij je korting kan krijgen bij de leverancier van het DMS voor het niet gebruiken van hun helpdesk.

Niet zelden wordt een systeembeheerder ook om inhoudelijk advies gevraagd. Bijvoorbeeld over de aanschaf van nieuwe apparatuur of een nieuwe applicatie. Vanuit het kantoor is de gedachte ‘jullie weten wat hier draait en of die nieuwe apparaten of applicaties ingebed kunnen worden in wat er nu ligt’. Een logische gedachte en een mooie rol voor een systeembeheerder. Waaruit ook veel vertrouwen spreekt. Maar ook dan is het wel zaak om een aantal zaken helder te hebben, zowel functioneel als financieel. Functioneel zal een beheerder kijken naar een zo soepel mogelijke inbedding van de applicatie, stabiliteit is essentieel vanuit zijn oogpunt. Welk product functioneel het beste aansluit is niet aan hem. Maar ook qua financiën is het belangrijk om bij zo’n adviesopdracht afspraken te maken: valt dit onder de servicedesk-retainer (lijkt mij niet), is het een extra service (en zo ja, hoever ga je dan als dienstverlener?) of worden die uren gewoon apart doorbelast? En tegen welk tarief dan? Communiceer hier helder over, dat voorkomt verrassingen!

Tot slot

Ik had vroeger van die vriendinnenclubjes om me heen waar ik soms een beetje jaloers op was. Van die meiden die alles met elkaar deelden maar ook drie minuten later ineens ruzie hadden. Daarvan zeiden mijn ouders dan ‘ze kunnen niet met, maar ook niet zonder elkaar’. Soms heb je het gevoel dat het met systeembeheerders en advocatenkantoren ook zo is. Ze hebben elkaar nodig, willen ook graag met elkaar samenwerken want een goede systeembeheerder waar je op kan bouwen is goud waard en een advocatenkantoor is vaak een loyale klant. Maar een systeembeheerder is ook snel de pispaal als ‘de IT het niet doet’ en niks is makkelijker dan katten op ‘die advocaten die er toch niks van begrijpen’. Maar ze zullen het met elkaar moeten zien te rooien en dat kan ook. Als systeembeheerders zich verdiepen in de praktijk van de advocaat en de advocaat probeert wat meer vanuit de techniek te denken. Dan moeten ze elkaar kunnen begrijpen en tot een vruchtbare samenwerking kunnen komen.

En hoe het met mijn auto is? Die rijdt weer als een zonnetje 😉