Faaloorzaak taal
Taal en specificeren middels taal, is veelal op zichzelf al een faalbron bij het opstellen van requirements, specificaties, procesbeschrijvingen en AO richtlijnen.
Taal is een van de hoofdoorzaken van fouten en omissies zo niet de voornaamste. Op zich zelf is taal veelal ``ambigious`` (multi-interpretabel), Daarnaast heeft per definitie elk mens een eigen perceptie bij de betekenis (interpretatie) van woorden en zinnen. Geboren uit zijn of haar eigen ervaring neemt men aan te begrijpen wat er op papier staat of wat er in een gesprek gezegd wordt. Enkele eenvoudige voorbeelden:
- Iemand heeft recht op een maandelijkse gemeentelijke uitkering, maar hij of zij moet binnen de gemeente wonen. …. Mr De Boer is net uit Rotterdam verhuisd naar Breda. Hij woont inmiddels in Breda maar hij staat nog ingeschreven in Rotterdam. Heeft hij nu wel of geen recht op die uitkering? En wie moet de uitkering betalen.
- Iemand die klant is bij ons heeft recht op 10% korting en gratis toezending van twee vrijkaartjes. Voor de marketingmedewerker binnen een organisatie is een klant iemand die een klantnummer heeft. Voor de ander van de debiteurenafdeling is het iemand die minder dan één jaar geleden nog iets bij ons gekocht heeft. Krijgt hij die korting of niet?
- Of de patiënt in een ziekenhuis: Wat is nu eigenlijk precies een patiënt en voor wie? Onderstaande afbeelding geeft weer hoe de verschillende functionarissen naar een patiënt kunnen kijken en wat hij of zij (mogelijk) verstaat onder een patiënt.
In alle gevallen hangt het er dus van af wat de logica en belevingswereld van de ontwerpers en programmeur zijn, en hoe hun aanspreekpunt een en ander beschreven heeft. De interpretatie is veelal aan hen. In het eerste geval van meneer De Boer geldt dat de ontwerper en programmeur de juiste interpretatie moeten geven aan het woorden ``wonen`` en ``ingeschreven``. Afhankelijk van hun interpretatie zal het systeem wel of niet uitkeren. In het tweede geval is de business-rule bedacht door de marketingafdeling en het is weer de ontwerper of programmeur die er zijn of haar eigen interpretatie aan geeft. In het geval van de patiënt in het ziekenhuis bepaalt elke functionaris zijn eigen definitie van zijn patiënt.
Het interpreteren en (vervolgens) schrijven van specificaties aan ICT kant is een van de belangrijkste bronnen voor het ontstaan van fouten. Exact hetzelfde geldt voor het interpreteren en neerschrijven van procesbeschrijvingen, AO richtlijnen en normen. En niet te vergeten het interpreteren van richtlijnen van externen, zoals bijvoorbeeld wetswijzigingen.
SOLIM biedt diverse trainingen en consultancy voor metingen en verbetertrajecten om de faalkans aanzienlijk te verkleinen.