Afstudeerverslag Project budget bewaking en urenregistratie in Sage CRM

Afstudeerverslag Project budget bewaking en urenregistratie in Sage CRM

Erik Vleugel (20010492) 11-01-2006

Referaat Opsomming van begrippen die betrekking hebben op dit verslag: •

Customer Relationship Management (CRM)

•

Sage CRM

•

Professional Services Dienstverleners

•

Projecten

•

Urenregistratie

•

Web-based

•

ASP

•

IAD

2

Voorwoord Ter afsluiting van de opleiding Informatica & Informatiekunde heb ik gedurende 18 weken een project uitgevoerd in opdracht van CBS Solutions B.V. Hierbij ben ik bekend geraakt met het web-based CRM pakket Sage CRM en heb in dit pakket een project uren bewaking module en urenregistratiemodule ontwikkeld. Tijdens de afstudeerperiode heb ik veel hulp gehad van verschillende personen. Deze personen wil ik graag van harte bedanken voor hun ondersteuning dat het mogelijk heeft gemaakt om dit project tot een goed einde te brengen: Edwin Quarles van Ufford Perry Meertens Peter Verheij Arno Nederend Kees de Jong Verder wil ik alle collega’s bij CBS Solutions B.V. bedanken voor de goede samenwerking en gezelligheid!

Erik Vleugel Sliedrecht, 11-1-2006

3

Inhoudsopgave 1. Inleiding ................................................................................................................................. 5 2. Opdracht ................................................................................................................................. 6 2.1 Opdrachtgever (CBS Solutions B.V.) .............................................................................. 6 2.2 Opdracht ........................................................................................................................... 7 2.3 Uitgangssituatie................................................................................................................ 9 3. Ontwikkelmethode ............................................................................................................... 10 4. Definitiestudie ...................................................................................................................... 12 4.1 Ontwikkelscenario.......................................................................................................... 14 4.2 Systeemeisen en systeemconcept ................................................................................... 15 4.3 Pilotplan ......................................................................................................................... 23 5. Pilot 1: Stamgegevens (medewerkergegevens en projectsjablonen).................................... 26 5.1 Reikwijdte ...................................................................................................................... 27 5.2 Ontwerp.......................................................................................................................... 28 5.3 Bouw .............................................................................................................................. 30 5.4 Test ................................................................................................................................. 33 5.5 Evaluatie......................................................................................................................... 34 6. Pilot 2: Project Budget Bewaking ........................................................................................ 35 6.1 Reikwijdte ...................................................................................................................... 36 6.2 Ontwerp.......................................................................................................................... 38 6.3 Bouw .............................................................................................................................. 41 6.4 Test ................................................................................................................................. 44 6.5 Evaluatie......................................................................................................................... 46 7. Pilot 3 en 4: Urenregistratie (binnen en buiten Sage CRM) ................................................ 47 7.1 Reikwijdte ...................................................................................................................... 48 7.2 Ontwerp.......................................................................................................................... 49 7.3 Bouw .............................................................................................................................. 51 7.4 Test ................................................................................. Error! Bookmark not defined. 7.5 Evaluatie......................................................................... Error! Bookmark not defined. 8. Evaluatie............................................................................................................................... 53 8.1 Het product..................................................................................................................... 53 8.2 Het proces....................................................................................................................... 53 Bijlage A: Begrippenlijst.......................................................................................................... 54 Bijlage B: Projectdocumentatie................................................................................................ 56 Bijlage C: Sage CRM............................................................................................................. 110

4

1. Inleiding In de 18 weken van de afstudeerperiode heb ik een module (toevoeging) op de bestaande Sage CRM applicatie ontwikkeld. Deze module is gericht op zogenaamde ‘Professional Services Dienstverleners’ in het MKB segment. Hoofdmoot in de module is de mogelijkheid tot het bewaken van projectbudgets, het boeken van uren door projectmedewerkers en het factureren van deze uren en eventuele andere projectkosten. Dit verslag zal het gehele traject, van opdrachtomschrijving tot oplevering van het product, van de afstudeeropdracht beschrijven. Het doel hiervan is om d.m.v. tekst en illustraties de uitgevoerde werkzaamheden en de daarbij gemaakte afwegingen en beslissingen in kaart te brengen. Het is in eerste instantie bedoeld voor de afstudeerexaminatoren ter beoordeling van de werkzaamheden, maar ook voor allen die geïnteresseerd zijn in de aanpak van een CRM-project. Het verslag is grofweg in chronologische volgorde opgebouwd. Bekenden met de IAD ontwikkelmethode zullen de werkwijze herkennen in de inhoudsopgave. Per onderdeel worden de belangrijkste werkzaamheden, keuzes en overwegingen beschreven om zodoende tot een beeld te komen van de werkzaamheden die ik tijdens de afstudeerperiode heb uitgevoerd.

5

2. Opdracht In dit hoofdstuk wordt een korte schets gegeven van het bedrijf waar ik werkzaam ben geweest, waarna de probleemstelling en de daarbij horende doelstelling van de opdracht worden verwoord. Als laatste zal worden uitgelegd hoe de opdrachtomschrijving en Plan van Aanpak tot stand zijn gekomen. Het volledige Plan van Aanpak is te vinden in Bijlage B.

2.1 Opdrachtgever (CBS Solutions B.V.) Missie: “Met hoogwaardige CRM systemen organisaties helpen meer klantgericht te worden en daarmee toegevoegde waarde te creëren voor de klant en zelfs de klanten van de klant.” CBS Solutions B.V. (CBS) levert CRM systemen voor middelgrote bedrijven (voornamelijk sales, marketing, support en service organisaties). Standaard CRM-oplossingen voor middelgrote bedrijven betekenen een aanpassing van de bedrijfsprocessen aan de applicatie. Door de omvang van deze bedrijven is dit niet wenselijk. Ook beschikken deze bedrijven niet over het budget voor volledig maatwerk. Er moet dus worden gezocht naar een basisoplossing die met beperkte inspanningen aan de eigen bedrijfsprocessen kan worden aangepast. De pakketten die door CBS geleverd worden (SalesLogix, Sage CRM en Microsoft CRM) hebben de mogelijkheid om dit voor elkaar te krijgen. Naast het leveren van CRM systemen verzorgt CBS ook het in kaart brengen van de bedrijfsprocessen, het inventariseren van de functionele behoeften en het scannen van de markt voor de juiste oplossing. CBS ondersteunt ook de organisatorische implementatie van CRM. Onder implementatie wordt hier verstaan: - Het aanpassen van de applicatie aan de bedrijfspecifieke situatie - Opleiden van de eindgebruikers en management in het gebruik van de applicatie - Trainen van beheerders zodat men zelfstandig de applicatie kan beheren en aanpassen - Het geven van ondersteuning na de oplevering - Het continue meehelpen met het verbeteren van het systeem CBS bestaat op het moment uit 15 medewerkers opgedeeld in de volgende afdelingen: - Management Team (2) - Project Bureau / Administratie (2) - Sales & Marketing (2) - Business Consultancy (2) - Projecten (6) - Customer Service (1) Ik ben werkzaam geweest op de afdeling Projecten. Deze afdeling bestaat uit werknemers die zorg dragen voor de technische kant van de producten, maar ook het ondersteunen van de implementatie (on-site support) en het geven van trainingen aan systeembeheerders en eindgebruikers.

6

2.2 Opdracht CRM oplossingen voor het MKB draaien meestal uit op veel maatwerk, wat voor veel bedrijven te duur is. Om toch deze grote markt te kunnen bedienen (de Nederlandse ondernemingen bestaan voor 99% uit MKB) verkoopt CBS basispakketten waarbij veel minder maatwerk is vereist om CRM te implementeren. Het probleem is echter dat het MKB een erg brede markt is met veel verschillende typen organisaties, die allemaal andere wensen van een CRM systeem hebben. Door deze markt op te splitsen in branches (verticals) en hiervoor basispakketten te ontwikkelen en verkopen probeert CBS het MKB van CRM systemen te voorzien.

MKB

Verticals

Professional Services Dienstverleners

Detailhandel

Etc.

Figuur: schematische weergave van de volledige markt en de opdeling in branches (verticals)

CBS wil zich richten op de ‘Professional Services Dienstverleners’ branche. Het web-based CRM programma Sage CRM is hiervoor de beste keuze, omdat veel werknemers in deze branche buiten de deur werken (denk aan consultants e.d.). De opdracht is het ontwikkelen van een module die binnen het Sage CRM pakket werkt waarin de volgende functionaliteiten aanwezig zijn: - Project budget bewaking; het invoeren van projectinformatie en – werkzaamheden, het toewijzen van medewerkers aan projecten en het daarbij horende budget. - Urenregistratie; het invoeren van gewerkte uren door medewerkers aan een project zodat deze vergeleken kunnen worden met de eerder gemaakte toewijzingen. - Facturering; de mogelijkheid tot factureren van projecturen en andere kosten Het standaard Sage CRM pakket mist deze functionaliteit. Al deze nieuwe functionaliteit dient beschreven te worden in een addendum op de handleiding van het Sage CRM pakket. Deze module moet het mogelijk maken om met zo min mogelijk maatwerk een passend CRM systeem aan een bedrijf in de betreffende branche te leveren.

7

Uitgaande van een projectdoorlooptijd van 18 weken tussen 5 september 2005 en 12 januari 2006 en IAD als de gebruikte ontwikkelmethode (zie ook hoofdstuk 3) is de volgende globale planning met mijlpaalproducten gedefinieerd in het Plan van Aanpak: Fase 1: Orientatie / Analyse - 5 dagen Fase 2: Definitiestudie (15 dagen) - Ontwikkelscenario – 4 dagen - Systeemeisen – 2 dagen - Systeemconcept – 3 dagen - Technische structuur – 1 dag - Organisatorische Inrichting – 1 dag - Pilotplan – 4 dagen Fase 3: Pilotontwikkeling (50 dagen) - Plan van Aanpak – 3 dagen - Pilotontwerp-workshop – 2 dagen - Specificatie globale functionele en technische structuur – 5 dagen - Pilotontwikkelplan – 5 dagen - Ontwerp software-bouweenheden – 15 dagen - Bouw software-bouweenheden – 15 dagen - Documenteren software-bouweenheden (handleiding, opleidingsmateriaal en invoeringsprocedures) – 3 dagen - Test software-bouweenheden – 2 dagen Fase 4: Overdracht – 5 dagen Met oog op de doorlooptijd is bij het definiëren van de opdracht besloten om het factureringsgedeelte als ‘luxe’ te beschouwen en deze pas dient te worden ontwikkeld wanneer de project budget bewaking en urenregistratie naar tevredenheid zijn ontwikkeld. Product(en) Plan van Aanpak Definitiestudie Stamgegevens binnen Sage CRM Project budget bewaking binnen Sage CRM Urenregistratie van projecten binnen Sage CRM Facturering projecten Documentatie

Afleverdatum Dinsdag 13 september Vrijdag 21 oktober Woensdag 9 november Woensdag 30 november Vrijdag 21 december Woensdag 30 december Vrijdag 6 januari

Het volledige Plan van Aanpak met daarin de opdrachtomschrijving is te vinden in Bijlage B.

8

2.3 Uitgangssituatie Bij aanvang van het project waren de volgende zaken aanwezig: - Sage CRM installatiepakket - Sage CRM documentatie - Marktanalyserapport - Ideeën van betrokken werknemers Dit betekent dat het project van de grond af op moest worden gebouwd. Waar de aanwezige ideeën verwoord moesten worden, maar ook een ontwikkelomgeving worden ingericht die het mogelijk maakt deze ideeën uit te werken. Tevens had ik wel verstand van web-based ontwikkelen, maar had totaal geen ervaring met het Sage CRM pakket. Binnen CBS waren er wel twee personen die al wel gewerkt hadden met Sage CRM en zodoende de student konden helpen met eventuele vraagstukken.

9

3. Ontwikkelmethode De keuze van de te gebruiken ontwikkelmethode ligt aan de basis van het verder uit te voeren werk. Bij het definiëren van de opdrachtomschrijving en Plan van Aanpak moest deze keuze dan al gemaakt worden aan de hand van de informatie en kennis die op dat moment aanwezig waren. Bij het maken van deze keuze moesten de volgende overwegingen worden gemaakt: -

wat voor soort project is het (aanpassen bestaand systeem of nieuw systeem, systeem voor intern gebruik of extern gebruik, lopend project, etc.)? De projectsoort heeft een grote invloed op de keuze van de ontwikkelmethode. Als het om een nieuw systeem gaat wordt de ontwikkelcyclus geheel doorlopen, maar bij een bestaand systeem zal er meestal maar een deel van deze cyclus worden doorlopen. Voor elk van deze situaties bestaan er verschillende ontwikkelmethodes. In dit project werden er modules toegevoegd aan een bestaand systeem dat niet door de opdrachtgever ontwikkeld wordt. Het ontwikkelproces zou geheel worden doorlopen, van ontwerp tot oplevering. Het feit dat modules moesten worden ontwikkeld gaf al aan dat het systeem in delen zou worden ontwikkeld. Het product is bedoeld voor zowel intern als extern gebruik.

-

in wat voor technische omgeving wordt het systeem ontwikkeld? Hierbij moet worden gedacht aan ontwikkelmethodes die bijvoorbeeld gespecialiseerd zijn voor objectgeoriënteerde technische omgevingen in het algemeen of specifiek gedefinieerd zijn voor een bepaalde technische omgeving. Het project zou in de huidige systeemomgeving worden ontwikkeld met daarbij een deel objectgeoriënteerd en een deel niet objectgeoriënteerd. Voor de ontwikkelomgeving bestaan geen speciale ontwikkelmethodes en het was niet bekend welke ontwikkelmethode is gebruikt in het totstandkomen van de omgeving.

-

wat is de verwachte inbreng van interne en externe personen? De verwachte mate van inbreng van (eind)gebruikers is bij het kiezen van een ontwikkelmethode het overwegen waard. Sommige ontwikkelmethodes zijn opgebouwd om met veel inbreng te werken, terwijl andere met weinig inbreng werken. Het product was aan het begin van het project nog niet aan klanten verkocht. De verwachte inbreng was dus voornamelijk intern. Er werd wel veel inbreng verwacht.

10

-

zijn er bedrijfsstandaarden waaraan de student zich moet houden? Als de opdrachtgever een bepaalde ontwikkelstandaard hanteert is de keuze snel gemaakt. CBS gebruikt een eigen ontwikkelmethode, die helaas niet conform de eisen aan het afstudeerproject is.

-

werkt de student alleen of in een projectgroep? De grootte van het projectteam heeft invloed op de keuze van ontwikkelmethode. Er zijn bijvoorbeeld methodes die bedoelt zijn voor twee of meerdere projectleden. De bedoeling was dat de student alleen, naast de inbreng van de betrokken medewerkers, aan het project zou werken.

-

wat is de aanwezige kennis van de student? De aanwezige kennis van de uitvoerende(n) van het project kan een grote invloed hebben op de keuze van ontwikkelmethode. Het gebruiken van een bekende methode betekent minder tijd om te ‘wennen’ aan de methode en informatie erover vinden. De student was bekend, door projecten tijdens zijn opleiding, met de traditionele ontwikkelmethode (watervalmodel) en de ontwikkelmethode IAD.

Watervalmodel:

IAD:

Met deze gegevens heb ik gekozen voor de IAD methode, dit in overleg met de stagebegeleider en de bedrijfsmentor. Het feit dat ik bekend ben met de IAD ontwikkelmethode en de opdracht voor deze methode geschikt is (modulaire opbouw, veel inbreng (eind)gebruikers) hebben in deze keuze het meeste invloed gehad.

11

4. Definitiestudie Volgens de IAD ontwikkelmethode moet, na het opstellen van de initiële opdrachtomschrijving en plan van aanpak, de definitiestudie van het project worden geschreven. In de definitiestudie worden de doelen en beperkingen van het systeem geanalyseerd. De werkzaamheden tijdens deze fase bestaan uit: - overeenstemming bereiken van het te volgen ontwikkelscenario - bepalen en prioriteren van systeemeisen - opstellen van een globaal systeemconcept - technische- en organisatie-aspecten analyseren die met de systeemeisen en het systeemconcept verband houden - onderverdelen van het systeemconcept in delen (pilots) - definiëren van een pilotplan - plannen van de volgende fase De belangrijkste punten – waar veel werk mee gemoeid was of een belangrijke beslissing werd vereist – zullen in dit hoofdstuk worden beschreven. Dit zijn het totstandkomen van de systeemeisen, systeemconcept en het pilotplan. In deze periode van vier weken werden drie workshops met de twee betrokken functionarissen gepland. Al vanaf de eerste interviews aangaande de systeemeisen is het daar gemaakte entiteitenmodel een significant model geweest aangaande het bepalen van de systeemeisen, het systeemconcept en het pilotplan. Aangezien Sage CRM met entiteiten (tabellen) werkt kan dit model in principe één op één worden ontwikkeld in Sage CRM. Het gebruikte entiteitenmodel is een afgeslankte versie van de bekende EER- en klassendiagrammen. Er wordt bijvoorbeeld geen onderscheid gemaakt in zwakke of sterke entiteiten of 0 – n / 1 – n relaties.

Figuur: voorbeeld van het gebruikte entiteitenmodel. Hierin zijn twee 1 - n relaties te zien. De kant met het ‘harkje’ is de n kant.

De input bij de gehouden workshops was een concept van het entiteitenmodel en met eventueel per entiteit de vereiste velden. Tijdens de workshops werd dit concept besproken, en eventuele veranderingen aangetekend, die bij de opvolgende workshop weer werden besproken tot het model naar tevredenheid van alle verantwoordelijken was. Om het proces van totstandkoming van de definitiestudie te illustreren geef ik in de komende paragrafen de verschillende concepten van het entiteitenmodel die als input en resultaat van een workshop dienden. De workshops die in dit verslag veelvuldig genoemd zullen worden waren de afstempunten met de opdrachtgever. Bij deze workshops waren naast ikzelf ook Edwin Quarles en Perry Meertens aanwezig. Input van deze workshops was altijd een concept die uiterlijk de dag voor de workshop beschikbaar was om te bekijken. De workshops bestonden uit discussies en brainstormsessies. Deze workshops hebben geleid tot een goede controle van de kwaliteit van het systeem naar de opdrachtgever toe.

12

13

4.1 Ontwikkelscenario Het doel van het ontwikkelscenario is het vaststellen van de reikwijdte en context van het project en ervoor te zorgen dat de iteratieve ontwikkelstrategie op de juiste wijze gebruikt wordt. De belangrijkste keuze die tijdens deze activiteit moest worden gemaakt is de te volgen iteratiestrategie. Dit bepaalt de werkwijze voor de rest van de projecttijd. IAD onderscheid vier verschillende iteratiestrategieën. Om een goede keuze te kunnen maken moeten de projectkenmerken worden vergeleken met die van de vier iteratiestrategieën. Voor het project kunnen de volgende kenmerken worden genoemd: - klein informatiesysteem - kleine, stabiele projectomgeving - systeemeisen zijn bekend - intern project, wat veel betrokkenheid van (eind)gebruikers kan betekenen - web-based ontwikkeling (gemakkelijke invoering) - geen specifieke haast gemoeid met het project Als deze kenmerken in een tabel worden uitgezet tegen de vier iteratiestrategieën is dit het resultaat: Evolutionair ontwikkelen Klein informatiesysteem Kleine, stabiele projectomgeving Bekende systeemeisen Veel betrokkenheid Web-based (gemakkelijke invoering) Geen specifieke haast

++ = erg goed

-++ + + = goed

Incrementeel opleveren

+ + ++ + leeg = neutraal

Incrementeel ontwikkelen

Big-bang invoeren

+

+

++ -

+

- = slecht

- - = erg slecht

Uit deze tabel blijkt dat de iteratiestrategie ‘incrementeel opleveren’ voor dit project de beste keuze is geweest. Belangrijkste punten zijn de systeemeisen die bij de opdrachtgever bekend waren, de kleine schaal van het systeem en de projectomgeving en het feit dat het systeem web-based zou worden wat de invoeringsfase gemakkelijk zou maken.

14

4.2 Systeemeisen en systeemconcept Het doel van deze activiteiten is het opstellen van de globale systeemeisen en het systeemconcept waaruit het pilotplan kan worden opgesteld. Deze dienen ook als basis voor de verdere pilotontwikkeling waarin deze verder worden gedetailleerd en uiteindelijk gebouwd en geïmplementeerd. Bij de uitvoering van deze activiteiten is veel inbreng van de opdrachtgever vereist. Binnen CBS waren er drie mensen verantwoordelijk voor de functionele specificatie van het project waarvan er twee tijdens het gehele project begeleiding gaven. Om de systeemeisen duidelijk en op één lijn te krijgen werd eerst iedere verantwoordelijke geïnterviewd. Uitgangspunt van deze interviews was de opdrachtomschrijving van het project en de opgedane kennis van de student in de ontwikkelomgeving van Sage CRM. Uitkomst van deze interviews waren drie lijsten met systeemeisen die niet helemaal gelijk waren of elkaar zelfs tegenspraken. Doel was om zo veel mogelijk ideeën op papier te krijgen. Om het geheel op één lijn te krijgen is er een workshop georganiseerd met de twee hoofdverantwoordelijken. Daarin werd de lijst met systeemeisen die uit de interviews was voortgekomen als uitgangspunt gebruikt. Uitkomst was een voorlopige lijst met globale systeemeisen en een globaal systeemconcept (entiteitenmodel) welke nogmaals onder de loep werden genomen in een tweetal workshops met dezelfde personen een week later. Op de volgende pagina’s zijn de verschillende concepten van het entiteitenmodel te vinden. De ontwikkeling van dit model a.d.h.v. de workshops is zo duidelijk te zien. In het entiteitenmodel is er een splitsing te zien tussen ‘stamgegevens’ entiteiten en ‘functionele’ entiteiten. Met stamgegevens worden hier basisgegevens van de organisatie, die met Sage CRM gaat werken, bedoeld. Dit zijn de werknemerinformatie, functies binnen de organisatie, kostencodes die gebruikt worden bij declaraties en standaard projectsjablonen die later gebruikt kunnen worden bij het aanmaken van projecten. Met functionele entiteiten worden de entiteiten bedoeld die het hart van de module zijn; project budget bewaking, urenregistratie en facturering.

15

Eerste concept

Cost_code

Activity

Function

Tariff

Phase

Employee

Projecttype

Prj_Members

Contact

Project

Prj_Phase

Prj_Assignment

Person

Opportunity Prj_Activity

Detaillering projectactiviteiten Product

Weekstate

Ws_rule

Purchase_rule

Weeks

Bestaand Stamgegevens Functioneel

Figuur: eerste concept entiteitenmodel n.a.v. initiële interviews. Dit model is als input gebruikt voor de eerste workshop.

16

Tweede concept

Cost_code

Activity

Function

Tariff

Phase

ProjectCost

Employee

Projecttype

Project ContactPerson

ProjectMember Project

CalendarEntry Person

Coupon

ProjectPhase

ProjectProduct

Project Assignment

ProjectActivity

Detaillering projectactiviteiten Opportunity

Weekstate

WeekstateLine

Week

Declaration

Product


PurchaseLine

Figuur: tweede concept n.a.v. de eerste workshop. Deze werd als input gebruikt voor de tweede workshop.

17

Uiteindelijke model

Cost_code

ActivityTemplate

Functions

PhaseTemplate

Tariff

Employee

ProjectCost

ProjectTemplate

ProjectMember

Project ContactPerson Project ProjectPhase

CalendarEntry

Person

ProjectActivity

Project Task

ProjectProduct Company Project WeekstateLine

PurchaseLine

Weekstate General WeekstateLine

Opportunity

Product

Week

Invoice

Project Declaration

InvoiceLine General Declaration

Bestaand Stamgegevens Functioneel Figuur: uiteindelijke versie van het entiteitenmodel dat gedurende de rest van het project is gebruikt.

18

Al bij de eerste workshop werd de manier waarop projecten zouden worden uitgewerkt overeengekomen: een project bestaat uit fases, per fase worden een aantal activiteiten uitgevoerd. Een projectmedewerker wordt aan een activiteit gekoppeld, dit is een taaktoewijzing. Ook moest de mogelijkheid om standaardprojecten of projectsjablonen in het systeem te maken bestaan. Als een nieuw project wordt aangemaakt kan één van deze sjablonen worden gekozen waarmee gelijk de fases en activiteiten uit dit sjabloon worden gekopieerd naar het nieuwe project.

Aangaande het entiteitenmodel waren de belangrijkste discussiepunten: -

hoe worden de weekstaten en declaraties uitgevoerd?

Zoals te zien is in bovenstaande figuren is het stuk waarin de weekstaten en declaraties zich bevinden veel veranderd. Er was al snel overeengekomen om medewerkers op takenniveau (projectassignment / projecttask) hun uren te laten verantwoorden. Dit in de gebruikelijke constructie van een weekstaat die ook daadwerkelijk voor één week(nummer) geldt. Hierbij was ook al tijdens één van de interviews besloten om een aparte week-entiteit in te voeren. Niet overal ter wereld worden de weeknummers van een jaar gelijk aangewezen. In Europa begint week 1 van het jaar over het algemeen op de eerste maandag in Januari. Elders kunnen andere regels gelden, zoals dat de week op zondag begint in plaats van maandag. Om tegemoet te komen met deze verschillende ‘weeknummerdefinities’ kan de beheerder van het Sage CRM systeem zelf bepalen wanneer week 1 begint en het systeem moet dan automatisch de overige weeknummers uitrekenen welke worden opgeslagen in de week-entiteit. Aanvankelijk werden de uitvoering van weekstaten en declaraties simpel gehouden. Later, in de laatste workshop, bleek dat men toch liever een onderscheid wilde hebben tussen projecturen (die op de klant kunnen worden verhaald) en algemene uren (zoals administratie, cursus, vakantie, etc.). Hetzelfde gold voor de declaraties; een onderscheid werd gemaakt tussen projectdeclaraties (reiskosten, lunchkosten, etc.) en algemene declaraties (aanschaf leerboeken, werkmateriaal, etc.). Dit ook met oog op het facturatie deel.

19

-

hoe worden de facturen opgeslagen?

De facturatie van projecten is pas in de laatste workshop uitgebreid besproken. Facturatie geschied volgens vaste prijs of nacalculatie. Bij vaste prijs wordt van tevoren een vaste prijs voor het project afgesproken. Bij nacalculatie bestaat de factuur aan een klant uit drie delen: uren, declaraties en inkoop van producten. Ook is een combinatie van de twee mogelijk waarin bijvoorbeeld de producten voor een vaste prijs worden berekend en de gewerkte uren op basis van nacalculatie. In de realiteit wordt deze laatste manier van factureren het meest gebruikt. Om dit mogelijk te maken zal op projecten activiteitniveau de keuze tot vaste prijs of nacalculatie moeten worden gegeven. Hetzelfde geldt voor de productkosten die bij een project horen. Om de nacalculatie van productkosten te registreren worden per product een aantal inkoopregels bijgehouden. Zo kunnen delen van een product dat in een project wordt gebruikt (bv.: licenties, cursussen, hard- en software, etc.) volgens nacalculatie en andere met een vaste prijs worden berekend. Uren, declaraties en producten worden allemaal één voor één of in delen gefactureerd waaruit een volledige factuur volgt. -

hoe staan de nieuwe entiteiten in verbinding met de bestaande entiteiten van Sage CRM?

Het te maken systeem is een toevoeging op een bestaand systeem. Logisch is dan ook dat er een koppeling met de bestaande functionaliteit is. In het entiteitenmodel staan dan ook een paar entiteiten van het bestaande systeem. De koppeling met het bestaande systeem is alleen rond het projectentiteit van toepassing. In eerste instantie werden projecten alleen aan ‘opportunities’ gekoppeld – uit een verkochte opportunity kwam een project voort. Echter bleek dat een project niet altijd uit een verkochte opportunity voortkomt. Voorbeeld hiervan zijn interne projecten. Daarom werd de koppeling met de opportunity entiteit optioneel gemaakt.

Interview

Concept

Concept

Product

Interview

Workshop

Workshop

Interview

Figuur: schematische weergave van het proces dat geleid heeft tot het uiteindelijke entiteitenmodel

20

Andere belangrijke discussiepunten tijdens de workshops: -

welke functionaliteit binnen Sage CRM worden hergebruikt en welke moeten er bij worden ontwikkeld? Als er nieuw wordt ontwikkeld wat is dan de meerwaarde?

Een goed voorbeeld hiervan is de eis dat de medewerkers van het bedrijf waar het systeem wordt geïnstalleerd worden geregistreerd in het systeem. Sage CRM maakt gebruik van autorisatie om in te kunnen loggen d.m.v. een inlognaam/wachtwoord combinatie. Dit zijn de gebruikers van het systeem. Voor elke gebruiker moet een licentie worden gekocht bij Sage. De enige medewerkers die geregistreerd worden en daadwerkelijk veel functionaliteit van het Sage CRM pakket zullen gebruiken zijn de (project)managers en medewerkers van de financiële afdeling. Het gros van de medewerkers maakt alleen gebruik van het systeem bij het registreren van gewerkte uren. Het was dus niet wenselijk deze medewerkers als gebruikers in Sage CRM te registreren, daar dit te duur zou worden voor de geleverde functionaliteit. In Sage CRM wordt klantinformatie (organisatiegegevens) opgeslagen, per organisatie kunnen een aantal personen worden geregistreerd. Een tweede optie om de eigen medewerkers te registreren binnen het systeem was dus het aanmaken van een organisatie genaamd ‘intern’ en de medewerkers als personen te koppelen aan deze organisatie. Het probleem hiermee was dat de bestaande functionaliteit m.b.t. personen niet toereikend was voor de nieuwe systeemeisen. Het toevoegen van functionaliteit bij de personen was niet goed mogelijk door de wijze waarop het bestaande systeem in elkaar zat. De laatste optie was het zelf ontwikkelen van de functionaliteit om medewerkergegevens te registreren. Voordeel hiervan is dat men niet afhankelijk zou zijn van beperkingen van de bestaande functionaliteit en er later eventueel andere gegevens van medewerkers kunnen worden toegevoegd. Nadeel was het feit dat het ontwikkelen waarschijnlijk meer tijd in beslag zou nemen. Uiteindelijk is gekozen voor de laatste optie, vooral omdat men dan volledig vrij is in het ontwikkelen van de functionaliteit en deze op een later moment gemakkelijk verder uitgebreid kan worden (denk aan het registreren van CV’s, opleidingen die de medewerker heeft doorlopen, eventuele targets van de medewerker voor het komende jaar, etc.). -

wat is de afbakening van het systeem? Wat wordt wel en wat wordt niet ontwikkeld?

De grootste discussie over de afbakening van het systeem ging over de keuze om, wel of niet, een planningsmodule toe te voegen. Het systeem moet het mogelijk maken projecten te definiëren die bestaan uit fases en activiteiten. Medewerkers moeten aan deze activiteiten worden toegewezen. Een mogelijkheid ontstaat dan om deze taken daadwerkelijk te plannen. Medewerkers zouden dan volgens de planning van het systeem moeten gaan werken. Een groot voordeel is dat er meer werkzaamheden binnen het systeem mogelijk zijn – centralisatie van gegevens en werkwijzen. Nadeel is dat het ontwikkelen van deze planningsmodule een hoop tijd in beslag zou nemen. Met oog op de tijd die de student heeft voor het afstudeerproject en het feit dat een planningsmodule er later altijd bij kan worden ontwikkeld is besloten om planning geen deel van het systeem te maken.

21

-

hoe moet de urenregistratie functionaliteit in het systeem worden uitgevoerd?

Belangrijk deel van de opdracht, na het definiëren en controleren van projecten en het budget daarvan, is de mogelijkheid voor projectmedewerkers om de gewerkte uren te registreren – het invoeren van weekstaten. Dit maakt een verdere controle van de projecten mogelijk als deze geregistreerde uren worden vergeleken met de geplande uren. Aangezien er eerder is besloten om medewerkergegevens apart te registreren, zodat voor deze mensen geen licentie hoeft te worden betaald, vervalt de optie om urenregistratie in het Sage CRM pakket te ontwikkelen. Tweede optie is het ontwikkelen van een externe website die in verbinding staat met de dezelfde database als Sage CRM. Deze optie wordt aantrekkelijker vanwege het feit dat Sage CRM het mogelijk maakt een dergelijke website te koppelen aan Sage CRM zodat deze gebruik kan maken van functionaliteit die ook in Sage CRM beschikbaar is. Als laatste kan de keuze worden gemaakt om een koppeling te maken met het huidige urenregistratiepakket en de Sage CRM database. Dit idee werd al gauw afgewezen, omdat dit enorm veel werk met zich mee zou brengen, laat staan of dit daadwerkelijk mogelijk zou zijn. Verder moet het systeem niet alleen intern worden gebruikt, maar wil men dit ook verkopen aan klanten. Klanten die waarschijnlijk een ander urenregistratiepakket gebruiken. Besloten is om de tweede optie verder uit te werken.

Na de laatste workshop was een systeemconcept aanwezig in de vorm van het entiteitenmodel en een lijst van globale systeemeisen. Deze dienden als invoer voor het te maken pilotplan, waarvan het proces in het volgende hoofdstuk wordt beschreven.

22

4.3 Pilotplan De laatste werkzaamheid met betrekking tot de definitiestudie is het opstellen van het pilotplan die als basis dient voor de pilotontwikkeling die volgt op de definitiestudie. In het pilotplan worden de systeemeisen geclusterd in pilots waarna deze pilots worden geprioriteerd en gestructureerd (volgorde van ontwikkeling). In dit hoofdstuk zal ik beschrijven hoe de definitie van de pilots tot stand is gekomen. Wederom kies ik om dit (deels) uit te beelden d.m.v. het entiteitenmodel. In de laatste workshop waarin de laatste hand werd gelegd aan het systeemconcept werd gelijk al een eerste splitsing van deze in pilots besproken. Uit de opdrachtomschrijving kan al een opdeling in de totale functionaliteit worden onderscheiden, namelijk: project budget bewaking, urenregistratie en facturering van dezen. Dit leidt tot de volgende drie delen uit het entiteitenmodel:

Project budget bewaking:

23

Urenregistratie: Project Task Weekstate

Project WeekstateLine

Week General WeekstateLine

Facturatie / declaratie: Project WeekstateLine PurchaseLine

Weekstate

Project Declaration

Invoice


Duidelijk mag zijn dat het project budget bewaking deel wel erg groot zou zijn zo. Daarom werd besloten dit deel te splitsen in 2 pilots. In de eerste pilot zouden de ‘stamgegevens’ worden ontwikkeld. Deze zou een kernel pilot kunnen worden genoemd, omdat alle volgende functionaliteit van deze informatie gebruik maken. Nog een voordeel is dat deze pilot nog niet zo complex zou zijn, wat een mooie kans bood om mezelf beter bekend te maken met het Sage CRM pakket. Het urenregistratie gedeelte bestaat naast de entiteiten in Sage CRM ook een externe website waarin medewerkers hun weekstaten kunnen invullen. Besloten werd om dit verschil uit te beelden door een aparte pilot voor de website te definiëren. Met oog op de tijd die er voor de afstudeerstage is werd besloten om het factureringsgedeelte als ‘luxe’ te definiëren. Dat wil zeggen dat de delen project budget bewaking en urenregistratie volledig af moeten zijn voor er aan het factureringsgedeelte zou worden begonnen.

24

De volgende pilots zijn gedefinieerd: Pilot 1 Pilot 2 Pilot 3 Pilot 4 Pilot 5

Medewerkergegevens en projectsjablonen (stamgegevens) Project budget bewaking Registreren en onderhouden weekstaten in Sage CRM Registreren van gewerkte uren d.m.v. een externe site in verbinding met Sage CRM Facturering van projecten en gewerkte uren

Uit deze verdeling werd besloten tot de volgende pilotstructurering:

Zoals te zien is werden pilot 3 en 4 parallel ontwikkeld, dit omdat ze beiden afhankelijk zijn van elkaar, maar in een verschillende omgeving (Sage CRM t.o.v. externe website) werden ontwikkeld.

Pilot 1

Pilot 2 Pilot 3

Pilot 4 Pilot 5

25

06-01-2006

30-12-2005

23-12-2005

16-12-2005

09-12-2005

02-12-2005

25-11-2005

18-11-2005

11-11-2005

04-11-2005

28-10-2005

21-10-2005

Als laatste werd aan de hand van deze structurering en de globale systeemeisen een globale planning opgesteld:

5. Pilot 1: Stamgegevens (medewerkergegevens en projectsjablonen) Deze eerste pilot werd direct na de acceptatie en afronding van de definitiestudie opgestart. Doel was het ontwikkelen van de zogenaamde stamgegevens voor de volgende pilots in Sage CRM. Met stamgegevens worden niet alleen de medewerkergegevens en de projectsjablonen bedoelt, maar ook de functies die binnen het bedrijf worden ingevuld zodat deze aan medewerkers kunnen worden gekoppeld en de kostencodes die gebruikt worden door de organisatie bij het maken van projectdeclaraties. De functionaliteit die in deze pilot werd ontwikkeld was niet zo complex als die in de opvolgende pilots. Dit had een reden, namelijk het feit dat ik geen ervaring met het Sage CRM pakket had en hier eerst bekend mee moest worden. In de eerste weken van het project, voor het maken van de definitiestudie, is hiermee al een start gemaakt door het lezen van beschikbare literatuur en het voorzichtig toevoegen van een testmodule. Daar de complexiteit van deze eerste pilot niet zo hoog was kon ik me nog beter bekend maken met het pakket voor er aan de meer complexe pilots zou worden begonnen. Verder had de keuze om deze pilot als eerste te ontwikkelen nog een andere praktische reden: alle volgende pilots zouden gebruik maken van de functionaliteit en gegevens die in deze pilot zou worden ontwikkeld. De doorvoertijd van deze pilot was geschat op 2 weken.

26

5.1 Reikwijdte De reikwijdte van de pilot is een belangrijk beginpunt om vanuit verder te werken. De grootte van de pilot wordt zodoende zichtbaar zodat er beter een planning kan worden gemaakt en er begonnen kan worden met het maken van een ontwerp van het te bouwen deel van het systeem. In de definitiestudie was al een globaal systeemconcept gedefinieerd. Aangezien de definitiestudie voor het gehele project moet gelden is de reikwijdte van een pilot logischerwijs een deel van dit systeemconcept. Er werd niet afgeweken van de in de definitiestudie beschreven pilotentiteiten:

Figuur: reikwijdte pilot 1

Deze reikwijdte was feitelijk al in het pilotplan van de definitiestudie beschreven. De volgende globale systeemeisen werden in deze pilot ontwikkeld: SE1: Projectmanagers moeten projectsjablonen kunnen beheren welke kunnen worden gebruikt als standaardprojecten binnen project budget bewaking. SE2: Projecten moeten bestaan uit fases die weer een aantal activiteiten hebben. SE3: Beheerders moeten informatie van bedrijfsmedewerkers kunnen beheren, waarbij een medewerker meerdere functies kan worden toegewezen. SE4: Beheerders moeten informatie van bedrijfsfuncties kunnen beheren. SE5: Medewerkers van de financiële afdeling moeten kostencodes kunnen beheren. SE6: Medewerkers van de financiële afdeling moeten weeknummers per jaar kunnen beheren. IE1: De interface van de te maken gedeeltes dienen overeen te komen met de huidige Sage CRM interface. De huidige Sage CRM interface stijl zal worden gebruikt. IE2: Het systeem dient in meerdere talen beschikbaar te zijn, in ieder geval Engels en Nederlands. ITE1: De inhoud van elk formulier wordt, voor deze opgeslagen wordt, gecontroleerd op correctheid (Validatie van gegevens). ITE2: Mocht, bij het ophalen van gegevens, corrupte informatie tevoorschijn komen wordt dit direct gemeld.

27

5.2 Ontwerp Het ontwerpen van deze eerste pilots (en de volgende pilots) was voor een groot deel al gedaan in de definitiestudie. Dit had vooral te maken met het feit dat de opdrachtgever en andere betrokken functionarissen bekend zijn met systeemontwikkeling. Dit bleek een groot voordeel omdat zij ook op technisch gebied al mee konden denken. De input bij het ontwerp van deze eerste pilot was dan ook het entiteitenmodel en de globale systeemeisen. Ik heb in overleg met de opdrachtgever gekozen voor de Yourdon techniek m.b.t. het ontwerpen van de pilots. Deze keuze was snel gemaakt daar ik op school naast Yourdon alleen UML als ontwerptechniek heb geleerd; over het algemeen is UML meer geschikt voor objectgeoriënteerde systemen en Yourdon voor systemen die dit niet zijn. In de eerste weken waarin ik mij het Sage pakket bekend heb gemaakt bleek dat toevoegingen in de programmeertaal ASP (met Javascript en HTML) moesten worden gemaakt. ASP is geen objectgeoriënteerde programmeertaal, het leek ons dan ook wijzer om voor de Yourdon techniek te kiezen. Volgende keuze bestond uit het bepalen van welke delen van de Yourdon techniek zouden worden uitgewerkt. Aangezien het doel van het systeem al bekend was en er al een entiteitenmodel was gedefinieerd werd besloten om de Yourdon techniek bij de eventlist te beginnen. Het overslaan van het contextdiagram is gedaan op verzoek van de opdrachtgever daar deze de eventlist een stuk duidelijker vond en het contextdiagram dubbel werk. Aan de hand van deze eventlist werden minidfd’s gemaakt met bijbehorende datadictionaries. Dezen werden als laatste gebruikt om de kolommen van de entiteiten te definiëren waarna begonnen zou worden met de bouw van de pilot. Voor deze fase van de pilotontwikkeling werd één week uitgetrokken waarin de tweede week gebruikt zou worden voor bouw en test. Met de definitiestudie als input begon ik de week met het definiëren van de eventlist voor de pilot. Waarna van elke event een mini-DFD werd gemaakt. Dit alles verliep vrij snel en zonder problemen. Bij de DFD’s moest ook een datadictionary worden gemaakt die de te bewaren informatie bevat, dit dient dan vervolgens voor de definitie van kolommen per entiteit. Met oog op de globale systeemeisen heb ik de datadictionary en kolommen benoemd. Dit diende als een eerste voorstel welke later in de week werd besproken. In deze bespreking bleek dat de datadictionary niet volledig was. Onder andere werden de volgende punten besproken: - moet het mogelijk zijn medewerkers te verwijderen? Ikzelf ging er van uit dat dit gewoon mogelijk zou moeten zijn, maar de opdrachtgever gaf aan dat hij liever zag dat een medewerker die uit dienst zou treden, op welke manier dan ook, als ‘uit dienst’ zou worden aangegeven i.p.v. verwijderd te worden. Zodoende krijgt men een archief waarin alle medewerkers staan die ooit bij het bedrijf hebben gewerkt. Ook kan de informatie nuttig zijn bij de overzichten van oude projecten waaraan de betreffende medewerker heeft meegewerkt. Er wordt besloten een kolom ‘status’ toe te voegen waarin kan worden aangegeven of de medewerker in dienst is, ziek is of uit dienst is.

28

- het bijhouden van contracturen In de bespreking werd besloten om, met oog op de urenregistratie, per medewerker het aantal uur per week dat hij volgens zijn contract moet werken ook op te slaan. Bij het invoeren van de weekstaat kan het systeem dan controleren of de medewerker genoeg uren voor de week heeft ingevoerd.

- splitsing kostprijs en verkoopprijs bij tarieven van medewerkers In eerste instantie had een tarief (koppeling tussen medewerker en functie) maar één bedrag. Het bedrag per uur of dag dat de medewerker zou kosten voor de klant in die functie. In de bespreking van dit bepaalde deel bleek dat men ook graag de kostprijs van die medewerker in die functie zou willen bijhouden. Dit zou van belang zijn voor gedefinieerde interne projecten en de budget bewaking van alle projecten. Besloten werd om het veld ‘kostprijs’ toe te voegen.

- hoe met mijlpalen in een project om te gaan? Een project bestaat ook uit mijlpalen die opgeleverd worden. Het halen of niet halen van deze mijlpalen zorgen ervoor of een project wel of niet succesvol is. Het implementeren van deze mijlpalen in de projecten is, na bespreking, opgelost door per activiteit aan te geven of het om een mijlpaal gaat. Dit is logischer dan het apart aanmaken van een mijlpaalentiteit aangezien een mijlpaal in feite ook een activiteit is – deel van het gehele project.

Deze bespreking had als resultaat een gedetailleerd entiteitenmodel welke geïmplementeerd kon gaan worden in Sage CRM. Vanwege de standaardfunctionaliteit in Sage CRM waarin overzichten en de mogelijkheid tot beheren van gegevens en de eenvoudige opzet van de pilot is besloten om voor deze pilot geen verder schermontwerp te maken.

Figuur: proces van definitiestudie tot entiteitendefinitie Pilot 1

29

5.3 Bouw Nu er een gedetailleerde entiteitendefinitie was kon begonnen worden aan het bouwen van deze functionaliteit in Sage CRM. Sage CRM maakt het mogelijk om gemakkelijk tabellen (entiteiten) toe te voegen aan het systeem. Daarvoor wordt gebruik gemaakt van een aantal verschillende veldtypen welke na te lezen zijn in Bijlage C. Elk veldtype heeft een bepaald gedrag bij het tonen en veranderen van gegevens. Deze veldtypen heb ik per gedefinieerde kolom van een entiteit aangewezen. Als voorbeeld het entiteit ‘ActivityTemplate’ (activiteitsjabloon):

ActivityTemplate Actt_ID Actt_Description Actt_Milestone Actt_Hours Actt_Order Actt_FunctionID Actt_PhaseID Actt_CostCodeID

Identityfield Text (255) Checkbox Integer, verplicht Integer Search Select Advanced, Functions, on delete no action (prompt) Search Select Advanced, PhaseTemplate, on delete cascade Search Select Advanced, CostCode, on delete no action (prompt)

Figuur: voorbeeld van een uitgewerkte entiteitendefinitie

De linkerkolom geeft de naam van de kolom en de rechterkolom het veldtype zoals deze in Sage CRM wordt gebruikt. De laatste drie kolommen zijn de vreemde sleutels van de functie-, fase-, en kostencodetabel zoals te zien in het entiteitenmodel. Daarbij staat ook welke actie er moet worden uitgevoerd bij het verwijderen van het veld waar de vreemde sleutel naar wijst. Sage CRM maakt van deze velden een keuzelijst welke gevuld is met een lijst van de beschikbare vreemde sleutels:

Figuur: voorbeeld hoe de vreemde sleutel velden (Search Select Advanced) werkt in Sage CRM. Er is een lijst te zien met functies die in het systeem zijn ingevoerd.

30

Het aanmaken en goed werkende krijgen van deze functionaliteit was eigenlijk het grootste struikelblok bij het bouwen van deze pilot. Naast het aangeven naar welke entiteit het bepaalde veld wijst (waar het een vreemde sleutel van is) moet er ook bij die entiteit worden aangegeven welke velden in de lijst worden getoond. De eerste keer dat ik probeerde een dergelijk veld toe te voegen kwam er een lege lijst tevoorschijn omdat ik nog niet had aangegeven welke velden getoond moesten worden in de lijst. Na het lezen van de documentatie, het nakijken van bestaande entiteiten in Sage CRM en het navragen bij collega’s die bekend zijn met het pakket werd me duidelijk wat ik vergeten was. Dit is een goed voorbeeld van een nadeel van het werken van een bestaand systeem. Helaas is niet alles in de documentatie te vinden waardoor men van tijd tot tijd zelf ontdekkingen moet doen. Naast dit kleine struikelblok is de rest van het invoeren van de entiteiten voorspoedig verlopen. Voor elke entiteit werd een invoerscherm en lijst gemaakt. Zodra alle entiteiten in het systeem waren ingevoerd werd er weer een bespreking met de opdrachtgever gehouden waarin we scherm voor scherm door het geheel gingen. Daarbij kwamen in dit geval geen veranderingen aan het ontwerp boven water. Wel waren er twee punten die de opdrachtgever graag anders zag, nl: de uitwerking van de medewerkerbeschikbaarheid en het gebrek aan een totaaloverzicht van een projectsjabloon. Bij de medewerkerbeschikbaarheid was in eerste instantie gebruik gemaakt van de Sage CRM veldtype ‘multi-select’ wat in feite een keuzelijst is waarin meerdere keuzes kunnen worden gemaakt.

Figuur: standaard Sage CRM uitwerking van de medewerkerbeschikbaarheid

Deze manier van tonen is, naast niet bijzonder fraai, ook nog eens onduidelijk. Hier waren we het allemaal over eens. Er moest dus worden gezocht naar een betere manier van tonen. Het veldtype moest wel hetzelfde blijven alleen de presentatie anders. Het bleek echter niet goed mogelijk om de presentatie van een veldtype te veranderen. Ik wilde daarom proberen om met de ruwe data uit de database als uitgangspunt zelf iets op het scherm te krijgen. Na wat zoekwerk in de database zelf om te kijken hoe Sage CRM de geselecteerde velden van de keuzelijst opslaat en het omzetten van deze gegevens in een duidelijke presentatie van de beschikbaarheid was het resultaat als volgt:

Figuur: aangepaste uitwerking van de medewerkerbeschikbaarheid

Zowel de opdrachtgever als ikzelf waren hier veel meer over te spreken. Met dezelfde gegevens uit de database en een kleine aanpassing aan de manier van presenteren is heel wat vooruitgang geboekt. Uiteraard kost dit wel extra tijd om te bouwen, maar dat was het in dit geval waard.

31

Nadat deze uitwerking was goedgekeurd werd er begonnen met een totaaloverzicht van een projectsjabloon. Vanwege het succes van het zelf interpreteren van gegevens uit de database werd besloten dit overzicht ook zelf op te bouwen, daar ook hier de standaardfunctionaliteit van Sage CRM te kort kwam (het was niet mogelijk om een lijst te creëren waarin een totaaloverzicht van fases en onderliggende activiteiten te zien was). Het resultaat ziet er als volgt uit:

Figuur: totaaloverzicht projectsjabloon met fases en functies

In eerste instantie werden alleen de fasenamen en activiteitnamen getoond. Bij het bespreken van deze oplossing werd aangegeven dat men liever ook de activiteitinformatie erbij getoond wilde hebben. Dit werd aangepast en goedgekeurd. Na deze goedkeuring werd een testdatum afgesproken waarop het geheel zou worden getest door de opdrachtgever en een gebruiker. Op dezelfde datum zou een evaluatie van de pilot plaatsvinden waarna de tweede pilot zou worden opgestart.

Figuur: proces van ontwerp tot testklare module

32

5.4 Test Voor de test werd een testscenario opgezet waarin de onderdelen die getest moesten worden staan. Aan de hand van deze punten zou de module worden getest en beoordeeld. Mochten er onvolkomenheden in de module voorkomen dan zullen deze moeten worden opgelost en op een later tijdstip opnieuw beoordeeld worden. Helaas zijn de originele testscenario’s van de pilots niet meer voor handen. Deze zijn dan ook niet terug te vinden in de bijlagen. Desondanks kan ik wel de hoofdpunten die werden getest bespreken: Navigatie: De navigatie binnen een systeem moet goed zijn zodat het fijn is om met een systeem te werken. Bij web-based applicaties bestaat het systeem uit een aantal webpagina’s, hierbij moet extra gelet worden op de navigatie. Zodra wordt verwezen naar een niet-bestaande webpagina wordt een foutmelding gegeven door de browser. Het testen van de navigatie was het eerste onderdeel van de test. Alle nieuwe schermen werden doorlopen waarbij veelvuldig ook andere webpagina’s werden opgevraagd en de ‘back’ en ‘forward’ toetsen van de browser werden gebruikt. Deze test verliep goed, tijdens het ontwikkelen is het gemakkelijk om de navigatie tussentijds te testen. Functionaliteit: De systeemeisen uit de definitiestudie en de entiteitendefinitie werden bij deze test geraadpleegd om te zien of de module ook daadwerkelijk alle beschreven functionaliteit bezat. Dit was het geval. Tevens werd er gebruik gemaakt van de functionaliteit door bestaande medewerkers, functies, kostencodes en projectsjablonen in te voeren. Er werden tijdens de test geen tekorten gevonden. Koppeling met bestaande Sage CRM: Aangezien het gaat om een toevoeging op een bestaand systeem is het ook van groot belang of de koppeling tussen deze twee goed verloopt. Deze pilot maakt geen gebruik van al bestaande entiteiten, hier hoeft dan ook niet op worden getest. Wel maakt de module deel uit van het Sage CRM systeem, met een extra tabblad op de hoofdpagina voor medewerkergegevens en extra opties bij het data management voor de functies, kostencodes en projectsjablonen. Ook hier werden geen problemen ontdekt. Beveiliging en integriteit: De beveiliging en integriteit van een systeem zijn enorm belangrijk, wederom vooral bij een webbased systeem dat voor iedereen met Internet toegankelijk is. Sage CRM handelt echter de beveiliging goed af dus daar hoefde men geen zorgen over te maken. Wel is de integriteit van de gegevens binnen een systeem belangrijk. Foutieve informatie moet worden afgevangen zodat deze niet opgeslagen wordt. Gelukkig handelt Sage CRM d.m.v. de standaard veldtypen ook dit probleem goed af. Het systeem geeft automatisch aan wanneer een invoer niet klopt. De twee delen die buiten de veldtypen zijn ontwikkeld werden wel aan de tand gevoeld, waarbij uiteenlopende informatie werd ingevoerd en gekeken werd of foutieve informatie werd afgevangen of genegeerd. Ook deze test verliep zoals het hoort.

Tijdens deze tests bleek dus dat de pilot goed was geïmplementeerd. Dit gebeurt, naar mijn ervaring, zelden bij een eerste test. Verklaring hiervoor zijn de beperkte grootte en complexiteit van de pilot, het uitvoerige testen van codeblokken tijdens de bouw en de bespreking die voor de test werd gehouden waarin nog wel een paar onvolkomenheden werden gevonden.

33

5.5 Evaluatie Als laatste werd de pilot geëvalueerd door mij en de opdrachtgever. De pilot is met succes geïmplementeerd daar de tests succesvol waren verlopen. Ook liep ik nog gelijk met de planning: voor de pilot waren twee weken uitgetrokken en dit is uiteindelijk ook wat er voor nodig was. Pilot 2 kon daarom ook zonder problemen worden opgestart. De opdrachtgever vroeg zich alleen het nut af van de gemaakte eventlist en DFD’s daar deze toch tot een entiteitendefinitie zou leiden. Hij stelde voor om bij de eerstvolgende workshop deze twee activiteiten achterwege te laten en gelijk een concept entiteitendefinitie en gedetailleerde systeemeisen te formuleren die dan zouden worden besproken. Ik was het wel met hem eens, omdat hij en de andere betrokken functionaris het te bouwen systeem goed in hun hoofd hadden. Vandaar dat vanaf pilot 2 is afgestapt van het Yourdon principe en er gelijk vanaf het al gemaakte entiteitenmodel wordt doorontworpen. Ook werd er op dit punt bekeken of de definitiestudie zou moeten worden herzien naar aanleiding van de ontwikkeling van pilot 1. Aangezien pilot 1 naar wens en ontwerp was verlopen waren er geen veranderingen nodig in de definitiestudie.

34

6. Pilot 2: Project Budget Bewaking Deze pilot zou het hart gaan vormen van de nieuwe module die ontwikkeld werd. Met de ontwikkelde en geteste pilot 1 en de definitiestudie als uitgangspunt werd de project budget bewaking binnen Sage CRM gerealiseerd. Naar aanleiding van de evaluatie aan het eind van de vorige pilot was besloten om af te stappen van de Yourdon ontwerptechniek. Dit heb ik in het vorige hoofdstuk al kort aangestipt. Hieronder zal ik een lijst met overwegingen die zijn gemaakt voor dit besluit werd genomen, dit om de reden van deze beslissing te onderbouwen. Deze overwegingen zijn tijdens de evaluatie met de opdrachtgever gemaakt. -

wat is de toegevoegde waarde van de gemaakte modellen boven die van het systeemconcept in de definitiestudie?

De ontwerptechniek heeft als functie om de doelstellingen van een systeem om te zetten in een technisch concept welke vervolgens wordt gebouwd. Door het volgen van een van deze technieken kunnen eventuele onvolkomenheden of toevoegingen aan de doelstelling aan het licht komen. Bij dit project zijn echter een paar omstandigheden anders dan de meeste andere projecten die ik op school en tijdens stage heb gedaan: de opdrachtgever heeft de opdracht erg duidelijk in zijn hoofd, de opdrachtgever is zelf informaticus en heeft dus weet van de technische kant van het geheel, het gaat om een web-based applicatie waar vooral de interface erg gemakkelijk aan te passen is bovendien maakt Sage CRM het mogelijk standaard lijsten en schermen te maken. Hierdoor is in de definitiestudie al een vrij definitief entiteitenmodel opgesteld die alleen maar dient te worden gedetailleerd met veldnamen. De toegevoegde waarde van de ontwerptechniek is in dit project dan ook miniem. -

is het gemaakte entiteitenmodel een goede basis voor de bouw van het systeem?

Als het ontwerp een detail wordt van het entiteitenmodel moet dit model wel een goede basis zijn voor de bouw van het systeem. De opbouw van het Sage CRM systeem in entiteiten met standaard veldtypen, schermen en lijsten maakt dit mogelijk. Een entiteit uit het model kan simpel gezegd één op één worden overgenomen in Sage CRM. Wel moeten extra functionaliteit die hier buiten valt worden gespecificeerd. -

welke activiteiten moeten in de plaats komen voor de eventlist, DFD’s en datadictionary?

Met het globale entiteitenmodel als input welke activiteiten moeten worden uitgevoerd om tot een goed ontwerp en bouw van de pilot te komen? Om het entiteitenmodel te kunnen implementeren in Sage CRM moeten er eerst velden en veldtypen worden gedefinieerd. Vervolgens moeten eventuele extra functionaliteit die niet door Sage CRM kan worden gegenereerd worden gedefinieerd en globaal geschetst. Naar aanleiding van deze punten is afgesproken met de opdrachtgever om deze pilot te beginnen met een concept van de entiteitendefinitie en schermdefinities.

35

6.1 Reikwijdte In de evaluatie van pilot 1 is een herziening van de definitiestudie niet nodig geacht. De reikwijdte van pilot 2 als deel van het entiteitenmodel werd dan ook overgenomen uit de definitiestudie:

Cost_code

Employee

ProjectCost

ProjectMember


CalendarEntry

Person

ProjectActivity

Project Task

ProjectProduct Company

PurchaseLine

Opportunity

Product

Figuur: reikwijdte pilot 2

In het bovenstaande model staan twee lichtgrijze entiteiten, cost_code en employee, dit zijn entiteiten die in de eerste pilot ingevoerd zijn. In de tweede pilot ontstaat dus een koppeling met de functionaliteit van de eerste pilot.

36

De volgende globale systeemeisen werden in deze pilot ontwikkeld: SE1: Projecten moeten bestaan uit fases die weer een aantal activiteiten hebben. SE2: Projectmanagers moeten nieuwe projecten kunnen definiëren en beheren. Nieuwe projecten worden gemaakt aan de hand van een opportunity, in het geval van een project bij een klant, of op zichzelf staand, in het geval van een intern project. SE3: Per project moeten de volgende zaken kunnen worden bijgehouden: projectmedewerkers, producten, kosten, contact personen, projecttaken en een documentbibliotheek. SE4: (Project)managers moeten de mogelijkheid hebben om d.m.v. diverse rapportages een overzicht te krijgen van de werkzaamheden binnen het bedrijf. IE1: De interface van de te maken gedeeltes dienen overeen te komen met de huidige Sage CRM interface. De huidige Sage CRM interface stijl zal worden gebruikt. IE2: Het systeem dient in meerdere talen beschikbaar te zijn, in ieder geval Engels en Nederlands. ITE1: De inhoud van elk formulier wordt, voor deze opgeslagen wordt, gecontroleerd op correctheid (Validatie van gegevens). ITE2: Mocht, bij het ophalen van gegevens, corrupte informatie tevoorschijn komen wordt dit direct gemeld.

37

6.2 Ontwerp De eerste activiteit van de ontwerpfase van deze tweede pilot was het detailleren van het globale entiteitenmodel. Met de kennis die was opgedaan tijdens de eerste pilot werden per entiteit de velden en daarbij horende typen gedefinieerd. Dit leverde een eerste concept van de entiteitendefinitie op.

ProjectMember Prm_ID Prm_ProjectID Prm_EmployeeID Prm_Function

Identityfield Search Select Advanced, Project, on delete cascades Search Select Advanced, Employee, on delete no action (prompt) Selection, verplicht

Figuur: voorbeeld van een deel van de entiteitendefinitie voor pilot 2. Het betreft hier de conceptdefinitie van de entiteit ProjectMember.

Voor alle entiteiten werd een tabel zoals hierboven afgebeeld met de velden die ik dacht noodzakelijk te zijn voor het implementeren van de systeemeisen. Deze definitie werd als input gebruikt bij de volgende workshop. Doel van deze workshop was het bespreken en detailleren van de eisen die voor deze tweede pilot golden. Deze workshop bestond uit het discussiëren van het huidige systeemconcept en het concept entiteitendefinitie. Zoals bij de voorgaande workshops zal ik hieronder een aantal belangrijke discussiepunten aanstippen om het proces tot het komen van een tweede concept te verduidelijken: -

moet het systeem naast het budget ook de doorlooptijd bewaken?

Bij de start van een project wordt voor het gehele project en per fase een begin- en einddatum geschat. Zodra deze overschreden wordt kan het systeem zo gebouwd worden dat deze hiervoor waarschuwt. Dit zou een constante controle op de data van een project vergen en het systeem zou zo meer richting een planningspakket gaan waarvan eerder al is besloten dat dit niet de bedoeling was. Om (project)managers toch inzicht te geven in de doorlooptijd van een project zal aan het begin van het project een begindatum en een verwachte einddatum worden gesteld. Hetzelfde geldt voor de fasen en activiteiten. Zo kan de (project)manager zelf controleren of het project op schema loopt. Zodra het project is opgeleverd en afgerond wordt deze datum ook ingevoerd als de werkelijke einddatum. Dit maakt het mogelijk om overzichten te creëren van projecten die te vroeg, op tijd of te laat zijn opgeleverd volgens de eerste afspraken. Concreet betekende dit voor de entiteitendefinitie dat zowel het project als de onderliggende fasen en activiteiten een begin- en einddatum veld kregen. Daarnaast werd nog een derde veld toegevoegd aan het project; werkelijke einddatum.

38

-

een projectoverzicht met alle onderliggende fasen en activiteiten is gewenst. Welke informatie gaat deze bevatten?

Het projectoverzicht zoals deze is gemaakt voor de projectsjablonen kon in feite worden overgenomen daar deze aan de wensen voldeed. Wel moest er extra informatie bij worden getoond. Het was wenselijk om per activiteit de totale kosten van alle toegewezen taken te tonen. Deze worden berekend door de kosten van alle taken die een activiteit heeft op te tellen. Het totaal van al deze activiteiten zijn de werkelijke kosten van het project in uren en geld. Onderaan het overzicht moesten deze totale kosten en het – positieve of negatieve – verschil met het gedefinieerde projectbudget worden getoond. Het was ook mogelijk om in het overzicht per activiteit ook alle toegewezen taken te laten zien. Dit zou echter een groot en onduidelijk overzicht betekenen. Besloten werd om in de tabbalk van het project een taakoverzicht voor het project aan te brengen.

-

bij het aanwijzen van projectmedewerkers wordt de medewerker en de functie die deze medewerker vervult binnen het project gekozen. Hierbij wordt het daarvoor geldende tarief gekozen. Is het wenselijk om bij het toevoegen van de projectmedewerker dit tarief aan te passen?

Het bleek dat het wel eens voorkomt binnen projecten dat een medewerker voor een ander tarief werkt dan standaard is voor zijn functie. Het was dus wenselijk om bij het toevoegen een ander tarief te definiëren. Dit tarief zou voor het project apart moeten worden opgeslagen want zodra het standaardtarief van de medewerker veranderd moet niet hetzelfde gebeuren voor het tarief binnen het project. Voor de entiteitendefinitie betekende dit het toevoegen van twee velden uit de tariefentiteit: tarief en eenheid (per uur, dag, etc.).

ProjectMember Prm_ID Prm_ProjectID Prm_EmployeeID Prm_Function Prm_Tariff Prm_Unit

Identityfield Search Select Advanced, Project, on delete cascades Search Select Advanced, Employee, on delete no action (prompt) Selection, verplicht Currency, verplicht Selection, verplicht

Figuur: voorbeeld van een deel van de entiteitendefinitie voor pilot 2. Het betreft hier de aangepaste definitie van de entiteit ProjectMember.

Figuur: uitvoering van bovenstaande discussiepunt door het toevoegen van twee velden.

39

Aan het eind van deze workshop werd besloten om de besproken delen (project met fasen, activiteiten, taken en medewerkers) allereerst als concept te implementeren in Sage CRM. Vervolgens zou hier in een volgende workshop doorheen worden gelopen en worden bepaald hoe de andere entiteiten zouden worden geïmplementeerd. Deze entiteiten met het projecten taakoverzicht werden vervolgens door mij in Sage CRM gerealiseerd, zoals te lezen is in het volgende hoofdstuk. Zodra dit concept in Sage CRM aanwezig was werd opnieuw een workshop georganiseerd met de opdrachtgever. Deze werd gestart met het doorlopen van dit concept. Bij het zien van de schermen kwamen nog een paar punten boven water die van belang zouden zijn: -

-

Het projectoverzicht was goed, maar bij het project zelf wilde men ook een ordernummer richting de klant van het gehele project noteren met daarbij een primair contactpersoon die als factuuradres zou dienen. Dit betekende het toevoegen van twee velden aan de projectentiteit wat dankzij de Sage CRM functionaliteit zo gebeurd was. Bij het invoeren van een nieuw project moesten nu wel het ordernummer en een primair contactpersoon worden aangewezen. In het projectoverzicht worden de kosten van alle taken binnen het project berekend. Dit zijn echter nog niet alle kosten, in de eerste workshop waren de kosten van het inkopen van producten vergeten. De totale kosten in het overzicht moest dus de totale taakkosten met de totale productkosten worden.

Verder werd dit concept goedgekeurd en kon de functionaliteit volledig werkend worden gemaakt. Als laatste werd het overgebleven deel van het entiteitenmodel uitgewerkt. Deze entiteiten hadden minder om handen dan de voorgaande. Één punt van discussie is het waard om hier te noemen: -

Er werd besloten de entiteit CalendarEntry in het model te houden maar (nog) niet te ontwikkelen. Deze entiteit zou in verbinding staan met de centrale kalender in Sage CRM. Na wat onderzoek door mij uitgevoerd in de tijd tussen de twee ontwerpworkshops bleek dat de toegang tot deze kalender danig ingewikkeld was dat het implementeren van deze entiteit veel tijd zou gaan kosten. Deze entiteit had geen prioriteit boven de volgende pilots dus werd deze in de spreekwoordelijk vrieskist geplaatst.

Resultaat van de workshop was een entiteitendefinitie en een lijst met uitgewerkte systeemeisen die hierbij horen.

Figuur: proces van concept entiteitendefinitie tot entiteitendefinitie pilot 2

40

6.3 Bouw Zoals te lezen is in het voorgaande hoofdstuk werd al tijdens de ontwerpfase een concept van een deel van de pilot in Sage CRM gemaakt. Dit betrof de entiteiten project, fase, activiteit, taak en medewerker.

Figuur: deel van het entiteitenmodel die in het concept aan bod kwamen.

Deze entiteiten werden in Sage CRM ingevoerd met standaardlijsten en –schermen zoals ook in pilot 1 is gedaan. Verder is de projectsjabloonoverzichtlijst overgenomen naar het projectscherm als projectoverzicht. In deze overzichtlijst werd, voor de volgende workshop, wat fictieve informatie gezet. Later zou de informatie in deze lijst uiteraard uit de database moeten komen. Grootste probleem tijdens het maken van dit concept kwam bij het invoeren van de medewerkerentiteit aan het licht. Daar kan een medewerker worden geselecteerd die aan het project gekoppeld wordt. Daarbij moet ook de functie die deze medewerker moet vervullen worden gekozen. In pilot 1 is de functionaliteit van het koppelen van functies aan medewerkers (tarieven) al geïmplementeerd. Zodra een medewerker is gekozen moet de lijst met functies die functies weergeven die aan de medewerker gekoppeld zijn en niet alle functies die in de lijst zijn aangegeven wat het geval was. Na uitgebreid zoekwerk in het systeem en de documentatie had ik dit probleem nog niet kunnen oplossen. Ik ben toen het probleem gaan bespreken met een collega die ook met Sage CRM werkt, samen hebben we nogmaals het systeem (waaronder de database) doorgespit en uiteindelijk de oplossing kunnen vinden. Bij het aanmaken van het functieveld in Sage CRM moet worden aangegeven dat deze ‘gebonden’ is aan de selectie van het medewerkerveld. Om dit werkend te krijgen moest bovendien een databaseview worden gemaakt die een lijst met alle medewerkers, functies en tarieven bevat. Het concept is naast dit probleem soepel gebouwd en werd in de tweede ontwerpworkshop besproken zoals te lezen is in het vorige hoofdstuk.

41

Het resultaat van de ontwerpfase was een entiteitendefinitie en een lijst met systeemeisen. Samen met het conceptdeel en de eerste pilot was dit het beginpunt van de bouw van de tweede pilot. Als eerste werd begonnen met het implementeren van de entiteiten die in de tweede workshop waren besproken. De entiteiten contactpersonen en projectkosten zijn zo relatief eenvoudig in het systeem verwerkt.

Figuur: lijst met contactpersonen van het project. Dit kunnen personen zijn bij het bedrijf waarvoor het project wordt ontwikkeld, maar ook van andere bedrijven.

Helaas kreeg ik toen te maken met een aantal tegenslagen die de uitvoering van deze pilot vertraagd hebben. Deze problemen werden voornamelijk veroorzaakt door onvoldoende documentatie van Sage CRM of fouten in de codefuncties die het systeem bevat. Hieronder zullen deze punten besproken worden: -

Bij het toevoegen van producten aan het project moesten de kosten van deze producten worden opgeteld als deel van de totale projectkosten. Gebruik zou worden gemaakt van de bestaande productenentiteit. Het probleem ontstond bij het uitrekenen van het totaalbedrag. Het bleek namelijk dat Sage CRM de producten in groepen had ingedeeld welke weer bepaalde typen hadden. Daar stond uiteindelijk de prijs van het product. Om hier achter te komen moest de database worden geraadpleegd en stap voor stap de registratie van een productprijs worden doorlopen om erachter te komen waar deze prijs precies werd opgeslagen en hoe deze in verbinding stond met de productnaam. Een overzicht van de database werd hier danig gemist en ook het feit dat de code van bestaande functionaliteit wegens concurrentieredenen niet toegankelijk is maakte het onmogelijk om de huidige werkwijze snel te kunnen nabootsen. Als oplossing werd in de code een query uitgevoerd die door deze verschillende databasetabellen ‘liep’ om voor het product de prijs te berekenen waarna ook het totaal van alle producten kon worden berekend.

-

Het functioneel maken van het projectoverzicht en de takenoverzicht ging helaas ook niet zonder slag of stoot. De informatie van het project (fasen, activiteiten) werd gedaan zoals in het projectsjabloonoverzicht. Het probleem zat hem in eerste instantie in de weergave van de kosten van een activiteit. Aangezien deze lijst geen standaardlijst van Sage CRM was gaf het systeem de waarde zoals deze in de database staat weer. Er ontbreken dan een aantal instellingen die per gebruiker van het systeem kan wisselen: valuta, het teken om duizendtallen aan te geven (in Amerika is dat een komma, in Europa een punt), het teken om de centen mee aan te geven (in Amerika is dat een punt, in Europa een komma) en het aantal decimalen (voor bedragen is dit meestal 2, maar men kan er ook voor kiezen om geen decimalen weer te geven, maar afgeronde getallen). Het ophalen van deze instellingen voor een gebruiker was een kwestie van een extra query in de code. Zodoende was het valutateken al gauw in het overzicht te tonen.

42

Helaas was er geen functie voor handen die het mogelijk maakte om van bijvoorbeeld de waarde ‘2000’ te maken ‘2.000,00’. Deze moest zelf worden geschreven. Het was een goede uitdaging een functie te maken die rekening houdt met zowel de decimalen, het decimaalteken en om de drie cijfers het teken om duizendtallen weer te geven. Het volledig correct krijgen van deze functie en het testen van verschillende waardes kostte echter wel aardig wat tijd. Naast de weergave van een bedrag kwam er ook een probleem met het omrekenen van een bedrag naar een andere valuta aan het licht. Bij het installeren van het Sage CRM systeem wordt gevraagd om een standaardvaluta (in dit geval de euro). Gebruikers hebben echter de mogelijkheid een voorkeursvaluta in te vullen (zoals de dollar of de yen). Het systeem laat dan, naast het bedrag in euro’s, ook het bedrag in dollars of yen zien berekend volgens een koersentabel die ingevuld kan worden door de systeembeheerder. De functie om een bedrag van één valuta naar een andere om te zetten was gelukkig wel aanwezig. Deze heb ik in eerste instantie ook gebruikt en de bedragen werden netjes in bijvoorbeeld dollars getoond. Alleen bleek er soms een klein verschil in waardes voor te komen als men de valutaconversie zelf uitrekende. Als voorbeeld het bedrag € 21,25 moet omgezet worden naar dollars volgens een koers van 1 euro is 1,21 dollar. Dit betekent dus dat het resultaat het volgende zou moeten zijn: 21,25 * 1,21 = $ 25,7125 (afgerond $ 25,71) Het systeem gaf echter een andere waarde weer na het converteren, namelijk $ 25,41. Een verschil van dertig dollarcent op een bedrag van iets meer dan twintig euro. Na het nogmaals controleren van de waardes en de onderlinge koersen van de valuta’s probeerde ik een aantal andere getallen uit waarvan sommige wel en sommige niet klopten. Daarna probeerde ik het foutieve bedrag terug te rekenen door te doen: 25,41 / 1,21 = 21 Deze berekening geeft de suggestie dat de Sage CRM functie het invoerbedrag eerst afrond voor de conversie plaatsvindt. Dit werd met andere waardes met en zonder decimalen getest en dit bleek inderdaad het geval te zijn. Zoals gezegd is de code van deze functies niet toegankelijk dus waren er twee opties: wachten op een nieuwere versie van Sage CRM waarin dit probleem zou zijn verholpen of zelf een conversiefunctie schrijven. Omdat niet bekend was wanneer het probleem door Sage zou worden verholpen is besloten een eigen functie te maken. Voor deze functie geldt hetzelfde als de bedragfunctie. Het is een goede ervaring om zo’n functie te maken, maar het kost wel extra tijd om te maken en te testen. Het testen van de functie werd door mij gedaan door het invoeren van een verschillend aantal bedragen en conversies naar verschillende valuta’s te doen.

43

-

Het laatste grote probleem was het toevoegen van een documentbibliotheek. Ook dit is standaardfunctionaliteit van Sage CRM alleen is het activeren van een bibliotheek voor een nieuwe entiteit niet mogelijk via het programma zelf. Wederom moest ik daarvoor de database in om te kijken welke waardes ik moest gebruiken bij de projectentiteit om deze bibliotheek toe te voegen. Over de oplossing zal ik hier niet uitweiden aangezien het om een aantal waardes die voor de projectentiteit speciaal moesten worden aangemaakt ging. Het doorzoeken van de database naar deze waardes en het testen van de bibliotheek door mij heeft me helaas wel bijna twee volle dagen gekost.

Figuur: voorbeeld van de documentbibliotheek binnen Sage CRM

Na deze problemen opgelost te hebben en de pilot volgens de entiteitendefinitie en systeemeisen te hebben gebouwd werd de gehele pilot getest. Een korte beschrijving van deze test is te vinden in het volgende hoofdstuk. In deze test werden nog een paar interfacezaken zoals de informatie die getoond werd in een lijst en een aantal navigatiefouten gevonden welke na de test nog moesten worden aangepast.

Workshop Concept entiteiten definitie

Conceptversie deel definitie in Sage CRM

Entiteiten definitie Pilot 2

Volledige versie in Sage CRM klaar voor test

Tweede versie in Sage CRM Test Laatste test en evaluatie

Figuur: proces van entiteitendefinitie tot implementatie pilot 2

44

6.4 Test Voor de test werd een testscenario opgezet waarin de onderdelen die getest moesten worden staan. Aan de hand van deze punten zou de module worden getest en beoordeeld. Mochten er onvolkomenheden in de module voorkomen dan zullen deze moeten worden opgelost en op een later tijdstip opnieuw beoordeeld worden. Helaas zijn de originele testscenario’s van de pilots niet meer voor handen. Deze zijn dan ook niet terug te vinden in de bijlagen. Desondanks kan ik wel de hoofdpunten die werden getest bespreken: Navigatie: De navigatie binnen een systeem moet goed zijn zodat het fijn is om met een systeem te werken. Bij web-based applicaties bestaat het systeem uit een aantal webpagina’s, hierbij moet extra gelet worden op de navigatie. Zodra wordt verwezen naar een niet-bestaande webpagina wordt een foutmelding gegeven door de browser. Het testen van de navigatie was het eerste onderdeel van de test. Alle nieuwe schermen werden doorlopen waarbij veelvuldig ook andere webpagina’s werden opgevraagd en de ‘back’ en ‘forward’ toetsen van de browser werden gebruikt. Tijdens deze test bleek in een aantal situaties de navigatie niet vlekkeloos te verlopen wat eindigde in een foutmelding van de browser. De acties die verricht waren om tot deze fout te komen werden opgeschreven zodat ik later deze onvolkomenheid kon oplossen. Functionaliteit: De systeemeisen uit de definitiestudie en de entiteitendefinitie werden bij deze test geraadpleegd om te zien of de module ook daadwerkelijk alle beschreven functionaliteit bezat. Dankzij snelle besprekingen ‘in de wandelgangen’ tijdens de bouw waren al wat punten aan het licht gekomen (zie ook het vorige hoofdstuk). De functionaliteit werd getest door een bestaand project geheel in te voeren in het systeem. Dit verliep vrijwel zonder fouten. Zo kon er bijvoorbeeld twee keer dezelfde medewerker met dezelfde functie worden toegevoegd aan een project. Er moest dus een controle komen of de invoer niet gelijk was aan bestaande informatie. Koppeling met bestaande Sage CRM: Aangezien het gaat om een toevoeging op een bestaand systeem is het ook van groot belang of de koppeling tussen deze twee goed verloopt. De koppeling met huidige entiteiten van Sage CRM bestaat in deze pilot uit een koppeling naar Companies, Persons, Opportunities en Products. Verschillende bedrijfs- en productinformatie werd ingevoerd en gekeken werd of deze informatie juist werd getoond. Beveiliging en integriteit: De beveiliging en integriteit van een systeem zijn enorm belangrijk, wederom vooral bij een webbased systeem dat voor iedereen met Internet toegankelijk is. Sage CRM handelt echter de beveiliging goed af dus daar hoefde men geen zorgen over te maken. Wel is de integriteit van de gegevens binnen een systeem belangrijk. Foutieve informatie moet worden afgevangen zodat deze niet opgeslagen wordt. Gelukkig handelt Sage CRM d.m.v. de standaard veldtypen ook dit probleem goed af. Het systeem geeft automatisch aan wanneer een invoer niet klopt. De twee delen die buiten de veldtypen zijn ontwikkeld werden wel aan de tand gevoeld, waarbij uiteenlopende informatie werd ingevoerd en gekeken werd of foutieve informatie werd afgevangen of genegeerd. Deze test verliep zoals het hoort.

Het bleek dus dat de pilot, op een paar kleine punten na, goed was geïmplementeerd. Besloten werd om deze punten op te lossen en er vervolgens nog eens met de opdrachtgever naar te kijken voor de pilot werd goedgekeurd en geëvalueerd.

45

6.5 Evaluatie

06-01-2006

30-12-2005

23-12-2005

16-12-2005

09-12-2005

02-12-2005

25-11-2005

18-11-2005

11-11-2005

04-11-2005

28-10-2005

21-10-2005

Ook deze pilot werd afgesloten met een evaluatie. Ondanks een paar struikelblokken en een paar kleine onvolkomenheden tijdens de test is ook deze pilot met succes geïmplementeerd. Ik liep echter wel een volle week achter op schema. In de evaluatie werd dus met oog op de resterende doorlooptijd gekeken naar de planning zoals deze in de definitiestudie staat. Pilot 2 heeft dus een week langer geduurd. Ook had ik in de planning geen rekening gehouden met het feit dat het kantoor tussen kerst en oud en nieuw gesloten zou zijn. De drie weken die ik voor de pilots 3 en 4 (urenregistratie) had gepland zouden gehandhaafd blijven. De week dat het kantoor gesloten was zou werk aan de pilots onmogelijk maken. Er werd geconcludeerd dat de ‘luxe’ pilot 5 (facturering) helaas niet tot uitvoering zou worden gebracht in dit project.

Pilot 1

Pilot 2 Pilot 3

Pilot 3 Kantoor gesloten

Pilot 4

Pilot 4

Figuur: de aangepaste planning n.a.v. de evaluatie van pilot 2, pilot 5 (facturering) is uit deze planning verdwenen

Naast de planning werden geen significante wijzigingen aan de definitiestudie besloten daar pilot 2 naar wens was geïmplementeerd. Er kon begonnen worden met de derde en vierde pilot.

46

7. Pilot 3 en 4: Urenregistratie (binnen en buiten Sage CRM) Na de tweede pilot werden zowel pilot 3 als 4 opgestart, deze zouden parallel worden ontwikkeld. De reden waarom de urenregistratiefunctionaliteit in twee pilots is gesplitst had als reden dat de ontwikkelomgeving van elke pilot verschilde. De eerste bevatte het urenregistratiedeel zoals deze in Sage CRM moest worden ontwikkelt. De tweede bevatte het deel buiten Sage CRM waarin projectmedewerkers via een website hun gewerkte uren konden registreren. Hoewel het hier om twee aparte pilots gaat zal ik ze alletwee bespreken in dit hoofdstuk. Deze pilot werd, volgens de eerste planning, een week te laat begonnen. Er zijn drie weken voor uitgetrokken. Op moment van schrijven moeten de tests nog worden gedaan, over de test en evaluatie valt van deze pilot dus helaas niks te zeggen.

47

7.1 Reikwijdte In de evaluatie van pilot 2 is een herziening van de definitiestudie wederom niet nodig geacht. De reikwijdte van pilot 3 en 4 als deel van het entiteitenmodel werd dan ook overgenomen uit de definitiestudie:

Project Task



Cost_code

Week

Figuur: reikwijdte pilot 3 & 4

In het bovenstaande model staan twee lichtgrijze entiteiten, Cost_code en ProjectTask, dit zijn entiteiten die in de eerste en tweede pilot ingevoerd zijn. In de derde en vierde pilot ontstaat dus een koppeling met de functionaliteit van de eerste twee pilots. De volgende globale systeemeisen werden in deze pilots ontwikkeld: SE1: Projectmanagers moeten weekstaten kunnen goedof afkeuren voordat deze gefactureerd mogen worden. SE2: Projectmedewerkers moeten gewerkte uren per projecttoewijzing kunnen registreren via een externe site. IE1: De interface van de te maken gedeeltes dienen overeen te komen met de huidige Sage CRM interface. De huidige Sage CRM interface stijl zal worden gebruikt. IE2: Het systeem dient in meerdere talen beschikbaar te zijn, in ieder geval Engels en Nederlands. ITE1: De inhoud van elk formulier wordt, voor deze opgeslagen wordt, gecontroleerd op correctheid (Validatie van gegevens). ITE2: Mocht, bij het ophalen van gegevens, corrupte informatie tevoorschijn komen wordt dit direct gemeld.

48

7.2 Ontwerp Ook bij deze pilots werd als eerste een concept entiteitendefinitie gemaakt voor de eerste workshop. Bij het maken van dit concept werd het huidige urenregistratie als voorbeeld gebruikt. Deze werkt naar behoren, maar is deel van een ander systeem. In de eerste workshop werd het concept besproken waarin de volgende paar discussiepunten het noemen waard zijn: -

Moet het voor medewerkers mogelijk zijn uren te registreren op projecten waar ze geen taken hebben toegewezen?

Het kan voorkomen dat tijdens een project door omstandigheden een andere medewerker bepaalde taken moet verrichten voor een collega. Hij moet deze uren uiteraard ook registreren. Als het systeem medewerkers alleen het registreren van uren op taken waarop ze zijn ingepland toestaat is dit niet mogelijk tenzij deze medewerker ook wordt toegevoegd aan het project en een taak krijgt aangewezen. De andere optie is om het systeem geen controle te laten maken op de projecten en dit de managers laten doen. Aangezien het systeem juist werkzaamheden moet automatiseren is besloten voor de eerste optie. Mocht bovenstaand scenario zich voordoen moet de projectmanager de betreffende medewerker toevoegen en een taak toewijzen. -

Hoe verloopt het proces van invoeren van weekstaat tot het sluiten van een weekstaat?

Het is van belang te weten welke fasen een weekstaat kan doorlopen eer deze gesloten wordt. Om dit te illustreren is gebruik gemaakt van een diagram dat sterk lijkt op een toestandsdiagram in UML. Dit diagram is voor iedereen duidelijk en het proces welke een weekstaat doorloopt is duidelijk te volgen.

Invoer medewerker Niet ingevoerd

Goedkeuring manager

Gesloten door manager Goed gekeurd

Ingevoerd

Gesloten

Afkeuring manager

Wijzigingen medewerker

Afgekeurd

Figuur: proces van invoeren tot sluiten van een weekstaat

-

Moet de externe website zo worden ontwikkeld dat deze naast Internet Explorer ook in Firefox (de twee populairste browsers, Sage CRM werkt alleen in de eerste) werkzaam is?

Naast het feit dat de layout en functionaliteit van de website strikt gescheiden moet zijn vanwege de eventuele wensen van de klant moet er ook rekening worden gehouden met de voorkeur voor browsers van deze klanten. Firefox is een alternatief op Internet Explorer die de laatste tijd steeds meer wordt gebruikt. Helaas interpreteren beide de code van de website niet hetzelfde. In de code dient dus rekening gehouden te worden met dit verschil wil de website in beiden te gebruiken zijn. Vanwege de eerder genoemde groeiende populariteit van alternatieven op Internet Explorer wordt besloten om de website voor in ieder geval de bovenstaande browsers te ontwikkelen.

49

Over het algemeen liep deze workshop vlot en was er al gauw een entiteitendefinitie en een idee voor de weekstaatinvoer. Er werd dan ook gelijk begonnen met het bouwen van deze pilots, ook met het oog op de resterende tijd.

50

7.3 Bouw De bouw van de pilots begon met het invoeren van de weekentiteit en bijbehorende pagina in Sage CRM welke, na het selecteren van de eerste dag van week 1, automatisch de weeknummers voor het gehele jaar uitrekent. Deze functie moest zelf gemaakt worden daar Sage CRM dit niet heeft. Er waren wat problemen met het feit dat de laatste week niet altijd goed werd getoond. Dit kwam omdat sommige dagen van de laatste week van een jaar in het volgende jaar vallen. De functie bestond uit een loop-constructie en de oplossing voor dit probleem was het uitvoeren van een laatste loop om ook de laatste week van het jaar zichtbaar te krijgen.

Figuur: voorbeeld van de uitvoer van de berekening wanneer deze voor het jaar 2007 wordt gedaan

Nu werd het mogelijk om aan de hand van deze weeknummers per medewerker weekstaten op te slaan. De volgende actie was dan ook het maken van de overige entiteiten en er kon begonnen worden aan de website. Bij het installeren van het Sage CRM pakket was de mogelijkheid om een demonstratie website die in verbinding staat met Sage CRM te installeren. Deze website is gemaakt in ASP. Het liefst wilden zowel ik als de opdrachtgever de nieuwe site in het nieuwere ASP.NET maken, daar de mogelijkheden van die programmeertaal groter zijn dan die van de originele ASP. Het moest dan wel mogelijk zijn om d.m.v. ASP.NET code verbinding te maken met Sage CRM. Met de demonstratie website als voorbeeld lukte me het al gauw om met een ASP pagina verbinding te maken. Hetzelfde kon niet worden gezegd van de ASP.NET pagina. Om een reden die mij onbekend is werd er niet goed verbinding gemaakt met Sage CRM. Na een volle dag proberen werd besloten dit idee voorlopig te laten wat het is en de site in ASP te maken. Later kan dan altijd nog worden besloten het geheel naar ASP.NET te converteren wat niet al te veel werk zou moeten zijn.

51

Het maken van de website werd zoals gezegd gedaan in ASP met daarbij Javascript voor de functionaliteit en HTML en CSS voor de opmaak van de website. In een CSS bestand kan de layout van een site worden gedefinieerd. Voor een andere layout hoeft in principe dan alleen dit bestand worden aangepast zonder verder aan de website te komen. Het maken van de website was niet ingewikkeld maar wel tijdrovend, vooral vanwege deze aparte layout en het feit dat de website in verschillende browsers goed moest werken. Heel veel tijd is opgegaan aan het kijken hoe de site in deze verschillende browsers wordt getoond en hoe de verschillen rechtgetrokken kunnen worden. De laatste activiteit van deze fase is het maken van de functionaliteit in Sage CRM. Via de website werden de weekstaten al gevuld, deze moesten worden getoond in Sage CRM zodat project managers deze konden beoordelen. Het maken van deze functionaliteit verliep, mede door eerder opgedane ervaring en gemaakte fouten, zonder problemen.

Figuur: overzicht van weekstaten voor een gekozen week met daaronder de medewerkers die nog geen weekstaat hebben ingevoerd, welke afgekeurd zijn en welke nog niet beoordeeld

Figuur: voorbeeld van een weekstaat welke nog niet beoordeeld is

De pilots zijn klaar voor de eerste tests, zoals gezegd moeten deze op het moment van schrijven nog uitgevoerd worden.

52

8. Evaluatie Als laatste wil ik in dit verslag een evaluatie geven van de afgelopen afstudeerperiode. Deze evaluatie is opgedeeld in twee delen: evaluatie van het product en evaluatie van het proces. Welke zaken gingen goed, welke niet en welke zaken zou ik anders doen in een volgend project.

8.1 Het product Ondanks dat het product niet geheel af is ben ik toch tevreden over het resultaat. Ik heb tijdens de afstudeerperiode mezelf bekend gemaakt met een voor mij volledig vreemde applicatie en daarin een goed en degelijk product volgens de wensen en eisen van de opdrachtgever ontwikkeld. Het werken met webapplicaties is voor mij op dit moment de beste keuze op het gebied van Informatica en specifiek applicatie ontwikkeling. Ondanks dat ik tijdens de eerste stage ook een webapplicatie heb moeten maken was deze ervaring heel anders. Ik heb de voor- en nadelen van het ontwikkelen in een bestaand systeem ondervonden en de werkwijze is anders dan bij een systeem dat van de grond af opgebouwd wordt. Waar ik bijzonder trots op ben is de module vrijwel naadloos is geïmplementeerd en iemand die niet bekend is met het systeem zou denken dat de module standaard bij de applicatie hoort. Verder is de ontwikkeling van de website, ondanks tijdrovend werk, naar mijn inziens ook geslaagd. Minder te spreken ben ik over het feit dat ik niet alles af heb kunnen krijgen. Waarschijnlijk was de planning die aan het begin van het project gemaakt is te optimistisch en wilde ik te graag alles in de afstudeerperiode ontwikkeld krijgen. Het plannen van tijd voor een IT-project blijft een moeilijke opgave, maar met elke keer dat het gedaan wordt moet het beter gaan. Als laatste ben ik ook blij dat de opdrachtgever tevreden is met het opgeleverde product. Zelfs zo tevreden dat ik een baan aangeboden heb gekregen waarin ik start met het verder ontwikkelen van deze module.

8.2 Het proces Het proces van opdrachtomschrijving tot oplevering is in mijn ogen ook goed verlopen. Ik had het geluk dat de opdrachtgever kennis van zaken had en de eisen van het systeem goed in het hoofd had en tevens ook veel beschikbaar. Hier heb ik van geprofiteerd door veel workshops (discussie/brainstorm) te organiseren met de opdrachtgever en andere collega’s die betrokken zijn bij het project. Ik denk dat deze workshops de basis van het succes van het systeem vormen. Verder heb ik zoveel mogelijk gestructureerd proberen te werken zoals mij dat geleerd is op school. Ik moet zeggen dat door een goed afgewogen gebruik van de IAD methode deze fijn werkt, ook in een kleinschalig project als deze. Bij mijn eerste stage had ik meer problemen bij het volgen van deze methode doordat ik teveel de regels volgde en te weinig aanpaste aan de situatie. Ook ben ik het project gestart met het volgen van de ontwerptechniek Yourdon, echter kwam ik er na de eerste pilot achter, mede na een bespreking met de opdrachtgever, dat deze techniek in dit project niet zinvol blijkt te zijn. Het volgen van een ontwerptechniek kan zeer nuttig zijn, maar in sommige gevallen ook heel veel dubbel werk betekenen. Ik heb afgezien van een uiterst gedetailleerd ontwerp zoals ook op school is geleerd. In mijn ervaring is veel van dit werk de tijd die het kost niet waard. Vooral niet in projecten van deze omvang. De opdrachtgever gaf mij hier gelijk in en de huidige mate van detaillering in het ontwerp heeft goed gewerkt. Wel is het noodzakelijk om gemaakte code te voorzien van commentaar zodat een andere ontwikkelaar snel zicht kan krijgen op de werking van de code.

53

Bijlagen Afstudeerverslag Project budget bewaking en urenregistratie in Sage CRM

Erik Vleugel (20010492) 11-01-2006

54

Bijlage A: Begrippenlijst Customer Relationship Management (CRM): Definitie – ‘Het continu en systematisch aangaan en ontwikkelen van relaties met individuele klanten teneinde wederzijdse voordelen te identificeren en te creëren.’ Omschrijving - CRM is een bedrijfsstrategie waarin de klant centraal staat. Dit houdt in dat er gestreefd wordt naar klantgerichter opereren. Om een relatie met de klant aan te gaan moet de organisatie in staat zijn de behoeften en wensen van een specifieke klant in kaart te kunnen brengen, omdat de organisatie de klant zo goed mogelijk moet leren kennen en begrijpen. De onderneming streeft er immers naar concurrentievoordeel te behalen door beter in te spelen op de behoefte van de klant. Bron: http://www.crmbegrippen.nl Voor meer informatie over CRM zie o.a.: http://crm.pagina.nl/ MKB: Midden- en kleinbedrijf. Ondernemingen met maximaal 250 werknemers. Het kleinbedrijf heeft maximaal 50 werknemers. 99% van de ondernemingen in Nederland behoort tot het MKB. Opportunity: Deze term wordt in het Sage CRM pakket gebruikt. Met een opportunity wordt een mogelijke verkoop van producten of diensten bedoelt. Zo kunnen er voor een opportunity meerdere offertes worden verstuurd. Zodra een offerte wordt getekend is er een product of dienst verkocht. Professional Services Dienstverleners: Organisaties die gericht zijn op het verlenen van diensten aan andere organisaties en individuen. Hierbij moet worden gedacht aan informatie technologie (IT), logistiek, consulting, detachering, etc. Sage CRM: Web-based CRM applicatie van ontwikkelaar Sage waarin het mogelijk is voor ontwikkelaars om extra modules toe te voegen en tot op zekere hoogte de bestaande functionaliteit aan te passen. Voor een uitgebreide beschrijving van Sage CRM zie de externe bijlage: ‘Sage CRM’. Web-based: Een web-based programma is via het Internet toegankelijk. Meestal dient de gebruiker d.m.v. een wachtwoord eerst in te loggen voor deze gebruik kan maken van de diensten die het programma biedt om zodoende onbevoegden te weren. Het programma is geïnstalleerd op een computer (web server) die het gebruik van het programma mogelijk maakt (denk o.a. aan databaseconnecties) en is toegankelijk d.m.v. een Internetconnectie en een standaard webbrowser.

55

Bijlage B: Projectdocumentatie Plan van Aanpak Definitiestudie Pilotontwikkelplannen pilots 1 t/m 4

56

Plan van Aanpak Sage CRM Module voor MKB

57

Inhoudsopgave Plan van Aanpak 1.

Opdrachtomschrijving ...................................................................................................... 59 1.1 Opdrachtgever(s)...................................................................................................... 59 1.2 Uitvoerenden ............................................................................................................ 59 1.3 Probleemstelling....................................................................................................... 59 1.4 Doelstelling .............................................................................................................. 60 1.5 Uitgangssituatie........................................................................................................ 60 1.6 Werkzaamheden: fasering en activiteiten ................................................................ 61 1.7 Methoden en technieken........................................................................................... 62 1.8 Resultaten / op te leveren producten ........................................................................ 62 1.9 Planning.................................................................................................................... 62 2. Afbakening Opdracht ....................................................................................................... 63 3. Randvoorwaarden............................................................................................................. 63 4. Risicofactoren................................................................................................................... 63 5. Projectorganisatie ............................................................................................................. 64 6. Wijze van rapporteren ...................................................................................................... 64 7. Benodigde mensen/middelen ........................................................................................... 64 8. Mijlpaalproducten ............................................................................................................ 65

58

1. Opdrachtomschrijving 1.1

Opdrachtgever(s)

CBS Solutions B.V. Stationspark 500 3364 DA Sliedrecht 0184-425920 CBS Solutions B.V. levert CRM systemen voor sales, marketing, support en service organisaties. CBS Solutions B.V. heeft meer dan 10 jaar ervaring in nationale en internationale projecten. Naast het leveren van CRM systemen verzorgt CBS Solutions B.V. ook het in kaart brengen van de bedrijfsprocessen, het inventariseren van de functionele behoeften en scannen als onafhankelijke leverancier de markt voor de juiste oplossing. CBS Solutions B.V. ondersteunt ook de organisatorische implementatie van CRM. CBS Solutions B.V. bestaat op het moment uit 15 medewerkers. De afstudeerder komt te werken op de afdeling projecten. Definitie CRM: Customer Relationship Management is een business strategie die de relatie met de klant als uitgangspunt neemt. De klant staat centraal in de bedrijfsvoering, in plaats van het product of het proces. De onderneming probeert zijn concurrentie positie te verbeteren door beter in te spelen op de wensen van de klant. CRM streeft naar klantgerichtheid, klantentevredenheid klantenloyaliteit.

1.2

Uitvoerenden

Erik Vleugel (Studentnummer: 20010492) Koningsweer 35 3363 XE Sliedrecht [email protected] De student zal tijdens de afstudeerperiode worden bijgestaan door de volgende personen bij CBS Solutions B.V.: Edwin Quarles van Ufford – Technisch Directeur (contactpersoon) Perry Meertens – Business Consultant (begeleiding ontwerpfase) Mehdi Du Puy – Business Consultant (begeleiding ontwerpfase) Peter Verhey – CRM Consultant (begeleiding realisatiefase)

1.3

Probleemstelling

Binnen het MKB is CRM een te dure oplossing vanwege de hoeveelheid maatwerk die nodig is om standaardsystemen passend te maken. Om CRM toegankelijker voor het MKB te maken wordt deze markt in branches (verticals) opgesplitst.

59

1.4

Doelstelling

Het doel van de afstudeeropdracht is het ontwikkelen van een specifieke branchegerichte CRM module voor het MKB. De gekozen branche is die van professional services dienstverleners die gebruik maken van projecten en urenregistratie. Dit zal in samenwerking met consultants binnen CBS Solutions B.V. worden uitgevoerd. Dit product zal door CBS Solutions worden verkocht aan eventuele klanten in het MKB. Er zal gebruik worden gemaakt van CRM software van Sage. CBS Solutions heeft een contract met Sage waarmee gebruik kan worden gemaakt van de Sage CRM software. Het product zal een specifieke toevoeging (module) zijn op de bestaande Sage CRM software. De volgende zaken zullen in het product ontwikkeld worden: - project budget bewaking - urenregistratie - facturering

1.5

Uitgangssituatie

a. Benodigde software

Sage CRM Software

Microsoft Visual Studio .NET

b. Benodigde hardware c. Beschikbare rapporten

Marktanalyse om het segment te bepalen, gemaakt door de sales-medewerkers van CBS Solutions B.V.

Trainingmateriaal Sage CRM Software

Documentatie Sage CRM Software

d. Aanwezige ideeen De aanwezige ideeën staan verwoord in het marktanalyserapport

60

1.6

Werkzaamheden: fasering en activiteiten

Fase 1: Oriëntatie / Analyse In deze fase zal de student zich bekend maken met: - de organisatie - de Sage CRM Software - CRM in het algemeen Het volgende zal opgeleverd worden: - Plan van Aanpak

Fase 2: Definitiestudie In deze fase zal de definitiestudie worden gemaakt. Deze bestaat, naast het Plan van Aanpak, uit de volgende onderdelen: - Ontwikkelscenario - Systeemeisen - Systeemconcept - Technische structuur - Organisatorische inrichting - Pilotplan

Fase 3: Pilotontwikkeling Per pilot zullen de volgende onderdelen aan bod komen: - Plan van Aanpak - Pilotontwerp-workshop - Specificatie globale functionele en technische structuur - Pilotontwikkelplan - Ontwerp software-bouweenheden - Bouw software-bouweenheden - Documenteren software-bouweenheden (handleiding, opleidingsmateriaal en invoeringsprocedures) - Testen software-bouweenheden

Fase 4: Overdracht -

Overdracht systeem en systeemdocumentatie

Aanvullende opmerkingen: -

-

Er zijn op dit moment geen klanten voor dit product. Er zal in de loop van de afstudeerperiode wel begonnen worden met het aantrekken van klanten door de sales afdeling. Invoering van het product bij klanten is geen onderdeel van de opdracht. Het product moet wel invoeringsgereed zijn. Het product zal lokaal op servers van CBS Solutions B.V. worden ontwikkeld

61

1.7

Methoden en technieken

CBS Solutions B.V. maakt gebruik van de volgende technieken: - IMAP (Information Mapping) - Flowcharts - EER Diagrammen - Yourdon - UML - Interviewtechnieken Het gehele project zal volgens de IAD methode worden uitgevoerd.

1.8

Resultaten / op te leveren producten

De student zal tijdens de afstudeerperiode de volgende producten opleveren: - Plan van Aanpak - Definitiestudie - Pilotontwikkelplannen - Testscenario’s met bijbehorende testresultaten - CRM module gericht op de gedefinieerde branche - Gebruikershandleiding - Systeemdocumentatie

1.9

Planning

Fase 1: Orientatie / Analyse - 5 dagen Fase 2: Definitiestudie (15 dagen) - Ontwikkelscenario – 4 dagen - Systeemeisen – 2 dagen - Systeemconcept – 3 dagen - Technische structuur – 1 dag - Organisatorische Inrichting – 1 dag - Pilotplan – 4 dagen Fase 3: Pilotontwikkeling (50 dagen) - Plan van Aanpak – 3 dagen - Pilotontwerp-workshop – 2 dagen - Specificatie globale functionele en technische structuur – 5 dagen - Pilotontwikkelplan – 5 dagen - Ontwerp software-bouweenheden – 15 dagen - Bouw software-bouweenheden – 15 dagen - Documenteren software-bouweenheden (handleiding, opleidingsmateriaal en invoeringsprocedures) – 3 dagen - Test software-bouweenheden – 2 dagen Fase 4: Overdracht – 5 dagen

62

2. Afbakening Opdracht Met betrekking tot de bezigheden zal het project zich hoofdzakelijk beperken tot het vervullen van de opdracht zoals beschreven is in de opdrachtomschrijving. Dit omvat in het kort het volgende: -

Ontwikkelen van een specifiek MKB-component binnen de Sage CRM software. Dit component bestaat uit project budget bewaking met daarbij urenregistratie en facturering van dezen. Ontwikkelen van een Self Service site voor werknemers die niet noodzakelijk in Sage CRM hoeven te werken, maar wel informatie in het systeem moeten schrijven. Schrijven van gebruikersdocumentatie, dit is een addendum op de al aanwezige Sage CRM documentatie.

Deze delen zullen in de definitiestudie en pilotontwikkeling verder in detail worden uitgewerkt.

3. Randvoorwaarden De volgende randvoorwaarden zijn op het project van betrekking: - Documentatie van het Sage CRM pakket dient ten allen tijde beschikbaar te zijn voor inzage - De begeleiders en/of Sage CRM experts binnen CBS Solutions dienen minstens 1 maal per week te bereiken zijn voor vragen en/of bespreking t.b.v. het project

4. Risicofactoren Risicofactor Dataverlies door hardof softwarefalen

Tijdverlies door ziekte of andere omstandigheden

Verandering van eisen aan het project

Risico-omschrijving Het kan voorkomen dat de hardof software op de ontwikkelcomputer faalt en daarmee informatie verloren gaat. Tijdens het project is het mogelijk dat uitvoerenden van het project of andere personen die kritisch zijn voor de voortgang van het project langdurig afwezig zijn. Tijdens systeemontwikkeling komt het vaak voor dat de eisen aan het systeem worden veranderd of er extra eisen worden toegevoegd.

63

Risico-opvang Door elke dag een back-up van alle belangrijke informatie te maken en documenten waarin gewerkt wordt regelmatig op te slaan moet het verlies van informatie tot een minimum worden beperkt. Door het maken van een ruime planning wordt eventueel tijdverlies ingecalculeerd. Tevens wordt gezorgd dat, voor het project, belangrijke personen altijd vervangers hebben die bij afwezigheid in kunnen springen.

Voordat het systeem gebouwd gaat worden, worden de eisen aan het systeem uitvoerig besproken en vastgelegd. Wijzigingen aan deze eisen die veel werk met zich meebrengen worden pas uitgevoerd als er wordt vastgesteld dat het gehele project niet in gevaar komt. Verder zal in de planning tijd worden ingecalculeerd voor eventuele wijzigingen.

5. Projectorganisatie Het project zal worden uitgevoerd door: Erik Vleugel Adres:

Koningsweer 35 3363 XE, Sliedrecht Telefoon: 06 22 53 32 97 E-mail: [email protected] of [email protected]

6. Wijze van rapporteren Het project wordt op het kantoor van de opdrachtgever gerealiseerd. Elke twee weken zal er een voortgangsverslag per e-mail aan de projectbegeleider worden gestuurd zodat deze controle heeft over het project en deze eventueel kan bijsturen. Projectdocumentatie zal per e-mail aan de betrokken personen worden gestuurd ter beoordeling. Eventuele noodzakelijke aanpassingen worden gedaan en het document wordt opnieuw gestuurd ter beoordeling. Dit proces herhaalt zich tot het document is goedgekeurd.

7. Benodigde mensen/middelen Mensen: De volgende personen zijn van belang voor het succesvol afronden van het project: Naam Edwin Quarles van Ufford Perry Meertens Mehdi Du Puy Peter Verheij

Functie Projectbegeleider en tester Consultant functionele inhoud en tester Consultant functionele inhoud Consultant technische inhoud en tester

Middelen: De middelen die benodigd zijn voor de volledige correcte en succesvolle afronding van de opdracht zijn te vinden in de paragraaf 1.5 ‘Uitgangssituatie’

64

8. Mijlpaalproducten De volgende mijlpaalproducten zijn gedefinieerd: Product(en) Plan van Aanpak Definitiestudie Project budget bewaking binnen Sage CRM Urenregistratie van projecten binnen Sage CRM Self Service Site voor projectmanagement en urenregistratie Facturering projecten binnen Sage CRM Documentatie

Afleverdatum Dinsdag 13 september Vrijdag 21 oktober Vrijdag 2 december Vrijdag 23 december Vrijdag 23 december Vrijdag 6 januari Vrijdag 13 januari

65

Definitiestudie

66

Inhoudsopgave Definitiestudie 1.

Plan van Aanpak............................................................................................................... 68 1.1 Reikwijdte ................................................................................................................ 68 1.2 Resultaten ................................................................................................................. 68 1.3 Kwaliteitsborging ..................................................................................................... 68 1.4 Projectstructuur ........................................................................................................ 69 1.5 Tijdschatting............................................................................................................. 69 1.6 Faseplanning............................................................................................................. 70 2. Ontwikkelscenario............................................................................................................ 71 2.1 Impact....................................................................................................................... 71 2.2 Cruciale succesfactoren............................................................................................ 71 2.3 Ontwikkelproces....................................................................................................... 72 2.4 Globale pilotstrategie ............................................................................................... 73 2.5 Globale strategie hergebruik en externe acquisitie .................................................. 74 2.6 Globale teststrategie ................................................................................................. 74 3. Systeemeisen .................................................................................................................... 75 3.1 Basissysteemeisen .................................................................................................... 75 3.2 Interface-eisen .......................................................................................................... 76 3.3 Integriteitseisen ........................................................................................................ 76 3.4 Performance-eisen .................................................................................................... 76 3.5 Operationele eisen .................................................................................................... 76 4. Systeemconcept................................................................................................................ 77 4.1 Globale actoren ........................................................................................................ 77 4.2 Globaal gegevensmodel ........................................................................................... 78 5. Technische structuur ........................................................................................................ 79 5.1 Technologische basis................................................................................................ 79 5.2 Systeemconfiguratie ................................................................................................. 79 6. Organisatorische inrichting .............................................................................................. 80 6.1 Werkstroom.............................................................................................................. 80 6.2 Opleidingsdoelstellingen en vereiste gebruikersdocumentatie ................................ 80 7. Pilotplan ........................................................................................................................... 81 7.1 Pilotstructuur ............................................................................................................ 81 7.2 Structurering pilotontwikkeling ............................................................................... 81 7.3 Prioritering pilots...................................................................................................... 81 7.4 Pilotacceptatieplan ................................................................................................... 81 7.5 Invoeringsplan .......................................................................................................... 82

67

1. Plan van Aanpak 1.1

Reikwijdte

Zoals te lezen is in het ontwikkelscenario (zie hoofdstuk 2) is er gekozen voor de ontwikkelstrategie incrementeel opleveren. Dit betekent dat de fase definitiestudie één keer voorkomt met als gevolg dat de reikwijdte van deze definitiestudie het gehele project omvat. De doelstellingen van deze definitiestudie zijn het analyseren van de probleemstelling en doelstellingen, zoals verwoord in het algemene Plan van Aanpak.

1.2

Resultaten

De fase definitiestudie heeft als resultaat een heldere definiëring van het uit te voeren project met daarin de eisen en wensen, een eerste systeemconcept en een uitgewerkt pilotplan van waaruit verder ontwikkeld zal worden.

1.3

Kwaliteitsborging

Om te zorgen dat het uiteindelijke product voldoet aan de eisen van de opdrachtgever, zal deze opdrachtgever nauw betrokken worden bij het ontwikkelproces. Voordeel is dat het product ‘binnenshuis’ wordt ontwikkeld; de uitvoerende van het project werkt op het kantoor van de opdrachtgever. Naast vaste workshops en besprekingen maakt dit ook korte besprekingen ‘in de wandelgangen’ mogelijk. Een ander punt dat een positieve invloed kan hebben op de kwaliteitsborging is het feit dat het te ontwikkelen product web-based is. De werkgever kan hierdoor altijd het, in ontwikkeling zijnde, product bekijken en eventuele op- of aanmerkingen doorspelen naar de ontwikkelaar. Concreet moet aan de volgende punten voldaan worden om de kwaliteit te waarborgen: - tweewekelijks voortgangsoverleg met de personen die bij het project betrokken zijn - documenten dienen goedkeuring te krijgen van de betrokken personen voor er doorontwikkeld wordt - als een mijlpaal wordt bereikt (zoals het afsluiten van een pilot) zal deze, aan de hand van een testscenario, uitgebreid worden getest

68

1.4

Projectstructuur

Het project wordt uitgevoerd door de afstudeerder. Om het project succesvol af te kunnen ronden is de medewerking van de volgende personen bij de opdrachtgever noodzakelijk: - Edwin Quarles van Ufford (Projectbegeleider, consultant functionele inhoud en tester) - Perry Meertens (Consultant functionele inhoud en tester) - Mehdi Du Puy (Consultant functionele inhoud) - Peter Verheij (Consultant technische inhoud en tester)

1.5

Tijdschatting

In het onderstaande schema is de tijdschatting voor deze definitiestudie te vinden. Per onderdeel van de definitiestudie zal het geschatte aantal uur dat nodig is van de uitvoerder en de diverse functionarissen worden gegeven. Hierbij geldt dat acht uur één werkdag is. Onderdeel Ontwikkelscenario Systeemeisen Systeemconcept Technische structuur Organisatorische inrichting Pilotplan

Uren uitvoerder 24 16 40 8 8 24

Uren functionarissen 2 6 16 1 1 8

Totaal

120

34

De uren die bij de functionarissen staan zullen worden ingevuld door het reviewen van documenten met het geven van feedback en de diverse workshops die worden gehouden t.b.v. de definitiestudie.

69

1.6

Faseplanning

Uit de bovenstaande tijdschatting volgt deze faseplanning: Datum 15-09-2005

Product Concept Ontwikkelscenario

16-09-2005

Concept Systeemeisen

22-09-2005

Eerste versie Systeemconcept

23-09-2005

Workshop

06-10-2005 13-10-2005

Concept Technische structuur en organisatorische inrichting Workshop

14-10-2005

Concept Pilotplan

19-10-2005

Workshop

21-10-2005

Definitieve versie definitiestudie

Opmerking Ter beoordeling door functionarissen voor workshop 23-09-2005. Ter beoordeling door functionarissen voor workshop 23-09-2005. Ter beoordeling door functionarissen voor workshop 23-09-2005. Workshop waarin met de betrokken functionarissen het concept ontwikkelscenario, concept systeemeisen en de eerste versie van het systeemconcept worden besproken. Resultaat van deze workshop is een voorlopig ontwikkelscenario, systeemeisen en systeemconcept. Ter beoordeling door functionarissen voor workshop 13-10-2005. Workshop waarin met de betrokken functionarissen de voorlopige ontwikkelscenario, systeemeisen en systeemconcept nogmaals worden besproken met als doel een uiteindelijke versie. Ook worden de concepten van de technische structuur en organisatorische inrichting alsmede het voltooide deel van het pilotplan besproken. Concept pilotplan (evt. aangepast n.a.v. workshop 13-10-2005) Workshop waarin het concept pilotplan wordt besproken. Eventueel worden eerdere delen van de definitiestudie nogmaals besproken en/of herzien. Doel van deze workshop is een definitieve versie van de definitiestudie. Er wordt begonnen aan de pilotontwikkeling zoals beschreven in het pilotplan.

NB: van 26-09 t/m 04-10 en op 07-10 worden er geen werkzaamheden verricht vanwege afwezigheid van de projectuitvoerder.

70

2. Ontwikkelscenario 2.1

Impact

Implementatie van het systeem is geen deel van dit project. Er kan echter wel wat worden gezegd over de mogelijke impact van het systeem mocht deze worden geïmplementeerd. Doordat het te maken product deel is van een breder pakket dat bedrijfsbreed moet worden ingevoerd zal de impact op de organisatie groot zijn. Alle gebruikers dienen geschoold te worden in het nieuwe pakket en veel procedures zullen worden aangepast aan het nieuwe systeem. Als het basispakket al ingevoerd is en alleen de te maken module wordt ingevoerd betekent dit herscholing van projectmanagers en projectmedewerkers en het aanpassen van procedures die te maken hebben met projectmanagement en urenregistratie.

2.2

Cruciale succesfactoren

Er is geen sprake van contractueel vastgelegde eisen. Desondanks kan er wel iets worden gezegd over de cruciale succesfactoren van het project. Om het project succesvol te kunnen noemen moeten, aan het eind van de projectperiode, op zijn minst de volgende mijlpalen worden bereikt: - Volledige definitiestudie - Project budget bewaking binnen Sage CRM - Urenregistratie op projecten via Self Service pagina De precieze inhoud van de laatste twee mijlpalen worden uitgewerkt in het systeemconcept en pilotplan.

71

2.3

Ontwikkelproces

Het project zal volgens de iteratieve ontwikkelstrategie ‘incrementeel opleveren’ worden ontwikkeld.


Deze keuze is gemaakt aan de hand van een aantal factoren: - klein informatiesysteem - kleine, stabiele projectomgeving - systeemeisen zijn bekend - intern project, wat veel betrokkenheid van (eind)gebruikers kan betekenen - web-based ontwikkeling (gemakkelijke invoering) - geen specifieke haast gemoeid met het project Mocht het zo zijn dat tijdens het project de definitiestudie niet toereikend meer blijkt te zijn dan zal deze worden herzien. Als deze kenmerken in een tabel worden uitgezet tegen de vier iteratiestrategieën is dit het resultaat: Evolutionair ontwikkelen Klein informatiesysteem Kleine, stabiele projectomgeving Bekende systeemeisen Veel betrokkenheid Web-based (gemakkelijke invoering) Geen specifieke haast

++ = erg goed

-++ + + = goed

Incrementeel opleveren

+ + ++ + leeg = neutraal


Big-bang invoeren

+

+

++ -

+

- = slecht

- - = erg slecht

Uit deze tabel blijkt dat de iteratiestrategie ‘incrementeel opleveren’ voor dit project de beste keuze is.

72

2.4

Globale pilotstrategie

Eerste systeemdecompositie: Product Stamtabellen invoeren Onderhoud stamtabellen Functionele tabellen invoeren Project budget bewaking Weekstaattabellen invoeren Onderhoud weekstaten binnen Sage CRM Self Service pagina voor invoeren weekstaten door werknemers Facturering weekstaten Rapportage

PBB PBB PBB PBB UR UR UR FA RAP

Pilot Pilot 1 Pilot 1 Pilot 2 Pilot 2 Pilot 3 Pilot 3 Pilot 4

Prioriteit A A A A B B A

Pilot 5 Pilot 2

C A

06-01-2006

30-12-2005

23-12-2005

16-12-2005

09-12-2005

02-12-2005

25-11-2005

18-11-2005

11-11-2005

04-11-2005

28-10-2005

21-10-2005

Time-boxing pilots:

Pilot 1

Pilot 2 Pilot 3

Pilot 4 Pilot 5

NB: Pilot 5 is gedefinieerd als luxe en zal pas worden uitgevoerd als blijkt dat pilot 1 t/m 4 succesvol zijn afgerond en er nog tijd over is binnen het project.

73

2.5

Globale strategie hergebruik en externe acquisitie

Het project wordt ontwikkeld in het Sage CRM pakket. Dit betekent dat de nieuwe functionaliteit aan moet sluiten op de oude. Veel van de bestaande functionaliteit kan als voorbeeld dienen voor de nieuwe functionaliteit; schermen, stukken code, lay-outs, etc. kunnen worden gebruikt. Naast het Sage CRM pakket zullen geen andere externe componenten gebruikt worden.

2.6

Globale teststrategie

Tests worden op verschillende niveaus gedaan: - testen van blokken code tijdens de ontwikkeling door de ontwikkelaar. - testen van pilot aan de hand van een testcase door de betrokken functionarissen. - testen van samenhang tussen pilots, mocht deze bestaan, aan de hand van een testcase door de betrokken functionarissen. Mochten aan de hand van deze tests onvolkomenheden in de programmatuur worden aangetroffen, dan zullen deze zo snel mogelijk worden opgelost en opnieuw getest tot de programmatuur naar behoren werkt.

74

3. Systeemeisen In dit hoofdstuk worden globaal de systeemeisen gedefinieerd. Deze zullen in de pilotontwikkeling tot in detail worden uitgewerkt.

3.1

Basissysteemeisen

BSE1: Projectmanagers moeten projectsjablonen kunnen beheren welke kunnen worden gebruikt als standaardprojecten binnen project budget bewaking. BSE2: Projecten moeten bestaan uit fases die weer een aantal activiteiten hebben. BSE3: Beheerders moeten informatie van bedrijfsmedewerkers kunnen beheren, waarbij een medewerker meerdere functies kan worden toegewezen. BSE4: Beheerders moeten informatie van bedrijfsfuncties kunnen beheren. BSE5: Medewerkers van de financiële afdeling moeten kostencodes kunnen beheren. BSE6: Medewerkers van de financiële afdeling moeten weeknummers per jaar kunnen beheren. BSE7: Projectmanagers moeten nieuwe projecten kunnen definiëren en beheren. Nieuwe projecten worden gemaakt aan de hand van een opportunity, in het geval van een project bij een klant, of op zichzelf staand, in het geval van een intern project. BSE8: Per project moeten de volgende zaken kunnen worden bijgehouden: projectmedewerkers, producten, kosten, contact personen, projecttaken en een documentbibliotheek. BSE9: Projectmedewerkers moeten gewerkte uren per projecttoewijzing kunnen registreren via een externe site. BSE10: Projectmedewerkers moeten declaraties kunnen registreren via een externe site. BSE11: Projectmanagers moeten weekstaten kunnen goedof afkeuren voordat deze gefactureerd mogen worden. BSE12: Projectmanagers en medewerkers van de financiële afdeling moeten facturen kunnen genereren per project, per gedefinieerde periode. Daarbij ook rekening houdende met projectdeclaraties. BSE13: (Project)managers moeten de mogelijkheid hebben om d.m.v. diverse rapportages een overzicht te krijgen van de werkzaamheden binnen het bedrijf.

75

3.2

Interface-eisen

IE1: De interface van de te maken gedeeltes dienen overeen te komen met de huidige Sage CRM interface. De huidige Sage CRM interface stijl zal worden gebruikt. IE2: De interface van het externe Self Service gedeelte moet overeen komen met die van het bedrijf waar het systeem operationeel is. Het is dus noodzakelijk dat functie en interface strikt gescheiden zijn en er verschillende interfaces moeten kunnen worden gedefinieerd zonder de functionaliteit te veranderen. IE3: Het systeem dient in meerdere talen beschikbaar te zijn, in ieder geval Engels en Nederlands.

3.3

Integriteitseisen

Om de integriteit van het systeem te waarborgen zullen de volgende acties worden ondernomen: ITE1: De inhoud van elk formulier wordt, voor deze opgeslagen wordt, gecontroleerd op correctheid (Validatie van gegevens).

ITE2: Mocht, bij het ophalen van gegevens, corrupte informatie tevoorschijn komen wordt dit direct gemeld.

3.4

Performance-eisen

Dit project heeft geen vastgestelde SMART performance-eisen.

3.5

Operationele eisen

OE1: Het systeem dient een toevoeging te zijn op het huidige Sage CRM pakket. Installatie moet mogelijk zijn op een reeds bestaande Sage CRM server. OE2: Het moet mogelijk zijn om door te ontwikkelen op het systeem. Om dit mogelijk te maken zal het systeem een modulaire opzet hebben, waarbij alle onderdelen gemakkelijk aan te passen zijn en toevoegingen op het onderdeel mogelijk zijn. OE3: Het systeem moet via Internet te bereiken zijn.

76

4. Systeemconcept 4.1

Globale actoren

Globaal kunnen de volgende actoren worden gedefinieerd: - Projectmanagers die projecten definiëren en de voortgang bewaken - Projectmedewerkers die aan gedefinieerde projecten werken en hier uren op moeten boeken - Medewerkers van de financiële afdeling die facturen en weekstaten van de projecten willen hebben - Managers die rapportages over projecten en gewerkte uren willen zien

77

4.2

Globaal gegevensmodel Cost_code

ActivityTemplate

Functions

PhaseTemplate

Tariff

Employee

ProjectCost

ProjectTemplate

ProjectMember


CalendarEntry

Person

ProjectActivity

Project Task

ProjectProduct Company Project WeekstateLine

PurchaseLine


Opportunity

Product

Week

Invoice

Project Declaration



78

5. Technische structuur 5.1

Technologische basis

De gekozen third-party-software is Sage CRM. Dit is een CRM pakket dat op een web-server geïnstalleerd wordt en zodoende via Internet te benaderen is. Naast de CRM functionaliteit is er ook een zogenaamde Administration aanwezig, waarin bestaande functionaliteit, tot op zekere hoogte, kan worden aangepast en nieuwe functionaliteit relatief makkelijk kan worden toegevoegd. Het grootste gedeelte van het project zal in dit Administration gedeelte worden uitgevoerd. Naast de Administration om het CRM programma aan te passen is het ook mogelijk om nieuwe pagina’s toe te voegen. Dit gebeurt d.m.v. HTML, ASP en JavaScript. De nieuwe functionaliteit die wordt toegevoegd zal in de vorm van deze ASP-pagina’s zijn. Als laatste is het mogelijk om een externe website te ontwikkelen en deze aan te wijzen als een zogenaamde Self Service site vanuit Sage CRM. De bedoeling van zo’n site is de mogelijkheid te bieden om gebruikers, die in principe geen (dure) lidmaatschap van het Sage CRM pakket hebben, gegevens in te laten voeren die van belang zijn voor het systeem. In feite is het systeemconcept voornamelijk gebaseerd op de mogelijkheden die Sage CRM biedt. Toch zijn er nog bepaalde elementen die de uitvoering van het project in de weg kunnen zitten: - Nieuwe entiteiten (tabellen) moeten in Sage CRM worden gedefinieerd, hierbij wordt voor het datatype een standaard aantal opties gegeven. Het is echter niet mogelijk nieuwe datatypen te definiëren. - Het is mogelijk om de basisfunctionaliteit aan te passen binnen Sage CRM. Veel van deze functionaliteit is echter afgeschermd, zodat men beperkt wordt in de ontwikkeling van een toevoeging aan het systeem. - Het feit dat het programma web-based is geeft vele mogelijkheden in de ontwikkeling, maar biedt helaas ook restricties t.o.v. een lokaal programma.

5.2

Systeemconfiguratie

Zoals gemeld is, is Sage CRM een web-based applicatie. Voor de installatie van het systeem is een webserver met minimaal Windows 2000 en SQL Server 2000 nodig. Clients kunnen van het systeem gebruik maken zolang de webserver via het Internet te bereiken is. Ontwikkeling gebeurt voornamelijk in de Sage CRM omgeving, maar het is ook belangrijk dat de webserver volledig te bereiken is door de ontwikkelaar(s). Deze moet de configuratie van de webserver kunnen veranderen en nieuwe bestanden op de webserver kunnen plaatsen. Aangezien het systeem gericht is op het MKB segment wordt er vanuit gegaan dat er maximaal 100 systeemgebruikers zijn. Zolang de webserver aan de gestelde hardware-eisen, zoals te vinden zijn in de Sage CRM installatiedocumentatie, voldoet worden hier geen problemen mee verwacht.

79

6. Organisatorische inrichting 6.1

Werkstroom

Globale weergave van de werkstroom van het bepaalde MKB segment.

Het systeem heeft impact op de delen ontwikkeling, implementatie en de (financiële) administratie hiervan. Het Sage CRM pakket mist de ondersteuning van projecten en urenregistratie/facturering hierop. Het project moet dit gat opvullen. Hieruit volgt dat het nieuwe systeem impact zal hebben op de werkwijze van projectmanagers, ontwikkelaars, consultants en medewerkers van de (financiële) administratie. Het is echter niet noodzakelijk om de organisatorische inrichting aan te passen.

6.2

Opleidingsdoelstellingen en vereiste gebruikersdocumentatie

Opleiding is geen deel van het project, maar het volgende is wel bekend over de opleidingen: Gebruikersgroep Projectmanagers Projectmedewerkers (Financiële) Administratie Managers

Opleiding Volledig: aanpassen gegevens stamtabellen & gebruik project budget bewaking en urenregistratie Gebruik Self Service urenregistratie Facturering Onderhouden en bekijken van rapportages

Naast de standaard documentatie van het Sage CRM pakket zal een addendum hierop worden gemaakt voor de functionaliteit die het project omvat.

80

7. Pilotplan 7.1 Pilot Pilot 1 Pilot 2 Pilot 3 Pilot 4 Pilot 5

7.2

Pilotstructuur Basissysteemeisen BSE1, BSE2, BSE3, BSE4, BSE5, BSE6 BSE2, BSE7, BSE8, BSE13 BSE11 BSE9, BSE10 BSE12

Structurering pilotontwikkeling

Voor de verwachte kosten per pilot wordt u verwezen naar de time-box in hoofdstuk 2.4 van dit document.

7.3 Pilot Pilot 1 Pilot 2 Pilot 3 Pilot 4 Pilot 5

7.4

Prioritering pilots Prioriteit A A B A C

Pilotacceptatieplan

De acceptatie van een pilot bestaat uit de volgende stappen: - test aan de hand van een testcase door de aangestelde testers - eventuele herziening van de functionaliteit - als de tests goed verlopen dan zal de pilot goed moeten worden gekeurd door Edwin Quarles en Perry Meertens

81

7.5

Invoeringsplan

Door het web-based karakter van het te ontwikkelen product wordt de invoering eigenlijk automatisch gedaan. Echte invoering binnen een operationele omgeving is geen deel van het project, daarom wordt in deze context invoering gezien als een volledig werkend deel dat via Internet te bekijken en testen is en waarop doorontwikkeld kan worden.

82

Pilot 1 Stamgegevens (medewerkergegevens en projectsjablonen)

83

Inhoudsopgave Pilot 1 1.

Plan van Aanpak........................................................................................................................... 85 1.1 Reikwijdte ............................................................................................................................ 85 1.2 Kwaliteitszorg ...................................................................................................................... 86 1.3 Tijdschatting ........................................................................................................................ 86 2. Globaal Functionele Structuur...................................................................................................... 87 2.1 Eventlist ............................................................................................................................... 87 2.2 DFD’s en datadictionary ...................................................................................................... 87 2.3 Gegevensmodel.................................................................................................................... 92 2.4 Aanpassingen externe componenten.................................................................................... 94 3. Pilotontwikkelplan........................................................................................................................ 95 3.1 Definitie Pilotdelen .............................................................................................................. 95 3.2 Beoordeling en test pilotdelen.............................................................................................. 95 3.3 Invoeringsplan...................................................................................................................... 95

84

1. Plan van Aanpak 1.1 Reikwijdte De doelstellingen van deze pilot zijn: - het toevoegen van de Employee entiteit aan Sage CRM - de mogelijkheid de beschikbaarheid per uur per dag van een Employee aan te geven - de mogelijkheid bieden medewerkerfuncties te beheren en deze aan een Employee te koppelen met daarbij de behorende uur- of dagtarieven van die Employee - de mogelijkheid bieden projectsjablonen met onderliggende fases en activiteiten te beheren - de mogelijkheid kostencodes te beheren en deze aan standaard projectactiviteiten te koppelen Bovenstaande punten hebben als resultaat een basis voor de volgende pilot(s). Ter illustratie staat hieronder het deel van de globale entiteitenmodel, die in het geheel in de definitiestudie te vinden is, die in deze pilot aan bod komt:

Reikwijdte pilot in het globale entiteitenmodel

De volgende globale systeemeisen werden in deze pilot ontwikkeld: SE1: Projectmanagers moeten projectsjablonen kunnen beheren welke kunnen worden gebruikt als standaardprojecten binnen project budget bewaking. SE2: Projecten moeten bestaan uit fases die weer een aantal activiteiten hebben. SE3: Beheerders moeten informatie van bedrijfsmedewerkers kunnen beheren, waarbij een medewerker meerdere functies kan worden toegewezen. SE4: Beheerders moeten informatie van bedrijfsfuncties kunnen beheren. SE5: Medewerkers van de financiële afdeling moeten kostencodes kunnen beheren. SE6: Medewerkers van de financiële afdeling moeten weeknummers per jaar kunnen beheren. IE1: De interface van de te maken gedeeltes dienen overeen te komen met de huidige Sage CRM interface. De huidige Sage CRM interface stijl zal worden gebruikt. IE2: Het systeem dient in meerdere talen beschikbaar te zijn, in ieder geval Engels en Nederlands. ITE1: De inhoud van elk formulier wordt, voor deze opgeslagen wordt, gecontroleerd op correctheid (Validatie van gegevens). ITE2: Mocht, bij het ophalen van gegevens, corrupte informatie tevoorschijn komen wordt dit direct gemeld.

85

1.2 Kwaliteitszorg De kwaliteit zal worden gewaarborgd zoals staat beschreven in hoofdstuk 1.3 van de definitiestudie. Inspectiepunten vinden plaats bij de eerste versie van het ontwerp (en evt. volgende versies hiervan), de eerste versie van het product (en evt. volgende versies hiervan) en de uiteindelijke tests.

1.3 Tijdschatting Startdatum van de pilot is 20-10-2005. Datum 27-10-2005 28-10-2005 3-11-2005 4-11-2005 7/8/9-11-2005

Product Ontwerp Pilot Uiteindelijk ontwerp en start bouwen Product pilot 1 Uiteindelijk product pilot 1 Test product pilot 1 en uitloop

86

Tijd functionarissen 2 uur, beoordeling ontwerp 1 uur, beoordeling ontwerp 2 uur, beoordeling product 1 uur, beoordeling product 4 uur, test product

2. Globaal Functionele Structuur Het globale ontwerp van deze pilot wordt gedaan volgens de Yourdon techniek beginnende bij de eventlist en eindigend bij de definitie van kolomnamen van de entiteiten die in de reikwijdte zijn aangegeven.

2.1 Eventlist Eventnr Eventnaam beheerder vraagt 1 medewerkergegevens op beheerder beheert 2 medewerkergegevens beheerder vraagt 3 functiegegevens op beheerder beheert 4 functiegegevens beheerder vraagt 5 kostcodegegevens op beheerder beheert 6 kostcodegegevens

Reactie systeem samenstellen medewerkergegevens vastleggen medewerkergegevens samenstellen functiegegevens vastleggen functiegegevens samenstellen kostcodegegevens vastleggen kostcodegegevens

Invoer medewerker

Uitvoer medewerker gegevens

medewerker gegevens

-

functie

functie gegevens

functie gegevens

-

kostcode

kostcode gegevens

kostcode gegevens

-

7

beheerder vraagt projectsjabloongegevens op

projectsjabloon samenstellen projectsjabloon gegevens projectsjabloongegevens

8

beheerder beheert projectsjabloongegevens

vastleggen projectsjabloon projectsjabloongegevens gegevens

2.2 DFD’s en datadictionary

87

Functies

FUNCTIE FUNCTIEGEGEVENS

Samenstellen functie gegevens

fu nc tie

Kostcodes

ge

functie

ge

Vastleggen functie gegevens

Functies

ve ns

KOSTCODE KOSTCODEGEGEVENS

Samenstellen kostcode gegevens

ko stc od

eg

kostcode

eg ev en

Vastleggen kostcode gegevens

Kostcodes s

pr

oje

b tsja jec pro nge lo o e gev ns

88

ja cts

blo

on

Datadictionary activiteitsjabloon

activiteitsjablonen fasesjabloon fasesjablonen functie functiegegevens kostcode kostcodegegevens medewerker

medewerkergegevens projectsjabloon projectsjabloongegevens selfservice tarief tarieven

= activiteitsjabloonnaam + activiteitsjabloonomschrijving + FUNCTIE + KOSTCODE + mijlpaal + uren + activiteitsjabloonvolgorde = {ACTIVITEITSJABLOON} = fasesjabloonnaam + fasesjabloonomschrijving + fasesjabloonvolgorde + ACTIVITEITSJABLONEN = {FASESJABLOON} = functienaam + functie omschrijving + functie afkorting = FUNCTIE = kostcodenr + kostcodenaam + kostcodegroep + kostcodetype = KOSTCODE = medewerkernaam + adres + postcode + woonplaats + land + telefoonnr + mobielnr + e-mail zakelijk + e-mail persoonlijk + medewerker afkorting + extern + status + wekelijkse contract uren + SELFSERVICE = MEDEWERKER + SELFSERVICE + TARIEVEN = projectsjabloonnaam + projectsjabloonomschrijving + FASESJABLONEN = PROJECTSJABLOON = loginnaam + wachtwoord = FUNCTIE + kostprijs + verkoopprijs + eenheid = {TARIEF}

89

KO

EG TI NC FU

MEDEWERKERGEGEVENS

ST C

EG EV S EN

MEDEWERKERGEGEVENS

1 Medewerkers

EG EG TI S EN EV

NS CT IE G EG EV E

EN S

O LO AB S J N S C T VE J E EG E O R G

N

N

NC

FU N

GE V

OO BL JA NS TS V E EC E OJ EG PR G

FU P

90

GE

2 Kostcodes & Project sjablonen

Functies

DFD 1

OD E

K G OS EG T EV CO EN DE S

DFD 0

DFD 2

k

t os

co

de

Samenstellen kostcode gegevens

Vastleggen kostcode gegevens KOSTCODE

KO GE STC GE OD VE E NS

Kostcodes

pr oj ec ts

KOSTCODE

ja bl oo n

PROJECTSJABLOON GEGEVENS

FUNCTIE

Project sjablonen

Samenstellen project sjabloon gegevens

PROJECTSJABLOON FAS ESJ ABL OON

Functies

Fasesjablonen O BL JA S N TS EC VE OJ GE PR GE

ACTIVITEITSJABLOON

Activiteit sjablonen

ON

91

Vastleggen project sjabloon gegevens

2.3 Gegevensmodel

Tabellen worden in de Sage CRM ontwikkelomgeving gemaakt. Sage CRM biedt een aantal standaard veldtypen welke besproken worden in het externe document ‘Sage CRM ontwikkelomgeving’. Hieronder volgt, per entiteit, een overzicht van velden met het veldtype en of het veld verplicht is. ‘Search Select Advanced’ staat voor een vreemde sleutel (foreign key). Bij dit veldtype wordt de gekoppelde tabel en de on delete actie gegeven.

Employee Emp_ID Emp_Name Emp_Address Emp_ZipCode Emp_City Emp_Country Emp_Phone Emp_MobilePhone Emp_BusinessEmail Emp_PersonalEmail Emp_Abbreviation Emp_External Emp_AvlMonday Emp_AvlTuesday Emp_AvlWednesday Emp_AvlThursday Emp_AvlFriday Emp_AvlSaturday Emp_AvlSunday Emp_HoursWeek Emp_Status Emp_SelfLogin Emp_SelfPassword

Identityfield Text (30), verplicht Text (50) Text (20) Text (30) Text (30) Phone Number (20) Phone Number (20) Email Address (255) Email Address (255) Text (20) Checkbox Multi-Select Multi-Select Multi-Select Multi-Select Multi-Select Multi-Select Multi-Select Integer, verplicht Selection Text (30) Text (17)

92

Functions Fun_ID Fun_Name Fun_Description Fun_Abbreviation

Identityfield Text (30), verplicht Text (255) Text (20), verplicht

Tariff Trf_ID Trf_EmployeeID Trf_FunctionID Trf_InAmount Trf_OutAmount Trf_Unit

Identityfield Search Select Advanced, Employee, on delete cascade Search Select Advanced, Functions, on delete no action (prompt) Currency Currency Selection

Cost_code Cc_ID Cc_Code Cc_Name Cc_Type Cc_Group

Identityfield Text (20), verplicht Text (30), verplicht Selection, verplicht Selection

ProjectTemplate PrT_ID PrT_Name PrT_Description

Identityfield Text (30), verplicht Text (255)

PhaseTemplate Pha_ID Pha_Name Pha_Description Pha_Order Pha_ProjectTemplateID

Identityfield Text (30), verplicht Text (255) Integer Search Select Advanced, ProjectTemplate, on delete cascade

ActivityTemplate Actt_ID Actt_Description Actt_Milestone Actt_Hours Actt_Order Actt_FunctionID Actt_PhaseID Actt_CostCodeID

Identityfield Text (255) Checkbox Integer, verplicht Integer Search Select Advanced, Functions, on delete no action (prompt) Search Select Advanced, PhaseTemplate, on delete cascade Search Select Advanced, CostCode, on delete no action (prompt)

93

2.4 Aanpassingen externe componenten In dit hoofdstuk worden de aanpassingen opgesomd die noodzakelijk zijn in het huidige Sage CRM systeem. -

de entiteit Employee wordt als primary entity toegevoegd de andere entiteiten worden als secondary entity toegevoegd op het hoofdscherm wordt de tab ‘Employee’ toegevoegd aan ‘Data Management’ worden de volgende opties toegevoegd: ‘Functions’, ‘Project Templates’ en ‘Cost Codes’

94

3. Pilotontwikkelplan 3.1 Definitie Pilotdelen Pilotdeel PD1 PD2 PD3

Entiteiten Employee, Functions, Tariff Cost Code Project Template, Phase Template, Activity Template

Bovenstaande pilotdelen worden in die volgorde gebouwd. Een verdere specificatie van bouweenheden en faseplanning is in dit geval niet zinvol gezien de beperkte grootte van de functionaliteit.

3.2 Beoordeling en test pilotdelen De beoordeling wordt uitgevoerd zodra er een concept van het betreffende pilotdeel in het systeem staat. De beoordeling en test wordt gedaan door de, in de definitiestudie gespecificeerde, functionarissen in overleg met de uitvoerder aan de hand van een testscenario.

3.3 Invoeringsplan Er is geen sprake van invoering in de klassieke zin aangezien het een web-based applicatie betreft. Wel wordt per pilotdeel een ‘pakket’ gemaakt die bestaat uit de nieuwe gemaakte pagina’s en de sqlstatements die nodig zijn om het pilotdeel in te voeren.

95

Pilot 2 Project budget bewaking

96

Inhoudsopgave 1.

Plan van Aanpak............................................................................................................... 98 1.1 Reikwijdte ................................................................................................................ 98 1.2 Kwaliteitszorg ........................................................................................................ 100 1.3 Tijdschatting........................................................................................................... 100 2. Globaal Functionele Structuur ....................................................................................... 101 2.1 Functioneel procesmodel........................................................................................ 101 2.2 Prototype Navigatie................................................................................................ 102 2.3 Gegevensmodel ...................................................................................................... 104 2.4 Aanpassingen externe componenten ...................................................................... 108 3. Pilotontwikkelplan ......................................................................................................... 109 3.1 Definitie Pilotdelen ................................................................................................ 109 3.2 Beoordeling en test pilotdelen................................................................................ 109 3.3 Invoeringsplan ........................................................................................................ 109

97

1. Plan van Aanpak 1.1 Reikwijdte De globale doelstellingen van deze pilot zijn: - het toevoegen van de Project entiteit aan Sage CRM - per project moeten de volgende entiteiten worden gekoppeld: projectfasen en –activiteiten, projectmedewerkers, projectkosten, contact personen en projectproducten - het moet mogelijk zijn projectmedewerkers aan activiteiten te koppelen, dit zijn projecttaken. Bij deze taken worden de standaardtarieven van de medewerker gehanteerd, maar deze moet ook aan te passen zijn voor dit bepaalde project - een gebruiker van het systeem moet zijn taken in de kalender kunnen zetten - per project product moet het mogelijk zijn om meerdere inkoopregels te registreren - bij het maken van een nieuw project moet de mogelijkheid bestaan om een projectsjabloon te kiezen waarvan de structuur (fases en activiteiten) worden overgenomen naar het nieuwe project - de kosten van een project moeten automatisch worden berekend a.d.h.v. totale taakkosten en productkosten - de mogelijkheid tot het maken van rapportages over de voortgang van projecten Bovenstaande punten hebben als doelstelling de mogelijkheid tot het bewaken van het budget van projecten. De globale systeemeisen zoals deze in de definitiestudie staan: SE1: Projecten moeten bestaan uit fases die weer een aantal activiteiten hebben. SE2: Projectmanagers moeten nieuwe projecten kunnen definiëren en beheren. Nieuwe projecten worden gemaakt aan de hand van een opportunity, in het geval van een project bij een klant, of op zichzelf staand, in het geval van een intern project. SE3: Per project moeten de volgende zaken kunnen worden bijgehouden: projectmedewerkers, producten, kosten, contact personen, projecttaken en een documentbibliotheek. SE4: (Project)managers moeten de mogelijkheid hebben om d.m.v. diverse rapportages een overzicht te krijgen van de werkzaamheden binnen het bedrijf. IE1: De interface van de te maken gedeeltes dienen overeen te komen met de huidige Sage CRM interface. De huidige Sage CRM interface stijl zal worden gebruikt. IE2: Het systeem dient in meerdere talen beschikbaar te zijn, in ieder geval Engels en Nederlands. ITE1: De inhoud van elk formulier wordt, voor deze opgeslagen wordt, gecontroleerd op correctheid (Validatie van gegevens). ITE2: Mocht, bij het ophalen van gegevens, corrupte informatie tevoorschijn komen wordt dit direct gemeld.

98

Ter illustratie staat hieronder het deel van de globale entiteitenmodel, die in het geheel in de definitiestudie te vinden is, die in deze pilot aan bod komt:

Cost_code

Employee

ProjectCost

ProjectMember


CalendarEntry

Person

ProjectActivity


PurchaseLine

Opportunity

Product

99

Project Task


1.3 Tijdschatting Startdatum van de pilot is 7-11-2005. Datum 11-11-2005 18-11-2005 25-11-2005 28-11-2005 2-12-2005

Product Ontwerp pilot Uiteindelijk ontwerp en start bouwen Product pilot 2 Test pilot 2 Uiteindelijk product pilot 2

100

Tijd functionarissen 2 uur, beoordeling ontwerp 2 uur, beoordeling ontwerp 2 uur, beoordeling product 4 uur, test 2 uur, beoordeling product

2. Globaal Functionele Structuur 2.1 Functioneel procesmodel In dit hoofdstuk zullen de globale systeemeisen zoals in de definitiestudie te vinden zijn worden uitgesplitst in meer gedetailleerde systeemeisen. SE1: Projecten moeten bestaan uit fases die weer een aantal activiteiten hebben. - zie pilot 1 SE2: Projectmanagers moeten nieuwe projecten kunnen definiëren en beheren. Nieuwe projecten worden gemaakt aan de hand van een opportunity, in het geval van een project bij een klant, of op zichzelf staand, in het geval van een intern project. - SE2.1: Een nieuw project moet aan de hand van een projectsjabloon worden gemaakt, of als een geheel nieuw soort project. In het laatste geval moeten de nieuw ingevulde gegevens als nieuw projectsjabloon kunnen worden opgeslagen - SE2.2: Aan elk project moeten meerdere producten kunnen worden gekoppeld - SE2.3: Projectgegevens, waaronder projectfases en projectactiviteiten, moeten per project apart kunnen worden gedefinieerd. Ook als een projectsjabloon wordt gebruikt. - SE2.4: Bij het projectoverzicht moet een volledig overzicht van alle onderliggende fases en activiteiten worden getoond waarin automatisch de werkelijke kosten van het project worden berekend. Deze kosten worden vervolgens uitgezet tegen het projectbudget. - SE2.5: Een project krijgt bij het aanmaken een bepaalde munteenheid toegewezen, deze kan later niet meer veranderd worden - SE2.6: Bedragen moeten worden opgeslagen volgens de gekozen munteenheid maar getoond volgens de munteenheid die de gebruiker in het systeem gebruikt SE3: Per project moeten de volgende zaken kunnen worden bijgehouden: projectmedewerkers, producten, kosten, contact personen, projecttaken en een documentbibliotheek. - SE3.1: Per product moeten gedefinieerde inkoopregels kunnen worden gekoppeld - SE3.2: Het moet mogelijk zijn contactpersonen van andere companies dan degene waarvoor het project wordt uitgevoerd te definiëren - SE3.3: Projectmedewerkers moeten worden gekoppeld aan projectactiviteiten, dit zijn projecttaken - SE3.4: Bij het aanwijzen van een projectmedewerker zal automatisch het standaard geldende tarief voor die medewerker in die functie worden getoond. Deze moet vervolgens aanpasbaar zijn voor het gekozen project - SE3.5: Tarieven moeten in verschillende tijdseenheden kunnen worden gedefinieerd (zoals uren, dagen (8 uur), half uren, etc.) Er dient bij het automatisch berekenen van de kosten rekening te worden gehouden met deze verschillende tijdseenheden - SE3.6: Bij het toevoegen van projectproducten moet uit de bestaande producten kunnen worden gekozen. Automatisch wordt berekend wat de totale productkosten zijn welke wordt getoond. Ook moeten deze kosten worden doorberekend in de totale projectkosten - SE3.7: Er moet per project een totaaloverzicht van taken per activiteit worden getoond met daarbij de kosten van een taak berekend door de tijd maal het tarief van de medewerker - SE3.8: De documentbibliotheek moet hetzelfde werken als de anderen in Sage CRM alleen dan voor het bepaalde project SE4: (Project)managers moeten de mogelijkheid hebben om d.m.v. diverse rapportages een overzicht te krijgen van de werkzaamheden binnen het bedrijf. De definitie van deze rapporten zal door de opdrachtgever worden verstrekt.

101

2.2 Prototype Navigatie Uit het globale entiteitenmodel die voor deze pilot is beschreven kan een navigatieschema worden gemaakt. Het implementeren van meerdere entiteiten die gekoppeld zijn aan de projecten wordt in Sage CRM gedaan door middel van een tabbalk.

Figuur: globaal navigatieschema waarin een nieuwe tabbalk te onderscheiden is, deze staat geïllustreerd op de volgende pagina

102

Hoofdmenutabbalk:

Projecttabbalk:

Projectoverzicht:

-

Zoals het projectsjabloonoverzicht Andere kleur om projectfases en mijlpalen aan te geven Automatisch berekenen van budget in uren en geld per fase Aangegeven startdatum en einddatum

103

2.3 Gegevensmodel Cost_code

Employee

ProjectCost

ProjectMember


CalendarEntry

Person

ProjectActivity

Project Task


PurchaseLine

Opportunity

Product


104

Project Prj_ID Prj_Name Prj_Description Prj_StartDate Prj_EndDateExpected Prj_EndDateActual Prj_BudgetType Prj_Budget Prj_ProjectManagerID Prj_OpportunityID Prj_CompanyID Prj_Customerordernr Prj_Invoicecontact Prj_Status Prj_Totalhours

Identityfield Text (30), verplicht Multiline Text Date & Time, verplicht Date & Time, verplicht Date & Time Selection, verplicht Currency, verplicht Search Select Advanced, Employee, on delete no action Search Select Advanced, Opportunity, on delete no action, optioneel Search Select Advanced, Company, on delete no action Text (30) Search Select Advanced, Person, on delete no action Selection, verplicht Integer, verplicht

ProjectContactPerson Pcp_ID Pcp_Description Pcp_Role Pcp_ProjectID Pcp_PersonID

Identityfield Text (255) Selection, verplicht Search Select Advanced, Project, on delete cascades Search Select Advanced, Person, on delete no action (prompt)

ProjectCost PC_ID Pc_Description Pc_ProjectID Pc_CostCodeID Pc_Amount

Identityfield Text (255), verplicht Search Select Advanced, Project, on delete cascades Search Select Advanced, CostCode, on delete no action (prompt) Currency, verplicht

ProjectMember Prm_ID Prm_ProjectID Prm_EmployeeID Prm_Function Prm_Tariff Prm_Unit

Identityfield Search Select Advanced, Project, on delete cascades Search Select Advanced, Employee, on delete no action (prompt) Selection, verplicht Currency, verplicht Selection, verplicht

105

ProjectPhase Pjp_ID Pjp_Name Pjp_Description Pjp_StartDate Pjp_EndDate Pjp_Status Pjp_Order Pjp_ProjectID

Identityfield Text (30), verplicht Multiline Text Date, verplicht Date, verplicht Selection, verplicht Integer Search Select Advanced, Project, on delete cascades

ProjectActivity Pja_ID Pja_Description Pja_Milestone Pja_Hours Pja_Order Pja_StartDate Pja_EndDate Pja_Budget Pja_BudgetType Pja_Status Pja_ProjectPhaseID Pja_FunctionID Pja_CostCodeID

Identityfield Text (255) Checkbox Integer, verplicht Integer Date & Time, verplicht Date & Time, verplicht Currency Selection, verplicht Selection, verplicht Search Select Advanced, ProjectPhase, on delete cascades Search Select Advanced, Functions, on delete no action (prompt) Search Select Advanced, CostCode, on delete no action (prompt)

ProjectTask Pas_ID Pas_ProjectActivityID Pas_ProjectMemberID Pas_Hours

Identityfield Search Select Advanced, ProjectActivity, on delete no action (prompt) Search Select Advanced, ProjectMember, on delete no action (prompt) Integer, verplicht

CalendarEntry CE_ID CE_Description CE_BeginDate CE_EndDate CE_ProjectAssignmentID

Identityfield Text (255), verplicht Date & Time, verplicht Date & Time, verplicht Search Select Advanced, ProjectAssignment, on delete no action (prompt)

106

ProjectProduct PrP_ID PrP_Description PrP_ProjectID Prp_Amount Prp_ProductID

Identityfield Text (255), verplicht Search Select Advanced, Project, on delete cascades Integer, verplicht Search Select Advanced, Product, on delete no action

PurchaseLine PL_ID PL_Date PL_Remark PL_ProjectProductID

Identityfield Date & Time, verplicht Text (255) Search Select Advanced, ProjectProduct, on delete cascades

107

2.4 Aanpassingen externe componenten In dit hoofdstuk worden de aanpassingen opgesomd die noodzakelijk zijn in het huidige Sage CRM systeem. -

de entiteit Project wordt als primary entity toegevoegd de andere entiteiten worden als secondary entity toegevoegd op het hoofdscherm wordt de tab ‘Project’ toegevoegd bij de bestaande entiteit Company wordt de tab ‘Projects’ toegevoegd bij het verkopen van een Opportunity wordt de mogelijkheid gegeven een nieuw project aan te maken a.d.h.v. de Opportunity

108

3. Pilotontwikkelplan 3.1 Definitie Pilotdelen Pilotdeel PD1 PD2 PD3

Entiteiten Project, ProjectPhase, ProjectActivity, ProjectTask, ProjectMember ProjectProduct, PurchaseLine, ProjectCost, ProjectContactPerson Koppeling nieuwe functionaliteit met bestaande


3.2 Beoordeling en test pilotdelen De beoordeling wordt uitgevoerd zodra er een concept van het betreffende pilotdeel in het systeem staat. De beoordeling en test wordt gedaan door de, in de definitiestudie gespecificeerde, functionarissen in overleg met de uitvoerder aan de hand van een testscenario.

3.3 Invoeringsplan Er is geen sprake van invoering in de klassieke zin aangezien het een web-based applicatie betreft. Wel wordt per pilotdeel een ‘pakket’ gemaakt die bestaat uit de nieuwe gemaakte pagina’s en de sqlstatements die nodig zijn om het pilotdeel in te voeren.

109

Pilot 3 Urenregistratie binnen Sage CRM

110

Inhoudsopgave 1.

Plan van Aanpak............................................................................................................. 112 1.1 Reikwijdte .............................................................................................................. 112 1.2 Kwaliteitszorg ........................................................................................................ 113 1.3 Tijdschatting........................................................................................................... 113 2. Globaal Functionele Structuur ....................................................................................... 114 2.1 Functioneel procesmodel........................................................................................ 114 2.2 Toestanden weekstaat............................................................................................. 115 2.3 Gegevensmodel ...................................................................................................... 116 2.4 Aanpassingen externe componenten ...................................................................... 118 3. Pilotontwikkelplan ......................................................................................................... 119 3.1 Definitie Pilotdelen ................................................................................................ 119 3.2 Beoordeling en test pilotdelen................................................................................ 119 3.3 Invoeringsplan ........................................................................................................ 119

111

1. Plan van Aanpak 1.1 Reikwijdte De globale doelstellingen van deze pilot zijn: - het toevoegen van de Weekstaat entiteit aan Sage CRM - het toevoegen van een Week entiteit waarin de gebruiker per jaar de weeknummers kan definiëren - een weekstaat bestaat uit een aantal regels deze worden opgeslagen in twee aparte entiteiten: project en algemene waarbij in de eerste alle uren die op een project worden geboekt worden opgeslagen en bij de tweede alle uren die niet voor een project werden besteed (billable / nonbillable) - een projectmanager moet per week per medewerker de weekstaten kunnen bekijken en goedof afkeuren Bovenstaande punten hebben als doelstelling de mogelijkheid tot het registreren van gewerkte uren. De globale systeemeisen zoals deze in de definitiestudie staan: SE1: Projectmanagers moeten weekstaten kunnen goedof afkeuren voordat deze gefactureerd mogen worden. IE1: De interface van de te maken gedeeltes dienen overeen te komen met de huidige Sage CRM interface. De huidige Sage CRM interface stijl zal worden gebruikt. IE2: Het systeem dient in meerdere talen beschikbaar te zijn, in ieder geval Engels en Nederlands. ITE1: De inhoud van elk formulier wordt, voor deze opgeslagen wordt, gecontroleerd op correctheid (Validatie van gegevens). ITE2: Mocht, bij het ophalen van gegevens, corrupte informatie tevoorschijn komen wordt dit direct gemeld. Ter illustratie staat hieronder het deel van de globale entiteitenmodel, die in het geheel in de definitiestudie te vinden is, die in deze pilot aan bod komt:

Project Task



Week

112

Cost_code


1.3Tijdschatting Startdatum van de pilot is 9-12-2005. Datum 15-12-2005 16-12-2005 4-12-2005 5-12-2005 6-12-2005


113


2. Globaal Functionele Structuur 2.1Functioneel procesmodel In dit hoofdstuk zullen de globale systeemeisen zoals in de definitiestudie te vinden zijn worden uitgesplitst in meer gedetailleerde systeemeisen. SE1: Projectmanagers moeten weekstaten kunnen goedof afkeuren voordat deze gefactureerd mogen worden. - SE1.1: De mogelijkheid tot het definiëren van de weeknummers moet per jaar kunnen geschieden. Er zal worden gevraagd om de eerste dag van de eerste week van het jaar te selecteren waarna het systeem de weeknummers van dat jaar genereert en opslaat. - SE1.2: Projectmanagers moeten per jaar, week en medewerker een lijst van weekstaten op kunnen vragen waarna deze bekeken kunnen worden. - SE1.3: Bij het tonen van een weekstaat wordt onderscheid gemaakt in billable en non-billable uren. - SE1.4: Het aantal uur dat de medewerker heeft ingevoerd wordt opgeteld en getoond met daarachter de contractuele wekelijkse uren zodat deze vergeleken kunnen worden. - SE1.5: Bij het tonen van een weekstaat moet de projectmanager deze goedof af kunnen keuren. Zodra een weekstaat goed is gekeurd zal deze als definitief worden gezien tenzij veranderd door de projectmanager. - SE1.6: In het takenoverzicht van een project worden achter de geraamde uren en budget het werkelijk aantal uur en budget getoond. Deze uren worden berekend aan de hand van goedgekeurde weekstaten en geven inzicht in het budget van het project.

114

2.2Toestanden weekstaat Invoer medewerker Niet ingevoerd

Goedkeuring manager

Gesloten door manager Goed gekeurd

Ingevoerd

Afkeuring manager

Wijzigingen medewerker

Afgekeurd

115

Gesloten

2.3

Gegevensmodel Project Task



Cost_code

Week


116

Week Wk_Id Wk_Number Wk_StartDate Wk_EndDate

Idfield Integer, verplicht Date, verplicht Date, verplicht

Weekstate Ws_Id Ws_Employeeid Ws_WeekNumber

Idfield Search Select Advanced Employee, on delete no action, verplicht Search Select Advanced Week, on delete no action, verplicht

ProjectWeekstateLine Pwsl_Id Pwsl_Description Pwsl_WeekstateID Pwsl_ProjectID Pwsl_TaskId Pwsl_day1 Pwsl_day2 Pwsl_day3 Pwsl_day4 Pwsl_day5 Pwsl_day6 Pwsl_day7

IdField Text (255) Search Select Advanced Weekstate, on delete no action, verplicht Search Select Advanced Project, on delete no action, verplicht Search Select Advanced ProjectTask, on delete no action, verplicht Numeric Numeric Numeric Numeric Numeric Numeric Numeric

GeneralWeekstateLine Gwsl_Id Gwsl_Description Gwsl_WeekstateID Gwsl_CostCodeID Gwsl_day1 Gwsl_day2 Gwsl_day3 Gwsl_day4 Gwsl_day5 Gwsl_day6 Gwsl_day7

IdField Text (255) Search Select Advanced Weekstate, on delete no action, verplicht Search Select Advanced CostCode, on delete no action, verplicht Numeric Numeric Numeric Numeric Numeric Numeric Numeric

117

2.4Aanpassingen externe componenten In dit hoofdstuk worden de aanpassingen opgesomd die noodzakelijk zijn in het huidige Sage CRM systeem. -

de entiteit Weekstate wordt als primary entity toegevoegd de andere entiteiten worden als secondary entity toegevoegd op het hoofdscherm wordt de tab ‘Weekstate’ toegevoegd bij de takenoverzicht van een project worden twee kolommen toegevoegd: werkelijke uren en werkelijke budget de entiteit Week wordt toegevoegd aan de datamanagement

118

3. Pilotontwikkelplan 3.1Definitie Pilotdelen Pilotdeel PD1 PD2

Entiteiten Week Weekstate, ProjectWeekstateLine, GeneralWeekstateLine


3.2Beoordeling en test pilotdelen De beoordeling wordt uitgevoerd zodra er een concept van het betreffende pilotdeel in het systeem staat. De beoordeling en test wordt gedaan door de, in de definitiestudie gespecificeerde, functionarissen in overleg met de uitvoerder aan de hand van een testscenario.

3.3Invoeringsplan Er is geen sprake van invoering in de klassieke zin aangezien het een web-based applicatie betreft. Wel wordt per pilotdeel een ‘pakket’ gemaakt die bestaat uit de nieuwe gemaakte pagina’s en de sqlstatements die nodig zijn om het pilotdeel in te voeren.

119

Pilot 4 Urenregistratie buiten Sage CRM (externe website)

120

Inhoudsopgave 1.

Plan van Aanpak............................................................................................................. 122 1.1 Reikwijdte .............................................................................................................. 122 1.2 Kwaliteitszorg ........................................................................................................ 123 1.3 Tijdschatting........................................................................................................... 123 2. Globaal Functionele Structuur ....................................................................................... 124 2.1 Functioneel procesmodel........................................................................................ 124 2.2 Prototype Schermen ............................................................................................... 125 2.3 Aanpassingen externe componenten ...................................................................... 126 3. Pilotontwikkelplan ......................................................................................................... 127 3.1 Definitie Pilotdelen ................................................................................................ 127 3.2 Beoordeling en test pilotdelen................................................................................ 127 3.3 Invoeringsplan ........................................................................................................ 127

121

1. Plan van Aanpak 1.1Reikwijdte De globale doelstellingen van deze pilot zijn: - het maken van een externe website die in verbinding staat met de Sage CRM database waarin projectmedewerkers hun weekstaten kunnen invoeren en bekijken - zorgen dat de ingevulde inlognaam en wachtwoord voor deze site, zoals deze in de medewerkerentiteit staan, daadwerkelijk gebruikt gaan worden bij het inloggen van de site - voor zover mogelijk maken dat de site niet alleen in Internet Explorer maar ook in Firefox werkbaar is - de lay-out van de site gescheiden houden van de functionaliteit zodat deze gemakkelijk aangepast kan worden naar de wensen van de klant Bovenstaande punten hebben als doelstelling de mogelijkheid tot het bewaken van het budget van projecten. De globale systeemeisen zoals deze in de definitiestudie staan: SE1: Projectmedewerkers moeten gewerkte uren per projecttoewijzing kunnen registreren via een externe site. IE1: De interface van de te maken gedeeltes dienen overeen te komen met de huidige Sage CRM interface. De huidige Sage CRM interface stijl zal worden gebruikt. IE2: Het systeem dient in meerdere talen beschikbaar te zijn, in ieder geval Engels en Nederlands. ITE1: De inhoud van elk formulier wordt, voor deze opgeslagen wordt, gecontroleerd op correctheid (Validatie van gegevens). ITE2: Mocht, bij het ophalen van gegevens, corrupte informatie tevoorschijn komen wordt dit direct gemeld.

122


1.3Tijdschatting Startdatum van de pilot is 9-12-2005. Datum 15-12-2005 16-12-2005 4-12-2005 5-12-2005 6-12-2005


123


2. Globaal Functionele Structuur 2.1Functioneel procesmodel In dit hoofdstuk zullen de globale systeemeisen zoals in de definitiestudie te vinden zijn worden uitgesplitst in meer gedetailleerde systeemeisen. SE1: Projectmedewerkers moeten gewerkte uren per projecttoewijzing kunnen registreren via een externe site. - SE1.1: Alleen medewerkers met een inlognaam en wachtwoord mogen in kunnen loggen - SE1.2: Het systeem toont een lijst met projecten waarin de medewerker werkzaam is - SE1.3: Het systeem toont per project een lijst met taken die de medewerker moet uitvoeren - SE1.4: Selectie van de in te vullen weekstaat wordt gedaan door eerst het jaar en vervolgens de weeknummer te selecteren. Bij inloggen wordt altijd de weekstaat van de huidige week weergegeven - SE1.5: Het systeem houdt het huidige aantal ingevulde uren bij - SE1.6: In de lijst met weeknummers worden goed- en afgekeurde weekstaten door middel van een kleurcode aangestipt

124

2.2Prototype Schermen

Inlogscherm

Urenregistratie Jaar

Weeknummer

Billable Projecten

Taken

Omschrijving

Dag 1

Dag 2

Dag 3

Dag 4

Dag 5

Dag 6

Dag 7

Projecten

Taken

Omschrijving

Dag 1

Dag 2

Dag 3

Dag 4

Dag 5

Dag 6

Dag 7

Omschrijving

Dag 1

Dag 2

Dag 3

Dag 4

Dag 5

Dag 6

Dag 7

Non-billable Costcode

Opslaan

Weekstaat

125

2.3Aanpassingen externe componenten In dit hoofdstuk worden de aanpassingen opgesomd die noodzakelijk zijn in het huidige Sage CRM systeem. -

de inlognaam en wachtwoord van de medewerker wordt gekoppeld aan de externe website de externe website wordt geregistreerd in Sage CRM

126

3. Pilotontwikkelplan 3.1Definitie Pilotdelen Pilotdeel PD1 PD2

Omschrijving Aanpassen medewerker inlognaam en wachtwoord en het maken van een inlogscherm Mogelijkheid tot invoeren weekstaten


3.2Beoordeling en test pilotdelen De beoordeling wordt uitgevoerd zodra er een concept van het betreffende pilotdeel in het systeem staat. De beoordeling en test wordt gedaan door de, in de definitiestudie gespecificeerde, functionarissen in overleg met de uitvoerder aan de hand van een testscenario.

3.3Invoeringsplan Er is geen sprake van invoering in de klassieke zin aangezien het een web-based applicatie betreft. Wel wordt per pilotdeel een ‘pakket’ gemaakt die bestaat uit de nieuwe gemaakte pagina’s en de sqlstatements die nodig zijn om het pilotdeel in te voeren.

127

Bijlage C: Sage CRM In deze bijlage wil ik kort het CRM-pakket waarin de opdracht is uitgevoerd uit de doeken doen d.m.v. illustraties en tekst. Als eerste zal een algemene impressie van het pakket gegeven worden. Daarna zal gedetailleerd in worden gegaan op een aantal zaken waarmee ik tijdens het uitvoeren van de opdracht het meest mee te maken heb gehad.

Sage CRM algemeen Sage CRM is een web-based CRM applicatie. Deze applicatie maakt het mogelijk voor bedrijven om hun klantgegevens te beheren in een toegankelijk systeem. Het systeem onderscheid de volgende typen informatie (primaire entiteiten of primary entities): -

Companies (gegevens van klanten, toekomstige klanten of concurrenten) Persons (contactpersonen bij een bepaalde company) Leads (eventuele interesse die er voor een product bestaat vanuit een company) Opportunity (een kans om een bepaald product aan een company te verkopen, kan ontstaan uit een lead) Case (een probleem of vraag die een person heeft gesteld aan het bedrijf) Communication (een communicatie naar een company of person betreffende een lead, opportunity of case)

Door de gebruikers van het systeem in teams en regio’s op te delen en aan deze teams/regio’s weer companies (en daarmee dus ook persons, leads, etc.) te wijzen kan elk team snel en effectief hun klantgegevens raadplegen, beheren en gebruiken om te komen tot een efficiënter bedrijfsproces.

Figuur: voorbeeldoverzicht van een company met in de blauwe taakbalk de optie om bijvoorbeeld de opportunities die voor het bedrijf gelden te bekijken

128

Figuur: lijst met opportunities die voor de gekozen company bestaan

Figuur: overzicht van een opportunity welke is toegewezen aan de systeemgebruiker Tim McGraw in het team Customer Service

129

Al deze functionaliteit is via de Internetbrowser te gebruiken. Ook kan het systeem rapporten en overzichten genereren.

Figuur: bovenstaand is een deel van de lijst van companies met meer dan 100 werknemers die in het systeem geregistreerd staan

Dit is maar een snelle en korte greep uit de mogelijkheden die Sage CRM voor gebruikers biedt. Hierna wordt het zogenaamde beheergedeelte of ‘administration’ beschreven. Dit maakt het voor ontwikkelaars mogelijk om het systeem aan te passen en nieuwe modules toe te voegen. Bij de uitvoer van de opdracht werd hier veel mee gewerkt.

130

Sage CRM Administration

Figuur: het hoofdscherm van het administration gedeelte

Het administration gedeelte maakt het mogelijk voor beheerders en ontwikkelaars om het systeem naar behoefte aan te passen of nieuwe delen toe te voegen. Het meeste werk van het project is uitgevoerd in dit gedeelte van de applicatie.

Figuur: entity customization scherm. Hier kunnen alle entiteiten worden aangepast.

Het systeem is opgebouwd uit een aantal entiteiten (tabellen) die met elkaar in verbinding staan. Het is mogelijk om nieuwe entiteiten toe te voegen en deze met elkaar of met bestaande entiteiten te verbinden.

131

Figuur: overzicht van velden van de entiteit ProjectMember

In bovenstaande figuur is de nieuw toegevoegde entiteit ProjectMember geselecteerd. Deze entiteit is tijdens het project in pilot 2 toegevoegd aan het systeem. Te zien zijn alle velden, waaronder de standaardvelden deleted, id en timestamp, met de naam, databasenaam en veldtype. Het is heel gemakkelijk een extra veld toe te voegen.

Figuur: voorbeeld van het toevoegen van een veld aan de entiteit ProjectMember

In bovenstaand figuur wordt een nieuw tekstveld toegevoegd aan de entiteit. Welke na het opslaan in de lijst met velden terug te vinden is:

132

Figuur: voorbeeld van een invoerscherm

In bovenstaande afbeelding is te zien hoe een invoerscherm wordt gemaakt. De informatie uit de tabel die in het invoerveld moeten komen staan links in de rij. Als het nieuw toegevoegde veld test wordt toegevoegd aan de lijst wordt het scherm aangepast. Oude situatie:

Nieuwe situatie:

Hierin is ook al het gedrag van veldtypen te zien.

133

Hetzelfde geldt voor het maken van lijsten. Het is heel gemakkelijk de informatie die in een lijst wordt getoond aan te passen aan de behoefte van de gebruiker. Om het invoerscherm of lijst van een nieuw toegevoegde entiteit op het scherm te krijgen moet echter wel een aparte ASP pagina worden gemaakt. In deze pagina wordt kan het scherm dan worden aangeroepen en Sage CRM zorgt ervoor dat de informatie correct op het scherm komt te staan. Om alleen een lijst op het scherm te krijgen is de volgende code nodig: <% ProjectMemberList = eWare.GetBlock('ProjectMemberList'); Response.Write(eWare.GetPage()); Response.Write(ProjectMemberList.Execute()); %> Dit heeft als resultaat:

Dit stuk is natuurlijk erg simpel. Het wordt pas uitdagend als men meer functionaliteit aan de pagina toe gaat voegen. Aangezien het om een ASP pagina gaat kan men ASP, Javascript en HTML gebruiken om de pagina naar zijn zin te krijgen.

134

Afstudeerverslag Project budget bewaking en urenregistratie in Sage CRM

Recommend Documents