Op het eerste gezicht hebben ‘business process reengineering’ en ‘rapid application development’ weinig met elkaar te maken. Toch beogen beide één doel: organisaties adequaat laten reageren op snel veranderende behoeften in de markt. De concepten hebben belangrijke raakvlakken en vragen veelal om een geïntegreerde aanpak, aldus Jacco de Gooijer en Martin ten Voorde .
Globalisatie en toegenomen concurrentie leiden tot turbulente en snel veranderende omgevingen voor organisaties. Hierop kan men reageren door zich te richten op de kernactiviteiten van de organisatie en door de klanten daadwerkelijk meerwaarde te bieden. Deze aanpak wordt veelal business process redesign of business process reengineering (bpr) genoemd [6,5,3,1]
Voor organisaties is het van belang dat zij hun kwaliteit verbeteren, produktkosten verlagen, innoveren en mogelijkheden benutten. Ze moeten rap kunnen inspelen op nieuwe technologieën en deze sneller kunnen toepassen dan de concurrentie. Daarnaast zijn functionele structuren van een organisatie ondergeschikt aan de essentiële organisatieprocessen. Organisatiestructuren dienen erop gericht te zijn om snel en klantgericht de processen te doorlopen.
Business process reengineering
Indien een radicale verandering van de structuur en de cultuur van een organisatie nodig is, bijvoorbeeld wanneer deze overgaat van een bureaucratische aanpak naar een marktgerichte aanpak, kan bpr een goede oplossing vormen [6]. Ook bij overnames en reorganisaties kan bpr een goede aanpak zijn. Business process reengineering is ontstaan ten gevolge van problemen op vier gebieden binnen organisaties. Deze gebieden en hun belangrijkste problemen zijn:
- de organisatie-omgeving/niet snel kunnen reageren op de veranderende concurrentie;
- de organisatiestructuur/onmogelijkheid om snel veranderingen te kunnen doorvoeren in de organisatie;
- de infrastructuur van de informatiesystemen/inefficiënt en inflexibel;
- de informatietechnologie/veroudering.
Business process reengineering kan organisaties laten breken met het verleden en ervoor zorgen dat organisaties erin slagen om de rentabiliteit en flexibiliteit te vergroten. Het probeert een oplossing te bieden voor de vier gesignaleerde probleemgebieden en onderscheidt zich door de volgende gemeenschappelijke kenmerken of aandachtspunten.
Bpr-projecten zijn complexe en ingrijpende veranderingsprocessen in organisaties. Deze projecten moeten daarom niet alleen aandacht geven aan de structuur en de omgeving van de organisatie, maar ook aan de verandering van de cultuur.
Ze leiden tot organisaties die ingericht worden naar de primaire klant-tot-klant processen. De – vooral op functies gerichte organisatiestructuur – zal moeten worden doorbroken en vervangen door één die meer op processen gericht is. In een traditionele, op functies gerichte structuur gaat de informatie over een groot aantal schijven omhoog en vervolgens over een groot aantal schijven omlaag. In een nieuwe procesgerichte organisatie wordt het werk veelal parallel uitgevoerd en is de informatie direct toegankelijk zonder dat deze over veel schijven hoeft te gaan.
Bpr-projecten dienen zich met name te richten op de processen die van eminent belang zijn om de missie van de organisatie te laten slagen. Door het meten van de procesprestaties in bijvoorbeeld doorlooptijd, kosten en tijd, kan men analyseren welke verbeteringen nodig zijn.
De projecten worden versneld door het gebruik van moderne informatietechnologieën. De techniek is geen belemmering meer bij het goed uitvoeren van deze projecten en zorgt voor de noodzakelijke ondersteuning. De grootste uitdaging is om tijdrovende sequentiële processen te transformeren tot gelijktijdige, parallelle processen met een korte levenscyclus. Een andere uitdaging is het terugdringen van de complexiteit van informatiesystemen. Ook hierbij kan moderne informatietechnologie goed worden ingezet.
Bpr-projecten leiden tot veranderingen in de architectuur van de informatiesystemen. Deze architectuur zal op de herontworpen processen afgestemd moeten worden. Moderne technologieën met verregaande integratie tussen case (computer aided system engineering), 4 GL (generation language) en rdbms (relational data base management system) kunnen hierbij van goede dienst zijn. Met name case-tools kunnen een goede geautomatiseerde aanvulling zijn op de procesmodellering bij bpr-projecten.
Drie fasen bpr
Business process reengineering onderscheidt drie fasen om een organisatie te herontwerpen. Achter iedere fase staat kort aangegeven welke werkzaamheden in een fase worden uitgevoerd:
1. strategie; scope, (technische) infrastructuur en gedetailleerde planning.
2. ontwerp; analyse, voorbeelden, visie en herontwerp.
3. implementatie; implementatie van organisatieprocessen en informatiesystemen die de organisatieprocessen ondersteunen.
Het resultaat van bpr is dat de concurrentie- en marktpositie verbetert door klantgericht te opereren en door het leveren van meer maatwerkprodukten. Ook wordt de aansluiting tussen klanten en produkten geoptimaliseerd, zowel op organisatie- als op procesniveau. De cultuur wordt gericht op de markt of een marktaandeel. Het personeel dient te bestaan uit ondernemers, specialisten en klantspecialisten met produktspecialisaties. Daarnaast wordt in een procesgerichte organisatie steeds meer belang gehecht aan vaardigheden als flexibiliteit, goede contactuele eigenschappen en samenwerking. Na afloop van een bpr-project zal de organisatiestructuur veelal bestaan uit een goede combinatie van deconcentratie/decentralisatie en een centrale coördinatie.
Rapid application development
De wijze waarop systeemontwikkeling de afgelopen decennia heeft plaatsgevonden, heeft tot nogal wat kritiek geleid. Vaak werd en wordt er geconstateerd dat een systeemontwikkelingstraject een te lange doorlooptijd heeft, te veel geld kost en dat het uiteindelijke resultaat achterblijft bij de hooggespannen verwachtingen. In de jaren na oplevering moest men vervolgens diep in de buidel tasten om het systeem te kunnen blijven gebruiken. Meestal was er al zoveel kwaad mee aangericht in de organisatie dat het nooit kwam tot een acceptatie door de gebruiker. Vrijwel iedereen kent wel een aantal voorbeelden die in dit inmiddels tot cliché verheven beeld van de informatietechnologie passen. Een belangrijke reden voor het mislukken van IT-projecten is de aanpak. In de traditionele ontwikkelingsmethodologie worden de fasen strategie, analyse, ontwerp en bouw sequentieel uitgevoerd. In de bouwwereld wordt deze fasering al lang met succes gebruikt. In de informatietechnologie lijkt ze echter niet altijd even goed toepasbaar. Belangrijke redenen hiervoor zijn de omvang en complexiteit van een informatiesysteem, en de communicatie tussen de gebruikers en systeemontwerpers.
Bij het ontwikkelen van een relatief groot en complex informatiesysteem is het moeilijk om het systeem als geheel te beheersen en te overzien. Een eenmaal geaccepteerde mijlpaal (lees: zeer lijvige documenten) betekent dat een volgende fase wordt ingeslagen, waarbij de planning en het budget het niet toelaten om hier nog op terug te komen. Juist bij dergelijke projecten zijn fouten en tekortkomingen meer regel dan uitzondering. De consequenties van een gedane uitspraak of genomen beslissing worden vaak pas overzien op het moment dat gebruikers worden geconfronteerd met de uiteindelijke applicatie.
Geïntegreerde case-tool
De rad-methode concentreert [2,4,8,9] zich veel minder op de strikte indeling van de activiteiten binnen de fasen, maar veel meer op het resultaat. Rad kan worden gezien als een verzameling technieken en hulpmiddelen die in een relatief korte tijd (vergeleken met de traditionele methodologie) een goed gekwalificeerd produkt oplevert. Rad gaat uit van een incrementele systeemontwikkeling: het systeem wordt in delen steeds verder uitgebouwd en leidt uiteindelijk tot het definitieve informatiesysteem. Een onontbeerlijk hulpmiddel bij deze techniek is het gebruik van een geïntegreerde case-tool (i-case), die de systeemontwikkelaars in staat stelt specificaties al op een hoog niveau in te brengen. Generatoren moeten vervolgens de specificaties razendsnel kunnen omzetten in een werkend prototype. Deze speelse wijze van systeemontwikkeling wordt gecombineerd met een strikte tijdsplanning, hetgeen leidt tot een min of meer zelfsturend proces.
Het belangrijkste hulpmiddel bij een rad-project is een i-case-tool, waarmee specificaties gestructureerd kunnen worden opgeslagen. Specifiek voor rad zijn de volgende aspecten met betrekking tot een i-case-tool onontbeerlijk: een centrale repository waarin alle specificaties worden opgeslagen en de mogelijkheden tot: omzetten van specificaties in een werkende applicatie (door middel van een generator); snelle aanpassing van gegenereerde applicaties(door middel van een regenerator); rapportage, gebruik makend van de gegevens in de centrale repository (ER-diagrammen, Dataflow-diagrammen, Functiemodellen); uitvoeren van kwaliteitscontroles (voorbeeld: welke gedefinieerde entiteiten worden door geen enkele systeemfunctie gebruikt); toevoegen van eigen objecten aan de repository (user extensibility/object oriëntatie); versiebeheer; procesmodellering.
Vier fasen van rad-project
Een rad-project kan worden ingedeeld in de volgende vier fasen: projectplanning, applicatie-ontwerp, bouw van de applicatie en implementatie. In de eerste fase – de projectplanning – worden de doelstellingen van de organisatie bepaald, evenals de processen binnen de organisatie en de wijze waarop IT deel uitmaakt van deze processen. De uitvoering van een dergelijke planningsfase wordt in rad-termen ook wel joint requirements planning (jrp) genoemd. Hierbij onderkent men in relatief korte tijd tijdens planningsessies de doelstellingen, relevante bedrijfsprocessen, taken en verantwoordelijkheden. De organisatiedeskundigen die aan deze sessies deelnemen moeten op een hoog niveau binnen de organisatie zijn gesitueerd. Ook de systeemontwikkelaars nemen aan deze sessies deel. Een aantal organisatiedeskundigen, voorzien van de nodige beslissingsbevoegdheid vanuit het management, en de systeemontwikkelaars zullen gedurende het hele project actief blijven deelnemen.
In de tweede fase – het applicatie-ontwerp – worden de onderkende systeemfuncties uit de vorige fasen verder uitgewerkt. Hierbij discussieert men in team-verband tijdens workshops over de gewenste specificaties van de systeemfuncties. In rad-terminologie spreekt men van de techniek joint application design (jad). Een team moet in de juiste verhouding zijn samengesteld uit materiedeskundigen en IT-deskundigen. De materiedeskundigen zijn veelal de eindgebruikers die door hun kennis van specifieke onderdelen van bedrijfsprocessen gedetailleerd kunnen ingaan op de gewenste functionaliteit. Voor het bepalen van die functionaliteiten kan men gebruik maken van prototypen, met name waar het gaat om functionaliteiten die een kritische rol vervullen in een bedrijfsproces. Deze prototypen zullen in de volgende fase verder worden uitgebouwd. Een aantal schermen en rapporten die deel uitmaken van een prototype kunnen bovendien worden gebruikt als discussiestuk voor het bepalen van de gebruikersinterface.
In de voorlaatste fase – de bouw van de applicatie -, zal het informatiesysteem worden gerealiseerd. Eventueel gemaakte prototypen worden verder ontwikkeld. Deze fase heeft een aantal kenmerken die duidelijk het verschil aangeven ten opzichte van de traditionele methode. We vermelden ze hieronder.
Functionaliteiten die zijn bepaald in de voorgaande fasen staan niet vast (incrementele systeemontwikkeling), maar kunnen nog van inhoud veranderen en nieuwe functionaliteiten kunnen worden toegevoegd.
Welke functionaliteiten uiteindelijk gebouwd gaan worden, hangt af van de prioriteitsstelling die is aangebracht en de beschikbare tijd. In dit verband wordt ook wel de techniek time box management toegepast: vaststaande begin- en einddata waarbinnen het systeem ontwikkeld moet worden. Hierbij worden de belangrijkste functionaliteiten als eerste gerealiseerd. Hierbij hanteert men ook wel de zogenaamde MoSCoW-onderverdeling [2], zie figuur 1.
Figuur 1. Het MoSCoW-model.BEGRIP OMSCHRIJVING Must haves Deze onderdelen (bouwstenen) van het informatiesysteem worden altijd gebouwd. Should haves Deze onderdelen van het informatiesysteem zullen worden gebouwd. Als de omstandigheden veranderen kunnen ze eventueel naar de Could haves worden verplaatst. Could haves Deze onderdelen van het informatiesysteem zullen niet worden gebouwd. Bij veranderende omstandigheden kunnen ze naar de Should haves worden verplaatst. Won’t haves Deze onderdelen van het informatiesysteem worden nooit gebouwd.
De rolverdeling binnen de systeemontwikkeling is zodanig dat de eindgebruikers bepalen welke functionaliteiten prioriteit krijgen om in het systeem te worden opgenomen. Systeemontwikkelaars vertalen de wensen van de eindgebruikers in de case-tool en genereren vervolgens bepaalde delen van het systeem.
Analyse en bouw vinden door elkaar plaats en het systeem wordt in verschillende iteratie-slagen voltooid. In eerste instantie zullen de te bouwen functionaliteiten volledig worden gegenereerd. Pas tegen het einde van de bouwfase zullen de eventueel niet genereerbare functionaliteiten handmatig worden geprogrammeerd. Het aantal wijzigingen zal per iteratie-slag afnemen naarmate het aantal iteraties toeneemt.
De wijze van implementatie – fase vier – is niet fundamenteel anders dan bij de traditionele methode. Wel zal ze veel eenvoudiger zijn doordat het systeem als het ware door de organisatie zelf is gebouwd en door haar wordt gedragen. De gebruikers die actief aan het rad-project hebben deelgenomen (vaak de key-users) zullen het systeem volledig in de vingers hebben en kunnen overdragen aan collega’s. Hierdoor zal de tijd, benodigd voor de acceptatie van het systeem, afnemen.
Mislukkingen
Ondanks de vele mogelijkheden van business process reengineering mislukken veel projecten [5]. Een groot aantal oorzaken is hiervoor aan te voeren, maar de drie belangrijkste zijn: het begeleidingsproces, het te laat toepassen van moderne informatietechnologie en de lange doorlooptijd. Bpr-projecten zijn erg ingrijpend, en dienen dus goed te worden begeleid. Zoals ieder veranderingsproces ondervinden ook bpr-projecten veel tegenstand. Het is van belang om daarbij goed rekening te houden met de cultuur van een organisatie en met de hiermee samenhangende menselijke aspecten. Deze worden vaak onderschat, hetgeen vaak leidt tot het mislukken van bpr-projecten. Een andere oorzaak is het te laat toepassen van moderne informatietechnologieën. Bpr-projecten dienen zowel de organisatie- als de informatiestructuur goed en gelijktijdig te onderzoeken. Het afronden van een bpr-traject met verouderde informatietechnologieën kost veelal aanzienlijk meer inspanning dan met nieuwe informatietechnologieën. Na afloop van het bpr-traject kan men dan opnieuw beginnen met het herdefiniëren van de beschikbare informatiesystemen. Een laatste belangrijke oorzaak van het mislukken van business process reengineering is de volgende. Hoewel bpr bedoeld is om snel en efficiënt te reageren op veranderingen in de markt, neemt ze daarentegen zelf vaak veel tijd in beslag. Het gevolg is dat, wanneer men een nieuw proces implementeert, deze al gelijk achterhaald is. Een grote vertragende factor is de invoering van het informatiesysteem dat bij het nieuwe proces behoort.
Een goede manier om de doorlooptijd van een bpr-project te verkorten is het toepassen van rad-methoden en technieken in combinatie met een moderne ontwikkelomgeving.
Ook bij rad-projecten komen mislukkingen voor. Een belangrijke reden is het feit dat een gedegen proces- en/of organisatie-analyse ontbreekt. Daardoor evolueert alleen de automatiseringskant door rad, maar sluiten de informatiesystemen niet beter aan op de organisatie. Een goede manier om dat op te lossen is het toepassen van bpr in een rad-project.
Business process redesign en rapid application development vullen elkaar dus op een aantal manieren aan. In de eerste plaats definieert een bpr-project in de strategiefase een groot aantal initiatieven waarvan een aantal geschikt zijn voor het toepassen van rad-projecten. Daarnaast kunnen rad-technieken worden toegepast om in de eerste fasen van een bpr-project te testen of de voorgestelde veranderingen in de informatiesystemen ook de beoogde veranderingen zijn.
Gebruik resultaten bpr
De volgende resultaten van een bpr-project zijn zeer geschikt voor een succesvol verloop van een rad-traject.
Vastgestelde organisatiedoelen en prioriteiten; hiermee kunnen ook binnen het rad-traject de juiste doelen en prioriteiten worden vastgesteld.
Opgestelde procesbeschrijvingen; de procesbeschrijvingen uit het bpr-project zijn binnen een rad-traject goed te gebruiken om systeemvereisten vast te stellen.
Opgestelde organisatiestructuur; aan de hand van de ‘ge-redesignde’ organisatie kan de integratie tussen de informatiesystemen worden vastgesteld.
Afgezien van de bedrijfsspecifieke wensen en eisen – de resultaten van een bpr-project – die er aan informatiesystemen gesteld worden, is er vaak een grote functionele gelijkheid tussen de informatiesystemen van verschillende organisaties in dezelfde branche. Door eenmalig de gemeenschappelijke elementen en functies te definiëren en te programmeren, en vervolgens aan te passen en aan te vullen aan de specifieke wensen, voorkomt men dat het wiel steeds opnieuw uitgevonden moet worden. Uiteraard dienen deze zogenaamde templates binnen een i-case-tool beschikbaar te zijn. Figuur 2 vat de karakteristieken van de maatwerk-benadering, de standaardpakket-benadering en de ’template’-benadering van informatiesysteemontwikkeling samen [7].
Figuur 2. Alternatieven voor informatiesysteemontwikkeling.
| ALTERNATIEF | KARAKTERISTIEKEN ALTERNATIEF |
| Maatwerk | – helemaal op de organisatie afgestemd (maatwerk)
|
| Standaardpakket | – redelijk op de organisatie afgestemd (standaard) |
| Template | – helemaal op de organisatie afgestemd |
Door het toepassen van templates kan men al in een vroegtijdig stadium in een bpr/rad-project gebruik maken van prototypes, waarbij niet of nauwelijks geprogrammeerd hoeft te worden. Indien gebruik wordt gemaakt van templates, kan in een bpr/rad-project een verschillen-analyse plaatsvinden waardoor de bedrijfsspecifieke eisen en wensen worden toegevoegd aan de ingebrachte standaard functionaliteiten. Het uiteindelijke doel is dat de standaard templates zodanig worden aangepast en aangevuld dat het model als geheel wordt geaccepteerd door de organisatie, en dat de templates evolueren tot maatwerk zonder de hoge kosten en lange doorlooptijd. Dit doel zal in de fase van applicatiebouw volledig moeten worden gerealiseerd.
Voordelen en strategieën
Een aantal voordelen zijn onderkend bij het toepassen van rad-projecten, geïntegreerd met bpr-projecten. Deze voordelen betreffen organisatie, prototypes en betrokkenheid.
Organisaties kunnen zich sneller aanpassen aan de nieuwe organisatieprocessen omdat de veranderingen in de informatiesystemen snel gereed zijn. Prototypes kunnen gebruikt worden om te testen of de voorgestelde informatiesystemen overeenkomen met voorgestelde organisatieveranderingen. De betrokkenheid van de teamleden blijft constant op een hoog peil doordat rad-trajecten een kortere tijd in beslag nemen dan traditionele systeemontwikkelingstrajecten.
Ook is uit de praktijk een aantal succesvolle strategieën voor de toepassing van bpr en rad naar voren gekomen. We noemen de belangrijkste.
Het starten van een pilot-project helpt om vertrouwen op te bouwen.
Deelnemers aan een bpr/rad-project moeten voldoende training hebben gehad in de te gebruiken methoden, technieken en hulpmiddelen waarmee zij gedurende het project geconfronteerd zullen worden.
Er dient veel terugkoppeling naar het personeel plaats te hebben om samenwerking te bevorderen en de natuurlijke tegenstand tegen de veranderingen te verkleinen.
Een goede samenstelling van het bpr/rad-team is van belang. Hierin dienen ook de menselijke aspecten van verandering een belangrijke rol te krijgen.
Het project moet een dusdanige inhoud hebben dat veel functionaliteiten vanuit een i-case tool gegenereerd kunnen worden.
Vanuit de organisatie moet een deelnemer worden aangewezen die de bevoegdheid heeft en in staat is om snel belangrijke beslissingen te nemen gedurende het project; hiermee wordt vermeden dat tijdrovende beslissingsprocedures het project vertragen. Een dergelijk persoon is cruciaal voor het slagen van het project en wordt soms aangeduid met de term executive sponsor of executive owner.
Direct doorstromen naar rad
De praktijk kent een groot aantal al dan niet geslaagde projecten van zowel bpr als rad afzonderlijk. Er zijn daarentegen nog weinig organisaties die bpr en rad als combinatie in projecten hebben toegepast. Concreet worden met een bpr/rad-aanpak de volgende resultaten bereikt.
Projectorganisatie van bpr maakt direct doorstomen naar rad (jrp/jad sessies) mogelijk. Door de grote aandacht voor proces-optimalisatie tijdens bpr kunnen rad-projecten voor ondersteunende informatiesystemen makkelijker en efficiënter worden geïdentificeerd en opgestart. Tenslotte bouwt rad de nieuw benodigde informatiesystemen in de gewenste tijd.
Drs J. de Gooijer (jgooijer@nl.oracle.com) is werkzaam als business unit lid Banken en Verzekeringen en drs M. ten Voorde (mvoorde@nl.oracle.com) als consultant bij Oracle Consulting Services.
Literatuur
1. Buitelaar, M. en U. Groen (1994), ‘Business Process Redesign, een nieuwe kijk op Informatisering ?’, Informatie, jaargang 36, nr. 6
2. Clegg, D. en R. Barker (1994)Case Method Fast-track, a rad Approach, Oracle Case series, Redwood
3. Davenport, T.H. (1993), Process innovation: Reengineering work through information technology, Harvard Business School Press, Cambridge
4. Gooijer, J. de en M. ten Voorde (1995), ‘Rapid Application Development; Systeemontwikkelingsveranderingen’, NGI-magazine, Jaargang 10, juli/augustus
5. Hammer, M. en J. Champy (1993), Reengineering the corporation – A manifesto for business revolution, Harper Business, New York
6. Oracle Consulting Services (1994), ‘Business Process Re-engineering: The Oracle perspective, Integrating technology with Business Process Re-engineering methodologies to produce superior business solutions’, Oracle, Redwood
7. Vann-Adibe, R. (1993), ‘Oracle Industries, The jumpstart system development approach’, Oracle Consulting Services, Redwood
8. Voorde (1995), ‘Hergebruik vermindert kosten; templates, Bouwstenen en ‘rad’ moeten ‘confectie’ voorkomen’, Computable, Jaargang 28, 20 oktober 1995
9. Zee, H.T.M. van der (1994), ‘Versneld ontwikkelen met Rapid Application Development’, Informatie, jaargang 36, nr. 1
