AUTOMATISERING ALS EEN TIKKENDE TIJDBOM
Diverse artikelen over automatisering
Toekomstige softwareontwikkeling, Uitgangspunten technisch ontwerp, Datamodules, Databaseontwerp
Vijf en twintig jaar werkzaam in de automatisering bij kleine softwarehuizen als senior programmeur verantwoordelijk voor het ontwikkelproces van standaard software pakketten. De laatste vijftien jaar gedetacheerd bij diverse klanten als banken, brokers, verzekeringsmaatschappijen, zorgverzekeraar en beveiliging. C++, Delphi, VB en SQL-Server specialist. Programmeertaal onafhankelijk. Fotografisch geheugen. ICT ervaring sinds 1986. Bij voorkeur werk ik aan systemen, waarvan de ontwikkelaar tien jaar gelden de deur is uitgelopen, zonder relevante documentatie. Ik lees broncode gemakkelijker dan technische en functionele ontwerpen en kan moeiteloos een schijnbaar verouderd systeem weer helemaal in een modern jasje gieten inclusief adequate documentatie.
'Automatiseringsprojecten mislukken dikwijls. Toch hebben topbestuurders er weinig aandacht voor. "De gemiddelde IT-'er is helemaal geen IT-er". Dit is het begin van een artikel in het NRC van zaterdag 21 februari 2004. Volgens de auteurs en onafhankelijk onderzoeksbureau Gartner wordt er jaarlijks wereldwijd 500 miljard dollar over de balk gegooid aan mislukte automatiseringsprojecten en lijdt volgens het even gerenommeerde Forrester, alleen de Amerikaanse economie al voor 60 miljard aan schade door slechte software. Nog een desastreus getal van Forrester: Slechts een op de vijftig computertoepassingen blijkt echt te werken, is op tijd afgeleverd, binnen het afgesproken budget en uitgevoerd volgens de offerte. Onthutsende cijfers. Toch komen mislukte automatiseringsprojecten maar mondjesmaat naar buiten. Alleen als het niet anders kan en de winst onder druk komt te staan, zie je er wat van terug in de jaarcijfers.'
Iedereen werkzaam in de automatisering en die zijn ogen gebruikt, ziet dat het NRC gelijk heeft. Ontzettend veel projecten mislukken. De oorzaak wordt veelal gelegd bij zwak management, slechte voorbereiding, te hoge verwachtingen, etc. Zelden heeft men het over de programmeerafdeling als oorzaak van het probleem. Vreemd... Aangezien vaak meer dan driekwart van de medewerkers aan een project op of rond deze afdeling werken. Een fractie meer efficiëntie bij zoveel medewerkers maakt enorm verschil op de kwaliteit en kwantiteit van het eindresultaat. Vaak is programmeren het afvoerputje van de automatisering. Daar begint ieders carrière, slecht betaald, weinig verantwoordelijkheid en iedereen probeert daar zo kort mogelijk te verblijven. Nergens veroudert kennis zo snel. De gemiddelde programmeur heeft niet of nauwelijks een relevante opleiding. Veel mensen worden na een korte cursus van enkele weken in het diepe gegooid. Tenzij zij zelf flink aan het studeren slaan, leren ze er weinig meer bij. Na twintig jaar werken bij dezelfde baas, met dezelfde tool zonder een dag cursus is voor veel mensen de toekomst uitzichtloos...
Een goed functionerende programmeerafdeling is opgebouwd uit mensen met potentieel, interesse in het vak, die dagelijks van alles bij willen leren. Een competitieve sfeer en professioneel gedrag is kenmerkend. Het is werk en het is beter voor iedereen om dat goed te doen. De leiding van zo'n afdeling stimuleert en controleert dagelijks het verloop van de werkzaamheden. Ieder verstoring wordt aangepakt alvorens het tot negatieve effecten leidt voor de voortgang van het project. De gebruiker en het programma is belangrijk. Het creëren van koninkrijk, het excelleren op deelgebieden is ondergeschikt aan het algemeen belang. Veelzijdigheid is belangrijker, dan kennis van de gebruikte programmeertools. Het vak is zo breed, dat niemand alles kan weten. Elkaar aanvullen leidt tot het best resultaat.
Hoe komt het dat je een goed draaiende programmeerafdeling zo zelden tegenkomt in de praktijk. Het is zelden een kwestie van geld. Vooral bij grote bedrijven met enorme budgetten voor automatisering zie je boel het hardst in het honderd lopen. In de jaren zeventig verschenen er diverse boeken, die op hilarische wijze het fenomeen bureaucratie beschreven. Peter-principal, wet van Murphi en succesvolle televisieprogramma's als Jiskefet zijn allemaal voorbeelden van grappen over grootschalige ambtelijke organisaties. Niets is zo slecht voor een automatiseringsproject als bureaucratie. In een grote ambtelijke organisatie is de lieve vrede belangrijker, dan kwaliteit. Eenmaal aangenomen is een niet functionerend automatiseerder nauwelijks meer weg te krijgen. Communicatie tussen ontwikkelaars en gebruikers is problematisch. Communicatie tussen werkers op de werkvloer en het management is moeizaam. De werkelijkheid van managers heeft vaak weinig te maken met succesvol automatiseren.
Tijdens mijn laatste vakantie trof ik een gepensioneerde directeur van een oliemaatschappij, die in het begin van zijn carrière eens een olieraffinaderij 'erfde', die in alle opzichten het slechtste presteerde van het hele concern. Voortdurend waren er storingen. De helft van de tijd lag de boel plat. Niemand voelde zich verantwoordelijk. Het was om wanhopig te worden. Hij was van mening, dat het vooral een personeelsprobleem was. Hij verdeelde zijn werknemers in drie categorieën: Hopeloos, redelijk en goed. Hij begon iedereen uit de eerste categorie te lozen. De tweede categorie liet hij met rust en voor derde categorie verzon hij uitdagingen. Hij gaf ze vooral verantwoordelijkheid. Hij organiseerde cursussen. Hij maakte bovenal iedereen duidelijk, dat als een toko plat ging, er maar een persoon verantwoordelijk was. Namelijk degene, wiens toko het was. Binnen een half jaar presteerde de raffinaderij boven modaal.
Dezelfde aanpak zou best eens kunnen werken bij een programmeerafdeling. Mensen zonder affiniteit of belangstelling voor het vak moet je zo snel mogelijk lozen. Ook moet men zich realiseren, dat programmeren een vak is. Niet iedereen is er geschikt voor. Zelfs buitengewoon intelligente mensen kunnen ongeschikt zijn, omdat het hen ontbreekt aan geduld, precisie, vasthoudendheid. Het is dan voor alle partijen beter, dat er een oplossing wordt gevonden. Gebrek aan opleiding is het tweede nijpende probleem in de automatisering. Vrijwel nergens kun je het vak leren. Een goede opleider loopt in een oogwenk kilometers achter op de werkelijkheid, omdat alles zo snel gaat. Iedere minuut opleiding op welk gebied dan ook, intern of extern verdient zich terug in het honderdvoud.
Niemand voelt zich verantwoordelijk voor het eindresultaat. In de automatisering geldt de regel van 10. Als een fout 1 euro kost om direct opgelost te worden door de programmeur, dan kost het 10 euro als een tester het moet ontdekken. Bij de eindtest kost het 100 euro en als de gebruiker er tegenaan loopt kost het probleem 1000 euro. Het is essentieel voor kosteneffectief ontwikkelen om de programmeur de elementaire fouten eruit te laten halen. Onbegrijpelijk vaak zie je programmeurs hun 'oplossingen' zonder enige vorm van technisch testen over de schutting werpen. De programmeur beschikt over de beste tools om fouten te signaleren. Voor anderen is het tasten in het duister. Broncode is niet beschikbaar. Hulpmiddelen als debuggers, query-analisers en profilers ontbreken. Het is van groot belang programmeurs ervan te doordringen, dat stomme fouten nooit en te nimmer mogen doordringen naar de buitenwereld.
Bij uitbesteding van het ontwikkeltraject aan derden is het succesvol aansturen van het project voor de opdrachtgever een hele opgave. Het betreft complexe zaken, veel onervaren slecht opgeleide deelnemers. Het is moeilijk om als ontwikkelaar de echte gebruiker te spreken te krijgen en te verstaan. De klant implementeert slechts eens in de zoveel jaar een nieuw automatiseringssysteem. Zelden slaagt hij erin om zelf voldoende kennis en ervaring op de been te brengen om te krijgen wat hij wil, voor de afgesproken prijs in de afgesproken tijd. Zonder voldoende deskundigheid, tijd en aandacht wordt het niets. Of je zorgt als toekomstig gebruiker zelf voor voldoende kennis en ervaring om toe te zien op de ontwikkeling of je huurt het in. Het is vreemd, dat in tegenstelling tot de bouw er geen systeem is ontstaan van gescheiden toezicht (architect, aannemer, etc.). Vrijwel altijd ligt de projectaansturing in een hand. Het ligt voor de hand om de bouw van een nieuwe applicatie uit te besteden aan twee verschillende bedrijven. De ene partij verzorgt de realisatie. De ander het toezicht.
Meten is weten. Echter het is niet eenvoudig om de prestaties van ontwikkelaars adequaat te meten. Uitgebreide planningen worden gemaakt. Urenstaten worden geduldig ingevuld. Systemen worden ontwikkeld met zogenaamde functiepunten. In rapportages naar de klant worden kosten uitvoerig verantwoord. Toch is het resultaat onbevredigend. Processen laten zich slecht vangen in cijfers. Cijfers liegen. Hetzelfde zie je in de boekhouding. Zonder een externe accountant zouden veel bedrijven er maar een potje van maken. Zelfs met onafhankelijke controle gaat het wel eens mis. Regelmatig hoor je hoe het gaat met het invullen van urenstaten. De uren van het lopende project zijn op. De projectleiding wil liever niet toegeven, dat de boel niet helemaal lekker verlopen is. Dus worden de uren geboekt op een volgend project, waarvoor nog uren beschikbaar zijn. Tegen de tijd dat dit project aan de gang gaat, is een groot deel van de uren opgebruikt. Het gevolg is, dat ieder reëel inzicht in de voortgang van projecten voor het management uit het zicht is verdwenen.
Je wilt kwaliteit en kwantiteit. Zeker routinematig verzamelde cijfers hebben de neiging een weerspiegeling te zijn van de wens van de projectleiding en niet van de werkelijkheid. Succesvol prestaties meten doe je door te vergelijken. Het is verstandig niet teveel te koop te lopen met het meetproces. Je vergelijkt personen, afdeling, voorgaande projecten. Formeel of informeel codereview helpt. Gesprekken zijn belangrijk. Regelmatig informeel van gedachten wisselen kan onthullend zijn. Functioneringsgesprekken daarentegen moeten goed georganiseerd worden om het gewenste effect te bereiken. Als een projectleider uitvoerig moet verantwoorden, waarom hij een teamlid minder vindt functioneren, dan zal hij geneigd zijn dit onder de pet te houden. Bij maatregelen naderhand zijn routinematige gesprekken eerder een last dan een lust. Onregelmatigheden zijn een belangrijke indicatie of er iets mis gaat. Bij goedlopende projecten is zelfbeheersing belangrijk. Zolang het goed gaat afblijven. Pas ingrijpen als het mis gaat.
Management is een moeilijk vak. Dat geldt met name voor het aansturen van automatiseringsafdelingen. Je hebt te maken met intelligente mensen. Vaak wat moeilijk in de omgang. Besturen op afstand werkt niet. De aansturing van een dergelijke afdeling er even bij te doen, leeft breed en leidt zelden tot een bevredigend resultaat. Er is geen vervanging mogelijk voor deskundigheid. Twee opties heb je bij het succesvol aansturen van programmeerafdelingen bij een groot bedrijf. Of je zorgt voor aansturing door gekwalificeerde mensen met kennis van zaken en voldoende tijd, of je zorgt voor een hoop ervaring op de programmeerafdeling zelf. Dan stuurt de afdeling zichzelf aan. Dat geeft best eens verrassingen, maar de boel draait tenminste.
