UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE

Transcriptie

1 UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR Gebruik van een standaard Enterprise Architecture modelleertaal voor het ontwerpen van een serviceconcept, proces en onderliggende architectuur Masterproef voorgedragen tot het bekomen van de graad van Master of Science in de Toegepaste Economische Wetenschappen: Handelsingenieur Matthias Deforche Onder leiding van Prof. dr. Geert Poels

2 II

3 UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR Gebruik van een standaard Enterprise Architecture modelleertaal voor het ontwerpen van een serviceconcept, proces en onderliggende architectuur Masterproef voorgedragen tot het bekomen van de graad van Master of Science in de Toegepaste Economische Wetenschappen: Handelsingenieur Matthias Deforche Onder leiding van Prof. dr. Geert Poels III

4 Vertrouwelijkheidsclausule PERMISSION Ondergetekende verklaart dat de inhoud van deze masterproef mag geraadpleegd en/of gereproduceerd worden, mits bronvermelding. Naam student: Matthias Deforche I

5 Woord vooraf Graag wil ik Prof. dr. Geert Poels bedanken voor de feedback en het begeleiden van deze masterproef, niet alleen voor de individuele begeleiding maar ook voor de relevante kennis die overgedragen werd bij de colleges aan de Universiteit Gent. Ook Prof. Frederik Gailly droeg daarbij de nodige kennis over die ik kon gebruiken voor deze masterproef en verder kan gebruiken in de toekomst. Verder wil ik ook nog Michaël Verdonck bedanken voor de feedback en de hulp bij het structureren van deze masterproef. Als laatste wil ik ook graag mijn ouders bedanken die mij de opportuniteit gaven om aan de Universiteit Gent te kunnen studeren. I

6 Inhoudsopgave TITELBLAD... VERTROUWELIJKHEIDSCLAUSELE... WOORD VOORAF... I INHOUDSOPGAVE... II LIJST GEBRUIKTE AFKORTINGEN... VII LIJST FIGUREN... VIII LIJST TABELLEN... IX DEEL I: SITUERING & PROBLEEMSTELLING HET BELANG VAN IT VANDAAG EN VOOR DE TOEKOMST BUSINESS EN IT ENTERPRISE ARCHITECTURE: DEFINITIE ENTERPRISE ARCHITECTURE: ARCHIMATE SERVICES IN ONZE ECONOMIE SERVICE BLUEPRINTING PROBLEEMBESCHRIJVING & ONDERZOEKSVRAAG FRAMEWORK... 8 DEEL II: ENTERPRISE ARCHITECTURE ZACHMAN TOGAF VIEWPOINTS IN ARCHIMATE VIEWPOINT VS VIEW: DEFINITIE CLASSIFICATIE VIEWPOINTS ARCHIMATE ALS DE MODELLEERTAAL DEEL III: CONCEPTEN SERVICE BLUEPRINTING ACTIES KLANTEN ZICHTBARE ACTIES WERKNEMERS ONZICHTBARE ACTIES WERKNEMERS II

7 ONDERSTEUNENDE PROCESSEN MANAGEMENTFUNCTIES FYSIEKE BEWIJZEN OVERIGE CONCEPTEN OVERZICHT SERVICECONCEPTEN ARCHIMATE ARCHIMATE (2.0) STRUCTUUR Business laag Applicatie laag Technologie laag Extensies Motivatie extensie Implementatie & migratie extensie RELATIES OVERZICHT CONCEPTEN EN RELATIES IN ARCHIMATE Business concepten Applicatie concepten Technologie (infrastructuur) concepten Motivatie concepten Implementatie en migratie concepten Relatieconcepten DEEL IV: PRAKTIJKANALYSE SERVICE BLUEPRINTING IN DE PRAKTIJK SERVICE BLUEPRINTING WORKSHOP Het objectief en de service Betrokkenen Aanpassingen Voorstelling van het meest frequente Discussies Klantgericht blijven Inzichten Aanbevelingen Gebruik VOORBEELDEN SERVICE BLUEPRINTS Hotelbezoek Restaurant Cafetaria universiteit III

8 CONCLUSIE ARCHIMATE IN DE PRAKTIJK: ARCHISURANCE ORGANIZATION VIEWPOINT Serviceconcepten in de organization viewpoint ACTOR CO-OPERATION VIEWPOINT Serviceconcepten in actor co-operation viewpoint BUSINESS FUNCTION VIEWPOINT Serviceconcepten in business function viewpoint APPLICATION CO-OPERATION VIEWPOINT Serviceconcepten in application co-operation viewpoint CONCLUSIE DEEL V: ONDERZOEK KLANTGERICHT VS. BUSINESSGERICHT ANALYSE BEIDE MODELLEERTALEN VIA CONCEPTEN Service blueprinting vs. Business laag Service blueprinting vs. applicatie laag Service blueprinting vs. technologie laag Service blueprinting vs. Motivatie extensie Service blueprinting vs. Implementatie & migratie extensie CONCLUSIE ANALYSE VAN EEN SERVICE VIEWPOINT Afzonderlijke viewpoints Combinatie van lagen en extensies voor een viewpoint Alles binnen één viewpoint CONCLUSIE DEEL VI: RESULTAAT DEFINIËRING CONCEPTEN LIJNINTERFACES PERCEPTIBEL BEWIJS AANGEPAST METAMODEL AANGEPAST BUSINESS METAMODEL AANGEPAST APPLICATIE METAMODEL AANGEPAST TECHNOLOGIE METAMODEL IV

9 3. VISUALISATIES DUIDELIJKHEID IN DE SEMANTIEK ONDERSCHEID IN SYMBOLEN TRANSPARANTIE IN SEMANTIEK MANAGEMENT IN COMPLEXITEIT COGNITIEVE INTEGRATIE VISUELE EXPRESSIVITEIT GEBRUIK VAN TEKST VISUALISATIES NIEUWE CONCEPTEN Visualisaties lijnen Evaluatie visualisaties lijnen Visualisaties perceptibel bewijs Evaluatie visualisaties perceptibel bewijs CLASSIFICATIE & DEMONSTRATIE CLASSIFICATIE SERVICE BLUEPRINT VIEWPOINTS SERVICE BLUEPRINT IN ARCHIMATE Business service blueprint viewpoint Business service blueprint demonstratie Applicatie service blueprint viewpoint Applicatie service blueprint demonstratie Technologie service blueprint viewpoint Technologie service blueprint demonstratie DEEL VII: CONCLUSIE & VERDER ONDERZOEK CONCLUSIE VERDER ONDERZOEK LIJST VAN DE GERAADPLEEGDE WERKEN BIJLAGEN... A A. ARCHIMATE: CONCEPTEN & RELATIES... A B. RELATIES BINNEN ARCHIMATE... B Relaties kernconcepten en implementatie & migratie extensie... B Relaties motivatie extensie... B C. SERVICE BLUEPRINT: HOTELBEZOEK... C D. KLASSIEKE SERVICE BLUEPRINT: RESTAURANT... D E. SERVICE BLUEPRINT MET VIRTUELE ZONE: RESTAURANT... E F. SERVICE BLUEPRINT: CAFETARIA UNIVERSITEIT... F G. VOORBEELD ARCHIMATE DRIE LAGEN IN ÉÉN VIEWPOINT... G V

10 H. ORGANIZATION VIEWPOINT... H I. ACTOR CO-OPERATION VIEWPOINT... I J. BUSINESS FUNCTION VIEWPOINT... J K. APPLICATION CO-OPERATION VIEWPOINT... K VI

11 Lijst gebruikte afkortingen Information Technology Enterprise Architecture Strategic Alignment Model Institute of Electrical and Electronics Engineers Moment of Truth Business Process Modeling Notation Enterprise Architecture Framework Informatie Systeem IT EA SAM IEEE MoT BPMN EAF IS VII

12 Lijst Figuren FIGUUR 1: BUSINESS/ IT ALIGNMENT FRAMEWORK R. MAES... 3 FIGUUR 2: ONDERZOEKSMETHODE CONCEPTUELE EVALUATIE... 9 FIGUUR 3: TOGAF ADM FIGUUR 4: TOGAF & ARCHIMATE (BIZZDESIGN) FIGUUR 5: CLASSIFICATIESYSTEEM VIEWPOINTS FIGUUR 6: SERVICE CONCEPTEN IN SERVICE BLUEPRINTING FIGUUR 7: BUSINESS LAAG FIGUUR 8: APPLICATIE LAAG FIGUUR 9: TECHNOLOGIE LAAG FIGUUR 10: MOTIVATIE EXTENSIE FIGUUR 11: IMPLEMENTATIE & MIGRATIE EXTENSIE FIGUUR 12: METAMODELLEN VOOR VERSCHILLENDE LEVELS VAN SPECIALISATIE FIGUUR 13: VIRTUELE ZONES IN SERVICE BLUEPRINTING (BENGHOZI ET AL.) FIGUUR 14: ORGANIZATION VIEWPOINT CLASSIFICATION FIGUUR 15: ACTOR CO-OPERATION VIEWPOINT CLASSIFICATION FIGUUR 16: BUSINESS FUNCTION VIEWPOINT CLASSIFICATION FIGUUR 17: APPLICATION CO-OPERATION VIEWPOINT CLASSIFICATION FIGUUR 18: VERGELIJKING OVERLAP CONCEPTEN SEMANTISCH VELD FIGUUR 19: AANGEPAST BUSINESS METAMODEL FIGUUR 20: AANGEPAST APPLICATIE METAMODEL FIGUUR 21: VISUALISATIE LIJN VAN INTERACTIE FIGUUR 22: VISUALISATIE LIJN VAN ZICHTBAARHEID FIGUUR 23: VISUALISATIE LIJN VAN INTERNE INTERACTIE FIGUUR 24: PERCEPTIBEL BUSINESSBEWIJS FIGUUR 25: PERCEPTIBEL APPLICATIEBEWIJS FIGUUR 26: SERVICE BLUEPRINT VIEWPOINT CLASSIFICATIE FIGUUR 27: HOTELBEZOEK: BUSINESS SERVICE BLUEPRINT FIGUUR 28: HOTELBEZOEK: APPLICATIE SERVICE BLUEPRINT FIGUUR 29: HOTELBEZOEK: TECHNOLOGIE SERVICE BLUEPRINT VIII

13 Lijst Tabellen TABEL 1: CONCEPTEN SERVICE BLUEPRINTING TABEL 2: BUSINESS CONCEPTEN TABEL 3: APPLICATIE CONCEPTEN TABEL 4: TECHNOLOGIE CONCEPTEN TABEL 5: MOTIVATIE CONCEPTEN TABEL 6: IMPLEMENTATIE EN MIGRATIE CONCEPTEN TABEL 7: RELATIES KERNCONCEPTEN TABEL 8: RELATIES MOTIVATIE EXTENSIE TABEL 9: EVALUATIE SERVICE BLUEPRINT:HOTELBEZOEK TABEL 10: EVALUATIE KLASSIEKE SERVICE BLUEPRINT: RESTAURANT TABEL 11: EVALUATIE SERVICE BLUEPRINT MET VIRTUELE ZONES TABEL 12: EVALUATIE SERVICE BLUEPRINT CAFETARIA TABEL 13: INDICATIEVE ANALYSE SERVICE BLUEPRINT VS. BUSINESS LAAG TABEL 14: INDICATIEVE ANALYSE SERVICE BLUEPRINT VS. APPLICATIE LAAG TABEL 15: INDICATIEVE ANALYSE SERVICE BLUEPRINT VS. TECHNOLOGIE LAAG TABEL 16: INDICATIEVE ANALYSE SERVICE BLUEPRINT VS. MOTIVATIE EXTENSIE TABEL 17: INDICATIEVE ANALYSE SERVICE BLUEPRINT VS. IMPLEMENTATIE & MIGRATIE EXTENSIE TABEL 18: DEFINITIE NIEUWE LIJNCONCEPTEN IN BUSINESS LAAG TABEL 19:DEFINITIE NIEUWE LIJNCONCEPTEN IN APPLICATIE LAAG TABEL 20: DEFINITIE NIEUWE LIJNCONCEPTEN IN TECHNOLOGIE LAAG TABEL 21: PERCEPTIBEL BUSINESSBEWIJS TABEL 22:PERCEPTIBEL APPLICATIEBEWIJS TABEL 23: SERVICE BLUEPRINT CONCEPTEN IN AANGEPASTE BUSINESS LAAG TABEL 24: SERVICE BLUEPRINT CONCEPTEN IN AANGEPASTE APPLICATIE LAAG TABEL 25: SERVICE BLUEPRINT CONCEPTEN IN AANGEPASTE TECHNOLOGIE LAAG IX

14 DEEL I: SITUERING & PROBLEEMSTELLING We beginnen in DEEL I met het situeren van de onderwerpen rond Informatie Technologie (IT) en Services. We geven meer uitleg over de toekomst die weggelegd is voor IT en wat de mogelijke gevolgen hiervan zijn. Daarna situeren we ook het belang die services hebben in onze economieën en waarom we hier meer aandacht aan moeten besteden. Zowel de servicesector als de IT-sector spelen een belangrijke rol in onze economie, wat echter ontbreekt bij het analyseren van beide sectoren is hoe men deze twee werelden kan combineren om betere inzichten te verkrijgen. Dit zal ons brengen bij de probleemstelling en de onderzoeksvragen waar we doorheen deze paper een antwoord op zoeken. Het is aan de hand van een modelleertaal in de servicesector (service blueprinting) en een modelleertaal binnen IT (ArchiMate) dat we de mogelijkheden gaan onderzoeken om beiden werelden samen te brengen. De modelleertalen worden in DEEL II en DEEL III geanalyseerd om de lezer voldoende informatie te voorzien bij het verdere verloop van het onderzoek. Daarna wordt in DEEL IV de theorie aan de praktijk gelinkt en kijken we hoe de modellen in de praktijk worden gebruikt. Wanneer beide modelleertalen duidelijk geanalyseerd zijn, kunnen we overgaan naar het uiteindelijke onderzoek in DEEL V en de resultaten die daaruit volgen in DEEL VI. 1. Het belang van IT vandaag en voor de toekomst Dit jaar, in het jaar 2016, is het grote topic van The World Economic Forum de vierde industriële revolutie. Het is een golf van technologisch ontwikkelingen die impact zullen hebben op onze levensstijl, maar ook op onze manier van werken en hoe de communicatie zal verlopen tussen personen onderling, maar ook tussen personen en machines. Een belangrijke quote van de CEO van General Motors, Mary Barra, geeft de impact van deze vierde industriële revolutie mooi weer: Ik geloof dat de auto-industrie meer zal veranderen in de komende vijf tot tien jaar, dan al de veranderingen die het al gekend heeft in de voorbije 50 jaar. (Forum, 2016, p.8) Deze nieuwe revolutie heeft echter niet enkel impact op de grote industrieën zoals de auto-industrie, maar op onze gehele economie. Meer en meer bedrijfsleiders worden zich hiervan bewust en daarmee ook van de opportuniteiten die technologie en IT kunnen bieden voor hun bedrijf/onderneming/organisatie. 1

15 In het vervolg van deze paper zullen we het woord onderneming gebruiken als overkoepelend begrip. Een onderneming betekent hier dus een ruimer begrip waar dus ook een organisatie of bedrijf onder valt. We houden hier dus geen rekening met het (economisch) verschil tussen deze woorden/entiteiten. We definiëren een onderneming als: Een verzameling van structuren dat een gezamenlijke set van doelen tracht te realiseren (TheOpenGroup, 2009, p. 5). De vierde industriële revolutie, met al zijn IT-componenten, maakt duidelijk dat IT een prominente plaats zal innemen in onze toekomst. De voorspellingen voor de toekomst zoals die voorgesteld zijn door The World Economic Forum zijn namelijk een hogere complexiteit van de IT en dit niet enkel op het technisch vlak maar voor de volledige toepassing ervan (Schwab & Howell, 2016). Het is natuurlijk niet zo eenvoudig om gewoon te investeren in de nieuwste technologieën en denken dat daarmee de kous af is. De technologie moet passen in de onderneming, een fit hebben met de business. Dit is echter niet zo vanzelfsprekend. Daarom is een goede onderbouwde kennis nodig vooraleer men aanpassingen kan doorvoeren. 1.1 Business en IT Het samenbrengen van business en IT is geen vanzelfsprekend onderwerp. Henderson en Vankatraman (1999) deden belangrijk onderzoek hierin dat beter bekend staat onder het Engelse begrip als: Business/IT alignment. Samen ontwikkelden zij het Strategic Alignment Model (SAM) om ervoor te zorgen dat zowel business, IT, strategie en activiteiten beter op elkaar afgestemd worden. Door deze alignering wordt IT niet enkel meer als een kost beschouwd en kan men het potentieel van IT beter begrijpen in de context van de onderneming. Zo ziet men IT bijvoorbeeld als een: competitief voordeel, ondersteuning bij de activiteiten, communicatiemiddel, (Henderson & Venkatraman, 1999). Gebaseerd op het SAM heeft R. Maes een aangepast framework voorgesteld (Maes, 2003). Er wordt hier een duidelijk onderscheid gemaakt tussen informatie en de technologie zelf. Deze geeft aan dat niet enkel de voorziening van informatie belangrijk is, maar voornamelijk het gebruik en het delen van deze informatie zelf toegevoegde waarde kan opleveren. Ook ziet men in dit framework het managen en ontwerpen van de onderneming als een architecturaal probleem waardoor er ook een specifieke focus op de structuur moet worden onderzocht. Om een goed huwelijk te bekomen tussen de business zijde enerzijds en de IT-zijde anderzijds is het dus ook belangrijk om te kijken naar het design en architectuur van de onderneming en dit alles ook zo goed mogelijk te communiceren (Maes & de Vries, 2008). Dit brengt ons dichter bij wat Enterprise Architecture eigenlijk allemaal inhoudt. 2

16 Figuur 1: Business/ IT alignment framework R. Maes 1.2 Enterprise Architecture: Definitie Onze economieën worden gekenmerkt door een hoge snelheid en complexiteit. De vierde industriële revolutie zal dit enkel nog maar versterken. Dit kan een dodelijke combinatie betekenen voor elke onderneming. Deze trends van snelheid en complexiteit zijn ook al eerder zichtbaar binnen de informaticasector (Winter & Fischer, 2006). Daarom is men meer en meer beginnen kijken naar manieren om overzicht te krijgen in deze complexiteit. In het prille begin van EA lag de focus voornamelijk op de modellering van de IT in de onderneming, later is men meer en meer business perspectieven erbij gaan betrekken. Er wordt verwacht dat de IT en de onderneming consistent, efficiënt en veerkrachtig zijn (Hoogervorst, 2004). Met veerkrachtigheid bedoelt men de mogelijkheid om te reageren op veranderingen en zich relatief gemakkelijk en snel aan te passen. Het is bij het implementeren van een consistent, efficiënt en veerkrachtig beleid waar EA kan helpen om dit te realiseren (Winter & Fischer, 2006). Zoals hiervoor aangegeven is dit een belangrijke evolutie voor EA, aangezien IT daardoor meer opportuniteiten kan bieden en dus niet enkel als een kostenpost wordt beschouwd. We kijken eerst naar de definitie van Architecture door het Institute of Electrical and Electronics Engineers ofwel IEEE. Dit is werelds grootste vereniging van professionals die al meer dan 900 standaarden heeft ontwikkeld in IT en vaak geciteerd wordt binnen academisch onderzoek. Definitie IEEE Standard , Architectuur: De fundamentele organisatie van een systeem, bestaande uit verschillende componenten, hun relaties ten opzichte van elkaar en de omgeving, en de elementen gaande over de design en evolutie (Jonkers et al., 2006, p.63) 3

17 Om duidelijk aan te tonen dat EA geen hol begrip is binnen de literatuur, kijken we naar het gebruik van Enterprise Architecture bij een van de grootste IT-consulting bedrijven in de wereld, namelijk Capgemini. Daarbij stelde Capgemini, dat dagelijks werkt met EA, een eigen definitie op over de betekenis van EA (Rijsenbrij D. et al, 2002). Definitie, Capgemini, EA: Enterprise Architectuur is een coherente, consistente verzameling principes, verbijzonderd naar uitgangspunten, regels, richtlijnen en standaarden soms vastgelegd in patronen die beschrijft hoe een onderneming, de informatievoorziening, een informatiesysteem of een infrastructuur is vormgegeven en zich voordoet in het gebruik. (Op t Land, M.; Proper, E.; Waage, M.; Cloo, J.; Steghuis, 2009, p. 33) Uit beide definities blijkt dat Enterprise Architecture dus meer is dan enkel visualiseren. Het helpt bij het plannen, organiseren, communiceren en coördineren van de onderneming op een consistente en geïntegreerde manier. Enterprise Architecture Frameworks (Cf. infra) helpen daarbij om de logische structuur zichtbaar te maken en om te vermijden dat zaken zoals IT op een chaotische wijze worden geïmplementeerd. Het is met EA dan ook de bedoeling om een betere communicatie tussen de verschillende stakeholders (= personen die enig belang of betrokkenheid hebben bij de onderneming) mogelijk te maken door gebruik te maken van modellen. Een model is hier een schematische voorstelling van de realiteit dat toelaat om een duidelijk beeld te schetsen. Om echter tot zo een concreet model te komen is er nood aan een modelleertaal die gehanteerd kan worden. Wij maken gebruik van de ArchiMate modelleertaal om de gewenste output te realiseren. 1.3 Enterprise Architecture: ArchiMate Enterprise Architecture is een ruim begrip waar de modellering een onderdeel van vormt. Wij focussen ons hier op een specifieke taal die daarbij gehanteerd kan worden, namelijk de ArchiMate modelleertaal. De reden waarom we voor deze modelleertaal kiezen zal duidelijk worden in DEEL II waar we dieper ingaan op EA en de modelleertaal. Het is de bedoeling om met ArchiMate verschillende domeinen en relaties te beschrijven, daarbij kan men een aantal domeinen in architectuur onderscheiden (Jonkers, Quartel, van Gils, & Francken, 2012): - Structuur in de organisatie - De verschillende producten die worden geleverd - Business processen - Informatiesystemen 4

18 - Applicaties - Technische infrastructuur In elk van deze domeinen is het mogelijk om gebruik te maken van modelleertalen die specifiek gericht zijn op een bepaald domein. Het moet wel duidelijk zijn dat de specifieke modelleertalen allemaal binnen elk domein afzonderlijk zijn (Jonkers, Quartel, et al., 2012). Wat de precieze relatie is tussen deze domeinen onderling wordt vaak genegeerd. ArchiMate daarentegen is een modelleertaal die ervoor zorgt dat de relaties tussen de verschillende domeinen duidelijk worden om zo een geïntegreerd beeld te krijgen van de architecturen in de onderneming. Oorspronkelijk lag de focus binnen ArchiMate voornamelijk op het modelleren van de IT en infrastructuur binnen de onderneming. Zoals duidelijk werd gemaakt door Henderson en Vankatraman (1999) biedt IT veel meer mogelijkheden dan enkel een ondersteunende rol. Dit inzicht zorgde ervoor dat Enterprise Architecture eveneens meer evolueerde naar een meer business georiënteerde aanpak. Dit houdt in dat men meer en meer gaat kijken naar de services en producten die men aan de klanten kan aanbieden. Daarom is ook ArchiMate geëvolueerd (naar ArchiMate 2.0) om meer en meer business gerelateerde zaken te kunnen voorstellen (The Open Group, 2013). Hiervoor zijn dan ook de nodige concepten (Cf. infra) voorzien. Om alle concepten binnen ArchiMate te gebruiken bij het modelleren van de onderneming zijn verschillende tools voorhanden. Wij werken in deze paper met de gratis beschikbare Archi-tool 1 die ons kan helpen bij het realiseren van een model in ArchiMate. We hebben nu een ruw beeld geschetst van wat Enterprise Architecture allemaal inhoudt en welke rol ArchiMate als modelleertaal hierin speelt. Men is hierbij meer en meer geëvolueerd om de business van de onderneming voor te stellen, daarmee kan men kijken hoe services en producten worden aangeboden aan klanten. Het aanbieden van een service is echter iets anders dan het aanbieden van een reëel product. 2. Services in onze economie Een service kan gedefinieerd worden als een verzameling van acties die uitgevoerd worden door een entiteit, de dienstverlener, die antwoord probeert te bieden op een verzoek komende van een andere entiteit, de klant (Gbaguidi, Znaty, & Hubaux, 1996). Het aanbieden van een service is niet hetzelfde 1 5

19 als het aanbieden van een tastbaar product. De belangrijkste verschillen van een product ten opzichte van een service zijn (Shostack, 1984): - Geen fysiek bezit mogelijk - Geen stockage mogelijk - Grotere heterogeniteit - Consumptie is simultaan met productie Deze verschillen maken duidelijk dat een product en een service een andere aanpak vergen wanneer men deze analyseert. De tertiaire sector (de servicesector) is de grootste bron in waarde-creatie voor het bruto nationaal product voor vele landen over de hele wereld. Door het belangrijke aandeel van services in onze economieën, is het belangrijk om ook service-innovatie te realiseren om zo steeds betere services te kunnen aanbieden en te blijven groeien. Het is typerend bij een service om contact en interactie met de klant te hebben waardoor consumptie en productie dus simultaan gebeuren, de kwaliteit van een service wordt daarom ook eerder subjectief beoordeeld (Gronroos, 1988). We spreken daarom voor deze belangrijke contacten tussen klanten en de onderneming over een Moment of Truth (MoT) of waarheidsmoment. Dit is de plaats en tijd waar een dienstverlener kan bewijzen wat de kwaliteit van de service inhoudt (Normann, 1984). Na dit moment is de klant weg en is er geen mogelijkheid meer tot wijzigen of ongedaan maken van de interactie, een oordeel is geveld. Om een slechte service te vermijden is het dus belangrijk dat men het volledige serviceproces kan analyseren met een focus op de klant (Grönroos, 2001). Zo krijgt men een beter beeld over hoe de klant de service percipieert. Een ander belangrijk kenmerk van een service is de hoge heterogeniteit die voornamelijk komt uit het feit dat elke klant anders is en de service dient aangepast te worden aan de klant. Dit resulteert in een hoge variabiliteit bij de activiteiten in het serviceproces wat een direct effect op de kosten, tijd, aantal taken, fouten, van de onderneming teweegbrengt (Zeithaml VA, Bitner MJ, 2000). Het is dus belangrijk om zo flexibel en efficiënt mogelijk te kunnen inspelen op alle mogelijke verrassingen. Men kan dit doen door de processen zo te ontwerpen dat men kan omgaan met de variabiliteit en deze zelfs kan reduceren. Dit vergt een goede kennis van alle mogelijke activiteiten binnen het proces waardoor grote inspanningen in het management van de processen nodig zijn (Fließ & Kleinaltenkamp, 2004). Er is er dus een nood aan een service-georiënteerde techniek die een goede analyse mogelijk maakt. 6

20 2.1 Service Blueprinting G. Lynn Shostack ontwikkelde Service Blueprinting om het mogelijk te maken om serviceprocessen in kaart te brengen. Dit is een techniek die resulteert in een visuele voorstelling om accuraat de processen in het servicesysteem weer te geven (Shostack, 1984). Belangrijk hierbij is dat deze blueprint moet kunnen gelezen worden door alle stakeholders, dus ook door de klanten. Zo kan er een objectief beeld gevormd worden dat iedereen begrijpt en gecommuniceerd kan worden. Service blueprinting focuste in het begin voornamelijk op het design van services, nu is het geëvolueerd naar een techniek dat hulp kan bieden op vlak van (Bitner, Ostrom, & Morgan, 2008): - Servicedesign - Kwaliteitsverbetering - Service innovatie - Strategische hervormingen met een focus op de klanten Belangrijk om te onthouden is dat het hele serviceproces wordt weergegeven vanuit het oogpunt van de klant. Via deze aanpak moet men zich kunnen inleven in de rol van de klant en welke stappen die allemaal ondergaat in het proces. 3. Probleembeschrijving & onderzoeksvraag We hebben nu een beeld geschetst van Enterprise Architecture en ArchiMate als modelleertaal. Ook hebben we gekeken naar wat een service eigenlijk inhoudt en waarom een andere soort analyse nodig is in vergelijking met het aanbieden van een product. We merken op dat er in het domein van Enterprise Architecture te weinig rekening wordt gehouden met de ervaringen van de klant bij de modellering. Men identificeert de relaties op vlak van de business, de applicaties en de technologie, zonder stil te staan bij de ervaringen van de klant. Dit terwijl een overgroot deel van de waarde in onze economieën wordt gerealiseerd door de servicesector en daarbij is het net belangrijk om te achterhalen wat klanten allemaal ervaren. De ervaringen van klanten bepalen immers mee hoe de kwaliteit van de service wordt beschouwd en daarmee ook de waarde die men aan de service toeschrijft. Het analyseren van een service vereist een andere aanpak dan het aanbieden van een tastbaar product, dit kan geanalyseerd worden met behulp van service blueprinting. Deze klantgerichte aanpak zorgt ervoor dat de volledige klantenervaring besproken wordt. Daarbij wordt er echter niet diep ingegaan op de ondersteunende processen en de infrastructuur. Nochtans is er vaak een complex geheel aan processen nodig om de service te kunnen 7

21 realiseren. Ook een goedwerkende IT-infrastructuur is in deze tijden vaak een cruciaal aspect in het gehele proces. In deze paper gaan we na wat de mogelijkheden zijn om de aanpak bij EA en de aanpak voor een service te combineren. Dit doen we door te kijken welke mogelijkheden er al zijn binnen de ArchiMate modelleertaal om serviceconcepten uit service blueprinting voor te stellen. Het resultaat zou een voorstelling moeten zijn waarbij de focus ligt op het proces die de klant doorloopt in relatie met de bedrijfsarchitectuur en de verschillende IT-elementen die nodig zijn om dit alles te realiseren. De onderzoeksvraag: Kan men in ArchiMate een service blueprint ontwerpen? Deze onderzoeksvraag kan worden opgedeeld in verschillende kleinere onderzoeksvragen die men moet stellen om tot een antwoord te komen. - Wat zijn de bestaande serviceconcepten in service blueprinting voor het modelleren van een serviceproces? - Wat zijn de bestaande concepten in ArchiMate? - Welke van de bestaande concepten in ArchiMate overlappen met de serviceconcepten die geïdentificeerd zijn in een service blueprint? - Wat is de functie van een service blueprint? - Wat is de functie van een model in ArchiMate? 4. Framework Om de onderzoeksvraag te kunnen beantwoorden moeten we weten welke de vereisten zijn om binnen ArchiMate een service blueprint te kunnen voorstellen. Wanneer de vereisten niet duidelijk zijn, zal men bij de ontwikkeling van een systeem op vele problemen en fouten stuiten. Daarom stelde Y. Wand en R. Weber zich de vraag: Hoe kunnen we de wereld modelleren opdat de ontwikkeling, implementatie, het gebruik en onderhoud van informatiesystemen op een eenvoudige en waardevolle manier kan verlopen (Yair Wand and Ron Weber, 2002, p363). Om een antwoord te formuleren op deze vraag ontwikkelden ze een framework dat ondersteuning biedt bij het onderzoek naar conceptuele vergelijkingen (Wand & Weber, 1993, 2002). Aan de hand van dit framework ontwikkelde Milton and Johnson (2012) een onderzoeksmethode om de BPMN modelleertaal te vergelijken met Service blueprinting (Milton & Johnson, 2012). Wij baseren ons op deze onderzoeksmethode (Cf. infra) om in dit geval ArchiMate met service blueprinting te kunnen vergelijken. 8

22 Daarbij zal gebruik gemaakt worden van de concepten die we terugvinden in service blueprinting en de concepten die terug te vinden zijn in ArchiMate. Aan de hand van deze vergelijking kunnen gelijkenissen en verschillen worden geïdentificeerd tussen beiden zoals voorgesteld in Figuur 2. Daarbij wordt impliciet gebruik gemaakt van de ontologie van elke modelleertaal als input. Het is zowel de bedoeling van service blueprinting als van ArchiMate om de werkelijkheid te kunnen voorstellen. De ontologie van de modelleertalen definiëren de mogelijkheden van de concepten om die realiteit voor te stellen (Milton & Johnson, 2012). De conceptuele evaluatie dient om te kijken naar hoe goed de voorstellingen in service blueprinting samengaan (overlap) met deze binnen ArchiMate. Vandaar dat de concepten in beide modelleertalen moeten worden onderzocht om daarna een kwalitatieve analyse te kunnen maken van de gelijkenissen en verschillen. Figuur 2: Onderzoeksmethode conceptuele evaluatie De methode die gehanteerd zal worden voor de conceptuele evaluatie van service blueprinting en ArchiMate bestaat uit vier stappen: 1. Bepalen van de set van concepten in service blueprinting Bij de eerste stap worden de concepten in service blueprinting geïdentificeerd om dan als referentie aan te duiden. Deze worden gehaald uit een analyse van de literatuur (DEEL III) en geverifieerd met praktijkvoorbeelden (DEEL IV). 2. Bepalen van de set van concepten in ArchiMate De tweede stap bestaat uit het identificeren van de concepten in ArchiMate die daarna met de referentieconcepten kunnen worden vergeleken. Ook hier worden de concepten gevonden op basis van de literatuur (DEEL II + III) en geverifieerd met praktijkvoorbeelden (DEEL IV). 9

23 3. Analyse van de sets aan concepten & kwalitatieve analyse De derde stap bestaat uit een vergelijking (DEEL V) van de gevonden concepten die opgelegd werden door de ontologie in beide modelleertalen. Doordat vergeleken wordt op het niveau van concepten gaat men naar een niveau waar een zekere subjectiviteit aan te pas komt (Milton & Johnson, 2012). Vandaar dat een goed onderzoek in literatuur nodig is en een analyse van praktijkvoorbeelden bij zowel service blueprinting als ArchiMate om een oordeel te kunnen vellen over eventuele overlap in de concepten van beide modelleertalen. 4. Aanbevelingen Indien serviceconcepten zouden ontbreken in ArchiMate geven we aan welke dit zijn en geven we eveneens aanbevelingen voor nieuwe concepten alsook hoe deze kunnen worden geïmplementeerd om een betere voorstelling te bekomen. Daarbij kijken we terug naar hoe deze concepten zouden kunnen passen in de bestaande ontologie van ArchiMate en demonstreren we deze aan de hand van een uitgewerkt voorbeeld (DEEL VI). Indien het mogelijk is om met de bestaande concepten in ArchiMate een service blueprint te maken en dus geen nieuwe concepten dienen gedefinieerd worden, illustreren we dit eveneens met een voorbeeld (DEEL VI). DEEL II: ENTERPRISE ARCHITECTURE Vooraleer we kunnen starten met ons onderzoek, moeten bepaalde zaken in Enterprise Architecture kunnen verklaren. Dit deel gaat dieper in op Enterprise Architecture opdat dit ons toelaat om de onderliggende functie van ArchiMate duidelijk te maken. Het is de bedoeling om met EA de architectuur van een onderneming in kaart te brengen. Dit kan men doen door op een gestructureerde en consistente manier te werk te gaan via verschillende Enterprise Architecture Frameworks (EAF) die beschikbaar zijn. Een EA framework geeft richtlijnen over hoe men tot een EA-model (zoals ArchiMate) kan komen en hoe deze te gebruiken volgens gedefinieerde elementen en methodes. Daarmee zou men de onderneming in kaart kunnen brengen, maar vooral hoe dit alles met elkaar in relatie staan en hoe ze bijdragen tot de strategie van de onderneming. Een EAF heeft tot doel om de onderneming beter te begrijpen en op zoek te gaan naar opportuniteiten, zwakheden en inconsistenties (TheOpenGroup, 2009). We bespreken hier kort eerst twee bekende EAFs: het Zachman Framework en TOGAF. Het Zachman framework maakt het best duidelijk wat het belang van viewpoints (Cf. infra) 10

24 zijn binnen ArchiMate terwijl TOGAF de reden aanreikt waarom we ArchiMate zullen gebruiken in plaats van een andere modelleertaal. 1. Zachman Het werk van J. A. Zachman (1987) is vaak geciteerd in de literatuur naar aanleiding van zijn onderzoek binnen information systems architecture. Dit onderwerp kreeg meer aandacht door de toenemende complexiteit binnen de technologie en eveneens de vrees dat de business gedesintegreerd geraakt van de IT. Daardoor is een overzicht in de architectuur en in informatiesystemen noodzakelijk opdat een zekere orde en controle kan gehandhaafd worden (J. A. Zachman, 1987). Dit resulteerde in een framework om de architecturale concepten en specificaties te verduidelijken om goede communicatie mogelijk te maken. De kennis hiervoor is natuurlijk gehaald uit het domein van de architectuur zelf, met eeuwen aan ervaring. Het is aan de architect om de noden van de klant te begrijpen en ervoor te zorgen dat deze gerealiseerd kunnen worden, rekening houdend met allerlei beperkingen. Ook na de ontwerpen van de architect voor de klant, moet duidelijkheid bestaan over hoe men deze gaat implementeren. Dit ligt in lijn met wat we in DEEL I reeds hebben aangehaald bij het framework van R. Maes (2003) dat de structuur van de onderneming een architecturaal probleem is. Wat hier duidelijk uit blijkt is dat men bij voorstellen van de onderneming de rol van een architect op zich moet nemen, dit zal eveneens zo zijn wanneer men gebruik maakt van ArchiMate. Als architect moet het uiteindelijke resultaat voldoen aan alle wensen en beperkingen die opgelegd worden door verschillende stakeholders. Om dit te realiseren zal een architect ook verschillende outputs of viewpoints (Cf. infra) realiseren gedurende het hele proces. Het framework dient om duidelijkheid te scheppen over de architectuur van de onderneming maar zegt niets over de implementatie of welke tools dienen gebruikt worden (J. Zachman, 2003). Het framework focust voornamelijk op een goed begrip van alle stakeholders aan de hand van de verschillende voorstellingen. Hoe men de architectuur ontwikkeld, wordt niet uitgelegd aan de hand van bijvoorbeeld een proces (Sessions, 2007). Er is echter ook geen standaard en er bestaan geen expliciete regels die men moet volgen bij het uitwerken van het framework (Urbaczewski & Mrdalj, 2006). Dit in tegenstelling tot TOGAF dat wel expliciete regels hanteert en standaarden vooropstelt die gebruikt kunnen worden. 11

25 2. TOGAF TOGAF is eveneens een EAF voor het vastleggen van een architectuur. Het voorziet een gedetailleerde methode en een set van tools ter ondersteuning van de aanvaarding, productie, gebruik en onderhoud van een enterprise architecture. TOGAF (en ArchiMate) worden ter beschikking gesteld door The Open Group. Dit is een consortium van meer dan 500 bedrijven met voornamelijk als doel om IT-standaarden aan te reiken op een globale schaal. TOGAF is dus onder andere zo een standaard die men probeert te verspreiden. De kern van TOGAF is de Architecture Development Method (ADM). Dit bestaat uit een iteratieve cyclus van definiëring en realisatie van de architectuur in de onderneming om zo de ontwikkeling op een gecontroleerde wijze aan te pakken en deze daarbij af te stemmen op de business goals en opportuniteiten (TheOpenGroup, 2009). Figuur 3: TOGAF ADM Figuur 3 is een grafische voorstelling van de cyclus van ADM. Daarbij wordt duidelijk dat ADM zich in verschillende fases opdeelt (elke bol stelt een andere fase voor). Elk van deze fases richt zich op een bepaald aspect binnen de architectuur. Via een iteratief proces waarbij men de verschillende fases doorloopt kan de onderneming in kaart gebracht worden zonder iets over het hoofd te zien. Bij het 12

26 doorlopen van deze fases zullen tal van outputs gerealiseerd worden. Dit kunnen process flows zijn, project plannen, benodigde architecturale componenten, (Ed et al., 2012). TOGAF is een van de meest uitgebreide EAFs. Het bezit duidelijke richtlijnen over de te nemen beslissingen, maar ook over het gebruik van de middelen in IT en over de architecturale principes die gehanteerd kunnen worden (Urbaczewski & Mrdalj, 2006). TOGAF reikt een hele reeks zaken aan die dienen als ondersteuning, dit gebeurt via (Jonkers, Quartel, et al., 2012): - Een proces (= a process) Dit is een manier van werken om de beschrijving van architecturen te realiseren. Dit kunnen richtlijnen zijn, technieken, voorbeelden uit de realiteit, - Perspectieven (= viewpoints) Aanreiken van een set van verschillende perspectieven voor de verschillende stakeholders, dit brengt verschillende elementen met zich mee die corresponderen met een betrokken perspectief. - Archief (=repository) Via een voor-gedefinieerde archief dat architecturale voorwerpen en referentiemodellen aanreikt, kunnen een aantal concretere zaken ondersteuning bieden. Deze kunnen helpen bij het concreter uitwerken van de EA. Wat echter ontbreekt is een concrete taal, een manier van modelleren (= a way of modelling ) voor het beschrijven van de architectuur. Dit is iets waar ArchiMate meer op focust, zie Figuur 4. Figuur 4: TOGAF & ArchiMate (BiZZdesign) 13

27 3. Viewpoints in ArchiMate Bij het bestuderen van het Zachman framework en TOGAF zal duidelijk geworden zijn dat men de rol van architect moet aannemen wanneer men de architectuur van een onderneming wil visualiseren. Dit resulteert in verscheidene outputs voor verschillende stakeholders. We gaan in dit hoofdstuk na wat dit betekent binnen een modelleertaal zoals ArchiMate. Het opstellen van een goed functionerende bedrijfsarchitectuur kan een complex proces worden met een verscheidenheid aan visies, notaties en perspectieven van allerlei stakeholders. Om dit allemaal te kunnen onderscheiden van elkaar in een model of visuele voorstelling, wordt een beroep gedaan op viewpoints. Bij het Zachman Framework worden er verschillende outputs of viewpoints gerealiseerd, maar de relaties onderling zijn zeer beperkt. In ArchiMate daarentegen zijn viewpoints zo ontworpen om zowel het perspectief van een bepaalde stakeholder voor te stellen, evenals hoe deze verschillende perspectieven met elkaar verbonden kunnen zijn (The Open Group, 2013). ArchiMate gaat met zijn viewpoints dus meer op zoek naar een coherent geheel in de architectuur van de onderneming. Wanneer we in ons onderzoek op zoek willen gaan naar een manier om een service blueprint voor te stellen, dan zullen we rekening moet houden met viewpoints. Daarbij kijken we naar een manier hoe de verschillende viewpoints worden geclassificeerd. 3.1 Viewpoint vs View: definitie We maken een viewpoint duidelijk door het te vergelijken met een begrip dat hier dicht gerelateerd aan is, namelijk een view. De definities volgens The Open Group zijn: Een view: Een deel van een beschrijving van de architectuur dat correspondeert met een set van bedenkingen en een set van stakeholders. (TheOpenGroup, 2009, p. 32) Een viewpoint: Voorschrijft de concepten, modellen, analysetechnieken en visualisaties die door een view worden gebracht. (TheOpenGroup, 2009, p. 32) Kortom: een view is het beeld dat bepaalde stakeholders willen zien, terwijl een viewpoint een recept is dat gevolgd dient te worden, rekening houdend met bepaalde eisen en bedenkingen van de stakeholders. 14

28 3.2 Classificatie viewpoints Het is aan de architect om alle mogelijke bedenkingen van alle mogelijke stakeholders te identificeren en te vertalen in een coherent beeld van de realiteit (=AS-IS) of in hetgeen wat gewenst is (=TO-BE). Dit is geen gemakkelijk opdracht door de veelzijdigheid aan informatie van diverse partijen, waardoor een architect gebruik kan maken van de viewpoints om orde te scheppen in deze chaos. Dit resulteert in verscheidene viewpoints die ontworpen worden om een bepaalde stuk informatie zichtbaar te maken. Binnen ArchiMate kunnen de viewpoints, afhankelijk van hun opzet, geclasifficeerd worden volgens twee dimensies: Doel (=purpose) en Inhoud (=content). Het doel bestaat uit drie types van architectuurvoorstellingen: - Ontwerpen (=designing): deze design-viewpoints kunnen de architect helpen bij de transformatie van een initiële sketch tot een gedetailleerde voorstelling. - Beslissen (=deciding): deze decision-viewpoints brengen een beslissingsproces in kaart, vaak met de bedoeling om de relaties binnen verschillende architecturale domeinen duidelijk te maken. - Informeren (=informing): deze informing-viewpoints verklaren de architectuur aan alle betrokken stakeholders om een gemeenschappelijke verstandhouding te verkrijgen. Via deze architectuurvoorstelling wil men de neuzen in dezelfde richting krijgen. De tweede dimensie, de inhoud, maakt duidelijk in welke vorm van abstractie men de drie types viewpoints heeft uitgewerkt. Er zijn drie niveaus van abstractie mogelijk: - Overzichtelijk (=overview): hier worden meerdere lagen en aspecten in kaart gebracht om een globaler beeld weer te geven, zonder in veel detail te treden. - Samenhangend (=coherence): hier maakt de architect verbindingen tussen bepaalde lagen en aspecten binnen ArchiMate om mogelijke relaties te identificeren tussen bepaalde zaken. Het is dus specifieker dan het overview-niveau doordat er focus kan worden gelegd op bepaalde aspecten en dus al iets gedetailleerder op enkele zaken kan worden ingegaan. 15

29 - Gedetailleerd (=details): hier focust de architect zich op een bepaalde laag (business, applicatie, technologie) of een bepaald aspect binnen ArchiMate. Er kan dus een uitvoerige voorstelling worden gemaakt van het aspect dat men wil behandelen. Het classificatiesysteem van viewpoints binnen ArchiMate kan zelf ook grafisch voorgesteld worden, zie Figuur 5. Daarbij staat bij elke type van de doel dimensie (bovenste deel zeshoek) enkele voorbeelden van stakeholders die voornamelijk betrokken zijn bij de bijhorende viewpoint. Wanneer wij een serviceproces voorstellen in ArchiMate zullen we nagaan hoe deze viewpoint zich oriënteert binnen het classificatiesysteem. We kunnen uit Figuur 5 al opmaken dat we een meer informerende viewpoint zullen nodig hebben aangezien daar de klant als belangrijke stakeholder naar voor komt. Figuur 5: Classificatiesysteem viewpoints 4. ArchiMate als de modelleertaal Zoals reeds aangegeven, bestaan er meerdere EA frameworks. We hebben Zachman en TOGAF reeds besproken, maar ook bijvoorbeeld DoDaF is een EAF die men kan gebruiken. Naast ArchiMate bestaan er ook andere modelleertalen zoals BPMN en UML die er eveneens in slagen om IT gerelateerde zaken te voorzien in het business domein. Het probleem met deze is dat ze echter voornamelijk worden toegepast in een geïsoleerde context waardoor ze geen geïntegreerd beeld weergeven van de onderneming (Peña & Villalobos, 2010). Door te focussen op bepaalde processen kan men echter wel in detail treden, maar is er minder aandacht voor relaties over verschillende domeinen heen (Jonkers, Quartel, et al., 2012). 16

30 Daarom focussen wij ons binnen EA op ArchiMate als de modelleertaal die een architect helpt bij het voorstellen van de onderneming. De ArchiMate modelleertaal kan daarbij ook complementair zijn met TOGAF. Beiden kunnen onafhankelijk van elkaar gebruikt worden, maar het is dus ook mogelijk om deze te combineren. Er is geen een-op-een relatie, maar toch correspondeert een groot deel van TOGAF ADM met ArchiMate. ArchiMate kan bijvoorbeeld eveneens met andere EAFs worden gebruikt, zoals bijvoorbeeld het Zachman Framework. Echter, omdat zowel TOGAF als ArchiMate uitgegeven worden door The Open Group, is er een grotere compatibiliteit tussen deze twee. Ook wordt verwacht dat de toekomst en ontwikkeling van beiden nog beter op elkaar afgestemd zullen worden met als doel de standaard te worden in EA (Jonkers, Proper, & Turner, 2009). DEEL III: CONCEPTEN Nu EA en de rol van ArchiMate met zijn viewpoints duidelijk geschetst zijn, kunnen we op zoek naar een antwoord op de onderzoeksvraag die we hebben geformuleerd in DEEL I. Vooraleer we hier echter antwoord op kunnen geven moeten we een antwoord geven op de deelvragen. Dit doen we door de eerste twee stappen van de onderzoeksmethode te volgen die in DEEL I werd uitgelegd, namelijk: Stap 1: Bepalen van de set van concepten in service blueprinting Stap 2: Bepalen van de set van concepten in ArchiMate Daarmee trachten we een antwoord te geven op de volgende deelvragen: - Wat zijn de bestaande serviceconcepten in service blueprinting voor het modelleren van een serviceproces? - Wat zijn de bestaande concepten in ArchiMate? We beginnen met het verduidelijken van de theorie en literatuur rond services via Service Blueprinting, daarna gaan we dieper in op ArchiMate. 1. Service blueprinting L. Shostack deed pionierswerk (1982) naar het design van een service en stelde daarbij een methode op om services te ontwerpen met een meer klantgerichte aanpak en een focus op de klantenervaring. Daarbij ontwikkelde ze de Line of visibility of de lijn van zichtbaarheid die duidelijk maakt wat wel en 17

31 niet zichtbaar is voor de klant in het serviceproces (L. Shostack, 1982). Voortbouwend op het design van een serviceproces, ontwikkelde J. Kingman-Brundage (1991) additionele elementen om de service nog beter in kaart te kunnen brengen. Hierbij sprak men eerder over een service map die kon gebruikt worden door het management om duidelijk te maken aan de werknemers wat hun plaats was in het totale plaatje van de service. In de service map kwam opnieuw de lijn van zichtbaarheid terug, maar nu met additionele elementen zoals (J Kingman-Brundage, 1991): - Line of interaction/ lijn van interactie Deze geeft de directe communicatie weer tussen de klant en de werknemers die aan de front line staan. Dit zijn de werknemers die de klant rechtstreeks kunnen aanspreken en waarmee men in contact komt. - Line of internal interaction/ lijn van interne interactie Wanneer deze lijn overschreden wordt, betekent dit een interne communicatie met de ondersteunende processen. Deze communicatie is dus niet enkel met werknemers onderling maar kan bijvoorbeeld ook tussen een klant en een reservatiesysteem zijn die gebruikt wordt binnen de onderneming. - Line of implementation/ lijn van implementatie Deze lijn maakt een scheiding met de rest van de processen en de managementfuncties. Het toont aan welke linken er kunnen gemaakt worden met de verantwoordelijkheden van het management. Service blueprinting en service maps worden vaak als gelijken beschouwd. We wijden niet uit over de verschillen en het ontstaan tussen beiden, maar gebruiken elementen uit beiden voor het realiseren van een goede service blueprint, net zoals Bitner et al. (2008) die opstellen. Ondanks dat service blueprinting al meer dan 30 jaar bestaat, beantwoordt het nog steeds aan de noden van vandaag waardoor het een wijdverspreide techniek blijft en gezien wordt als de standaard (Bitner et al., 2008). Daarom gebruiken we Service blueprinting als de modelleertaal voor het voorstellen van een service. Binnen een service blueprint is het belangrijk om zes componenten te identificeren (Bitner et al., 2008; J. Kingman-Brundage, 1991): - Acties die de klant onderneemt - Zichtbare (voor de klant) acties werknemers - Onzichtbare (voor de klant) acties werknemers - Ondersteunende processen 18

32 - Managementfuncties - Fysieke bewijzen Acties klanten De klant staat centraal binnen service blueprinting, daarom zijn de stappen die de klant ondergaat ook cruciaal. Deze stappen worden in chronologische volgorde in kaart gebracht, vaak bovenaan de blueprint. De reden van de positionering bovenaan is om duidelijk te maken dat de stappen van de klant de basis vormen en alle onderliggende processen deze stappen moeten supporteren. Zichtbare acties werknemers Alle acties die werknemers kunnen verrichten en direct zichtbaar zijn voor de klant, worden hier voorgesteld. Daarom spreekt men vaak van het frontoffice of -stage. Deze acties van werknemers hebben een directe impact op de klantenervaring. Een belangrijke (denkbeeldige) lijn die deze acties onderscheidt van de acties van de klant, is de lijn van interactie. Elke keer dat deze lijn wordt overschreden is er dus direct zichtbaar contact tussen de werknemer en de klant. In het vakjargon spreekt men hierbij van Moments of Truth of waarheidsmomenten zoals reeds in DEEL I al werd aangehaald. Dit is de plaats en tijd waar een dienstverlener kan bewijzen wat de kwaliteit van de service inhoudt. Het zijn dermate belangrijke momenten voor een onderneming aangezien de klant daarbij een direct oordeel zal vellen over de kwaliteit van de service. Onzichtbare acties werknemers De zichtbare en onzichtbare acties van werknemers worden gescheiden door de lijn van zichtbaarheid. Alles wat zich achter deze lijn bevindt, is niet zichtbaar voor de klant. Daarom spreekt men hier eerder van en backoffice of -stage. Dit wil echter niet zeggen dat deze niet meer waarneembaar kunnen zijn. Zo kan er bijvoorbeeld nog contact zijn via bijvoorbeeld telefoongesprekken en s. Ondersteunende processen Deze processen ondersteunen de acties die gemaakt worden door de werknemers of de klant. De ondersteunende processen worden gescheiden van de klant door de lijn van interne interactie. Managementfuncties De processen die in kaart worden gebracht, kunnen worden gelinkt aan de functies die het management moet realiseren. Deze linken worden duidelijk wanneer de lijn van implementatie wordt overschreden. (Deze wordt niet vermeld in de service blueprinting techniek van Bitner et al. (2008) maar wordt wel duidelijk vermeld door J. Kingman-Brundage waardoor we de managementfuncties als vervollediging op Bitner et al. toch vermelden.) 19

33 Fysieke bewijzen Al het tastbare waar de klant mee in aanraking kan komen gedurende het hele proces wordt beschreven in deze component. Het meer tastbaar maken van een service kan ervoor zorgen dat de klant meer waarde hecht aan de service en dragen bij tot de gepercipieerde kwaliteit. Vandaar dat deze component eveneens zeer belangrijk is en helemaal bovenaan geplaatst. Overige concepten De vorige concepten worden in Figuur 6 nog eens duidelijk gevisualiseerd. Met deze opdeling kan men dan acties toevoegen bij het frontoffice, backoffice of bij de ondersteuning. We spreken daarbij van een actiestroom wanneer er een opeenvolging is van acties. Het is ook mogelijk om communicatie te hebben onderling en eveneens een communicatiestroom te hebben wanneer er een opeenvolging van communicatie is (Milton & Johnson, 2012). Deze communicatie gebeurt aan de hand van pijlen die de twee concepten verbinden. Daarbij stelt een dubbele pijl een vorm van interactie voor, terwijl een éénrichtingspijl ook éénrichtingsverkeer in de communicatie voorstelt van afzender naar ontvanger. Wanneer dit gebeurt tussen de klant en het frontoffice spreken we van de reeds aangehaalde waarheidsmomenten. Het klantenproces wordt voorgesteld op een sequentiële manier, het niveau van detail waarmee men een service blueprint wil voorstellen is afhankelijk van de opzet (Bitner et al., 2008). Zo kan men bijvoorbeeld een globaal overzicht wensen van alle acties wat ervoor zorgt dat de details in mindere mate dienen uitgewerkt te worden. Traditioneel is men bij de analyse van een service op zoek naar faalpunten en bottlenecks. Bottlenecks zijn punten in het proces waarbij de capaciteit van een proces onvoldoende kan zijn waardoor klanten langer moeten wachten en de service dus meer tijd in beslag neemt. Faalpunten zijn alle andere zaken die niet met capaciteit te maken hebben die ervoor kunnen zorgen dat de service niet voldoet aan de verwachtingen (Van Looy et al., 1998). Hoe men dit allemaal concreet zal realiseren zal duidelijk worden in DEEL IV waar we dieper ingaan op deze techniek en hoe deze in de praktijk wordt toegepast. 20

34 Figuur 6: Service concepten in service blueprinting Overzicht serviceconcepten We plaatsen de concepten die we hebben geïdentificeerd samen met hun corresponderende definitie in een overzicht, zie Tabel 1. We volgen de basisrichtlijnen van service blueprinting waardoor we de managementfuncties en lijn van implementatie niet opnemen. Dit ligt in lijn met wat Bitner et al. voorstelt (2008) bij het praktisch toepassen van de modelleertaal. We focussen ons dus op de basisvoorstellingen volgens Bitner et al. (2008) en laten andere concepten hier buiten beschouwing voor het evalueren van de service blueprints. Verder merkt men op dat waarheidsmomenten geen expliciet concept zijn omdat ze eerder een logisch gevolg zijn door het feit dat deze voortvloeit uit een actie of communicatie over de lijn van interactie. 21

35 Tabel 1: Concepten Service Blueprinting CONCEPT ACTOR CATEGORIEËN ACTIE ACTIE STROOM LIJN VAN INTERACTIE LIJN VAN ZICHTBAARHEID LIJN VAN INTERNE INTERACTIE COMMUNICATIE COMMUNICATIESTROOM FYSIEKE BEWIJZEN FAALPUNTEN BOTTLENECKS DEFINITIE Klanten, frontstage personeel, backstage personeel, ondersteunend personeel. Zaken die klanten, frontstage personeel, backstage personeel en ondersteuning kunnen uitvoeren voor een service. Een opeenvolging van acties. De interface tussen klanten en frontstage personeel. De interface tussen frontstage personeel en backstage personeel. De interface tussen backstage personeel en ondersteuning. Uitwisseling van informatie tussen deelnemers. Opeenvolging van communicatie tussen elke deelnemer van de service. Alles dat waarneembaar is door de klant in het proces van de service. Problemen die kunnen optreden bij het doorlopen van het proces. Problemen die kunnen optreden gerelateerd aan de capaciteit. 2. ArchiMate Nu de concepten van service blueprinting zijn geïdentificeerd, gaan we ook op zoek naar de concepten binnen ArchiMate. We hebben in DEEL II duidelijk gemaakt wat de functies van viewpoints zijn binnen ArchiMate. Nu gaan we op zoek naar hoe de taal concreet in elkaar zit opdat men de verschillende viewpoints kan modelleren. Een uitvoerige beschrijving van ArchiMate zou ons te ver leiden van het onderzoek, daarom wordt een zeker kennis van de ArchiMate modelleertaal verondersteld. Alle informatie rond ArchiMate is vrij te vinden via de website van The Open Group 2. Hier wordt nog eens

36 kort een beschrijving gegeven van wat ArchiMate allemaal inhoudt die relevant is voor het onderzoek in deze paper. Niet alle concepten en relaties die ArchiMate bevat worden hier dus besproken. In Bijlage A kan men een eerste overzicht vinden van de concepten in AchiMate. 2.1 ArchiMate (2.0) structuur De kern van ArchiMate bestaat uit drie lagen (business, applicatie en technologie) die elk nog eens opgesplitst worden in verschillende aspecten (gedrag, actief, passief). Deze kern werd later uitgebreid (ArchiMate 2.0) met de motivatie extensie en de implementatie & integratie extensie Business laag De business laag toont hoe de business in elkaar zit en welke de business processen zijn om alles draaiende te houden. De entiteit of persoon die acties kan verrichten binnen de business laag is de business actor. Dit is degene die een bepaald gedrag kan vertonen en bepaalde business functies of processen kan uitvoeren. Een business actor kan men zien als een individueel persoon. Dit hoeft echter niet steeds zo te zijn, het is ook mogelijk dat een business actor voorgesteld wordt als een groep van individuen met gelijklopende kenmerken of verantwoordelijkheden. Wanneer actoren een bepaalde verantwoordelijkheid krijgen toegewezen, spreken we over een business rol. De verantwoordelijkheid over bepaalde business processen zorgt ervoor dat men met een bepaalde rol in staat is om zekere business objecten te manipuleren via bepaalde business processen. De business processen worden naar de buitenwereld toe zichtbaar gemaakt aan de hand van een service die een bepaalde functionaliteit kan aanbieden aan zijn omgeving. Door services te groeperen is men in staat om bepaalde producten te realiseren die men kan aanbieden. Via een contract kan men voor deze producten nog eens specifiëren welke de specifieke karakteristieken, rechten en vereisten zijn. (Steen, Akehurst, Ter Doest, & Lankhorst, 2004; The Open Group, 2013) 23

37 Figuur 7: Business laag concepten (Steen et al.) Applicatie laag Centraal in de applicatie laag is de applicatie component. Het is niet enkel een software component dat deel uitmaakt van één of meerdere applicaties. Het is ook mogelijk om een applicatie component te gebruiken voor een volledige software applicatie of een volledig informatiesysteem. Een data object is een zelfstandig stuk informatie relevant voor de applicatie en de business. De applicatie interface kan gezien worden als de plaats waar toegang tot services kan worden verkregen. In het gedrag of behaviour binnen de applicatie laag kan een onderscheid gemaakt worden tussen extern zichtbaar gedrag van applicatie componenten en het intern gedrag. Het externe gedrag resulteert in de applicatie services terwijl het intern gedrag, de applicatie functie, nodig is voor het realiseren van deze services maar niet expliciet naar de omgeving gecommuniceerd wordt. (Steen et al., 2004; The Open Group, 2013) 24

38 Figuur 8: Applicatie laag concepten (Steen et al.) Technologie laag De centrale component binnen de technologie laag is de node. Nodes kunnen bestaan uit twee soorten: device en systeemsoftware. Een device is een fysiek rekenkundig middel waar artifacts, een fysiek stuk informatie, kunnen worden op geïmplementeerd. Systeemsoftware daarentegen stelt een geheel van softwarecomponenten voor. Een infrastructuur interface stelt de locatie voor waar infrastructuur services van nodes kunnen worden verkregen. Een communicatie pad visualiseert de relatie tussen twee of meer nodes waar informatie kan worden uitgewisseld. Om de communicatie paden te realiseren is een netwerk nodig. Dit is een fysiek medium dat de communicatiepaden mogelijk maakt. De gedraging of behaviour in de technologie laag worden extern voorgesteld als de infrastructuur service, intern spreken we van de infrastructuur functie. (Steen et al., 2004; The Open Group, 2013) Figuur 9: Technologie laag concepten (Steen et al.) 25

39 2.1.4 Extensies De kern van het ArchiMate framework focust op de beschrijving van de architectuur van alle mogelijke systemen die de onderneming ondersteunen. Er zijn echter nog enkele belangrijke zaken binnen EA die ontbreken, maar wel duidelijk in enkele Enterprise Architecture Frameworks voorkomen. Dit resulteerde in enkele extensies die toegevoegd werden aan ArchiMate (ArchiMate 2.0) Motivatie extensie Voor TOGAF komt deze extensie het meest overeen met de twee beginfases in de cyclus van ADM (preliminary phase en Phase A). In deze fases worden op high level de business goals, architecturale principes en initiële business vereisten in kaart gebracht. De motivatie extensie maakt het mogelijk om deze elementen te bespreken via motivatie in het design en in de operaties van een onderneming. Deze extensie was voornamelijk nodig om de business/it alignering te verduidelijken. Zo worden concepten zoals doelstellingen, stakeholders, opgenomen. Ook het concept driver situeert zich in de motivatie laag. Een driver is een interne of externe factor die invloed kan hebben op de plannen of doelstellingen van de onderneming (The Open Group, 2013). Door de sterktes, zwaktes, opportuniteiten en dreigingen te analyseren en deze in relatie te brengen met de nodige drivers, kan men een betere architectuur realiseren die beantwoordt aan de business/it alignering. Figuur 10: Motivatie extensie (Steen et al.) Implementatie & migratie extensie Hier vindt men de concepten terug die helpen bij het visualiseren van een implementatie- of migratieproces. Zo is het bijvoorbeeld ook mogelijk om met ArchiMate aan projectmanagement te doen. Enkele belangrijke concepten hierbij zijn de work package en het plateau. Een work package kan 26

40 men vergelijken met een proces, maar met het verschil dat het om een tijdelijk proces gaat. Een plateau geeft een relatief stabiele toestand weer van architectuur, opnieuw voor een tijdelijke situatie. Figuur 11: Implementatie & migratie extensie (Steen et al.) 2.2 Relaties ArchiMate bevat naast de kernconcepten ook een set aan kernrelaties. Vele van deze relaties zijn afkomstig van bestaande standaard modelleertalen. Zo zijn de relatieconcepten zoals aggregatie, associatie en specialisatie afkomstig van UML 2.0, terwijl triggering gebruikt wordt in vele businessproces modelleertalen. Daarom behandelen we de relaties eveneens niet in detail, in Bijlage B vindt men een overzicht van de relaties die gedefinieerd zijn binnen ArchiMate. Het is echter mogelijk om via afgeleide relaties nog extra relaties toe te voegen, waardoor de voorgestelde set aan relaties niet exhaustief is. De relaties worden onderverdeeld in drie categorieën: 1. Structurele relaties: modelleren van de structurele samenhang van concepten van hetzelfde of verschillende types. De relaties zijn: associatie, toegang, gebruikt door, realisatie, toewijzing, aggregatie en compositie 2. Dynamische relaties: modelleren van (tijdelijke) afhankelijkheid tussen gedragsconcepten De relaties zijn: stroom en triggering 3. Andere: relaties die niet behoren tot de andere twee. De relaties zijn: groepering, knooppunt en specialisatie. Binnen de implementatie en migratie extensie worden deze relaties overgenomen. De motivatie extensie heeft echter zijn eigen relaties: associatie, aggregatie, realisatie en invloed. 27

41 2.3 Overzicht concepten en relaties in ArchiMate Met ArchiMate heeft men geprobeerd om de ideale balans te vinden tussen een specifieke taal en een meer algemene taal voor Enterprise Architecture. Figuur 12 illustreert dat concepten op verschillende niveaus kunnen worden beschreven. Daarbij stelt de top het meest algemene metamodel voor dat binnen EA kan worden gerealiseerd. De basis stelt meer specifieke modelleertalen voor zoals UML en BPMN. Met ArchiMate is men gestart van relatief algemene concepten (top) en is men deze meer gaan specialiseren naar de verschillende lagen (business, applicatie, technologie) in de architectuur. Elk van deze meer specifieke concepten kan men dan nog eens onderscheiden aan de hand van de verschillende aspecten (actief, gedrag, passief). Dit zijn de twee dimensies voor de kernconcepten in ArchiMate. Daarnaast zijn echter nog extra concepten toegevoegd die behoren tot de extensies, deze volgen niet dezelfde onderverdeling als bij de kernlagen. In wat volgt definiëren we alle concepten die beschikbaar zijn in ArchiMate voor elke laag afzonderlijk en de twee extensies. Figuur 12: Metamodellen voor verschillende levels van specialisatie Business concepten In Tabel 2 worden alle business concepten voorgesteld, samen met de corresponderende definitie. De concepten worden onderverdeeld volgens de aspect dimensie. Daarbij zijn actor, rol, samenwerking, interface en locatie actieve structuur concepten. De gedragsconcepten zijn: proces, functie, interactie, event en service. De passieve structuurconcepten zijn: object, voorstelling, betekenis, waarde, product en contract. 28

42 Tabel 2: Business concepten CONCEPT ACTOR ROL SAMENWERKING INTERFACE LOCATIE PROCES FUNCTIE INTERACTIE EVENT SERVICE OBJECT VOORSTELLING BETEKENIS WAARDE PRODUCT CONTRACT DEFINITIE Een entiteit dat een bepaald gedrag kan uitvoeren. De verantwoordelijkheid voor de uitvoering van een bepaald gedrag dat toegewezen is aan een actor. Een groepering van twee of meer rollen die samenwerken om collectief een bepaald gedrag uit te voeren. De plaats waar de omgeving toegang kan verkrijgen tot een service. Een plaats in een ruimte. Het groeperen van gedrag dat gebaseerd is op een volgorde in activiteiten met als doel om een product of service te realiseren. Het groeperen van gedrag aan de hand van een gekozen set van criteria. Het beschrijven van een gedrag door samenwerking. Iets dat kan gebeuren en invloed heeft op het gedrag. Het vervullen van een behoefte van een klant (intern of extern in de onderneming). Een relevant element gezien volgens het business perspectief. Een waarneembare vorm van informatie dat gedragen wordt door een object. De kennis of expertise dat beschikbaar is in een object of voorstelling, binnen een bepaalde context. De relatieve prijs, het gebruik, het belang van een service of product. Een coherente verzameling van services, samen met een contract/akkoord, die als een geheel wordt aangeboden aan (interne of externe) klanten. Een formeel of informeel specificatie van een akkoord dat de rechten en plichten duidelijk maakt die horen bij een product. Applicatie concepten Net zoals bij de business laag kan men in de applicatie laag een onderscheid maken tussen de actieve structuurconcepten (component, samenwerking, interface), gedragsconcepten (functie, interactie, 29

43 service) en passieve structuurconcepten (object). Tabel 3 geeft een overzicht van de concepten in de applicatie laag evenals de corresponderende definitie. Tabel 3: Applicatie concepten CONCEPT COMPONENT SAMENWERKING INTERFACE FUNCTIE INTERACTIE SERVICE OBJECT DEFINITIE Een modulair, inzetbaar en vervangbaar deel van een softwaresysteem dat het gedrag en de data behandelt en deze beschikbaar maakt via interfaces. Een groepering van twee of meer componenten die samenwerken om collectief een bepaald gedrag uit te voeren. De plaats waar een gebruiker of een andere component toegang kan verkrijgen tot een service. Het groeperen van automatisch gedrag dat uitgevoerd kan worden door een component. Het beschrijven van een gedrag door samenwerking. Een service dat geautomatiseerd gedrag extern zichtbaar maakt. Element dat geschikt is voor automatische processen Technologie (infrastructuur) concepten Bij de technologie laag zijn de actieve structuurconcepten: een node, apparaat, software, interface, netwerk en een communicatie pad. De gedragsconcepten zijn: functie en service. Het passieve structuurelementen is een artifact. Tabel 4 geeft een overzicht van alle concepten in de technologie laag, evenals hun definitie. Tabel 4: Technologie concepten CONCEPT NODE APPARAAT SOFTWARE DEFINITIE Een rekenmiddel waarop artifacts kunnen opgeslagen worden of bruikbaar gemaakt worden voor uitvoering. Een middel van hardware waar artifacts op kunnen worden opgeslagen of bruikbaar gemaakt voor uitvoering. Een softwareomgeving voor specifieke types van componenten en objecten die uitgevoerd worden in de vorm van artifacts. 30

44 INTERFACE NETWERK COMMUNICATIE PAD FUNCTION SERVICE ARTIFACT De plaats waar toegang kan verkregen worden door nodes en componenten tot services die worden aangeboden door een andere node. Een communicatiemedium tussen twee of meer apparaten. De link tussen twee of meer nodes, waardoor data kan worden uitgewisseld. Het groeperen van gedrag dat door een node kan worden uitgevoerd. Een extern zichtbare functionaliteit die betekenisvol is voor de omgeving, dat aangeboden wordt door een of meer nodes en beschikbaar is via interfaces. Een fysiek stuk data dat gebruikt en geproduceerd wordt door een softwareproces, of door ontwikkeling en operaties in een systeem. Motivatie concepten In tegenstelling tot de business, applicatie en technologie laag wordt er hier geen onderscheid gemaakt tussen de verschillende aspecten (actief, gedrag, passief). Tabel 5 geeft de lijst van concepten in deze extensie met hun corresponderende definitie. Tabel 5: Motivatie concepten CONCEPT STAKEHOLDER DRIVER BEOORDELING DOEL VEREISTE BEPERKING PRINCIPE DEFINITIE De rol van een individu, team of organisatie die zijn interesses en bezorgdheden kan formuleren met betrekking tot de architectuur. Iets dat kan creëren, motiveren en verandering teweegbrengt binnen de onderneming. De uitkomst van een analyse van een driver. Een eindtoestand dat een stakeholder wil bereiken. Een statement dat er een behoefte is die moet bevredigd worden door een systeem. Een restrictie op de manier hoe een systeem wordt gerealiseerd. Een normatieve eigenschap van alle systemen in een bepaalde context of de manier waarop de systemen worden gerealiseerd. 31

45 Implementatie en migratie concepten Ook in deze extensie wordt er geen onderscheid gemaakt volgens de verschillende aspecten. Tabel 6 geeft de concepten in de implementatie en migratie extensie weer evenals de definitie. Tabel 6: implementatie en migratie concepten CONCEPT WERK PAKKET DELIVERABLE PLATEAU KLOOF DEFINITIE Een serie van acties die gericht zijn op het realiseren van een unieke doelstelling binnen een bepaalde tijd. Een specifiek-gedefinieerde uitkomst van een werk pakket. Een relatief stabiele toestand van de architectuur die bestaat gedurende een beperkte periode in de tijd. De uitkomst van een analyse tussen twee plateaus. Relatieconcepten De relaties voor de business, applicatie en technologie laag worden onderverdeeld in drie types: structurele, dynamische en andere relaties. De structurele relaties bestaan uit: associatie, toegang, gebruikt door, realisatie, toewijzing, aggregatie en compositie. Bij het dynamische type zijn er twee relaties, namelijk een stroom en triggering. De andere relaties zijn groepering, knooppunt en specialisatie. Een overzicht is met de corresponderende definitie is te vinden in Tabel 7. Het is mogelijk om binnen ArchiMate nog afgeleide relaties toe te voegen. De implementatie en migratie extensie maakt eveneens gebruik van de relaties voor de kernconcepten, de motivatie extensie heeft echter een eigen set van relaties, zie Tabel 8. Tabel 7: Relaties kernconcepten CONCEPT ASSOCIATIE TOEGANG GEBRUIKT DOOR REALISATIE TOEWIJZING DEFINITIE De relatie tussen objecten die niet omvat is door een meer specifieke relatie. De toegang van gedragsconcepten tot een business of data object. Modelleren van het gebruik van services door processen, functies of interacties en de toegang tot interfaces door rollen, componenten en samenwerking. Linkt een logische entiteit met een meer concrete entiteit dat deze realiseert. Linkt units van gedrag met actieve elementen die deze uitvoeren, of rollen met actoren die deze vervullen. 32

46 AGGREGATIE COMPOSITIE STROOM TRIGGERING GROEPERING KNOOPPUNT SPECIALISATIE Geeft aan dat een object een aantal andere objecten groepeert. Geeft aan dat een object is samengesteld uit een of meer andere objecten. Beschrijft de uitwisseling of transfer tussen processen, functies, interacties en events Beschrijft de tijdelijke of causale relatie tussen processen, functies, interacties en events. Geeft aan dat objecten van hetzelfde type of een verschillende type bij elkaar horen voor een bepaalde karakteristiek. Punt om relaties van hetzelfde type te verbinden. Geeft aan dat een object een specialisatie is van een ander object. Tabel 8: Relaties motivatie extensie CONCEPT ASSOCIATIE AGGREGATIE REALISATIE INVLOED DEFINITIE Modellering van een bepaalde intentie die gerelateerd is aan de bron. Modellering van een intentioneel element dat uit meerdere intentionele elementen bestaat. Modellering van een bepaald eind dat gerealiseerd wordt aan de hand van bepaalde middelen. Modellering van een bepaald intentioneel element dat een positieve of negatieve invloed kan hebben op een ander intentioneel element. 33

47 DEEL IV: PRAKTIJKANALYSE Nu we de concepten van zowel Service Blueprinting als ArchiMate hebben geïdentificeerd kunnen we nagaan hoe deze in de praktijk worden gebruikt. Dit laat ons toe om na te gaan of er eventueel zaken zijn die ontbreken en hoe we de concepten uit de theorie nu in de praktijk kunnen implementeren. We beginnen met een stappenplan bij Service Blueprinting die gebruikt kan worden als leidraad gedurende het implementatieproces opdat de objectieven van de service blueprint duidelijk zijn en worden verwezenlijkt. Dit biedt een antwoord op de vraag: - Wat is de functie van een service blueprint? Voor het toepassen van Enterprise Architecture in de praktijk kan gebruik gemaakt worden van Enterprise frameworks zoals TOGAF of Zachman die we reeds hebben besproken. Dit is echter heel uitgebreid en minder relevant voor ons objectief. Wij maken gebruik van een bestaand uitgewerkt voorbeeld Archisurance dat bekend is in de literatuur. Aan de hand van het classificatiesysteem voor viewpoints binnen ArchiMate maken we een korte analyse van enkele standaard viewpoints waar het mogelijk is om serviceconcepten toe te passen. Daarmee trachten we een antwoord te vinden op de vraag: - Wat is de functie van een model in ArchiMate? 1. Service blueprinting in de praktijk In dit hoofdstuk evalueren we enkele service blueprints die gerealiseerd zijn in de praktijk. Daarvoor is het eerst belangrijk om de stappen te kennen die dienen gevolgd te worden wanneer men een eigen service blueprint wil ontwerpen. Daarvoor heeft M. Bitner een aantal stappen opgesteld die men moet volgen voor het praktisch uitwerken van een service Blueprint (Bitner et al., 2008). Deze stappen worden gebruikt in workshops om mensen op te leiden voor het uitwerken van de blueprint voor een service in hun eigen bedrijf. 1.1 Service blueprinting workshop Wanneer men voor het eerst een effectieve blueprint wil uitwerken, is het belangrijk om te starten met een simpele blueprint als voorbeeld vooraleer men de eigen onderneming tracht voor te stellen. Bij de uitwerking is het steeds belangrijk om alle inzichten te communiceren en als een team samen te werken. Daarbij is volgend stappenplan een leidraad gedurende het proces: 34

48 1.1.1 Het objectief en de service Het is niet de bedoeling om alles ineens te behandelen, daarom moet men focussen op een bepaalde service of serviceproces. Er dient daarvoor dan ook een bepaald klantensegment gekozen te worden. Klantensegmentatie betekent dat men klanten gaat onderverdelen in groepen met soortgelijke kenmerken. Niet alle klanten hebben dezelfde verwachtingen van een service, waardoor deze ook anders behandeld kunnen worden. In deze fase is het ook de bedoeling dat iedereen het eens is over de doelen van het service blueprinting proces. Is het bijvoorbeeld de bedoeling dat er een nieuwe service wordt ontworpen of dat er verbeteringen worden gedaan of wil men duidelijk maken wat de kritieke punten zijn in het serviceproces? Betrokkenen Het ideale scenario is is dat iedereen betrokken wordt bij de service blueprint die iets te maken heeft met het serviceproces dat in kaart wordt gebracht. Dit is echter vaak niet mogelijk. Toch is het belangrijk dat er een verscheidenheid aan perspectieven beschikbaar is, zo kan men beter identificeren hoe de service ervaren wordt door klanten en hoe deze best uitgevoerd wordt door de onderneming Aanpassingen In bepaalde omstandigheden is het beter om af te stappen van de traditionele service blueprinting techniek. Wanneer men een internet gebaseerde service aanbiedt is het misschien logischer om de frontstage-werknemers te vervangen door frontstage-technologieën of deze laatste gewoon toe te voegen aan de traditionele rijen. Ook mag men eigen symbolen gebruiken om aan te tonen waar de faalpunten of opportuniteiten zijn in het proces. Eigenlijk mag men elke aanpassing doorvoeren dat de kwaliteit van de voorstelling kan verbeteren om betere communicatie te verkrijgen. De flexibiliteit is een van de grote sterktes van de service blueprinting techniek Voorstelling van het meest frequente Het is belangrijk om niet te starten van het ideale proces waarbij alles verloopt zoals het in theorie zou moeten verlopen. Het is veel waardevoller wanneer men kijkt naar het proces zoals het werkelijk gerealiseerd wordt in het overgrote deel van de gevallen. Achteraf is het mogelijk om eventueel het ideale scenario voor te stellen, afhankelijk van de doelstelling, en deze te vergelijken met de werkelijkheid Discussies Gedurende het blueprint-proces zullen de betrokkenen meningsverschillen hebben over bepaalde zaken. Het is van groot belang om deze ook bij te houden en te noteren omdat ze vaak aanwijzingen geven over hoe het ideale serviceproces er moet uitzien. 35

49 1.1.6 Klantgericht blijven Het komt vaak voor bij de betrokkenen van het blueprint proces om de eigen business focus op te leggen. Men moet er zich echter van bewust blijven dat alles moet gemodelleerd worden met de klant als centrale spilfiguur Inzichten Wanneer men de blueprint opstelt, kan men tijdens het proces al tot nieuwe inzichten komen. Hou deze bij om ze voor te stellen wanneer de blueprint klaar is. Pas wanneer men klaar is met de blueprint zoals deze nu in de realiteit is, kan men beginnen kijken naar het ideale scenario en kunnen de verworven inzichten terug naar boven gehaald worden Aanbevelingen Wanneer de service blueprint ontwikkeld is, kan men aanbevelingen en voorstellen aanbrengen om de blueprint aan te passen. Het is afhankelijk van de doelstelling, die men in de eerste stap identificeerde, welke aanbevelingen gepast zijn Gebruik De service blueprint kan ook als communicatiemiddel gebruikt worden in de onderneming voor alle betrokkenen in het serviceproces. Zo kan deze gebruikt worden bij trainingen, om duidelijkheid te schetsen voor de klant en andere diverse doeleinden binnen de onderneming. Ook kunnen medewerkers nieuwe inzichten aanbrengen, daarvoor is echter vaak ondersteuning nodig van bovenaf om iedereen hiervoor te motiveren actief deel te nemen. Zoals vermeld, helpt de verscheidenheid aan perspectieven om een accuraat en idealistisch beeld te schetsen 1.2 Voorbeelden service blueprints We bespreken enkele voorbeelden van service blueprints in grote lijnen via een evaluatie aan de hand van de concepten die we reeds hebben geïdentificeerd in DEEL III. Daarbij kijken we wat allemaal aanwezig is ( ) en welke zaken ontbreken/weggelaten zijn ( ). Ook extra s die eventueel aan de service blueprint zijn toegevoegd worden bekeken. Hotelbezoek Het schoolvoorbeeld bij het ontwerpen van een service blueprint is dit van een hotelbezoek (voor één nacht) door M. Bitner et al. (2008). Daarbij doorloopt men het proces van de klant vanaf de reservatie via de website tot de check out en het vertrek. In bijlage C vindt men het voorbeeld van de service blueprint voor een hotelbezoek. Dit is een conceptuele blueprint met enkel de basisstappen. Afhankelijk van de doelstelling is het mogelijk om elk van deze stappen dieper uit te werken in sub- 36

50 processen tot het gewenste niveau van detail is bereikt (Bitner et al., 2008). Wanneer we kijken naar de concepten die we hebben geïdentificeerd in DEEL III en nagaan of deze al dan niet aanwezig zijn, leidt dit tot Tabel 9. Tabel 9: Evaluatie service blueprint:hotelbezoek CONCEPT ACTOR CATEGORIEËN ACTIE ACTIE STROOM LIJN VAN INTERACTIE LIJN VAN ZICHTBAARHEID LIJN VAN INTERNE INTERACTIE COMMUNICATIE COMMUNICATIESTROOM FYSIEKE BEWIJZEN FAALPUNTEN/BOTTLENECKS AANWEZIG Deze weergave bevat enkel de basisstappen waar alle basislijnen en -lagen van een service blueprint in verwerkt zitten, zonder extra s. Verder missen de faalpunten, bottlenecks. Dit geeft inderdaad een indicatie er met deze blueprint nog een grondigere analyse kan gemaakt worden indien men dit wenst. De waarheidsmomenten zijn zoals vermeld geen expliciet concept maar eerder een logisch gevolg van de communicatie met de klant. Dit wordt in deze blueprint eveneens aangegeven aan de hand van pijlen die van en naar de klant lopen met het frontoffice. Restaurant In het boek Digital Enterprise Design & Management van Benghozi et al. (2014) wordt de functie van service blueprinting voor een technologisch-gebaseerde service besproken. Hieronder verstaat men de service die door klanten zelf geproduceerd wordt door gebruik te maken van technologische infrastructuur. Via analyse van deze services met service blueprinting heeft men nieuwe elementen voorgesteld die kunnen worden geïmplementeerd in de service blueprinting techniek. Deze elementen zijn (Benghozi, Krob, Lonjon, & Panetto, 2014): 37

51 - Virtuele zone in zowel de klantenacties, onstage, backstage en ondersteunende processen. - Fysieke zone in zowel de klantenacties, onstage, backstage en ondersteunende processen. - Lijn van materialiteit die beide zones (virtueel en fysiek) in elke laag van elkaar onderscheidt. In Figuur 13 worden de nieuwe voorgestelde elementen visueel duidelijk gemaakt. Figuur 13: Virtuele zones in Service Blueprinting (Benghozi et al.) In bijlage D vindt men het resultaat van een klassieke service blueprint in een restaurant. Daarbij doorloopt men het hele proces vanaf dat de klant arriveert in een restaurant tot het moment dat deze het restaurant opnieuw verlaat. Tabel 10 geeft aan welke elementen aanwezig zijn in deze blueprint. Als we kijken naar de structuur, dan zien we dat de fysieke bewijzen ontbreken. De waarheidsmomenten worden ook hier voorgesteld door pijlen die lopen over de lijn van interactie. De faalpunten en bottlenecks worden ook niet behandeld in dit voorbeeld, dit wijst opnieuw op een blueprint waar stappen in het proces op een meer high level zijn uitgewerkt. Tabel 10: Evaluatie klassieke service blueprint: Restaurant CONCEPT ACTOR CATEGORIEËN ACTIE ACTIE STROOM LIJN VAN INTERACTIE LIJN VAN ZICHTBAARHEID LIJN VAN INTERNE INTERACTIE AANWEZIG 38

52 COMMUNICATIE COMMUNICATIESTROOM FYSIEKE BEWIJZEN FAALPUNTEN/BOTTLENECKS De klassieke service blueprint van het restaurant werd aangevuld met nieuwe voorgestelde elementen, dit resulteerde in een nieuwe service blueprint zoals deze wordt voorgesteld in Bijlage E. Daarbij vallen meteen enkele zaken op. Allereerst is elke laag onderverdeeld in een virtuele zone en een fysieke zone waardoor ook meerdere processen worden voorgesteld. Verder ziet men ook dat de start in het proces bij de klantacties al vroeger begint dan bij het klassieke voorbeeld. Dit komt doordat men de website van het restaurant mee in kaart brengt, wat duidelijk werd door technologie er bij te betrekken. Bij de evaluatie in Tabel 11 valt dus op dat er extra elementen aan toegevoegd zijn. Dit is de grote sterkte van de service blueprinting techniek die toelaat om eigen aanpassingen en aanvullingen te doen (stap 3 in workshop Bitner: aanpassingen). Opnieuw ontbreekt echter de laag met de fysieke bewijzen. Nochtans zou deze in dit geval een duidelijke toegevoegde waarde kunnen bieden door de omgeving en de (IT-) infrastructuur duidelijk in kaart te brengen. Vooral door de IT-infrastructuur te linken met de virtuele zones kan men mogelijks een beter beeld schetsen en nieuwe inzichten bekomen. Dit hangt natuurlijk opnieuw af van de scope die men voor ogen heeft. Tabel 11: Evaluatie service blueprint met virtuele zones CONCEPT ACTOR CATEGORIEËN ACTIE ACTIE STROOM LIJN VAN INTERACTIE LIJN VAN ZICHTBAARHEID LIJN VAN INTERNE INTERACTIE COMMUNICATIE COMMUNICATIESTROOM AANWEZIG 39

53 FYSIEKE INSTRUMENTEN FAALPUNTEN/BOTTLENECKS VIRTUELE ZONE FYSIEKE ZONE LIJN VAN MATERIALITEIT Cafetaria universiteit Deze service blueprint, zie Bijlage F, focust zich op een specifiek item dat in de cafetaria van een universiteit wordt verkocht, de clubhouse sandwich. Daarbij wordt een grondige analyse gemaakt en worden enkele elementen uit een valuestream map in de blueprint verwerkt. Er worden faalpunten weergegeven evenals de verbeteringen om deze te vermijden (Poka-Yokes). Men visualiseert het wachten door middel van een driehoek, wat overgenomen is uit de valuestream mapping techniek. Dit is minder gebruikelijk in service blueprints maar kan dus makkelijk worden geïncorporeerd. Tabel 12 vat nog eens de belangrijkste elementen samen die (niet) aanwezig zijn. Tabel 12: Evaluatie service blueprint cafetaria CONCEPT ACTOR CATEGORIEËN ACTIE ACTIE STROOM LIJN VAN INTERACTIE LIJN VAN ZICHTBAARHEID LIJN VAN INTERNE INTERACTIE COMMUNICATIE COMMUNICATIESTROOM FYSIEKE BEWIJZEN FAALPUNTEN/BOTTLENECKS WAITING POKA YOKE AANWEZIG 40

54 Conclusie De service blueprinting techniek is flexibel waardoor het mogelijk is om de nodige aanpassingen te doen die een goede analyse van het proces mogelijk maken. Daarbij wordt er steeds gewerkt met de aangereikte lagen en lijnen in de service blueprint, al is men vrij om bijvoorbeeld een laag als de fysieke bewijzen weg te laten of een nieuwe laag toe te voegen indien men deze nodig acht. Ook kan men nieuwe concepten toevoegen of gebruik maken van bestaande concepten uit bijvoorbeeld value chains die duidelijk aangeven wat er wordt voorgesteld. Wat de voorbeelden ook duidelijk maken is dat afhankelijk van de scope, men een service blueprint heel gedetailleerd kan uitwerken of eerder high level. Het nadeel bij service blueprints is echter dat er heel weinig rekening wordt gehouden met de IT die helpt bij het ondersteunen van de processen. Het ontwikkelen van nieuwe elementen, zoals bijvoorbeeld een virtuele zone, maken het mogelijk om meer en focus te leggen op de ITmogelijkheden, maar maken de service blueprint daarmee heel wat complexer. Hoe men de service blueprint ook wil voorstellen, de blueprint wordt opgesteld door de ogen van de klant die de service ervaart. 2. ArchiMate in de praktijk: Archisurance Met ArchiMate is het mogelijk om een volledig model op te stellen die zowel de business laag, applicatie laag, technologie laag als de extensies in één viewpoint voorstelt. In bijlage G vindt men een voorbeeld van een model dat de drie lagen combineert in één viewpoint. Daarbij wordt het proces voorgesteld van een planning voor de opening van een onderneming. Dit is een gedetailleerde omschrijving van het proces, waar alle drie de lagen in betrokken worden. Zoals blijkt uit het voorbeeld kan dit leiden tot een hoge complexiteit, daarom wordt er vaak gewerkt met verschillende viewpoints die het proces opsplitsen. Gebaseerd op praktische ervaringen heeft ArchiMate een set van standaard viewpoints ontwikkeld die kunnen gebruikt worden wanneer men de architectuur van de onderneming wil voorstellen. Binnen bepaalde standaard viewpoints in ArchiMate zijn er reeds mogelijkheden om bepaalde serviceconcepten te modelleren. We beperken ons bij deze bespreking tot enkele viewpoints waarbij gepoogd is om serviceconcepten afkomstig uit service blueprinting te incorporeren. Deze lijst van viewpoints is dus zeker niet exhaustief. In bijlage H tot K vindt men de visuele voorstellingen van deze viewpoints. Elk van deze viewpoints focust op een bepaald aspect van de onderneming die men tracht voor te stellen. Voor de uitwerking van de viewpoints is gebruik gemaakt van de Archisurance case study, waar men de problemen (rond IT) tracht te identificeren naar aanleiding van een fusie tussen verschillende verzekeringskantoren (Jonkers, Band, & Quartel, 2012). Aan de hand van het 41

55 classificatiesysteem dat in DEEL II werd voorgesteld kunnen we nagaan waar de focus bij de betreffende viewpoints ligt. Organization viewpoint Via het niveau van coherence worden relaties in de onderneming expliciet gemaakt binnen deze viewpoint, zonder echt in detail te treden. Het is bijvoorbeeld mogelijk om bepaalde relaties binnen een departement in kaart te brengen. Maar ook inter-organisationele relaties kunnen worden verduidelijkt. Zoals te zien is in Figuur 14 via de donkere schaduw, kan men ook de relaties van beslissingen en relaties van informatie visualiseren. Een voorbeeld bij beslissingen op coherence niveau zou kunnen aantonen hoe het beslissingsproces binnen een onderneming afhangt van verschillende departementen. Al deze voorstellingen situeren zich eerder op de business laag en omschrijven de zaken rond business van de onderneming. Serviceconcepten in de organization viewpoint Via deze voorstelling is het bijvoorbeeld mogelijk om duidelijk te maken welke departement of divisies frontoffice zijn en welke backoffice. Deze viewpoint heeft als doel structuur te brengen voor de onderneming en daarbij kunnen serviceconcepten, zoals bijvoorbeeld frontoffice en backoffice, een mogelijk criteria zijn waar de structuur op wordt gebaseerd. Figuur 14: Organization viewpoint classification Actor co-operation viewpoint Het is voor elk bedrijf enorm belangrijk om te weten welke relaties er zijn tussen personen/actoren, zowel intern als extern. Intern kan er bijvoorbeeld een sterke samenwerking nodig zijn tussen iemand van de Human Resources en iemand van de Finance departement om te zorgen dat de lonen op tijd kunnen betaald worden. Ook extern is het belangrijk om de relaties te identificeren, zo kan men 42

56 bijvoorbeeld zien hoe afhankelijk de onderneming is van informatie van een klant of hoe omvangrijk de samenwerking met leveranciers zijn. In tegenstelling tot de vorige viewpoint, Organization viewpoint, treedt men hier meer in detail om de relaties aan te duiden tussen actoren. Figuur 15 toont de positionering van Actor co-operation viewpoint binnen het classificatiesysteem. Zowel een ontwerp, beslissend als informatief type van voorstelling is mogelijk. Zo kan een voorstelling van de hiërarchie in departemeten met zijn ordening als een informatiemiddel dienen om de eigen positie te situeren. Serviceconcepten in actor co-operation viewpoint Op vlak van serviceconcepten voor de klant kan men in deze viewpoint meer aangeven hoe de communicatie met de klant verloopt voor verschillende departementen of divisies van de onderneming. Ook de relatie op vlak van communicatie met de divisies onderling worden duidelijk. Zo wordt een set van verantwoordelijkheden duidelijk tussen de actoren van de onderneming en de klant. Deze relaties kunnen duidelijk maken welke divisies beter op elkaar afgestemd moeten worden om een vlotte service aan de klant te kunnen leveren. Figuur 15: Actor co-operation viewpoint classification Business function viewpoint Dit is de meest stabiele viewpoint gedurende de jaren van bestaan voor een onderneming. De hoofdactiviteiten, op business level, van de onderneming worden beschreven om aan te duiden wat elke dag opnieuw moet worden gerealiseerd om draaiende te blijven. In grote lijnen worden dus de functies van de onderneming gevisualiseerd. Het is via de wijze waarop men deze functies/services realiseert dat men een verschil kan maken met de concurrentie in de industrie. Serviceconcepten in business function viewpoint Wanneer men de functies van de onderneming heeft geïdentificeerd, worden deze in relatie gebracht met de personen die een bepaalde rol hebben binnen de onderneming. Eén van deze rollen is de klant 43

57 die in relatie staat met deze activiteiten die voor hem/haar van belang kunnen zijn. In tegenstelling tot de vorige viewpoints betreft het hier de activiteiten van de onderneming waar de klant mee betrokken is, zonder rekening te houden met de structuur van de onderneming. Figuur 16: business function viewpoint classification Application co-operation viewpoint Hier worden de relaties van verschillende applicaties verduidelijkt evenals de informatie die deze delen met elkaar. In tegenstelling tot de vorige viewpoints ligt hier voornamelijk de focus op de interactie en relaties tussen applicaties, dus in de applicatie laag. Serviceconcepten in application co-operation viewpoint Ook hier kunnen bijvoorbeeld frontoffice-applicaties en backoffice-applicaties van elkaar worden gescheiden. Daarbij kijkt men welke applicaties de klant rechtstreeks gebruikt en welke niet. Figuur 17: Application co-operation viewpoint classification Conclusie Met ArchiMate wil men de architectuur van een onderneming in kaart brengen. Men focust op zaken die gerelateerd zijn aan de business, de applicaties en/of de technologie. Wanneer men in detail een 44

58 model opstelt, kan dit vaak leiden tot een enorme toename in complexiteit. Viewpoints zijn een handig hulpmiddel om de complexiteit te reduceren wanneer men bijvoorbeeld in detail wil gaan. Het is mogelijk om verschillende lagen te combineren of te focussen op een bepaalde laag. Zo kan men de juiste informatie weergeven en een goede communicatie tussen verschillende stakeholders mogelijk maken. Alles hangt natuurlijk af van de scope en doelstellingen van de modellering. DEEL V: ONDERZOEK Nu we de concepten van zowel ArchiMate als Service Blueprinting hebben geïdentificeerd (DEEL III) en aan de hand van praktijkvoorbeelden (DEEL IV) duidelijk hun functies en mogelijkheden hebben geanalyseerd, gaan we in ons onderzoek dieper in op de vraag: - Welke van de bestaande concepten in ArchiMate overlappen met de serviceconcepten die geïdentificeerd zijn in een service blueprint? We beginnen met het eerder aangehaald onderzoek van Milton en Johnson (2012) naar de integratie van service blueprinting in BPMN waar we in DEEL I ons Framework hebben op gebaseerd. Aan de hand van dit onderzoek wordt een analyse gemaakt van een meer business georiënteerde modelleertaal met een meer klantgerichte modelleertaal. Daarna vervolgen we onze onderzoeksmethode aan de hand van: Stap 3: Analyse van de sets aan concepten & kwalitatieve analyse 1. Klantgericht vs. businessgericht Zoals reeds vermeld maakt service blueprinting gebruik van een klant-georiënteerde aanpak om de processen in kaart te brengen. Dit is een verschillende aanpak van modelleertalen die zich richten op de processen binnen een onderneming en dus een business-georiënteerde aanpak hanteren. Milton en Johnson (2012) deden onderzoek naar de gelijkenissen en verschilpunten tussen een klantengerichte procesvoorstelling en een meer businessgerichte proces-voorstelling. Daarbij focusten ze zich op de verschillen en gelijkenissen tussen de service blueprinting techniek en de Business Process Modeling Notation (BPMN). Aan de hand van een hotelbezoek als fictief voorbeeld, maakten de auteurs een ontologische vergelijking van beide tools om na te gaan of deze eventueel 45

59 complementair aan elkaar konden zijn (Milton & Johnson, 2012). Een studie naar de ontologie in het domein van IT betekent dat men kijkt naar de set van basisvoorstellingen die men kan gebruiken om een model op te bouwen (Liu & Özsu, 2009). Deze basisvoorstellingen zijn een set van voorstellingen met bepaalde eigenschappen en relaties die kunnen gebruikt worden om meer uitgebreide voorstellingen te realiseren. BPMN is een standaardmodelleertaal dat ontworpen is om zo ruim mogelijk toepasbaar en verstaanbaar te zijn. Het moet een communicatiemiddel zijn dat zowel door de business gebruikers (uitvoerders) als de business analisten (ontwerpers) gehanteerd kan worden (Chinosi & Trombetta, 2012). De conclusie bij het onderzoek van Milton & Johnson (2012) is dat er in BPMN nog enkele zaken ontbraken voor het voorstellen van een service blueprint. Men moet er ook wel rekening mee houden dat beide modelleertalen vanuit een verschillend perspectief starten. BPMN maakt gebruik van een perspectief met een focus op de onderneming, terwijl een service blueprint gebruik maakt van een meer klantgericht perspectief. Deze perspectieven kunnen echter in combinatie worden gebruikt aangezien het klantgerichte perspectief meer de kritieke punten blootlegt waar de klant mee betrokken is, terwijl het ondernemingsperspectief in BPMN de onderliggende processen beter kan schetsen. Wij zullen in deze paper eveneens een vergelijking maken van Service blueprinting met een modelleertaal komende uit de IT met een meer business georiënteerd perspectief. In tegenstelling tot S. Milton & L. Johnson, richten wij onze focus op ArchiMate in plaats van BPMN. Hoewel BPMN een specifieke modelleertaal aanbiedt die ruim toepasbaar is, wordt deze voornamelijk toegepast in een geïsoleerde business context. Waardoor een BPMN er minder in slaagt om een geïntegreerd beeld weer te geven van de onderneming over alle domeinen heen (Peña & Villalobos, 2010). Door de focus op business processen richt BPMN zich ook minder op de middelen en competenties die nodig zijn voor de realisatie van het proces (Glissman & Sanz, 2009). Enterprise Architecture behandelt deze zaken wel, waardoor deze ook mogelijk zijn in de ArchiMate modelleertaal. Het grote voordeel van het gebruik bij een BPMN is dat het net zoals bij service blueprinting heel gedetailleerde stappen kan beschrijven. Dit is iets wat minder gebruikelijk is in EA waardoor men meer abstractie maakt van bepaalde stappen in het proces en waarmee we dus rekening mee zullen moeten houden (The Open Group, 2013). 2. Analyse beide modelleertalen via concepten Bij de analyse van de resultaten wordt er gebruik gemaakt van de semantische theorie, waar de betekenis van de symbolen wordt onderzocht. Meer specifiek worden de concepten van beide 46

60 modelleertalen onderzocht in het semantische veld (Eco, 1976). Daarbij gaan we na of er binnen een context een zekere correlatie tussen concepten bestaat via hun definitie die tot op een bepaalde hoogte correspondeert met elkaar, zonder dat het exacte kopieën hoeven te zijn (Milton & Johnson, 2012). Het is dus mogelijk dat bepaalde concepten in de ArchiMate modelleertaal en de service blueprinting modelleertaal tot op een zekere hoogte hetzelfde kunnen uitdrukken. We gebruiken daarbij de concepten vanuit een service blueprint als een referentie om deze te kunnen vergelijken met concepten uit ArchiMate. Er zijn drie categorieën bij het vergelijken van de concepten in hun semantisch veld. De eerste is een volledige overlap tussen een concept van service blueprinting en een concept uit Archimate. De volledige overlap in het semantische veld kan gebeuren met één concept of met een combinatie van meerdere concepten. De tweede mogelijkheid is dat er een partiële overlap is en als laatste mogelijkheid is er geen of onvoldoende overlap tussen concepten in beide modelleertalen. Alle mogelijkheden worden voorgesteld in Figuur 18, waarbij volledige overlap aangeduid wordt met een gedeeltelijke overlap als p en geen overlap als. Het is echter niet altijd zo dat een concept als een mooi afgelijnde figuur voorgesteld kan worden zoals de ovalen die gebruikt worden in de figuur, dit is louter om het principe te illustreren. We bevinden ons op het niveau van concepten waar er een deel subjectiviteit aan te pas komt bij de analyse. Wij bepalen de graad van overlap aan de hand van de definities en hoe deze in de realiteit worden gebruikt zoals in uitgewerkte voorbeelden. Daarvoor komen de definities uit DEEL III en de ervaringen uit DEEL IV van pas waar we de concepten en mogelijkheden in de praktijk hebben bestudeerd. Een volledige overlap is er wanneer een concept binnen service blueprinting kan worden voorgesteld door middel van concepten binnen ArchiMate. Partiële overlap is er wanneer we vinden dat het concept in service blueprinting onvoldoende kan worden voorgesteld met concepten binnen ArchiMate. Als laatste is er geen overlap wanneer we vinden dat er geen duidelijke overeenkomsten zijn tussen een concept in service Blueprinting en concepten in ArchiMate. Figuur 18: Vergelijking overlap concepten semantisch veld 47

61 Service blueprinting vs. Business laag Actor categorieën binnen service blueprinting kunnen eenvoudig door business actoren en rollen worden voorgesteld binnen ArchiMate. Zowel de klanten, frontstage, backstage en ondersteunend personeel kunnen worden voorgesteld. Er is ook steeds de mogelijkheid om extra actoren toe te voegen in de business laag. Acties kunnen volledig worden vervangen door gebruik te maken van de business processen, services, samenwerking en de functies. De actiestroom kan eveneens volledig worden vervangen door gebruik te maken van de meerdere processen, services, samenwerking en functies in combinatie met de stroom- en triggering-relatie. Hoewel er geen concept binnen de business laag is die de lijn van interactie, zichtbaarheid of interne interactie expliciet kan voorstellen, zijn er toch enkele mogelijkheden. Er is de mogelijkheid om via de groeperingsrelatie een onderscheid te maken tussen verschillende objecten. Zo kunnen objecten van de klant, frontoffice, backoffice en ondersteunende objecten worden gegroepeerd. Het is mogelijk om de lijn van zichtbaarheid duidelijk te maken door een onderscheid te maken tussen frontoffice acties en backoffice/ondersteunende acties door middel van het verschil tussen functies en services. Het is namelijk zo dat services acties voorstellen die extern zichtbaar zijn, terwijl de functies eerder intern zijn. Het is wel zo dat er dan geen onderscheid kan gemaakt worden tussen interne acties en ondersteunende acties. Een andere mogelijkheid is om een verschil te maken tussen actoren door een bepaalde rol toe te wijzen zoals een klantenrol, frontoffice-rol, backoffice-rol of een ondersteunenderol. Als laatste mogelijkheid is er de business interface die aangeeft waar een business service toegankelijk wordt gemaakt voor de omgeving. Dit sluit het meeste aan bij de betekenis van de lijnen in een service blueprint aangezien de lijnen gedefinieerd zijn als een soort interface. Het verschil is dat deze interfaces een expliciete betekenis krijgen. De communicatie en communicatiestroom kunnen worden weergegeven door gebruik te maken van de business interactie en/of de business samenwerking die in relatie worden gebracht door middel van de stroom en triggering relatieconcepten. Fysieke bewijzen kunnen deels worden voorgesteld door de interface, locatie, object en voorstelling concepten. Dit komt doordat fysieke bewijzen heel ruim gedefinieerd zijn en alles kan voorstellen waar de klant mee in contact komt. Als laatste kan een event de problemen aangeven die invloed hebben zoals een faalpunt of bottleneck aangeeft bij service blueprinting, waarbij duidelijk wordt aangegeven wat de impact is van het event. Alles wordt nog eens op een rijtje gezet in Tabel

62 Tabel 13: Indicatieve analyse service blueprint vs. business laag CONCEPT SERVICE BLUEPRINT OVERLAP BUSINESS LAAG CONCEPT ACTOR CATEGORIEËN Actor, rol ACTIE Proces, service, functies, samenwerking ACTIE STROOM Proces, service, functies, samenwerking + Stroom, triggering LIJN VAN INTERACTIE p Groeperingsrelatie, rol, interface LIJN VAN ZICHTBAARHEID p Groeperingsrelatie, verschil functie-service, rol, interface LIJN VAN INTERNE INTERACTIE p Groeperingsrelatie, rol, interface COMMUNICATIE Interactie, samenwerking COMMUNICATIESTROOM Interactie, samenwerking + Stroom, triggering FYSIEKE BEWIJZEN p Interface, locatie, object, voorstelling FAALPUNTEN/BOTTLENECKS Event Service blueprinting vs. applicatie laag Binnen de applicatie laag worden geen concepten voor actoren voorzien waardoor deze ook geen acties of actiestromen kunnen verrichten. Het is binnen de applicatie laag meer de opzet om het concept van een component als soort van actor te beschouwen die gebruikt kan worden om bijvoorbeeld de klant voor te stellen. Dit sluit aan bij van Benghozi et al. (2014) die virtuele zones in een service blueprint voorstelde, wat we reeds in DEEL IV hebben besproken. De component kan dan (virtuele) acties verrichten via functies (intern) en services (extern) en deze via de stroom en triggering relatie een actiestroom voorstellen. Via deze acties kan men duidelijk de communicatie van de klant met de applicaties schetsen. Het is dus de bedoeling om de klant als een soort virtuele actor te beschouwen die gebruik maakt van de applicaties in de onderneming. Via de groeperingsrelatie kan opnieuw een onderscheid gemaakt worden tussen verschillende objecten om zo de lijnen van interactie, zichtbaarheid en interne interactie te simuleren, maar dit dus opnieuw enkel voor objecten. Ook het verschil tussen functies en services zijn opnieuw mogelijkheden om de lijn van zichtbaarheid te vervangen, maar opnieuw met dezelfde limieten zoals aangehaald in 49

63 de business laag. Ook is opnieuw de interface een mogelijkheid om de lijnen voor te stellen doordat deze aangeeft hoe iets toegankelijk wordt gemaakt. Het bestaande interfaceconcept is het dan weer niet mogelijk om een expliciet onderscheid aan te geven tussen klant, frontoffice, backoffice en ondersteunende zaken. De communicatie en communicatiestroom in service blueprinting kan, wanneer men de klant als component beschouwt, eveneens voorgesteld door middel van de applicatie interactie en samenwerking met de stroom en triggering relaties. Voor Fysieke bewijzen kan een data object gebruikt worden, dit kunnen bijvoorbeeld bepaalde gegevens zijn die voor de klant zichtbaar zijn. Maar ook de interface kan duidelijk maken hoe bijvoorbeeld deze objecten ontvangen worden en kunnen dus gebruik worden om de meer tastbare belevingen van de klant duidelijk te maken. Opnieuw zijn echter niet alle mogelijkheden voor fysieke bewijzen te modelleren met de concepten in de applicatie laag. Voor faalpunten/bottlenecks zijn geen concepten voorhanden binnen de applicatie laag die een overlap vertonen. Tabel 14: Indicatieve analyse service blueprint vs. applicatie laag CONCEPT SERVICE BLUEPRINT OVERLAP APPLICATIE LAAG CONCEPT ACTOR CATEGORIEËN Component ACTIE Functies, services ACTIE STROOM Functies, services + stroom, triggering LIJN VAN INTERACTIE p Groeperingsrelatie, interface LIJN VAN ZICHTBAARHEID p Groeperingsrelatie, verschil functie-service, interface LIJN VAN INTERNE INTERACTIE p Groeperingsrelatie, interface COMMUNICATIE Interactie, samenwerking COMMUNICATIESTROOM Interactie, samenwerking + stroom, triggering FYSIEKE BEWIJZEN p Object, interface FAALPUNTEN/BOTTLENECKS / 50

64 Service blueprinting vs. technologie laag De technologie laag binnen Archimate dient om de (IT-)infrastructuur in de onderneming voor te stellen. Vandaar dat de klant als actor opnieuw anders beschouwd moet worden indien men een service blueprint wil realiseren, namelijk als een virtuele klant-node die gegevens kan verwerken, produceren en opslaan. Wanneer men de klant volgens dit perspectief aanschouwt is het opnieuw mogelijk om met de stroomen triggeringrelaties in combinatie met het service- en functieconcept acties en actiestromen voor te stellen. Er is een mogelijkheid om communicatie expliciet voor te stellen via een communicatie pad concept, maar dit specifiek tussen twee of meer nodes. Communicatiestroom kan eveneens worden gemodelleerd met behulp van de triggering- en stroomrelaties. Er kan ook hier een onderscheid worden gemaakt tussen de front- en backoffice technologieën door het verschil tussen service en functie. En de lijnen van interactie, zichtbaarheid en interne interactie kunnen worden vervangen door de groeperingsrelatie. De interface kan eveneens om dezelfde redenen worden gebruikt zoals in de vorige lagen aangegeven. Er is eveneens slechts deels een overlap met de Fysieke bewijzen door de ruime betekenis in service blueprinting. Met de infrastructuur kunnen enkel de IT-gerelateerde zaken worden voorgesteld. De faalpunten/bottlenecks kunnen ook in de business laag niet worden gemodelleerd met de bestaande concepten. Tabel 15: Indicatieve analyse service blueprint vs. technologie laag CONCEPT SERVICE BLUEPRINT ACTOR CATEGORIEËN Node OVERLAP TECHNOLOGIE LAAG CONCEPT ACTIE Functie, service ACTIE STROOM Functies, services + Stroom, triggering LIJN VAN INTERACTIE p Groeperingsrelatie, interface LIJN VAN ZICHTBAARHEID p Groeperingsrelatie, verschil tussen functieservice, interface LIJN VAN INTERNE INTERACTIE p Groeperingsrelatie, interface 51

65 COMMUNICATIE Communicatie pad, netwerk COMMUNICATIESTROOM Communicatie pad + stroom, triggering FYSIEKE BEWIJZEN p Apparaat, artifact, interface FAALPUNTEN/BOTTLENECKS / Service blueprinting vs. Motivatie extensie Het is mogelijk om de concepten binnen de motivatie extensie te linken met concepten uit de verschillende lagen (business, applicatie, technologie) aan de hand van de vereiste en beperking concepten. We bespreken hier echter het geïsoleerde geval van de extensie zelf. De motivatie extensie heeft als doel om de motivaties of redenen achter het design of de verandering voor de architectuur in de onderneming voor te stellen. Het is met de concepten in deze extensie mogelijk om de verschillende actoren voor te stellen door middel van het stakeholder concept. De faalpunten kunnen worden aangegeven door gebruik te maken van het driver concept. Deze kunnen dan dieper worden uitgewerkt door middel van het beoordelingsconcept die de driver verder onderzoekt. De driver wordt in deze context dan wel met een negatieve connotatie gebruikt. De Bottlenecks daarentegen kunnen worden beschouwd worden als beperking bij het doorlopen van het proces. Daarom kan het beperkingsconcept gebruikt worden om aan te tonen dat er een bottleneckprobleem kan zijn. Tabel 16: Indicatieve analyse service blueprint vs. Motivatie extensie CONCEPT SERVICE BLUEPRINT ACTOR CATEGORIEËN Stakeholder ACTIE / ACTIE STROOM / LIJN VAN INTERACTIE / LIJN VAN ZICHTBAARHEID / LIJN VAN INTERNE INTERACTIE / COMMUNICATIE / COMMUNICATIESTROOM / OVERLAP MOTIVATIE EXTENSIE CONCEPT 52

66 FYSIEKE BEWIJZEN / FAALPUNTEN Driver BOTTLENECKS Beperking Service blueprinting vs. Implementatie & migratie extensie Het is ook hier mogelijk om met verschillende concepten binnen deze extensie een link te maken met kernconcepten van verschillende lagen in ArchiMate. We bespreken opnieuw het geïsoleerde geval van de extensie zelf. Daarbij is er een zekere overlap met de concepten actie en actiestroom via het werkpakket concept en de stroom en triggering relaties. Een werkpakket is echter tijdelijk, waardoor het niet gebruikt kan worden bij een standaardproces dat doorlopen wordt. Deze extensie maakt zoals eerder vermeld gebruikt van de relaties die eveneens beschikbaar zijn bij de kernconcepten. Ook hier kan men de lijnen van interactie, zichtbaarheid en interne interactie simuleren door middel van de groeperingsrelatie, maar expliciete concepten zijn ook in deze extensie niet voorhanden. Verder kunnen Fysieke bewijzen voor een deel worden vervangen door middel van het deliverable concept dat een uitkomst is van een werkpakket. Opnieuw is het concept rond fysieke bewijzen veel ruimer dan hier kan worden voorgesteld. Er is ook nog een kleine overlap met faalpunten en het gapconcept. Een gap is echter eerder een tijdelijk verschil in twee toestanden. Maar het is dus wel mogelijk om hiermee een bepaald probleem aan te duiden, toch zijn faalpunten ruimer dan enkel een verschil tussen twee tijdelijke toestanden. Tabel 17: Indicatieve analyse service blueprint vs. implementatie & migratie extensie CONCEPT SERVICE BLUEPRINT ACTOR CATEGORIEËN / OVERLAP IMPLEMENTATIE & MIGRATIE EXTENSIE CONCEPT ACTIE p Werkpakket ACTIE STROOM Werkpakket + stroom, triggering LIJN VAN INTERACTIE (Groeperingsrelatie) LIJN VAN ZICHTBAARHEID (Groeperingsrelatie) LIJN VAN INTERNE INTERACTIE (Groeperingsrelatie) 53

67 COMMUNICATIE / COMMUNICATIESTROOM / FYSIEKE BEWIJZEN p Deliverable FAALPUNTEN p Gap BOTTLENECKS / Conclusie We hebben nu onderzocht welke concepten in service blueprinting overlappen met concepten in Archimate. Dit hebben we gedaan voor elke laag en elke extensie afzonderlijk. Het is echter mogelijk om combinaties te maken van verschillende lagen en extensies. Daarvoor richten we ons terug op viewpoints om te kijken wat de mogelijkheden hiermee zijn. 3. Analyse van een service viewpoint Om een model te maken in Archimate dient er een viewpoint ontworpen te worden. Daarbij hebben we in DEEL IV, de praktijkanalyse, enkele voorbeelden van standaardviewpoints besproken. Wanneer we serviceconcepten in ArchiMate willen verwerken, zal dit aan de hand van een nieuwe viewpoint zijn. In dit hoofdstuk gaan we na hoe deze viewpoint er moet uitzien en maken we enkele keuzes tussen verschillende opties die ervoor moeten zorgen dat we een service blueprint kunnen voorstellen. Daarbij moeten we ook rekening houden met het klantengerichte perspectief in combinatie met een business georiënteerd perspectief waar EA gebruik van maakt zoals we in het begin van dit DEEL V hebben aangehaald. Zo moet er ook nog steeds aandacht zijn voor de architectuur en dus moet er rekening gehouden worden met de processen, structuur en (IT-)infrastructuur van de onderneming. De viewpoint kan op verschillende wijzen worden voorgesteld. De eerste mogelijkheid is om de serviceconcepten voor te stellen binnen elke laag en extensie afzonderlijk. De tweede mogelijkheid is om een combinatie van lagen en extensies te selecteren. Tot slot kan men ook gebruik maken van alle mogelijkheden en dus alle concepten en relaties van de verschillende lagen en extensies in één geheel te gebruiken. 1. Afzonderlijke viewpoints Bij het vergelijken van Tabel 13 tot en met Tabel 17 uit het vorige hoofdstuk kan men concluderen dat de verschillende lagen al een ruime mogelijkheid aan concepten aanbieden om de serviceconcepten bij service blueprinting voor te stellen. De beide extensies lenen zich daarentegen minder toe. Een 54

68 bespreking van de afzonderlijke viewpoints komt neer op dezelfde analyse als de analyse voor overlapping die we eerder deden. 2. Combinatie van lagen en extensies voor een viewpoint De extensies bieden zoals vermeld weinig mogelijkheden voor serviceconcepten in een geïsoleerde context, maar kunnen de kernconcepten aanvullen om eventuele ontbrekende serviceconcepten voor te stellen. De belangrijkste concepten binnen de motivatie laag die kunnen worden gebruikt ter ondersteuning van de kernlagen bij het modelleren van een service zijn de driver en de beperking. Dit komt doordat de faalpunten en bottlenecks niet kunnen gemodelleerd worden in zowel de applicatie laag als de technologie laag. Stakeholders zijn minder nodig aangezien in elke laag wel een mogelijkheid bestaat om de actoren voor te stellen. Bij de implementatie & migratie extensie kunnen geen concepten gebruikt worden die een betere overeenkomst vertonen met bepaalde serviceconcepten ten opzichte van de andere concepten in de kernlagen. De business laag komt het meest overeen met wat men in een service blueprint wil voorstellen. Daarbij stelt de klant een natuurlijk persoon voor die in relatie staat met de onderneming. We hebben echter ontdekt dat bij de applicatie laag de applicaties en softwareprocessen kunnen worden besproken waar een soort virtuele klant de interacties met de onderneming duidelijk maakt. De technologie laag daarentegen heeft als grote meerwaarde om de infrastructuur voor te stellen die behoort bij het doorlopen van het virtuele klantenproces. Afhankelijk van de doelstellingen en de focus die men wil leggen is het ook mogelijk om combinaties te maken met meerdere lagen in een viewpoint. Er moet echter wel rekening gehouden worden met de toenemende complexiteit die voortvloeit uit het combineren van de verschillende lagen omdat hierdoor meerdere aspecten worden behandeld. Dit resulteert vaak in een grotere abstractie binnen alle lagen om deze complexiteit te reduceren. 3. Alles binnen één viewpoint De laatste mogelijkheid bestaat erin om de drie lagen samen in één viewpoint te gieten en zo een gelaagde view te verkrijgen. Dit is mogelijk doordat de drie lagen elk een verschillende focus leggen wanneer men het klantenproces zou doorlopen. Het grote probleem hiermee is dat door het level van detail bij de service blueprint en de combinatie van de drie lagen (en eventueel extensies) de complexiteit enorm toeneemt en het overzicht daardoor verloren kan gaan. Indien men deze complexiteit wil reduceren moet men meer abstracties maken binnen de lagen waardoor een groot deel aan informatie verloren gaat die in een service blueprint wel aan bod zou komen. 55

69 4. Conclusie We maken de keuze om drie verschillende viewpoints te realiseren, daar de business, applicatie en technologie laag elk een andere focus kunnen leggen op het serviceproces. Ook leidt het samenvoegen van meerdere lagen in één viewpoint tot een grote complexiteit of een te groot level van abstractie. Aangezien een service blueprint vrij gedetailleerd uitgewerkt kan worden, is het beter om te werken met verschillende viewpoints. Het resultaat die wij beogen zijn dus drie nieuwe viewpoints, één voor elke laag: de business service blueprint, de applicatie service blueprint en de technologie service blueprint. Elk van deze lagen kan worden aangevuld met de motivatie extensie die het mogelijk maakt om faalpunten en bottlenecks te modelleren aan de hand van respectievelijk het driverconcept en het beperkingsconcept. Er rest dan enkel nog de onvolledigheid van vier zaken: - De lijn van interactie - De lijn van zichtbaarheid - De lijn van interne interactie - De fysieke bewijzen Hoewel de lijnen vervangen kunnen worden door gebruik te maken van een interface, schept het expliciete gebruik van de verschillende lijnen meer duidelijkheid over de functionaliteiten. Dit brengt een duidelijke structuur teweeg die gebruikt kan worden in de viewpoint. Zo heeft het overschrijden van de lijn van interactie duidelijk de betekenis dat er communicatie is tussen klant en het frontoffice. Daarom willen we deze 3 lijnen eerder modelleren als een specialisatie van de interface met een specifieke functionaliteit en dit voor de drie lagen. Als vierde is er de onvolledigheid bij het voorstellen van fysieke bewijzen. Hoewel veel mogelijkheden beschikbaar zijn om fysieke bewijzen voor te stellen, zoals de objectconcepten, is de definitie in service blueprinting veel ruimer. We kunnen dit oplossen door bestaande concepten in ArchiMate ruimer te definiëren en meerdere relaties toe te laten opdat er meer overlap is in de betekenis van het fysieke bewijs. Een andere mogelijkheid is dat we een nieuw concept definiëren, waarbij we kijken wat de mogelijke relaties zijn met de bestaande concepten. In dit onderzoek kiezen we voor het tweede waarbij we kijken voor elke laag om een nieuw concept te definiëren opdat het mogelijk is om alle mogelijke fysieke bewijzen aan te tonen. De reden waarom we een nieuw concept aanraden is om de bestaande concepten en de bestaande relaties te behouden zoals deze nu zijn gedefinieerd, zo kan verwarring vermeden worden met bestaande modellen. Een nieuw concept laat ons ook de ruimte om de definiëring beter af te stemmen op de betekenis van fysieke bewijzen zoals deze in een service blueprint gedefinieerd zijn. 56

70 DEEL VI: RESULTAAT In dit hoofdstuk maken we gebruik van alle informatie uit de vorige delen om tot concrete modellen van een service blueprint in ArchiMate te komen. Daarvoor moeten we eerst de definiëring van de nieuwe concepten vastleggen evenals hun relaties met de bestaande concepten in het metamodel. Na de definiëring kijken we hoe we de nieuwe concepten visueel kunnen voorstellen. Dit doen we door gebruik te maken van de richtlijnen voorgesteld door D. Moody (2009). We bespreken eerst kort deze richtlijnen en passen deze daarna toe. In onze onderzoeksmethode komt dit DEEL overeen met: Stap 4: Aanbevelingen 1. Definiëring concepten Lijninterfaces We plaatsen de lijn van interactie, lijn van zichtbaarheid en lijn van interne interactie als een specialisatie van de interface concepten in ArchiMate. Net als bij de groeperingsrelatie duiden deze lijninterfaces eveneens aan dat bepaalde concepten bij elkaar horen, gebaseerd op een bepaalde karakteristiek. In tegenstelling echter tot de groeperingsrelatie en het interfaceconcept duiden de nieuwe lijnconcepten een interface aan met een specifieke karakteristiek. Tabel 18: Definitie nieuwe lijnconcepten in business laag CONCEPT LIJN VAN INTERACTIE LIJN VAN ZICHTBAARHEID LIJN VAN INTERN INTERACTIE DEFINITIE De interface tussen concepten van hetzelfde type of een verschillend type die ofwel bij de klant horen ofwel bij het frontoffice. De interface tussen concepten van hetzelfde type of een verschillend type die ofwel bij het frontoffice horen ofwel bij het backoffice. De interface tussen concepten van hetzelfde type of een verschillend type die ofwel bij het backoffice horen ofwel bij het ondersteunende. 57

71 Tabel 19:Definitie nieuwe lijnconcepten in applicatie laag CONCEPT LIJN VAN INTERACTIE LIJN VAN ZICHTBAARHEID LIJN VAN INTERN INTERACTIE DEFINITIE De interface tussen concepten van hetzelfde type of een verschillende type die ofwel bij de virtuele klant horen ofwel bij frontofficeapplicaties. De interface tussen concepten van hetzelfde type of een verschillende type die ofwel bij de frontoffice-applicaties horen ofwel bij het backoffice-applicaties. De interface tussen concepten van hetzelfde type of een verschillende type die ofwel bij de backoffice-applicaties horen ofwel bij de ondersteunende-applicaties. Tabel 20: Definitie nieuwe lijnconcepten in technologie laag CONCEPT LIJN VAN INTERACTIE LIJN VAN ZICHTBAARHEID LIJN VAN INTERN INTERACTIE DEFINITIE De interface tussen concepten van hetzelfde type of een verschillende type die ofwel bij de klant horen ofwel bij de frontoffice-technologie. De interface tussen concepten van hetzelfde type of een verschillende type die ofwel bij de frontoffice-technologie horen ofwel bij de backoffice-technologie. De interface tussen concepten van hetzelfde type of een verschillende type die ofwel bij de backoffice-technologie horen ofwel bij de ondersteunende-technologie. Perceptibel bewijs In tegenstelling tot het serviceconcept fysieke bewijzen in service blueprinting, spreken wij eerder van perceptibel bewijs. Met dit concept willen we alles duidelijk maken dat waarneembaar kan zijn voor de klant. Het verschil met fysieke bewijzen ligt voornamelijk in het feit dat we ook in de applicatie laag zaken willen aantonen die waarneembaar zijn door de klant. Daar applicaties ook heel veel niet fysieke aspecten kunnen bevatten, zoals bijvoorbeeld de lay-out van een reservatiesysteem, en we deze ook willen kunnen aantonen, is gekozen voor een ruimer concept dan enkel het fysiek waarneembare. In elke laag van ArchiMate valt het perceptibel bewijs onder de categorie van passief structuurconcept. Voor de technologie laag wordt er echter geen perceptibel bewijs gedefinieerd omdat deze laag reeds 58

72 focust op de tastbare IT-infrastructuur. Wij willen deze focus op de IT infrastructuur behouden, waardoor we geen extra concept toevoegen daar we veronderstellen dat alle nodige concepten voor IT infrastructuur kunnen worden voorgesteld met de bestaande concepten in de technologie laag. We definiëren dit concept nu voor de twee andere lagen in ArchiMate. Tabel 21: Perceptibel businessbewijs CONCEPT PERCEPTIBEL BUSINESSBEWIJS DEFINITIE Alles dat waarneembaar is door de klant in het proces van de service op het business level. Tabel 22:Perceptibel Applicatiebewijs CONCEPT PERCEPTIBEL APPLICATIEBEWIJS DEFINITIE Alles dat waarneembaar is door een virtuele klant die het proces doorloopt door gebruik te maken van applicaties. 2. Aangepast metamodel We kijken nu hoe de nieuwe concepten zich verhouden ten opzichte van de bestaande concepten in elke laag. Aangepast business metamodel In het metamodel van de business laag zien we een business object als een specialisatie van het perceptibel bewijs. Daarnaast is er ook een associatierelatie met een business actor, om duidelijk te kunnen maken wat de klant als actor allemaal kan waarnemen. De lijn van interactie, zichtbaarheid en interne interactie zijn dan weer een specialisatie van de business interface. 59

73 Figuur 19: Aangepast business metamodel Aangepast applicatie metamodel Eveneens in het metamodel van de applicatie laag zien we het data object in de applicatie laag als een specialisatie van het perceptibel applicatiebewijs. Verder is er ook een associatierelatie met de applicatie component die een virtuele klant kan voorstellen. Daarnaast zien we dat de lijn van interactie, lijn van zichtbaarheid en de lijn van interne interactie een specialisatie zijn van het interface concept. Figuur 20: Aangepast applicatie metamodel 60

74 Aangepast technologie metamodel In de technologie laag nemen we geen perceptibel bewijs op zoals eerder vermeld. Wel zijn de lijn van interactie, zichtbaarheid en interne interactie eveneens in de technologie laag beschikbaar en zijn deze eveneens een specialisatie van de interface. 3. Visualisaties Er rest ons nu nog om de gedefinieerde concepten visueel voor te stellen. Visuele voorstellingen zijn een belangrijk deel geworden binnen de IT. Er is echter weinig onderzoek naar de evaluatie en de vergelijking van verschillende notaties, ook wordt de visuele syntax zelden behandeld. In dit domein lag de focus voornamelijk op de semantiek. Daarom stelde D. Moody (2009) richtlijnen op bij visuele notaties om zowel de semantiek als syntax te behandelen. Daarbij moest ook rekening gehouden worden dat de mens goed overweg kon met deze visualisaties en deze kan gebruiken om te communiceren. Dit resulteerde in een designtheorie dat de naam physics of notations meekreeg (Moody, 2009). Hiermee kan men bestaande visualisaties vergelijken of verbeteren, maar eveneens nieuwe ontwerpen. Maar wat is nu een goede visuele voorstelling? Daarvoor is het begrip cognitieve doeltreffendheid belangrijk om aan te tonen wat goed is voor een mens-georiënteerde visualisatie. De definitie van cognitieve doeltreffendheid is: de snelheid, het gemak en de accuraatheid waarmee een voorstelling kan worden verwerkt in het menselijke brein (Larkin & Simon, 1987). De richtlijnen voorgesteld door D. Moody kunnen worden aangevuld of gereduceerd, hier wordt gebruik gemaakt van volgende richtlijnen om consistent, onderbouwde visuele voorstellingen te kunnen realiseren: 61

75 Duidelijkheid in de semantiek Er moet een een-op-een relatie zijn tussen het semantische construct en het grafische symbool. Dit betekent dat een grafisch symbool maar één en slechts één betekenis mag hebben waardoor een gebruiker geen keuzes dient te maken. Onze Nederlandse taal voldoet bijvoorbeeld niet aan deze richtlijn aangezien we synoniemen en homoniemen hebben. Onderscheid in symbolen Er moet gemakkelijk een verschil te onderscheiden zijn tussen de gebruikte symbolen waardoor er geen verwarring ontstaat. Dit is gerelateerd aan het menselijk brein om visuele informatie te verwerken door verschillen na te gaan met hetgeen men al kent. Transparantie in semantiek Het gebruik van visuele voorstellingen waarbij het voorkomen de betekenis tracht te suggereren. Terwijl het vorige een duidelijk onderscheid verwacht tussen symbolen onderling, is het hier de bedoeling dat een symbool signalen geeft over zijn eigen betekenis. Management in complexiteit Het is de bedoeling om met een visuele voorstelling de nodige informatie te verschaffen zonder het menselijk brein te overladen. Cognitieve integratie Het is vaak zo dat men maar een deel van het geheel voorstelt om de complexiteit te reduceren. Dit zorgt er natuurlijk wel voor dat men zelf het plaatje moet kunnen passen in het ruimer geheel. Daarom moet er een vorm van integratie zijn met het geheel om deze stap gemakkelijker te maken voor het menselijke brein. Visuele expressiviteit Om een grafische voorstelling te maken zijn er meerdere variabelen beschikbaar dan enkel de vorm. Zo zijn er bijvoorbeeld ook mogelijkheden om verschillen aan te duiden via structuur, oriëntatie, grootte, kleur, etc. Gebruik van tekst Het gebruik van tekst kan gebruikt worden om complementair te zijn aan de visuele voorstelling. Hoewel een visuele voorstelling meer expressiviteit vertoont dan woorden, kan men deze toch in combinatie gebruiken. 62

76 Visualisaties nieuwe concepten We baseren ons voor de lijnen van interactie, zichtbaarheid en interne interactie op de bestaande visualisaties uit service blueprinting om ze toe te passen in de ArchiMate modelleertaal. ArchiMate maakte voor vele concepten en relaties reeds gebruik van bestaande modelleertalen zoals BPMN, UML, etc. Daarbij lag de focus op het integreren van business concepten, nu doen we hetzelfde voor het integreren van serviceconcepten. Voor het perceptibel bewijs hebben we ons gebaseerd op de zintuigen die het mogelijk maken op zaken waar te nemen, we hebben hier gekozen voor een oog. Visualisaties lijnen De drie lijnen worden voorgesteld zoals ze gebruikt worden in service blueprinting, Figuur 21, Figuur 22 en Figuur 23 stellen de concepten visueel voor. Deze visualisaties zijn gebaseerd op een combinatie van de visuele lijnconcepten uit service blueprinting in combinatie met de bestaande interface voorstelling uit de ArchiMate modelleertaal. Daarbij spannen zij zich over het volledige proces die de klant doorloopt en groeperen zij alle zaken van elkaar die gerelateerd zijn aan ofwel de klant, frontoffice, backoffice of ondersteuning. De tekst met de benaming van de lijnen maakt eveneens het verschil duidelijk met het bestaande interface concept uit ArchiMate. Figuur 21: Visualisatie lijn van interactie Figuur 22: Visualisatie lijn van zichtbaarheid Figuur 23: Visualisatie lijn van interne interactie 63

77 Evaluatie visualisaties lijnen We volgen de richtlijnen voorgesteld door het framework van D. Moody (2009) voor het evalueren van visuele notaties. De visualisaties maken een onderscheid mogelijk waardoor deze een interface aangeven wanneer de lijn overschreden wordt. Wanneer we echter kijken naar de integratie in het geheel, dan bestaat er al een concept met soortgelijke visualisatie, namelijk het interfaceconcept. De een-op-een relatie komt er slechts door tekst toe te voegen met de benaming van de lijnen maar ook door de onderlinge positionering. Net zoals bij service blueprinting worden deze concepten gebruikt om het hele proces te overspannen om de verschillende concepten te onderscheiden gebaseerd op een bepaalde karakteristiek (klant, frontoffice, backoffice, ondersteuning). Deze oriëntatie zorgt voor een sterke visuele expressiviteit ten opzichte van de andere concepten. Visualisaties perceptibel bewijs Voor deze visualisatie is gekozen voor een abstracte vorm, een rechthoek, met daarin een oog. Doordat een groot deel van wat we waarnemen met onze ogen gebeurt, hebben we voor dit zintuig gekozen. Het is echter ruimer waardoor we eveneens waarnemingen met andere zintuigen hierin kunnen vermelden, waarbij men eventueel het oog vervangt. Figuur 24: Perceptibel businessbewijs Figuur 25: Perceptibel applicatiebewijs Evaluatie visualisaties perceptibel bewijs Opnieuw volgen we de richtlijnen voorgesteld door het framework van D. Moody (2009) voor het evalueren van de visuele notaties. Het rechthoekige symbool is abstract waardoor de objecten die men 64

78 wil voorstellen legio zijn. Zo kan men er talloze beschrijvingen in toevoegen, dit kan gaan van bijvoorbeeld een gebouw tot bloemen aan de receptie. Het oog in de rechterbovenhoek maakt duidelijk dat deze objecten effectief waarneembaar zijn. Een oog is namelijk een waarnemingsorgaan dat ons in staat stelt om de omgeving rondom ons te zien. Er zijn natuurlijk nog andere zintuigen die men kan gebruiken, maar met ogen kan al veel duidelijk gemaakt worden. In Archimate wordt al gebruik gemaakt van rechthoekige vormen om bijvoorbeeld een business object, contract, product of een data object voor te stellen. Elk van deze concepten heeft nog een extra visueel aspect om zich onderling te onderscheiden, waarbij nog geen oog gebruikt wordt. Ook de kleur zorgt ervoor dat er een onderscheid kan gemaakt worden tussen de business en de applicatie laag. Met de nieuwe visualisatie van een perceptibel bewijs wordt de kleur gekozen dat hoort bij de betrokken laag. Daarnaast zorgt het oog voor een onderscheid tussen de rest van de rechthoekige vormen. Dit zorgt voor duidelijkheid en transparantie in de semantiek. 4. Classificatie & Demonstratie Classificatie service blueprint viewpoints Het grote voordeel van de service blueprinting techniek is dat deze enorm flexibel is. Zo kunnen er nieuwe elementen worden toegevoegd of elementen weggelaten indien dit de verstaanbaarheid ten goede komt. Het is ook mogelijk om zowel op een uiterst gedetailleerd niveau als een meer high-level niveau het proces uit te werken. Bij ArchiMate is een meer striktere set aan regels van toepassing met verschillende relaties en beperkingen die men in rekening moet nemen. Wanneer we dus een service blueprint willen maken in ArchiMate zullen we hier rekening mee moeten houden. We bespreken daarom hoe een service blueprint er moet uitzien in een viewpoint binnen ArchiMate aan de hand van het classificatiesysteem. Wanneer we de viewpoints classificeren in ArchiMate dan situeert een voorstelling van een service blueprint zich op een gedetailleerd niveau. Dit komt doordat de stappen van de klant heel precies in kaart kunnen worden gebracht. Het is natuurlijk ook mogelijk om dit op een hoger niveau van abstractie te modelleren, maar ook in dat geval blijft een service blueprint vrij gedetailleerd in de ArchiMate modelleertaal. Voor de tweede dimensie, het doel, situeert een service blueprint zich onder informerend en ontwerpend. Het is namelijk de bedoeling om met een service blueprint een communicatiemiddel te hebben dat stakeholders informeert over de klant. Bijvoorbeeld welke rol zij spelen in het verwezenlijken van de wensen van de klant. Ook helpt het structuur brengen in de onderneming door 65

79 gebruik te maken van de lijn van interactie, lijn van zichtbaarheid, lijn van interne interactie. Met behulp van deze drie lijnen is het mogelijk om een frontoffice, backoffice en ondersteuning te identificeren. Zo kan men bijvoorbeeld een beeld krijgen van welke zaken allemaal rechtstreeks in contact kunnen komen met de klant en welke zaken geen directe link vertonen. Figuur 26 stelt de classificatie van de viewpoint nog eens grafisch voor, waarbij de donkere schaduwen de eigenschappen van de viewpoint aanduiden. Figuur 26: Service blueprint viewpoint classificatie Service blueprint in ArchiMate We demonstreren in dit hoofdstuk hoe een service blueprint kan worden uitgewerkt in ArchiMate aan de hand van een fictief voorbeeld van een hotelbezoek, zoals bij Bitner et al. (2008). We focussen op een selectie van stappen die een klant daarbij kan maken. Business service blueprint viewpoint Met deze viewpoint worden business elementen in relatie gebracht met het proces dat de klant doorloopt. In DEEL V: ONDERZOEK bleek dat er in de business laag zaken ontbraken om een goede service blueprint voor te stellen. We kijken nu of elk serviceconcept in een service blueprint kan worden voorgesteld met behulp van de nieuwe concepten, zie Tabel 23. Tabel 23: Service blueprint concepten in aangepaste business laag CONCEPT SERVICE BLUEPRINT OVERLAP BUSINESS LAAG CONCEPT ACTOR CATEGORIEËN Actor, rol 66

80 ACTIE Proces, service, functies ACTIE STROOM Proces, service, functies, samenwerking + Stroom, triggering LIJN VAN INTERACTIE Business lijn van interactie LIJN VAN ZICHTBAARHEID Business lijn van zichtbaarheid LIJN VAN INTERNE INTERACTIE Business lijn van interne interactie COMMUNICATIE Interactie, samenwerking COMMUNICATIESTROOM Interactie, samenwerking + Stroom, triggering FYSIEKE BEWIJZEN Perceptibel businessbewijs FAALPUNTEN Vereiste + driver (motivatie extensie) BOTTLENECKS Beperking (motivatie extensie) Uit de tabel blijkt dat we nu in staat zijn om een volledige service blueprint te kunnen voorstellen. Aan de hand van de nieuwe concepten kunnen we nu ook volledig de fysieke bewijzen voorstellen evenals alle lijnen, zonder verwarring met bestaande concepten. Voor de faalpunten en bottlenecks maken we gebruik van concepten uit de motivatie extensie. Aangezien een kernconcept enkel kan gelinkt worden door middel van het beperkingsconcept of vereiste-concept, moeten faalpunten eerst gelinkt worden aan het beperkingsconcept om daarna het driverconcept te kunnen gebruiken. Business service blueprint demonstratie Voor het illustratief voorbeeld van een hotelbezoek hebben we de check-in en het verblijf gemodelleerd voor de klant, zie Figuur 27. Dit voorbeeld dient om het gebruik van de concepten duidelijk te kunnen demonstreren. Daarbij zorgen de lijn van interactie, lijn van zichtbaarheid en lijn van interne interactie voor een onderscheid in respectievelijk de klant, frontoffice, backoffice, en ondersteuning. Voor de check-in moet de klant verschillende gegevens voorzien aan de receptionist die de klant verwelkomt en de nodige informatie verzamelt. Dit gebeurt rechtstreeks met de klant dus aan de front office. Bij die check-in komt de klant in contact met de lobby van het hotel, die hij volledig kan waarnemen. De lobby kan men ook voorstellen met het locatieconcept, maar het perceptibel bewijs maakt duidelijk dat de klant ook alle aspecten van de lobby waarneemt. Indien men dit als locatie zou modelleren, zou men focussen op het geografische, met het perceptibel bewijs ligt de focus op de visuele aantrekkelijkheid van die lobby. Wanneer men aan de receptie nog bezig is met de klant, 67

81 kan men met de verzamelde gegevens de verdere verwerking doen om de administratie in orde te brengen. Dit kan zonder de klant gebeuren waardoor het aan de backoffice toebehoort. Verder bestaat het verblijf van de klant uit slapen en eten. Daarbij wordt het gewenste eten doorgespeelt aan de roomservice die daarna het eten bij de klant komt brengen. Dit behoort allemaal toe tot de front office. Om het eten te maken moet er in de backoffice voor gezorgd worden dat het eten in orde is die de koks hebben voorzien (ondersteunende processen). Het slapen gebeurt logischerwijs in een kamer die voorzien is door het hotel en waarbij de klant de kamer en zijn decoratie zal waarnemen. Daarbij moet men ook rekening houden dat er max 50 kamers zijn (bottleneck). Ook dient elke kamer proper gemaakt te worden, hier rekent men op het schoonmaakpersoneel om dit te realiseren. Er kan echter een probleem optreden (faalpunt) aangezien proper voor sommige klanten spik en span betekent en hogere eisen stellen waardoor een kamer opnieuw onder handen moet worden genomen. 68

82 Figuur 27: Hotelbezoek: business service blueprint 69

83 Applicatie service blueprint viewpoint Om in deze viewpoint de relaties met de klant duidelijk te maken, beschouwen we de klant als een applicatie component met verschillende functionaliteiten. De klant moet men hier dus voorstellen als een soort virtuele klant die in directe relatie kan staan met verschillende andere applicatie componenten (frontoffice) of indirecte relatie heeft (backoffice, ondersteunde processen). We kijken opnieuw welke concepten nu kunnen worden gebruikt om een service blueprint te realiseren in de applicatie laag, zie Tabel 24. Tabel 24: Service blueprint concepten in aangepaste applicatie laag CONCEPT SERVICE BLUEPRINT OVERLAP APPLICATIE LAAG CONCEPT ACTOR CATEGORIEËN Component ACTIE Functies, services ACTIE STROOM Functies, services + stroom, triggering LIJN VAN INTERACTIE Applicatie lijn van interactie LIJN VAN ZICHTBAARHEID Applicatie lijn van zichtbaarheid LIJN VAN INTERNE INTERACTIE Applicatie lijn van interne interactie COMMUNICATIE Interactie, samenwerking COMMUNICATIESTROOM Interactie, samenwerking + stroom, triggering FYSIEKE BEWIJZEN Perceptibel applicatiebewijs FAALPUNTEN Vereiste + driver (motivatie extensie) BOTTLENECKS Beperking (motivatie extensie) Applicatie service blueprint demonstratie Als illustratie tonen we aan hoe de klant communiceert met de systemen om een reservatie en checkin te realiseren, zie Figuur 28. Opnieuw maken de lijnen van interactie, zichtbaarheid en interne interactie een onderscheid tussen de klant, frontoffice, backoffice en ondersteuning. De reservatie gebeurt via de website van het hotel waarbij hij in het reservatiesysteem terecht komt en waarbij de klant zal letten op het design van de website. Op de website kan men de verschillende kamers tonen, waarbij de klant een keuze kan maken. Om de vrije kamers te kunnen weergeven moet het reservatiesysteem met het kamersysteem communiceren om de juiste informatie te voorzien. Dit 70

84 kamersysteem die de toewijzingen van kamers regelt, is niet zichtbaar voor de klant en is dus een backoffice systeem. De prijzen die aangerekend worden aan de klant worden berekend via het financieel systeem dat ondersteuning biedt bij het kamersysteem om de juiste prijzen aan de juiste kamers te kunnen geven. Wanneer de klant wil inchecken aan de receptie dient hij de juiste gegevens te voorzien opdat de reservatie kan teruggevonden worden. Bij die registratie dient het reservatiesysteem opnieuw geraadpleegd te worden om een overzicht van de registratie te krijgen. Het is daarbij mogelijk dat een bepaalde registratie niet goed doorgekomen is waardoor deze niet te vinden is in het systeem (faalpunt). Ook moet men rekening houden met de werkkracht van het reservatiesysteem dat slechts 2Gb werkgeheugen (bottleneck) heeft om alles te verwerken. 71

85 Figuur 28: Hotelbezoek: applicatie service blueprint 72

86 Technologie service blueprint viewpoint De viewpoint met de technologie laag in relatie met het klantenproces moet het mogelijk maken om de nodige infrastructuur in kaart te brengen waar de klant mee in contact kan komen. Dit is de meest tastbare viewpoint, maar ook hier wordt de klant als virtuele klant beschouwd aan de hand van een node. De klant kan verschillende bewerkingen en verwerkingen verrichten die in relatie staan met andere IT-infrastructuur. Zo is het mogelijk om opnieuw het onderscheid te maken tussen de infrastructuur waar de klant rechtsreeks mee in contact komt (frontoffice) en de zaken die geen rechtstreekse relatie hebben met de klant. In Tabel 25 zetten we ze nog eens op een rijtje. Daarbij zien we dat de fysieke bewijzen niet volledig overlappend zijn omdat we in deze laag geen perceptibel bewijs hebben gedefinieerd. Dit komt doordat we in deze laag de focus willen houden op de ITinfrastructuur die nodig is bij het realiseren van alle processen. Tabel 25: Service blueprint concepten in aangepaste technologie laag CONCEPT SERVICE BLUEPRINT ACTOR CATEGORIEËN Node OVERLAP TECHNOLOGIE LAAG CONCEPT ACTIE Functie, service ACTIE STROOM Functies, services + Stroom, triggering LIJN VAN INTERACTIE Technologie lijn van interactie LIJN VAN ZICHTBAARHEID Technologie lijn van zichtbaarheid LIJN VAN INTERNE INTERACTIE Technologie lijn van interne interactie COMMUNICATIE Communicatie pad, netwerk COMMUNICATIESTROOM Nodes + Communicatie pad FYSIEKE BEWIJZEN p Apparaat, artifact, interface FAALPUNTEN Vereiste + driver (motivatie extensie) BOTTLENECKS Beperking (motivatie extensie) 73

87 Technologie service blueprint demonstratie In ons voorbeeld, zie Figuur 29, bekijken we welke IT-infrastructuur nodig is bij het realiseren van de check in. Opnieuw zorgen de lijnen van interactie, zichtbaarheid en interne interactie voor de nodige structuur. Daarbij wordt duidelijk dat de klant enkel in contact komt met de PC die aan de receptie staat (frontoffice). Achter de schermen (backoffice) zorgt deze dat de juiste informatie gehaald wordt door middel van een LAN (ondersteuning). Via dit LAN kan men aan een databaseservice die uit verschillende softwarecomponenten bestaat. Men moet er wel rekening houden dat de snelheid van de LAN maar 20Mb/s is om gegevens te downloaden en 16Mb/s om te uploaden (bottlenecks). 74

88 Figuur 29: Hotelbezoek: technologie service blueprint 75

89 DEEL VII: Conclusie & verder onderzoek 1. Conclusie Gezien het toenemende belang van IT in de toekomst en het grote aandeel van services in het BBP van vele landen, wint de combinatie van IT en services ook meer en meer aan belang. Wij gingen in deze paper op zoek naar een manier om dit aan te pakken. Het is tijd om binnen EA verder te evolueren en ook service-aspecten te integreren, met een focus op de klant. Daarbij kan men gebruik maken van een standaard binnen de servicesector, namelijk de service blueprinting techniek om een service te modelleren. We hebben in deze paper onderzocht of het mogelijk was om met bestaande concepten in een EA-modelleertaal, ArchiMate, een service blueprint te ontwerpen (onderzoeksvraag). Aan de hand van de literatuur en praktijkanalyse zijn deze bestaande concepten geïdentificeerd van zowel service blueprinting als de ArchiMate modelleertaal. Daarna heeft semantische mapping de overlap blootgelegd tussen de concepten. We vonden daarbij dat de ArchiMate modelleertaal al een ruime mogelijkheid biedt om serviceconcepten voor te stellen. We misten echter nog enkele concepten en een verschil in focus van een business-georiënteerd en klant-georiënteerd perspectief. We hebben de ontbrekende concepten geïdentificeerd en daarbij nieuwe concepten in de ArchiMate modelleertaal voorgesteld en aangereikt. Daarbij is het belangrijk om steeds het onderscheid in de verschillende lagen te behouden. De business laag om de interactie met de klant op het business niveau in kaart te brengen, de applicatie laag om de interactie van de klant met de systemen te bepalen en de technologie om de nodige IT-infrastructuur te identificeren die nodig is om dit alles te kunnen realiseren. Dit resulteerde in drie nieuwe viewpoints binnen ArchiMate: Business service blueprint, Applicatie service blueprint en de Technologie service blueprint. Daarbij wordt een focus op de klant gelegd in relatie met de betrokken laag. Voor de applicatie laag en technologie laag wordt daarom een virtuele klant verondersteld opdat deze kan communiceren met de IT. Aan de hand van een demonstratie voor elke nieuwe viewpoint zijn de nieuwe concepten aangetoond evenals hoe de viewpoints moeten worden gebruikt om een service blueprint te realiseren in ArchiMate. Deze nieuwe viewpoints kunnen nu worden gebruikt in de dienstensector voor hotels, banken, restaurants, verzekeringskantoren, om een beter beeld te krijgen van de service die zij aanbieden. Daarbij wordt IT een steeds belangrijkere component om een betere service aan te bieden, denk bijvoorbeeld maar aan de vele online-reservatiesystemen. Deze focus wordt voornamelijk in de applicatie service blueprint en technologie service blueprint duidelijk gemaakt. 76

90 Men moet er echter rekening mee houden dat er een zekere subjectiviteit ontstaat bij het analyseren van het semantische veld van de concepten. Ook zijn de nieuwe voorgestelde viewpoints eerder suggestief daar oneindig veel mogelijkheden bestaan voor het opstellen van een nieuwe viewpoint met serviceconcepten. Daarom kan men deze resultaten niet veralgemenen of exhaustief beschouwen. We hebben getracht het onderzoek vergelijkbaar te maken met bestaand onderzoek door dezelfde methode te hanteren die gebruikt is in eerder onderzoek naar de vergelijking van BPMN en service blueprinting. Zo kan men betere vergelijkingen maken tussen de verschillende modelleertalen zoals BPMN en ArchiMate om een service blueprint voor te stellen. 2. Verder onderzoek We hebben onderzocht hoe service blueprinting concepten in ArchiMate kunnen worden voorgesteld. Daarbij is het zo dat service blueprinting een heel flexibele techniek is waarbij nieuwe concepten kunnen worden toegevoegd. Men kan onderzoeken hoe flexibel de ArchiMate modelleertaal is wanneer men deze nieuwe concepten wil toevoegen. Zo hebben wij de minder gebruikte concepten zoals managementfuncties en lijn van implementatie niet opgenomen. Een verder onderzoek kan dus uitwijzen of het een meerwaarde geeft om deze nieuwe concepten ook in ArchiMate te modelleren. In dit onderzoek werden ook drie nieuwe viewpoints aangereikt en gedemonstreerd aan de hand van de service blueprinting techniek. Men kan echter ook andere mogelijkheden aanreiken om services duidelijk in kaart te brengen. Zo kan men bijvoorbeeld gebruik maken van een andere modelleertaal dan service blueprinting om een service in ArchiMate voor te stellen. Wanneer meerdere mogelijkheden zijn geïdentificeerd en voorgesteld om een service in ArchiMate te modelleren, is het de bedoeling om dit als standaard verder te gaan ontwikkelen. Dit betekent dat nieuwe viewpoints moeten worden gecommuniceerd en geïmplementeerd bij het modelleren van Enterprise Architecture. Daarvoor is het nodig om de nieuwe concepten te programmeren in bestaande tools zoals de Archi-tool die gebruikt worden voor het grafisch weergeven van de ArchiMate modelleertaal. Daarbij moeten EA frameworks zoals TOGAF mee ontwikkelen om een meer service georiënteerde aanpak mogelijk te maken. Deze frameworks moeten helpen om het klantenproces in kaart te brengen en hoe dit allemaal in verhouding staat met de business en IT. 77

91 Lijst van de geraadpleegde werken Benghozi, P.-J., Krob, D., Lonjon, A., & Panetto, H. (2014). Digital Enterprise Design & Management. Digital Enterprise Design & Management (Vol. 261). Bitner, M. J., Ostrom, A. L., & Morgan, F. N. (2008). Service Blueprinting: a practical technique for service innovation. California Management Review, 50(3), Chinosi, M., & Trombetta, A. (2012). BPMN: An introduction to the standard. Computer Standards and Interfaces, 34(1), Eco, U. (1976). A theory of semiotics (Vol. 217). Indiana University Press. Ed, H. J., Band, I., Quartel, D., Franken, H., Adams, M., Haviland, P., & Proper, E. (2012). Using the TOGAF 9. 1 Architecture Content Framework with ArchiMate 2.0 Modeling Language. The Open Group, (July), Fließ, S., & Kleinaltenkamp, M. (2004). Blueprinting the service company - Managing service processes efficiently. Journal of Business Research, 57(4), Gbaguidi, C., Znaty, S., & Hubaux, J.-P. (1996). Service Management: From definition to information modeling. Ieee Globecom, 1 6. Glissman, S., & Sanz, J. (2009). Business Architecture for the Design of Enterprise Service Systems. A Comparative Review of Business Architecture, 10451, Gronroos, C. (1988). Service quality: the six criteria of good perceived service quality. Review of Business, 9(3), Grönroos, C. (2001). The Perceived Service Quality Concept A Mistake? Managing Service Quality, 11(3), pp Henderson, J. C., & Venkatraman, N. (1999). Strategic alignment: Leveraging information technology for transforming organizations. IBM Systems Journal, 32(1), Hoogervorst, J. (2004). Enterprise architecture: Enabling integration, agility and change. International Journal of Cooperative Information Systems, 13(03), IEEE (2000), IEEE Recommended Practice for Architectural Description of Software Intensive Systems (IEEE Std ), IEEE Computer Society Jane Kingman-Brundage. (1991). Technology, design and service quality. International Journal of Service Industry Management, 2(3), Jonkers, H., Band, I., & Quartel, D. (2012). ArchiSurance Case Study. The Open Group, (January), Jonkers, H., Lankhorst, M. M., Ter Doest, H. W. L., Arbab, F., Bosma, H., & Wieringa, R. J. (2006). Enterprise architecture: Management tool and blueprint for the organisation. Information Systems Frontiers, 8(2),

92 Jonkers, H., Proper, E., & Turner, M. (2009). TOGAF TM and ArchiMate : A Future Together. The Open Group, (November), Jonkers, H., Quartel, D., van Gils, B., & Francken, H. (2012). Enterprise Architecture with TOGAF 9.1 and ArchiMate 2.0. Bizzdesign, Larkin, J., & Simon, H. (1987). Why a Diagram is (Sometimes) Worth Ten Thousand Words. Cognitive Science, 11(1), Liu, L., & Özsu, M. T. (2009). Encyclopedia of Database Systems. Encyclopedia of Database Systems. Maes, R. (2003). On the alliance of executive education and research in information management at the University of Amsterdam. International Journal of Information Management, 23(3), Maes, R., & de Vries, E. J. (2008). Redefining business IT alignment through a unified framework. PrimaVera Working Paper Series, Milton, S. K., & Johnson, L. W. (2012). Service blueprinting and BPMN: a comparison. Managing Service Quality, 22(6), Moody, D. (2009). The physics of notations: Toward a scientific basis for constructing visual notations in software engineering. IEEE Transactions on Software Engineering, 35(6), Normann, Richard (1984). Service management. Chichester: Wiley. Op t Land, M.; Proper, E.; Waage, M.; Cloo, J.; Steghuis, C. (2009). Defining Enterprise Architecture. Enterprise Architecture Creating Value by Informed Governance, Peña, C., & Villalobos, J. (2010). An MDE approach to design enterprise architecture viewpoints. Proceedings - 12th IEEE International Conference on Commerce and Enterprise Computing, CEC 2010, Rijsenbrij D., Schekkerman J., Hendrickx H. (2002), Architectuur, besturingsinstrument voor adaptieve organisatie Schwab, K., & Howell, W. L. (2016). World Economic Forum Annual Meeting 2016 Mastering the Fourth Industrial Revolution. The World Economic Forum. Sessions, R. (2007). A Comparison of the Top Four Enterprise Architecture Methodologies. Msdn Microsoft, Shostack, G.L. (1982), How to design a service, European Journal of Marketing, Vol. 16 No. 1, pp Shostack, G. L. (1984). Designing services that deliver. Harvard Business Review, 62(1), Steen, M. W. A., Akehurst, D. H., Ter Doest, H. W. L., & Lankhorst, M. M. (2004). Supporting viewpointoriented enterprise architecture. Proceedings - IEEE International Enterprise Distributed Object Computing Workshop, EDOC, (8), The Open Group. (2013). Archimate 2.1 Specification. TheOpenGroup. (2009). The Open Group Architecture Framework (TOGAF) version 9. The Open Group. Urbaczewski, L., & Mrdalj, S. (2006). A comparison of enterprise architecture frameworks. Issues in 79

93 Information Systems, 7(2), Van Looy, Bart, Paul Gemmel, and Roland Dierdonck (2003). Services management: An integrated approach. Pearson Education Wand, Yair, and Ron Weber. On the ontological expressiveness of information systems analysis and design grammars. Information Systems Journal 3.4 (1993): Winter, R., & Fischer, R. (2006). Essential Layers, Artifacts, and Dependencies of Enterprise Architecture. 10th IEEE International Enterprise Distributed Object Computing Conference, (10). Yair Wand and Ron Weber. (2002). Research Commentary: Information Systems and Conceptual Modeling A Research Agenda. Information Systems Research, 13(4), Zachman, J. (2003). The Zachman Framework For Enterprise Architecture : Primer for Enterprise Engineering and Manufacturing. Zachman, J. A. (1987). A framework for information systems architecture. IBM Systems Journal, 26(3), 18. Zeithaml VA, Bitner MJ (2000). Services marketing. New York: Irwin McGraw Hill 80

94 BIJLAGEN A. ArchiMate: concepten & relaties A

95 B. Relaties binnen ArchiMate Relaties kernconcepten en implementatie & migratie extensie Structural Relationships Notatie Associatie Toegang De relatie tussen objecten die niet omvat zijn door een meer specifieke relatie. De toegang van gedragsconcepten tot een business of data object. Gebruikt door Realisatie Toewijzing Aggregatie Modelleren van het gebruik van services door processen, functies of interacties en de toegang tot interfaces door rollen, componenten en samenwerking. Linkt een logische entiteit met een meer concrete entiteit dat deze realiseert. Linkt units van gedrag met actieve elementen die deze uitvoeren, of rollen met actoren die deze vervullen. Geeft aan dat een object een aantal andere objecten groepeert. Compositie Geeft aan dat een object is samengesteld uit een of meer andere objecten. Dynamische Relates Notatie Stroom Triggering Beschrijft de uitwisseling tussen processen, functies, interacties en events Beschrijft de tijdelijke of causale relatie tussen processen, functies, interacties en events. Other Relationships Notation Groepering Geeft aan dat objecten van hetzelfde type of een verschillende type bij elkaar horen voor een bepaalde karakteristiek. Knooppunt Specialisatie Om relaties van hetzelfde type te verbinden. Geeft aan dat een object een specialisatie is van een ander B

96 Relaties motivatie extensie Intentionele Relaties Associatie Modellering van een bepaalde intentie die gerelateerd is aan de bron. Aggregatie Modellering van een intentioneel element dat uit meerdere intentionele elementen bestaat. Notatie Realisatie Invloed Modellering van een bepaald eind dat gerealiseerd wordt aan de hand van bepaalde middelen. Modellering van een bepaald intentioneel element dat een positieve of negatieve invloed kan hebben op een ander intentioneel element. B

97 C. Service blueprint: hotelbezoek C

98 D. Klassieke Service blueprint: Restaurant (Benghozi et al., 2014) D

99 E. Service blueprint met virtuele zone: Restaurant (Benghozi et al., 2014) E

100 F. Service blueprint: Cafetaria universiteit Phil Barter 2012 (creately) F

101 G. Voorbeeld ArchiMate drie lagen in één viewpoint G

102 H. Organization viewpoint H

103 I. Actor co-operation viewpoint I

104 J. Business function viewpoint J

105 K. Application co-operation viewpoint K