Invoering van een rad-pilot leidt nogal eens tot weerstand bij automatiseringsdeskundigen. Dit is veelal het gevolg van onbekendheid met de methode en angst voor het feit dat in een project hun rol verandert. Voorlichting, training en een open sfeer kunnen bijdragen aan een succesvolle introductie van rapid application development, zo betoogt senior consultant Rob Stroober in dit eerste artikel uit een serie van drie.
Rapid application development (rad) is een aanpak voor systeemontwikkeling die drie doelen nastreeft: een kortere doorlooptijd van ontwikkeltrajecten, lagere kosten en verbetering van de kwaliteit van informatiesystemen. Bij het implementeren van rad in een organisatie zijn zes fasen te onderkennen.
Ontkenning. Allereerst zullen de mogelijkheden van rad worden ontkend. Men vindt het een hype en wil er niet aan beginnen. Verkenning. Nu steeds meer verhalen over succesvol gebruik van rad in de vakbladen verschijnen, ontstaat de behoefte om er meer over te weten te komen. In dit stadium wordt op basis van evaluaties en aanvullende pilots getracht het nut van het gebruik van deze ontwikkelmethode te onderzoeken.
Vervanging. Wanneer uit het onderzoek naar voren komt dat het gebruik van rad als systeemontwikkelmethode duidelijke voordelen heeft, zal de beslissing tot invoering worden genomen. In delen van de systeemontwikkel-organisatie wordt rad ingezet ter vervanging van de oude wijze van werken.
Integratie. Het vervangingsstadium kenmerkt zich door de geïsoleerde toepassing van rad in verschillende delen van de onderneming, veelal op verschillende wijzen. In het integratiestadium worden deze eilanden geïntegreerd tot één geheel.
Transformatie. Tot nu toe is alleen de ene systeemontwikkelmethode vervangen door een andere. De organisatie van de systeemontwikkeling is nog de oude gebleven. In het transformatiestadium worden ook de systeemontwikkel-organisatie en gebruikersorganisatie anders ingericht, zodat de voordelen van rad optimaal kunnen worden benut.
Transparantie. In het laatste stadium is rad gemeengoed geworden. Iedereen maakt er bewust (en onbewust) gebruik van op de daarvoor geschikte momenten.
Bij de uitvoering van pilots denken veel managers dat hun organisatie zich al in de verkenningsfase of zelfs verder bevindt. Uit de weerstanden die ik bij de begeleiding van rad-pilots ontmoet, moet ik helaas concluderen dat veel automatiseringsdeskundigen in dezelfde organisatie zich vaak nog in de ontkenningsfase bevinden. Een veranderende organisatie dient goed rekening te houden met de oorzaken van de opgeworpen weerstanden van automatiseringsdeskundigen, omdat zij een gevaar vormen voor de pilot waarin de nieuwe methode wordt verkend.
Weerstanden
Gezien de mondigheid van de gebruikers vinden wij het ronduit verrassend dat de kreet ‘wij weten wat goed is voor onze gebruiker’ nog steeds openlijk wordt geuit. Deze gedachte is vaker verscholen achter opmerkingen als ‘onze gebruikers hebben geen tijd of zijn niet slim genoeg’. Daarbij vergeet men echter dat er voor het goed beoordelen van de stapels documenten uit het klassieke ontwikkeltraject ook veel tijd nodig is en dat de gebruiker de hiervoor noodzakelijk kennis niet bezit. Door de workshops in het rad-traject zeer gestructureerd te laten verlopen, kan heel efficiënt gebruik worden gemaakt van de tijd van de gebruikers. Juist door het presenteren van prototypes in het rad-traject is de deskundigheid van de gebruikers optimaal te benutten. Overigens moet men zich serieus afvragen of de gebruikersorganisatie het nieuwe systeem echt wel wil hebben, als zij geen of onvoldoende mankracht beschikbaar stelt.
De opvallendste opmerking die ik ooit ben tegengekomen is dat de gebruikers volgens de automatiseringsdeskundigen al tevreden zijn over de huidige manier van werken. Een door ons uitgevoerde tevredenheidsmeting bewees in dit geval echter het tegendeel.
Sommige ontwikkelaars zeggen dat ze al aan prototyping doen en dus al rad toepassen. Rad is echter veel meer dan prototyping alleen: het is een gestructureerde totaal-aanpak waarin budgetverantwoordelijkheid, participatie van gebruikers en geïntegreerde case-tools de sleutelelementen vormen.
Nog niet zo lang geleden dacht men dat rad alleen maar werkt als de gebruikers exact kunnen aangeven wat ze willen. Ik denk dat in dat (overigens uitzonderlijke) geval iedere methode werkt. Door de confrontaties met prototypes kunnen de gebruikers zich juist een beeld vormen van het op te leveren systeem, zo is onze ervaring. Dit is bijzonder waardevol in situaties waarin de gebruiker niet exact kan aangeven wat hij wenst.
Sommige systeemontwikkel-organisaties passen andere elementen van de rad-methode – zoals bijvoorbeeld workshops – in een systeemontwikkeltraject met behulp van systems development methodology (sdm) toe en beweren daarmee de voordelen van rad te behalen. Men dient daarbij te bedenken dat wel elementen van rad naar sdm worden overgehaald, maar dat de voordelen van rad als geïntegreerde systeemontwikkelmethode niet gerealiseerd zullen worden.
Daarnaast is er een groot aantal automatiseringsdeskundigen dat denkt dat rad alleen maar geschikt is voor interactieve programmatuur. Dit is een misverstand: rad werkt minder goed voor (delen van) systemen die niet door de gebruiker aan de buitenkant te beoordelen zijn. De werking van veel batch-programmatuur – als tegenhanger van interactieve programmatuur – is echter vaak aan de buitenkant te beoordelen in de vorm van formulieren of gewijzigde gegevens.
Aansluiten bij organisatie
Vaak doen zich situaties voor waarin een functioneel ontwerp is goedgekeurd en waar men de realisatie-fase wil ingaan. Daarbij denkt men vaak tijdwinst te kunnen behalen door gebruik te maken van ontwikkelhulpmiddelen die zichzelf van het predikaat rad hebben voorzien. Eén van de voordelen van rapid application development is juist dat het ontwerp intensief door de gebruikers wordt beoordeeld met behulp van prototypes. Met deze zogenaamde rad-tools is het weliswaar mogelijk om zeer snel fraaie systemen te bouwen. Zonder toepassing van de rad-methode bestaat echter nog steeds het gevaar dat het systeem niet aansluit bij de gebruikersorganisatie. In een dergelijke situatie is het dan ook zinvol om elementen van het ontwerp in een kort rad-traject te toetsen.
Veel organisaties kiezen ervoor om een pakket aan te schaffen in plaats van zelf systemen te ontwikkelen. Het feit dat het systeem niet zelf wordt ontwikkeld, dragen zij vaak aan als reden om rad niet toe te passen. Bedenk echter dat de software moet worden ingericht of aangepast aan de specifieke kenmerken van de organisatie. Vanuit het oogpunt van projectmanagement kiest men er dan vaak voor om de noodzakelijke aanpassingen in een document te beschrijven en te toetsen. Ook bij het inrichten van een pakket loopt men dan weer het gevaar dat het uiteindelijke systeem niet aansluit bij de organisatie. Het is zinvol om ook hier elementen van rad te introduceren. Men kan er bijvoorbeeld voor kiezen om de software met behulp van prototyping in te richten. In sommige standaard-pakketten, zoals SAP-HR, kan het gegevensmodel zelfs worden aangevuld en heeft de gebruiker invoerfuncties beschikbaar op het aangevulde gegevensmodel. Het zal duidelijk zijn dat rad ook voor de inrichting van standaard-software mogelijkheden biedt.
Grote complexe systemen hebben de naam dat zij niet gerealiseerd kunnen worden met behulp van rad. De omvang van het systeem wordt dan ook vaak gebruikt als argument om rad niet toe te passen. Dergelijke systemen worden echter vaak opgedeeld in deelsystemen, waarop men rad zou kunnen toepassen. Het spreekt voor zich dat de afstemming over de deelsystemen heen moet worden bewaakt. Natuurlijk is er vanuit het oogpunt van projectmanagement in de praktijk een maximum aantal deelsystemen dat tegelijkertijd ontwikkeld kan worden. Deze problematiek is vergelijkbaar met de problemen in overeenkomstige sdm-projecten. Grote complexe ondeelbare systeem kunnen waarschijnlijk niet met behulp van rad worden ontwikkeld. Overigens kan men zich afvragen of dit soort systemen überhaupt gerealiseerd moeten worden.
Oorzaak van weerstanden
Veel organisaties plannen op dit moment pilots om kennis te maken met rad. Daarbij wordt in het algemeen wel nagedacht of de voorwaarden zijn vervuld waaraan moet worden voldaan om rad te kunnen toepassen. Het voorgaande laat zien dat men ook rekening moet houden met weerstanden van mensen. Om deze weerstanden te kunnen overwinnen, is het goed om te weten wat de oorzaken daarvan kunnen zijn.
Aan de basis van enkele geconstateerde weerstanden ligt het feit dat een deel van de automatiseringsdeskundigen denkt op functioneel gebied meer te weten dan de gebruiker zelf. Uiteraard komt het voor dat automatiseringsdeskundigen veel kennis hebben over bepaalde functionaliteit. Uit de constatering dat de gebruiker de weerslag van de functionaliteit in de ontwerpen niet kan doorgronden, mag echter niet de conclusie worden getrokken dat hij minder weet van de functionaliteit dan zij.
Maar hoewel de rol van gebruikers bij rad groot is, hebben zij het niet alleen voor het zeggen. Het team – bestaande uit automatiseringsdeskundigen en gebruikers – is samen verantwoordelijk voor het eindresultaat. De grote rol van de gebruikers betekent dus ook niet dat de automatiseringsdeskundige niet de verantwoordelijkheid heeft om creatief en kritisch met de gebruiker mee te denken. Hij moet er echter voor waken om op de plaats van de gebruiker te gaan zitten. Wel zal hij moeten luisteren: een vaardigheid die bij veel automatiseringsdeskundigen verder ontwikkeld zal moeten worden.
Met rapid application development worden de automatiseringsdeskundigen niet meer op het voetstuk geplaatst waarop zij in veel organisaties staan. Managers realiseerden zich al veel langer dat automatisering geen ivoren toren is. Automatiseringsdeskundigen doen echter vaak of die toren nog bestaat. Rad is in dergelijke gevallen inderdaad een serieuze bedreiging van de verworven positie. Het management kan rad gebruiken om de ivoren toren in sneltreinvaart af te breken. Wellicht heiligt het doel de middelen, maar het zal duidelijk zijn dat ivoren torens een pilot behoorlijk kunnen frustreren.
Daarnaast hebben sommige automatiseringsdeskundigen liever niet dat de gebruikers in de ‘automatiseringskeuken’ kunnen kijken. Op zich is het een juiste constatering dat de gebruiker bij de toepassing van rad beter inzicht krijgt in de tijdsbesteding van de automatiseringsdeskundigen. Het verdient aanbeveling om de automatiseringsdeskundige erop te wijzen dat zij eigenlijk niets te verbergen hebben en dat de gebruiker hem met behulp van het time-box-mechanisme helpt om zijn tijd zo effectief mogelijk te besteden.
Wanneer de automatiseringsafdeling liever niet heeft dat de gebruiker meekijkt in haar keuken, wordt dat wellicht veroorzaakt door het feit dat zij zelf weten dat zij niet optimaal functioneren. Als dat het geval is, zal het management passende maatregelen moeten nemen. Anders bestaat het gevaar dat de mondig geworden gebruiker op zoek gaat naar een andere automatiseringspartner.
Rad-training
Een deel van de bezwaren is te herleiden tot gebrek aan kennis over de methode en onderschatting van de mogelijkheden. Het is verleidelijk om het gebrek aan kennis te compenseren door alle automatiseringsdeskundigen naar een rad-training te sturen. Het gevaar bestaat echter dat er na de training niets wordt gedaan om de methode echt te implementeren. De ervaring leert dat het veel zinvoller is alleen die personen een rad-training te laten volgen die bij een pilot zijn betrokken. De overige personen uit de systeemontwikkel-organisatie kunnen dan globaal over rad worden voorgelicht. Tijdens en na de pilot zullen zij op de hoogte worden gehouden van de ervaringen. Dat kan met behulp van een bulletin; meestal zijn die saai en vertellen zij alleen maar een successtory. Het is daarom zaak om ook de minder positieve ervaringen te vermelden. Juist van dat soort zaken leert de organisatie het meest en ontstaat er een reëel beeld van rapid application development.
Drs Rob Stroober is senior rad-consultant bij Consultdata.
In het tweede artikel van deze serie over rapid application development laat de auteur zien dat prototyping met rad niet ‘quick and dirty’ is. Het derde en laatste artikel gaat in op het nut van workshops.
