Interface management

De interface waar ik het hier over heb is die tussen de ICT- en gebruikersorganisatie.
Van oudsher een gebied waar makkelijk iets mis gaat. Meestal heeft dat te maken met het toverwoord ‘communicatie’.

Vanuit de ICT-organisatie is vanzelfsprekendheid vaak het probleem. Dat is nog wel eens zichtbaar in gebruikershandleidingen. ‘Klik op OK’ is lang niet voor iedere gebruiker een vanzelfsprekende handeling, maar toch wordt die stap vaak weggelaten in handleidingen. En op deze website komt u altijd terug bij de homepagina door op het logo te klikken. Een zeer gebruikelijke oplossing. Toch wou ik een menukeuze ‘Home’, want navraag leerde dat lang niet iedereen dat principe van home-via-logo kent.
En dan is er nog dat klassieke voorbeeld. ‘Press any key” stond in de handleiding, waarop de gebruiker de helpdesk belde om te melden dat hij helemaal geen any-key op zijn toetsenbord had. Humor, maar deze simpele voorbeelden geven hopelijk aan wat ik bedoel. Communicatie tussen ICT-ers en gebruikers dient heel serieus genomen te worden. Beide richtingen uit overigens.

In het gebied tussen ICT- en gebruikersorganisatie voel ik mij thuis. Ik ben geen communicatie-adviseur in de klassieke zin. Huur mij niet in om een communicatieplan op te stellen of om een communicatiecursus te geven. Maar als communicatie tussen gebruikers en ICT-ers concreet moet worden, ben ik de juiste persoon. Noem me maar een tolk: ik spreek beide talen.

Opstellen functionele specificaties

Misschien wel de moeilijkste stap in een ontwikkelproces. Samen met de klant helder en ondubbelzinnig vastleggen wat de klant wil. Op een zodanige manier dat ontwikkelaars en/of technisch specialisten daar mee verder kunnen en uiteindelijk iets opleveren wat de klant ook echt wilde hebben.
Ik hanteer een paar basisprincipes bij het opstellen van functionele specificaties die goed blijken te werken.

  1. Formuleer eerst een duidelijk doel en kader en blijf daar bij.
  2. Ga uit van de praktijk.
  3. Zoek voorbeelden maar vermijd concrete oplossingen.
  4. Vermijd vaktermen.
  5. Betrek een ICT specialist.
  6. Automatiseren is geen must.
     

1. Formuleer eerst een duidelijk doel en kader en blijf daar bij
Als je klantwensen gaat opschrijven, is het risico groot dat de specificaties steeds langer worden, omdat er steeds meer ‘ook nog wel handig’ aan wordt toegevoegd. Vooraf duidelijk met elkaar afspreken wat doel en kader van de specificaties moeten zijn, helpt dat te voorkomen.

2. Ga uit van de praktijk
‘Hoe gaat dat nú dan?’, is een zin die ik vaak uitspreek als ik met gebruikers over functionele specificaties aan het praten ben. Mensen kunnen vaak prima uitleggen wat hun eigen werk is en hoe ze dat doen. Dat is een enorm sterk uitgangspunt bij het formuleren van de gewenste situatie. Wat gaat er nu fout? Waarom werkt het nu niet of juist wel?

3. Zoek voorbeelden maar vermijd concrete oplossingen
Om te bepalen wat voor type functionaliteit gewenst wordt, kunnen voorbeelden heel goed helpen.
Bij het specificeren van de RfC-portal waarover u kunt lezen onder ‘Productontwikkeling’ hadden we het in de werkgroep vaak over ‘een belastingformulier’. Dat was een handig voorbeeld om aan te geven dat we op zoek waren naar een soort vraag- en antwoordspel zoals dat wordt toegepast bij de elektronische belastingaangifte.
Maar ‘We willen graag dat en dat softwarepakket’ is geen goed uitgangspunt voor functionele specificaties. Het ontneemt ICT-specialisten de mogelijkheid om naar een oplossing te zoeken die goed is voor de klant maar die ook past binnen de bestaande infrastructuur. Kostenoverwegingen kunnen daar een rol bij spelen.
Een klein voorbeeldje? Iemand vroeg ooit een ander spreadsheetprogramma dan Excel aan “omdat Excel maar 65.536 regels heeft en dat is te weinig voor mij” (Voor de kenners: het ging om Excel 2003). Daadwerkelijk een andere spreadsheet zoeken was hier niet de meest optimale oplossing. Wat wilde deze persoon precies dat hij zulke grote hoeveelheden data in een spreadsheet nodig had? Uiteindelijk was hij prima geholpen met een eenvoudige query-tool waarmee hij meteen de juiste gegevens kon opvragen uit een centrale database.

4. Vermijd vaktermen
Het lijkt voor de hand te liggen dat in een verhaal over ICT veel vaktermen staan. Toch liever niet. Vaktermen dragen vaak niet bij aan de eenduidigheid en begrijpelijkheid van het verhaal. Hoeveel betekenissen van het woord ‘interface’ kent u bijvoorbeeld? En als er dan toch vaktermen vallen, dan moeten die helder gedefinieerd zijn. Dat geldt overigens evenzeer voor vaktermen van de gebruikersorganisatie. Ook hier geldt: pas op voor onterechte vanzelfsprekendheid.

5. Betrek een ICT specialist
Ik neem bij gesprekken over functionele specificaties graag één van de toekomstige (senior) ontwikkelaars of technisch specialisten mee. Die kan helpen voorkomen dat er zaken op papier komen te staan die bij voorbaat al onhaalbaar zijn.
Ook helpt het dat de ICT-specialist het ‘wordingsproces’ meemaakt; dat maakt de kans op communicatiestoringen tijdens de uitvoering weer wat kleiner.

6. Automatiseren is geen must
Niet alles hoeft geautomatiseerd te worden. Sommige zaken zijn ook prima op te lossen of zelfs beter met goede afspraken en procedures. Een voorbeeld.
Een technische meldkamer wilde een 24/24-uurs systeem waarmee klanten zelf on-line storingen konden melden. De afgesproken reactietijden waren zeer kort. De klant wilde daarom een systeem met een extreem hoge betrouwbaarheid. Dat werd een dure grap. Volgens mij kan het ook zo: vertel de klant na het melden van de storing dat hij binnen een paar minuten een bevestigingsmail krijgt. Komt die mail niet, laat de klant dan alsnog telefonisch contact zoeken.

Nog even een knipoog. Bekijk dit filmpje eens. Iemand heeft dit apparaat kennelijk gebouwd. De bouwplaten (technische specificaties) schijnen ook echt te koop te zijn. Maar welke functionele specificaties zijn hier nou voor opgesteld?

Procedures en werkinstructies

‘Als ze er niet zijn wil iedereen ze hebben en als ze er wel zijn leest niemand ze.’
Deze uitspraak is misschien wat kort door de bocht, maar enige waarheid schuilt er wel in. Maar hoe maak je nu procedures en werkinstructies die wel gelezen worden?
Ik heb er zo langzamerhand al een heleboel geschreven, dus ik zou het moeten weten. Maar eerlijk gezegd zien mijn documenten er iedere keer toch weer net even anders uit.
‘Voortschrijdend inzicht’, zou je dan kunnen zeggen, maar dat is niet het hele verhaal. Ik probeer altijd zo veel mogelijk aan te sluiten bij al bestaande praktijken binnen een bedrijf. Dat verhoogt de kans dat de nieuwe procedures en werkinstructies ook daadwerkelijk geadopteerd worden. Het ene bedrijf is nou eenmaal formeler ingericht dan het andere en dat heeft zijn invloed op de acceptatie van dit soort zaken.
In ieder geval ga ik zo min mogelijk in discussie over de vraag wat nou een procedure en wat nou een werkinstructie is, en waar exact de grens ligt tussen die twee. Wat veel beter werkt is het maken van een paar voorbeelden en het aanbieden van sjablonen die het zo gemakkelijk mogelijk maken om dezelfde stijl te hanteren.

Eén procedure moet er in ieder geval altijd zijn: de procedure die beschrijft hoe het onderhoud van de procedures en werkinstructies is geregeld. Dat lijkt een open deur, maar is één van de zaken die in de praktijk vaak niet is geregeld en dat is zonde van al de tijd en het werk wat is gestopt in het initiële opstellen. Bovendien zijn slecht of traag onderhouden procedures en werkinstructies de doodsteek voor de acceptatie daarvan.

Er komen overigens steeds meer mogelijkheden beschikbaar om procedures en werkinstructies anders te publiceren dan als een set van losse documenten. Van vrij eenvoudig tot zeer complex. Die kunnen het onderhoud vaak ook vergemakkelijken.

Het project masterplan

Ik was lid van een projectteam dat een grote SAP-rollout ging doen bij een groot Nederlands bedrijf met verstigingen door heel Nederland.
De projectleider had hier een masterplan voor opgesteld. Doel: de diverse managementlagen van te voren uitleggen hoe het project zou gaan verlopen. De rollout werd per vestiging uitgevoerd, dus het plan moest meerdere keren gebruikt worden.
De projectleider gaf mij het plan om het te optimaliseren. Het was namelijk ‘knip- en plakwerk’. Daar is niets mis mee overigens; ook ik gebruik graag ervaringen en goede formuleringen uit het verleden opnieuw.
Ik heb het plan op alle manieren gereviseerd. Zinsbouw en leesbaarheid; logische indeling van de hoofdstukken; aanpassen taalgebruik etc. Daarbij kwamen vanzelf ook nog een paar hiaten in het plan naar boven die we vervolgens hebben opgelost. Daarna hebben we het nodige presentatiemateriaal ontwikkeld om het verhaal mee te kunnen uitleggen.