real word-digital world
organisatie

Functionarissen in de ICT en lijnorganisatie als faalbron.

Naast taal en interpretatie als faalbron is er natuurlijk de functionaris zelf die fouten kan maken omdat hij of zij niet de juiste kennis of kunde heeft . Naarmate een functionaris meer betrokken is in het voortraject van informatiesysteem ontwikkeling, zijn de gevolgen van een fout groter, simpelweg omdat alles dat er sequentieel achteraan komt dan ook moet worden overgedaan.

De ICT-organisatie is opgedeeld naar functionaliteit. De functies en functiebenamingen verschillen van organisatie tot organisatie. In feite geldt dat hoe eerder een functionaris participeert in het informatiesysteem-ontwikkelproces, hoe belangrijker hij of zij is … … Niet omdat iemand belangrijker is, maar omdat een fout in het voortraject meestal een grotere gevolgschade heeft, want de fout zit dan ook in alle deelproducten daarna, die op basis van het voortraject zijn gebouwd.

Dit impliceert dus dat een lijnmanager die een verkeerde beslissing neemt aan het begin van het ontwerp van een applicatie meer impact heeft dan een tester die aan het eind van traject zit. Je kunt dus stellen dat een business analist een grotere verantwoordelijkheid heeft dan een functioneel ontwerper die op zijn beurt weer een grotere verantwoordelijkheid heeft dan een programmeur.

Niet dat een tester of een programmeur niet een kapitale fout kan maken, want dat kunnen ze absoluut zeker, maar de herstelkosten van een programmeursfout of testfout zijn (in veruit de meeste gevallen) relatief veel lager. De faalkosten van een programmeerfout zijn normaliter veel kleiner dan een fout in het database ontwerp of een foutieve interpretatie van een set business-rules bij het opstellen van use-cases door ontwerpers, of het verkeerd definiëren van een oplossing (business case) door de business-analist.

Het feit dat fouten en omissies in een applicatie vaak laat worden ontdekt, namelijk als ze al geprogrammeerd zijn (meestal pas bij het testen door de eigen ICT-afdeling of bij de gebruikers acceptatie test), is er de oorzaak van dat men in het taalgebruik altijd spreekt van foute programmatuur. Daarbij kan nog worden vermeld dat de hedendaagse programmeur qua coderen weinig of geen fouten meer kan maken, simpelweg omdat de code gegenereerd wordt en er talloze geautomatiseerde controles plaatsvinden binnen de softwareomgeving waarmee men de applicatie ontwikkelt.

Fouten en omissies en de  daarmee samengaande  te hoge kosten ontstaan dus eerder door verkeerde ontwerpen en ideeën van allerlei functionarissen aan de voorkant van de informatiesysteemontwikkeling dan door programmeerfouten of testfouten.

Vanuit de zijde van de lijnorganisatie hebben de AO-functionarissen die verantwoordelijk zijn voor de instructies voor gebruikers en eindgebruikers eveneens een cruciale rol. Als de applicatie goed is, maar de werkinstructies niet, zal dit eveneens voor aanzienlijke problemen zorgen.

Waar dus de ene programmeur nooit exact hetzelfde zal programmeren als de andere, geldt ook dat de ene zaakbeoordelaar ook niet altijd dezelfde conclusie zal trekken als de andere. Zeker niet als de administratieve regelgeving onvoldoende eenduidig is beschreven. Hoe meer regels hoe complexer. Hoe meer uitzonderingen, hoe complexer. Hoe frequenter veranderingen, hoe complexer het wordt  voor lijnfunctionarissen (o.a. de zaak behandelaars) en IT-ers. Onderstaand schema illustreert een en ander.

3

Specificeren van business-rules en data-definities is dus bijzonder lastig! Evenals het opstellen van de juiste actuele AO-richtlijnen.  Nog moeilijker is het vertalen en juist combineren en interpreteren van al deze informatiestromen.

Het is daarom zaak om de kwaliteit van van functionarissen in elke rol (zowel aan de  ICT zijde als aan de business/AO zijde) dan ook grondig te controleren.  Zeker ook omdat soms vanuit bedrijfspolitieke beweegredenen functionarissen arriveren op plaatsten waarvoor  ze minder geschikt zijn. Derhalve zijn continu assessments noodzakelijk om er voor te zorgen dat de juiste man of vrouw op de juiste plaats zit.

SOLIM biedt diverse  trainingen,  functie-assessments en consultancy voor metingen en verbetertrajecten om de faalkans  aanzienlijk te verkleinen.

ACTUEEL

Transparantie en Traceerbaarheid

Hoe bewaak ik de consistentie tussen uitgevaardigde wet of business rule en de implementatie daarvan in mijn organisatie  Wetswijzigingen , wijzigingen in de dienstverlening of in producten leiden impliciet tot veranderingen in bedrijfsprocessen en hun IT systemen.  Hoe gaan we daar mee om nu de veranderingssnelheid toe blijft nemen ?  Met transparantie bedoelen we hier:…
Read More

Veranderbaarheid

Veranderbaarheid van applicaties en TESLA’ s (een softwarefabriek is geen automobiel fabriek ) Hoe breng je in een organisatie wijzigingen aan, rekening houdend met de complexiteit aan deelprocessen, componenten, richtlijnen, procedures, normen en mensen? Bijna elke wijziging raakt het informatiesysteem. De mate van veranderbaarheid daarvan is dus essentieel.  Het beheer van applicaties en systemen, AO…
Read More

Werving & Selectie

GEZOCHT : Business analist QA specialisten
Read More