Auteur: Kevin Konings Pagina | 18 van 37 Rapport Productverslag
5. Methode van aanpak
Ter ondersteuning van het afstudeertraject is gekozen voor een aantal methodes. Deze methodes vergroten de kans op een succesvolle afronding. In dit hoofdstuk wordt de gekozen aanpak voor het afstudeertraject nader toegelicht. Ook bevat dit hoofdstuk een beargumentatie voor de gemaakte keuzes.
5.1 Werkwijze
Het afstudeerproject is aan de hand van de Accenture Delivery Method for Business Intelligence (ADM for BI)9 uitgevoerd. De ADM for BI methode is een applicatie ontwikkelingsmethode gebaseerd op de Custom Development v2.1 Method. De methode focust zich op ‘single instance custom data warehouse projects’
die een groot deel van de AIMS-BI projecten vertegenwoordigen.
Enkele grote verschillen ten aanzien van de CD v2.1 methode zijn:
Deliverables
Job aids
ADM for BI volgt dezelfde volgorde als alle ander ADM Development Methods. De methode focust zich op de analyse, het ontwerp, de realisatie en het testen van bijvoorbeeld een data warehouse applicatie. De methode bevat ook richtlijnen voor projectplanning en management. De ADM for BI methode draagt eraan bij om effectieve, consistente en kostenbesparende oplossingen te bieden. Het doel is om samenhang tussen projecten te creëren en risico`s te verminderen met behulp van een standaard project aanpak voor het leveren van op waarde gebaseerde Business Intelligence oplossingen.
In principe is de ADM for BI methode nuttig en aanbevolen voor ieder BI project, maar met onderstaande elementen komt de methode het best tot zijn recht:
Tijdsplanning die correspondeert met de incrementele opleveringen.
Een architectuur zoals die wordt weergegeven in figuur 3.
Het opleveren van een of meer zelf gecreëerde componenten als sleutel elementen in de uiteindelijke oplossing.
Figuur 3: Proces BI project
9 [Bron: ATS BI Bootcamp Lesson 09 - ADM BI.pdf]
Auteur: Kevin Konings Pagina | 19 van 37 Rapport Productverslag
5.2 Fasering
Alle aspecten van het project zijn voorafgaand tijdens de oriëntatiefase vastgelegd in het plan van aanpak.
Dit is gedaan om het afstudeertraject zo beheersbaar mogelijk te maken en duidelijkheid te scheppen hoe alle activiteiten gepland staan en hoe deze activiteiten zo effectief en efficiënt mogelijk uitgevoerd kunnen worden. Tijdens de oriëntatiefase is er gekozen voor een geschikte projectmatige aanpak, namelijk de Accenture Delivery Method (ADM). Deze aanpak faseert het project in verschillende fasen, namelijk:
Plan
Tijdens deze fase is vastgelegd wie de opdracht gaat uitvoeren en wat er moet gebeuren om de opdracht tot een goed eind te brengen. Kortom, alle randzaken zijn vastgesteld om het project goed op te starten.
Analyse
In de analyse fase zijn de eisen bepaald waaraan de uiteindelijke case moet voldoen en is de huidige situatie in kaart gebracht. Een analyse van de voorgaande case is uitgevoerd om zo een compleet beeld te krijgen van wat er vooraf is gegaan aan het project. De interviews ten behoeve van de tool selectie zijn afgenomen en verwerkt in een document welke is terug te vinden in de gescheiden bijlage van dit document. De analyse van de voorgaande case is ook opgenomen als gescheiden bijlage van dit document.
Design
Met de analyse als input en het bepalen van de eisen en wensen is een functioneel ontwerp geschreven van hoe de case er uiteindelijk uit moet gaan zien en welke functionaliteiten de case moet gaan bieden. Alle aspecten die in de case behandeld moeten gaan worden zijn vastgelegd in dit document. Dit document is terug te vinden in de gescheiden bijlage van dit rapport.
Build
De ‘build’ fase bevat de uiteindelijke beschrijving van de case. De onderdelen die opgesteld zijn in het functionele ontwerp zijn uitgewerkt in de case. De case is door de afstudeerder uitgewerkt in de reporting tool die is bepaald aan de hand van de tool selectie in de analyse fase. De beschrijving van de case is te vinden in de gescheiden bijlage van dit document.
Test
In deze fase is de case getest door middel van feedback van de medewerkers en het uitwerken van de case.
Waar nodig is de case aangepast om zo een optimaal rendement te behalen. Omdat de case uiteindelijk definitief in gebruik zal worden genomen kan het altijd zijn dat er nog aanpassingen ten behoeve van de inhoud gedaan gaan worden.
Deploy
De case is door middel van een eindpresentatie overgedragen aan de opdrachtgever. Vanuit dat startpunt is er een verdere voortgang gemaakt met de Reporting & Analytics case. Ook het opleveren van de documentatie voor ATS en de Avans Hogeschool is in deze fase voltooid.
Voor de keuze van de ADM methode zijn een aantal redenen. Een van de belangrijkste redenen is dat de ADM methode DE methode is binnen Accenture. Elk project wat hier uitgevoerd wordt, wordt uitgevoerd aan de hand van deze methode. Dat gaf mij als afstudeerder de kans om in de ‘keuken’ van deze organisatie te kijken. Enkele andere belangrijke redenen zijn de hoeveelheid informatie die over deze methode is te vinden binnen de organisatie en de kennis die bijvoorbeeld mijn directe betrokkenen al hadden over deze methode. Bovenstaande punten maakten het een weloverwogen keuze om de ADM methode op dit afstudeertraject toe te passen.
Auteur: Kevin Konings Pagina | 20 van 37 Rapport Productverslag
5.3 Methode van analyse
Tijdens de analyse fase van mijn afstudeertraject zijn er drie analyses uitgevoerd om de eisen en wensen in kaart te brengen en de huidige situatie goed weer te geven. De analyses worden in de onderstaande paragraven nader toegelicht. De uitkomsten van die analyses worden weergegeven in hoofdstuk 6, de resultaten.
5.3.1 High Level Analysis ETL Case
Voorafgaand aan het afstudeertraject is reeds en met succes een case opgezet door de ETL capability (deze case is overigens nog steeds in ontwikkeling). Het resultaat van de gemaakte ETL case is een gevuld data warehouse wat als uiteindelijke bron dient voor de Reporting & Analytics case. Om een goed beeld te krijgen van wat er in die case behandeld is, welke aspecten naar voren zijn gekomen, hoe de case is opgezet, wat er qua architectuur is, wat het doel van de ETL case is, welke ‘learning objectives’ er opgesteld zijn en hoe het hele ETL proces omtrent de case in elkaar zit, is er een analyse uitgevoerd naar de genoemde ETL case.
Figuur 4: Phase 1: Analyze Application
De analyse beschrijft het voorgaande proces en geeft een oriëntatie van de huidige / voorgaande situatie weer. Met de informatie die uit deze analyse is gekomen is de basis gelegd voor de verdere ontwikkeling van de Reporting & Analytics case. Figuur 4 hierboven toont schematisch het proces wat uitgevoerd is. In de gescheiden bijlage van dit document kan de gehele analyse na gelezen worden.
5.3.2 Tool Selection
Aan de hand van de interviews die er in het begin stadium van dit afstudeertraject zijn gehouden met respectievelijk, Maarten Ketelaars (manager BI & DM cel) en Rogier Jochims (capability lead R & A) is de tool selectie opgestart. De tool selectie is uitgevoerd aan de hand van de methode Pakketselectie en Implementatie (PSI)10. Deze methode verdeelt een project waarmee een pakket wordt geselecteerd en geïmplementeerd in een aantal fasen. Deze fasen zijn op hun beurt weer verder onderverdeeld in taken en activiteiten. Figuur 5 hieronder geeft dit proces schematisch weer.
10 http://ehv-srvhost-fe.fontys.nl/IMD/files/ICT61/diversen/ICT61%20-%20Pakketselectie_begin_eindfase.pdf
Auteur: Kevin Konings Pagina | 21 van 37 Rapport Productverslag
Figuur 5: PSI pakketselectie
Niet alle hierboven genoemde fasen zijn gebruikt tijdens deze selectie omdat de tool selectie hier simpelweg te klein voor was. Onderstaande punten beschrijven de fases en de activiteiten die uitgevoerd zijn ten behoeve van de tool selectie:
Vooronderzoek
Het vooronderzoek bevatte het meeste werk en is uitgevoerd in de analyse fase van het project. In die fase zijn de eisen en wensen geïnventariseerd en is de analyse van de voorgaande case uitgevoerd. De interviews die tijdens deze fase zijn gehouden zijn uitgewerkt en de uitkomsten daarvan vormden belangrijke input voor de uiteindelijke selectie.
Shortlist
Voorafgaand aan het onderzoek was het min of meer duidelijk om welke drie reporting tools het zou moeten gaan. Van een longlist zou dus geen sprake zijn en de shortlist was vooraf al grotendeels bepaald (dit was aangegeven tijdens de interviews). Het belangrijkste om te bepalen was dus met welke reporting tool de case in eerste instantie zou worden uitgevoerd. Dit is gedaan aan de hand van de criteria en voorwaarden die vooraf zijn opgesteld in samenwerking met de geïnterviewden. Deze criteria zijn terug te vinden in hoofdstuk 6 ‘resultaten’ en het tool selectie document, te vinden in de gescheiden bijlage van dit rapport.
Implementatie
Het uitwerken van de reporting tool in de ontwikkelde case vormt de implementatie van deze methode. Op 24 februari 2010 is de case gepresenteerd voor de capability group. Direct hierna is er een start gemaakt met de Reporting & Analytics case door de verschillende teams. Deze activiteiten vielen in de nazorg fase van het afstudeertraject en diende tevens als een uitstekende test voor de toepasbaarheid van de Reporting & Analytics case.
5.3.3 Literatuuronderzoek
Het literatuuronderzoek is bedoeld om het afstudeertraject theoretisch te verankeren en is aan het begin van de afstudeerperiode is uitgevoerd. De volgende twee boeken zijn behandeld tijdens de literatuurstudie:
Business Intelligence - ‘De eenduidige informatieomgeving en de gevolgen voor de organisatie’
Business Intelligence was een vrij nieuw onderwerp voor mij en om met de juiste kennis van start te gaan was de keuze voor een boek over Business Intelligence snel gemaakt. In de eerste week van het
afstudeertraject is er een ‘bootcamp’ gevolgd waarin alle aspecten van Business Intelligence behandeld worden maar met behulp van dit boek is er genoeg informatie verzameld om dit onderzoek uit te voeren.
Competent adviseren - ‘Professioneel aan het werk’
Het afstudeertraject bestaat uit een aantal componenten. Adviseren is er daar een van. Aan het begin van dit afstudeertraject wist ik dat ik op zoek was naar een boek over adviseren. Er zou ten slotte aan het eind van deze afstudeerperiode een gedegen advies moeten komen richting ATS. Dit zou dan wel via het productrapport moeten of via de eindpresentatie. Voor een goede onderbouwing was het daarom een logische keuze om een boek rondom het onderwerp ‘adviseren’ te kiezen. De complete uitwerking van het literatuuronderzoek is te vinden in de gescheiden bijlage van het procesverslag.
Auteur: Kevin Konings Pagina | 22 van 37 Rapport Productverslag
5.4 Methode van ontwerpen
Voorafgaand aan het uiteindelijke beschrijven van de case is er een High Level Design (functioneel ontwerp) van de Reporting & Analytics case opgesteld. De uiteindelijke Reporting & Analytics case is dus gebaseerd op het functionele ontwerp welke in deze fase is ontwikkeld.
5.4.1 High Level Design Reporting & Analytics Case
Het High Level Design van de Reporting & Analytics case kan gezien worden als het functionele ontwerp van de case zelf. In dit ontwerp is de blauwdruk van in dit geval de case gemaakt. Het High Level Design is gebaseerd op de uitkomsten de High Level Analysis en de gesprekken met de directe betrokkenen, namelijk mijn begeleider en opdrachtgever(s). In het High Level Design is beschreven wat er van de case verwacht kan worden en welke functionaliteiten er in de case terug komen. In het High Level Design zijn onder andere de volgende functionaliteiten beschreven:
Ontwerp van de (uiteindelijke) rapporten
• Lay-out
• Tabellen
• Grafieken
• etc.
Eisen en wensen Reporting & Analytics case
• Informatie behoeften
• Fases case
• Rapport activiteiten
• etc.
Het High Level Design van de Reporting & Analytics case is terug te vinden in de gescheiden bijlage van dit document. Figuur 6 toont schematisch het proces wat uitgevoerd is.
Figuur 6: Phase 2: Design Application
Auteur: Kevin Konings Pagina | 23 van 37 Rapport Productverslag
5.5 Methode van testen
Nadat de case beschrijving voltooid is en dit doormiddel van een presentatie aan de capability groep op 24 februari 2010 is gepresenteerd was het zaak om te testen of de case daadwerkelijk voldoet aan de verwachtingen en of er alle benodigde informatie in de case aanwezig is. Aan de hand van de testen die in onderstaande paragraven zijn weergegeven is gekeken en getest of de case compleet en uitvoerbaar is.
5.5.1 Acceptatietest
De acceptatietest is uitgevoerd met behulp van het IRF (Individual Review Form) formulier. In het IRF form hebben gebruikers commentaar kunnen geven op de gerelateerde case documenten. De op- en / of aanmerkingen zijn gedocumenteerd met een pagina en sectie nummer waar de opmerking(en) is / zijn gevonden, evenals een uitgebreide en heldere omschrijving van de opmerking en vooral waarom hij of zij dat vind.
Het IRF formulier is net als alle andere bijbehorende documentatie (case description, high level analysis, high level design etc.) na de tussentijdse presentatie verstuurt naar alle betrokkenen. In een uitgebreide e-mail is gevraagd om de documentatie over de Reporting & Analytics case inhoudelijk goed te bestuderen en eventuele op- en / of aanmerkingen, vragen en suggesties door middel van het IRF formulier terug te sturen voor 5 maart 2010 jl. Het invullen van het IRF formulier heeft ervoor gezorgd de case de week er na nog aangepast en geoptimaliseerd is zodat er na de aanpassingen een start gemaakt kan worden met de case.
Het IRF form is gebruikt als onderdeel van de acceptatietest11. Het doel van deze test is om aan te tonen dat in dit geval de case de gebruiker te zijner tijd kan ondersteunen in de door hem met het product uit te voeren handelingen. De centrale vraag bij de acceptatietest is in dit geval: ‘staat in de case beschrijving wat we verwachten dat er in staat’. De uitkomsten van het IRF formulier zijn verwerkt in de gescheiden bijlagen van dit document.
5.5.2 Feedback form
Bijgevoegd aan de case beschrijving is het feedback form. Dit document is opgesteld door de afstudeerder en dient ingevuld te worden door de deelnemer na het voltooien van de case. Door middel van het invullen van het feedback formulier en het meten van de uitkomsten daarvan wordt duidelijk wat men van de case vind en kunnen eventuele op- en / of aanmerkingen verwerkt worden. Op die manier kan de case na afloop geoptimaliseerd en verbeterd worden voor een eventuele volgende uitwerking binnen de capability of wellicht elders (dit wordt nader toegelicht in het hoofdstuk 7).
Na afloop van de afstudeerperiode zal het uitwerken van de Reporting & Analytics case nog niet voltooid zijn. Het feedback formulier wat is gecreëerd zal pas na het voltooien van de case ingevuld kunnen worden door de deelnemers om zo een goed oordeel te vormen. De feedback formulieren zullen dus ook geretourneerd moeten worden aan de capability lead van Reporting & Analytics welke het project voort zal zetten als de afstudeerperiode erop zit.
5.5.3 Systeemtest
Het uitwerken van de case door de afstudeer zelf is een van de belangrijkste testen geweest om te kijken of de case goed uitvoerbaar en realistisch is. Het door de afstudeerder uitwerken van de case kan worden gezien als een systeemtest en moet aantonen dat het ontwikkelde systeem (Reporting & Analytics case) of delen daarvan aan de functionele- en niet-functionele specificaties voldoen. Het uitvoeren van de case is aan het eind van de afstudeerperiode voltooid.
11 http://nl.wikipedia.org/wiki/Acceptatietest
De methodes van de analyse zijn in paragraaf 5.3 beschreven. De uitkomsten van de verschillende analyses worden beschreven in de onderstaande paragraven.
6.1.1 High Level Analysis ETL case
Voordat de daadwerkelijke Reporting & Analytics case ontwikkeld kon worden was het zaak om een onderzoek te doen naar de voorgaande ETL case die met succes geïmplementeerd was. Het bestuderen van de case en het bespreken van de case met directe betrokkenen (capability lead ETL) resulteerde in een aantal resultaten welke hieronder worden weergegeven. De uitkomsten van deze analyse resulteerden in overzicht van wat er in de voorgaande ETL case ontwikkeld was en dat resulteerde in een aantal verbeterpunten voor de Reporting & Analytics case. Deze verbeterpunten worden ook hieronder weergegeven:
ETL Case - Algemeen Uitkomst analyse
Doel
Het bouwen van de oplossing met vier verschillende ETL tools.
Het vergelijken van de oplossingen in termen van bruikbaarheid en prestaties.
Het verstrekken van trainingsmateriaal voor consultants die niet vertrouwd zijn met het ETL proces.
Doelgroep
Mensen die niet vertrouwd zijn met ETL.
Mensen die willen leren werken met een bepaalde ETL tool.
Mensen die het verschil willen weten tussen bepaalde ETL tools.
ETL ontwikkelaars die zich nieuwe ETL tools eigen willen maken.
Leerdoelen
Inzicht krijgen in het niveau van de ETL vaardigheden.
Het leren van nieuwe tools.
Deliverables
Bron systeem inclusief data (ontwikkeld bron systeem).
Target data model (volledig gegevens model met informatie).
Functioneel ontwerp (beschrijving van de functies per tool).
Technisch ontwerp (beschrijving van de technische functies per tool).
Solution document (beschrijving van de ontwikkeling van de case).
Uitkomst entiteiten aanwezig zijn. Een hogere granulariteit geeft aan dat er -op een zeker niveau- minder details worden opgeslagen.