Bruggen slaan – waar nog meer?

In een Service Support landschap: Het gat tussen techniek en mens

De slagzin van het nieuwe kabinet is “bruggen slaan”. De brug die als beeldmerk wordt genomen is de Uyllanderbrug in Amsterdam. Het is een brug in aanbouw en moet in 2014 klaar zijn. Zou dit symbolisch zijn voor het nieuwe kabinet: het is in aanbouw en pas in 2014 zullen we de gevolgen merken van de bedachte beleidsmaatregelen?

Bruggen bouwen tussen techniek en de mens
Regeren is vooruitzien. Zo ook voor de diverse service support organisaties. Hoe zorgen we ervoor dat we op de toekomst voorbereidt blijven? De grootste zorg lijkt op dit moment het op peil houden van het kennisniveau van de service support engineers. Hoe blijf je de brug slaan tussen de toenemende product complexiteit en de technische kennis van de service engineer?

 Met technische training alleen bereik je de overkant niet
Veel engineers roepen nog steeds dat technische kennis de cruciale factor is bij het oplossen van problemen. Organisaties reageren daarop door het opzetten van een  Service Support trainingsafdeling. Het is een aparte tak van sport: trainingstrajecten worden ontwikkeld en eigen training ontwikkelaars worden aangenomen. Het doel is om de engineers stap voor stap inhoudelijk meer te weten laten komen van het systeem dat zij moeten ondersteunen. Hiermee denken ze het gat te kunnen dichten tussen de techniek en de mens. Helaas blijkt in de praktijk dat dit gat niet overbrugd kan worden door producttraining alleen. Hiervoor gaat de snelheid van technische innovatie te snel.

Zelfs Cisco, bekend om zijn aanbod aan technisch inhoudelijke trainingen en certificering, erkende vorig jaar op de Technology Services World conferentie dat technische training niet werkt.

Experts kunnen die brug toch wel slaan?
Het “ik heb niet genoeg technische kennis” denken, is niet op te lossen door de experts dan maar te blijven raadplegen. Dit brengt nog een ander nadeel met zich mee, namelijk de organisatie wordt te afhankelijk van de ervaren engineers. Maar het is toch super efficiënt: Je stopt er een vraag in deze wandelende database en er komt nog een goed antwoord uit ook. Helaas zijn het ook deze ervaren mensen die hun koffer kunnen pakken en met het vliegticket in de hand als een soort superman worden opgestuurd. Met je 20 jaar ervaring heb je het toch zo opgelost?! Jammer, er ontstaat nu echt een gapend gat: de wandelende database is even niet aanspreekbaar voor een week of twee met als gevolg dat de incidenten blijven langer openstaan. De junior engineers zitten met hun handen in het haar, niet in staat zelf kritische vragen te stellen en zo dus voortgang te maken.

En die arme man met het vliegticket op zak. Wat als deze ervaren persoon tegen zijn eigen grenzen van kennis en ervaring aanbotst. Wat als zijn intuïtie hem in de steek laat en de zaken toch net iets complexer zijn? Waar valt hij op terug? Resultaten uit het verleden bieden geen garantie voor de toekomst.

Een gestructureerde aanpak met een gemeenschappelijke taal als schakel
Wouter Bos introduceerde naar nu blijkt ideeën uit de consultancy om de twee zeer verschillende partijen met elkaar te laten samenwerken. Een van de opdrachten die vaak naar voren kwam was “het in de PvdA of VVD taal verwoorden van een beleidspunt”. Ook maakte hij gemaakte afspraken direct zichtbaar door het te projecteren op de muur. Zelfs een whiteboard deed zijn intrede.

Denken zichtbaar maken
Dat een senior engineer een wandelende database is, is handig te weten, maar niet werkbaar indien hij er niet is. Zijn denken zichtbaar maken in een goede knowledgebase zou een hoop ellende kunnen voorkomen. De kunst is om in de juiste taal (voor iedereen herkenbaar en terugvindbaar) de juiste informatie in het systeem op te slaan. Een set van regels en afspraken aan welke kwaliteit de informatie moet voldoen, is een goede stap in de richting. Ik heb gezien dat de engineer de oorzaak als titel meegaf, terwijl je als zoekende engineer die juist niet weet.
Hier een aantal praktische tips:
–       Schrijf in duidelijke bewoordingen. Bedenk of het verkeerd geïnterpreteerd kan worden, zo ja herformuleer totdat het duidelijk is. Hou je bij de geobserveerde feiten en trek niet (verkeerde voorbarige) conclusies “het is een netwerk issue” is heel wat anders dan “systeem is traag met het versturen van jpeg bestanden”. Onacceptabele woorden zijn “doet het niet”, “faulty”, “issue”.
–       Splits problemen: probeer niet twee problemen met elkaar te vermengen. “Mijn auto mist een ruitenwisser en bovendien heeft hij problemen met starten”. Verschillende problemen hebben verschillende acties nodig.
–       Schrijf op wat je gehoord hebt en bevestig: hoe weten we of een  vraag gesteld is als de antwoorden niet gedocumenteerd worden? Neem de tijd om het op te schrijven en verifieer bij de indiener of je het juist begrepen hebt. Het resultaat is een helder geschetst beeld van het probleem. Het voorkomt dat collega´s werk opnieuw gaan doen en, belangrijker nog, het voorkomt het opnieuw vragen naar de bekende weg (wat vaak tot irritatie bij de klant leidt).
–       Omschrijf problemen in een “object+afwijking” format. Het zoeken in het titel- veld wordt hiermee stukken krachtiger. Onderzoek bij Kepner-Tregoe wees uit dat 37% van de oplostijd gewonnen kan worden door een goede probleemomschrijving.
–       Documenteer de oorzaak. Klinkt logisch, maar ik kom veel cases tegen waarbij de case gesloten is met alleen een opmerking “printkaart issue”. Mocht het probleem nog een keer voordien, dan die opmerking je niet verder helpen. Omschrijf de oorzaak dan ook in een “object+afwijking/uitleg” format. Wat was nou uiteindelijk het foute werkingsmechanisme dat tot deze oorzaak heeft geleid?

Het lijkt allemaal niet wereld schokkend. “Zo doen we het toch al”. Ja, dat dachten de VVD en PvdA ook: wij weten toch wel hoe we zaken moeten formuleren en opschrijven. Toch is het van belang, wil je het beste uit de engineers halen, het op een gezamenlijke manier te doen. Dat dit niet over één nacht ijs gaat moge duidelijk zijn. Gerichte coaching en feedback (net als Bos?) dient ingeregeld te zijn voor het beste resultaat.

En die technische complexiteit dan?
De gemeenschappelijke taal en gestructureerde aanpak zorgen er ook voor dat de senior een pas op de plaats maakt en zijn denken kan ordenen met behulp van een set kritische vragen. De junior krijgt houvast door het setje kritische vragen en kan zo toch een probleem aanpakken wat voor hem op een nieuw en onbekend terrein ligt. Bovendien helpt de gemeenschappelijke aanpak ook in het mentoren van juniors door seniors. Het pad dat bewandeld moet worden is duidelijk, en brengt de “magie van de senior” helder in kaart. Het geeft beide partijen richting en versterkt tegelijk het onderlinge vertrouwen.

Nu maar hopen dat het met het regeerakkoord ook zo gaat.

Share

2 thoughts on “Bruggen slaan – waar nog meer?

  1. Mooie Blog Martine! Geweldig hoe je de politieke actualiteit verbindt met het dagelijks leven in organisaties. Gelukkig is de brug van jouw benadering al lang kant en klaar en heeft deze al vele jaren de test doorstaan, kortom: een dankbare brug. Ik hoop dat je er nog veel mensen overheen kunt loodsen.

Leave a Reply