U bent hier

Door Koen D. op 05-09-2017 08:02

ICT communicatie - Een praktijkgeval

Een bedrijfsproces loopt vast

...en ook de communicatie lijkt geblokkeerd. Thuisverpleegkundige E. gebruikt een applicatie van firma C. om prestaties te registreren en maandelijks de facturatie te doen. Facturatie houdt in dat alle gegevens i.v.m. prestaties via MyCareNet worden verzonden naar de mutualiteiten, die vervolgens zorgen voor de uitbetalingen. Voor elke nieuwe maand heb je 10 dagen de tijd voor de facturatie; wacht je te lang, dan moet je meteen wachten tot de volgende maand.

E. heeft een probleem: de facturatie werkt niet. Er komt onmiddellijk een foutbericht: "Foutieve serialisatie". Een gelijkaardig bericht verschijnt ook telkens bij het opstarten van de applicatie: "Foutieve serialisatie. Wenst u via internet na te gaan of er een nieuwe serialisatie beschikbaar is?". Daarop kan je "Ja" of "Nee" klikken, maar dat lijkt nooit een verschil te maken. De applicatie blijft bruikbaar. Alleen, de facturatie werkt niet...
Ik kijk in detail na wat "Ja" oplevert.
- Eerst komt een kader, met in de titelbalk " Serial Connect", onderaan de knoppen "OK" en "Annuleren", maar verder geen informatie. Dan maar "OK" klikken zeker?
>> Je moet als gebruiker iets doen, maar je hebt geen idee waarom of wat. Je gokt dan maar. Dat schaadt onmiddellijk het vertrouwen in de applicatie. Ergernis.
- Dan volgt dit: "Calling SerialConnect.dll", "SerialConnect (c) C. V2.05", "IGL Serial Connect Service Ready", "Close Connect", "Verifying Serial", "ERROR: Serial update failed. Call C.".
>> Een hoop berichten, (1) in het Engels (dat je nochtans niet moet kennen om de applicatie te mogen betalen), (2) met termen die blijkbaar bedoeld zijn voor technische specialisten, waar een gebruiker niets aan heeft, (3) met als enige concrete aanwijzing dat je naar firma C. kan bellen, waar je vervolgens in het telefonische afweersysteem terechtkomt. Ergernis.

Als het maar een naam heeft

Wat "serialisatie" precies betekent, daar heb je trouwens het raden naar. Ik vind op internet twee betekenissen: (1) het zodanig omzetten van een object dat dit geschikt wordt voor verzending of opslag op een sequentieel medium, en (2) het toekennen van een uniek serienummer per uitgifte-eenheid (in de farmacie). Als gebruiker moet je blijkbaar aannemen dat je die "serialisatie" nodig hebt, en je je bijgevolg niet hoeft af te vragen wat dat inhoudt. Je krijgt iets onbekend opgedrongen, en dat is nooit aangenaam. Weer ergernis dus. Vermoedelijk gaat het om een sleutel, een bestand met een toegangscode dat op je PC moet aanwezig zijn om met de applicatie te kunnen werken, waarmee de leverancier de toegang tot de applicatie kan vrijgeven of blokkeren, voor een specifieke periode, afhankelijk van je contract. De "serialisatie" is waarschijnlijk een technisch detail in het versturen van die sleutel; het gebruik van de term "serialisatie" in de foutberichten is dan zonder meer misleidend. "Sleutel" of "sleutelbestand" of "licentie" is ook nog technisch, maar zou al iets duidelijker zijn.
>> Er worden onduidelijke termen gebruikt in de communicatie met de gebruiker. Dat schaadt het vertrouwen in de applicatie. Ergernis.
>> In veel softwarebedrijven wordt deze "serialisatie" een "licentie" genoemd. Het gaat doorgaans om een code die een aantal parameters voor de applicatie bevat (bv. licentietermijn, aantal gebruikers, opties qua functionaliteit), zodanig geserialiseerd (!) tot een lang getal dat de parameters niet kunnen gelezen worden; dit uiteraard om namaak van de licentie te beletten.

Updates, serialisaties en andere speelballen

In elk geval, het bijwerken van de sleutel schijnt niet in orde te komen, gezien de ERROR in het foutbericht. Intussen werkt ook de synchronisatie met de smartphone niet meer. En er is een "update" beschikbaar, maar de installatie lukt niet, alweer omwille van een "foutieve serialisatie". Update, serialisatie, ...kan je nog volgen? Door de term "serialisatie" te gebruiken wordt onduidelijkheid gecreëerd; wat is nu precies een update en wat is een serialisatie?
>> Als gebruiker zonder technische achtergrond voel je je de speelbal van techneuten. Dat is niet aangenaam, en dat kan anders. Met wat fatsoenlijke uitleg begrijpt elke gebruiker dat (1) de applicatie af en toe moet bijgewerkt worden, en dat (2) de toegang tot de applicatie (of een deel daarvan, bv. de facturatie) kan geregeld worden met een sleutelbestand. Zowel de applicatie als het sleutelbestand krijgen dus af en toe een bijwerking of update. Het ene een update noemen en het andere een serialisatie is vragen om verwarring. Dit is zonder meer een meervoudig vlag- en ladingprobleem.

Oei, een helpdesk...

De eerste van de maand is een vrijdag; we proberen het probleem dadelijk op te lossen, anders moeten we wachten tot na het weekend. Firma C. heeft een helpdesk, maar die is telefonisch meestal zeer moeilijk te bereiken. Je kan gerust een half uur wachten, maar er wordt niet opgenomen. Je kan wel een bericht achterlaten per telefoon, en/of een mail sturen. Noch het bericht per telefoon, noch mails, naar het algemeen adres en naar enkele specifieke adressen van mensen van de helpdesk, schijnen iets op te leveren. Firma C. laat niets van zich horen. De consultant die je toevallig per Messenger kan contacteren meldt dat hij op vakantie is, en vraagt om via de helpdesk te gaan. Maandag opnieuw verwoede pogingen om de helpdesk te contacteren, zonder resultaat. Je zoekt op de duur naar andere telefoonnummers van dezelfde firma, maar wat je ook probeert, je loopt telkens vast op dezelfde telefooncentrale, met dezelfde stem die zegt dat alle medewerkers in gesprek zijn en dat je een bericht kan achterlaten, en met hetzelfde melodietje dat terugkomt in je nachtmerries. Je wordt er hoorndul van. Het lijkt wel of je met opzet geblokkeerd wordt door fima C. en je begint je af te vragen of je iemand voor het hoofd gestoten hebt... Een firma die zijn gebruikers respecteert laat dit niet gebeuren. Maar je kan er niet zomaar weg, je hebt een aanzienlijk bedrag betaald voor de jaarlijkse licentie, bij een andere firma raak je niet op zo'n korte termijn terecht, en het zal wel overal iets zijn zeker...?
>> Een helpdesk die niet bereikbaar is, creëert veel stress bij gebruikers.
>> Een telefooncentrale die meer lijkt op een afweersysteem komt behoorlijk arrogant over.
>> Beseffen dat je niet zomaar weg kunt betekent weer extra stress. Klantenbinding heb je in verschillende soorten; sommigen gebruiken kettingen.

Als het probleem deze week niet opgelost raakt, kan verpleegkundige E. deze maand niet betaald worden. Ook al is dat geen ramp, het is een ongewenste en vermijdbare verstoring in de keten van processen, met vooral veel ergernis tot gevolg, bij diverse partijen. Dus we blijven proberen. Morgen dinsdag nieuwe poging.
>> Je hebt als gebruiker geen verhaal tegen nalatigheden van een softwareleverancier die je geld kosten.

Dit hadden we niet zien aankomen

Dinsdagmorgen blijkt er een mail te zijn toegekomen, van één van de helpdeskmedewerkers, verstuurd op maandag om 22:55 (!), met de vraag of we misschien een persoon hebben toegevoegd in de applicatie.
- Het feit dat iemand zich op zo'n ontieglijk uur nog verantwoordelijk voelt om werk te verzetten, zou er kunnen op wijzen dat de helpdesk wel heel erg overbelast is.
- Er was inderdaad een persoon toegevoegd, niet als gebruiker, maar als derde.
- Na het desactiveren van die persoon kwam alles in orde, de serialisatie, de update, en de synchronisatie.
- Er is op geen enkel ogenblik enige verwijzing geweest naar een toegevoegde persoon als mogelijke oorzaak van de blokkering van serialisatie, update en synchronisatie. Het is ook niet duidelijk waarom een persoon niet zou mogen toegevoegd worden als daarvoor niet gefactureerd wordt.
- Blijkbaar is de sleutel slechts voorzien voor twee actieve gebruikers. De toegevoegde derde persoon werd blijkbaar aangezien als een volwaardige gebruiker, wat vervolgens, zonder enige kennisgeving, de serialisatie, update en synchronisatie blokkeerde.
>> Hier volstaat een vlag- en ladingprobleem niet meer als diagnose, dit is erger. In applicaties komt dit veelvuldig voor. Het ding werkt niet meer, en je weet niet waarom, maar waarschijnlijk heb je zelf iets gedaan dat door de applicatie als fout gezien wordt. Dit heeft alles te maken met controles binnen de applicatie en daaruit volgende communicatie met de gebruiker. Een gebruiker ziet absoluut geen verband tussen het bericht "Foutieve serialisatie" en de invoering van een extra persoon.

ICT ellende

Het gaat hierboven om één van de massaal vele incidenten tussen gebruikers en ICT-diensten. Je zou gaan denken dat ICT-organisaties meer aandacht hebben voor hun winsten dan voor de gebruikers, maar dat is het niet, denk ik. Als ze hun gebruikers beter verzorgen, zijn die meer tevreden, en meer geneigd om bij hun leverancier te blijven, wat goed is voor het marktaandeel. Als ze zorgen dat hun applicaties beter werken, dan hebben ze minder helpdeskmedewerkers nodig, en geen afweersystemen. Hier geldt nog altijd dat kwaliteit geld opbrengt. Waarom gaat het dan nog steeds fout?

"Waarom falen informatiesystemen nog steeds?" is de titel van een boekje va J.A.M. Oonincx, uit 1982 (!). De moeite waard om te vergelijken met de huidige stand van zaken; zie binnenkort in de rubriek "Boeken". Hoewel je in vakliteratuur zeer weinig tegenkomt over negatieve dingen als fouten, zijn er toch wel bronnen te vinden over de omgang met en het vermijden van fouten, zie bv. minderfoutenmaken.nl. Maar ik vrees dat er hier iets anders speelt. Laat ons eens kijken waar eigenlijk de fout zit.

In het bovenstaande voorbeeld ontbreekt een essentieel bericht, bv. iets als "De licentie is beperkt tot twee actieve personen. Er zijn er momenteel drie geregistreerd. Gelieve één persoon te desactiveren.". Het gevolg van het ontbrekend bericht is ergernis bij de gebruiker, omdat zijn normaal proces onderbroken wordt, en ergernis bij firma C. omdat hun helpdesk wordt overbelast (om diverse redenen, wat intussen werd bevestigd). Je kan een ontbrekend bericht zien als een fout, maar het is interessanter nog wat verder terug te gaan: waarom ontbreekt dat bericht?

De fout

De veroorzaker is in elk geval firma C. Zij verzuimt aan de gebruiker de informatie te geven die hij nodig heeft om zelf zijn probleem op te lossen, en de gebruiker heeft niet voldoende kennis van de applicatie om het zonder die informatie te doen. De firma C. begaat de fout de gebruiker te overschatten qua technische kennis van de applicatie (en vermoedelijk ook haar eigen capaciteit om acute problemen bij gebruikers op te lossen te onderschatten, maar dat is een ander aspect); zij houdt dus geen rekening met menselijke eigenschappen. Het is immers zeer menselijk om de applicatie niet te kennen als daar onvoldoende opleiding voor gegeven wordt (en het hier vereiste niveau van opleiding is voor de meeste gebruikers bovendien te hoog gegrepen; het zijn niet allemaal informatici). Dus naast diverse vlag- en ladingproblemen is dit ook een systeem van het zevende knoopsgat. Welk systeem precies deze kwalificatie verdient is een andere vraag. Bekijk je het eng, dan gaat het om de geleverde software, bekijk je het ruimer (als foutsequentie), dan betreft het de hele firma C., of minstens de afdelingen analyse, ontwikkeling en helpdesk. Er is hoe dan ook werk aan de winkel.

Probleem en oplossing

Het kernprobleem: de kwaliteit van de applicatie is ondermaats op het vlak van preventie van problemen waarvoor een beroep wordt gedaan op de helpdesk. Het directe gevolg: overbelasting van de helpdesk, en ontevreden klanten. Firma C. is een grote firma in de sector, en kan vermoedelijk tegen een stootje, maar er zijn al grotere firma's over de kop gegaan door stommiteiten vol te houden. Als klant wil je geen problemen, maar wel stabiliteit op lange termijn, en die is hier in gevaar.

Als je binnengeraakt in de helpdesk (bv. buiten het begin van de maand, waar alle gebruikers willen factureren) wordt je doorgaans prima geholpen; de kwaliteit van de helpdesk is dus OK. De kwantiteit is wat anders, maar die uitbreiden is geen goede oplossing. Vermits de documentatie niet blijkt te deugen, is er allicht ook geen materiaal om nieuwe helpdeskmedewerkers op te leiden, zodat een opleiding door de beschikbare medewerkers zou moeten gegeven worden, wat nog minder capaciteit zou overlaten om gebruikers te helpen. Op die manier krijg je elke helpdesk op de knieën.

De oplossing: de applicatie op korte termijn verbeteren op de punten die de meeste capaciteit vergen van de helpdesk. Blijkbaar is elk begin van een maand een kritieke periode; de facturatie (net zeer belangrijk voor de gebruikers) is blijkbaar een pijnpunt. De helpdeskmedewerkers weten allicht precies waar de schoen het meest en het vaakst wringt. Er kan specifieke documentatie voorzien worden om die problemen op te vangen, en ook aan de functionaliteit valt m.i. één en ander te verbeteren.  Het volledig herwerken van de documentatie op middellange termijn is een volgende stap.

Nuttige procesverbetering bij firma C. kan ook nog, bv. door ervoor te zorgen dat er geen applicatie wordt uitgebracht die onvoldoende is getest. Ten tijde van het hoger beschreven geval werd door gebruikers volop geëxperimenteerd met het inlezen van de identiteitskaart van patiënten, een door het RIZIV opgelegde maatregel die de volgende maand in voege gaat. Data uit een smartphone of tablet werden blijkbaar niet correct gesynchroniseerd, of niet correct weergegeven op PC, waar het dan lijkt alsof de off-line lezing van de identiteitskaart niet goed gebeurd is. Natuurlijk krijg je dan een massa oproepen... Dat was absoluut te vermijden door grondiger te testen (en de gebruikers niet als testvee te beschouwen).

Ook belangrijk: zie de gebruiker als een specialist op zijn eigen terrein, maar als een leek in informatica, en vertrek van het idee dat hij zich toch moet kunnen behelpen zonder helpdesk. Dat helpt allicht om te bepalen welke berichten voor de gebruiker nuttig zijn, en impliceert meteen ook dat je de communicatie met de gebruikers beter kan laten inrichten door iemand die de taal van de gebruikers spreekt...

----------------------------------------------------------------

Standaard labels: