Casus 1: Een gebruiker meldt "Ik ben mijn wachtwoord kwijt, kun je dat voor me resetten?"
Casus 2: Een gebruiker meldt: "Ik ben de sleutel van mijn locker kwijt, kun je me een nieuwe geven?"
Casus 3: Een gebruiker meldt: "Ik heb een foute invoer gedaan in applicatie X, en nu zijn mijn data beschadigd, kun je dat herstellen?"
Talloze in- en externe dienstverleners behandelen deze casussen als incidenten, als storingsmeldingen. Ze voeren de vereiste handelingen uit, registreren de vraag als een storing, en rapporteren daar netjes over in de servicerapportage.
Waarom is dit fout? De storing wordt toch hersteld?
De denkfout
Elk verzoek van een klant/gebruiker valt te herleiden tot een wens, een RFC, een incident of een service request (of het is communicatie binnen een eerder gedane melding). De aard van de vraag bepaalt die interacties, binnen de context van de afgesproken dienstverlening.
De veronderstelling om bovenstaande casussen af te handelen als incidenten berust op de perceptie:
- dat de klant recht heeft op ondersteuning
- dat er sprake is van een storing in het functioneren van de beschikbaar gestelde voorzieningen
- dat er dus sprake is van een tekortkoming in het handelen van de dienstverlener
- dat de dienstverlener de situatie dus dient te herstellen, en wel op eigen kosten
In alle drie de casussen zal punt 1 positief worden beantwoord, anders had de dienstverlener helemaal niet in actie moeten komen. In alle drie casussen faalt echter punt 2, en daarmee ook punt 3 en punt 4.
Er is immers geen sprake van dat de voorzieningen falen: integendeel, ze functioneren juist zoals afgesproken. De gebruiker kan niet in de beveiligde applicatie of in de afgesloten locker - en dat is precies de bedoeling. In casus 1 en casus 2 is in de serviceovereenkomst blijkbaar een afspraak gemaakt over beveiliging. Ongeoorloofde gebruikers mogen geen toegang krijgen tot beveiligde middelen (de applicatie, de locker). De voorziening functioneert dus juist goed en er kan daarom geen sprake zijn van een storing.
Beide casussen zijn dus voorbeelden van gebruikersfouten, net als casus 3.
De oplossing
In alle drie de casussen wil de gebruiker geholpen worden. Om er voor te zorgen dat dat gebeurt, zal daarvoor eerst het recht op ondersteuning moeten zijn geregeld. Dat gebeurt in de serviceovereenkomst, de SLA.
Zodra in de SLA wordt afgesproken dat een voorziening wordt beveiligd (casus 1 en 2), dienen klant en leverancier ook af te spreken wat er gebeurt als de gebruiker een fout maakt (de sleutel verliezen). De oplossing is eenvoudig: de leverancier dient te voorzien in extra handelingen (extra wachtwoord/sleutel leveren). De kosten voor die extra handelingen dienen dan in de SLA te worden vastgelegd. Logischerwijs zal de klant extra moeten betalen omdat de klant de extra handelingen veroorzaakt.
Voor alle andere gebruikersfouten geldt hetzelfde. Klant en leverancier dienen in de SLA af te spreken welke ondersteuning de leverancier levert als de klant een gebruikersfout maakt die tot extra inspanning leidt en hoe de extra kosten worden verrekend.
De praktijk laat zien dat talloze gebruikersfouten worden geregistreerd en afgehandeld als een incident. Die situaties doen afbreuk aan een correcte klant-leverancier relatie en leiden tot fouten in de prestatiebeoordeling van de leverancier en in de verrekeningen van de dienstverlening.
Wie de simpele logica van het USM-managementsysteem volgt, kan die situaties eenvoudig bespreken in de onderhandelingen over de dienstverlening, en vervolgens even eenvoudig en correct afhandelen.