Workflowmanagement in een op services georiënteerde IT architectuur

Workflowmanagement in een op services georiënteerde IT architectuur

Afstudeeronderzoek gehouden bij TNO informatie –en communicatietechnologie te Groningen ten behoeve van de studie Technische bedrijfswetenschappen aan de Rijksuniversiteit te Groningen

F.R. Rijpma

Groningen, oktober 2005

Begeleiding RuG

Eerste begeleider: W.M.C. van Wezel Tweede begeleider: D.J. Schaap

Begeleiding TNO ICT

Eerste begeleider: H. Ensing Tweede begeleider: M.J. Konsman

De auteur is verantwoordelijk voor de inhoud van het afstudeerverslag; het auteursrecht van het afstudeerverslag berust bij de auteur.

Voorwoord

Nu, na zeven maanden gestage voortgang, is het moment daar, om het onderzoek af te ronden. Deze maanden waren in meerdere opzichten leerzaam en interessant. Ik kan echter vooral terugkijken op een erg leuke periode. Als je een half jaar stage hebt gelopen maar het aanvoelt alsof je net begonnen bent, dan kun je niet anders concluderen dan dat de tijd gevlogen heeft.

Voor het verloop van mijn afstudeerperiode ben ik veel mensen dankbaar maar met name mijn beide begeleiders bij TNO ICT. Dit zijn Henk Ensing en Mente Konsman. Bedankt voor jullie geboden inzichten, inzet en bovenal de prettige samenwerking. Dit heeft mijn onderzoek zeker op een hoger niveau gebracht en mijn tijd bij TNO ICT tot een goede herinnering gemaakt!

Naast de genoemde begeleiding bij TNO ICT, is mijn afstudeeronderzoek vanuit de RuG begeleid door de heren Wout van Wezel (zelfs tijdens zijn vakantie!) en Dick Schaap. Hun inzichten en de daaruit volgende aanwijzingen, hebben me enorm geholpen. Zonder deze input was het onderzoek wellicht nog steeds een overenthousiaste samenstelling van interessante onderzoeksterreinen gebleven. Hartelijk dank voor de kritische blik en de prettige samenwerking!

Verder heb ik een aantal keer interviews mogen afnemen bij personen uit verschillende organisaties. In dit verband gaat mijn dank uit voor de geboden expertise naar de heren Huub Montanus (Atos Origin), Zwier Zoet (Pallas Athena) en Arnold Zijlstra (Bestuurlijke Informatie Voorziening – RuG). Jullie hebben me geweldig geholpen!

Groningen, oktober 2005

Frits Rijpma

3

Samenvatting

Voor u ligt een onderzoek dat uitgevoerd is in opdracht van TNO ICT te Groningen. De doelstelling van dit onderzoek luidt als volgt:

Om deze ontwikkelingen in informatietechnische architecturen in kaart te brengen, is begonnen met een overkoepelende weergave van alle ontwikkelingen op het gebied van informatietechnische architecturen. Daaruit zijn een tweetal ontwikkelingen naar voren gekomen welke voor TNO ICT een veelbelovend perspectief bieden. Dit zijn Service Oriented Architectures (SOA) en Case Handling (CH). Op basis van deze concepten is de vraagstelling van het onderzoek als volgt vastgesteld:

Een SOA biedt de mogelijkheid om functies in applicaties te ontsluiten door hiervoor services te definiëren en deze beschikbaar te stellen voor de gehele organisatie en indien gewenst voor externe partijen. Om deze services beschikbaar te stellen, moet een generiek platform opgezet worden, waardoor de verschillende applicatieplatformen met elkaar kunnen communiceren. Dit generieke platform wordt een servicebus genoemd en is gebaseerd op standaarden zoals XML en SOAP. Om daarnaast het hergebruik van services in de hand te werken, kan een serviceregister worden bijgehouden. Hierin worden alle gedefinieerde services opgenomen zodat inzichtelijk is, welke functies beschikbaar zijn.

Over het algemeen kan gesteld worden dat SOA hergebruik in de hand werkt doordat het programmeurs dwingt buiten de kaders van specifieke projecten te denken. Het opstellen van deze generieke services zal echter wel behoorlijke investeringen vergen en alleen dan lonend zijn indien hergebruik van services te verwachten is.

Het CH concept geeft invulling aan de beheersing van een workflow, wat een ander niveau van een organisatiearchitectuur is dan een SOA. Doordat dit ontwikkelingen zijn op verschillende niveaus van een organisatiearchitectuur, is onderzocht in hoeverre ontwikkelingen in workflowbeheersing op basis van CH, gevolgen heeft en/of mogelijkheden biedt wanneer de onderliggende architectuur vormgegeven is door een SOA. Om hierbij tot een goede analyse te komen, is workflowmanagement (WFM) ter vergelijking naast CH bestudeerd.

Uit de bespreking van CH en WFM is duidelijk geworden dat beide concepten gericht zijn op ondersteuning van verschillende soorten bedrijfsprocessen. WFM biedt meer efficiëntie in bedrijfsprocessen waar de nadruk ligt op het gestructureerd afhandelen van gelijksoortige cases. Een CH systeem biedt daarentegen een meer flexibelere invulling aan kennisintensieve (en dus vaak ongestructureerde) bedrijfsprocessen.

Biedt nu de combinatie tussen WFM of CH een verschil in flexibiliteit, wanneer deze gecombineerd worden met een SOA? Hiertoe zijn een aantal kenmerken van flexibiliteit opgesteld. Dit zijn de volgende:

• De snelheid waarmee een bedrijfsproces aangepast kan worden aan de veranderde omgeving.

• De kosten die een aanpassing van een bedrijfsproces met zich meebrengt.

In hoeverre biedt case handling meer flexibiliteit dan workflowmanagement in de beheersing van een workflow, wanneer de systeemarchitectuur ingericht is volgens een Service Oriented Architecture?

Het weergeven van, voor TNO ICT relevante ontwikkelingen, in informatietechnische architecturen en op basis daarvan praktische en theoretische aanbevelingen aan TNO ICT te doen.

• De mate waarin met uitzonderingen op de (standaard) procesdefinitie omgegaan kan worden.

• De bereidheid van het personeel om zich een nieuwe werkwijze eigen te maken.

Op basis van deze kenmerken is geconcludeerd dat de combinatie van WFM of CH gekoppeld aan een SOA geen toegenomen flexibiliteit biedt, boven de flexibiliteit die reeds door de afzonderlijke concepten worden geboden. De som is dus niet meer dan de delen.

Dit wordt met name veroorzaakt door de strikte koppelingen tussen de workflowbeheersing en de services. Hierdoor biedt het gebruik van services geen voordeel boven het gebruik van de standaard applicaties.

Als laatste stap in het onderzoek is de bovengenoemde strikte koppeling getracht te ondervangen, door intelligent agents toe te voegen tussen de workflowbeheersing en de SOA.

Een intelligent agent is een autonoom opererende software entiteit, die binnen een domein op eigen initiatief een probleem kan oplossen. Aangetoond is dat door de opkomst van services, door het toegenomen aantal functies dat beschikbaar is, de intelligent agents beter kunnen functioneren. Daarnaast kunnen agents in een workflow aan dataobjecten invulling geven, waardoor agents een ontkoppeling van functies en data kunnen realiseren.

Hierbij maakt echter het onderscheid tussen WFM en CH weinig verschil, waardoor de afweging tussen flexibiliteit en efficiëntie blijft bestaan.

Een keerzijde van het inzetten van agents is, dat er een behoorlijke inspanning vereist is om de intelligentie te trainen en dat daarnaast de aangedragen oplossing van een agent vaak alsnog gecontroleerd dienen te worden.

5

Inhoudsopgave

1 Inleiding ...7

1.1 Leeswijzer ...7

1.2 Context van het onderzoek ...7

1.3 Achtergrond van het onderzoek...9

2 Ontwikkelingen in IT architecturen...10

2.1 Inleiding... 10

2.2 Achtergronden van bedrijfsprocessen... 10

2.3 Concluderend... 17

3 Probleemstelling ...19

3.1 Inleiding... 19

3.2 Aanleiding tot het onderzoek ... 19

3.3 Doelstelling... 19

3.4 Vraagstelling... 19

3.5 Deelvragen... 20

3.6 Afbakening ... 21

3.7 Conceptueel model ... 21

3.8 Methodologie ... 22

4 Organisatiearchitectuur ...24

4.1 Inleiding... 24

4.2 Organisatiearchitectuur raamwerk ... 24

4.3 Bedrijfsprocessen in een waardeketen... 25

4.4 Functiemodel ... 26

4.5 De structuur van een bedrijfsproces... 27

4.6 Proces Architectuur Model ... 28

4.7 Voorbeeld: Autoschade verzekering ... 30

5 Service Oriented Architectures...34

5.1 Inleiding... 34

5.2 Wat is een Service Oriented Architecture? ... 34

5.3 webservices... 38

5.4 Bespreking SOA ... 40

5.5 Services in de autoschadeclaim ... 41

5.6 Aanbevelingen ... 42

5.7 Conclusie... 43

6 Workflowmanagement en case handling...44

6.1 Inleiding... 44

6.2 Wat is workflowmanagement?... 44

6.3 Case Handling... 48

6.4 Grafische weergave van beide workflow modellen... 50

6.5 Technische bespreking case handling ... 52

6.6 CH in de autoschadeclaim... 55

6.7 Aanbevelingen ... 58

6.8 Conclusie... 60

7 Resultaten...62

7.1 Inleiding... 62

7.2 WFM en SOA... 62

7.3 Bespreking CH en SOA ... 63

7.4 Intelligent agents ... 65

7.5 Hoe werken agents? ... 66

7.6 Voorgesteld systeem... 68

7.7 Agents en workflow ... 69

7.8 Autoschadeclaim ... 70

7.9 Flexibiliteit... 73

7.10 Aanbevelingen ... 76

7.11 Conclusie... 76

8 Conclusies en aanbevelingen ...77

8.1 Inleiding... 77

8.2 Conclusie... 77

8.3 Kansen voor TNO ICT... 77

8.4 Aanbevelingen voor TNO ICT ... 78

8.5 Onderzoeksevaluatie... 78

Literatuurlijst ...80 Bijlage 1 – Begrippenlijst ...Error! Bookmark not defined.

7

1 Inleiding

1.1 Leeswijzer

Het onderzoeksterrein dat in dit onderzoek beschouwd wordt, is zeer breed te noemen. Om een kader te bieden waarom keuzes qua focus gemaakt worden, zal begonnen worden met het bespreken van de achtergronden van het onderzoek. Hierbij zal weergegeven worden wat de verwachtingen en voorwaarden zijn, die vanuit TNO ICT aan het onderzoek gesteld zijn. Daaropvolgend zal in hoofdstuk 2 het onderzoeksterrein besproken worden waarbinnen het onderzoek plaats vindt.

In dit afstudeeronderzoek komen zeer veel begrippen voor. Een aantal begrippen zal direct worden toegelicht in de tekst, maar voor de leesbaarheid en overzichtelijkheid van het onderzoek komt dit niet altijd ten goede. Daarnaast is het vaak veel geblader om begrippen die wel direct in de tekst zijn gedefinieerd terug te vinden. Om die redenen is in bijlage 1 een lijst opgenomen met de definities van de belangrijke begrippen.

Daarnaast zal bij het gebruik van ‘internationale’ begrippen, gekozen worden voor de meest gangbare vorm. Dit betekent dat er gekozen wordt voor Engelse begrippen, wanneer deze meer algemeen aanvaard zijn dan de Nederlandse variant.

Zoals aangegeven worden in hoofdstuk 2 de ontwikkelingen en achtergronden van informatietechnische organisatiearchitecturen weergegeven. Voor de lezers die bekend zijn met de begrippen service oriented architectures, Enterprise Application Integration (EAI) en workflow, is de bespreking hiervan wellicht ten overvloede en kan dus eventueel overgeslagen worden. De conclusie van het onderzoek is echter wel van belang. Deze vormt namelijk de input voor de probleemstelling en daardoor eveneens de input voor het verdere onderzoek.

1.2 Context van het onderzoek

Dit onderzoek wordt uitgevoerd in het kader van de studie Technische Bedrijfswetenschappen (afstudeerrichting Informatie Technologie) aan de Rijksuniversiteit te Groningen. Als afsluitend onderdeel van deze studie dient een onderzoek uitgevoerd te worden, waarbij het zelfstandig oplossen van een wetenschappelijk vraagstuk centraal staat. Over het algemeen worden bedrijven benaderd om studenten van een dergelijk vraagstuk te voorzien. Dit niet in de laatste plaats om als student praktijkervaring op te kunnen doen. Voor deze afstudeeropdracht is TNO bereid gevonden een vraagstuk aan te leveren.

1.2.1 TNO

De Nederlandse organisatie voor Toegepast Natuurwetenschappelijk Onderzoek (TNO) is in 1932 opgericht om onderzoek toepasbaar te maken voor bedrijven en overheden. TNO heeft een onafhankelijke positie waardoor objectieve en wetenschappelijk gefundeerde oordelen kunnen worden geleverd. TNO heeft de missie bij te dragen aan de concurrentiekracht van bedrijven en organisaties, aan de economie en aan de kwaliteit van onze maatschappij als geheel.

Het bedrijf is een zelfstandige instelling met onder meer een eigen financieel beleid, personeelsbeleid en commercieel beleid. TNO heeft wel een, bij wet vastgelegde, relatie met de Nederlandse (centrale) overheid en vervult zodoende een aantal maatschappelijke taken, zoals bijvoorbeeld het leveren van keurmerken. Onder andere om deze reden

ontvangt het bedrijf een overheidsfinanciering. Deze bedraagt circa 30% van de totale omzet.

TNO is een kennisorganisatie voor bedrijven en overheden en telt ongeveer 5000 medewerkers. Centraal staat de brugfunctie tussen de wetenschap en het bedrijfsleven. De doelstelling van TNO is om door middel van het opbouwen en toepasbaar maken van kennis, het innoverend vermogen van het bedrijfsleven en de overheid te bevorderen.

Als organisatie is TNO opgedeeld in vijf kerngebieden waarbinnen alle verschillende activiteiten van TNO opgedeeld zijn. Deze vijf kerngebieden zijn:

• Kwaliteit van leven

• Defensie en veiligheid

• Industrie en techniek

• Bouw en ondergrond

• Informatie- en communicatietechnologie

Binnen al deze vijf kerngebieden streeft TNO ernaar om hoogwaardige kennis te bezitten over alle relevante onderwerpen. Om de toestroom van kennis te waarborgen, laat TNO dan ook jaarlijks een groot aantal afstudeerders toe.

Dit afstudeeronderzoek wordt uigevoerd binnen het kerngebied informatie- en communicatietechnologie (ICT).

1.2.2 TNO Informatie- en communicatietechnologie

Dit kerngebied van TNO is ontstaan vanuit KPN research. Op 1 januari 2003 is deze research afdeling van KPN door TNO overgenomen. Door deze achtergrond is veel van het werk dat door TNO ICT uitgevoerd wordt, nog in grote mate gerelateerd aan KPN.

TNO ICT is een uniek innovatiecentrum in Nederland, waarbinnen de ICT en Telecom disciplines van TNO zijn gebundeld. De opdrachtgevers van TNO zijn bedrijven, overheden en (semi-)publieke organisaties. Deze worden geholpen om succesvol te innoveren met ICT. Hierbij staat de waardecreatie centraal en schuilt de kracht van TNO ICT in de combinatie van innovatieve oplossingen en relevante kennis.

Daarnaast heeft TNO ICT ook een innovatie stimulerende rol. Dit heeft betrekking op het ondersteunen en begeleiden van innovatieve oplossingen om hierdoor nieuwe initiatieven op de markt te brengen. Dit kan onder andere de vorm aannemen van een Spin-off, waarbij enkele betrokkenen vanuit TNO verzelfstandigen.

Naast technologische oplossingen wordt ook veel nadruk gelegd op de gebruikersvriendelijkheid, de financiële onderbouwing en de procesinrichting van organisaties. Via technische- en marktpilots wordt ook meegewerkt aan de implementatie van oplossingen.

Innovatiestrategie en innovatiebeleid zijn de kerncompetenties van TNO ICT en bieden een omvangrijke bron van ICT kennis voor maatschappelijke vraagstukken. Grondige kennis van de nieuwste ICT en Telecom ontwikkelingen is daarbij essentieel. De ongeveer 375 medewerkers van TNO ICT zijn onder andere door hoogleraar en docent posities verankerd in de nationale en internationale kennisinfrastructuren. Door deelname aan nationale en internationale standaardisatiefora en kennisontwikkelingsprogramma’s en door samenwerking met universiteiten en hogescholen, wordt de kennis binnen TNO ICT continu vernieuwd. Naast kennis zijn ook de praktische vaardigheden belangrijk. TNO ICT investeert daarom veel tijd en energie in het gebruiken en testen van nieuwe technieken en concepten in laboratoria en infrastructuur.

9 1.2.3 Werkveld van TNO Informatie- en communicatietechnologie

TNO ICT voert met name opdrachten uit voor de ICT en telecom branche. Binnen deze branche volgen technologische ontwikkelingen elkaar in hoog tempo op, waardoor een snelle doorstroming van nieuwe producten en diensten ontstaat. De traditionele levenscyclus van een product wordt hierdoor zeer snel doorlopen, of wordt relatief kort na de invoering van een product weer afgebroken door technologische vernieuwingen.

Een sprekend voorbeeld is de ontwikkeling van de markt voor (breedband) internetverbindingen. Deze markt is binnen enkele jaren zeer groot geworden en is in die korte tijd vele malen door innovaties behoorlijk veranderd. Van ‘verbinden met internet’

naar ‘live voetbalwedstrijden kijken’ heeft de markt voor internetverbindingen zich zeer snel ontwikkeld.

Binnen TNO ICT wordt ook continu aan innovaties gewerkt en wordt zodoende bijgedragen aan het hoge tempo van de innovatiecyclus. Daarnaast heeft TNO ICT echter de rol om innovaties toegankelijk en toepasbaar te maken voor het bedrijfsleven en de overheden.

Dus niet enkel de innovatie, maar ook de implementatie ervan valt binnen het werkveld van TNO ICT.

Bij de implementatie is met name de informatietechnische organisatie-inrichting van groot belang. Kan bijvoorbeeld de huidige inrichting van een organisatie het nieuwe product wel voortbrengen?

1.3 Achtergrond van het onderzoek

De bovengenoemde snelle innovatiecyclus heeft op de inrichting van organisaties grote impact. Een organisatie, die concurrerend wil blijven in een innovatiegedreven markt, wordt gedwongen om continu, qua organisatie-inrichting, met innovaties mee te groeien.

De vraag naar een dynamische opbouw van organisaties speelt met name op het conceptuele niveau (de inrichting van een bedrijfsmodel) van een organisatiearchitectuur (McGregor, 2003).

Naast de organisatorische ontwikkelingen waarmee TNO ICT geconfronteerd wordt, zijn ook de mogelijkheden van ondersteunende software in een enorme vaart doorontwikkeld.

Daarom zal in hoofdstuk 2 uitvoerig worden ingegaan op ontwikkelingen in informatietechnische organisatiearchitecturen. Uit deze beschrijving van ontwikkelingen en achtergronden, zullen enkele concepten naar voren komen die in de toekomst een belangrijke rol kunnen gaan spelen. Deze concepten zullen uitvoerig worden besproken en op basis daarvan zal een advies worden uitgebracht.

2 Ontwikkelingen in IT architecturen

2.1 Inleiding

In dit hoofdstuk zullen de ontwikkelingen op het gebied van de inrichting en ondersteuning van administratieve bedrijfsprocessen worden besproken. Bij deze bespreking zullen veel nieuwe begrippen geïntroduceerd worden. Deze zullen waar nodig direct toegelicht worden.

Voor de lezer echter, die weinig achtergrondkennis heeft inzake IT architecturen, zullen niet alle onderwerpen direct geplaatst kunnen worden. Daarom zal op veel kernzaken later in het onderzoek uitgebreid teruggekomen worden. Voor nu volstaat het om eerst de lijn in de ontwikkeling te schetsen en kansen voor de toekomst te herkennen.

Daarnaast is dit hoofdstuk een (uitgebreide) inleiding op de probleemstelling. Vanuit de beschreven ontwikkelingen zal een vraag worden geformuleerd, waarop aan het einde van dit onderzoek antwoord gegeven zal worden.

2.2 Achtergronden van bedrijfsprocessen

Administratieve bedrijfsprocessen zijn in steeds grotere mate verbonden met softwarepakketten. Het is immers niet meer in te denken, dat de boekhouding van een organisatie handmatig wordt bijgehouden. Om een compleet beeld te geven, zal begonnen worden met het schetsen van de historische achtergrond van softwarematige ondersteuning van bedrijfsprocessen. Hierdoor wordt ook inzichtelijk gemaakt hoe bepaalde afhankelijkheden zijn ontstaan en waardoor organisaties na enkele automatiseringsrondes een behoorlijk uitgebreid netwerk aan softwareproducten gebruiken.

2.2.1 Automatisering

Aan het begin van de jaren ‘80, tijdens de opkomst van de vierde generatie digitale computers, werd het praktisch nut van IT ondersteuning van bedrijfsprocessen meer en meer onderkend. Hierbij lag de focus op het functioneren van een ondersteunend IT programma, ofwel applicatie. Slechts kleine onderdelen van processen werden geautomatiseerd of werden vergemakkelijkt door een softwareapplicatie. Hierbij kan gedacht worden aan bijvoorbeeld voorraadbeheer of loonadministratie.

De software was voor bijna iedere organisatie uniek en moest dus speciaal ontworpen worden. Daarbij werd bij de implementatie van een softwareproduct geen rekening gehouden met eventuele toekomstige afhankelijkheden van andere softwareproducten. Er waren nauwelijks afspraken tussen (en vaak ook binnen) organisaties gemaakt over welke standaarden aangehouden moesten worden, zodat een eventueel nieuw softwareonderdeel eenvoudig toegevoegd kon worden.

Door de toegenomen rol van ICT in organisaties, werden steeds meer afzonderlijke deelprocessen geautomatiseerd. Dit leidde ertoe dat, aan het begin van de jaren ‘90, steeds meer onderdelen van organisaties ‘gedigitaliseerd’ werden. Door deze toegenomen vraag naar digitale ondersteuning, kwamen er enkele standaard softwarepakketten op de markt. Door deze pakketten kon, met een veel kleinere investering, een aantal standaard activiteiten eenvoudig ondersteund worden. Ook kleinere organisaties konden zodoende profiteren van de mogelijkheden om processen te ondersteunen met softwareproducten.

Een voorbeeld van een dergelijk softwarepakket is een boekhoudprogramma.

11 Het kwam echter vaak voor binnen een organisatie, dat er voor ieder deelproces een ander

softwareproduct was geïmplementeerd. Hierdoor werd er enorm veel tijd en geld verspeeld aan het omzetten van data, zodat de verschillende programma’s ermee konden werken.

Deze implementaties van software waren vooral op snel resultaat van procesautomatisering gericht. In eerste instantie konden hier aardige successen qua efficiëntie mee behaald worden. Zodra echter het proces veranderde, moesten alle afhankelijkheden tussen de applicaties opnieuw vastgelegd worden.

Daarnaast was het niet goed mogelijk om de status van een product door de organisatie te volgen. Het kon dus vaak niet nagegaan worden waar een product op dat moment in de organisatie was. Daarnaast kon, wanneer een fout in de afhandeling was ontstaan, niet nagegaan worden waar en waardoor deze was veroorzaakt.

Een ander nadeel hiervan was, dat wanneer een medewerker data handmatig kopieerde van het ene systeem naar het andere, dit enerzijds erg foutgevoelig is en anderzijds dat er redundantie in gegevens kon ontstaan.

Een laatste nadeel van deze oplossingsgerichte manier van applicatiebeheer was, dat het goed mogelijk was dat er voor een ander proces of afdeling een nagenoeg identiek deelproces voor bijvoorbeeld het factureren was geïmplementeerd. Deze onnodige implementaties kwamen doordat afdelingen hun eigen automatisering in de hand hadden en er vaak nog geen organisatiebreed IT beleid vastgelegd was. (Inmon, 1999)

2.2.2 Enterprise Application Integration

Naar aanleiding van bovenstaande beschreven problemen, ontstond halverwege de jaren

‘90 de vraag naar een eenvoudige manier om de IT applicaties binnen een organisatie op elkaar aan te laten sluiten. Zodoende zou er een organisatiebreed IT beleid gevoerd kunnen worden. Uit deze gedachte is Enterprise Application Integration (EAI) ontstaan. De noodzaak voor applicatie integratie is versterkt door de opkomst van de internet economie.

Door deze nieuwe economie ontstond de vraag naar realtime data en het synchroniseren van applicaties tussen organisaties (Radhakrishnan, 2005).

1^e Generatie - Point to Point - CORBA - Specifiek

Waarde voor de klant

1990 1995 2000 2005 2010

2^e Generatie -Hub-and-Spoke -Business to Business -Loose Coupling

Huidige Generatie - Webservices - Focus op architectuur - Organisatiebrede Software

Toekomstige Generatie -Service Oriented Architecture -Reengineering

-Business Activity Monitoring

Figuur 1 - Generaties EAI

De ontwikkeling van EAI heeft in enkele generaties van verbeteringen en verschillende denkwijzen, plaats gevonden. Deze generaties van ontwikkeling zijn weergegeven in figuur 1. Deze opdeling in generaties is ontleend aan Radhakrishnan (2005) en zal nu verder uitgewerkt worden.

1^e generatie EAI

De eerste generatie EAI was vooral bedoeld applicaties op elkaar aan te laten sluiten. Een van de eerste grote standaarden met betrekking tot applicatie integratie was de Common Object Request Broker Architecture (CORBA). Dit is een standaard die ontwikkeld is voor het koppelen van applicaties waarbij het niet uitmaakte in welke programmeertaal de applicatie ontworpen was of waar de applicatie zich

in de organisatie bevond. De software die hiervoor zorgt, wordt middleware genoemd. In eerste instantie werden de applicaties point-to-point gekoppeld. Dit betekende een directe koppeling van applicatie tot applicatie, zoals weergegeven in figuur 2. Zo konden IT systemen door de hele organisatie gekoppeld worden en ontstonden complexe IT architecturen. Dit bracht voor iedere organisatie een unieke architectuur van gekoppelde applicaties met zich mee. Hierdoor was EAI voor alle organisatie een zeer specifieke architectuur.

2^e generatie EAI

In de tweede generatie werd, door de complexiteit van gekoppelde applicaties, de IT architectuur volgens het hub-and-spoke principe ingericht. Dit houdt in dat er een centraal mechanisme is (de hub), waardoor meerdere applicaties (de spokes) verbonden en aangestuurd kunnen worden. Hierdoor veranderde de koppeling tussen applicaties van point-to-point in many-to-many. Alle applicaties waren op deze manier met elkaar verbonden doordat de hubs ook weer met elkaar in verbinding stonden.

Door het hub-and-spoke principe konden de afhankelijkheden tussen applicaties veel losser gedefinieerd worden omdat er altijd via de centraal vastgelegde middleware werd gecommuniceerd. De applicaties kunnen als soort adapters (of koppelstukken) op de hub aangesloten worden, zonder dat er aanpassingen te hoeven worden gedaan aan de applicatie. Deze eenvoudige manier van koppelen van applicaties wordt met loosely coupling aangeduid. Dit houdt in dat applicaties

moeiteloos aan een architectuur gekoppeld en indien gewenst ook eenvoudig ontkoppeld kunnen worden (Moitra, 2004)

Door de losse opzet van de EAI werd het ook veel eenvoudiger om (een applicatie van) een partnerbedrijf toegang te geven tot het interne bedrijfsnetwerk via de middleware. Dit is business- to-business (b2b) integratie.

De hub-and-spoke opzet brengt ook een aantal

nadelen of potentiële valkuilen met zich mee. Het eerste nadeel is een zogenaamde Vendor lock-in. Hiermee wordt een te grote afhankelijkheid van één softwareleverancier bedoeld.

Wanneer de middleware van een organisatie eenmaal is aangeschaft, moet de rest van de applicaties ook met deze middleware kunnen communiceren. Over het algemeen betekende dit dat de applicaties ook bij de betreffende softwareleverancier aangeschaft moesten worden. Dit is dus juist het tegenovergestelde van het doel wat voor ogen stond, namelijk een onafhankelijke structuur.

Figuur 2 - point-to-point EAI

Figuur 3 - Hub-and-spoke EAI

13 Aan het einde van deze tweede generatie zijn deze afhankelijkheden grotendeels

opgevangen door de opkomst van de populaire programmeertalen zoals XML en Java waardoor, onafhankelijk van de middleware leverancier, applicaties konden worden geïmplementeerd.

De tweede nadeel van een hub-and-spoke architectuur en aanschaf van middleware is, dat het integratieproces binnen een organisatie niet sneller kan verlopen, dan dat de leverancier een update van het product beschikbaar stelt. Dus zolang de middelware niet geschikt gemaakt is voor bijvoorbeeld XML, kan de organisatie er nog geen gebruik van maken.

(Huidige) 3^e generatie EAI

Tijdens de derde en huidige generatie EAI is de, in de tweede generatie ingezette koers qua inrichting van een organisatiearchitectuur, verder doorontwikkeld en volwassen geworden. De eerder genoemde standaarden (Java en XML), worden door alle softwarepakketten ondersteund. Hierdoor is de kans op een ongewenste vendor lock-in verder terug gebracht. Op de markt voor integrale softwarepakketten nemen enkele leveranciers een dominante positie in. Deze bieden alle standaard functionaliteiten voor een organisatie in één uitgebreid pakket. Deze bewuste afhankelijkheid van een leverancier wordt geprefereerd boven de keuze uit meerdere losse softwarepakketten die slechts een deel van de totaal gewenste functionaliteiten bieden. Daarbij hebben de aanbieders van deze integrale pakketten vaak een dusdanige positie op de markt dat dit als meer betrouwbare partner wordt ervaren dan kleinere spelers. Voorbeelden van deze grote leveranciers (en de betreffende softwarepakketten) zijn SAP (NetWeaver), IBM (WebSphere) en Microsoft (BizTalk).

Verder is de aandacht voor de architectuur van een organisatie toegenomen. Een langetermijnvisie qua architectuur voorkomt een kortzichtige implementatie van applicaties gebaseerd op de directe behoeften vanuit een project of een afdeling.

Naast de standaarden om applicaties binnen organisaties eenduidig te laten communiceren, is er ook een standaard ontwikkeld voor communicatie tussen organisaties (b2b). Dit zijn de webservices, die grotendeels een nieuwe vorm is van Electronic Data Interchange (EDI) kunnen worden beschouwd (Shirky, 2002). EDI maakt het mogelijk om tussen organisaties (point-to-point) documenten (bijvoorbeeld een factuur) digitaal te versturen. Dit is een standaard die nog altijd veel gebruikt wordt in b2b communicatie.

Webservices zijn hierin een nieuwe vorm, met name doordat er algemeen geaccepteerde standaarden vastgelegd zijn. Daarbij zijn webservices niet slechts point-to-point b2b communicatie zoals EDI, maar bieden de mogelijkheid tot many-to-many communicatie. Er is dus geen sprake van een van te voren afgesproken communicatie tussen organisatie A en B, maar van een netwerk van webservices waarbij organisaties van de aangeboden webservices gebruik kunnen maken, zonder eerst over de communicatie afspraken te hoeven maken. Dit betekent dat webservices ook beter aansluiten bij EAI en de wens om over een loosely coupled architectuur te beschikken (Bijl, 2003).

Nadelen van webservices zijn dat de standaarden waarop deze gebaseerd zijn (SOAP en de (sector)specifieke dialecten van XML) nog in beweging zijn. Dus de gewenste ‘vaste grond’

waarop verder gebouwd kan worden ontbreekt vooralsnog. Daarbij is het niet goed mogelijk een standaard te ontwikkelen waar alle vormen van communicatie in gevat zijn.

Er is dus behoefte aan higher-level standaarden, wat feitelijk een stap terug betekent in de algemene integratie trend (Shirky, 2002).

(Toekomstige) 4^e generatie EAI

Een van de concepten die, wanneer gesproken wordt over toekomstige IT architecturen, ter sprake wordt gebracht, is de Services Oriented Architecture (SOA). Een service is de

invulling van één bedrijfsfunctie met daarbij een goed gedefinieerde input en output op basis van standaarden. Dit betekent dat de bedrijfsfuncties in applicaties, aangeroepen kunnen worden door de generiek gedefinieerde services. Hierdoor kan hergebruik van services plaats vinden, omdat deze specifiek invulling geven aan één duidelijke bedrijfsfunctie, die voorheen in de diverse applicaties verwerkt waren. Een service is dus de invulling van één specifieke functie zoals bijvoorbeeld het opleveren van adresgegevens van een klant voor het opstellen van een factuur. De input in dit voorbeeld is een klantidentificatienummer en de output van de service, de adres- en bankgegevens van de betreffende klant. De functie die als voorbeeld werd gebruikt, zal in erg veel applicaties gebruikt worden en levert zodoende een onnodig aantal invullingen van deze functie. Het grote voordeel van een SOA is dat deze op basis van standaarden (bijvoorbeeld XML), een functionele laag over de applicaties vormt, waardoor de hierin geïmplementeerde functies ook vanuit andere applicatieplatformen gebruikt kunnen worden. Hierop zal uitgebreid ingegaan worden in hoofdstuk 5.

Het opzetten van een IT architectuur door gebruik te maken van services is niet nieuw. De oriëntatie op services is al bekend sinds de opkomst van EAI en wordt sindsdien ook gebruikt (door bijvoorbeeld het eerder besproken CORBA). Binnen een homogene omgeving functioneerde deze opzet naar behoren, maar zodra de services gekoppeld moesten worden aan andere technologieën moesten zeer uitgebreide en complexe koppelingen (interfaces) speciaal worden ontworpen. Ironisch genoeg werden deze pogingen, in plaats van het vereenvoudigen van integratie, uiteindelijk een struikelblok voor (organisatiebrede) integratie. (Radhakrishnan, 2005)

De steeds duidelijker geworden opzet van een IT architectuur in een organisatie, geeft ook steeds meer en betere mogelijkheden om de processen en activiteiten nauwgezet te volgen. Dit wordt Business Activity Monitoring (BAM) genoemd. Dit omvat aggregatie, analyse en presentatie van relevante en tijdige informatie over bedrijfsactiviteiten binnen en tussen de organisaties. Het geeft daardoor real-time informatie over her verloop van processen en transacties, en biedt zodoende de mogelijkheid om direct in te grijpen waar en wanneer nodig.

Per periode zijn hierboven de belangrijkste concepten en de ontwikkeling daarvan weergegeven. Dit geeft echter nog geen volledig beeld over hoe de praktijk in organisaties is veranderd. Veel oude technieken en concepten worden nog steeds door veel organisaties gebruikt. Dit is wellicht niet de optimale oplossing voor de betreffende organisaties, maar vaak wel (op kortere termijn) een goed werkende oplossing. Dit komt doordat een nieuw systeem uiteraard niet van de ene op de andere dag ingevoerd kan worden. Veel oude afhankelijkheden tussen applicaties blijven op de achtergrond bewaard, doordat een nieuw systeem het oude niet vervangt, maar ‘eroverheen’ wordt geïmplementeerd. Hierdoor ontstaat een architectuur die een aantal malen is ‘opgelapt’ met nieuwe technieken, maar nooit een keer grondig herzien is. Deze verouderde grondlaag in een architectuur wordt het zogenaamde legacy systeem genoemd.

Dit is het laatste, maar zeker ook een erg belangrijk inzicht voor toekomstige systemen, dat besproken zal worden, namelijk de functie van een bedrijfsproces. De functie van een bedrijfsproces mag nooit uit het oog worden verloren. Soms werkt een systeem naar behoren, alleen weet niemand in de organisatie precies hoe afhankelijkheden tussen applicaties ontstaan zijn en wat de functie ervan is. Deze problematiek vraagt op termijn om een grondige herziening van de volledige IT organisatiearchitectuur, met als uitgangspunt de functie van een proces. Pas dan kunnen de eventuele services ook goed vastgesteld worden en de overbodige activiteiten verwijderd worden. (Khan, 2004)

15 2.2.3 Workflow

Naast de bovenstaande ontwikkeling van EAI, is er ook een tweede ontwikkeling die invloed heeft op de inrichting van IT architecturen, namelijk workflow. Waar EAI met name gericht is op de IT inrichting van een architectuur, is workflow gefocust op de besturing van bedrijfsprocessen in een architectuur. Workflow is de stroom van werk in een organisatie. Hierbij wordt vastgelegd hoe het werk kan worden opgedeeld in taken, wie deze taken uitvoert, in welke volgorde ze uitgevoerd moeten worden en tot slot welke informatie daarbij nodig is.

Binnen workflow zijn verschillende technologieën die deze werkstroom coördineren. Reijers (2003) onderscheidt de volgende categorieën workflow: production workflow, groupware, ad-hoc workflow en case handling.

In de bovenstaande figuur zijn de vier categorieën ingedeeld op basis van structuur en sturing. De verschillende categorieën zullen nu kort besproken worden.

Production workflow: Dit is een veel voorkomende categorie workflow. In deze categorie ligt de nadruk op de route die een werkstroom moet doorlopen. Door expliciet (op voorhand) vastgelegde regels voor de route, biedt deze vorm een hoge mate van procesondersteuning maar is hierdoor weinig flexibel.

Groupware: Deze categorie workflow biedt de mogelijkheid tot het delen van informatie en de communicatie tussen medewerkers. Hierbij wordt geen enkele procesondersteuning geboden maar is hierdoor wel zeer flexibel.

Ad-hoc workflow: Deze vorm biedt de mogelijkheid om, wanneer dit nodig is, snel een workflowmodel te creëren en aan te passen. Dit houdt in dat bij (unieke) zaken of projecten een tijdelijke procesroute kan worden ontworpen. Door de eenvoudige en dus snel op te zetten workflow biedt deze vorm een hoge mate van flexibiliteit. Op langere termijn echter vormt de eenvoudige opzet een tekort aan efficiëntie.

Figuur 4 - positionering vier categorieën workflow, (Reijers 2003)

Case handling: Bij deze vierde vorm van workflow ligt de focus op de zaak (of case) en wordt door deze case de route impliciet bepaald. Dit betekent dat de route tijdens (in plaats van vooraf) wordt bepaald door de openstaande activiteiten in de case.

De beschreven categorieën zijn in figuur 5 weergegeven en daardoor wordt duidelijk dat een toename van ondersteuning ten koste gaat van de flexibiliteit van workflow. Met flexibiliteit wordt in deze figuur de ‘aanpasbaarheid’ van de workflow bedoeld. Dus in hoeverre de workflow strikt vastgelegd is, of nog aangepast kan worden aan veranderde omstandigheden. Het optimale resultaat voor een workflowsysteem ligt gemiddeld genomen in het snijpunt van flexibiliteit en ondersteuning. Echter een bedrijfsproces met zeer weinig variatie en dus veel vaste routes, is weinig gebaat bij een flexibel systeem en kan dus met een efficiënt opgezette production workflow de beste resultaten behalen. Het omgekeerde geldt voor een bedrijfsproces waar nauwelijks vaste routines in te herkennen zijn. Dergelijke onderdelen van organisaties hebben meer belang in een flexibel systeem zoals groupware.

Door de toegenomen mogelijkheden van software en communicatie, is de wisselwerking tussen flexibiliteit en ondersteuning op een hoger niveau gebracht. Een ander gevolg van deze technische vernieuwingen is dat concepten in een gecombineerd pakket aangeboden worden. Met name production en ad-hoc workflow wordt veelal in een dergelijke gecombineerde pakketten aangeboden. De reden hiervoor is dat production workflow over het algemeen de basis vormt in een (procesgedreven) workflow binnen een organisatie en ad-hoc workflow gezien wordt als vereenvoudigde en tijdelijke definitie van een (uiteindelijke) production workflow. In workflowmanagement systemen (WFMS)¹ is de mogelijkheid om ad-hoc een workflow op te zetten een mogelijkheid als variatie op de standaard production workflow. Daarnaast wordt het onderscheid tussen beide concepten ook steeds kleiner door de vereenvoudigde mogelijkheden om grafisch een proces te

1 Voor zowel enkelvoud als meervoud zal de afkorting WFMS gebruikt worden.

Figuur 5 - wisselwerking tussen flexibiliteit en ondersteuning (Reijers 2003)

17 definiëren en hierin direct de workflow vast te leggen. Centraal in een WFMS staat echter

nog wel de expliciete en procesgedreven aanpak van een workflow. Dit is ook direct het onderscheid met case handling waarbij de route impliciet wordt bepaald door de data in de case. (Allen, 2001)

Case Handling (CH) biedt een in de kern verschillende aanpak van een workflow ten opzichte van een WFMS. Zoals aangegeven bepaald CH de route van een workflow op basis van data in de case zelf. Dit houdt in dat wanneer een vereist dataveld nog niet ingevuld is, de bijbehorende activiteit dus nog ondernomen moet worden. Mede door deze meer flexibele manier van procesbesturing en zonder daarbij grote concessies te hoeven doen qua ondersteuning, wordt CH gezien als een veelbelovend concept voor aansturing van een workflow.

2.2.4 Algemene ontwikkelingen in IT architecturen

In het voorgaande is veel beschreven over ontwikkelingen en mogelijkheden die nog in de toekomst liggen. Daarbij is gericht beschreven wat dit betekent voor informatietechnische architecturen en in de aansturing daarvan. Daarnaast echter kunnen ook een aantal algemene trends met betrekking tot een IT organisatiearchitectuur worden opgesomd.

Deze ontwikkelingen vallen samen met de ontwikkelingen zoals deze zijn weergegeven voor de vierde generatie EAI.

• Integratie; Zowel binnen als tussen organisaties. Of dit in de vorm van applicaties of services plaats vindt maakt daarvoor in eerste instantie niet uit. Daarnaast kan voor externe integratie de koppeling met een (intern) bedrijfsnetwerk een groot voordeel opleveren. Ook dit kan weer vormgegeven worden door meerdere concepten (EDI en webservices). Hierbij kan bijvoorbeeld gedacht worden aan inzicht in leveringsschema’s zodat de afnemende partij zijn planning daarop af kan stemmen.

(Heffner, 2004)

• Aanpasbaarheid / flexibiliteit (adaptiveness / responsiveness); Door snelle veranderingen in de omgeving van organisaties, moet de organisatiearchitectuur flexibel georganiseerd worden om zodoende adequaat op deze veranderingen in te kunnen spelen. (Bezancon, 2005 en Moitra, 2004)

• Hergebruik (reuse); Wanneer services eenmaal goed gedefinieerd zijn, kunnen deze binnen (en eventueel buiten) de organisatie opnieuw ingezet worden. (Bezancon, 2005 en Hao, 2003)

• Uitbesteden; Wanneer een service is gedefinieerd en los in een integrale architectuur is geplaatst, kan de uitbesteding aan een externe partij relatief eenvoudiger plaats vinden. Doordat exact bekend is wat de service inhoudt (dus wat de in- en output is), kan de uitbestedende partij zeer duidelijke leveringsvoorwaarden stellen en is de kans op succes behoorlijk gegroeid. (Gliedman, 2004)

Daarbij is een groeiende vorm van uitbesteden het offshoring. Dit is het uitbesteden van een complete (backoffice) dienst naar een zogenaamd ‘lagelonenland’ om zodoende een kostenbesparing te realiseren. (Ooijevaar, 2005)

2.3 Concluderend

Vanuit verschillende technologische perspectieven is er nu gekeken naar ontwikkelingen in IT architecturen. Deze perspectieven zijn: EAI, workflow, B2B communicatie en tot slot nog enkele algemene ontwikkelingen. In figuur 6 zijn deze perspectieven weergegeven.

Deze figuur geeft ook direct een andere ontwikkeling weer; het integraal aanbieden van de gecombineerde technologieën in één software suite.

In deze suites wordt één integraal pakket aangeboden waarin alle technologische perspectieven samengevoegd kunnen worden. Door een dergelijke suite kan een organisatie alle functionaliteiten in één keer implementeren. Reeds eerder genoemde voorbeelden hiervan zijn: de Staffware suite van TIBCO, de BizTalk suite van Microsoft en de NetWeaver suite van SAP. In deze suites staat een zogenaamde Enterprise Service Bus (ESB) centraal. Daarom worden deze producten ook wel met ESB suites aangeduid. In hoofdstuk 5 zal deze samenvoeging tot ESB suites besproken worden

Het vervolg van het onderzoek zal gericht zijn op deze integrale aanpak van IT architecturen. Zoals beschreven zijn er binnen de perspectieven verschillende concepten die daar invulling aan geven. Zo kan in diverse combinaties van concepten worden gedacht en beschreven worden welke wellicht een goede of logische combinatie vormen.

In dit onderzoek zal de combinatie tussen workflow en IT architecturen centraal staan en de B2B relaties buiten beschouwing worden gelaten. Zoals reeds beschreven, vormen Case Handling Systemen (CHS) en WFMS verschillende concepten voor invulling van een workflow. Daarnaast biedt de opzet in services een veelbelovend perspectief met betrekking tot een flexibele IT organisatiearchitectuur.

Vooruitlopend op de probleemstelling die in het volgende hoofdstuk wordt behandeld, kan het volgende alvast worden opgemerkt. De kern van dit onderzoek is om de combinatie van systemen te vinden, welke een maximale flexibiliteit biedt in een informatietechnische organisatiearchitectuur. Volgens Moitra (2004) bestaat er in dit verband een directe relatie tussen een flexibele IT architectuur en flexibele bedrijfsprocessen. Een flexibel bedrijfsproces heeft betrekking op bijvoorbeeld de mogelijkheden van een organisatie om met een markt mee te groeien of daarnaast om eenvoudig nieuwe processen te introduceren of juist uit te besteden.

Dit sluit direct aan bij de beschreven marktontwikkelingen waarbinnen TNO ICT opereert.

Daarom is het van belang dat TNO ICT inzicht krijgt in (toekomstige) mogelijkheden qua aansturing en inrichting van IT organisatiearchitecturen.

Figuur 6 – ontwikkeling naar integrale (ESB) software suites

19

3 Probleemstelling

3.1 Inleiding

Dit hoofdstuk biedt de handvatten die dit onderzoek een vaste richting geven. Allereerst zal hiertoe de aanleiding tot het onderzoek worden weergegeven. Daardoor kan de doelstelling en vraagstelling worden geformuleerd. Vervolgens zal door de afbakening een kader worden geboden waarbinnen het onderzoek plaats zal vinden. Tot slot zullen de vervolgstappen van het onderzoek worden besproken in de methodologie.

3.2 Aanleiding tot het onderzoek

Binnen TNO ICT is de vraag ontstaan naar duidelijkheid over nieuwe concepten met betrekking tot informatietechnische organisatiearchitecturen. Workflowmanagement is hierbij een veel genoemd concept voor de aansturing van bedrijfsprocessen en daarnaast zijn service oriented architectures een veelbelovend perspectief voor flexibele inrichting van de onderliggende architectuur. Workflowmanagement is echter een enorm breed begrip en is geïntroduceerd in een periode dat de eisen aan de IT architectuur vanuit organisaties minder op flexibiliteit gericht waren. Daarnaast is Case Handling, zoals is beschreven in hoofdstuk 2, een nieuw concept om een workflow in te richten. Welke van de beide workflow concepten biedt in een op services gebaseerde architectuur optimale flexibiliteit en kan het beste omgaan met de functionele services in een organisatie.

3.3 Doelstelling

De doelstelling geeft antwoord op de vraag waarom een onderzoek wordt uitgevoerd. In het voorgaande is beschreven wat de achtergronden van dit onderzoek zijn en ook wat het belang van TNO ICT hierin is. De doelstelling kan dan als volgt worden opgesteld:

Deze doelstelling is ruim geformuleerd. Dit in de eerste plaats omdat deze doelstelling de verwachting -met betrekking tot dit onderzoek- van TNO ICT weergeeft. Daarnaast zal in de vraagstelling van het onderzoek enger worden gedefinieerd en het onderzoek de benodigde focus geven.

3.4 Vraagstelling

De centrale vraagstelling geeft de vraag weer, waarop in dit onderzoek antwoord zal worden gegeven. Hierdoor wordt invulling gegeven aan de eerder opgestelde doelstelling waarin het belang van TNO ICT is verwoord.

Het weergeven van, voor TNO ICT relevante ontwikkelingen, in informatietechnische architecturen en op basis daarvan praktische en theoretische aanbevelingen aan TNO ICT te doen.

In hoeverre biedt case handling meer flexibiliteit dan workflowmanagement in de beheersing van een workflow, wanneer de systeemarchitectuur ingericht is volgens een Service Oriented Architecture?

In de bovenstaande vraagstelling staan een aantal kernzaken die verder uitgewerkt zullen worden in de deelvragen en vervolgens in de nog volgende hoofdstukken. Het centrale punt in de vraagstelling wordt echter gevormd door de zinsnede ‘meer flexibiliteit’. Dit is de crux van het onderzoek en zal daarom nu worden toegelicht.

In de vraagstelling duidt de flexibiliteit op het gehele IT systeem dat gevormd kan worden door de koppeling tussen WFM/CH en SOA. Dus in hoeverre biedt een systeem waarin CH aan SOA gekoppeld meer flexibiliteit dan een systeem waarin WFM aan SOA gekoppeld is?

Vanuit verschillende onderzoeken worden elementen en criteria van flexibiliteit aangedragen. Omdat echter geen van deze onderzoeken alle relevante kenmerken bevat die de flexibiliteit bepalen die geboden kan worden door de koppeling van procesmanagement en IT organisatiearchitecturen, wordt hier gekozen om elementen van flexibiliteit uit verschillende onderzoeken te combineren. De kenmerken van flexibiliteit van een administratief bedrijfsproces en dus de mogelijkheid om deze aan te passen, zoals deze in dit onderzoek worden aangehouden, zijn de volgende:

• De snelheid waarmee een bedrijfsproces aangepast kan worden aan de veranderde omgeving. (Moitra en Ganesh, 2004)

• De kosten die een aanpassing van een bedrijfsproces met zich meebrengt. (Byrd en Turner, 2001)

• De mate waarin met uitzonderingen op de standaard procesdefinitie omgegaan kan worden. (Sadiq e.a, 2005)

• De bereidheid van het personeel om zich een nieuwe werkwijze eigen te maken.

(Byrd en Turner, 2001)

De bovengenoemde elementen zullen gebruikt worden bij het beantwoorden van de vraagstelling. Dus in hoeverre sluit CH beter aan bij de elementen van flexibiliteit ten opzichte van WFM, wanneer de IT infrastructuur op basis van services ingericht is?

3.5 Deelvragen

Om bovenstaande doel- en vraagstelling in te vullen en de lijn van het onderzoek te verduidelijken, zijn een aantal deelvragen opgesteld. Deze vragen dragen bij aan het beantwoorden van de centrale vraagstelling.

1. Uit welke elementen is een informatietechnische organisatiearchitectuur opgebouwd?

Bij het beschrijven van een IT organisatiearchitectuur zijn zeer veel begrippen, invalshoeken en definities bruikbaar. Omdat in een onderzoek echter een dusdanige hoeveelheid niet werkbaar is zal eerst hierin een duidelijk kader gecreëerd moeten worden, zodat duidelijk is wat er in dit onderzoek onder begrippen wordt verstaan.

2. Wat is een Service Oriented Architecture (SOA)?

Waarin verschilt een SOA opzet ten opzichte van huidig EAI in organisatiearchitecturen?

Wat is de toegevoegde waarde van deze opzet en hoe kan worden nagegaan dat het niet slechts bij een goed concept blijft maar ook daadwerkelijk geïmplementeerd gaat worden.

3. Waarin onderscheiden WFM en CH zich en welk concept is qua concept het meest geschikt in combinatie met een SOA?

Om deze vraag te kunnen beantwoorden moet eerst voor beide concepten een goede beschrijving worden gegeven, voordat deze met elkaar kunnen worden vergeleken. Nadat de concepten behandeld zijn, kan bepaald worden welke van beide principes, vanuit het SOA perspectief, de meest flexibele vorm van aansturing kan bieden.

21 4. Hoe kan het voorgestelde concept (WFM of CH) gekoppeld worden aan een SOA?

Vanuit de conclusie van de voorgaande deelvraag, kan gekeken worden wat er nodig is om het voorgestelde concept te laten aansluiten op een SOA. Waar in de vorige deelvraag meer gefocust is op de conceptuele aansluiting van de concepten, zal nu beoordeeld worden wat praktisch gezien nodig is voor een koppeling.

3.6 Afbakening

Zoals meerdere malen naar voren is gekomen, is dit onderzoek gericht op de inrichting en aansturing van informatietechnische organisatiearchitecturen en processen. Met betrekking tot de inrichting van een architectuur zal gekeken worden naar SOA’s. Daarnaast met betrekking tot de besturing van processen, beperkt dit onderzoek zich tot WFMS en CHS.

De redenen voor de beperking tot deze drie concepten zijn reeds in hoofdstuk 2 weergegeven.

Uit de dagelijkse werkzaamheden blijkt dat TNO ICT met name adviezen uitbrengt over en ten behoeven van administratieve processen. Binnen dit onderzoek wordt daarom gefocust op administratieve processen.

Naast verschillende soorten processen, kan een proces ook op een aantal manieren ondersteund worden. Dit onderzoek beperkt zich tot de softwarematige of informatietechnische ondersteuning van bedrijfsprocessen.

3.7 Conceptueel model

In de eerder beschreven doel- en vraagstelling, komen veel begrippen en veronderstelde relaties voor. Ter verduidelijking van deze begrippen en de relaties hiertussen, dient een conceptueel model. Alle voor het onderzoek relevant geachte elementen worden hierbij in één overzicht weergegeven.

Figuur 7 - conceptueel model Bedrijfsprocesniveau

Implementatieniveau Workflow

WFM

CH

EAI SOA

Fit tussen architectuur- en proceslaag in een organisatiearchitectuur:

−

−

o Snelheid van verandering o Kosten van verandering

o Uitzonderingen op procesdefinitie o Personeelsbereidheid

In de figuur zijn de drie concepten (SOA, WFM en CH) uit hoofdstuk 2 weergegeven. Bij het concept workflow zijn de twee concepten (CH en WFM) weergegeven. In de koppeling tussen workflow en SOA ligt de kern van het onderzoek, zoals verwoord in de vraagstelling. De twee niveaus, het bedrijfsproces en de implementatie, waaruit het conceptueel model is opgebouwd, zijn gebaseerd op het organisatiearchitectuur raamwerk van Harmon (2004). Dit zal in hoofdstuk 4 worden besproken.

3.8 Methodologie

Dit onderzoek is er op gericht om enerzijds inzicht te bieden in nieuwe concepten en anderzijds om weer te geven hoe deze gecombineerd kunnen worden. In het vervolg van het onderzoek zullen dus veel concepten behandeld worden, waaraan afzonderlijke conclusies en aanbevelingen gekoppeld kunnen worden. Aan het einde van ieder hoofdstuk, waarin een nieuw concept behandeld is, zullen de betreffende conclusies en aanbevelingen weergegeven worden. Zo dient de bespreking van een concept zijn doel in het geheel van het onderzoek, maar kunnen ook de aanbevelingen en conclusies van de afzonderlijke concepten per hoofdstuk beschouwd worden.

De opbouw van het totale onderzoek naar de mogelijkheden om de concepten te combineren, is op de volgende pagina weergegeven in figuur 8. Begonnen wordt met een analyse, waarin de afzonderlijke concepten besproken worden. Daarbij zal nog niet worden beoordeeld in hoeverre de concepten (SOA en WFM/CH) op elkaar aansluiten. Dit vindt plaats in hoofdstuk 7, waarin de resultaten weergegeven worden. Tot slot zullen in hoofdstuk 8 alle gedane conclusies en aanbevelingen gecombineerd en samengevoegd weergegeven worden.

Het beantwoorden van de centrale vraagstelling zal dus plaats vinden in hoofdstuk 7.

Echter het voldoen aan de doelstelling van het onderzoek, zal binnen de hoofdstukken vorm gegeven worden.

23 Samenvoeging

Analyse Organisatiearchitectuur

Hoofdstuk 4

Service Oriented Architectures Hoofdstuk 5

Workflow (WFM en CH) Hoofdstuk 6

Resultaten Hoofdstuk 7 Ontwikkelingen

Hoofdstuk 2

Aanbevelingen Conclusies en aanbevelingen

Hoofdstuk 8

Figuur 8 – Overzicht van het onderzoek

4 Organisatiearchitectuur

4.1 Inleiding

In dit hoofdstuk zal besproken worden uit welke elementen een organisatiearchitectuur is opgebouwd. Daardoor kunnen bedrijfsprocessen en IT architectuur geplaatst worden in het raamwerk van de overkoepelende organisatiearchitectuur. Zodoende wordt duidelijk van welke andere elementen uit de organisatiearchitectuur deze onderdelen afhankelijk zijn en in welke relatie ze tot elkaar staan.

4.2 Organisatiearchitectuur raamwerk

In de onderstaande figuur zijn alle elementen weergegeven, waaruit een organisatiearchitectuur is opgebouwd. De organisatiearchitectuur wordt in vier niveaus ingedeeld:

• In de bovenste laag van de piramide worden alle management beslissingen genomen. Hier worden doelen, strategieën en mogelijkheden bepaald en beoordeeld met betrekking tot de gehele organisatie.

• Het tweede niveau geeft de waardeketen weer waarbinnen de organisatie valt en de bedrijfsprocessen die zorgdragen voor de waardetoevoeging in de waardeketen.

Dit is het aantrekken van onderdelen en die omzetten in producten of diensten voor klanten van de organisatie. Daarbij is een verdere onderverdeling gemaakt.

De bovenste helft geeft weer hoe bedrijfsprocessen gerelateerd zijn aan de waardeketen. Daaronder is wordt gefocust op één specifiek bedrijfsproces, dat vervolgens exact gedefinieerd kan worden.

Figuur 9 - Organisatiearchitectuur raamwerk, ontleend aan (Harmon, 2004)

25 Wanneer nauwkeuriger gekeken wordt naar een specifiek bedrijfsproces, kan worden

vastgesteld dat deze handmatig, automatisch of door een combinatie van beide kan worden uitgevoerd.

• Deze driedeling wordt verder uitgewerkt in de derde laag van het model. Aan de linkerkant zijn de handmatige proceselementen weergegeven. Deze worden uitgevoerd door de medewerkers in een organisatie. Aan de rechterkant zijn de geautomatiseerde proceselementen weergegeven welke ingevuld worden door software systemen. Daartussenin zijn de gecombineerde mens-computer elementen weergegeven die de derde vorm weergeven.

• De onderste en vierde laag van het model geeft de fysieke infrastructuur weer van de organisatie. Dit zijn bijvoorbeeld; grond, gebouwen en computer hardware.

Dit onderzoek kan gepositioneerd worden in de tweede en derde laag. In de bedrijfsprocessen moet dus rekening gehouden worden met twee (hoofd)soorten van uitvoerende elementen en een tussenvorm daarvan. De wisselwerking tussen de verschillende lagen en de verschillende uitvoerende elementen vormt de kern van dit onderzoek.

Er zal nu eerst beschreven worden hoe bedrijfsprocessen aan een waardeketen gerelateerd kunnen worden. Dit is dus de bovenste helft van de tweede laag. Daarna zal specifiek ingegaan worden op één (generiek) proces en zal weergegeven worden waaruit een proces opgebouwd kan worden. Dit is de onderste helft van de tweede laag. In hoofdstuk 5 zal ingegaan worden op de derde laag, de IT architectuur.

4.3 Bedrijfsprocessen in een waardeketen

Een organisatie is gericht op het vervullen van een functie voor haar omgeving. Dit geeft een organisatie haar bestaansrecht. Zodra een organisatie geen functie, en dus geen toegevoegde waarde heeft voor haar omgeving, verliest de organisatie haar doel en heeft daardoor geen bestaansreden meer.

De omgevingsfunctie voor een organisatie bepaald welke producten of diensten er geleverd worden. Een product moet dus altijd een functie vervullen in de omgeving van de organisatie. Hieraan kan een uiteenlopende invulling worden gegeven.

Een organisatie is ook op een andere wijze afhankelijk van de omgeving. Dit omdat een organisatie deel uitmaakt van een waardeketen. Een waardeketen beschrijft de keten van de aaneenschakeling van functies die er gezamenlijk voor zorgen dat een product of dienst bij de klant terechtkomt (‘van zand tot klant’). De waardeketen en de onderneming kunnen elkaar compleet overlappen. Dit houdt dan in dat de organisatie het volledige proces van grondstof tot eindproduct beheerst. Over het algemeen is een organisatie gericht op een deel van de waardeketen.

Doordat positie is gekozen in de waardeketen, wordt een organisatie afhankelijk van aan de ene kant leveranciersprocessen en aan de andere kant afnemersprocessen. Bij fysieke productie is deze afhankelijkheid direct duidelijk te maken. Een aantal grondstoffen of (half)producten vormen de input van een dergelijke organisatie. Deze input wordt dusdanig bewerkt dat ze waarde krijgen voor de afnemers. Veel minder inzichtelijk is daarentegen de waardeketen van een administratief proces. De relatie tussen leverancier, producent en afnemer is hierbij veel minder zichtbaar.

Ook binnen een organisatie is het denken in termen van waardetoevoegende activiteiten waardevol. Hierdoor wordt duidelijk wat de primaire en wat de secundaire (ondersteunende) processen zijn. De primaire processen dragen bij om de functies van een organisatie te realiseren. De secundaire processen zijn ter ondersteuning van de primaire

processen (bijvoorbeeld het werven van nieuwe medewerkers). De combinatie van primaire en secundaire processen zorgen voor de uitvoering van de bedrijfsactiviteiten.

Naast de processen die zorgdragen voor de uitvoering, zijn er processen die zorgen voor de besturing van de bedrijfsactiviteiten. Dit zijn de zogenaamde besturingsprocessen. Een voorbeeld hiervan is het inroosteren van het personeel.

In het algemeen zijn bedrijfsprocessen in een waardeketen de unieke manier waarop een organisatie is ingericht met betrekking tot de coördinatie van werk, informatie en kennis.

De bedrijfsprocessen geven dus kerncompetenties van de organisatie weer. De beschrijving van een proces is dan veelal conceptueel van aard en geeft de langetermijnvisie, met betrekking tot de inrichting van de organisatie, van het management weer.

4.4 Functiemodel

Alle organisaties zijn verantwoordelijk voor stukken werk in één of meerdere waardeketens. Op die bepaalde positie in een keten voegt een organisatie waarde toe aan de binnengekomen producten of diensten. Er moet dus binnen de organisatie een meerwaarde gecreëerd worden voor de afnemers. Op deze wijze is een proces te definiëren als het verschil tussen invoer en uitvoer, wat dus de toegevoegde waarde is van een bedrijfsproces. Deze benadering sluit direct aan bij het functiemodel (Sanden, 2000).

Hierin wordt beschreven wat de bijdrage is van een organisatie aan de omgeving, dus wat haar functie² is.

Het functiemodel biedt de mogelijkheid om een bedrijfsproces te beschrijven, zonder uitspraak te hoeven doen over de vormgeving daarvan. Dit houdt in dat, ongeacht hoe het bedrijfsproces is ingericht, er een uitspraak over de beoogde functie ervan kan worden gedaan.

Een hoofdfunctie van een organisatie bestaat weer uit een aantal deelfuncties. Zodoende kan er van de gehele organisatie een hiërarchie van functies opgesteld worden.

Een functie van een proces kan bepaald worden door afstand van de inrichting te nemen en te bepalen waar het voor dient, wat het doet in de omgeving en welke plaats het inneemt in het geheel. Bij het (her)ontwerpen van een procesinrichting kan de functie vooraf dienen als randvoorwaarde en na afloop als beoordelingscriterium.

Binnen een organisatie bestaat bijvoorbeeld het proces “het versturen van facturen”.

De invoer van dit proces komt van de afdeling financiën, die aangeeft welke klanten er nog een openstaande factuur hebben. Het proces bestaat uit het zoeken van de adresgegevens en de betalingsgeschiedenis, vervolgens het opstellen van de brief en tot slot het printen en frankeren.

2 Met functie wordt niet de (hiërarchische) positie in een organisatie bedoeld, maar de bijdrage of toegevoegde waarde.

Figuur 10 - de functie van een bedrijfsproces

Invoer Bedrijfsproces Uitvoer

Functie = verschil tussen input en output, en dus de waardecreatie door een bedrijfsproces

27 Het idee kan ontstaan om dit proces te willen automatiseren. Als nu de bestaande

situatie als vertrekpunt wordt genomen en dit wordt geautomatiseerd, dan is de kans reëel dat er mogelijkheden qua procesverbetering worden gemist en het uiteindelijke ontwerp niet optimaal is. Er kan voor alle deelprocessen (zoals het zoeken van adresgegevens) een geautomatiseerd systeem worden ontworpen en geïmplementeerd, waardoor uiteindelijk het hele proces geautomatiseerd is en waarschijnlijk sneller en goedkoper functioneert. Maar wordt buiten de kaders van het bestaande proces gedacht en eerst de functie van het proces bepaald, dan komen er andere mogelijkheden aan het licht.

De functie van het proces is bijvoorbeeld “klanten informeren over verschuldigde bedragen”. Dit is sinds jaren vorm gegeven door een factuur te versturen, maar wanneer de functie nogmaals bekeken wordt, ontstaat wellicht het idee om klanten te informeren via email. Door te kiezen voor email, kan het proces op veel meer mogelijkheden ondersteund worden door een nieuw informatiesysteem.

Door in eerste instantie op functies te concentreren, wordt een (proces)inrichting niet beperkt door de wijze waarop het proces voorheen is ingericht. Daarnaast worden vergelijkbare processen zichtbaar, door de functies hiervan te definiëren.

Naast de beschrijving van de functie, is ook het beschrijven van het bijbehorende context van belang. De functie beschrijft ‘wat’ er moet gebeuren. De context geeft weer binnen welke omstandigheden een functie uitgevoerd moet worden. In bovenstaande voorbeeld maakt het groot verschil of ‘het informeren van klanten’ betrekking heeft op enkele tientallen klanten per jaar, of honderden per dag. Dit geeft het verschil weer of het hier gaat om een kernproces of om een ondersteunend proces. Wat is het belang van het proces waarnaar gekeken wordt? Is het “versturen van facturen” de kerncompetentie van een organisatie of gaat het hier om een sporadische ondersteuning van een ander proces.

De functie verandert niet door de context, maar het relatieve belang van een proces kan daardoor wel veranderen. Het versturen van een tiental brieven per maand, biedt namelijk zeer minimale grond voor een (grote) investering.

In de loop van het onderzoek zal altijd de functie van een proces benadrukt worden.

Wanneer een (her)ontwerp niet voldoet aan de functie-eisen, is het ontwerp zonder waarde. Of wanneer de functie van een proces niet eenduidig geformuleerd kan worden, is de discussie over de functie veel belangrijker dan eventuele ondersteunende softwarepakketten. Want welk pakket moet aangeschaft worden, wanneer niet duidelijk is welke functie(s) het moet ondersteunen?

4.5 De structuur van een bedrijfsproces

Een proces kan op een meer gedetailleerd niveau beschreven worden, namelijk de beschrijving van de daadwerkelijke informatiestroom. Volgorde van bewerking is dan de basis van een bedrijfsproces. Een proces is een gekoppelde serie van handelingen die, door gebruik te maken van resources, een waardevol resultaat opleveren. Een resource kan alles zijn, wat een bepaalde taak uit kan voeren. Dit kan dus variëren van medewerker tot printer.

Een proces laat zich op dit niveau vaak het beste beschrijven door de veranderingen in eigenschappen van het bewerkte object. “De afhandeling van een schadeclaim” geeft een duidelijker beeld van het proces, dan een opsomming van de losse activiteiten die daarvoor zorgdragen. Een proces wordt dus over het algemeen direct gekoppeld aan een product.

Voor verdere bespreking van processen en waar deze uit bestaan is het goed een aantal begrippen eenduidig te formuleren. Dit omdat er vaak verschillend definities aangehouden

worden over terminologie binnen procesontwerp. In dit onderzoek wordt de terminologie aangehouden zoals die wordt aangereikt door het proces architectuur model. (Joosten, 2002)

Een krachtige manier om een begrip vast te leggen is door enkele criteria aan te reiken, waarmee elementen uit een willekeurig bedrijfproces vergeleken kunnen worden. Definities bieden vaak een moeilijk hanteerbaar kader en geven weinig handvatten voor hoe een begrip geplaatst kan worden binnen een organisatie.

4.6 Proces Architectuur Model

Bovenstaande invalshoeken kunnen duidelijk weergegeven worden in het Proces Architectuur Model (figuur 11). Voordat dit model verder uitgewerkt wordt, moet hierbij opgemerkt worden dat dit model relationeel opgezet is. De opbouw van de figuur suggereert namelijk een hiërarchische ordening. Dat zou (kunnen) gelden voor één concreet proces, maar zeker niet als conceptuele opbouw van een generiek proces.

Daarnaast worden, in tegenstelling tot de hiërarchische procesindeling van Harmon (2003), in het PAM de activiteiten wel verder onderverdeeld.

Voor een goede en gedetailleerde bespreking van workflow, is deze opdeling essentieel.

De zes lagen uit het model zullen nu worden besproken.

Waardeketen

Bedrijfsprocessen als kerncompetenties worden in het model gepositioneerd door het aandeel in de waardeketen te bepalen. Hierdoor wordt de strategische positie van de organisatie duidelijk en hoe deze past in de keten van grond- tot eindproduct. Belangrijk op dit niveau van procesbeschrijving is de interactie tussen de verschillende schakels in de totale waardeketen en hoe de organisatie zich verhoudt tot andere organisaties die een vergelijkbare positie in de waardeketen innemen. Daarbij speelt de eerdergenoemde invulling van de organisatiefunctie een belangrijke rol.

In administratieve processen wordt het steeds moeilijker een traditionele waardeketen te onderscheiden. Door

integratie van bedrijfsonderdelen van verschillende organisaties, vervagen de organisatiegrenzen steeds meer. Deze nieuwe indeling van de waardeketen wordt ook wel aangeduid met (dynamisch) waardenweb.

Processen

Een proces vormt een schakel in de waardeketen, waarvoor één partij verantwoordelijk is voor het hierin afgesproken werk (R. Joosten, 2004). Hierbij is het proces afhankelijk van

Figuur 11 - Proces Architectuur Model (Joosten, 2002) Waardeketen

Processen

Procedures

Activiteiten

Handelingen

Gebeurtenis