De zwakste schakel
75 % van alle implementaties van data- en documentbeheersystemen schijnt te mislukken. Dat is een onvoorstelbaar hoog percentage, al verbaast het me niet echt. In de praktijk blijkt dat dit soort projecten heel stroperig verloopt, omdat in alle wijsheid besloten wordt dat werken aan draagkracht en goede communicatie kan stoppen op het moment dat er een implementatie- en communicatieplan gemaakt zijn. De menselijke factor, die zo belangrijk is voor het slagen van dit soort projecten, wordt binnen organisaties structureel genegeerd.
En dat is zeer opvallend, want het is tevens een ‘menselijke factor’ die het beleid formuleert, die systemen kiest en koopt, die systemen implementeert, die de randvoorwaarden voor het functioneren van systemen wel (en meestal niet) invult, die beheershandelingen overlaat aan mensen, die niet controleert of deze handelingen wel of niet worden uitgevoerd…. Zo kunnen we nog even doorgaan.
Toch is het negeren van de mens door de mens niet de enige oorzaak van die dramatische implemetatie-performance. Een net zo belangrijke factor ligt in het zwakke handelen van de ‘menselijke factor’ die stuurt, managed, beleid vormt of erover adviseert en zo. Die verantwoordelijk is voor het formuleren van de goedgebekte, maar zeer vage doelstellingen van het ontwikkeltraject dat aan de implementatie vooraf gaat of van het traject waarin nieuwe software gekozen wordt. Die de eisen waaraan de nieuwe software moet voldoen (zowel technisch als functioneel) slecht of zelfs helemaal niet specificeert. De gevolgen laten zich raden.
Laat ik eens een aantal problemen noemen met het formuleren van eisen die de ontwikkeling of de keuze van software te vaak parten spelen en vervolgens leiden tot problemen met de implementatie of het onderhoud ervan.
• De eisen zijn niet 100 % duidelijk, waardoor meerdere interpretaties mogelijk zijn;
• De eisen worden verward met ontwerp, waardoor geen eisen gesteld worden aan de te ontwikkelen applicatie, maar aan het totstandbrengen ervan. Hierdoor kunnen allerlei bottle-necks en beperkingen optreden;
• De eisen zijn onrealistisch. De software moet functies kunnen vervullen die veelal nooit worden gebruikt, maar ‘je kunt nooit weten’;
• De tijdsdruk: een produkt moet liever eergisteren functioneel zijn. Ik constateer voortdurend dat te snel besloten wordt dat een produkt aan de eisen voldoet, zonder een intensieve test van het produkt.
• De ongeïnteresseerdheid van het management: ze geloven het wel. Participatie van belanghebbenden in een project is bijna onhaalbaar. De tijd die besteed mag worden aan het project is zeer beperkt en vaak moeten ook de dagelijkse problemen gewoon opgelost blijven worden. Het gevolg is dat de realisering van het project of in externe handen komt en/of in een exclusieve, volledige ‘ivoren toren’ terecht komt met alle gevolgen van dien.
• Het ontbreken van adequate technologie, waardoor minder fouten mogelijk worden omdat de inbreng van de ‘factor mens’ in het beheerproces wordt teruggebracht. ‘Menselijke fouten’ worden daardoor vermeden.
Zo kan ik nog wel even doorgaan.
Niet alleen in organisatie-interne projecten is dit te constateren, maar – wellicht nog minder te verteren – ook in projecten die ons als maatschappij in totaliteit aangaan. Ik denk dan met name aan al die projecten gericht op het invoeren van een echte ‘digitale identiteit’ (los van DigID, wat (hoe graag dat ook wordt beweerd) in principe geen digitale ID is), waarvan de pilots zo ongeveer overal op een laag pitje zijn gezet….
Weten we eigenlijk wel wat we willen ? Moeten we overal niet te snel ‘scoren’ ?
Ik maak regelmatig mee dat ‘scoren’ op korte termijn veel belangrijker is dan een project werkelijk goed voorbereiden, zodat werkelijk het resultaat gehaal wordt wat men wenst te halen. Een beetje goede voorbereiding maakt veel van de bovenstaande problemen onnodig.
Maar ja, zal wel een teken van de tijd zijn…..
De mens als ‘zwakste schakel’: dat idee moet nog echt ingang vinden !
Mei-juni 2006