Online offerte calculatie
Afstudeerverslag
Jordy van der Meij 500531021
Afstudeerverslag
Jordy van der Meij
Titel:
Online offerte calculatie
Naam auteur: Studentnummer: Studierichting:
Jordy van der Meij 500531021 Informatica
Naam school: Instituut: Begeleider:
Hogeschool van Amsterdam Domein Media, Creatie en Informatie Jan Hellings
Opdrachtgever: Begeleider:
Magnus Technology Consultants Christian Onderstal
Datum:
06-01-2012 Pagina 2 van 79
Afstudeerverslag
VOORWOORD Voor u ligt het eindwerk van mijn opleiding Informatica aan de Hogeschool van Amsterdam. Tijdens de gelopen afstudeerstage heb ik laten zien dat ik in staat ben om de laatste krachtproef van mijn studie, een opdracht uit mijn toekomstig beroep zelfstandig te kunnen uitvoeren, succesvol af te ronden. Dit heb ik echter niet geheel alleen kunnen doen en om die reden wil ik een aantal personen bedanken. Allereerst wil ik alle collega’s van mijn afstudeerbedrijf Magnus bedanken met wie ik in contact ben gekomen tijdens deze afstudeerstage. In het bijzonder wil ik Christian Onderstal en Norbert Gundlach bedanken voor hun begeleiding en ondersteuning. Ook wil ik in het bijzonder mijn afstudeerbegeleider Jan Hellings en studieloopbaan begeleider Bert Rengelink, beide van de Hogeschool van Amsterdam, bedanken voor hun begeleiding en ondersteuning tijdens mijn gehele schoolperiode, de afgelopen 3,5 jaar. Dit verslag is geschreven voor personen met een achtergrond, of interesse, in de IT. Om die reden zal niet iedere IT term worden uitgelegd. Termen waarbij wel verdere uitleg vereist is, zijn opgenomen in hoofdstuk “Verklarende woordenlijst” op pagina 56. Wanneer een bepaalde term voor het eerst wordt gebruikt zal deze direct toegelicht worden. Stukken die geschreven zijn op basis van bronnen zullen duidelijk aangegeven zijn. In hoofdstuk “Bronnenlijst” op pagina 58 staan deze bronnen uitgewerkt in meer detail. Wanneer er in de tekst gewezen wordt naar een ander deel in dit verslag, zal dit kenbaar gemaakt worden met een verwijzing. In dat geval komt er bijvoorbeeld een “ 1” teken achter de tekst te staan. Op diezelfde pagina kan in de voettekst de desbetreffende verwijzing worden gevonden. In dit afstudeerverslag zijn, op last van Magnus, alle bedrijfskritische gegevens weggelaten. Wanneer er wel gebruik wordt gemaakt van bedrijfskritische gegevens, zullen deze niet op de werkelijkheid gebaseerd zijn. Dit zal in dat geval duidelijk kenbaar worden gemaakt bij het desbetreffende onderdeel. Graag wens ik u veel plezier bij het lezen van dit afstudeerverslag.
Jordy van der Meij Januari 2012
Jordy van der Meij
Pagina 3 van 79
Afstudeerverslag
SAMENVATTING Magnus is een SAP-dienstverlener dat zich richt op de 500 grootste bedrijven van Nederland. Het werknemersaantal ligt op dit moment rond de 130. Één van de werkzaamheden van Magnus is het uitvoeren van technische SAP beheer projecten. Hieronder valt onder andere het upgraden van verschillende SAP omgevingen. Voor ieder upgradetraject wordt er een offerte opgesteld voor de klant, dit proces is momenteel niet geautomatiseerd. Wanneer dit proces wel wordt geautomatiseerd brengt dit vele voordelen met zich mee. Denk hierbij aan bijvoorbeeld het reduceren van de tijd die het kost om een offerte uit te brengen. Dit project is door Magnus opgezet om het proces van offertes maken te vergemakkelijken. Daarnaast wil Magnus ook een dienst neerzetten waardoor klanten zelfstandig een offerte aanvraag kunnen indienen. Op die manier kan een klant snel en makkelijk een inzicht krijgen in de kosten voor een bepaald SAP upgradetraject. De uitkomst van dit project is een applicatie die te benaderen is via de website van Magnus. Deze applicatie kan door zowel Sales Managers en presales consultants van Magnus als door klanten zelf gebruikt worden om een offerte te op te vragen voor een aantal SAP upgradetrajecten. Met behulp van het analyseren van SAP upgradetrajecten uit het verleden en gesprekken met de betrokkenen van Magnus tijdens deze upgradetrajecten, is er voor ieder type upgradetraject een rekenmodel ontwikkeld. De rekenmodellen geven op basis van een aantal invoer parameters (welke klantspecifiek zijn) een ureninschatting voor de verschillende upgradetrajecten. De rekenmodellen zijn uitvoerig getest om zodoende de nauwkeurigheid en juistheid te waarborgen. Deze rekenmodellen vormen de basis van de applicatie. De offerte die het genereert is namelijk gebaseerd op de uitvoer van de rekenmodellen. Op de offerte zullen bepaalde voorwaarden van kracht zijn om onduidelijkheden en misverstanden te voorkomen voor zowel de klant als Magnus. Met behulp van de DSDM (Dynamic System and Development Method) projectontwikkelingmethodiek is dit project gecontroleerd uitgevoerd. Deze methodiek heeft als uitgangspunt dat de looptijd van het project vast staat en de functionaliteit van de applicatie variabel is. Zo kan de garantie worden gegeven dat het project binnen de gestelde looptijd afgerond is. Een belangrijk onderdeel binnen DSDM is het toewijzen van de juiste prioriteiten aan de functionaliteiten van de applicatie. DSDM gebruikt hiervoor de zogenaamde MoSCoW prioriteringswijze. Daarnaast wordt met behulp van de kwaliteitscirkel van Deming de functionaliteiten van de applicatie geanalyseerd en verbeterd om zodoende de kwaliteit van de applicatie op een afgesproken niveau te houden.
Jordy van der Meij
Pagina 4 van 79
Afstudeerverslag
DOCUMENT GESCHIEDENIS
Uitgifte datum 07-12-2011
Versie Concept
Uitgeleverd aan - Jan Hellings (Hogeschool van Amsterdam) - Christian Onderstal (Magnus Technology Consultants) - Norbert Gundlach (Magnus Technology Consultants)
06-01-2012
Jordy van der Meij
Final
- Maurice van der Meij (Externe lezer) - 4x Tamar Freeve (Hogeschool van Amsterdam)
Pagina 5 van 79
Afstudeerverslag
INHOUDSOPGAVE Voorwoord ............................................................................................................. 3 Samenvatting ......................................................................................................... 4 Document geschiedenis.......................................................................................... 5 1
Inleiding .......................................................................................................... 8 1.1
1.1.1
Toen en nu ............................................................................................. 8
1.1.2
Missie en visie ......................................................................................... 8
1.1.3
Organisatiestructuur................................................................................. 9
1.1.4
Contactgegevens ..................................................................................... 9
1.2
3
4
Onderzoeksvraag ................................................................................... 10
1.2.2
Project doelstellingen ............................................................................. 10
1.2.3
Projectscope.......................................................................................... 10
1.2.4
Randvoorwaarden en uitgangspunten ....................................................... 11
1.2.5
Project ontwikkelingsmethode ................................................................. 11
1.2.6
Kwaliteitswaarborging ............................................................................ 11
1.2.7
Risicobeheersing .................................................................................... 11
Vooraf gestelde competenties en leerdoelen .................................................... 13
Theoretische verdieping ................................................................................. 14 2.1
SAP, een introductie ..................................................................................... 14
2.2
De upgradetechniek van SAP systemen .......................................................... 16
2.3
Project ontwikkelingsmethodiek ..................................................................... 20
2.4
Relatie tot de opdracht ................................................................................. 22
Analyse huidig proces .................................................................................... 23 3.1
Beschrijving huidig proces ............................................................................. 23
3.2
Verbeterpunten ........................................................................................... 26
De rekenmodellen; van getallen naar geraamte ............................................ 27 4.1
5
Aanleiding van het project............................................................................. 10
1.2.1
1.3 2
Magnus, het bedrijf in beeld ............................................................................ 8
De ontwikkeling van de SAP ERP upgrade rekenmodellen .................................. 29
4.1.1
Verzamelfase ........................................................................................ 29
4.1.2
Uniformeerfase ...................................................................................... 31
4.1.3
Ontwikkelfase ........................................................................................ 33
4.1.4
Test en verbeterfase .............................................................................. 34
De rekenmodellen aangekleed ....................................................................... 36 5.1
Gebruikersscenario’s .................................................................................... 36
Jordy van der Meij
Pagina 6 van 79
Afstudeerverslag 5.1.1 5.2
Behoefte onderzoek ..................................................................................... 41
5.3
Het gebruikersscenario uitgewerkt ................................................................. 43
5.3.1
Niet functionele prototypes ..................................................................... 43
5.3.2
Backend ............................................................................................... 47
5.4
Ontwikkelomgeving ...................................................................................... 48
5.4.1 6
Mendix Business modeler ........................................................................ 50
Realisatie, implementatie en beheer .............................................................. 51 6.1
Realisatie .................................................................................................... 51
6.1.1
Het Mendix datamodel ............................................................................ 51
6.1.2
Functies binnen de applicatie ................................................................... 51
6.1.3
De vormgeving ...................................................................................... 52
6.2
Implementatie en testen ............................................................................... 52
6.2.1
Ontwikkel en productieomgeving ............................................................. 52
6.2.2
Testen .................................................................................................. 53
6.3
7
Scenariokeuze ....................................................................................... 37
Het beheer van de applicatie ......................................................................... 53
6.3.1
De backend ........................................................................................... 53
6.3.2
Aanpassingen op de applicatie ................................................................. 54
Reflectie op de werkzaamheden en leerdoelen .............................................. 55
Verklarende woordenlijst ..................................................................................... 56 Bronnenlijst ......................................................................................................... 58 Bijlage A: “Het organogram”................................................................................... 59 Bijlage B: “Prototype schermen in een vroeg stadium” ............................................... 60 Eerste prototype ................................................................................................ 60 Tweede prototype .............................................................................................. 61 Bijlage C “Vragenlijst van het behoefte onderzoek”................................................... 63 Bijlage D “Het niet functionele prototype uitgewerkt” ................................................. 64 Bijlage E: “Mendix; een korte tutorial” ..................................................................... 67 Bijlage F “De applicatie in beeld” ............................................................................. 73 Bijlage G “Het datamodel uitgelegd” ........................................................................ 77
Jordy van der Meij
Pagina 7 van 79
Afstudeerverslag
1
INLEIDING
1.1 Magnus, het bedrijf in beeld 1.1.1 Toen en nu Magnus is een SAP-dienstverlener dat zich richt op de 500 grootste bedrijven van Nederland. Naast het hoofdkantoor in Naarden heeft het bedrijf ook een vestiging in Den Bosch, Rotterdam en Maleisië. De geschiedenis van Magnus begint in 1989 met de eerste grote Nederlandse SAP implementatie. Sindsdien heeft het bedrijf vele andere bedrijven voorzien van hoogwaardige SAP-services en -expertises of SAP is de naam van het bedrijf, en tevens de verzamelnaam van haar geholpen bij de optimalisatie van bestaande SAP softwareoplossingen, dat systemen. Magnus is een SAP Service Partner, dit marktleider is op het gebied van houdt in dat het bedrijf zich voornamelijk richt op ERP, CRM en SCM pakketten. strategische consultancy, implementatie, (Wikipedia, SAP AG, 2011) systeemintegratie en continue verbetering van bedrijfsprocessen bij SAP gebruikers. Lange tijd was Magnus een beursgenoteerd bedrijf met kantoren verspreid over de gehele wereld (o.a. Verenigde Staten, Frankrijk en Maleisië ) dat zich richtte op volledige SAP-systeem implementaties. Het aantal werknemers lag toen rond de 600. Tussen 2000 en 2003 belandde het bedrijf in zwaar weer, met als gevolg dat vele buitenlandse vestigingen werden gesloten. Later is Magnus ook van de beurs gehaald, het toen veel kleiner geworden bedrijf heeft echter wel weer zijn weg vervolgd. In 2010 heeft Magnus de SAP-adviesactiviteiten van Inter Access overgenomen, hierdoor zijn er 36 SAP-consultants overgaan naar de SAP-dienstverlener uit Naarden. In het eerste kwartaal van dit jaar heeft er nog een overname plaatsgevonden, branchegenoot TopForce uit Rotterdam werd overgenomen. De voormalige TopForce medewerkers blijven opereren vanuit hun voormalige vestiging in Rotterdam. Hierdoor komt het werknemersaantal van Magnus rond de 130 te liggen.
1.1.2 Missie en visie De missie van Magnus luidt als volgt: “Duurzame verbetering van organisaties door stroomlijning van bedrijfsprocessen en systemen, en van de wijze waarop mensen binnen de onderneming met elkaar, externe partners en klanten samenwerken.” Hiermee wordt bedoeld dat Magnus steeds bezig is met het aandragen en realiseren van innovaties en verbeteringen waarmee bedrijven een strategisch voordeel weten te behalen. De werkwijze en diensten van Magnus ondersteunen de visie dat (markt)kennis en mensen voor Magnus de belangrijkste sleutels tot succes vormen. 1
1
(Magnus.nl, 2011)
Jordy van der Meij
Pagina 8 van 79
Afstudeerverslag
1.1.3 Organisatiestructuur De organisatie van Magnus bestaat uit een strategische top met daaronder de ondersteunende diensten en een uitvoerende kern (“Delivery Management”). De uitvoerende kern is onderverdeeld in verschillende disciplines (intern ook wel “practices” genoemd). Iedere practice bevat een bepaald aantal medewerkers en practice manager. Deze practice manager rapporteert periodiek aan het management. De organisatievorm heeft het meeste weg van een zogenaamde lijnorganisatie. Mijn plaats in de organisatie is binnen de practice “SAP Techniek”, welke aangegeven is in het donkerblauw in Figuur 1, zie hieronder. De applicatie, wat het eindproduct van de opdracht is, zal ook bedoeld zijn voor deze practice. Het gehele organogram in figuurvorm is te vinden in Bijlage A: “Het organogram” op pagina 59.
Magnus
Marketing & Sales
Portfolio Management
Delivery Management
Finance & Office
Practice 1
SAP Techniek
Figuur 1 Het organogram vereenvoudigd
1.1.4 Contactgegevens Naam: Bezoekadres: Telefoon: Website: Naam: Bezoekadres: Telefoon: Website:
Jordy van der Meij
Magnus Technology Consultants (Naarden) Gooimeer 5-39 1411 DD Naarden +31 (0)35 699 60 60 http://www.magnus.nl Magnus Technology Consultants (Rotterdam) Hofplein 20 3032 AC Rotterdam +31(0)10 458 64 02 http://www.magnus.nl
Pagina 9 van 79
Afstudeerverslag
1.2 Aanleiding van het project Magnus voert regelmatig installaties van updates en upgrades op SAP systemen uit voor bestaande en nieuwe klanten. Momenteel is het maken van offertes voor dit soort projecten een niet-geautomatiseerde handeling. Hierdoor komt het voor dat offertes niet altijd op een eenduidige manier worden uitgebracht, iedere consultant heeft immers een eigen manier van werken. Uit onderzoek, door Magnus zelf, blijkt dat ongeveer 80% van de offerteaanvragen standaard activiteiten betreft. Dit project is, door Magnus, in het leven geroepen om het proces van offertes maken te vergemakkelijken. Op die manier kan er namelijk een hoop tijd worden bespaard. Daarbij wilt Magnus deze applicatie ook extern inzetten om op die manier de klant makkelijk en snel een inzicht te geven over de kosten van een bepaald project. Het idee daarachter is om zodoende nieuwe klanten binnen te halen.
1.2.1 Onderzoeksvraag Op basis van gesprekken over het project is er overeengekomen om de volgende onderzoeksvraag te hanteren: “Op welke innovatieve wijze kan Magnus ervoor zorgen dat er op een eenduidige en duidelijke manier een offerte kan worden uitgebracht voor de klant?”
1.2.2 Project doelstellingen De doelstelling van dit project is om op een innovatieve wijze een applicatie neer te zetten die voldoet aan het volgende: De applicatie dient intern ingezet te kunnen worden om zodoende de Sales managers en presales consultants van Magnus in staat te stellen om een nauwkeurige offerte op een eenduidige manier uit te brengen voor haar klanten. De applicatie zal ook extern gebruikt moeten worden door (toekomstige) klanten.
1.2.3 Projectscope De scope van het project is het opzetten van rekenmodellen voor een aantal projecttypen. Deze rekenmodellen vormen de basis van een offerte berekening. Het ontwikkelen van een applicatie om deze rekenmodellen is optioneel. De volgende projecttypen zullen tot de scope van het project behoren. In hoofdstuk 2 “Theoretische verdieping” op pagina 14 zal toegelicht worden wat deze projecttypen precies inhouden: Upgrade van Enhancement Packages op een SAP ERP en SAP BW omgeving Upgrade van Support Packages Stacks op een SAP ERP en SAP BW omgeving Release upgrades voor: SAP R/3, SAP BW en SAP BO Database upgrade; Oracle, MSSQL, DB2 Migratie / virtualisatie (optioneel) Voor ieder projecttype zal er een rekenmodel worden ontwikkeld, de ontwikkeling van de applicatie ligt tevens ook binnen de scope. Echter zal dit niet door mij persoonlijk gedaan worden, tenzij anders wordt overeengekomen tijdens het project.
Jordy van der Meij
Pagina 10 van 79
Afstudeerverslag
1.2.4 Randvoorwaarden en uitgangspunten Hieronder volgen de randvoorwaarden en uitgangspunten die aan het project zijn gesteld: Het project heeft een looptijd van 100 werkdagen en dient binnen deze tijd te zijn afgerond. De applicatie, en de daarbij behorende functionaliteiten, moeten in de strategie van Magnus liggen: “Keep it simple!”. De termen “simpelheid, duidelijkheid en laagdrempeligheid” moeten steeds weer terug te zien zijn in de applicatie.
1.2.5 Project ontwikkelingsmethode Dit project zal een aantal elementen bevatten van de DSDM project ontwikkelingsmethodiek. Meer informatie hieromtrent kan worden gelezen in hoofdstuk 2.3 “Project ontwikkelingsmethodiek” op pagina 20.
1.2.6 Kwaliteitswaarborging In de planning zijn evaluatie momenten opgenomen van de op te leveren producten. Veelal kennen deze een evaluatie van het concept als mede een evaluatie van het uiteindelijke product. De evaluatie zal gedaan worden door Christian Onderstal (Practicemanager SAP Techniek) en Norbert Gundlach (Managing Consultant SAP Techniek). Tevens zal er een wekelijkse meeting plaatsvinden met Norbert Gundlach voor het bespreken van de voortgang. Afhankelijk van de voortgang zal Christian Onderstal eens per maand aanwezig zijn bij deze meeting. Tevens wordt de kwaliteit gewaarborgd door de DSDM project ontwikkelingsmethodiek.
1.2.7 Risicobeheersing In de onderstaande tabel (Tabel 1 Risicobeheersing) zijn de risico’s weergegeven die voorafgaand van het project zijn ingeschat. Het risico wordt beoordeeld door een kans x impact berekening, dit gebeurd op een schaal van 1 – 10 (1 = klein, 10 = groot). De risicobeoordelingen zijn gemaakt op basis van inschatting en ervaring. Voor ieder risico zullen er ook maatregelen worden besproken.
Risico Project niet haalbaar binnen afgesproken tijd Applicatie zelf niet te realiseren
Kans 3
Impact 8
Score 24
-
4
3
12
-
-
Benodigde project informatie niet genoeg voor beschikbaar
Jordy van der Meij
2
9
18
-
Maatregelen MoSCoW op de applicatie / scope Ontwikkeling van de applicatie intern uitbesteden Schrijven van documentatie omtrent rekenmodel. (dit is meegenomen in de planning) Rekenmodel ontwikkelen op basis van livebenchmarking
Pagina 11 van 79
Afstudeerverslag
Langdurige eigen afwezigheid Langdurige afwezigheid sleutelpersonen Magnus
1
10
10
-
1
5
5
-
Verlengen van de afstudeerstage. Andere sleutelpersonen toewijzen.
Tabel 1 Risicobeheersing
Toelichting op de risico’s Project niet haalbaar binnen afgesproken tijd Tijdens het project zal de MoSCoW methodiek worden gebruikt. Dit is een onderdeel uit DSDM project methode waarmee prioriteiten worden vastgesteld aan de projecteisen. Deze methodiek wordt uitgelegd in hoofdstuk 2.3 “Project ontwikkelingsmethodiek” op pagina 20. Applicatie zelf niet te realiseren Wanneer er tot de conclusie wordt gekomen dat de applicatie niet door mijzelf kan worden gerealiseerd moet er worden gekeken naar het uitbesteden hiervan. In eerste instantie zal dit intern worden uitbesteedt. De maatregel tegen dit risico zal zijn dat er gezorgd wordt voor een goede documentatie van het rekenmodel zodat de aanbestedende partij (intern dan wel extern) op basis hiervan de applicatie kan ontwikkelen. Benodigde project informatie niet genoeg beschikbaar Het rekenmodel zal worden gebaseerd op informatie van voorgaande, afgeronde, projecten. Wanneer deze informatie niet genoeg beschikbaar is zal er het rekenmodel moeten worden gebaseerd op live benchmarking. Dit is een iteratief proces. Bij iedere benchmark zal het rekenmodel worden aangepast en opnieuw getest worden. De impact van dit risico is erg groot omdat live benchmarking ontzettend veel tijd in beslag neemt waardoor het voor kan komen dat het project niet haalbaar is binnen de afgesproken tijd. Langdurige eigen afwezigheid Alhoewel de kans klein is van dit risico, kan het voorkomen dat ik langdurig afwezig ben. In overleg met Christian Onderstal en Jan Hellings (afstudeerbegeleider) zal er dan gekeken worden naar een oplossing. Een oplossing kan zijn; het verlengen van de afstudeerstage. Langdurige afwezigheid sleutelpersonen Magnus Er zijn twee personen binnen Magnus die nauw betrokken zijn bij het project. Dit zijn Christian Onderstal en Norbert Gundlach. Wanneer één van deze personen, of beide, langdurig afwezig is tijdens het project zal er in overleg met hen andere personen worden toegewezen die hun taak binnen dit project overnemen.
Jordy van der Meij
Pagina 12 van 79
Afstudeerverslag
1.3 Vooraf gestelde competenties en leerdoelen Voorafgaand dit project heb ik een aantal competenties en leerdoelen opgesteld. Deze competenties komen voort uit de competentielijst die vooraf is ingevuld bij de aanvraag voor deze afstudeeropdracht2. De leerdoelen zijn een door mijzelf opgestelde doelen. De volgende competenties en leerdoelen zullen van toepassing zijn op deze afstudeeropdracht: Competenties - Ik voer een analyse uit van processen, producten en informatiestromen in hun onderlinge samenhang en de context van de omgeving. - Ik stel functionele specificaties op. - Ik formuleer op basis van een analyse en in overleg met stakeholders een onderbouwd advies voor herinrichting van processen en / of informatiestromen en voor een nieuw te ontwikkelen of aan te schaffen ict-systeem. - Ik ontwerp een ict-systeem op basis van een architectuurbeschrijving en specificaties, in samenhang met een analyse. - Binnen de gestelde kaders voor kwaliteit, testen, beveiliging, doorlooptijd, budget en exploitatie en beheer. Leerdoelen - Inzicht krijgen in de wereld van SAP beheer. - Een project volgens planning uitvoeren aan de hand van een projectontwikkelingmethodiek. - Omgaan met, en in juiste banen leiden van meerdere, verschillende, belangen binnen een project in het bedrijfsleven. Toelichting op de keuze van deze afstudeeropdracht. In het semester voordat ik begon aan mijn afstudeerstage, ben ik tijdens een cursus van de Hogeschool van Amsterdam in contact gekomen met SAP. SAP trok mijn aandacht en interesse vanwege de vele mogelijkheden die het biedt. Tijdens deze cursus werd SAP gebruikt vanuit het gebruikersperspectief. Het lijk mij ontzettend interessant om SAP ook vanuit een ander perspectief te leren kennen. Magnus, en deze afstudeerstage, stelt mij er toe in staat om met consultants en projecten in aanraking te komen waardoor ik SAP vanuit een ander perspectief leer kennen.
2
Zie blanco formulier “aanvraag afstudeeropdracht” op https://intra.informatica.hva.nl/content/Links/formulieren/4.%20Afstudeerfase/Aanvraag_Afstudeeropdracht.d oc
Jordy van der Meij
Pagina 13 van 79
Afstudeerverslag
2
THEORETISCHE VERDIEPING
De wereld van SAP is immens groot, ingewikkeld maar bovenal ook ontzettend interessant. Na het lezen van dit hoofdstuk zal het duidelijk zijn wat SAP is, wat het kan en wat de relatie is tot de afstudeeropdracht. Ook wordt de projectontwikkelingmethodiek nader toegelicht welke gebruikt wordt om dit project in goede banen te leiden. Dit hoofdstuk geeft een houvast om de opdracht en de rest van dit verslag goed te kunnen begrijpen. Dit hoofdstuk is onder andere geschreven op basis van bronnen die vermeld staan in het hoofdstuk “Bronnenlijst” op pagina 58.
2.1 SAP, een introductie SAP AG, spreek uit als “es aa pee”, is een Duits softwarebedrijf dat wereldwijd opereert en zich specialiseert in bedrijfssoftware oplossingen. Het bedrijf levert de softwareoplossingen aan zowel het MKB als internationale ondernemingen. Bedrijfsnaam: SAP AG Wereldwijd werken er ongeveer 53.000 Opgericht in: 1972 medewerkers, verdeeld over meer dan 75 landen Hoofdkantoor: Walldorf, Duitsland voor SAP AG. Het bedrijf staat beursgenoteerd Winst: €1,816 miljard aan de New York Stock Exchange. De letters SAP (2010) staan voor Systeme, Anwendungen und (Wikipedia, SAP AG, 2011) Produkte in der datenverarbeitung (Systemen, Applicaties en Producten in gegevensverwerking). SAP AG is momenteel marktleider op het gebied van ERP, CRM en SCM softwarepakketten. ERP Om beter te begrijpen wat voor soort softwareoplossingen SAP levert is het goed om te weten wat ERP is. ERP staat voor Enterprise Resource Planning, in de regel wordt hiermee software bedoeld die binnen organisaties wordt gebruikt ter ondersteuning van bedrijfsprocessen. ERP systemen helpen organisaties om te gaan met de verschillende stappen in de volledige toeleveringsketen (Engels: Supply Chain), zoals goederenontvangst, voorraadbeheer, klantordermanagement, productieplanning, goederenverzending, boekhouding en personeelsmanagement 3. Een ERP systeem wordt ook wel gedefinieerd als een pakket die de bedrijfsvoering over de gehele breedte ondersteund. In het verleden had iedere afdeling vaak haar eigen systemen waarmee ze werkte, voor de medewerkers werkte dit uitstekend. Echter de koppeling tussen deze systemen leidde tot veel problemen. Denk hierbij aan hoge kosten en weinig flexibiliteit in de systemen. Een ERP systeem is hiervoor de oplossing. Een ERP systeem werkt met een bedrijfsdatabase waarin alle zakelijke transacties ingevoerd, bewerkt en bewaakt worden en van waaruit rapporten kunnen worden samengesteld. De grote kracht van een ERP systeem is dat de informatie slechts eenmaal hoeft worden ingevoerd en door het hele bedrijf bruikbaar is. Dit biedt voordelen zoals de verkleining van de kans op inconsistente data , een efficiëntere manier van werken en leidt daarom zelfs tot kostenreductie. Een ERP softwarepakket is opgebouwd uit verschillende modules die ondersteuning bieden voor een bepaald proces (HR, finance of branche specifieke modules), de ingevoerde gegevens in deze modules
3
(Somers en Nelson, 2003)
Jordy van der Meij
Pagina 14 van 79
Afstudeerverslag worden onderling direct uitgewisseld en gebruikt. Voor de beeldvorming volgt er een voorbeeld waarbij SAP als ERP pakket gebruikt wordt: “Een klant belt bedrijf A op om een product te bestellen. De desbetreffende medewerker noteert de contactgegevens en de order van de klant. Hij ziet in SAP dat het product op voorraad is en wat de levertijd van het product is. De klant gaat hiermee akkoord en de medewerker voert in SAP een nieuwe order in. De order wordt door SAP verwerkt, het SAP systeem merkt op dat na het plaatsen van deze order de voorraad niet hoog genoeg is om aan de forecast te voldoen. SAP zal een inkooporder klaarzetten bij de leverancier om de voorraad op peil te houden voor de komende periode. De desbetreffende afdelingsmanager zal enkel nog zijn goedkeuring moeten geven voor deze inkooporder.” Dit is maar één voorbeeld uit duizenden om de kracht van een ERP pakket aan te tonen. Het product kan zoals eerder gezegd voor vele bedrijfsprocessen worden ingezet zoals onder andere de HR zaken, financiële administratie of voorraadbeheer. Bedrijfssoftware oplossingen SAP ERP is het belangrijkste pakket dat SAP levert, dit pakket wordt doorgaans ook SAP genoemd in plaats van SAP ERP. SAP is een geïntrigeerd informatie- en besturingssysteem waarin bedrijfsmatige processen kunnen worden vastgelegd en beheerd. Deze processen zijn ondergebracht in modules. De gegevens in de modules worden onderling direct uitgewisseld, waardoor er een volledig geïntegreerd systeem ontstaat. SAP ERP ondersteunt alle essentiële bedrijfsprocessen en activiteiten van een onderneming. Het pakket is volledig toegespitst op algemene en branchespecifieke behoeften. Desondanks dat is het ook mogelijk om het SAP systeem aan te passen aan het bedrijfsproces of om extra functionaliteit zelf te ontwerpen en toe te voegen aan het systeem. Dit betekent wel dat er veel maatwerk bij komt kijken. Afhankelijk van de grootte van de organisatie kiezen bedrijven er soms voor om hun bedrijfsproces aan SAP aan te passen in plaats SAP aan het bedrijfsproces. Naast SAP ERP levert SAP nog talloze andere bedrijfssoftware oplossingen. In dit verslag beperken we ons enkel tot de bedrijfssoftware oplossingen die in de projectscope4 zijn opgenomen. SAP Business Warehouse SAP Business Warehouse is de naam van de Business Intelligence, analytische, verslaglegging en Data Warehouse oplossing van SAP. Deze oplossing zorgt ervoor dat de opslag van data in verschillende structuren wordt opgeslagen (dit gebeurt in een zogenaamd “Data Warehouse”). Vervolgens kunnen er rapportages en andere analytische gegevens op een gebruiksvriendelijke manier worden gegenereerd.
4
Data Warehouse Een Data Warehouse is een opslagruimte voor een grote hoeveelheid gegevens. Het onderscheidt zich van een normale database door de manier van dataopslag. Dit wordt zodanig gedaan dat gegevensverwerking vanuit een Data Warehouse efficiënt en snel kan gebeuren.
Zie hoofdstuk “Projectscope” op pagina 10.
Jordy van der Meij
Pagina 15 van 79
Afstudeerverslag SAP Business Objects Het belangrijkste onderdeel van SAP Business Objects is de mogelijkheid tot data visualisatie. Met SAP Business Objects is het mogelijk om dashboards te creëren met daarin een dynamische weergave van grafieken en tabellen waar data in staat. Vervolgens is het mogelijk om deze visualisaties weer te geven op een online portal, intranet of zelfs een mobiele telefoon.
Figuur 2 Een voorbeeld van een SAP Business Objects dashboard.
2.2 De upgradetechniek van SAP systemen In dit hoofdstuk wordt een beeld geschetst dat in grote lijnen de upgradetechniek van een SAP systeem weergeeft welke voldoende is om de afstudeeropdracht te begrijpen. Technisch gezien ziet een SAP systeem er veel complexer uit dan wordt beschreven in dit hoofdstuk. Echter is dat niet van belang om te weten om dit verslag, en tevens de opdracht, goed te begrijpen. Om die reden is dit niet opgenomen in dit verslag. Om een goed en duidelijk beeld te krijgen van de upgradetechniek achter een SAP systeem is het makkelijk om een vergelijking te maken tussen een SAP systeem en een besturingsysteem zoals bijvoorbeeld Microsoft Windows. De reden waarom dit gemakkelijk is , is omdat men over het algemeen de werking en opbouw van Microsoft Windows wel kent en dat van een SAP systeem niet. Let wel; de vergelijking die hieronder wordt gebruikt komt niet overeen met de werkelijkheid maar geeft wel een goed beeld van de techniek en werking van SAP systemen. Zoals in het vorige hoofdstuk ter sprake is gekomen levert SAP AG meerdere bedrijfssoftware oplossingen. In het vervolg zullen dit “systemen” worden genoemd. De meest gebruikte systemen, en welke ook onder de projectscope vallen, zijn: SAP ERP SAP Business Warehouse SAP Business Objects Laten we nu zeggen dat ieder SAP systeem een Microsoft Windows versie is. In dit voorbeeld zal SAP ERP worden gebruikt dat hetzelfde is als Microsoft Windows XP. Voor Windows XP komen er iedere week updates uit welke problemen in het besturingssysteem verhelpen en welke het besturingssysteem verbeteren. Laten we zeggen dat dit de reguliere Windows Updates zijn. Daarnaast bundelt Microsoft eens in de zoveel tijd al deze reguliere updates in een grote update. Dit wordt door Microsoft een “Service Pack” genoemd. Een Service Pack bevat naast de reguliere updates voor het besturingssysteem ook een aantal kleine nieuwe functionaliteiten. Deze functionaliteiten zijn niet te installeren op het besturingssysteem zonder het Service Pack te moeten installeren. Wanneer er een Service Pack is geïnstalleerd op het besturingssysteem zal deze ook worden verbeterd middels reguliere Windows updates. Dit zijn dan weer Service Pack specifieke updates. Windows XP is qua functionaliteit uit te breiden met bijvoorbeeld Windows Live Essentials. Bij de installatie van dit pakket kan er gekozen Jordy van der Meij
Pagina 16 van 79
Afstudeerverslag worden om bepaalde functionaliteiten los van elkaar te installeren, bijvoorbeeld Windows Messenger, Windows Movie Maker of Windows Photo Gallery. Na een paar jaar komt Windows Vista, de opvolger van Windows XP, uit. Dit betreft een nieuwe release van het besturingssysteem. Deze nieuwe releases bevatten voornamelijk veel grote veranderingen qua functionaliteit en de werking “onder de motorkap”. In het kort kunnen we dus stellen dat: Windows XP is een besturingssysteem, dit wordt ook wel een “release” genoemd. Reguliere Windows updates zijn kleine verbeteringen op het besturingssysteem. Service Packs bevatten naast veel reguliere Windows updates, ook extra kleine functionaliteiten die aan het besturingssysteem worden toegevoegd. Op een Service Pack kunnen ook reguliere Windows Updates worden geïnstalleerd. Met Windows Live Essentials wordt de functionaliteit van Windows XP uitgebreid. Met deze vergelijking in het achterhoofd gaan we weer terug naar de upgradetechniek van een SAP systeem. SAP ERP zal hier als voorbeeld worden genomen. Op een SAP ERP systeem kunnen ook diverse updates uitgevoerd worden, in SAP termen worden dit upgrades genoemd. Dit zijn Enhancement Pack upgrades, Support Package Stack upgrades en Release upgrades (deze upgradetypes vallen tevens onder de projectscope5). In dit onderdeel zal ook SAP OSS Notes aan bod komen. Dit upgradetype valt echter niet onder de projectscope maar om de upgradetechniek van SAP systemen goed te begrijpen is het wel belangrijk dat deze vermeld wordt. Om te begrijpen wat deze upgrades inhouden volgt er een vergelijkingstabel met daaronder een bijbehorende uitleg. SAP termen
Microsoft Windows termen
SAP ERP SAP OSS Note
is gelijk aan is gelijk aan
Support Package Stack upgrade Enhancement Pack upgrade Release upgrade
is gelijk aan is gelijk aan is gelijk aan
Windows XP Reguliere Windows updates installeren Naar een hogere Windows Service Pack upgraden Windows Live Essentials installatie Naar nieuwere Windows versie upgraden. Tabel 2 SAP in vergelijking tot Windows
SAP OSS Note SAP OSS Notes zijn updates op het SAP systeem die fouten (bugs) in het desbetreffende SAP systeem oplossen. Support Package Stacks Een Support Package Stack upgrade voert wijzigingen toe op het desbetreffende SAP systeem. Voorbeelden hiervan zijn bijvoorbeeld een veranderde wet / regelgeving omtrent BTW of andere financiële en juridische aspecten. Tevens bevat een Support Package Stack een aantal bug fixes (SAP OSS Notes). Ieder
5
Zie Hoofdstuk 1.2.3 “Projectscope” op pagina 10
Jordy van der Meij
Pagina 17 van 79
Afstudeerverslag Support Package Stack dat beschikbaar wordt gesteld door SAP heeft een eigen versie nummer. Enhancement Packs Een Enhancement Pack zorgt voor nieuwe en verbeterde functionaliteit aan het desbetreffende SAP systeem. Deze functionaliteiten kunnen modulair geselecteerd worden tijdens een Enhancement Pack upgrade traject. De keuze van de geselecteerde functionaliteiten gebeurt op basis van business specifieke doeleinde. Ieder Enhancement Pack dat beschikbaar wordt gesteld door SAP heeft een eigen versie nummer. Release upgrade Een SAP Release upgrade is het meest omvangrijke type upgrade van de drie. Zoals eerder is geschreven kun je dit vergelijken met een upgrade naar een nieuwere Windows versie. Een Release upgrade zorgt niet enkel voor extra functionaliteit aan het SAP systeem maar ook zitten hier nieuwe “state of the art” technologieën in waar vanuit de business vraag naar is om op die manier de productiviteit van het systeem te vergroten. Iedere Release upgrade dat beschikbaar wordt gesteld door SAP heeft een eigen versie nummer.
Figuur 3 Figuurlijke weergave van de diverse upgrade soorten
In de praktijk Nu het duidelijk is hoe de upgradetechniek van een SAP systeem in elkaar zit zullen we kijken hoe dit nu eigenlijk in de praktijk werkt. Wanneer men praat over een SAP landschap van een bedrijf bedoeld men daarmee alle SAP systemen die een bedrijf heeft draaien, dit kunnen dus bijvoorbeeld een SAP ERP en SAP Business Warehouse systeem zijn. Om aan te geven hoe een upgrade traject in zijn werk gaat pakken we in dit onderdeel één systeem van een SAP landschap als voorbeeld, dit is de SAP ERP omgeving. Voor de overige systemen geldt min of meer hetzelfde upgradetraject. SAP ERP wordt geïnstalleerd op een besturingssysteem (Windows Server of een Linux distributie) en maakt daarnaast ook gebruik van een database (MS SQL of Oracle). Over het algemeen heeft een bedrijf drie SAP ERP systemen afzonderlijk van elkaar draaien, welke we de volgende namen geven met tussen haakjes de afkortingen die in het vervolg worden gebruikt: Ontwikkeling systeem (DEV) Kwaliteit en acceptatie systeem (QAS) Productie systeem (PRD)
Jordy van der Meij
Pagina 18 van 79
Afstudeerverslag Ontwikkeling systeem (DEV) Dit systeem wordt gebruikt als ontwikkeling en test systeem. Vandaar de afkorting DEV dat afgeleid is van Development. Bij een upgradetraject zal dit systeem als eerst geüpgrade worden. Dit systeem bevat geen enkele data van het Productie systeem. Kwaliteit en acceptatie systeem (QAS) Dit systeem wordt gebruikt als acceptatie systeem. Periodiek wordt de database van het productie systeem gekopieerd naar dit systeem. Op die manier kan wordt het Productie systeem nagebootst. Tijdens een upgradetraject zal dit systeem na het upgraden van het DEV systeem geüpgrade worden. Productie systeem (PRD) Op dit systeem zitten de SAP gebruikers aangesloten en hierin wordt ook daadwerkelijk gewerkt. Denk hierbij bijvoorbeeld aan het aanmaken van orders en dergelijke. Dit systeem wordt als laatste geüpgrade. Wanneer er een upgrade wordt uitgevoerd op een SAP ERP systeem zal dit op ieder van de bovenstaande systemen worden uitgevoerd. Dit heeft te maken met het feit dat er na iedere upgrade bepaalde problemen opspelen. De problemen spelen op omdat bedrijven vaak in hun SAP systeem maatwerk hebben zitten. Dit zijn zelf ontworpen functionaliteiten. Het systeem, en haar functionaliteiten, zullen pas goed werken wanneer deze problemen zijn opgelost. Wanneer de upgrade eerst wordt uitgevoerd op het DEV systeem heeft men alle tijd om de problemen op te lossen die na een upgrade zijn komen opspelen. De SAP eindgebruiker kan namelijk gewoon nog in het PRD systeem werken, dit systeem wordt tijdens het upgraden van het DEV systeem niet aangetast. Wanneer een probleem is opgelost wordt er gedocumenteerd hoe deze is opgelost. Na iedere upgrade geldt er een bepaalde downtime van het systeem, in deze tijd is het niet mogelijk om in het desbetreffende systeem te werken. Wanneer het DEV systeem geüpgrade is en alle bijkomende problemen zijn opgelost kan er begonnen worden aan het upgraden van het QAS systeem. Dit systeem bevat een kopie van de database van het PRD systeem. Op die manier wordt het productie systeem nagebootst. Wanneer dit systeem wordt geüpgrade zullen dezelfde problemen opspelen als die ook opspeelde bij het upgraden van het DEV systeem. Echter kan men deze snel oplossen omdat men de oplossing al weet, omdat deze ook op het DEV systeem zijn doorgevoerd. Er kunnen ook nieuwe problemen gaan opspelen omdat er gebruik gemaakt wordt van een andere database (die van het PRD systeem). Dit is dan ook de belangrijkste functie van het QAS systeem; het oplossen van de problemen die op het PRD zouden kunnen gaan ontstaan. Wanneer de problemen, en de daar bijbehorende oplossingen, bekend en doorgevoerd zijn zullen deze wederom worden gedocumenteerd. Hierna kan er begonnen worden aan het upgraden van het productie systeem. Het upgraden van het productiesysteem is het meest spannende van een upgradetraject. Op dit systeem mag namelijk zo weinig mogelijk downtime zijn. Wanneer het productie systeem niet beschikbaar is kan er niet in gewerkt worden met als gevolg dat dit een bedrijf ontzettend veel geld kan kosten. Het productie systeem wordt dan ook geüpgrade wanneer hier het minst op gewerkt wordt, meestal is dat in het weekend. Omdat de upgrade ook al is gedaan op het QAS systeem weet men dus welke problemen er op kunnen spelen bij het upgraden van het PRD systeem. Omdat deze problemen, inclusief oplossingen, toentertijd zijn gedocumenteerd kan men deze vaak snel verhelpen. Zo wordt de downtime van het productie systeem tot een minimum beperkt. Jordy van der Meij
Pagina 19 van 79
Afstudeerverslag
2.3 Project ontwikkelingsmethodiek Om een project in goede banen te leiden is het aan te raden om een project ontwikkelingsmethodiek te gebruiken. De omvang , aantal projectleden / gebruikersgroep en de looptijd van het project zijn hierbij belangrijke factoren om te bepalen voor welke project ontwikkelingsmethodiek het best bij het project past. Wanneer er een keuze is gemaakt betekent dit niet dat de methodiek één op één gevolgd moet worden. Project ontwikkelingsmethodieken zijn namelijk een greep “best practices” waarbij men niet wordt verplicht alles te hanteren. Het is per project afhankelijk welke onderdelen er uit een project ontwikkelingsmethodiek worden gehanteerd. Bij de keuze van de project ontwikkelingsmethode voor dit project, is er uitgegaan van de onderstaande randvoorwaarden en uitgangspunten: Het project heeft een looptijd van 100 dagen, binnen deze termijn moet het project zijn afgerond. Er is een duidelijke gebruikersgroep en projectgroep. De applicatie die binnen het project wordt ontworpen is een interactief systeem. Aan de hand van de bovenstaande uitgangspunten is er gekozen om facetten van de DSDM project ontwikkelingsmethode te hanteren. Ook heb ik met deze methodiek meer ervaring dan met methodieken zoals SCRUM of Prince2. De ervaringen die ik heb met DSDM zijn dusdanig positief en tevens denk ik dat deze methodiek zich het best leent voor dit soort projecten. DSDM DSDM staat voor Dynamic Systems Development Method en wordt voornamelijk gebruikt voor ontwikkeling van gecomputeriseerde informatiesystemen. DSDM kenmerkt zich door het feit dat een project een vaste looptijd heeft waarbij de functionaliteit van het product variabel is. Wanneer een project dreigt uit te lopen wordt de functionaliteit ervan aangepast om zodoende het project afgerond te krijgen binnen de gestelde looptijd. Verder hanteert DSDM de volgende 9 basisprincipes: Actieve deelname van gebruikers is essentieel; Design groepen zijn bevoegd om beslissingen te nemen op het vlak van systeem ontwikkeling; Vaak en regelmatig opleveren van componenten is een prioriteit; Het belangrijkste acceptatiecriterium voor een systeem of component is zijn geschiktheid voor business doelen; De businessoplossing is het doel, en iteratieve en incrementele ontwikkeling is noodzakelijk om tot die oplossing te komen; Alle veranderingen die worden gemaakt tijdens ontwikkeling, kunnen worden teruggedraaid; Initiële eisen zijn erg algemeen opgesteld; Testen is niet een aparte fase, het gebeurt gedurende het hele traject; Het is essentieel dat er samenwerking is tussen alle project participanten. DSDM gaat uit van een actieve deelname van de gebruikers. Onder deze groep vallen de projectleden en de gebruikers vanuit de klant. Samen vormen zij het projectteam die de verschillende fasen van DSDM doorlopen. Over het algemeen wordt iedere fase ingevuld door een aantal workshops waarbij het gehele projectteam aanwezig is. Jordy van der Meij
Pagina 20 van 79
Afstudeerverslag Fase 1: “Feasibility study” In deze fase wordt er gekeken naar de haalbaarheid en geschiktheid van het project voor het bedrijf. Dit wordt bepaald aan de hand van de gekozen technische realisatie en de kosten en duur van het project. Fase 2: “Business study” In deze fase worden algemene primaire functies van het systeem bepaald. Deze fase wordt over het algemeen samengevoegd met de “Feasibility study”. Fase 3: “Functional model iteration” Deze fase wordt gebruikt om informatie te Figuur 4 Figuurlijke weergave DSDM fasen achterhalen en aan de hand van prototyping worden de gebruikerseisen bepaald. Deze fase is iteratief en kan zo vaak worden herhaald als nodig. Fase 4: “Design and Build iteration” Wanneer de Functional Model Iteration fase voorbij is kan er aan de Design and Build Iteration worden begonnen. Hierin wordt het prototype verder uitgewerkt. Het doel van deze fase om een prototype op te leveren die voldoet aan de gestelde eisen die zijn opgesteld in de Functional Model Iteration. Ook deze fase is iteratief. Fase 5: “Implementation” In deze fase wordt het systeem opgeleverd aan de eindgebruikers. Uit de Functional Model Iteration en Design and Build Iteration fasen komen veel gebruikerseisen en functionaliteiten naar voren. Wanneer elke eis even belangrijk is, en dus opgenomen moet worden in de applicatie, is de kans erg groot dat het project over de gestelde looptijd heen gaat. Om dit tegen te gaan wordt er aan iedere eis, door de projectgroep, een prioriteit toegekend volgens het MoSCoW principe. Iedere hoofdletter staat voor een bepaalde prioriteit: Must have De letter “M” staat voor “Must have”. De eis / functionaliteit die deze prioriteit krijgt zal ten allen tijden worden opgenomen in de applicatie. De voorwaarde die er voor staat om deze prioriteit te krijgen is: Deze functionaliteit moet gerealiseerd worden omdat deze applicatie kritisch is. Wanneer deze eis niet wordt gerealiseerd komt de werking / succes van de applicatie in gevaar. Should have De letter “S” staat voor “Should have”. Deze eis / functionaliteit zou moeten worden gerealiseerd om de werking / succes te garanderen. Dit is een applicatie kritische eis / functionaliteit welke echter ook kan worden opgelost middels een “work-around”. Could have De letter “C” staat voor “Could have”. Deze eis / functionaliteit is niet applicatie
Jordy van der Meij
Pagina 21 van 79
Afstudeerverslag kritisch en zal pas worden gerealiseerd wanneer de “M” en “S” functionaliteiten zijn gerealiseerd. Won’t have De letter “W” staat voor “Won’t have”. Deze eis / functionaliteit is niet applicatie kritisch en zal waarschijnlijk niet worden gerealiseerd binnen dit project. Deze eisen / functionaliteiten kunnen eventueel mee genomen worden in vervolgprojecten. Tijdens het realiseren van de applicatie zullen de eisen en functionaliteiten worden gerealiseerd volgens dit principe waarbij eerst de “M” eisen worden gerealiseerd en daarna de “S” en “C” eisen. Meer informatie omtrent de onderdelen binnen DSDM kan gevonden worden in het DSDM handboek6.
2.4 Relatie tot de opdracht Zoals bij ieder softwarepakket komen er regelmatig upgrades, of geheel nieuwe versies, uit om het pakket te voorzien van verbeteringen, dit is bij SAP niet anders. Zoals in hoofdstuk 2.2 “De upgradetechniek van SAP systemen” op pagina 16 geschreven staat, bestaan er verschillende soorten upgrades aan SAP systemen. De applicatie zal de mogelijkheid bieden om voor de onderstaande upgradetrajecten (welke gelijk staan aan de projectscope)een offerte uit te brengen: Upgrade van Enhancement Packages op een SAP ERP en SAP BW omgeving Upgrade van Support Packages Stacks op een SAP ERP en SAP BW omgeving Release upgrades voor: SAP R/3, SAP BW en SAP BO Database upgrade; Oracle, MSSQL, DB2 Migratie / virtualisatie (optioneel) De projectgroep, ook wel design groep genoemd, bestaat zowel uit de ontwikkelaars van het systeem als de gebruikers ervan. De projectgroep zal bestaan uit: Christian Onderstal (Practicemanager SAP Techniek van Magnus) Norbert Gundlach (Senior Managing Consultant SAP Techniek van Magnus) Jordy van der Meij (Projectontwikkelaar) De eerste en, gedeeltelijk de tweede DSDM fases (Feasibility study en Business study) zullen in dit project niet worden uitgevoerd omdat deze al door Magnus zelf zijn uitgevoerd. In de eerste gesprekken tussen mij en Magnus omtrent het aangaan van de afstudeeropdracht is dit ook ter sprake gekomen. Omdat dit een intern project betreft hoeft er in eerste instantie niet gekeken worden naar de (ontwikkelings)kosten. Wel dienen alle licenties in orde te zijn wanneer het blijkt dat er licenties nodig zijn. De overige DSDM fases zullen volgens een workshopachtige wijze worden ingevuld. Dit gebeurt zal voornamelijk met Norbert Gundlach gebeuren. Wanneer er grote, of belangrijke beslissingen moeten worden genomen zal Christian Onderstal hierbij ook aanwezig zijn.
6
http://intra.iam.hva.nl/content/0708/propedeuse/ontwikkelmethoden_en_technieken//intro-enmateriaal/DSDM.pdf
Jordy van der Meij
Pagina 22 van 79
Afstudeerverslag
3
ANALYSE HUIDIG PROCES
In dit hoofdstuk wordt het huidige proces van offertes uitbrengen geanalyseerd. Deze analyse komt voort uit de DSDM fase “Business study”. Allereerst zal het proces in kaart worden gebracht. Uit deze analyse komen een aantal knelpunten naar voren. Het uiteindelijke product van dit project zal onder andere deze knelpunten (gedeeltelijk) oplossen.
3.1 Beschrijving huidig proces Het huidige proces van het uitbrengen van een offerte is redelijk simpel, echter zijn dit wel enkel menselijke handelingen. Menselijke handelingen kosten over het algemeen veel tijd, en daarom ook geld, en daarbij zijn de kansen op fouten groter dan wanneer deze handelingen zijn geautomatiseerd. De behoefte van een upgrade, ongeacht welk systeem of type upgrade, kan vanuit de business of vanuit het ICT perspectief komen. Behoefte vanuit het business perspectief Wanneer een behoefte is vanuit de business heeft dit vaak te maken met het feit dat de klant een extra functionaliteit wilt toevoegen aan zijn systeem of dat men een bepaalde functie beter wil laten functioneren. Dit komt over het algemeen voort uit problemen die de klant ervaart. De extra functionaliteiten die worden toegevoegd middels een upgrade kunnen deze problemen verhelpen en zodoende het systeem beter laten functioneren. Voor sommige upgrades is het zelfs noodzakelijk dat deze periodiek worden uitgevoerd. Denk hierbij bijvoorbeeld aan het upgraden van het financiële component binnen SAP, ieder jaar worden er bepaalde belastingregels aangepast. Dit zal dan ook binnen dit component moeten worden aangepast. Dit gebeurt ook middels een upgrade traject. Advies vanuit het ICT perspectief Upgrades kunnen ook worden uitgevoerd vanuit het ICT perspectief. Wanneer een consultant bij een klant aan het werk is, kan het zijn dat hij of zij problemen ziet waar de klant niet direct last van heeft. Een voorbeeld hiervan is het uitfaseren van de ondersteuning van een bepaald softwareniveau. Een klant kan al jarenlang zonder problemen werken op een bepaald softwareniveau, echter kan de leverancier (SAP in deze) ervoor kiezen om de ondersteuning van dit niveau te stoppen. Vanuit de ICT wordt er dan geadviseerd om een upgrade uit te voeren. Dit is vooral met het oog op de toekomst, wanneer de klant namelijk wel problemen gaat krijgen zijn deze lastiger, zo niet helemaal niet, op te lossen. De klant wordt dan alsnog gedwongen om een upgrade uit te voeren. Dit zal op hele korte termijn moeten gebeuren met alle gevolgen van dien. De klant wordt op deze manier op (voor hem) onvoorziene kosten worden gejaagd. Dit is nog niet het grootste probleem. Bij upgrade trajecten zullen er bepaalde systemen ook tijdelijk onbruikbaar zijn, dit kan de klant erg duur komen te staan wanneer dit belangrijke en / of veelgebruikte systemen zijn. Voor beide behoeftes wordt binnen Magnus hetzelfde proces doorlopen om uiteindelijk tot een offerte te komen. Het proces is weergegeven in de BPMN flowchart (zie Figuur 5 op pagina 24). Tevens zal iedere processtap nader worden toegelicht.
Jordy van der Meij
Pagina 23 van 79
Afstudeerverslag
Figuur 5 BPMN flowchart van het huidig proces
Aan de bovenkant staat de naam van het proces, in dit geval “Offerte aanvraag”. Aan de linkerkant staan de zogenaamde “swimlanes” welke staan voor de verantwoordelijke afdelingen / rollen die zijn betrokken bij dit proces. De rollen in dit proces zijn de klant en Magnus, waar Magnus onderverdeeld is in twee afdelingen; Sales en SAP Techniek. Aanvraag offerte Deze taak wordt vervuld door de klant, welke over het algemeen een IT manager is. De desbetreffende klant dient een aanvraag voor een offerte over het algemeen per e-mail of per telefonisch contact in bij Magnus. De offerte aanvraag kan middels twee manieren gedaan worden. Als de klant een contactpersoon van Magnus heeft die binnen de afdeling SAP Techniek werkzaam is, kan hij de offerte aanvraag bij deze persoon neerleggen. De activiteit “offerte aanvraag opnemen” en “Toewijzen consultant” worden in dat geval overgeslagen. Wanneer de klant dit niet heeft kan de aanvraag neergelegd worden bij de Sales afdeling van Magnus. Offerte aanvraag opnemen De afdeling Sales neemt de offerte aanvraag in behandeling en wordt vervolgens naar de Practice Manager van SAP Techniek gestuurd. Toewijzen consultant De Practice Manager van SAP Techniek wijst een consultant aan die de offerte verder behandeld. Opstellen specificaties De consultant die de offerte aanvraag behandeld gaat nu de specificaties opstellen. Dit doet hij, of zij, aan de hand van het noteren van de huidige situatie en de gewenste situatie. De uitvoer van deze activiteit zijn de beoogde softwareniveaus die de klant zal hebben na het uitvoeren van de upgrade en welke handelingen er hierbij komen kijken. Hieronder valt ook een risicoanalyse. Jordy van der Meij
Pagina 24 van 79
Afstudeerverslag Opstellen ureninschatting Wanneer de specificaties bekend zijn kan er een ureninschatting worden gemaakt door de consultant. Dit gebeurt op basis van ervaringen waarbij er rekening wordt gehouden met klantspecifieke omstandigheden. Goedkeuring door Practicemanager Iedere ureninschatting die gemaakt wordt, wordt gecontroleerd door de Practicemanager. Wanneer de Practicemanager geen goedkeuring geeft gaat de ureninschatting weer terug naar de consultant die de ureninschatting heeft gemaakt. De consultant zal aan de hand van de feedback de ureninschatting moeten aanpassen waarna deze weer gecontroleerd wordt door de Practicemanager. Dit proces wordt herhaald totdat de Practicemanager de ureninschatting heeft goedgekeurd. Opstellen offerte De (goedgekeurde) ureninschatting wordt gegeven aan een persoon binnen de afdeling “Sales”. Deze persoon schrijft op basis van de eerdere genoteerde specificaties en ureninschatting een offerte. Ook bepaald deze afdeling of dit een offerte is op “time / material” of op “fixed price” basis. Daarnaast worden ook de randvoorwaarden toegevoegd die bij de offerte horen. Al deze onderdelen vormen samen het offerte document. De offertes worden soms opgeslagen op het intranet en soms op een lokale plek van een medewerker. Uitbrengen offerte Nu de offerte opgesteld is wordt deze naar de klant uitgebracht per e-mail of per post. Ontvangen offerte Hier ontvangt de klant de offerte en daarbij is het proces “Offerte aanvraag” afgerond. De offerte heeft een bepaalde geldigheid. Wanneer de klant de offerte accepteert zal dit dus binnen de gestelde tijd moeten gebeuren. Het offerte proces, van begin tot eind, neemt ongeveer twee tot drie weken in beslag. Dit heeft niet zozeer te maken met het feit dat de handelingen die dit proces bevat veel tijd vergen, maar meer met het feit dat dit soort projecten vanuit de klant gezien niet per direct uitgevoerd hoeven te worden.
Jordy van der Meij
Pagina 25 van 79
Afstudeerverslag
3.2 Verbeterpunten In deze paragraaf leg ik de knelpunten bloot die ik heb vastgesteld na het analyseren van het huidige proces. Een onderdeel van het analyseren was het in gesprek gaan met de betrokkenen van het proces. Meer handelingen automatiseren Het huidige proces bestaat enkel uit menselijke handelingen. Dit brengt met zich mee dat de kans op fouten erg groot is. Als men bijvoorbeeld een bepaalde projecthandeling vergeet in het proces heeft dit een grote invloed. De ureninschatting zal daarna namelijk niet correct zijn waarna de gehele offerte niet correct is. Om dit te voorkomen is aan te raden om zoveel mogelijk handelingen binnen dit proces te automatiseren. De kans op fouten binnen een geautomatiseerd proces, of geautomatiseerde handeling, is namelijk veel kleiner dan bij een niet geautomatiseerd proces. Verkorten van de doorlooptijd De offertes worden gemiddeld twee tot drie weken na aanvraag geleverd. Alhoewel in de vorige paragraaf vermeld stond dat dit niet een heel groot probleem is zie ik hier toch een verbeterpunt in. In mijn ogen is het veel prettiger om een offerte zo snel mogelijk te ontvangen dan dat je hier een aantal weken op moet wachten. De klant voelt zich dan over het algemeen serieuzer genomen en tevens geeft dit een goede eerste indruk naar de klant toe. Ook voor Magnus is het prettig om de offerte zo snel mogelijk uit te brengen. Zo blijft er geen werk op de plank liggen en zullen de klanten sneller beslissen of men de offerte accepteert of niet. Uniformeren Uit onderzoek van Magnus zelf blijkt dat ongeveer 80% van de offerte aanvragen standaard activiteiten7 zijn. Op dit moment wordt hier nog niets mee gedaan en wordt iedere offerte stap voor stap handmatig opgesteld. Dit neemt veel tijd in beslag voor de betreffende consultant die de offerteaanvraag in behandeling heeft. Meer uniformiteit in het uitbrengen van offertes zal een groot voordeel zijn voor Magnus, hierdoor zal er veel tijd worden bespaard. Tevens zal hiermee de kans worden verkleind dat er verschillen zitten in offertes (bijvoorbeeld de ureninschatting) als deze door verschillende consultants worden gemaakt. Offertes centraal opslaan Wanneer alle offertes centraal worden opgeslagen kunnen hierover bepaalde rapportages worden gedraaid. Men kan makkelijk inzien wat de aanvraagfrequentie is van een bepaald type offerte. Op die manier kunnen er bijvoorbeeld trends worden herkend. De uiteindelijke applicatie zal een aantal van deze punten gaan doorvoeren zodat het gehele proces wordt verbeterd.
7
Zie hoofdstuk 1.2.3 “Projectscope” op pagina 10
Jordy van der Meij
Pagina 26 van 79
Afstudeerverslag
4
DE REKENMODELLEN; VAN GETALLEN NAAR GERAAMTE
Nu bekend is hoe het huidige proces in elkaar steekt kan er gekeken worden naar de gewenste situatie. Er zal voor ieder project type uit de scope8 een rekenmodel ontwikkeld moeten worden. De rekenmodellen vormen de basis van de applicatie, dit is het belangrijkste onderdeel. Deze rekenmodellen zullen op basis van invoer parameters, een uitvoer genereren. De uitvoer betreft een inschatting van het aantal besteedde uren die voor het gehele project staan. In paragraaf 3.1, “Beschrijving huidig proces” op pagina 23, zijn deze stappen als menselijke handelingen weergegeven. De rekenmodellen zullen de volgende menselijke handelingen vervangen: Bepalen projecthandelingen Opstellen ureninschatting Voor ieder type project zal er een apart rekenmodel worden ontwikkeld, dit heeft te maken met het feit dat de projecthandelingen binnen een project nooit hetzelfde zijn in de verschillende project types. Een SAP ERP Support Package Stack upgrade bevat bijvoorbeeld andere projecthandelingen dan een SAP ERP Enhancement Pack upgrade. Echter zijn de handelingen voor een SAP ERP Support Package Stack upgrade wel altijd hetzelfde voor ieder project. Er zullen in deze fase dus acht rekenmodellen worden ontwikkeld. De uitvoer die de rekenmodellen moeten genereren zijn voor allemaal hetzelfde. Dit is een inschatting van het aantal besteedde uren voor het project. Met dit als uitgangspunt is het ontwikkeltraject van een rekenmodel in een aantal fases verdeeld:
Verzamelfase
Uniformeerfase
Ontwikkelfase
Testfase
Verbeterfase
Figuur 6 De verschillende fases van de ontwikkeling van een rekenmodel
Verzamelfase Om een rekenmodel te kunnen ontwikkelen is het van wezenlijk belang dat er bruikbare informatie voor handen is. De rekenmodellen in dit project worden immers voornamelijk gebaseerd op deze informatie. De informatie die op dit moment bruikbaar is, is informatie die betrekking heeft tot afgeronde projecten. Het uitgangspunt van het rekenmodel is dat deze het aantal verwachtte besteedde uren moet kunnen genereren. Er wordt in deze fase dus gericht gezocht naar informatie die betrekking heeft tot de: Planning / ureninschatting van het project. De daadwerkelijk gefactureerde uren op het project. 8
Zie hoofdstuk 1.2.3 “Projectscope” op pagina 10
Jordy van der Meij
Pagina 27 van 79
Afstudeerverslag Uniformeerfase Wanneer de projectinformatie verzameld is wordt er gekeken naar de diverse werkzaamheden die tijdens de projecten worden uitgevoerd. De uitkomst van deze fase is om een uniforme werkwijze neer te zetten en daaraan de besteedde uren toe te kennen. Omdat de uren onder dezelfde handelingen worden geschreven kunnen de projecten makkelijk met elkaar worden vergeleken. Ontwikkelfase In deze fase gaat het rekenmodel ontwikkeld worden, dit zal gebeuren in Microsoft Excel. Dit programma leent zich er uitstekend voor om berekeningen te maken en indien nodig, snel aan te passen. Als er aan deze fase wordt begonnen is het duidelijk hoeveel uur er in een project heeft gezeten en zijn deze gespecificeerd op de verschillende werkzaamheden die binnen een project vallen. Test en verbeterfase In deze fase wordt het rekenmodel getest aan de hand van een aantal casussen. De verschillende casussen worden gestuurd naar een aantal consultants van Magnus. Zij zullen een ureninschatting maken van iedere casus. De casussen worden ook ingevoerd in het rekenmodel. Hierna worden de resultaten tussen de uitkomst van het rekenmodel en die van de consultants vergeleken en geëvalueerd. Eventueel wordt het rekenmodel aangepast. Deze fase is iteratief om het rekenmodel zo nauwkeurig mogelijk te laten werken. Deze vier fases worden voor de ontwikkeling van ieder rekenmodel doorlopen. In de risicoanalyse9 die vooraf opgesteld is wordt er rekening gehouden met het feit dat er niet voldoende bruikbare informatie is om het rekenmodel op te baseren. In dat geval zal het iteratieve “test en verbeterfase” vaker worden doorlopen dan wanneer er wel voldoende bruikbare informatie voorhanden is. Wanneer er drie, of meer, projecten zijn waarbij de inschatting van de uren en de daadwerkelijk gefactureerde uren aanwezig zijn kan er gesproken worden over “voldoende bruikbare informatie”. Dit neemt echter niet weg dat er minder getest moet worden in de laatste fase. Hoe meer er getest kan worden, hoe nauwkeuriger het rekenmodel uiteindelijk zal zijn. In de volgende paragraaf zal de ontwikkeling van een aantal projectsoorten behandeld en beschreven worden. De overige projectsoorten die niet worden besproken zullen volgens exact dezelfde wijze worden ontwikkeld en zijn daarom niet in het verslag opgenomen.
9
Zie hoofdstuk 1.2.7 “Risicobeheersing” op pagina 11
Jordy van der Meij
Pagina 28 van 79
Afstudeerverslag
4.1 De ontwikkeling van de SAP ERP upgrade rekenmodellen In deze paragraaf wordt het duidelijk hoe ontwikkeling van de rekenmodellen tot stand zijn gekomen. Het betreft hier om de Enhancement Pack upgrade, Support Package Stack upgrade en Release upgraden van een SAP ERP systeem. Dit is de scope welke aangehouden wordt in dit hoofdstuk. De rekenmodellen bevatten bedrijfskritische gegevens (zoals bijvoorbeeld de verwachtte inspanningsuren van een project en het daarbij behorende uurloon), om die reden zullen de desbetreffende gegevens in dit verslag niet op de werkelijkheid gebaseerd zijn. Om dit hoofdstuk goed te kunnen begrijpen is het raadzaam om hoofdstuk 2.2 “De upgradetechniek van SAP systemen” op pagina 16, te gebruiken als naslag tijdens het lezen.
4.1.1 Verzamelfase In deze fase moet er worden gezocht naar informatie waarmee je de volgende fase, de ontwikkelfase, in kan gaan. We gaan opzoek naar projectdocumentatie uit het verleden die de volgende punten bevatten: 1. Het project moet een Enhancement pack upgrade, Support Package Stack upgrade of een Release upgrade zijn op een SAP ERP systeem. 2. Planning / ureninschatting van het project. 3. De daadwerkelijk gefactureerde uren op het project. De eerste stap is om alle projecten uit het verleden te verzamelen die betrekking hebben tot het eerste punt. Vanuit het urendeclaratie systeem van Magnus, waarin alle uren worden geschreven, hebben we een lijst gegenereerd met daarin alle afgeronde projecten tussen 2008 en 2011. Projecten van voor 2008 hebben we als “te oud” aangemerkt en zijn om deze reden niet bruikbaar. Deze projecten zijn namelijk niet meer te vergelijken met de projecten zoals hoe deze nu gedaan worden. De volgende stap is om de lijst te filteren op de desbetreffende scope (punt 1). Ieder project wordt nagelopen en wanneer een project onder de scope valt, zijn de volgende gegevens genoteerd: Naam klant Projecttype Datum Projectcode Namen van Magnus medewerkers die uren op het project hebben geschreven De volgende stap is om de projectinformatie op te halen. Dit zijn punt 2 en punt 3 uit de eerder genoemde lijst. Punt 2, planning en ureninschatting, kan worden gevonden in de desbetreffende offerte van het projectnummer. Zoals beschreven staat in hoofdstuk 3.1 “Beschrijving huidig proces” op pagina 23, worden de offertes bewaard. Dit gebeurt op het intranet van Magnus in de vorm van een PDF document. In de praktijk blijkt dit echter niet altijd te gebeuren, toen ik hier verder op in ging bleek hier een reden voor te zijn: Bij relatief kleine projecten wordt er niet een hele offerte opgesteld maar heeft de zowel de klant als Magnus voldoende aan enkel een ureninschatting. Dit heeft voornamelijk betrekking op de SAP ERP Support Package Stack upgrade projecten. Omdat sommige klanten ook een onderhoudscontract hebben met Magnus is het niet nodig om voor deze projecttypen een hele offerte op te stellen. De uren vallen namelijk in dat geval onder de uren van het onderhoudscontract. Jordy van der Meij
Pagina 29 van 79
Afstudeerverslag Voor de SAP ERP Support Package Stack upgradeprojecten zijn er dus enkel ureninschattingen voorhanden welke opgesteld zijn in een Microsoft Excel document. Deze ureninschattingen bleken niet centraal opgeslagen te staan. Om deze ureninschattingen toch te ontvangen zijn de consultants die met dit project bezig zijn geweest, dit is te zien aan welke consultant uren heeft geschreven op het project, persoonlijk door mij benaderd. Over het algemeen bleken deze consultants de ureninschattingen wel zelf op te slaan in hun administratie en kon ik deze dus ook ontvangen. Voor de SAP ERP Release upgrades en SAP Enhancement Pack upgrades waren er wel volledige offertes voor handen op het intranet. Dit heeft te maken met het feit dat dit grotere projecten zijn dan SAP ERP Support Package Stack upgrade projecten. Aan een groter project zitten namelijk onder andere meer randvoorwaarden en risico’s waarmee de klant akkoord moet gaan. Tevens vallen dit soort projecten niet altijd binnen de onderhoudscontracten die de klant met Magnus heeft. De volgende stap is om de daadwerkelijk aantal gefactureerde uren op een project te verzamelen om deze vervolgens in de volgende fase, uniformeerfase, met de eerder opgevraagde ureninschatting te vergelijken. Het opvragen van de gefactureerde uren kon uit het urendeclaratie systeem van Magnus worden gehaald aan de hand van de projectcodes. Alle informatie is nu voorhanden om de volgende fase in te gaan, de uniformeerfase, waarin de projecten met elkaar worden vergeleken. Projectinformatie overige projecttypen Synchroon aan het zoeken naar projectinformatie die binnen de scope van dit hoofdstuk valt, liep het zoeken en verzamelen van projectinformatie van de algemene projectscope10. In die zoektocht kwamen er wel wat problemen bij kijken. Één van de problemen was het feit dat er voor SAP Business Warehouse systemen geen projectinformatie (zoals offertes en ureninschattingen) kon worden gevonden die betrekking hebben tot een Enhancement Pack of een Support Package Stack upgrade. Hierover ben ik in gesprek gegaan met Norbert Gundlach, een senior consultant van Magnus die tevens ook tot de projectgroep behoord. De conclusie die we uit dit gesprek hebben getrokken is dat deze upgradetypen vaak een onderdeel zijn van grotere onderhoudsprojecten. De informatie van deze onderhoudsprojecten is voorhanden, echter bleek daarin dat de uren die betrekking hebben tot de Enhancement Pack upgrade, of Support Package Stack upgrade, heel lastig af te scheiden zijn van de andere projectwerkzaamheden. Wij zijn toen verder gaan kijken hoe we toch deze informatie konden gaan verzamelen. Ervaringen van betrokken consultants hebben mij toen geleerd dat de projecthandelingen die binnen deze projectsoorten vallen, ongeveer gelijk zijn aan de projecthandelingen van een SAP ERP Enhancement Pack Upgrade en SAP ERP Support Package Stack upgrade. Het enige verschil is dat het aantal besteedde uren van deze projecten verschillen van de SAP Business Warehouse upgrade projecten. Het enige probleem dat er nu nog is, is dat er geen correctie invoerparameters voor deze rekenmodellen kunnen worden gedefinieerd. In de risicobeheersing11 is hier rekening meegehouden. Wanneer er niet voldoende projectinformatie voorhanden is zal de test en verbeterfase vaker worden doorlopen om zodoende tot een goede uitvoer van het rekenmodel te komen. In de ontwikkelfase zal verder
10 11
Zie hoofdstuk 1.2.3 “Projectscope” op pagina 10 Zie hoofdstuk 1.2.8 “Risicobeheersing” op pagina 11
Jordy van der Meij
Pagina 30 van 79
Afstudeerverslag worden toegelicht hoe de invoer parameters voor deze rekenmodellen zijn vastgesteld.
4.1.2 Uniformeerfase Nu alle projectinformatie voorhanden is, is het zaak om de offertes te analyseren en voor ieder projecttype de projecthandelingen te uniformeren voor ieder project. Wanneer dit gedaan is kunnen de projecturen worden ingevuld op de geüniformeerde projecthandelingen. Op die manier kun je projecten met elkaar vergelijken om vervolgens in de ontwikkelfase een rekenmodel te creëren voor het desbetreffende projecttype. De uitkomst van deze fase zal, voor ieder projecttype, een lijst zijn met daarin de projecthandelingen die worden verricht tijdens het desbetreffende project. Achter deze handelingen staan zowel de uren van de eerder verzamelde ureninschatting vermeld als de uren die daadwerkelijk zijn gefactureerd. De resultaten van deze fase zijn op last van Magnus niet in dit verslag opgenomen omdat deze bedrijfskritische gegevens bevatten. In deze paragraaf zal de uniformeerfase van één projecttype worden uitgelicht. Dit zal de Enhancement Pack upgrade zijn op een SAP ERP systeem. De uniformeerfase van de overige twee projecttype, en tevens van de overige projecttype die buiten de scope van dit hoofdstuk vallen, zijn op exact dezelfde wijze doorlopen. Na het uitvoerig analyseren en bestuderen van de SAP ERP Enhancement Pack upgrade projecten ben ik tot de volgende projecthandelingen gekomen, zie Tabel 3 Uniformering van handelingen van een SAP ERP Enhancement Pack upgrade, inclusief toelichting. op pagina 31, die uitgevoerd worden tijdens deze upgradetrajecten. Sommige van de geanalyseerde offertes bevatten meerdere handelingen dan die in de tabel beschreven staan. Dit zijn bijvoorbeeld onderhoudshandelingen als hardware upgrade / migratie trajecten en dergelijke. Deze handelingen worden niet altijd uitgevoerd en vallen om die reden niet onder de projectscope. SAP ERP Enhancement Pack upgrade handelingen Voorbereiding Algemene handelingen Downloads DEV systeem Inspelen EHP Inspelen SPS na EHP upgrade Kernel upgrade Nabewerking QAS systeem Inspelen EHP Inspelen SPS na EHP upgrade Kernel upgrade Nabewerking PRD systeem Inspelen EHP Inspelen SPS na EHP upgrade Kernel upgrade Nabewerking Tabel 3 Uniformering van handelingen van een SAP ERP Enhancement Pack upgrade, inclusief toelichting.
Jordy van der Meij
Algemene handelingen Hieronder vallen de algemene projecthandelingen verstaan, bijvoorbeeld het opzetten van een projectplan. Downloads Hieronder valt de tijd van het downloaden van de Enhancement Pack versie. Inspelen EHP De tijd die staat voor het installeren van de Enhancement Pack versie. Inspelen SPS na EHP upgrade De tijd die staat voor het installeren van de Support Package Stacks na de Enhancement Pack installatie. Kernel upgrade De tijd die staat voor het upgraden van de SAP kernel. Nabewerking De tijd die staat voor de foutoplossing na het installeren en upgraden van de software.
Pagina 31 van 79
Afstudeerverslag Nu de handelingen bekend zijn die binnen een project zitten kunnen er aan deze handelingen uren gekoppeld worden. Dit zullen zowel de uren van de eerder verzamelde ureninschatting zijn, als de uren van de daadwerkelijk gefactureerde uren. Tevens zijn ook de upgradespecificaties vermeld (van en naar welk softwareniveau). Na dit gedaan te hebben is het overzicht geanalyseerd en zijn er de volgende conclusies getrokken: Uren worden niet altijd op een duidelijke / eenduidige manier in het urensysteem gedeclareerd. Soms worden uren voor een bepaalde handeling bijgeschreven op andere handelingen. Sommige projecten worden aangeboden op een “fixed price” basis, daardoor worden de uren niet altijd even goed bijgehouden. Tevens is de conclusie getrokken dat de uren van de projecten erg veel van elkaar afwijken. Onderzoek hiernaar geeft als resultaat dat dit, onder andere, met de volgende dingen te maken heeft: De softwareniveaus, “van en naar” verschillen per project. Ieder project heeft te maken met zijn eigen klantspecifieke omgevingen. o Sommige klanten hebben meer maatwerk, er is dan meer tijd voor probleemoplossing nodig. o De performance van het ene systeem is beter dan het andere systeem. Sommige klanten willen dat de systemen tijdens een upgradetraject fulltime gemonitord worden. Soms ging een upgrade van een systeem niet goed. In dat geval moet de upgrade nog een keer gedaan worden. De algemene conclusie luidt eigenlijk dat geen van de projecten het zelfde is, of dat ooit zal zijn. Iedere klant heeft namelijk ook klantspecifieke eisen of in ieder geval een klantspecifieke omgeving. Wel heeft ieder project, binnen hetzelfde projecttype, altijd een aantal basis handelingen die in ieder project terugkomen. Door een juiste afbakening van de projecthandelingen is echter wel mogelijk de projecten met elkaar te vergelijken. Tevens kon na gesprekken met consultants, en analyse van het overzicht waar de projecten met elkaar worden vergeleken, het volgende worden geconcludeerd: Het upgraden van het Development systeem (DEV) duurt over het algemeen het langst. Dit heeft vooral te maken met het feit dat er veel uren kwijt zijn aan de probleemoplossing. Bij het upgraden van het QAS systeem is men minder uur kwijt aan probleemoplossing dan bij het DEV systeem. Het inspelen van de Enhancement Pack op het Productiesysteem (PRD) duurt even lang als bij het DEV en QAS systeem. Echter zal er tijdens het upgraden van dit systeem meer gemonitord worden.
Jordy van der Meij
Pagina 32 van 79
Afstudeerverslag
4.1.3 Ontwikkelfase In deze fase zal het rekenmodel worden ontwikkeld. Dit zal gebeuren in Microsoft Excel, dit programma leent zich uitstekend voor het maken van berekeningen. Voordat een rekenmodel ontwikkeld kan worden moeten er eerst twee dingen duidelijk zijn: Wat moeten de invoerparameters zijn Wat moet de uitvoer zijn. De invoerparameters verschillen per projecttype. Ook in deze paragraaf gaan we weer uit van één projecttype; SAP ERP Enhancement Pack upgrade. De invoerparameters zullen dezelfde gegevens moeten zijn, als de gegevens die in de handelingen “Noteren specificaties” en “bepalen projecthandelingen” van het huidige proces 12 worden genoteerd. Voor dit projecttype zullen de volgende invoerparameters gevraagd worden door het rekenmodel: Huidig Enhancement pack versie. Gewenste Enhancement pack versie. Is er na het inspelen van de Enhancement Pack, nog een Support Package Stack upgrade nodig. Aantal systemen waarop de upgrade moet worden toegepast. De uitvoer van het rekenmodel zal gelijk zijn aan de tabel uit de vorige paragraaf. De uren die aan de projecthandelingen worden toegekend zullen het verwacht aantal besteedde uren zijn (ook wel “Budget” uren genoemd). Zoals er in de vorige paragraaf al werd geconcludeerd is geen van de projecten hetzelfde gegaan en zal ook nooit één van de projecten hetzelfde gaan zijn. Dit maakt het erg lastig om tot een goed rekenmodel te komen. Er zullen dus keuzes gemaakt moeten worden om toch tot een goedwerkend rekenmodel te komen die voor ieder project een goede indicatie geeft hoeveel uur er in het project gaat zitten. De volgende keuzes zijn toen door de project groep gemaakt: Er wordt een rekenmodel ontwikkeld op basis van de projecten waar de minsten problemen bij zijn komen kijken. De uitvoer van het rekenmodel wordt uiteindelijk in de offerte opgenomen die de applicatie genereert. Op deze offerte zullen duidelijke voorwaarden van toepassing moeten zijn. Aan de hand van de conclusies uit de vorige paragraaf en de invoer en uitvoerparameters die in deze paragraaf vermeld staan is er een rekenmodel ontwikkeld. In dit verslag zal er niet dieper op dit rekenmodel worden ingegaan omdat deze bedrijfskritische gegevens bevatten.
12
Zie hoofdstuk 3.1 “Beschrijving huidig proces” op pagina 23
Jordy van der Meij
Pagina 33 van 79
Afstudeerverslag
4.1.4 Test en verbeterfase Nu het rekenmodel ontwikkeld is wil het niet zeggen dat deze daadwerkelijk een goede uitvoer genereert. Alhoewel het rekenmodel gebaseerd is op projecten uit het verleden is het ontzettend belangrijk om het rekenmodel te testen. Wanneer het rekenmodel getest is, zullen de resultaten bekeken moeten worden en waarnodig moet het rekenmodel worden aangepast. Dit is een iteratief proces dat zo vaak mogelijk herhaald moet worden als mogelijk. Hoe vaker er getest kan worden, hoe nauwkeuriger de uitvoer van het rekenmodel namelijk zal zijn. De beste manier om de rekenmodellen te testen is om de resultaten van het rekenmodel te vergelijken met die van een daadwerkelijke consultant. Deze testmethode is voor ieder rekenmodel gehanteerd. Er zijn daarom een aantal testcasussen opgesteld. Deze casussen bestonden uit dezelfde vragen als die gevraagd werden door de invoerparameters van het rekenmodel. De consultants dienden voor iedere casus een ureninschatting te maken. De uren moesten geschreven worden in dezelfde tabel als dat het rekenmodel als uitvoer geeft. Om hier een duidelijker beeld van te krijgen volgt er één van de naar consultants gestuurde casussen. Handeling SAP ERP Enhancement Pack upgrade
Voorbereiding Algemene handelingen
Huidige situatie Type systeem: Huidig EHP versie: Aantal systemen:
Uur
Downloads SAP ERP 3 3 (Dev, Qas, Prd)
DEV systeem Inspelen EHP Inspelen SPS na EHP upgrade
Gewenste situatie Type systeem: Gewenst EHP versie: Inclusief SPS upgrade: Aantal systemen:
Kernel upgrade SAP ERP 5 Ja, SPS4 3 (Dev, Qas, Prd)
Nabewerking QAS systeem Inspelen EHP Inspelen SPS na EHP upgrade
Tabel 4 Één van de casussen die de consultants hebben ontvangen
Kernel upgrade Nabewerking PRD systeem Inspelen EHP Inspelen SPS na EHP upgrade Kernel upgrade Nabewerking Tabel 5 De tabel waar de consultants de uren in moesten schrijven.
Jordy van der Meij
Pagina 34 van 79
Afstudeerverslag Gemiddeld zijn er ongeveer 1 á 2 testrondes geweest voor ieder rekenmodel. Iedere testronde bestond uit ongeveer 2 á 3 testcasussen welke gestuurd werden naar 2 of 3 consultants. Wanneer er een testronde geweest was zijn de resultaten besproken in de gehele projectgroep en soms werden de consultants die de casussen hadden gemaakt erbij betrokken om uitleg te geven over hun urenverantwoording. Aan de hand hiervan werd het rekenmodel aangepast wanneer dat nodig was. Voor sommige rekenmodellen werden er ook aanpassingen gedaan in de projecthandelingen. Om een voorbeeld te noemen; bij een SAP Business Warehouse Release upgrade was het een keuze om in het upgradetraject ook een SAP Business Warehouse Enhancement Pack en Support Package Stack upgrade uit te voeren. Feedback van diverse consultants vertelde ons (de projectgroep) dat dit geen keuze behoord te zijn, maar een standaardactiviteit die altijd moet worden uitgevoerd. Dit is ook een advies vanuit SAP zelf. Om die reden is het rekenmodel aangepast zodat er bij dit type upgrade altijd uren worden berekend voor deze twee activiteiten. Nu het rekenmodel uitvoerig getest is wordt de uitvoer die het genereert steeds nauwkeuriger en meer in lijn met de werkelijkheid. De gegeneerde ureninschatting van het rekenmodel zal uiteindelijk worden verwerkt in een offerte. Natuurlijk is de kans altijd aanwezig dat de uitvoer die het genereert niet in lijn is met de werkelijkheid, dit heeft vaak te maken met klant specifieke omstandigheden. In dat geval is de offerte niet juist en kan deze niet worden uitgevoerd. Om hier geen onduidelijkheden over te laten bestaan zullen er bepaalde voorwaarden worden gesteld aan de offerte. Deze voorwaarden zullen worden opgesteld door Magnus.
Jordy van der Meij
Pagina 35 van 79
Afstudeerverslag
5
DE REKENMODELLEN AANGEKLEED
Tijdens het ontwikkelen van de rekenmodellen is er ook nagedacht over de presentatie en het gebruik van de applicatie. Dit valt onder de “Functional Model Iteration” fase van de DSDM project ontwikkelingsmethodiek. De nadruk van deze fase ligt op het vaststellen van de functionele en niet functionele eisen. Met behulp van diverse prototypes worden deze bepaald. Aan al deze eisen zal een prioriteit worden toegekend door de projectgroep middels het MoSCoW principe13. De eisen worden bepaald aan de hand van de relatie tussen de projectscope, uitgangspunten, randvoorwaarden en de projectdoelstellingen14. In deze fase zal tevens onderzocht worden hoe, en waarin, de applicatie zal worden gerealiseerd.
5.1 Gebruikersscenario’s Voordat de gebruikerseisen en functionaliteiten kunnen worden bepaald is het nodig om eerst in kaart te brengen hoe de applicatie moet functioneren. Hier heb ik een aantal gebruikersscenario’s voor bedacht en uitgewerkt. Deze scenario’s zijn gebaseerd op het gebruik van de applicatie door een klant. Vervolgens heb ik deze aan de projectgroep voorgelegd waaruit discussies voortkwamen. De scenario’s zijn allen gebaseerd op volgende drie uitgangspunten die de volledige scope op dit onderdeel dekken:
Simpel
Uitgangspunten Duidelijk
Laagdrempelig
Figuur 7 De drie uitgangspunten van de applicatie
Simpel De applicatie moet er simpel uit zien; “less is more”. Tevens moet de applicatie simpel in gebruik zijn. De gebruiker mag zo weinig mogelijk fouten kunnen maken tijdens het gebruik van de applicatie. Duidelijk Alles wat invoer betreft moet duidelijk zijn zodat de kans op foutieve invoer nihil is. De gebruiker moet weten wat hij dient te vullen. 13 14
Zie hoofdstuk 2.3 "Project ontwikkelingsmethodiek" op pagina 11 Zie hoofdstuk 1.2.4 "Randvoorwaarden en uitgangspunten" op pagina 11
Jordy van der Meij
Pagina 36 van 79
Afstudeerverslag Laagdrempelig Een gebruiker van de applicatie kan een klant zijn. De drempel voor de klant om de applicatie te gebruiken dient zo laag mogelijk te zijn. Echter moet het niet zo zijn dat de drempel zo laag ligt dat Magnus hier hinder van kan gaan ondervinden.
5.1.1 Scenariokeuze In dit onderdeel zullen alle uitgewerkte scenario’s in het kort aan bod komen. Deze scenario’s worden vergeleken en vervolgens wordt er een definitieve keuze gemaakt welk scenario gebruikt gaat worden. Dit scenario wordt in de volgende paragraaf uitgebreider behandeld, inclusief het interne gebruik van de applicatie binnen dit scenario. Scenario 1
De klant gaat naar de website van Magnus en klikt in het menu op “Offerte aanvraag”. Hier kiest hij het gewenste upgradetype en vult daarna de gevraagde invoer in. De klant drukt vervolgens op de knop “genereer offerte” waarna de offerte wordt getoond op een nieuwe pagina. Onderaan deze pagina staat een verwijzing naar de voorwaarden die op de offerte van toepassing zijn. Het is voor de klant mogelijk de offerte te downloaden naar een PDF waarna hij deze op kan slaan.
Figuur 8 Simpele figuurlijke weergave scenario 1
Voordelen Laagdrempelig omdat er weinig acties van de klant zijn vereist. Ook te gebruiken voor toekomstige klanten van Magnus. Nadelen De kans op “niet serieuze” offertes is ontzettend groot. De kans dat de klant de voorwaarden niet leest is erg groot. Wanneer de offerte wordt opgeslagen in een database is het niet af te leiden van welke klant dit komt.
Jordy van der Meij
Pagina 37 van 79
Afstudeerverslag Scenario 2 De klant gaat naar de website van Magnus en klikt in het menu op “Offerte aanvraag”. Hier kiest hij het gewenste upgradetype en vult daarna de gevraagde invoer in. Tevens wordt de klant gevraagd om de NAW gegevens in te vullen. De klant drukt vervolgens op de knop “genereer offerte” waarna de offerte wordt getoond op een nieuwe pagina. Onderaan deze pagina staat een verwijzing naar de voorwaarden die op de offerte van toepassing zijn. Het is voor de klant mogelijk de offerte te downloaden naar een PDF waarna hij deze op kan slaan. Voordelen Kans op “niet serieuze” offertes verlaagd vanwege de NAW gegevens die gevraagd worden. Echter is het gebruik nog wel laagdrempelig. Offertes worden in de database opgeslagen inclusief NAW gegevens. Magnus weet dus wie de offerte heeft aangevraagd. Ook te gebruiken voor toekomstige klanten van Magnus. Nadelen Kans op “niet serieuze” offertes nog wel aanwezig omdat de NAW gegevens niet gecontroleerd kunnen worden of deze echt van de klant zijn. De kans dat de klant de voorwaarden niet leest is erg groot.
Figuur 9 Simpele figuurlijke weergave scenario 2
Jordy van der Meij
Pagina 38 van 79
Afstudeerverslag Scenario 3 De klant gaat naar de website van Magnus en klikt in het menu op “Offerte aanvraag”. Hier kiest hij het gewenste upgradetype en vult daarna de gevraagde invoer in. Tevens wordt de klant gevraagd een e-mailadres in te vullen. De klant drukt vervolgens op de knop “genereer offerte” waarna de offerte (inclusief de voorwaarden) in PDF formaat per e-mail naar het ingevoerde e-mailadres wordt gestuurd.
Voordelen Kans op “niet serieuze” offertes is nihil. Klant krijgt duidelijk de voorwaarden te zien. Ook te gebruiken voor toekomstige klanten van Magnus. Offertes worden in de database opgeslagen inclusief het e-mailadres. Magnus weet dus wie de offerte heeft aangevraagd. Nadelen Minder laagdrempelig omdat de klant zelf meer acties moet ondernemen.
Figuur 10 Simpele figuurlijke weergave scenario 3
Jordy van der Meij
Pagina 39 van 79
Afstudeerverslag Scenario 4 De klant gaat naar de website van Magnus en klikt in het menu op “Offerte aanvraag” en logt hier op in middels een persoonlijke gebruikersnaam en wachtwoord die door Magnus is uitgegeven. Daarna kiest hij het gewenste upgradetype en vult daarna de gevraagde invoer in. De klant drukt vervolgens op de knop “genereer offerte” waarna de offerte wordt getoond op een nieuwe pagina. Onderaan deze pagina staat een verwijzing naar de voorwaarden die op de offerte van toepassing zijn. Het is voor de klant mogelijk de offerte te downloaden naar een PDF waarna hij deze op kan slaan. Voordelen Alleen serieus geïnteresseerde klanten maken gebruik van de dienst. Klanten zijn bekend met de werkwijze van Magnus. (Het gehele upgradetraject, facturatie e.d.) Nadelen Niet te gebruiken door toekomstige klanten.
Figuur 11 Simpele figuurlijke weergave scenario 4
Jordy van der Meij
Pagina 40 van 79
Afstudeerverslag Om uiteindelijk tot het beste scenario te komen is goed om de scenario’s met elkaar te vergelijken. De vergelijkingsvariabelen zijn de algemene projectscope15. De score die gegeven kan worden is: +, +/- of -. De scores zijn in eerste instantie door de projectontwikkelaar, ikzelf dus, toegekend. Tijdens één van Functional Model Iteration workshops zijn deze met het gehele projectteam besproken. Hieronder wordt de vergelijkingsmatrix weergegeven.
Scenario Scenario Scenario Scenario
1 2 3 4
Simpel
Duidelijk
Laagdrempelig
Gebruik door (toekomstige) klant
+ + + +
+ + + +
+/+/+ -
+ + -
Tabel 6 De scenario’s in een vergelijkingsmatrix
Conclusie De conclusie die getrokken kan worden uit de vergelijkingsmatrix is dat het derde scenario het beste is om te gebruiken. Scenario 1 is vanuit het oogpunt van Magnus niet optimaal omdat men niet kan zien welk bedrijf de offerte heeft aangevraagd. Magnus kan dus niet pro actief richting deze klant zijn omtrent de aangevraagde offerte. De kans dat Magnus middels dit gebruikersscenario nieuwe klant binnenhaalt is daarom een stuk kleiner in vergelijking met de andere scenario’s. Ook scenario 4 valt wat dat betreft af, als Magnus zelf inloggegevens moet verstrekken kan dat alleen aan al bestaande klanten. Scenario 2 en scenario 3 blijven dan over. Wanneer we deze naast elkaar zetten is de conclusie van de projectgroep dat het derde scenario het best is. Het gebruik van de applicatie is laagdrempelig omdat de klant enkel zijn e-mailadres in hoeft te vullen. In dat geval weet Magnus zeker dat de klant ook daadwerkelijk de klant is omdat hij de offerte naar dat e-mailadres wordt gestuurd. Indien dit een niet bestaand e-mailadres is kan de klant de offerte dus niet inzien. Bij scenario 2 kunnen er eventueel nog wel niet klanteigen gegevens ingevuld worden. De mogelijkheid dat de klant bij scenario 3 een privé e-mailadres of iets dergelijks invult, en Magnus daarom niet weet welk bedrijf de offerte heeft aangevraagd, wordt zeer klein geacht en is geen reden om af te wijken van scenario 3.
5.2 Behoefte onderzoek Alhoewel dit project voornamelijk in het leven is geroepen om het proces van offertes uitbrengen voor Magnus te vergemakkelijken is één van de doelstellingen15 ook dat de applicatie door niet klanten van Magnus gebruikt kan gaan worden. Dit is al uitvoerig beschreven in de scenariobeschrijvingen van de vorige paragraaf. Het is daarom goed om de behoefte uit die kant te peilen. Om die reden is er een behoefte onderzoek opgezet. Vanuit strategisch oogpunt is ervoor gekozen om enkel firma’s te bellen die geen klant zijn van Magnus. Aan de hand van een vijftal korte vragen willen wij er graag achter komen wat de, en of er, behoefte is aan een dergelijke online offerte calculatie tool. Binnen Magnus was er een lijst beschikbaar met firma’s en contactpersonen (dit waren meestel IT managers of SAP gerelateerde personen). Helaas kwam er uit dit onderzoek niet wat wij vooraf hebben gedacht. De resultaten waren als volgt:
15
Zie hoofdstuk 1.2.2 "Project doelstellingen", hoofdstuk 1.2.3 "Projectscope" en hoofdstuk 1.2.4 "Randvoorwaarden en uitgangspunten" op pagina 11
Jordy van der Meij
Pagina 41 van 79
Afstudeerverslag Er zijn 17 firma’s gebeld: Waarvan 3 firma’s niet de behoefte hadden om de vragen telefonisch of per email te beantwoorden. Waarvan 1 firma de contactpersoon er niet meer werkte en er geen ander contactpersoon beschikbaar hiervoor was. Waarvan 2 firma’s de contactpersoon mijzelf meedeelde hier geen interesse in hadden omdat ze tevreden zijn met hun eigen leverancier. Waarvan 11 firma’s op dit moment niet in de gelegenheid waren om op dit moment mij te woord te staan. Deze mocht ik een e-mail sturen met daarin de vragen. Van de 11 firma’s die ik per e-mail heb benaderd voor het invullen van de vragen voor het behoefte onderzoek, heeft geen enkele dit gedaan. In overleg met de projectgroep is er toen besloten om aan dit onderzoek verder geen aandacht meer te besteden omdat de verwachtte resultaten uit bleven. Ook was de verwachting er niet dat er, na meer inspanning, meer resultaten zouden komen. De vragenlijst die dit onderdeel uitmaakte van het behoefte onderzoek is terug te vinden Bijlage C “Vragenlijst van het behoefte onderzoek” op pagina 63. Dat het onderzoek geen resultaten heeft opgeleverd betekent overigens niet dat er geen behoefte is aan een dergelijke online calculatie tool. In een business to business markt, waarin Magnus zich bevindt, is het erg lastig om een dergelijk onderzoek uit te voeren. Over het algemeen kom je als enquêteur in contact met IT managers, of andere personen die hoog aangeschreven staan in het bedrijf, waarbij de enquête moet worden afgenomen. Deze personen zijn vaak erg druk en zijn om die reden minder geïnteresseerd om telefonisch, of per e-mail, aan een dergelijk onderzoek mee te werken. Tevens kan niet iedere firma hiervoor gebeld worden, er moet wel enige aanleiding voor zijn. De 17 firma’s die in dit onderzoek zijn gebeld, hadden al vanuit het verleden een link, op welke manier dan ook, met Magnus.
Jordy van der Meij
Pagina 42 van 79
Afstudeerverslag
5.3 Het gebruikersscenario uitgewerkt De keuze is gevallen op gebruikersscenario 3 waarbij de offerte naar de klant per e-mail wordt toegestuurd. Deze paragraaf zal een uitgebreide uitwerking bevatten van dit scenario. Tevens zullen de eerste prototype schermen ontworpen en besproken worden. Dit is een iteratief proces, aan de hand van prototyping zullen namelijk de gebruikerseisen worden vastgesteld waarbij, zoals in de inleiding van dit hoofdstuk al staat vermeld, deze door de gehele projectgroep een prioriteit toegewezen krijgt aan de hand van het MoSCoW16 principe.
5.3.1 Niet functionele prototypes Nu het gebruikersscenario gekozen is kan er begonnen worden met het maken van de niet functionele prototypes. Een niet functioneel prototype is een prototype die in afbeeldingen de applicatie laat zien. Deze prototypes bevatten dus geen functionaliteiten. Dit is een iteratief proces en is gebaseerd op de kwaliteitscirkel van Deming. Kwaliteitscirkel van Deming De kwaliteitscirkel van Deming beschrijft een viertal activiteiten die op alle verbeteringen in organisaties op toepassing is. De garantie voor kwaliteitsverbetering wordt gegeven omdat deze methode een cyclisch karakter heeft. De volgende activiteiten vallen binnen de kwaliteitscirkel; Plan In deze fase wordt er gekeken naar de huidige werkzaamheden. De uitkomst van deze fase is om de verbeteringen, en eventueel doelstellingen, vast te stellen. Do Wanneer de verbeteringen bekend zijn, zullen deze doorgevoerd moeten worden in een proefopstelling. Figuur 12 Figuurlijke weergave van de Nederlandse kwaliteitscirkel van Deming
Check Als de verbeteringen doorgevoerd zijn zullen deze getoetst moeten worden aan de doelstellingen en verbetering uit de eerste fase. Act De verbeteringen worden bijgesteld aan de hand van de resultaten uit de vorige fase. Hierna zal weer begonnen worden aan de “Plan” fase. Deze methode wordt vaak gebruikt als hulpmiddel voor kwaliteitsverbetering binnen organisaties. Tijdens dit project zal de cirkel gebruikt worden als hulpmiddel voor kwaliteitsverbetering en probleemoplossing voor de functionaliteit van de applicatie. Wanneer de projectgroep een prototype gaat bespreken zal elke eis worden gecontroleerd in de “Plan” fase. Indien de gebruikersgroep de desbetreffende gebruikerseis niet goed genoeg vindt functioneren, zal er besproken worden hoe 16
Zie hoofdstuk 2.3 "Project ontwikkelingsmethodiek" op pagina 20
Jordy van der Meij
Pagina 43 van 79
Afstudeerverslag deze verbeterd kan worden. Vervolgens zal de verbetering worden doorgevoerd waarna er in de volgende bespreking de “Check” fase wordt doorlopen. Als hieruit voort komt dat de desbetreffende gebruikerseis nog niet voldoende werkt, zal de gebruikerseis bijgesteld worden aan de hand van de feedback uit de “Check” fase. Omdat dit een iteratief proces is voor elke gebruikerseis, wordt kwaliteit gegarandeerd. Het is echter niet zo dat alleen de eindgebruikers binnen de projectgroep bepalen of een gebruikerseis voldoende is of niet. Dit gaat altijd in samenspraak met de gehele projectgroep. Tijdens de diverse gesprekken met de hele projectgroep zijn er een aantal gebruikerseisen vastgesteld waar het prototype aan moet voldoen. We maken hierin een onderscheid tussen functionele en niet functionele eisen. Functionele eisen Deze eisen geven aan welke functies het systeem moet hebben. Deze eisen gaan om het bereiken van het uiteindelijke doel. Voorbeeld: “De gebruiker moet aan de hand van een zelfingevoerd trefwoord een zoekactie starten”. Niet functionele eisen Deze eisen geven dragen niet direct bij aan het bereiken van het doel. Ze geven aan hoe iets gedaan moet worden. Voorbeeld: “De gebruiker moet de zoekresultaten binnen 0,20 seconden te zien krijgen”.
Functionele eisen De invoervelden moeten de invoer parameters van het rekenmodel zijn.
Prioriteit Must have
De invoervelden voor de gebruiker dienen zoveel mogelijk voor gedefinieerd te zijn.
Could have
Gebruik door klant: Offerte moet in PDF per e-mail worden.
Must have
Gebruik door Magnus consultant: Offerte moet in .DocX per e-mail verstuurd worden.
Must have
Er moet een mogelijkheid zijn om extra informatie op te vragen dat betrekking heeft tot het gevraagde invoerveld.
Must have
Er moet een backend functie, voor Magnus, zijn om de parameters van de rekenmodellen aan te passen.
Could have
Er moet een mogelijkheid zijn om informatie op te vragen over het desbetreffende invoerveld.
Should have
Niet functionele eisen Applicatie dient beschikbaar te zijn binnen de huidige Magnus website. Applicatie dient ontwikkeld te worden binnen de huisstijl van Magnus
Prioriteit Must have
Applicatie moet browser onafhankelijk zijn.
Must have
Must have
Tabel 7 Functionele en niet functionele eisen die zijn voortgekomen uit de workshops.
Jordy van der Meij
Pagina 44 van 79
Afstudeerverslag Op basis van de bovenstaande gebruikerseisen, en de algemene projectscope 17, is er een prototype gebouwd. Dit prototype is een aantal keer aan de hand van de kwaliteitscirkel van Deming verbeterd. Uiteindelijk is er door de projectgroep besloten om met het volgende prototype de volgende fase (“Design en Build” fase) in te gaan waarin de applicatie daadwerkelijk gerealiseerd gaat worden. De eerdere versies van het prototype kunnen teruggevonden worden in Bijlage B: “Prototype schermen in een vroeg stadium” op pagina 60. Voor de volledigheid volgt hieronder het gebruikersscenario uitgewerkt in een BPMN flowchart voor zowel het interne als het externe gebruik van de applicatie (zie Figuur 13). De proces activiteiten zijn genummerd en zullen nader worden toegelicht met behulp van screenshots van het prototype.
Figuur 13 BPMN flowchart van het gebruikersscenario
Hieronder volgt het gebruikersscenario. In Bijlage D “Het niet functionele prototype uitgewerkt” op pagina 64 is dit gebruikersscenario nogmaals beschreven maar dan inclusief afbeeldingen van het prototype. 1. -
Gebruiker surft naar de website van Magnus.
17
Zie hoofdstuk 1.2.2 “Project doelstellingen”, hoofdstuk 1.2.3 “Projectscope” en hoofdstuk 1.2.4 “Randvoorwaarden en uitgangspunten” op pagina 11.
Jordy van der Meij
Pagina 45 van 79
Afstudeerverslag 2. -
3. 4.
5. 6.
Gebruiker klikt op de link in het menu van de offerte applicatie. Gebruiker kiest het upgrade type. Gebruiker kiest het SAP systeem type uit een lijst, waar hij de gekozen upgrade op wilt laten uitvoeren. Gebruiker kiest de huidige en gewenste softwareniveaus uit een lijst. Gebruiker kiest het aantal systemen uit een lijst waarop hij de upgrade wilt toepassen. Tevens is, afhankelijk van het upgrade type, de mogelijkheid om extra upgrademogelijkheden te kiezen. Gebruiker voert e-mailadres in, in dit geval zijn @Magnus.nl e-mailadres. Gebruiker kan er voor kiezen om een telefoonnummer achter te laten wanneer hij wilt dat Magnus contact met hem opneemt omtrent de offerte aanvraag. Gebruiker drukt op “Bereken offerte”. Het systeem controleert of het e-mailadres a. Indien @Magnus.nl e-mailadres; offerte wordt in DocX gegenereerd. b. Indien anders: offerte wordt in .PDF gegenereerd. De offerte wordt verstuurd per e-mail naar het ingevoerde e-mailadres. De gebruiker ontvangt offerte per e-mail
Uitzonderingen: 3. Wanneer één van de velden niet, of niet correct, is ingevoerd wordt er een melding weergegeven onder het desbetreffende veld. Intern gebruik Een consultant van Magnus kan ook de applicatie gebruiken om voor een klant een offerte uit te brengen. Hij, of zij, zal hetzelfde gebruikersscenario volgen die eerder in dit hoofdstuk is beschreven. Op het moment dat de gebruiker, in dit geval een Magnus consultant, het e-mailadres in moet voeren (zie Figuur 21 op pagina 66) zal hij zijn persoonlijke Magnus e-mailadres in moeten voeren. Het systeem zal herkennen dat dit een medewerker van Magnus is. In dat geval zal de gegenereerde offerte in .DocX formaat worden gestuurd naar het e-mailadres van de consultant. Het idee hierachter is dat de consultant, om welke reden dan ook, nog de mogelijkheid heeft om de offerte aan te passen. Vervolgens kan de consultant de offerte zelf naar een .PDF formaat converteren en uitsturen naar de klant. Extern gebruik Wanneer de gebruiker van de applicatie een klant is zal het gebruikersscenario, dat eerder in dit hoofdstuk staat beschreven, gevolgd worden. Op het moment dat de offerte wordt gegenereerd zal zowel de klant deze ontvangen, op het door hem gegeven e-mailadres. Tevens wordt er een kopie van de offerte gestuurd naar het Sales e-mailadres van Magnus. Zo is Magnus op de hoogte van het feit dat de desbetreffende klant een offerte heeft aangevraagd. Indien de klant wilt dat Magnus contact opneemt met hem omtrent de offerte (zie Figuur 21 op pagina 66), ziet Magnus dit terug in de e-mail die gestuurd wordt naar het Sales adres van Magnus.
Jordy van der Meij
Pagina 46 van 79
Afstudeerverslag Wanneer het uiteindelijke prototype wordt vergeleken met de eerdere versies 18 valt direct op dat de vormgeving drastisch veranderd is. Waar voorheen alle invoer parameters werden gevraagd middels het tonen van een lijst, worden nu de invoer parameters gevraagd middels een wizard methode. Dit is één van de punten waar de kwaliteitscirkel van Deming voor heeft gezorgd. In de evaluatie gesprekken van de vorige prototype versies werden deze prototypes terug vertaald naar de projectdoelstellingen, randvoorwaarden en uitgangspunten 19. De projectgroep kwam tot de conclusie dat de termen “simpel” en “duidelijk” niet goed genoeg vertaald werden naar het prototype. In de vorige prototypes was kon het tekstvak voor extra informatie worden opgeroepen middels een icoon naast het betreffende invoerveld. Dit moest duidelijker en simpeler kunnen. Deze doelstellingen zijn toen vastgesteld in de “Plan” fase van de kwaliteitscirkel van Deming. In de “Do” fase zijn deze doelstellingen doorgevoerd, waarna de gehele vormgeving van de invoervelden is veranderd naar wizard methode. De extra informatie is hierin direct zichtbaar, dat maakt de applicatie een stuk duidelijker. Tevens oogt dit een stuk rustiger omdat de klant bij iedere stap maar één of twee dingen in hoeft te voeren. Bij de vorige versies van het prototype kreeg de gebruiker in één keer een scherm te zien waarin hij alle invoer moest zetten. In de “Check” fase werd dit nieuwe ontwerp getoond binnen de projectgroep. Uit deze fase kwamen nog een aantal kleine verbeteringen die doorgevoerd moesten worden, zoals bijvoorbeeld de positie van het tekstvak waar de extra informatie in staat. Deze kleine verbeteringen zijn in de “Act” fase doorgevoerd. Vervolgens is de projectgroep met dit nieuwe ontwerp weer de eerste fase van de kwaliteitscirkel ingegaan. Hieruit kwam naar voren dat dit ontwerp voldoet aan de gestelde doelstellingen, randvoorwaarden en uitgangspunten. Met dit prototype zal de volgende DSDM fase “Design and Build Iteration” worden gestart waarin de applicatie daadwerkelijk gerealiseerd gaat worden.
5.3.2 Backend In zowel het prototype als het gebruikersscenario komt de backend van de applicatie niet aan de orde. Deze is echter wel besproken binnen de projectgroep. De prioriteit van de backend ligt niet op het grafische ontwerp maar meer op de functionaliteit ervan. De functionaliteit ervan is opgenomen in de lijst van functionele eisen, die vermeld staan in hoofdstuk 5.3.1 “Niet functionele prototypes” op pagina 43. De backend zal in hoofdstuk 6.3.1 “De backend” op pagina 53 verder worden besproken.
18
Zie Bijlage B: “Prototype schermen in een vroeg stadium” op pagina 68. Zie hoofdstuk 1.2.2 “Project doelstellingen”, hoofdstuk 1.2.3 “Projectscope” en hoofdstuk 1.2.4 “Randvoorwaarden en uitgangspunten” op pagina 11. 19
Jordy van der Meij
Pagina 47 van 79
Afstudeerverslag
5.4 Ontwikkelomgeving Nu het bekend is hoe het niet functionele prototype eruit ziet, kan er gekeken worden hoe dit prototype kan worden gerealiseerd. Tijdens het ontwerpen van het prototype is er al onderzoek gedaan naar de mogelijkheden waarin de applicatie kan worden gebouwd. Hieruit kwamen een aantal verschillende ontwikkelomgevingen naar voren. De applicatie kan natuurlijk in ontzettend veel verschillende ontwikkelomgevingen worden gerealiseerd, echter is niet iedere ontwikkelomgeving voor de handliggend. Magnus heeft zelf in haar organisatie een tak dat zich bezig houdt met applicatie ontwikkeling. Deze tak van het bedrijf heet “Magnus Technology Solutions” en valt in het organogram 20 onder de afdeling “Advanced Technology and Development”. Met een aantal personen die werkzaam zijn binnen deze afdeling ben ik in gesprek gegaan. In combinatie met eigen ervaringen die ik heb met diverse ontwikkelomgevingen is er de volgende shortlist gemaakt van mogelijkheden waarin de applicatie ontworpen kan worden. PHP Microsoft .Net Mendix PHP PHP (PHP Hypertext Preprocessor) is een object georiënteerde programmeertaal die bedoeld is om dynamische webpagina’s te creëren. PHP kun je samen laten werken met een database management systeem zoals MySQL. Deze combinatie biedt een mogelijkheid om veilige en krachtige webapplicaties te bouwen. Mijn persoonlijke kennisniveau is hiervan redelijk. Binnen Magnus is de aanwezige kennis redelijk, tot goed. PHP is, zoals eerder geschreven, een pure scripttaal wat betekent dat het een tijdrovende klus is om grote webapplicaties hierin te realiseren. In combinatie met de aanwezige kennis, zowel van mij als van Magnus die iets meer dan redelijk is, zal de realisatietijd lang zijn. Microsoft .NET Microsoft .NET is een door Microsoft ontwikkeld applicatie framework waar onder andere webapplicaties mee kunnen worden ontwikkeld. Dit kan bijvoorbeeld gerealiseerd worden met ASP.NET, deze programmeertaal is specifiek gericht op het ontwikkelen van dynamische webpagina’s. Mijn persoonlijke kennis van het .NET framework is nihil, echter binnen Magnus is de kennis hiervan wel ruimschoots aanwezig op een hoog niveau. Mendix Mendix (volledige naam: Mendix Agile Business Platform) is wellicht de meest onbekende van de drie. Mendix is een ontwikkelomgeving dat, in tegenstelling tot PHP en Microsoft.NET, (web)applicaties kan ontwikkelen aan de hand van een visueel datamodel. Dit bespaard enorm veel tijd omdat er zeer weinig, tot niets, zelf geprogrammeerd hoeft te worden. Magnus Technology Solutions is een erkend partner van Mendix, de kennis is daarom ruimschoots aanwezig op hoog niveau. Persoonlijk heb ikzelf nog geen ervaring met het ontwikkelen binnen Mendix. Echter in gesprekken met medewerkers van Magnus Technology Solutions kwam naar voren dat het ontwikkelen binnen deze omgeving erg goed en snel te leren valt. 20
Zie bijlage A “Het organogram” op pagina 60
Jordy van der Meij
Pagina 48 van 79
Afstudeerverslag Om tot een goede beslissing te kunnen komen waarin de applicatie moet worden ontwikkeld, zullen de diverse ontwikkelomgevingen met elkaar worden vergeleken. Dit zal gebeuren op de volgende vier punten: Aanwezige kennis Realisatietijd Website integratie Flexibiliteit Aanwezige kennis Het is belangrijk dat de aanwezige kennis, van zowel mij persoonlijk als de kennis binnen Magnus, van de desbetreffende ontwikkelomgeving goed is. Wanneer dit niet het geval is, is het mogelijk dat het project niet binnen de gestelde looptijd van 100 dagen afgerond is. Een eventuele oplossing hiervoor is om de ontwikkeling uit te besteden. Realisatietijd Het project kent een looptijd van 100 dagen, binnen deze termijn moet de applicatie af zijn. Dit is een eis. Website integratie Het is belangrijk dat de applicatie onderdeel uitmaakt van de website. Een goede website integratie is daarom een eis. Flexibiliteit Met flexibiliteit wordt bedoeld hoe makkelijk het is om de applicatie in de toekomst uit te breiden. Ook andere aanpassingen op de applicatie vallen hieronder, bijvoorbeeld het aanpassen van het design. Aan de hand van de bovenste vier punten is de volgende vergelijkingsmatrix opgesteld waarin de drie ontwikkelomgevingen met elkaar worden vergeleken. De beoordeling van ieder punt komt voort uit onderzoek naar de ontwikkelomgevingen en gesprekken met medewerkers van Magnus Technology Consultants.
Aanwezige kennis Realisatietijd Website integratie Flexibiliteit
PHP ++ -
Microsoft .Net + +/+ +/-
Mendix ++ + + ++
Tabel 8 Ontwikkelomgeving vergelijkingsmatrix
Zoals uit de bovenstaande vergelijkingsmatrix kan worden geconcludeerd is de ontwikkelomgeving van Mendix het meest ideaal om de applicatie in te ontwikkelen. Zoals vermeld staat in de projectscope21 was het niet het idee dat de applicatie door mijzelf zou worden ontwikkeld. De reden hierachter was het gebrek aan kennis van dergelijke applicatieontwikkeling. Over het algemeen is deze kennis niet dusdanig op te bouwen binnen de looptijd van het project, om een kwalitatief goede applicatie te realiseren. Dit kreeg echter een andere wending toen ik mijzelf een aantal uur heb verdiept in Mendix. Met de gehele projectgroep is er toen besloten dat ik persoonlijk de 21
Zie hoofdstuk 1.2.3 “Projectscope” op pagina 10
Jordy van der Meij
Pagina 49 van 79
Afstudeerverslag applicatie ga ontwikkelen in Mendix. Ook is er de keuze gemaakt om meer prioriteit te geven aan de applicatieontwikkeling dan aan het ontwikkelen van rekenmodellen voor migratie en virtualisatie trajecten. Dit onderdeel uit de scope22 is toen komen te vallen. Normaliter wordt een applicatie ontworpen aan de hand van een uitgebreid functioneel en technisch ontwerp. Toen er door de gehele projectgroep is overeengekomen dat ikzelf de applicatie ook ga ontwikkelen zijn we daar gedeeltelijk vanaf gestapt. Aan de hand van de niet functionele protypes (dit kan gezien worden als het functionele ontwerp) en de rekenmodellen23 (die gedeeltelijk gezien kunnen worden als technisch ontwerp) zal de applicatie verder ontworpen worden. Eventuele hulp die daarbij nodig zal zijn kan worden geboden door Magnus Technology Consultants, welke een zeer uitgebreide kennis van Mendix hebben. Tevens is Magnus een partner van Mendix, dat wilt zeggen dat er ook ondersteuning mogelijk is vanuit het bedrijf Mendix zelf. Het zelf ontwikkelen van de applicatie heeft mij meer competenties bijgebracht dan die vooraf waren vastgesteld24.
5.4.1 Mendix Business modeler Mendix is een van origine Nederlands Platform as a Service (PaaS) softwarebedrijf dat gevestigd is in Rotterdam. Platform as a Service is het leveren Het hoofdproduct dat Mendix levert is “Mendix van een platform (infrastructuur) Business modeler”. Dit product is een via het internet zonder daarvoor krachtige “PaaS” tool waarmee extra producten te moeten bedrijfsapplicaties kunnen worden ontwikkeld. installeren. Het ondersteund het ontwikkelen, uitrollen en beheren van zelfgemaakte applicaties welke eventueel geïntegreerd kunnen worden met bestaande bedrijfsapplicaties van bijvoorbeeld SAP, Oracle of Tibco. De kracht van Mendix is dat het de ontwikkelomgeving “behendig” is. Dat wilt zeggen dat er tijdens het ontwikkelen van de applicatie zo weinig mogelijk zelf geprogrammeerd wordt. Aan de hand van een datamodel, dat iets weg heeft van een ERD datamodel, en door Mendix aangeboden functies kan er met behulp van een visuele weergave een krachtige applicatie worden ontwikkeld. Om deze ontwikkelomgeving is ook een community gebouwd waarin Mendix gebruikers, met behulp van een internetforum, elkaar voorzien van oplossingen van problemen. Ook is er een zogenaamde “Mendix App Store” waarin gebruikers hun zelf gemaakte functies kunnen delen met andere Mendix gebruikers. Zo’n functie kan bijvoorbeeld een integratie met een softwarepakket zijn, bijvoorbeeld Microsoft Excel. Het grote voordeel hiervan is dat de gebruiker zelf steeds minder zelf hoeft te ontwikkelen. De kracht van een community in het algemeen is dat gebruikers elkaar keer op keer verbeteren waardoor het aanbod steeds groter en beter wordt. In Bijlage E: “Mendix; een korte tutorial” op pagina 67, laat ik in het kort zien hoe een applicatie in Mendix wordt ontwikkeld. Dit geeft een goed beeld van hoe Mendix werkt en biedt een houvast om het volgende hoofdstuk, hoofdstuk 6 “Realisatie, implementatie en beheer”, te begrijpen.
22 23 24
Zie hoofdstuk 1.2.3 “Projectscope” op pagina 10 Zie hoofdstuk 4 “De rekenmodellen; van getallen naar geraamte” op pagina 27 Zie hoofdstuk 1.3 “Vooraf gestelde competenties en leerdoelen” op pagina 13
Jordy van der Meij
Pagina 50 van 79
Afstudeerverslag
6
REALISATIE, IMPLEMENTATIE EN BEHEER
Dit onderdeel bevat de werkzaamheden van de realisatie en implementatie van de applicatie. Dit valt onder de “Design and Build iteration” fase uit de DSDM projectontwikkelingmethodiek25. Na het lezen van dit hoofdstuk is het duidelijk hoe de applicatie -in grote lijnen- technisch in elkaar zit, geïmplementeerd is en beheerd gaat worden.
6.1 Realisatie In deze paragraaf zal in grote, en niet al te technische, lijnen worden uitgelegd hoe de applicatie is opgebouwd en gerealiseerd. De applicatie is ontworpen aan de hand van het gebruikersscenario26. Aan de hand van regelmatige bijeenkomsten in deze fase van de projectgroep, waarin de werkende applicatie keer op keer werd getoond, is de applicatie verfijnd en verbeterd met behulp van de kwaliteitscirkel van Deming27. De applicatie zal uiteindelijk in de website van Magnus worden geïntegreerd echter werd tijdens het project duidelijk dat er een nieuwe website van Magnus in ontwikkeling is. Om die reden wordt de applicatie niet in de huidige website maar in die nieuwe website geïntegreerd. Het is daarom niet mogelijk om een link in dit verslag te zetten waarin de applicatie te zien is. Om die reden is in Bijlage F “De applicatie in beeld” op pagina 73 de gebruikerskant van de applicatie aan de hand van screenshots te zien.
6.1.1 Het Mendix datamodel Zoals in het vorige hoofdstuk28 al geschreven is, is de basis van een Mendix applicatie het datamodel. Dit datamodel heeft veel weg van een ERD datamodel echter bevat een Mendix datamodel meer relaties tussen de entiteiten. Dit is noodzakelijk om bepaalde functies binnen de applicatie werkend te krijgen. Mendix zet dit datamodel vervolgens om naar een relationele database, in dit geval een SQL database. In Bijlage G “Het datamodel uitgelegd” op pagina 77 wordt een onderdeel van het datamodel uitgelicht.
6.1.2 Functies binnen de applicatie De meest belangrijke functies van de applicatie komen voort uit de eerder opgestelde functionele eisen29. In deze fase van het project is de applicatie veelvuldig besproken en geëvalueerd door de projectgroep. Iedere keer wanneer er een nieuwe functionaliteit was toegevoegd werd deze getoond en met behulp van de kwaliteitscirkel van Deming 30 eventueel verbeterd. Nieuwe ideeën, of functionaliteiten, die ontstonden in tijdens deze bijeenkomsten werden genoteerd en kregen volgens het MoSCoW 31 principe een prioriteit toegekend om te waarborgen dat het project binnen de gestelde looptijd klaar is. De techniek van de rekenmodellen zijn in verschillende functies van de applicatie verwerkt. Om ervoor te zorgen dat de offertes per e-mail worden verstuurd naar de gebruiker is er gebruik gemaakt van een door Mendix zelf gebouwde e-mail module. De 25 26 27 28 29 30 31
Zie Zie Zie Zie Zie Zie Zie
hoofdstuk 2.3 “Project ontwikkelingsmethodiek” op pagina 20 hoofdstuk 5.3 “Het gebruikersscenario uitgewerkt” op pagina 43 hoofdstuk 5.3.1 “Niet functionele prototypes” op pagina 43 hoofdstuk 5.4.1 “Mendix Business modeler” op pagina 52 Tabel 7 op pagina 45 Figuur 12 op pagina 44 hoofdstuk 2.3 “Project ontwikkelingsmethodiek” op pagina 20
Jordy van der Meij
Pagina 51 van 79
Afstudeerverslag module bevat enkel de e-mailfunctionaliteit welke ik aangepast en gekoppeld heb aan de applicatie. Tevens bevat de applicatie enkele controlefuncties waarbij de invoer, in de invoervelden van applicatie32, van de gebruiker wordt gecontroleerd of deze juist is. Wanneer dit niet het geval is krijgt de gebruiker een duidelijke melding te zien betreffende de foutieve invoer.
6.1.3 De vormgeving De applicatie die in Mendix wordt gebouwd wordt uiteindelijk gegeneerd naar .HTML bestanden waardoor de applicatie in een CSS CSS (Cascading Style Sheets) zijn webomgeving te gebruiken is. De opmaak een mogelijkheid om de van deze .HTML bestanden wordt bepaald vormgeving van webpagina’s los te door een .CSS bestand. Dit heeft als koppelen van hun feitelijke inhoud belangrijk voordeel dat de opmaak voor de en centraal vast te leggen. gehele applicatie vanuit één bestand te (Wikipedia, CSS, 2011) regelen is. Wanneer Magnus er bijvoorbeeld voor kiest om haar huisstijl aan te passen, kan de opmaak van de applicatie vanuit dit .CSS bestand aangepast worden naar bijvoorbeeld de nieuwe kleuren van de huisstijl. De tekstuele inhoud van de applicatie valt onder de verantwoordelijkheid van Magnus. Dit betekent dat alle teksten die zijn weergegeven in de applicatie door henzelf zijn aangeleverd. Op de offerte die de gebruiker ontvangt gelden bepaalde voorwaarden. Deze voorwaarden zijn opgesteld door de Sales afdeling van Magnus. Zowel de tekstuele inhoud als de offerte voorwaarden vallen buiten de verantwoordelijkheid van de projectontwikkelaar (Jordy van der Meij).
6.2 Implementatie en testen Zoals in de projectdoelstellingen staat vermeld zal de applicatie worden geïntegreerd in de website van Magnus. Op het moment van schrijven is dit nog niet gerealiseerd omdat men bezig is met het realiseren van een nieuwe website. Met dit in het achterhoofd zal de applicatie zo kaal mogelijk worden geleverd. Hiermee wordt bedoeld dat de applicatie qua kleuren en het uiterlijk zo neutraal mogelijk is. Op die manier kan de applicatie in de toekomst simpel en snel worden aangepast naar de het uiterlijk van de nieuwe website. Wel zal de applicatie in een productieomgeving komen te staan, dit houdt in dat de applicatie van buitenaf te bereiken, en dus te gebruiken, is. De laatste stap, de integratie in de Magnus website, zal buiten de looptijd van dit project gebeuren.
6.2.1 Ontwikkel en productieomgeving Er zullen twee omgevingen worden opgezet voor de applicatie. De eerste omgeving zal een ontwikkelomgeving zijn, de tweede een productieomgeving. De ontwikkelomgeving van de applicatie is een omgeving die enkel intern door Magnus kan worden bereikt. Op deze omgeving kunnen bijvoorbeeld nieuwe functionaliteiten van de applicatie worden ontwikkeld en getest. Wanneer de functionaliteiten dusdanig goed getest zijn kunnen 32
Zie hoofdstuk 5.3.1 “Niet functionele prototypes” op pagina 44
Jordy van der Meij
Pagina 52 van 79
Afstudeerverslag deze worden over gezet naar de productieomgeving zodat de eindgebruiker van de applicatie deze nieuwe functionaliteiten kan gebruiken. Op de productieomgeving komt de applicatie voor de buitenwereld te draaien, de applicatie is dan te bereiken door te surfen naar een bepaald internetadres. Op de website van Magnus zal er een link beschikbaar komen naar dit internetadres. De applicatie kan in dat geval binnen de website worden gebruikt. Op het moment van schrijven staat de applicatie nog niet in een productieomgeving. Om een Mendix applicatie op een productiesysteem te draaien zal er gebruik moeten worden gemaakt van de Mendix Windows Service. Dit programma zorgt ervoor dat de applicatie wordt gestart en te gebruiken is. Binnen dit programma dienen er een aantal instellingen te worden gedaan. De belangrijkste hiervan is de koppeling naar een database, waarin alle data wordt opgeslagen van de applicatie (denk hierbij aan de aangevraagde offertes en applicatie-instellingen). Binnen Magnus is er een database beschikbaar waar de applicatie gebruik van kan maken. De invulling van de database (bijvoorbeeld het aanmaken van de tabellen) wordt vervolgens door de Mendix Windows Service afgehandeld.
6.2.2 Testen Het testen van de applicatie is tijdens het gehele project gebeurd, dit is één van de voordelen van de DSDM projectontwikkelingmethodiek33. Voordat de applicatie op een productieomgeving gaat draaien is men (de projectgroep) er dus zeker van dat de applicatie, inclusief alle functionaliteiten, werken zoals is afgesproken tijdens het project.
6.3 Het beheer van de applicatie Het beheer van de applicatie wordt onderverdeeld in functioneel beheer en technisch beheer. Het technisch beheer is verantwoordelijk voor het in de lucht houden van de applicatie. De applicatie zal worden gedraaid op een systeem waarvoor de IT afdeling van Magnus verantwoordelijk is, hieronder valt onder andere het backuppen van de applicatie data. Het functioneel beheer is verantwoordelijk voor alle functionele onderdelen van de applicatie. Denk hierbij aan het onderhouden van de keuzemogelijkheden die de gebruiker te zien krijgt tijdens het gebruik van de applicatie. De functionele beheerders zullen de managers zijn van de afdeling SAP Basis Techniek 34 van Magnus.
6.3.1 De backend De backend van de applicatie wordt met name gebruikt door de functionele beheerders van de applicatie. Dit onderdeel van de applicatie is enkel te benaderen door het ingeven van de juiste gebruikersnaam en wachtwoord combinatie. Vanuit de backend van de applicatie is het mogelijk om: Offertes in te zien en te downloaden in .DocX formaat Nieuwe systeemtypes toevoegen (bijvoorbeeld een nieuw SAP ERP systeem wanneer deze door SAP AG wordt geïntroduceerd). 33 34
Zie hoofdstuk 2.3 “Project ontwikkelingsmethodiek” op pagina 20 Zie Bijlage A: “Het organogram” op pagina 66
Jordy van der Meij
Pagina 53 van 79
Afstudeerverslag Nieuwe Support Package Stack versies toevoegen Nieuwe Enhancement Pack versies toevoegen Parameters van de rekenmodellen aanpassen Alle wijzigingen die op dit gebied worden gedaan zullen direct zichtbaar voor de eindgebruiker van de applicatie. Voorbeeld: wanneer er een nieuwe Support Package Stack versie voor een SAP ERP ECC 6.0 wordt toegevoegd, kan de gebruiker deze direct selecteren om naar toe te upgraden. Wanneer het blijkt dat de offertes die worden gegenereerd qua uren niet meer in lijn liggen met de realiteit is het mogelijk om de parameters van het desbetreffende rekenmodel aan te passen. Op die manier kan de uitvoer van de offerte worden beïnvloed. Voorbeeld (op basis van fictieve informatie): De applicatie genereert een offerte voor een SAP ERP ECC 6.0 Support Package Stack upgrade. In de offerte is terug te zien dat de upgrade 100 uur in beslag neemt, waarvan 10 uur wordt besteedt aan voorbereidingshandelingen. In het verleden is echter gebleken dat de voorbereidingshandelingen maar 2 uur duren in plaats van 10. Vanuit de backend kan de functioneel beheerder de parameter “Voorbereidingshandelingen” aanpassen van 10, naar 2. De volgende offerte voor dit upgradetype zal dan de nieuwe waarde van de parameter hanteren.
6.3.2 Aanpassingen op de applicatie Zoals eerder geschreven is zal er ontwikkelomgeving worden opgezet voor de applicatie35. Deze omgeving staat los van de productieomgeving, maar hij bevat wel een kopie van de data van de productieomgeving om op die manier de productieomgeving na te bootsen. Aanpassingen die worden gedaan op de ontwikkelomgeving hebben op geen enkele wijze invloed op het gebruik van de applicatie voor de eindgebruiker. Op het moment dat men nieuwe functionaliteiten wilt toevoegen aan de applicatie, of huidige functionaliteiten wilt aanpassen of verbeteren, zal dit in eerst worden gerealiseerd op deze ontwikkelomgeving. Fouten die voortkomen uit de aanpassing op de applicatie kunnen op deze manier worden opgelost zonder dat de eindgebruiker hiervan hinder ondervindt. Wanneer de aanpassing op de applicatie ontwikkeld en uitvoerig getest is kan deze vervolgens geïmplementeerd worden op de productieomgeving waardoor deze voor de eindgebruiker zichtbaar wordt.
35
Zie hoofdstuk 6.2.1 “Ontwikkel en productieomgeving” op pagina 58
Jordy van der Meij
Pagina 54 van 79
Afstudeerverslag
7
REFLECTIE OP DE WERKZAAMHEDEN EN LEERDOELEN
Voorafgaand dit project heb ik mijzelf een aantal leerdoelen en competenties gesteld 36. Terugkijkend op de afgelopen periode heb ik ontzettend veel geleerd en heb ik in mijn ogen bewezen aan deze competenties te voldoen. Het bewijs hiervan is de uiteindelijke applicatie die is ontwikkeld. Doordat tijdens de ontwikkeling van de applicatie er veel controle momenten waren, waarin de applicatie getoond werd, weet ik dat de uiteindelijke versie van de applicatie voldoet aan de eisen en wensen van Magnus. De conclusie die daaruit kan worden getrokken is dat ik aan de eerder opgestelde competenties37 op een kwalitatief acceptabel niveau voldoe. Het project heb ik gevolgd volgens de DSDM projectontwikkelingmethodiek met behulp van een planning. Het project is binnen de looptijd afgerond en daarmee toon ik aan dat ik dat leerdoel heb behaald. Hoewel de planning in het begin erg specifiek was opgesteld, ging dit in de loop der tijd steeds meer richting een mijlpaalplanning waarin enkel de belangrijkste onderdelen vermeld stonden. Dit is zo ontstaan omdat de werksfeer erg prettig was. Beide partijen (ik en Magnus) hadden een goede, informele en serieuze, werkrelatie met elkaar en dat leidde ertoe dat er veel vertrouwen tussen elkaar is ontstaan. Dit vertrouwen heb ik bevestigd door het project op een kwalitatief afgesproken niveau binnen de gestelde looptijd af te ronden. Daarbij heb ik de belangen van de partijen binnen de projectgroep in mijn ogen in juiste banen geleidt. Dit heb ik kunnen doen door de verschillende theorieën en werkwijzen toe te passen die eerder in dit verslag aan bod zijn gekomen. Het bewijs hiervan is ook weer het uiteindelijke kwaliteitsniveau van de applicatie. Tevens heb ik door dit project een inzicht gekregen in SAP beheer projecten. Naast het analyseren van SAP projecten uit het verleden van Magnus heb ik veel met SAP consultants kunnen praten over de wereld van SAP. Hierdoor heb ik een goed beeld voor mijzelf kunnen schetsen hoe het er aan toe gaat in deze tak van het bedrijfsleven. De SAP wereld heeft mij nog meer aangetrokken in vergelijking tot de periode voorafgaan dit project. Naast de voorafgestelde leerdoelen en competenties heb ik nog iets geleerd wat vooraf niet was opgesteld. Dit was de ontwikkeling van de uiteindelijke applicatie in de ontwikkelomgeving Mendix. Ik heb in een zeer kort tijdsbestek geleerd hoe ik een kwalitatief goede applicatie kan ontwikkelen binnen Mendix. Dit heb ik gedaan door veel dingen zelf te proberen en uit te testen. Daarnaast heb ik ook gebruik gemaakt van de kennis van Mendix die binnen Magnus aanwezig is. Deze mensen hebben mij op het vlak van applicatieontwikkeling naar een hoger niveau getild.
36 37
Zie hoofdstuk 1.3 “Vooraf gestelde competenties en leerdoelen” op pagina 13 Zie hoofdstuk 1.3 “Vooraf gestelde competenties en leerdoelen” op pagina 13
Jordy van der Meij
Pagina 55 van 79
Afstudeerverslag
VERKLARENDE WOORDENLIJST BPMN:
Business Process Modelling Notation; procesmodellering.
een standaard voor
CRM:
Customer Relationship Management; een werkwijze waarbij het optimaliseren van klantcontacten centraal staat.
CSS:
Cascading Style Sheets; een mogelijkheid om de vormgeving van websites los te koppelen van de inhoud. De opmaak wordt vanuit één centraal bestand (.CSS bestand) vastgelegd.
DSDM:
Dynamic Systems Development Method; methodiek.
een projectontwikkeling
Data Warehouse: Een grote verzameling van gegevens. Deze gegevens worden op een bepaalde manier opgeslagen zodat gegevensverwerking efficiënt kan gebeuren. EHP:
Enhancement Pack; Update voor SAP systeem die zorgt voor nieuwe en verbeterde functionaliteit
Entiteit:
Entiteiten maken onderdeel uit van een datamodel, voor een database. Een entiteit kan worden gezien als een object. Iets dat bestaat. Tussen entiteiten kunnen er relaties bestaan. Voorbeeld: Er zijn twee entiteiten; “Auto” en “Eigenaar”. Een “Eigenaar” kan meerdere “Auto’s” hebben (dit is een relatie). En; Een “Auto” heeft maar één “Eigenaar” (dit is ook tweede relatie).
ERD:
Entity Relationship Diagram; Een diagram voor het grafisch weergeven van een conceptueel datamodel (database). Het geeft een visuele weergave tussen entiteiten, relaties en beperkingen.
ERP:
Enterprise Resource Planning; software dat wordt gebruikt ter ondersteuning van bedrijfsprocessen.
Microsoft.NET
Een ontwikkelomgeving van Microsoft voor (web)applicaties.
MoSCoW:
Een wijze van prioritering uit de DSDM projectmethodiek. De betekenis van de letters MSCW zijn als volgt: M = Must have (Functie moet gerealiseerd worden) S = Should have (Functie zou gerealiseerd moeten worden, anders work-around verzinnen) C = Could have (Functie kan gerealiseerd worden als er tijd genoeg is) W = Won’t have (Functie hoeft niet in dit project gerealiseerd te worden)
PaaS:
Platform as a Service;
Het leveren van een platform (infrastructuur) via het internet zonder daarvoor extra producten te moeten installeren.
Jordy van der Meij
Pagina 56 van 79
Afstudeerverslag PHP:
PHP Hypertext Preprocessor; een scripttaal die bedoeld is om dynamische webpagina’s te creëren.
SAP:
In de volksmond een verzamelnaam voor alle bedrijfssoftware oplossingen die SAP AG levert. Voorbeelden hiervan zijn SAP ERP, SAP Business Warehouse en SAP Business Objects.
SAP AG:
Duits softwarehuis dat marktleider is op het gebied van ERP, CRM en SCM pakketten. De letters SAP staan voor “Systeme, Anwendungen und Produkte in der Datenverarbeitung (Systemen, Applicaties en Producten in gegevensverwerking”).
SAP BW:
SAP Business Warehouse is de naam van de Business Intelligence, analytische, verslaglegging en Data Warehouse oplossing van SAP.
SAP BO:
SAP Business Objects is de naam van de software oplossing van SAP waarmee het mogelijk is om dashboards te creëren met daarin een dynamische weergave van grafieken en tabellen waar data in staat. Dit kan worden verwerkt in bijvoorbeeld een online portal.
SAP ERP:
SAP Enterprise Resource Planning; De meest bekende software oplossing van SAP. Dit pakket ondersteund alle essentiële bedrijfsprocessen en activiteiten van een onderneming. Het pakket is volledig toegespitst op algemene en branchespecifieke behoeften.
SAP Notes
Problemen die bekend zijn bij SAP AG, die voortkomen na het upgrades van een SAP systeem. Vaak worden deze SAP Notes ook voorzien van een oplossing.
SCM:
Supply Chain Management; integraal ketenbeheer. Het afstemmen van processen, technieken en producten tussen bedrijven in de keten.
SPS:
Support Package Stack; update voor SAP system dat juridische en wet / regelgeving aanpast op het system.
UML:
Unified Modeling Language; een modelmatige taal om objectgeoriënteerde analyses en ontwerpen te maken voor een informatiesysteem (bijvoorbeeld een database).
Jordy van der Meij
Pagina 57 van 79
Afstudeerverslag
BRONNENLIJST BPMN. (2011). Opgehaald van http://www.bpmn.org/ DSDM Handboek. (2011). Opgehaald van http://intra.iam.hva.nl/content/0708/propedeuse/ontwikkelmethoden_en_technieken//in tro-en-materiaal/DSDM.pdf Fowler, M., & Scott, K. (2000). UML beknopt. Pearson Education. Magnus.nl. (2011). Opgehaald van Magnus.nl: http://www.magnus.nl Mendix. (2011). Opgehaald van http://www.mendix.com/ Microsoft.NET. (2011). Opgehaald van http://www.microsoft.com/net PHP. (2011). Opgehaald van http://www.php.net/ SAP Community Network. (2011). Opgehaald van http://www.sdn.sap.com/irj/sdn/upgradetech SAP Nederland. (2011). Opgehaald van SAP Nederland: http://www.sap.com/netherlands/index.epx Schenk, D., Draijer, C., & Caris, A. (2008). De praktijk van mySAP en IDES. Wolters Noordhoff. Sumner, M. (2007). Enterprise Resource Planning. Pearson Education. Wikipedia. (2011). CSS. Opgehaald van Wikipedia: http://nl.wikipedia.org/wiki/Cascading_Style_Sheets Wikipedia. (2011). Data Warehouse. Opgehaald van Wikipedia: http://en.wikipedia.org/wiki/Data_warehouse Wikipedia. (2011). DSDM. Opgehaald van Wikipedia: http://en.wikipedia.org/wiki/DSDM Wikipedia. (2011). ERP. Opgehaald van Wikipedia: http://en.wikipedia.org/wiki/Enterprise_resource_planning Wikipedia. (2011). Kwaliteitscirkel van Deming. Opgehaald van Wikipedia: http://en.wikipedia.org/wiki/Deming_circle Wikipedia. (2011). SAP AG. Opgehaald van Wikipedia: http://en.wikipedia.org/wiki/SAP_AG
Jordy van der Meij
Pagina 58 van 79
Afstudeerverslag
Bijlage A: “Het organogram”
Magnus
Marketing & Sales
Portfolio Management
Delivery Management
Finance & Office
BPM
PM/EA
PCC
Advanced Technology and Development
BI
Financial Management
PLM / EA
Sales & Logistics
SAP Techniek
Managed Services
Jordy van der Meij
Pagina 59 van 79
Afstudeerverslag
Bijlage B: “Prototype schermen in een vroeg stadium” Eerste prototype
Figuur 14 Een niet functioneel prototype van de applicatie in vroeg stadium
Gebruikersscenario 1. Gebruiker surft naar de website van Magnus. 2. Gebruiker klikt op de link in het menu van de offerte applicatie. 3. Gebruiker kiest het systeem type uit een lijst waarop hij de upgrade wilt toepassen. 4. Gebruiker kiest het upgrade type uit een lijst, welke hij wilt toepassen op het gekozen systeem. 5. Gebruiker kiest de huidige en gewenste softwareniveaus uit een lijst. 6. Gebruiker kiest het aantal systemen uit een lijst waarop hij de upgrade wilt toepassen. 7. Gebruiker kan informatie opvragen over het desbetreffende invoerveld wanneer hij op het “i” icoon klikt. Een pop-up zal dan tevoorschijn komen. 8. Gebruiker voert e-mailadres in, in dit geval zijn @Magnus.nl e-mailadres 9. Gebruiker drukt op “Bereken offerte”. 10. Gebruiker ontvangt offerte per e-mail a. Indien @Magnus.nl e-mailadres; gebruiker krijgt de offerte in DocX formaat b. Indien anders: gebruiker krijgt de offerte in PDF formaat Uitzonderingen: 9 b. Wanneer één van de velden niet, of niet correct, is ingevoerd wordt er een melding weergegeven onder het desbetreffende veld. Gebruiker gaat weer terug naar stap 8.
Jordy van der Meij
Pagina 60 van 79
Afstudeerverslag
Tweede prototype
Figuur 15 Een niet functioneel prototype van de applicatie in vroeg stadium
1. Gebruiker surft naar de website van Magnus. 2. Gebruiker klikt op de link in het menu van de offerte applicatie. 3. Gebruiker kiest het systeem type uit een lijst waarop hij de upgrade wilt toepassen. 4. Gebruiker kiest het upgrade type uit een lijst, welke hij wilt toepassen op het gekozen systeem. 5. Gebruiker kiest de huidige en gewenste softwareniveaus uit een lijst. 6. Gebruiker kiest het aantal systemen uit een lijst waarop hij de upgrade wilt toepassen. 7. Gebruiker kan informatie opvragen over het desbetreffende invoerveld wanneer hij op het “i” icoon klikt. Een pop-up zal dan tevoorschijn komen. 8. Gebruiker voert e-mailadres in, in dit geval zijn @Magnus.nl e-mailadres 9. Gebruiker kan in veld “Opmerkingen” informatie of extra vragen kwijt omtrent de offerte aanvraag. 10. Gebruiker kan er voor kiezen om een telefoonnummer achter te laten wanneer hij wilt dat Magnus contact met hem opneemt omtrent de offerte aanvraag. 11. Gebruiker drukt op “Bereken offerte”. 12. Gebruiker ontvangt offerte per e-mail
Jordy van der Meij
Pagina 61 van 79
Afstudeerverslag a. Indien @Magnus.nl e-mailadres; gebruiker krijgt de offerte in DocX formaat b. Indien anders: gebruiker krijgt de offerte in PDF formaat Uitzonderingen: 11. Wanneer één van de velden niet, of niet correct, is ingevoerd wordt er een melding weergegeven onder het desbetreffende veld. Gebruiker gaat weer terug naar stap 11.
De offerte die de klant ontvangt kan er als volgt uitzien.
Figuur 16 De offerte die gegenereerd wordt. Dit betreft een onderdeel uit een niet functioneel prototype van de applicatie in vroeg stadium.
Jordy van der Meij
Pagina 62 van 79
Afstudeerverslag
Bijlage C “Vragenlijst van het behoefte onderzoek”
Jordy van der Meij
Pagina 63 van 79
Afstudeerverslag
Bijlage D “Het niet functionele prototype uitgewerkt” 1. 2. -
3. 4.
5. 6.
Gebruiker surft naar de website van Magnus. Gebruiker klikt op de link in het menu van de offerte applicatie. Gebruiker kiest het upgrade type (Figuur 17 op pagina 64). Gebruiker kiest het SAP systeem type uit een lijst, waar hij de gekozen upgrade op wilt laten uitvoeren (Figuur 18 op pagina 65). Gebruiker kiest de huidige en gewenste softwareniveaus uit een lijst. (Figuur 19 op pagina 65). Gebruiker kiest het aantal systemen uit een lijst waarop hij de upgrade wilt toepassen. Tevens is, afhankelijk van het upgrade type, de mogelijkheid om extra upgrademogelijkheden te kiezen (Figuur 20 op pagina 66). Gebruiker voert e-mailadres in, in dit geval zijn @Magnus.nl e-mailadres (Figuur 21 op pagina 66) Gebruiker kan er voor kiezen om een telefoonnummer achter te laten wanneer hij wilt dat Magnus contact met hem opneemt omtrent de offerte aanvraag (Figuur 21 op pagina 66). Gebruiker drukt op “Bereken offerte” (Figuur 21 op pagina 66). Het systeem controleert of het e-mailadres a. Indien @Magnus.nl e-mailadres; offerte wordt in DocX gegenereerd. b. Indien anders: offerte wordt in .PDF gegenereerd. De offerte wordt verstuurd per e-mail naar het ingevoerde e-mailadres. De gebruiker ontvangt offerte per e-mail
Uitzonderingen: 3. Wanneer één van de velden niet, of niet correct, is ingevoerd wordt er een melding weergegeven onder het desbetreffende veld.
Figuur 17 Beginscherm van de applicatie
Jordy van der Meij
Pagina 64 van 79
Afstudeerverslag
Figuur 18 Systeemkeuze waar de gebruiker de upgrade op wilt uitvoeren.
Figuur 19 Versiekeuze
Jordy van der Meij
Pagina 65 van 79
Afstudeerverslag
Figuur 20 Keuze voor extra upgrade mogelijkheden
Figuur 21 Contactgegevens invoeren
Jordy van der Meij
Pagina 66 van 79
Afstudeerverslag
Bijlage E: “Mendix; een korte tutorial” Deze korte tutorial is bedoeld om te laten zien hoe een applicatie in Mendix gebouwd wordt. De tutorial wordt ondersteund door tekst en afbeeldingen. Deze tutorial is door mijzelf gemaakt maar is echter wel gebaseerd op één van de tutorials die Mendix zelf aanbiedt op haar website38. Deze versie is bevat enkel minder functionaliteit. In deze tutorial wil ik door middel van een simpele applicatie laten zien hoe Mendix verschilt ten opzichte van programmeertalen, daar ligt namelijk precies de kracht van Mendix. Computerbedrijf XYZ maakt gebruik van een systeem om orders in bij te houden. De volgende bedrijfsregels zijn actief: Een klant mag meerdere orders hebben Een order mag bestaan uit meerdere producten Sommige orders worden meteen geleverd aan de klant, en sommige niet. Het datamodel De eerste stap in het ontwikkelen van de applicatie is om het datamodel te creëren. Een datamodel geeft de verschillende entiteiten aan en haar onderlinge relaties. Het datamodel van deze applicatie ziet er als volgt uit:
Figuur 22 Datamodel
Relaties Order customer: OrderLine_Order: OrderLine_Product: 38
Uitleg één klant mag meerdere orders hebben één order heeft meerdere OrderLines één product wordt geassocieerd met meerdere orderLines
https://world.mendix.com/pages/releaseview.action?pageId=7110995
Jordy van der Meij
Pagina 67 van 79
Afstudeerverslag
Nu het datamodel bekend kan Mendix met een simpele handeling de formulieren genereren om de objecten van de entiteiten aan te maken. De schermen voor de entiteit “Customer” ziet er dan als volgt uit.
Figuur 23 Het aanmaken van een nieuwe klant
Figuur 24 Een overzicht van alle klanten
Ditzelfde geldt voor de entiteit “Product”. Hierin kunnen op dezelfde wijze producten worden aangemaakt. Echter heeft deze entiteit nog een extra veld, namelijk “Price” waarin de prijs van het product vermeld staat. In de onderstaande afbeelding is een overzicht te zien van alle objecten “Product”.
Figuur 25 Overzicht van alle producten
Een order plaatsen Een klant (dhr. van Wijk) neemt contact op met het computerbedrijf XYZ omdat hij een order wilt plaatsen. De klant wilt graag de volgende order plaatsen, welke nog niet geleverd hoeft te worden: Computer Beeldscherm Muis Toetsenbord USB stick Jordy van der Meij
1x 2x 1x 2x 3x Pagina 68 van 79
Afstudeerverslag De medewerker van het computerbedrijf opent de applicatie en kiest als eerst de klant uit een dropdown menu. De keuze die het dropdown menu laat zien zijn alle objecten uit de entiteit “Customer”.
Figuur 26 Klant van de order selecteren
Vervolgens voert hij de producten van de order in. De selectie die gezien wordt bij “Product” zijn alle objecten uit de entiteit “Product”.
Figuur 27 Producten aan de order toekennen
Jordy van der Meij
Pagina 69 van 79
Afstudeerverslag De onderstaande afbeelding geeft de volledige order weer.
Figuur 28 Overzicht van één order
Vervolgens kan er een overzicht worden opgevraagd om alle orders te laten weergeven.
Figuur 29 Overzicht van alle orders
De techniek erachter Zoals eerder geschreven is in deze tutorial maakt genereert Mendix alle formulieren zelf. Alle gegevens die in de database worden geplaatst zijn functies die al in de formulieren zitten. Men hoeft dus geen handmatige connectie met de database te maken om vervolgens met behulp van SQL queries de data er in te stoppen of uit te lezen. Wat in deze tutorial niet automatisch gaat is bijvoorbeeld het optellen van de totaal prijs van de order. In een programmeertaal zal je hiervoor data moeten uitlezen uit de database waarmee je vervolgens een berekening maakt. Daarna moet er een connectie met de database worden gemaakt om het veld “TotalPrice” van het object “Order” te updaten naar een nieuwe waarde, de totaalprijs. In Mendix gaat dit ook op die manier alleen vele malen makkelijker, dit heet in Mendix een “microflow”.
Wanneer er een nieuw object “Order” wordt aangemaakt, (als de order wordt opgeslagen), wordt de volgende microflow aangeroepen. De begint bij de groene cirkel (“Start Point”) en eindigt bij de rode cirkel (“End point”). De invoerparameter is het object “OrderLine”.
Jordy van der Meij
Pagina 70 van 79
Afstudeerverslag
Figuur 30 Een functie van de applicatie, ook wel microflow genoemd.
Stap 1 Hierin wordt het object “Order” opgevraagd uit de database welke behoord tot de invoerparameter “OrderLine”. Dit gebeurt aan de hand van de relatie tussen Order en OrderLine (zie datamodel). Stap 2 In deze stap wordt de gehele orderLine opgehaald die bij het object “Order” uit stap 1 hoort. Deze OrderLine bevat alle producten van de desbetreffende order. Stap 3
Figuur 31 Functie “optellen” binnen een Mendix applicatie
In deze stap worden alle “TotalAmount” bedragen van de “OrderLines” bij elkaar opgeteld. Bijvoorbeeld: Product Computer Beeldscherm
prijs 150 100
aantal 1x 2x
totaalprijs 150 200
Het totaal is dan 350. Refererend naar de bovenstaande afbeelding. Eerst wordt de invoervariabele gekozen, dit is de in stap 2 opgehaalde lijst van alle “OrderLines”. Bij “Function” wordt “Sum” gekozen omdat alle attributen (in figuur “Attributes”) van “TotalAmount” bij elkaar opgeteld moeten worden. De uitkomst van deze som wordt opgeslagen in de variabele “TotalOfOrderLines”.
Jordy van der Meij
Pagina 71 van 79
Afstudeerverslag Stap 4
Figuur 32 De waarde van een attribuut van een object aanpassen
In deze stap wordt het desbetreffende object “Order” opgeroepen vanuit de database. Dit is te zien onder het kopje “Input” waar als input variabele het object “Order” wordt geselecteerd. Vervolgens staat er onder het kopje “Action” dat het attribuut (“Member” in de afbeelding) “TotalPrice van het object moet worden gewijzigd (de activiteit heet namelijk ook “Change Object”). De waarde van dit attribuut is de uit stap 3 berekende “TotalOfOrderLines”. Dit ziet men terug onder het kopje “Value”. Na het lezen deze tutorial moet het enigszins duidelijk zijn hoe Mendix werkt. Het belangrijkste wat hieruit moet worden geconcludeerd is dat Mendix werkt met activiteiten om bepaalde handelingen gedaan te krijgen. Dit in tegenstelling tot een programmeertaal waarbij de handelingen geprogrammeerd moeten worden aan de hand van een bepaalde scripttaal. Dat is iets wat veel meer tijd in beslag neemt en waar de kans op fouten groter is.
Jordy van der Meij
Pagina 72 van 79
Afstudeerverslag
Bijlage F “De applicatie in beeld” In deze bijlage ziet men de applicatie uitgebeeld in afbeeldingen, de afbeeldingen zijn screenshots van de werkende applicatie. Er wordt laten zien hoe een gebruiker een offerte aanvraagt voor een SAP ERP release upgrade. Sommige teksten die voorkomen in de afbeeldingen zijn nog niet bijgewerkt op het moment van schrijven. Hieronder valt onder andere de opmaak van de gegenereerde offerte. De applicatie is op het moment van schrijven nog niet geïmplementeerd in de website van Magnus, vandaar dat de afbeeldingen enkel de inhoud van de applicatie tonen en niet van de website eromheen.
De gebruiker kan een keuze maken uit de verschillende upgrade types.
Er is gekozen voor een “Release upgrade”. De gebruiker ziet nu een lijst van systeemtypes waar de upgrade op kan worden uitgevoerd. Er wordt gekozen voor een SAP ERP 5.0 upgrade. Jordy van der Meij
Pagina 73 van 79
Afstudeerverslag
De gebruiker ziet nu een lijst van naar welke versie hij kan upgraden. In dit geval kan de gebruiker zijn SAP ERP 5.0 systeem enkel upgraden naar een SAP ERP 6.0 systeem.
De gebruiker krijgt nu enkele extra upgrade mogelijkheden te zien. In dit geval kiezen we voor zowel een Enhancement Pack upgrade en Support Package Stack upgrade in het Release upgrade traject. Tevens kiezen we ervoor om dit te doen op 3 systemen (DEV, Jordy van der Meij
Pagina 74 van 79
Afstudeerverslag QAS en Productie). We willen dat de upgrade op locatie wordt uitgevoerd en niet gedeeltelijk op afstand.
De gebruiker vult vervolgens zijn gegevens in (gegevens zijn hier gefingeerd).
De gebruiker krijgt het eindscherm te zien, de offerte is in een .PDF bestand naar het ingevoerde e-mailadres gestuurd. Een kopie van de offerte aanvraag is tevens verstuurd naar een e-mailadres van Magnus.
Jordy van der Meij
Pagina 75 van 79
Afstudeerverslag
De offerte is toegevoegd in de bijlage van de gestuurde e-mail. Bovenstaande afbeelding bevat een gedeelte uit deze bijlage. De opmaak hiervan is op het moment van schrijven nog onder voorbehoud. De teksten en dergelijke zullen nog worden aangepast door Magnus. De persoonlijke gegevens in deze afbeelding zijn gefingeerd.
Jordy van der Meij
Pagina 76 van 79
Afstudeerverslag
Bijlage G “Het datamodel uitgelegd” In deze bijlage zal er een gedeelte van het datamodel worden uitgelegd. Één van de belangrijkste onderdelen van de applicatie is het kiezen van een upgradetype (Enhancement Pack upgrade, Support Package Stack upgrade of een Release upgrade) waar een offerte voor moet worden gemaakt. Een belangrijk onderdeel hiervan is het bepalen op welk systeem de upgrade moet worden uitgevoerd en wat de huidige en gewenste softwareniveaus zijn. Het datamodel voor dit onderdeel is weergegeven in de onderstaande afbeelding, Figuur 30.
Figuur 33 Onderdeel van het datamodel dat betrekking heeft tot de upgradetypes en de daarbij behorende specificaties.
In dit onderdeel van het datamodel zijn er drie entiteiten gedefinieerd, welke onderling ook een relatie met elkaar hebben: SystemType UpgradeType Version Relaties: Één “SystemType” object is geassocieerd met meerdere “Version” objecten. Één “UpgradeType” object is geassocieerd met meerdere “SystemType” objecten. Één “UpgradeType” object is geassocieerd met meerdere “Version” objecten. Entiteit SystemType De entiteit SystemType bevat alle informatie omtrent een systeemtype. Deze entiteit bevat drie attributen. SystemType: Dit attribuut is van het type “Enumeration” en geeft het systeemtype aan. Bij het aanmaken van een object van de entiteit SystemType is de waarde voor dit attribuut vooraf gedefinieerd aan de hand van een lijst (vandaar dat het attribuuttype “Enumeration” is). Dit vooraf gedefinieerde waarde van dit veld zijn in dit geval de systeem types die onder de projectscope vallen (SAP ERP, SAP BW, SAP BO en Database). Dit attribuut is verplicht.
Jordy van der Meij
Pagina 77 van 79
Afstudeerverslag SystemTypeVersion: Dit attribuut is van het type “String” en geeft de versie van het SystemType aan. Dit attribuut is verplicht. IntroductionDate: Dit attribuut is van het type “Date” en geeft de introductiedatum van de betreffende versie aan. Dit attribuut is optioneel.
Entiteit UpgradeType De entiteit UpgradeType bevat de upgradetypen die gedaan kunnen worden. Deze entiteit bevat één attribuut. UpgradeType: Dit attribuut is van het type “Enumeration”. De waarde voor dit attribuut is vooraf gedefinieerd aan de hand van een lijst (vandaar dat het attribuuttype “Enumeration” is). Dit attribuut is verplicht. Entiteit Version De entiteit Version bevat de versies die gekoppeld zijn aan een bepaald SystemType. Deze entiteit bevat 3 attributen. Number: Dit attribuut is van het type “Integer” en geeft de softwareversie aan. Dit attribuut is verplicht. IntroductionDate: Dit attribuut is van het type “Date” en geeft de introductiedatum van de software versie aan. Dit attribuut is verplicht. NumberDate: Dit attribuut wordt niet uitgelegd omdat dit niets toevoegt aan dit onderdeel van het verslag. Als er een object wordt aangemaakt voor de entiteit “SystemType” ziet dit eruit zoals weergegeven is in Figuur 34.
Figuur 34 Screenshot uit backend van de applicatie voor het aanmaken van een systeem type.
Achter “Systeem” wordt de versie van het systeem ingevoerd (welke wordt opgeslagen in de attribuut “SystemTypeVersion” van de entiteit “SystemType”). Achter “SystemType” wordt het systeem type ingevoerd (welke wordt opgeslagen in het attribuut “SystemType” van de entiteit “SystemType”). Ook wordt er het upgrade type aangegeven, welke voortkomt uit de relatie “SystemType_UpgradeType” die staat weergegeven in het datamodel (zie Figuur 33 op pagina 77). Als er nu op “Save” wordt gedrukt betekent het dat het mogelijk is om in de applicatie een offerte aan te vragen voor een Support Package Stack upgrade op een SAP R/3 4.6 systeem. Wat er nu enkel nog moet gebeuren is het aanmaken van de Support Package Stack versies voor een Jordy van der Meij
Pagina 78 van 79
Afstudeerverslag SAP R/3 4.6 systeem. Zoals in hoofdstuk 2.2 “De upgradetechniek van SAP systemen” op pagina 16 staat beschreven heeft ieder Support Package Stack namelijk een bepaalde versie. Het aanmaken van een Support Package Stack versie gaat zoals weergegeven is in Figuur 35, zie onderstaande afbeelding.
Figuur 35 Screenshot uit de backend van de applicatie voor het aanmaken van versies
Achter “Upgrade Type” wordt het upgradetype geselecteerd waarvoor een versie aangemaakt moet worden, de lijst van keuzemogelijkheden komt voort uit de relatie “Version_upgradetype” van het datamodel (zie Figuur 33 op pagina 77). Achter “Systeem” wordt er een keuze lijst getoond voor welke systeemversie de upgradeversie moet worden aangemaakt. Omdat er in Figuur 34, op pagina 78, een “Support Package Stack Upgrade” voor een “SAP R/3 4.6” systeem is aangemaakt, komt deze nu voor in de lijst van keuzemogelijkheden. Bij het veld “Number” wordt het versienummer ingevoerd en bij “Introduction Date” de introductie datum van de softwareversie. Wanneer er bijvoorbeeld voor een Support Package Stack versie 1, 2 en 3 zijn aangemaakt voor een SAP R/3 4.6 systeem betekent dit, dat bij het gebruik van de applicatie de gebruiker bij het ingeven van de softwareniveaus (zie Figuur 19 op pagina 65), een keuze heeft uit de aangemaakte softwareniveaus (in dit geval dus 1, 2 en 3). Op deze manier kunnen er ook softwareniveaus voor Enhancement Pack upgrades worden aangemaakt voor de systeem types.
Jordy van der Meij
Pagina 79 van 79
