Als training niet werkt! (2)

Zie alle posts uit deze serie.

Hoe je door NIET te trainen miljoenen kunt besparen.

Een internationaal opererend bedrijf had het computerserver- en workstation-installatiewerk bij de klanten uitbesteed aan OPQRS*. Al gauw bleek dat de installaties heel complex waren waardoor de OPQRS engineers gedurende het hele installatieprocess met de helpdesk aan de telefoon zaten om instructies en begeleiding te krijgen. OPQRS klaagde over de extra tijd die iedere installatie kostte, en dat de engineers niet de juiste training hadden gekregen. De helpdesk van het bedrijf klaagde over de lange tijd die de engineers aan de telefoon bezig waren om de installatie uit te voeren en dat de OPQRS engineers ook nog eens de meest gekwalificeerde helpdesk medewerkers nodig hadden. Het antwoord lag voor de hand:

Doe toch gewoon je werk! Die engineers moeten getraind worden!

Nu is er niets gemakkelijker dan de opdracht gewoon uit te voeren. Zo zit ik echter niet in elkaar. Ik weet dat als er en vraag naar training is, dit vaak een diepere oorzaak heeft. De vragen die bij mij in mijn achterhoofd spelen zijn:

• Wat doen die mensen nu en wat wordt er van ze verwacht?
  
• Waarom kunnen ze dat nu niet?
  
• Waarom denk je dat je dat met training kunt oplossen?
  
• Hoe kan het zijn dat iets blijkbaar zo onduidelijk is dat je dit moet aanvullen met training?

De analyse:

• De installatie procedure was gecompliceerd.
  
• De gegevens op de installatieopdracht waren onduidelijk en in een andere volgorde.
  
• De OPQRS engineers kwamen uit een grote pool en er moesten honderden engineers per jaar getraind worden.
  
• De kans dat een OPQRS engineer binnen een jaar nadat hij getraind was een opdracht zou krijgen was klein omdat de pool van engineers groot was.
  
• Als de OPQRS engineers getraind zouden worden zou het outsource contract duurder worden omdat de engineers een hoger opleidingsniveau hadden.
  
• Grof geschat zou 95% van de training nooit binnen een jaar toegepast worden.
  
• OPQRS engineers moesten van heel ver (soms wel 4000 km) weg komen om getraind te worden, tenzij we een oplossing gebruikten met remote access. Dit kon wel maar het stond wel ver af van de werkelijkheid.

Kon het dan anders?

Ja, eerst terug naar de tekentafel.

• Maak een eigen eenvoudig te begrijpen installatieprogramma/script dat bij iedere invoer controleert of de gegevens kloppen/werken, zodat fouten meteen gecorrigeerd worden en niet helemaal aan het einde.
  
• Door de servers in het warehouse al van de juiste (aangepaste) installatie software te voorzien (disk image). De engineers hoefden geen software meer mee te nemen.
  
• De engineer kon niet verder met de installatie als een test in het script faalde (b.v. ping eigen netwerkkaart, dan ping lokale router, dan ping datacenter).
  
• Als een test uit het installatiescript faalde kwamen er voorstellen op het scherm hoe je dit probleem kon oplossen. (controleer netwerkkaart, LED activiteit op netwerkkaart, netwerkkabel, DNS instelling, netwerkmasker, etc.).
  
• Door de gegevens op de installatieopdracht formulieren in de zelfde volgorde te plaatsen zoals nodig was voor het installatiescript kon het lijstje logisch afgewerkt worden. Wij hebben nog met de gedachte gespeeld om de configuratie gegevens via email als XML file op een USB stick te plaatsen, maar dat was echt nog een brug te ver.
  
• Op het moment dat de basis installatie klaar was en de server verbinding had met het datacenter kwam er een webpagina op met het (actuele) telefoon nummer van de helpdesk die de tweede fase van de serverconfiguratie zou overnemen. Ook dit had geautomatiseerd kunnen worden maar het is goed voor mensen om af en toe even met elkaar te spreken en te weten dat de ander inderdaad de zaak van je overneemt en bij wie je terrecht kunt als de eindconfiguratie niet op tijd klaar is.
  
• Terwijl de OPQRS engineer de workstation software installeerde bij de eindgebruikers, maakten de eigen, hooggekwalificeerde, engineers in het datacentrum de uiteindelijk configuratie van de server via de remote access verbinding af.
  

Voordelen van deze aanpak.

• Het outsource contract met OPQRS bleef op de oude prijs. Een nieuw contract met hoger gekwalificeerde engineers en een langere installatie tijd zou veel duurder geworden zijn.
  
• Het super eenvoudige installatie script samen met de handleiding op de installatieopdracht zorgden ervoor dat iedere OPQRS engineer deze installatie zonder training kon uitvoeren.
  
• De OPQRS engineers hoefden de helpdesk bijna niet meer te bellen.
  
• Er was geen training nodig! Dit alleen al zou meer dan een half miljoen per jaar zou hebben gekost (Training, Faciliteiten, Reizen en overnachten, Niet gewerkte dagen) .
  
• De specialistien die de eindconfiguratie vanuit het datacentrum deden werden alleen dan ingezet als de server klaar stond en niet eerder.
  
• De OPQRS engineer kon al met de software voor de eindgebruikers beginnen terwijl de server nog op afstand geconfigureerd werd, hierdoor werd de installatietijd zelfs korter.
  
• Dit zou nooit hebben kunnen gebeuren als de technische dienst niet geoutsourced was. De moed ontbrak om dit gezamelijk (technische dienst, development, administratie en datacentrum) aan te pakken.

De nadelen van deze aanpak.

• Alle betrokken afdelingen (silo's) moeten het belang inzien en willen meewerken (technische dienst, development, administratie en datacentrum). Als dit niet gedragen en ondersteund wordt door de CEO zal de verandering beperkt blijven tot een of twee afdelingen. Dit zal niet helpen en in dat geval kun je misschien beter het geld uitgeven en de engineers trainen.
  
• Veranderingen kunnen ertoe leiden dat er op sommige plaatsen teveel medewerkers zijn. Veel weerstand tegen verandering komt voort uit de angst dat men op straat komt te staan nadat men eerst een opvolger uit China of Polen heet ingewerkt. Door regelmatig onderhoud te plegen is de kans klein dat grote groepen medewerkers tegelijkertijd overbodig worden. Dit moet door het management duidelijk aangekaart worden. Een bedrijf als Toyota heeft al jaren als slogan:
  
  
• "Respect voor mensen"
  "Respect for people"
  
  
• "Productiviteits verbeteringen zullen niet tot ontslagen leiden"
  "lean initiatives will not result in laying off people."
  
  Hierdoor ontstaat de sfeer en het vertrouwen dat iedereen er beter van wordt en niet alleen de CEO en de aandeelhouders.
  
  
• Sommige afdelingen kunnen door deze actie kleiner worden, denk aan de helpdesk, dit vereist een management team dat het succes van het bedrijf boven haar eigen belang stelt. De CEO moet zelf duidelijk en congruent zijn als het om het vieren van sucessen gaat. Zolang het streven naar macht en invloed boven het streven naar langdurig verantwoord succes van de onderneming gaat zal dit niet werken.

Bedrijfsnamen zijn bewust aangepast* of weggelaten.