Gruppenummer (dersom besvarelsen leveres i gruppe): Gruppe 15 Tittel: Troja.NET utvikling av en nettbasert CRM modul.

Transkript

1 Fagbetegnelse: PJ 501 Semester: Gruppenummer (dersom besvarelsen leveres i gruppe): Gruppe 15 Tittel: Troja.NET utvikling av en nettbasert CRM modul Eventuell oppdragsgiver: Tilgjengelighet: FRI BEGRENSET Innleveringsdato: 7. mai 2004 Antall sider: VÅR Sammendrag (fra rapporten): Dialogplan AS 55 Troja.NET utvikling av en nettbasert CRM modul, tar utgangspunkt i problemstillingen: Hvordan utvikle en CRM modul som kan være med på å øke kundeforståelse og verdiskapning? Problemstillingen har bestått av å utvikle en.net basert CRM modul som har mulighet til å administrere informasjon om entiteter, samt presentere rapporter over disse. Det er gruppens konklusjon at målene for oppgaven er nådd. Dette på grunnlag av at det har blitt har blitt utviklet en CRM modul med funksjonalitet som beskrevet i kravspesifikkasjonen. I tillegg er denne utviklet innen rammene for.net arkitektur og dokumentert i henhold til rådende standarder. Vi mener på bakgrunn av den implementerte funksjonaliteten og dens muligheter til bearbeidelse og prosessering av data, at CRM modulen kan være med på å øke kundeforståelsen og verdiskapningen i bedrifter. Oppdragsgiver har uttrykt seg veldig positivt til det ferdige resultatet og CRM modulen skal snarest integreres med Troja markedsprogram som lanseres 27. mai Arbeidet avsluttet: 7. mai 2004 Gruppemedlemmer: Mette Andersen Jørgen Fundingsrud Tor-Morten Grønli Irjan Javo Kenneth Lilleaas Innleveringen er også en bekreftelse av at gruppen har gjort seg kjent med, og fulgt, NITHs retningslinjer for intellektuell redelighet (tilgjengelig på intranett

2 Forord Denne rapporten er et resultat av et diplomprosjekt utført av fem studenter ved Norges Informasjonsteknologiske Høgskole våren Prosjektet er gjennomført i samarbeid med Dialogplan AS. Oppgaven er først og fremst rettet mot intern og ekstern sensor ved Norges Informasjonsteknologiske Høgskole. Det forventes at de har noe bakgrunn innen systemeringsfaget og programvareutvikling. I løpet av prosjektperioden har vi fått hjelp og støtte av mange vi ønsker å takke. Vi takker vår veileder Cat Holten for den kontinuerlige oppfølgingen og Eva Schwencke i forbindelse med prosjektet Bedre dialog. Begge fra Norges Informasjonsteknologiske Høgskole. Vi ønsker også å takke for et godt samarbeid med Per Anders Gjefsen, Oskar Sungodt Overå og daglig leder Eirik Rasmussen ved Dialogplan AS. Med vennlig hilsen Mette Andersen Jørgen Fundingsrud Tor-Morten Grønli Irjan Javo Kenneth Lilleaas Gruppe 15 1 av 66

3 Sammendrag Troja.NET utvikling av en nettbasert CRM modul, tar utgangspunkt i problemstillingen: Hvordan utvikle en CRM modul som kan være med på å øke kundeforståelse og verdiskapning? Problemstillingen har bestått av å utvikle en.net basert CRM modul som har mulighet til å administrere informasjon om entiteter, samt presentere rapporter over disse. Det er gruppens konklusjon at målene for oppgaven er nådd. Dette på grunnlag av at det har blitt har blitt utviklet en CRM modul med funksjonalitet som beskrevet i kravspesifikkasjonen. I tillegg er denne utviklet innen rammene for.net arkitektur og dokumentert i henhold til rådende standarder. Vi mener på bakgrunn av den implementerte funksjonaliteten og dens muligheter til bearbeidelse og prosessering av data, at CRM modulen kan være med på å øke kundeforståelsen og verdiskapningen i bedrifter. Oppdragsgiver har uttrykt seg veldig positivt til det ferdige resultatet og CRM modulen skal snarest integreres med Troja markedsprogram som lanseres 27. mai Gruppe 15 2 av 66

4 Innholdsfortegnelse 1 INNLEDNING PRESENTASJON AV OPPDRAGSGIVER PRESENTASJON AV PROSJEKTOPPGAVE VISJON, HOVEDMÅL OG DELMÅL AVGRENSNING ALTERNATIVE LØSNINGER PROBLEMSTILLING PROSJEKTORGANISERING RAPPORT STRUKTUR TEORI CUSTOMER RELATIONSHIP MANAGEMENT NET ARKITEKTUR BRUKERVENNLIGHET METODE KVALITATIV METODE VALG AV UTVIKLINGSMODELL Tilpassing av RUP Andre metoder TEKNIKKER OG VERKTØY Rational Rose Enterprise Edition Version Microsoft Visual Studio.NET 2002 Versjon Visual Basic.NET Microsoft SQL Server Microsoft Internet Information Services Microsoft.NET Framwork versjon Microsoft ASP.NET Web Services Unified Modeling Language Crystal Reports for Visual Studio.NET Microsoft Word Microsoft Excel Arbeidskontrakt Microsoft Project Risikostyring Timelister Skapt verdi ANALYSE OG UTFORMING FORRETNINGSBRUKSTILFELLE KRAVSPESIFIKASJON Funksjonelle krav Ikke funksjonelle krav ARKITEKTUR Brukstilfelle perspektiv Logisk perspektiv Prosess perspektiv Implementasjonsperspektivet Utplasseringsperspektiv LØSNING KORT BESKRIVELSE AV LØSNING KORT BESKRIVELSE AV ORGANISATORISK LØSNING VURDERING AV LØSNING VURDERING AV TEKNISK RESULTAT Gruppe 15 3 av 66

5 6.2 VURDERING AV NYTTE FOR OPPDRAGSGIVER VURDERING AV RESULTAT I FORHOLD TIL FORSKNINGSTEORI Customer Relationship Management NET Arkitektur Brukervennlighet VURDERING AV PROSJEKT BRUK AV RUP OG XP SOM UTVIKLINGSMODELL RUP XP VURDERING AV VERKTØY Rational Rose Enterprise Edition Version (Rational Rose) Microsoft Visual Studio.NET 2002 Versjon Visual Basic.NET Microsoft SQL Server Microsoft Internet Information Services Microsoft.NET Framwork versjon Microsoft ASP.NET og Web Services Unified Modeling Language Crystal Reports for Visual Studio.NET Microsoft Word Microsoft Excel NYTTEN AV STYRINGSVERKTØY Arbeidskontrakt Microsoft Project Risikostyring Feil tidsestimering av en aktivitet (6) Sykdom inntil to dager for systemerere (5) Timelister Skapt verdi PROSJEKTORGANISERING KONKLUSJON BEGREPSLISTE REFERANSER Figurliste FIGUR 1, VERDIKJEDEN (CAPGEMINI 2004, KILDE B)...12 FIGUR 2, XML WEB SERVICES USING.NET (MICROSOFT 2003)...13 FIGUR 3, FORRETNINGSBRUKSTILFELLE...24 FIGUR 4, IKKE FUNKSJONELLE KRAV (HASLE 2003)...26 FIGUR 5, KRUCHTENS 4+1 MODELL (KRUCHTEN 2000)...29 FIGUR 6, HOVEDFUNKSJONER TIL CRM MODULEN...30 FIGUR 7, DESIGN MODELL...31 FIGUR 8, LAGDELING VERSJON FIGUR 9, SEKVENSDIAGRAM FOR HÅNDTERING AV KONTAKT...36 FIGUR 10, SEKVENSDIAGRAM LAGRE KONTAKT (OMG 2004)...37 FIGUR 11, KOMPONENT DIAGRAM...38 FIGUR 12, UTPLASSERINGSDIAGRAM...39 FIGUR 13, RISIKOLISTE OVER INNTRUFNE RISIKO...55 Gruppe 15 4 av 66

6 1 Innledning Prosjektrapporten er den dokumenterende delen av gruppens hovedprosjekt gjennomført våren 2004 ved Norges Informasjonsteknologiske Høgskole. Kapittelet vil starte med å presentere oppdragsgiver og prosjektoppgaven. Visjon, hovedmål og delmål vil også belyses. I et diplomprosjekt er det mange valg og avgrensninger som skal vurderes, det er kommentert i dette kapittelet. Det avsluttes med en beskrivelse av prosjektorganiseringen og rapportstrukturen. 1.1 Presentasjon av oppdragsgiver Bakgrunnen for diplomoppgaven var en henvendelse fra Dialogplan AS til Norges Informasjonsteknologiske Høgskole. Dialogplan AS ønsket å komme i kontakt med en gruppe som kunne utvikle en Customer Relationship Management (CRM) modul som skal integreres i et markedsprogram. Oppdragsgiveren til dette prosjektet er Dialogplan AS som eies og drives av Eirik Rasmussen. Eirik Rasmussen startet Dialogplan AS alene i 1997, og bedrift består i dag av tre personer. Dialogplan AS jobber med modeller og verktøy for effektiv kundeoppfølging og har utviklet kompliserte databaseapplikasjoner som forenkler kundeoppfølgingen for bedrifter. Dialogplan AS kan blant annet tilby et system for markedsplanlegging som heter Troja markedsprogram (for bakgrunnshistorien bak navnet Troja (Moe u.å.) se vedlegg s. 130). Troja er et databaseverktøy som bistår markedsførere på alle trinn i bedriftenes markedsplanleggingsprosess: fra situasjonsanalysen, via målformulering og strategivalg, til spesifiseringen av når og hvor hvert markedsføringstiltak skal iverksettes (Rasmussen 2004). Den samlede nytteverdien til Troja er å gi bedrifter kunnskap til å ta de riktige avgjørelsene i forhold til markedsføring. Det vil si kunnskap om hvilke veier som bør velges for å realisere bedriftens mål og strategier (sst. 2004). 1.2 Presentasjon av prosjektoppgave Oppdragsgiver ønsket å få laget en CRM modul som skal være et supplement til markedsprogrammet Troja. De ønsket et nettbasert system basert på.net arkitektur. Systemet skal ha mulighet til å lagre informasjon om kontakter, kontaktpersoner, aktiviteter og konkurrenter. Systemet skal også kunne presentere et utvalg av rapporter. Systemet skal integreres med Troja markedsprogram som er under utvikling av Dialogplan AS. (For nærmere dokumentasjon vises det til avgrensningen kapittel 1.4 s. 6 ). Dersom oppdragsgiver ikke skulle se seg fornøyd med det ferdige produkt, kan de benytte seg av kildekoden og videreutvikle produktet etter ønske. Det er ingen konkrete avtaler mellom gruppen og Dialogplan AS om videre samarbeid. Gruppe 15 5 av 66

7 1.3 Visjon, hovedmål og delmål For Troja markedsprogram inngår følgende visjon: Ifølge Erik Rasmussen skal Troja markedsprogram være et verktøy som tar seg av all markedsinformasjon til en bedrift på et felles sted. Alle behov skal dekkes av et program (personlig samtale ). Hovedmålet til prosjektgruppen består i å utvikle en CRM modul som skal være klar for integrering med Troja markedsprogram 1. Mai Kildekode, brukermanual og rapport skal leveres Norges Informasjonsteknologiske Høgskole og Dialogplan AS 7. mai Delmål: - Fremstille en modellert løsning av prosjektgruppens modul ved bruk av Unified Modeling Language - Opprette en Microsoft SQL database samt et.net miljø med den nødvendig strukturen - Integrasjon mot MS Outlook 1.4 Avgrensning Det skal utvikles en mini CRM modul for Dialogplan AS som skal integreres i deres markedsprogram. Systemet skal innholde de forskjellige entitetene: kontakt, kontaktperson, aktivitet og konkurrent. Kontakt regnes som en kunde, det kan være et firma eller en privatperson. Brukeren skal kunne opprette en kontakt med aktuell informasjon. I tillegg skal være det mulig å gjøre oppdateringer på eksisterende kontakter, søke og slette. En kontakt skal kunne knyttes til en målgruppe, et forretningsområde og en gruppe. I tillegg skal det kunne brukerdefineres hva slags type kontakt det er. Til sammen gir dette utfyllende informasjon om hver kontakt. Det vil også være mulig å skrive ut forskjellige rapporter knyttet til en eller flere kontakter. For fullstendig oversikt over mulige rapporter henvises det til brukstilfeller i vedlegg s. 79. En kontaktperson er brukeren av systemet sin kontakt hos kundekontakten. Her gjelder de samme mulighetene som for en kontakt. Det vil også her være mulig å skrive ut forskjellige rapporter knyttet til en eller flere kontaktpersoner. For fullstendig oversikt over mulige rapporter henvises det til brukstilfeller i vedlegg s. 79. Aktivitet er forskjellige oppgaver som kan gjøres opp mot en kontakt. En aktivitet kan for eksempel være et møte, en telefonsamtale, nyhetsbrev eller lignende. En aktivitet kan gå mot enten en enkelt kontaktperson eller mot selve kontakten, som kan være et firma. I tillegg til dette er det mulig å knytte opp filer mot ulike aktiviteter. Dette kan være aktuelt Gruppe 15 6 av 66

8 ved for eksempel referater, utsendte tilbud og lignende. Det vil også her være mulig å skrive ut forskjellige rapporter knyttet til en eller flere aktiviteter. For fullstendig oversikt over mulige rapporter henvises det til brukstilfeller i vedlegg s. 79. En Konkurrent er her tenkt som konkurrerende virksomheter. For å kunne holde oversikt over disse er det mulig å opprette, endre, søke og slette konkurrenter. I tillegg kan man skrive ut en rapport over alle konkurrenter, eller et knippe konkurrenter. Konkurrent er et område med stort potensial. På grunn av den korte tidsrammen for prosjektet, ble det i samarbeid med oppdragsgiver bestemt at konkurrent ikke skulle ha like omfattende funksjonalitet som de andre områdene. Den skulle implementeres med grunnleggende funksjoner som beskrevet, samt være tilrettelagt for videreutvikling. Tilleggsfunksjonalitet for integreringsstøtte med Microsoft Outlook planlegges lagt inn for å kunne gi brukeren en mulighet til å kunne eksportere og importere sine kontakter til denne CRM modulen. Det planlegges ikke integrering av aktiviteter, men Outlook modulen vil legge til rette for det. Gruppen skal stå for begynnelsen av en rapportmodul for hele systemet. Denne skal ikke ferdigstilles, men legges til rette slik at Dialogplan AS kan fortsette arbeidet med den. 1.5 Alternative løsninger Alternative løsninger er vurdert og integrert gjennom hele rapporten i de ulike kapitlene. 1.6 Problemstilling Gruppens problemstilling ble laget på bakgrunn av prosjektoppgaven fra oppdragsgiver: Hvordan utvikle en CRM modul som kan være med på å øke kundeforståelse og verdiskapning? Definisjon av kundeforståelse: Med økt forståelse om kundene vil det si å inneha mer informasjon om disse. Ved å kjenne kundenes ønsker vil det være mulig å forutsi deres behov. Det kan være informasjon om hvor ofte kundene har mottatt nyhetsbrev, hvor ofte kundene har ringt inn for support eller om kundene er fornøyde eller misfornøyde. Gruppe 15 7 av 66

9 Definisjon av verdiskapning: Verdiskapning omfatter økt utvikling for bedriften. Det kan være samarbeid med andre bedrifter, produktutvikling, bedre oppfølging av den enkelte kunde eller også økt vekst og fortjeneste. Følgende ligger til grunn for vinklingen og dybden i denne rapporten: Prosjektgruppen har fått i oppdrag fra Dialogplan AS å lage en CRM modul. Systemet skal gi bedriftskunder en bedre kundeforståelse og økt verdiskapning. (For å få et bedre innsyn i hvilken teori prosjektoppgaven er basert på henvises det til kapittel 2.0 Teori s 10). 1.7 Prosjektorganisering Oppstart hos Dialogplan AS var 13.januar 2004 og prosjektroller ble fordelt. (Viser til prosjektroller og ansvarsfordeling i vedlegg s. 11). Overordnede planer for fremgang og gjennomføring ble umiddelbart utarbeidet. I henhold til planene skal hver arbeidsdag utgjøre åtte timer inkludert 30 minutters spisepause. (Viser til arbeidskontrakt i vedlegg s. 10 og prosjektplaner i vedlegg s. 13). Ved behov vil alle prosjektdeltagere jobbe overtid. Prosjektdeltagerne har fulgt Norges Informasjonsteknologiske Høgskoles retningslinjer for intellektuell redelighet (viser til retningslinjer for intellektuell redelighet vedlegg s. 64). 1.8 Rapport struktur Innledning Kapittel 1, innledning: Prosjektrapporten er den dokumenterende delen av gruppens hovedprosjekt gjennomført våren 2004 ved Norges Informasjonsteknologiske Høgskole. Kapittelet starter med å presentere oppdragsgiver og prosjektoppgave. Visjonen, hovedmål og delmål blir også belyst. I et diplomprosjekt er det mange valg og avgrensninger som skal vurderes og dette er kommentert i dette kapittelet. Det avsluttes med en beskrivelse av prosjektorganiseringen og rapportstrukturen. Kapittel Teori to, teori: Kapittel 2, teori: Teori kapittelet omhandler hva CRM er og hvorfor et system basert på en slik metode kan være med på å øke kundeforståelse og verdiskapning. Programvareløsningen til CRM modulen er utviklet ved bruk av.net rammeverk. Vi ser nærmere på hvordan.net arkitekturen er bygget opp. Vi avslutter kapittelet ved å si noe om hvilke kriterier som kan være viktig å vurdere ved utvikling av et godt brukergrensesnitt benyttet til en CRM modul. Metode Kapittel 3, metode: Kapittelet metoder beskriver valget av utviklingsmodell, teknikker og verktøy som er tatt i bruk i prosjektet. Gruppe 15 8 av 66

10 Kapittel 4, analyse og utforming: Analyse og Kapittelet analyse og utforming beskriver først forretningsbrukstilfelle, Utforming kravspesifikasjon og arkitektur. Deretter kommer en vurdering av alternative løsninger til den utviklede CRM modulen. Løsning Kapittel 5, løsning: I kapittel fem blir løsningen og den organisatoriske løsningen beskrevet. Vurdering av løsning Kapittel 6, vurdering av løsning: Kapittelet presenterer vurdering av løsningen og prosjekt. Vurdering av teknisk resultat vil gi en vurdering av løsningen i forhold til kravspesifikasjonen. Det vil dernest bli gitt en vurdering av hvilken nytte CRM modulen vil ha for oppdragsgiver. Det vil også bli gitt en vurdering av metoder og verktøy gruppen har benyttet seg av i prosjektet. Kapittelet avsluttes med en vurdering av resultatet i forhold til forskningsteori. Vurdering av prosjekt Kapittel 7, vurdering av prosjekt: Prosjektet er basert på tungvektsmetoden RUP og lettvektsmetoden XP. Avsnittet Bruk av RUP og XP som utviklingsmodell gir en vurdering av erfaringen med disse i prosjektet. Konklusjon Kapittel 8, konklusjon: Konklusjonen beskriver grad av måloppnåelse for prosjektgruppe og oppdragsgiver. Som basis for rapportskrivingen er formelle krav til utforming av prosjektoppgaver for Norges Informasjonsteknologiske Høgskole fulgt (NITH 2004). Boken Prosjektoppgaven 2. utgave (Rognsaa 2003) er benyttet som supplement. Gruppe 15 9 av 66

11 2.0 Teori Teorikapittelet omhandler hva begrepet CRM er og hvorfor et system basert på en slik metode kan være med på å øke kundeforståelse og verdiskapning. Programvareløsningen til CRM modulen er utviklet ved bruk av.net rammeverk og vi ser nærmere på hvordan slik arkitekturen er bygd opp. Vi avslutter kapittelet ved å si noe om hvilke kriterier som kan være viktig å vurdere ved utvikling av et godt brukergrensesnitt til en CRM modul. 2.1 Customer Relationship Management Ved prosjektstart hadde gruppen liten kunnskap om CRM. Det førte til at alle måtte sette seg inn i hva dette begrepet innebar. PC World har i en artikkel testet fire ulike CRM systemer (Verwoe 2003). Gruppen valgte ut ifra denne å selv teste noen av systemene (Mamut 2003, SuperOffice 2003, Vega SMB AS 2004). Testingen ga et innblikk i hva slags funksjoner som kunne være potensielle i utviklingen av CRM modulen og vi fikk en bedre forståelse av CRM som begrep. Customer Relationship Management (CRM) er ifølge Eirik Rasmussen en strategi som setter kundenes behov i sentrum (personlig samtale 20. januar 2004). Som begrep er det ikke et verktøy, men en måte å tenke på. Et system basert på CRM skal hjelpe til med å holde oversikt over eksisterende og fremtidige kunder og dermed øke kundeforståelsen. Det er flere måter å følge opp kunder på. Det kan for eksempel være ved hjelp av e-post, telefon eller utsendelse av et spørreskjema. Om en kunde er fornøyd eller misfornøyd er viktig informasjon. God kunnskap om egne kunder er en viktig faktor for å kunne skape god kundelojalitet. Vi er klar over at andre faktorer som fagkunnskap og service også er viktige faktorer for å skape et godt kundeforhold. I boken Principles of Marketing står følgende på bokomslaget om professor Philip Kotler: I mer enn tretti år har Philip Kotler, professor ved The Kellogg Graduate School of Management, vært sjefsguru for markedsføringsstudenter over hele verden. Han har skrevet over 10 bøker som er utgitt på nesten 20 språk, hvorav Marketing Management er utpekt av Financial Times som en av de 50 beste ledelse bøker som noensinne er skrevet. Kotler er tildelt en lang rekke priser og utmerkelser og blitt utnevnt til æresdoktor ved flere universiteter (Kotler 1999). I boken Principles of Marketing nevner Kotler (1999) fire prinsipper for hva som bør gjøres for å vinne kunder i den elektroniske tidsalder. Vi nevner to av de her. Det første prinsippet lyder som følger: Etabler og styr en aktiv kundedatabase (sst. s 270). Anvendelsen av en kundedatabase kan gi et selskap et sterkt konkurransefortrinn. En database med kundeinformasjon kan gjøre det mulig å nå ut til kundene på en effektiv måte. Ved hjelp av en database kan kundene registreres med navn, profiler, målgruppe, prosjekter, en kundes ønsker med mer. En bedrift kan nyttiggjøre seg informasjonen om de ulike gruppene av kunder og deres ønsker. Det andre prinsippet, nummer fire, lyder som Gruppe av 66

12 følger: Vær lett tilgjengelig og besvar kundehenvendelser raskt (sst. s 274). Kundeservice er essensielt for om kunden vil komme tilbake eller bli borte for godt. En CRM modul med god oversikt over når kunder har tatt kontakt, hva et eventuelt problem var, når de bør kontaktes igjen og lignende kan føre til at en ny kunde kan bli en fast kunde. Et CRM system i seg selv vil ikke gjøre at kundemassen øker, det er hvordan teknologien tas i bruk som kan øke kundeforståelsen og verdiskapningen. Gartner Inc. er et forsknings og rådgivnings firma som foretar analyser og utredninger (Gartner 2004). Selskapet består av analytikere og konsulenter i mer enn 75 land. Gartner har gjennomført en analyse om brukernes erfaringer med CRM systemer og konkluderer med at det ikke er leverandørenes feil selv om produktene ikke er perfekte (ifølge Ryvardsen 2004). Det er bedriftene selv og deres implementeringskonsulenter som står for feilene (sst.). De syv vanligste forholdene er følgende: - Dårlig datakvalitet - Intern politikk - Manglende samarbeid - Ingen plan - Tenker ikke på kundene - Viderefører feil - Mangel på opplæring Disse syv forholdene er feil som går igjen i helt eller delvis mislykkede CRM prosjekter (sst.). Capgemini er et av verdens ledende forretningsrådgivnings- og ITkonsulentselskaper. For å bistå virksomheter med å iverksette strategier og utnytte teknologi, tilbyr selskapet forretnings- og IT-rådgivningstjenester, systemintegrasjon samt løsningsdesign og eksternt konsulentarbeid på global basis.(capgemini 2004, kilde A). Et sentralt element innen CRM er verdikjeden (Capgemini 2004, kilde B). Verdikjeden omhandler kunnskap, styring, salg og tjenester. Har vi kunnskap om kunden vil det kunne føre til økt kundeforståelse. CRM skal hjelpe din bedrift til å beholde de viktige kundene og gjøre de mer lønnsomme (Capgemini 2004, kilde C ). En bedrift bør velge en CRM modul for å øke salget, for bedre kundeservice og for å oppnå større effektivitet. Dette kan igjen føre til økt verdiskapning. Gruppe av 66

13 Figur 1, verdikjeden (Capgemini 2004, kilde B) Verdikjeden viser at har vi kunnskap om kundene og deres bakgrunn kan vi på en enklere måte analysere de. Capgemini (2004) peker på sju punkter de mener kan oppnås ved bruk av et CRM system. De er følgende: - Forutse kundenes behov - Mer lønnsom kundesammensetning - Mer fornøyde kunder - Økt kundelojalitet - Bedre kundeservice - Fokus på total inntjening gjennom hele kundens levetid - Kundeforhold som gir verdiskapning for begge parter 2.2.NET Arkitektur.NET Opplevelsen I februar 2002 ble Visual Studio.NET og Microsoft.NET Framework introdusert til verdens utviklere og arkitekter (Microsoft.NET 2004). Et nytt utviklingsmiljø og en ny programmeringsmodell var laget for å utvikle nye programvare løsninger..net, opplevelsen som Microsoft sier selv, er dataopplevelsen til sluttbrukeren med tjenester bygget på.net plattformen. Teknisk er.net opplevelsen en kombinasjon av Extensible Markup Language (XML) Web Services og lokal programmeringskode..net plattformen knytter datamaskiner, XML Web Services og mennesker sammen (sst.)..net plattformen består av alle produktene, utviklingsverktøyene og operativsystemene som brukes til å bygge, vise frem og kjøre XML Web Services. Ifølge Microsoft består plattformen av fire komponenter: -.NET Framwork og Visual Studio.NET - Tjenerinfrastruktur - Komponenttjenester Gruppe av 66

14 - Programvare for smarte enheter.net Framework er støttemiljøet til alle :NET baserte produkter. XML Web Services og programmer bygges, installeres og kjøres med støtte fra dette rammeverket.net arkitekturen er i stor grad tilrettelagt for distribuerte systemer. Til nå har den mest utbredte programmeringsteknikken vært å ha en todeling mellom en klient og en tjener. XML Web Services er hovedkomponenten i.net hvor man enkelt legger opp til distribuerte applikasjoner på flere noder i et nettverk. I denne sammenheng kan noder være alt fra en tjener, et nettsted og til en PDA. (sst.). Denne tilretteleggelsen har vært et viktig ledd i måten systemet er utviklet på. XML Web Services XML Web Services er selvstendige enheter som tilbyr sine tjenester til klienter over Internett. Figur 2, XML Web Services using.net (Microsoft 2003) Gruppe av 66

15 En XML Web Service er nøkkelkomponenten i Microsoft sitt.net rammeverk. Den er bygget opp av fire deler. En sikkerhetsmodul, en modul for forretningslogikk, en XML data modul og en overordnet prosesstyringsmodul. XML Web Services fungerer som et nav mellom utviklere, lagret data og kunder. Utviklere bygger opp XML Web Services og kommuniserer med den gjennom UDDI. XML Web Services henter og lagrer data fra datakilder som objekter gjennom ADO.NET. Klienter som bruker XML Web Services kommuniserer med denne gjennom XML, og henter og sender data via SOAP. ADO.NET ADO.NET er Microsoft sin teknologi for aksess til ulike datakilder som databaser, XML og andre OLE DB datakilder. Det er gjennom en slik forbindelse mulig å innhente, manipulere og oppdatere data. ADO.NET lager dataaksesskomponenter som objekter som er vel egnet til oppdeling i mindre deler som kan gjenbrukes hver for seg eller som en enhet i andre programmer. ADO.NET transporterer dataene hovedsakelig i datasett. Denne strukturen baserer seg igjen sin oppbygning på XML struktur. (MSDN 2004, kilde C) Extensible Markup Language (XML) XML er det universelle formatet for strukturert data på Internett. XML består av en rekke regler for utforming av tekstformat for data, noe som gjør det enklere å fremstille filer som er lette å generere og lese, utvetydige og plattformsuavhengige. For at et nettprogram i dag skal kunne hente data fra et annet, må man stort sett benytte terminalemulering det vil si hente et bilde av den skjermen som inneholder aktuelle data og siden forsøke å gjentolke bildet til data. Denne metoden er både ineffektiv og feilbarlig. XML er et format som kan benyttes for å hente ut virkelige data, i stedet for kun bilder av dataene, mellom ulike XML Web Services. (Microsoft.NET 2004) Simple Object Access Protocol (SOAP) SOAP bygger på XML og HTTP. Denne teknologien gjør det mulig med anrop mellom ulike programmer på en løst sammensatt standardisert måte. Dette er noe som igjen gjør det mulig å bygge programmer som distribueres over Internett. Om man forestiller seg interaksjonen mellom ulike XML Web services som en telefonsamtale, tilsvarer XML det programmene sier til hverandre og SOAP hvilken måte telefonene brukes. Nøyaktig som med XML inngår SOAP i W3C s standardiseringsprosess, og ble innlevert av Microsoft og en rekke andre selskaper, blant annet IBM. Både XML og SOAP har offisiell støtte fra stort sett alle større programvarehus i bransjen (for eksempel Microsoft, IBM, HP, Sun og Oracle). (sst.). Universal Description, Discovery and Integration (UDDI) En fritt tilgjengelig spesifikasjon for distribuerte XML-baserte kataloger over Web Services. En Web Services er en applikasjon eller en del av en applikasjon som kan aksessers gjennom nett av andre programmer. UDDI-kataloger (register) lar deg beskrive og finne det du er ute etter. UDDI er nært, men ikke eksklusivt, knyttet til det XML-baserte WSDL ( Web Services Description Language ). UDDI er spesifisert av Ariba, IBM og Microsoft, og tiltrådt av en rekke sentrale aktører innen utvikling av e-handelsapplikasjoner. WDSL er spesifisert av IBM og Microsoft. (Digi.no 2004). Gruppe av 66

16 2.3 Brukervennlighet I og med at CRM modulen skal være nettbasert er det viktig å utvikle et godt tilpasset brukergrensesnitt. Vi har lagt vekt på faktorer fra to dyktige fagmenn, Jakob Nielsen og Theo Mandel. Jakob Nielsen som er regnet som The king of usability ifølge Internet Magazine (2004) har en doktorgrad innenfor brukergrensesnitt ved universitetet i Danmark. Han startet med nettdesign i 1994 og erfarte at de feil han gjorde de første årene også ble gjort av andre i oppstartsfasen. Han har derfor med sine bøker gjort et forsøk på å forebygge at nettdesignere gjør de samme fundamentale feil (Nielsen 2000). I boken Designing Web Usability sier Jakob Nielsen (2000) at når det gjelder design av brukergrensesnitt er enkelhet et mål for designeren. Brukere er sjelden på en side for å se på designet, det er innholdet som er viktig mener Nielsen. Fargen på arbeidssiden er et sentralt punkt. Skal man sitte foran et skjermbilde som har sterke farger kan det være vanskelig å lese. Skal en bakgrunn velges, bør det være en nøytral farge som gir god kontrast til sort skrift. Det er også viktig at teksten står stille. Tekst som beveger på seg eller blinker er vanskelig å lese. Det eksisterer mange gode skrifttyper, men det viktige er at teksten skal være godt synlig. Nielsen sier at de fleste mennesker foretrekker å lese en type Serif tekst slik som Verdana (2000 side 126). Han anbefaler å ikke spesifisere en skrittype da det kan bli et problem når brukeren skal få opp en side fra en maskin som ikke har den aktuelle skrittypen. Skal en spesifikk skrittype brukes, anbefales det å liste opp alternativer for å minske risikoen for problemer. Når brukeren skal lese teksten på nettsiden gir en venstre justert tekst et stabilt startsted for øyet. Man leser raskere om teksten ikke er midtstilt eller høyre justert (sst.). For å oppnå lett navigering kan det lønne seg med interne lenker eller faner (sst.). Brukeren slipper da mange forskjellige skjermbilder, som kan oppfattes forvirrende. Navigering skal frembringe enkelhet, og meningsfulle stier og utganger. Kjente navigeringspiler er en fordel. Det er viktig at programmet er lett å lære og lett å huske. Tekstbokser med lik størrelse kan gi et godt organisert brukergrensesnitt. For brukeren som benytter systemet jevnlig er det viktig å kjenne seg igjen, og derfor er kjente knapper en god ting å ta med. Et eksempel kan være verktøyraden som er øverst i Microsoft Office produkter. Dette er knapper de fleste er kjent med. Rullefelt er et annet hjelpemiddel for navigering internt på skjermbildet. Et rullefelt kan være til hjelp slik at ikke mye informasjon eller mange valg nødvendigvis må vises på siden. Det er viktig at siden kan fungere på mange ulike plattformer og med ulik teknologi.. Nielsen (2000) anbefaler at siden bør kunne brukes av en nettleser som er inntil tre år gammel. Det er ca 10 % av brukerne som vanligvis bruker eldre programvare og teknologi og det er synd å miste denne andelen av kundene. Design som kan brukes på alle skjermoppløsninger anbefales av Nielsen. I stedet for å bruke bestemte størrelser, burde layouten spesifiseres i prosent av den tilgjengelige størrelsen. Det er viktig å huske at ulike mennesker har ulik meninger om skriftstørrelser. Det er viktig å forsikre seg om at designet fungerer bra med små og store skriftstørrelser. Gruppe av 66

17 På grunn av ulike nettlesere og oppløsninger anbefales stilark. Et enkelt stilark kan benyttes på alle undersidene på nettstedet og er tidsbesparende. Sidene blir konsistente og stilrene. Ved å gjøre en endring på en skrittype kan endringen skje for eksempel på ti ulike sider. Det eksisterer ulike stilark: Cascading Style Sheet og Javaskript Style Sheet er to av de. Det er alltid ønskelig at brukergrensesnittet er så lett å lære at det ikke er nødvendig med en brukermanual eller en hjelpefunksjon. Er det nødvendig skal brukermanualen eller hjelpfunksjonen være lett leselig. Nielsen første lov om brukermanualer lyder som følger: Mennesker leser ikke brukermanualer frivillig! Eneste gangen de faktisk leser brukermanualer er når de har problemer og ikke får systemet til å fungere. (Nielsen 2000 s. 129). I boken Interface Design and Development står følgende på bokomslaget om Theo Mandel: Theo Mandel, Phd er en konsulent, forfatter og en foredragsholder. Han er grunnlegger og rektor for studiet Interface Design and Development i Austin, Texas. Han jobbet for IBM i tolv år innen ulikefelt innen program utvikling. Mandel er en spesialist innen brukergrensesnitt design. (Mandel 1997). Mandel påpeker at våre erfaringer med tidligere programvarer forteller noe om hvordan vi vil reagere på et nytt system (1997). For å designe et godt system er det viktig å vite hvem bruker er, hvilke funksjoner brukeren forventer og hvordan han vil bruke programmet. Microsoft har med sin dominerende posisjon i markedet gjort at mange produserer programvare basert på Microsoft Windows sitt brukergrensesnitt. Fra sin oppstart i 1975 og frem til 2004 har de fleste erfaring fra Microsoft sine produkter. Korttidsminne er karakteristisk og setter grenser for design av brukergrensesnittet. Dersom en brukeren ønsker å skrive inn informasjon på skjermen og spør om hjelp, er det viktig at ikke hjelpevinduet dekker til det som brukeren ønsket hjelp om. Mange trenger å gå tilbake til hjelpevinduet to og tre ganger før de får all informasjonen de trenger. Det er essensielt at sprettoppvinduer vinduer kommer opp på riktig sted. (Mandel 1997). ). Innen brukergrensesnittdesign er det tre elementære prinsipper som gjelder (Mandel 1997): La brukeren ha kontroll over brukergrensesnittet - la brukeren velge om han ønsker å bruke tastatur eller mus - la brukeren ha mulighet til å kansellere eller lagre en jobb og ha muligheten til å fortsette senere der han sluttet - gi brukeren en indikasjon på om påbegynt funksjon er fullført Reduser brukerens minnebelastning - bruk lister og menyer som lar brukeren velge innholdet i felt istedenfor å fylle de ut - la brukeren ha enkel tilgang til funksjoner som brukes ofte Det er ikke nødvendig å ha all informasjon i et vindu Gruppe av 66

18 La brukergrensesnittet være konsistent - la brukeren kjenne igjen brukergrensesnittet fra tidligere erfaringer med andre programmer - sekvenser og steg i et program bør være konsistente. Navigeringen bør være lik i alle vinduer til et program Prinsippene er ikke ment å alltid følges til punkt og prikke, men mer ment som retningslinjer. Prinsippene er ikke bare relevante for dagens designere, men har vært noenlunde de samme i mange år. De første prinsippene i 1971 ifølge Mandel (1997). Gruppe av 66

19 3.0 Metode Kapitlet metode beskriver valg av utviklingsmodell, teknikker og verktøy som er tatt i bruk i prosjektet. 3.1 Kvalitativ metode Prosjektoppgavens teorigrunnlag er basert på en kvalitativ metode. Gruppen hadde på grunn av tidsmessige årsaker ingen mulighet til selv å foreta undersøkelser i forkant av prosjektet. All forskning er derfor basert på sekundær informasjon. Gruppen har systematisk gått igjennom utvalgte kilder og dokumentasjon. 3.2 Valg av utviklingsmodell Rational Unified Process (RUP) er hovedsakelig benyttet som rammeverk for prosjektet (Kruchten 2000). RUP er en iterativ og inkrementell prosessmodell for systemutvikling, utviklet av Rational Software. RUP kan benyttes til de fleste utviklingsprosjekt, fra små til store prosjekter (sst.). Hensikten med modellen er å sette utviklere i stand til å konstruere systemer av høy kvalitet. Et utvalg av prinsipper og praksiser fra lettvektsmetoden Extreme programming (XP) ble også valgt som en del av rammeverket til prosjektet. XP består av fem basisprinsipper som ble valgt: Hurtig tilbakemelding (læringseffekter), forutsett enkelthet (enkle løsninger bedre enn kompliserte), inkrementell endring (små endringer) omfavn endring og kvalitetsarbeid (ingen liker å gjøre dårlig arbeid). Det ble valgt ut to praksiser, parvis programmering og enkel design. Parvis programmering ble valgt av den grunn at forskning viser at parvis programmering øker kvaliteten uten å påvirke avleveringstiden (Beck 2000). Enkelt design skal ta mindre tid å utføre enn et komplekst et (sst.). Det vil også være enklere for oppdragsgiver å sette seg inn en enkel design, enn en komplisert design Tilpassing av RUP Ved start av prosjektet satte vi opp en plan for hele prosjektet. Vi valgte å bruke RUP sine hovedfaser: Idefasen, utdypningsfasen, konstruksjonsfasen og overleveringsfasen. Under følger de artefaktene vi har valgt å bruke og å arbeide etter: Forretningsmodell - viser forretningsprosessene i den aktuelle organisasjonen.. (Viser til kapittel 4.0 analyse og utforming side 24 for nærmere dokumentasjon.) Domenemodell - også kalt en konseptuel modell, angir sammen med forretningsmodellen en kontekst og et vokabular for systemet. (Viser til vedlegg s. 76 for nærmere dokumentasjon.). Gruppe av 66

20 Brukstilfellemodell - modellering av brukstilfelle er en metode for å vise funksjonelle krav. (Viser til kapittel 4.0 analyse og utforming side 24 for nærmere dokumentasjon.) Designmodell designmodellen viser vokabularet av problemet og dets løsningen (Booch mfl. 1999). (Viser til kapittel logisk perspektiv side 31 for nærmere dokumentasjon.) Prosessmodell prosessmodellen fokuserer på hvordan prosessen i systemet organiseres når systemet kjører. Utplasseringsmodell en utplasseringsmodell viser hvordan de ulike komponentene i systemet er utplassert i forhold til hverandre. Implementasjonsmodell - viser hvilke komponenter systemet består av Testmodell - testing består av et utvalg av metoder som brukes til å finne feil i applikasjonen. (Se vedlegg s. 93 for nærmere dokumentasjon om testing.) Andre metoder Det eksisterer ulike systemeringsmetoder. Vi har tatt utgangspunkt i de som vi har erfaring i fra studier ved Norges Informasjonsteknologiske Høgskole. RUP og XP er to ulike metoder forklart ovenfor. Microsoft Solution Framwork (MSF) er et tredje alternativ. MSF er et prosjektrammeverk utviklet av Microsoft. Metoden har flere likheter med RUP, blant annet benytter MSF begreper som iterasjon og rolle. MSF ble hovedsakelig ikke benyttet på bakgrunn av lite erfaring med rammeverket. MSF ble i vår skolesammenheng kun benyttet til to små prosjekter, mens RUP ble benyttet til et prosjekt som gikk over et år. 3.3 Teknikker og verktøy Kapittelet teknikker og verktøy gir en beskrivelse av de verktøy benyttet under utviklingen av CRM modulen samt styringsverktøy som ble brukt til prosjekt arbeidet Rational Rose Enterprise Edition Version Rational Rose er et modelleringsverktøy for analyse og design som støtter Unified Modeling Language. Rational Rose benyttes i stor grad til å visualisere objektorienterte datasystemer. (For nærmere dokumentasjon se kapittel 7.2 s.50, vurdering av verktøy). Gruppe av 66