Een episch relaas van een Tester op een afdeling Beheer en Onderhoud

In de onderstaande afbeelding is op de eenvoudigste wijze weergegeven hoe de gebruiker omgaat met het systeem. De gebruiker voert gegevens in waarna het systeem deze omzet en het weer terugkoppelt aan de gebruiker. Voor de gebruiker zal in eerste instantie niet duidelijk zijn welke gegevens het systeem terugkoppelt, in hoeverre er reeds een transformatie heeft plaatsgevonden en of dat de input dan wel de output niet correct is.

 

Op het moment dat een gebruiker een melding indient dan zal dat zijn omdat hij een afwijking heeft gevonden op wat hij verwacht had. Het kan ook zijn dat de gebruiker op een bepaald moment niks verwacht had maar toch een terugkoppeling uit het systeem krijgt. In de bovenstaande afbeelding zit de gebruiker op het moment dat hij een melding doorgeeft aan de beheerders van het systeem dus in zijn beleving altijd aan de Output-Fout kant. Voor de analyse is het noodzakelijk dat de gebruiker communiceert wat de gebruiker te zien krijgt, wat hij daar dan verwacht had en waarom hij dat daar verwachte. Maar ook welke handelingen hij verrichte voordat de afwijking aan hem gepresenteerd werd.

De gebruiker zal dus uit zich zelf de volgende vragen moeten beantwoorden:

Waarom wilt de gebruiker het opgelost zien?          Waarom is het een probleem?

Wat is het probleem precies?                                     Waarom juist dat?

Waar treedt het probleem op?                                   Waarom juist daar?

Wanneer treedt het probleem op?                             Waarom juist dan?

Wie is/zijn bij het probleem betrokken?                   Waarom juist hij/zij?

Hoe gebeurt het?                                                         Waarom op die manier?

Het is belangrijk dat de gebruiker zelf de afwijking kan reproduceren, dit onder woorden kan brengen en eventueel kan communiceren aan de hand van screenprints en loggingen. Een voorbeeld spreekt immers boekdelen en een plaatje zegt meer dan een duizend woorden. Een referentie naar een FO, TO of een andere bron waarin requirements staan beschreven worden zeer op prijs gesteld. Alleen als aan al deze voorwaarden is beantwoord kan een gedegen analyse door de beheerders van het systeem gemaakt worden. Indien deze informatie ontbreekt dan zal dit opgevraagd moeten worden bij de gebruiker die de melding heeft ingediend voordat het euvel serieus aangepakt kan worden.

Zodra de melding door de klant gemeld wordt aan de beheerders van het systeem zal deze dusdanig bewerkt moeten worden dat het voor andere gebruikers duidelijk is waar het om gaat. Daarom mag in de verklarende beschrijving geen rechtstreekse kopie staan van de initiële melding van de gebruiker. Dit is ook om bij alle vervolg stappen van het proces sneller te laten doorlopen en miscommunicatie te voorkomen.

De analyse valt uit één in twee gedeeltes, het functionele en van daar uit de technische analyse. De beheerders van het systeem moet zich er voor hoeden dat in deze fase gedegen informatie wordt geproduceerd en niet de analyse een (al dan niet gehele) kopie betreft van de verklarende beschrijving . Of nog erger dat de verklarende beschrijving leeg wordt gelaten. In de functionele analyse moet staan hoe de functie wordt aangeroepen, wat de gebruikte invoergegevens zijn en welke sources voor de spaak zorgen. Dit kan dan vervolgens na verdere analyse aangevuld worden met pseudo-code. Niet alleen de juist situatie dient beschreven te worden maar ook de fout situatie en op welke manier dit gecommuniceerd dient te worden richting de gebruiker. Na de functionele analyse vindt de technische analyse plaats indien de functioneel specialist dit nodig acht. Dit is het geval als blijkt dat de melding van de klant niet door middel van sturingstabellen is op te lossen. Bij de technische analyse dient te worden beschreven aan welke objecten nieuwe code toegevoegd moet worden en/of in welke objecten oude code zal worden aangepast dan wel verwijderd. (Met een uitgebreide beschrijving welke code dit dan betreft.) Daarnaast wordt tijdens de technische analyse beschreven in welke laag van de applicatie de aanpassing plaats zal vinden. Denk daarbij grof weg aan: schermen, database, transport en/of de data-dictionary, repository of zelfs opleidingsmateriaal.

De uiteindelijk toegepaste oplossing wordt volledig, uitvoerig en eenduidig beschreven in de bevinding’s artefact. Deze oplossing wordt uiteindelijk naar de klant teruggekoppeld.

Als laatste komt de tester om de hoek kijken, voor de tester is het belangrijk dat het bovenstaande volledig is uitgevoerd. Anders zal de tester geen simulatie uit kunnen voeren met de eindgebruiker in gedachten. Dit omdat de tester de bovenstaande gegevens zal omvormen tot testscripts en die zal proberen uit te voeren. Daarvoor is het dus nodig dat de tester toegang heeft tot een stabiele omgeving waarin geen technische of functionele werkzaamheden plaats vinden.

Zou dit niet fantastisch zijn als dit allemaal gebeurd is, helaas is dit maar zelden het geval. Net zo zelden als dat een gebruiker weet wat hij doet en een opdrachtgever weet wat hij opgeleverd wilt krijgen. Net zo zelden als alle partijen op één lijn zitten en net zo zelden als de roadmap die aan het begin gemaakt wordt gaande de tijd overeind blijft staan. Net zo zelden als een melding een alleen staand geval is en net zo zelden als van te voren duidelijk is wanneer we klaar zijn als dat we een onuitputtelijke bron van resources hebben.

Deze zeldzaamheden maakt dat we nog twee vragen beantwoord moeten krijgen:

Welke werkzaamheden doen we eerst?                                    Waarom juist die?

Wat voor terugkoppelingen verwacht je?                                 Waarom juist dan?

Waarom zou je een netwerk op zetten?

Strategische allianties en netwerken zijn termen die meestal geassocieerd worden met het bedrijfsleven en net als het meeste jargon verwart ze meer dan dat het duidelijk maakt. In wezen zijn beide simpele genootschappen van mensen of organisaties die zich verenigen voor het gezamenlijke belang.

Strategische allianties en netwerken zijn al geruime tijd belangrijk voor de zakelijke wereld. De zelfde economische nood en markt omstandigheden die dit de efficiëntste strategie heeft gemaakt voor andere bedrijven zijn ook op jouw organisatie van toepassing. Om te begrijpen waarom strategische allianties en netwerken bruikbaar zijn voor jouw organisatie en wat het effect er van zal zijn moet men eerst kijken naar welke veranderingen er gaande zijn binnen de organisatie en de algemene economie.

Men kan rustig zeggen dat er op dit moment een neerwaartse trend is in de economie, men spreekt zelfs van een recessie. Om nog maar te zwijgen over het gevoel dat “alles alsmaar duurder en duurder wordt” bij de consument. Dit zal ook zijn effect op jouw organisatie hebben in de nabije toekomst, als men niet nu al de effecten ervan voelt.
Uw organisatie kan deze effecten van zich af schudden door gebruik te maken van strategische allianties en netwerken zonder dat ze daarbij haar eigen gezicht verliest.

Terwijl men zich in deze branche steeds meer specialiseert, slaan de organisaties steeds meer bruggen tussen de niches. Op de nieuwe manier is het gehele proces van oerproducent tot consument belangrijk en niet slechts één schakel in de bedrijfskolom. Terwijl men de moeite kan nemen om elke stap van het proces zelf te doen kan men ook zo veel mogelijk uitbesteden om zo elke keer de maximale dienstverlening te kunnen bieden. (Al kan je op die manier niets vastleggen en dreigt dan het gevaar de controle en het overzicht te verliezen.)

In het kort kan je zeggen dat er een verschuiving nodig is van een basis dienst naar een all-in pakket en van een markt naar contracten. Het voornaamste onderscheid tussen de twee manieren van werken zit in de winstmarge. Waar je het met een basis dienst verlening van hogere volumes en lage kosten moet hebben, kan door de toegevoegde meerwaarde van het totale concept een hoger rendement worden behaald (Je houdt het beste zelf en dumpt de restjes op de voor de concurrent nadelige markt).

De vastgelegde informatie wordt extreem belangrijk. Of dat dit nu de informatie is over de pensioenreglementen, welke overheidsregels men moet hanteren of wanneer wie nu welke afspraak heeft staan, de gehele organisatie is gebouwd rond om de kennis van de dienstverlening. Al deze kennis wordt vergaard en vastgelegd met behulp van moderne technologieën. Deze technologieën zorgen er voor dat het wiel niet elke keer op nieuw uitgevonden moet worden. De beschikbare kennis wordt met iedereen gedeeld zodat alle koppen de zelfde richting op staan. Zie figuur 1 hoe de vaardigheden zich ontwikkelen naarmate de organisatie volwassen wordt. (lees: Ouder.) 

Figuur 1: Ontwikkeling van netwerk vaardigheden.
Al met al laat een organisatie zich steeds meer standaardiseren, wat inhoud dat de dienstverlening die men aanbiedt steeds meer “lopendebandwerk” word. Alsmaar beter inzicht in de dienstverlening, een database gekoppeld aan het internet en belanghebbenden die eigenlijk op voorhand een keuze moeten maken waardoor de wijzigingen niet veel meer zijn dan een formaliteit die waar wel juist op ingespeeld moet worden.