Taal en specificeren, als faalbron bij het opstellen van requirements, specificaties, procesbeschrijvingen en AO richtlijnen.
Een van de hoofdoorzaken van fouten en omissies zo niet de voornaamste oorzaak, is het gebruik van taal. Per definitie heeft elk mens een eigen perceptie bij de betekenis (interpretatie) van woorden. 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 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?
- 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 is de business-rule afgeleid uit een wet- en regelgeving van landelijke overheid en gemeentelijke voorschriften waarbij op de afdeling applicatieontwikkeling een ontwerper er zijn of haar interpretatie aan geeft. 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.
ACTUEEL
Transparantie en Traceerbaarheid
Veranderbaarheid
