Afstudeerverslag Project budget bewaking en urenregistratie in Sage CRM

Transcriptie

1 Afstudeerverslag Project budget bewaking en urenregistratie in Sage CRM Erik Vleugel ( )

2 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

3 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,

4 Inhoudsopgave 1. Inleiding Opdracht Opdrachtgever (CBS Solutions B.V.) Opdracht Uitgangssituatie Ontwikkelmethode Definitiestudie Ontwikkelscenario Systeemeisen en systeemconcept Pilotplan Pilot 1: Stamgegevens (medewerkergegevens en projectsjablonen) Reikwijdte Ontwerp Bouw Test Evaluatie Pilot 2: Project Budget Bewaking Reikwijdte Ontwerp Bouw Test Evaluatie Pilot 3 en 4: Urenregistratie (binnen en buiten Sage CRM) Reikwijdte Ontwerp Bouw Test... Error! Bookmark not defined. 7.5 Evaluatie... Error! Bookmark not defined. 8. Evaluatie Het product Het proces Bijlage A: Begrippenlijst Bijlage B: Projectdocumentatie Bijlage C: Sage CRM

5 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

6 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

7 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

8 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

9 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

10 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

11 - 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

12 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 13

14 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 Incrementeel opleveren Incrementeel ontwikkelen Big-bang invoeren Klein informatiesysteem Kleine, stabiele projectomgeving - + Bekende systeemeisen Veel betrokkenheid Web-based (gemakkelijke invoering) Geen specifieke haast = erg goed + = goed leeg = neutraal - = 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

15 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

16 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 Bestaand Stamgegevens Functioneel Weeks Figuur: eerste concept entiteitenmodel n.a.v. initiële interviews. Dit model is als input gebruikt voor de eerste workshop. 16

17 Tweede concept Cost_code Activity Function Tariff Phase Employee ProjectCost Projecttype Project ContactPerson Project ProjectMember Person ProjectPhase CalendarEntry Coupon ProjectProduct ProjectActivity Project Assignment Detaillering projectactiviteiten Opportunity Weekstate WeekstateLine Product Bestaand Stamgegevens Functioneel PurchaseLine Week Declaration Figuur: tweede concept n.a.v. de eerste workshop. Deze werd als input gebruikt voor de tweede workshop. 17

18 Uiteindelijke model Cost_code ActivityTemplate Functions Tariff PhaseTemplate Employee ProjectCost ProjectTemplate ProjectMember Project ContactPerson Project ProjectPhase CalendarEntry Person ProjectActivity Project Task Company ProjectProduct Project WeekstateLine PurchaseLine Weekstate Opportunity General WeekstateLine Product Week Project Declaration Invoice InvoiceLine General Declaration Bestaand Stamgegevens Functioneel Figuur: uiteindelijke versie van het entiteitenmodel dat gedurende de rest van het project is gebruikt. 18

19 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

20 - 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 project- en 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

21 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

22 - 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