UTVECKLING AV CRM-SYSTEMET ADMETA SALES MANAGER

Examensarbete 20 poäng D-nivå UTVECKLING AV CRM-SYSTEMET ADMETA SALES MANAGER Reg.kod: Oru-Te-EXA089-D101/04 Henrik Bark och Martin Zackrisson Datamagisterprogrammet 160 p Örebro vårterminen 2004 Handledare: Thomas Padron-McCarthy Examinator: Lars Karlsson DEVELOPMENT OF THE CRM SYSTEM ADMETA SALES MANAGER Örebro universitet Örebro University Institutionen för teknik Department of technology 701 82 Örebro SE-701 82 Örebro, Sweden

Sammanfattning Denna rapport beskriver utvecklingen av CRM-systemet Admeta Sales Manager, som utvecklades för företaget Admeta AB. Ett CRM-system, där CRM står för Customer Relationship Management, hjälper företag att upprätthålla en bra kontakt med och ha översikt över sina befintliga kunder. Applikationens uppgift är att vara stöd åt säljare och supportpersonal samt ge företaget en möjlighet att själva sköta faktureringen, som idag sköts externt. De tekniker vi använt oss av i utvecklingen av systemet är.net, C#, MySQL och SQL. Utvecklingsmiljön och programvarorna vi använt oss av är Microsoft Visual Studio 2003.NET, MySQL Control Center och ritprogrammet dia. Arbetet har gett oss inblick i metodlösningar, hur det är att bedriva konsultverksamhet för ett projekt samt även att på egen hand hitta på lösningar till problem. Abstract This report describes the development of the CRM system Admeta Sales Manager, which was developed for the company Admeta AB. A CRM system, where CRM is a shortening of Customer Realtionship Management, helps companies to uphold a good contact and have overview of their current clients. The purpose of the application was to assist sales and support personnel and to give Admeta the possibility to handle invoices, which are currently handled externally. The technologies we used in the development of the system are.net, C# and SQL. The enviroment and tools we worked with were Microsoft Visual Studio 2003.NET, MySQL Control Center and the designtool dia. This project has given us experience of methodical solutions, of running a consulting project and of finding solutions to technical difficulties. 2 (27)

Förord Vårt examensarbete omfattar 20 poäng och ingår i Magisterprogrammet i Datateknik (160 p) vid Örebro Universitet. Arbetet har utförts på företaget Admeta AB under våren 2004. Vi vill passa på att tacka alla inblandade på Admeta AB, särskilt vår handledare Leif Jägerbrand som har hjälpt oss med utvecklingen och designen. Fredrik Strauss och Jonas Svensson som har kommit med goda idéer och förslag. Vi vill även tacka Thomas Padron-McCarthy, vår handledare på Örebro universitet. Örebro den 2004-07-10 Henrik Bark Martin Zackrisson 3 (27)

1 INLEDNING... 5 1.1 ADMETA AB... 5 1.2 SYFTE... 5 1.3 MÅL... 6 2 METOD... 7 2.1 ARBETSGÅNG... 7 2.2 CRM-SYSTEM I KORTHET... 7 2.3 TRESKIKTSMODELL... 8 3 VERKTYG... 9 3.1 MICROSOFT VISUAL STUDIO.NET 2003... 9 3.2.NET FRAMEWORK 1.1...9 3.3 C#... 9 3.4 SQL... 10 3.5 MYSQL... 10 4 GENOMFÖRANDE... 11 4.1 KRAVSPECIFIKATION... 11 4.2 UTVECKLINGSMETOD...12 4.3 KRAVUTVECKLING... 12 4.4 ANVÄNDARGRÄNSSNITT... 13 4.5 LOGIK... 14 4.6 DATABASSCHEMA... 14 4.6.1 Databaskoppling... 14 4.6.2 Databasens uppbyggnad... 14 5 APPLIKATIONEN... 16 5.1 LOGIN... 16 5.2 TREEVIEW... 17 5.3 LISTVIEW... 17 5.4 INSERTER... 18 5.5 SÖKNING... 19 5.6 KUNDMENY... 20 5.7 UPDATER... 21 5.8 CHART... 22 6 ANALYS... 23 6.1 LÄRDOMAR... 23 6.2 PRIORITERING... 23 6.3 UTVECKLINGEN... 23 6.4 SÄKERHETSANALYS... 24 6.5 RESULTAT... 24 6.5.1 Användaranpassning... 24 7 DISKUSSION... 25 7.1 MÅL... 25 7.2 VIDAREUTVECKLING... 25 8 REFERENSER... 26 8.1 BÖCKER... 26 8.2 INTERNET... 26 9 TERMINOLOGI... 27 4 (27)

1 Inledning I det här kapitlet redovisar vi åt vilket företag vi utfört examensarbetet, samt syfte och mål för projektet. 1.1 Admeta AB Admeta är bland de första företagen i världen att erbjuda ett beslutsstödssystem för att i realtid analysera effektiviteten av annonser på Internet. Med systemets hjälp kan ett företag lätt se var deras Internetannonser har högst respektive lägst effektivitet, dvs. vilka annonser som leder till försäljning och vilka som kan anses överflödiga. Admeta är helt oberoende i förhållande till medieföretag och annonsnätverk. Kunderna betalar för tillgången på systemet som används under och efter onlinekampanjerna. Tekniken som Admetas system är uppbyggt kring är patenterad och unik i sitt slag. Bolaget startades 2001 av Leif Jägerbrand och Fredrik Strauss inom ramen för teknikinkubatorn Chalmers Innovation i Göteborg. Idag är sex personer verksamma på heltid i bolaget. Utöver detta finns en forskningsgrupp inom artificiell intelligens på Chalmers tekniska högskola knuten till företaget. För mer information om Admeta se [15]. 1.2 Syfte Kravspecifikationen var det som låg till grund för vad som önskades av systemet. Nedan följer ett utdrag ur specifikationen för examensarbetet: Admeta är ett expanderande företag och har idag problem med att få en bra översikt över faktureringen. Den sköts av extern part, men Admeta tillhandahåller fakturaunderlaget. Detta betyder att Admeta är ansvarigt för att alla tjänster som företaget utfört faktureras. Ibland glöms fakturering bort, för att man inte haft en bra översikt över den, och det har lett till bortkastade pengar. En applikation som ger en överskådlig blick över tjänster och fakturor är därför önskvärd. Admeta använder sig av flera olika slags typer av fakturor och har därför svårt att kunna använda sig av generell programvara för att sköta om faktureringen. Systemet som eftersöks skall göra det enkelt att ha översikt över fakturering, klara av att påminna användaren om när det är dags att fakturera samt ha en avstämningsfunktion för att kunna avgöra om påminnelse måste skickas eller om fakturan blivit korrekt betald. Önskvärt vore om systemet även kunde visa statistik över faktureringen, dels för betalda fakturor och dels för det som skall faktureras framöver. Eftersom Admeta använder sig av cirka 15 olika konton vore det även bra att se statistik för hur faktureringen är uppdelad mellan dessa konton. Efter diskussioner kring specifikationen och Admetas nuvarande system kom vi till slutsatsen att ett CRM-system skulle utvecklas och att utvecklingen av detta skulle bli syftet med hela examensarbetet. 5 (27)

CRM-systemet skall hantera faktureringar som önskades av Admeta, men även fungera som säljoch supportstöd. Användarna (Säljare, Support, Admin) har olika roller samt rättigheter och skall i applikationen kunna skapa och hantera: Offerter Kontrakt Fakturor Övriga aktiviteter Detta skall kunna göras för alla kunder i kundregistret. En statistikdel skall även ingå för att få en bra översikt över fakturering och andra aktiviteter. 1.3 Mål Målet var att färdigställa en fungerande applikation, med full funktionalitet och en koppling mot en egenutvecklad MySQL-databas. 6 (27)

2 Metod 2.1 Arbetsgång Arbetsgången för examensarbetet såg ut enligt följande: Utredning av kravspecifikation Utveckling av designen och kraven för applikationen Specificering av detaljkrav för applikationen Design av MySQL-databas Utveckla systemet enligt treskiktsmodell Implementation av klasser och databasanrop Testning och felrättning I grund och botten liknar systemet som utvecklats ett traditionellt CRM-system. Skillnaden ligger i att applikationen vi utvecklat innehåller funktioner och verktyg som är specifika efter Admetas behov. 2.2 CRM-system i korthet Ett CRM-system, där CRM står för Customer Relationship Management, hjälper ett företag att hålla reda på information om sina kunder. Det får företaget att känna till kundens behov samt förbättrar relationen mellan parterna. Det bygger på att kontinuerligt samla all viktig data rörande kunder och göra den tillgänglig för dem som har tillgång till systemet. Det passar främst de områden som utgår från sälj- och supportfunktioner. Säljarna ser vilken kund som bör kontaktas och kan planera aktiviteter efter det. Supporten ser vilka typer av problem som dyker upp och kan åtgärda dem så att de inte återkommer gång på gång. Det ger samtidigt företagsledningen en bättre överblick på hur säljarna sköter sitt jobb samt gör att exempelvis en säljare som tidigare inte varit i direktkontakt med kunden snabbt kan sätta sig in i hela kundprocessen genom att läsa igenom kontakthistoriken. Systemet skall leda till bättre kundservice, effektivare arbete, bättre försäljning och därmed ökad vinst. 7 (27)

2.3 Treskiktsmodell Applikationen är uppbyggd enligt en traditionell treskiktsmodell (figur 2.1), då vi ansåg denna lösning mest passande till ändamålet. Figur 2.1: Översikt av treskiktsmodellen. Presentationsskiktet: På översta nivån finns presentationsskiktet, alltså det skikt användaren styr och ser. Översta skiktet tillhandahåller en brygga till det mellanliggande skiktet. Logikskiktet: Mellanskiktet innehåller funktioner och logik och sköter kopplingen mellan databasskiktet och presentationsskiktet. Funktionerna och logiken bearbetar och hanterar data, från de olika skikten, som sedan återges i presentationsskiktet. Databasskiktet: På den nedersta nivån sköts all kommunikation med databasen. Databasskiktet sköter kopplingen mellan databasen och presentationsskiktet och sköter all in- och utmatning från databasen. För mer information om treskiktsmodellen se [15]. 8 (27)

3 Verktyg Detta kapitel omfattar och ger en grundlig beskrivning av de, för oss, nya programvaror och tekniker som använts vid utvecklingen av Admeta Sales Manager. Microsoft Visual Studio.NET 2003.NET Framework 1.1 C# SQL MySQL 3.1 Microsoft Visual Studio.NET 2003 Visual Studio.NET 2003 (VS.NET 2003) var utvecklingsmiljön vi använde oss av för att utveckla applikationen. I april 2003 släpptes version 1.1 av.net Framework och samtidigt passade även Microsoft på att släppa version 2003 av Visual Studio. Själva utvecklingsmiljön är språkneutral, tillåter kodning och felsökning för alla.net-språk och ser dessutom likadan ut oavsett språkval. De programmeringsspråk som stöds är Visual C#.NET, Visual Basic.NET, Visual C++.NET och Visual J#.NET. VS.NET 2003 har även databasstöd baserat på ADO.NET samt ett XML-designverktyg. 3.2.NET Framework 1.1.NET Framework är en plattform för programutveckling utvecklad av Microsoft. Även om det i dagsläget inte har fullt utvecklat stöd för mer än Windows, så finns det planer på versioner av.net Framework för andra operativsystem, som t.ex. Linux, Macintosh och FreeBSD. En av de främsta anledningarna till uppkomsten av plattformen är att olika operativsystem skall kunna interagera med varandra på ett förtjänstfullt sätt. Tanken är att ett program utvecklat under.net skall vara körbart under Linux även om det är utvecklat under Windows..NET Framework består huvudsakligen av ett stort bibliotek som är uppdelat i moduler. Olika moduler används beroende på vad man vill åstadkomma, t.ex. kod för Windowsprogram, kommunikation eller webbutveckling. Med detta vill man uppnå att alla moduler inte behövs för alla typer av operativsystem utan att bara specifika delar används för det operativsystem som körs. Förutom att biblioteket tillhandahåller en kärna av programmeringsfunktioner ingår även en exekveringsmotor, Common Language Runtime (CLR), som beskrivs mer ingående senare. 3.3 C# Språket vi använde oss av vid utveckling av applikationen var C#, eller C-Sharp som det uttalas. Enligt utvecklaren Microsoft är det ett av de kraftfullaste objektorienterade språk som någonsin utvecklats. Admeta önskade att applikationen skulle utvecklas under plattformen.net och det fick vi ta hänsyn till när vi valde utvecklingsspråk. Eftersom vi båda var intresserade av att lära oss C#, var valet inte svårt. Vi började med att studera språket för att få full förståelse för funktionaliteten och se vad som skiljde C# från språk vi tidigare arbetat med. Se [1] och [2]. 9 (27)

C# är ett starkt typat objektorienterat språk som är designat att vara optimerat gällande enkelhet, flexibilitet och prestanda. Det skapades för att snabbt kunna utveckla ett brett sortiment av olika sorters applikationer för Microsofts plattform.net. Språket släpptes till allmänheten i juni 2000 och är nu, efter flera efterföljande versioner, uppe i version 2.0. Med C# ville man ta till vara det som var bra i redan existerande språk som C och C++, och lägga till förbättringar för att skapa något ännu bättre. Resultatet blev ett språk som påminner väldigt mycket om Java eftersom man endast använder sig av en symbol, punkt-operatorn, för att arbeta med medlemmar och funktioner. Detta motverkar förvirringar från C och C++, då man använder sig av någon av de tre operatorerna (::,. eller ->). En annan del som man slipper i C# är komplexiteten och problemen med pekare. Automatisk skräpsamling och typsäkerhet är numera integrerade delar av språket. En applikation skriven i C# exekveras på samma sätt som i Java. Detta innebär att applikationen kräver en exekveringsmotor, exempelvis CLR (Common Language Runtime), för att kunna exekveras på en dator. Till skillnad från en C++-kompilator som skapar maskinspråk, skapar kompilatorn i C# en Intermediate Language-fil, även kallad IL-fil. Det är den fil som CLR använder sig av för att göra en sista kompilering och översätta koden till ett maskinspråk som datorn kan förstå, innan applikationen startas. På grund av denna sista kompilering innan första programstart tar det lite längre tid att exekvera en C# applikation första gången jämfört med ett helt kompilerat språk som C++. Men efter första gången försvinner denna skillnad i och med att den helt kompilerade versionen används i fortsättningen. Tekniken för att skapa ett C#-projekt eller en.net-applikation kan du läsa mer om i Appendix A, [1] och [2]. 3.4 SQL SQL är en förkortning av Structured Query Language. Det är ett standardiserat språk som används för att ställa frågor till en relationsdatabas. Med dessa frågor kan man hämta ut, lägga till, uppdatera och ta bort data ur databasen. Strukturen av språket gör att det är enkelt att lära sig grunderna. Det finns både ANSI och ISO standard av språket och numera finns det flera olika dialekter av språket beroende på vilken databashanterare man använder sig av. För mer information om SQL se [4] och [6] (kapitel 5 och 6). 3.5 MySQL Enligt ett av de icke-funktionella kraven från Admeta skulle version 4.0.15 av MySQL användas. Men eftersom det rekommenderades på MySQL:s webbsida att man skulle använda sig av deras senast utvecklade version 4.0.18, beslutade vi att göra så. MySQL är ett databasalternativ som är utvecklat av ett svenskt företag med samma namn. Den har fått mycket bra kritik av media och utvecklare och är idag ett av de mer populära alternativen. Arkitekturen gör den extremt snabb och enkel att konfigurera. I nuläget saknas stöd för skapande av referensnycklar, nästlade SQL-frågor, vyer, triggers och lagrade procedurer, men det är enligt MySQL AB på väg. Från utvecklarens webbplats kan man ladda hem relationsdatabasservern som vi använt oss av. Den bygger på öppen källkod, och är licensierad under GPL (General Public License). Läs mer om GPL på [12] och [13]. 10 (27)

4 Genomförande Detta kapitel beskriver hur projektet fortskridit, val av utvecklingsmetod och hur kravspecifikationen för applikationen vuxit fram från den diffusa kravspecifikation som vi utgick från. Vi förklarar även hur vi byggt upp applikationens logik, databasen och vilken typ av databaskoppling som används. 4.1 Kravspecifikation En stor del av arbetet utgörs av att utforma kravspecifikationen och utveckla designen därefter. Den största delen av examensarbetet bör fokuseras på detta, så att flödet mellan systemets delar fungerar bra. En viktig del är även att kunna förstå hur kunden, Admeta, vill att systemet skall fungera och även komma med egna förslag på lösningar eller förbättringar. (Utdrag ur specifikationen från Admeta) Kravspecifikationen var tvungen att delas upp i olika delar. Dels de krav som Admeta ställde på applikationen och dels de krav som vi själva ställde. Admeta AB önskade en applikation som uppfyllde kraven enligt följande: Det skall vara användarvänligt Det skall vara behörighetsanpassat Faktureringssystem Påminnelsefunktion Det skall byggas på plattformen.net Vi som utvecklare ansåg att projektet gav oss en utomordentlig chans att skaffa oss kunskaper som har hög efterfrågan på arbetsmarknaden och satte följande krav: Det skall utvecklas med C# De slutliga detaljkraven som utvecklades under projekttiden för applikationen kan ses under Appendix D. 11 (27)

4.2 Utvecklingsmetod Figur 4.1: Diagram över arbetsgången Eftersom det inte fanns någon klar kravbild för applikationen tidigt i projektet och eftersom specifikationen för examensarbetet var att upprätta design och krav för applikationen var det svårt att välja en metod att utgå ifrån. Mycket av arbetet låg i att utveckla en bra prototyp som senare kunde vidareutvecklas till en klar produkt i mån av tid. Ett klart metodval i form av vattenfallsmodellen, TPFD, RUP eller liknande var svårt att göra. Kraven fastställdes tidigt likt i vattenfallmodellen, men omformades senare. Allt detta skedde i korta inkrement. Det som var väsentligt för projektet var att utveckla kravbilden och sedan följa den så långt tiden räckte till. För mer information om utvecklingsmetoder se [5]. 4.3 Kravutveckling Utifrån den grundläggande kravspecifikationen för examensarbetet gick det inte att klargöra exakt vad som krävdes av systemet eller hur upplägget av det skulle se ut. För att reda ut funktionalitet och design gjordes först en grov skiss av systemet, och det var på detta sätt som utvecklingen till en början fortskred. Allteftersom tiden gick och kraven utvecklades växte även systemet. Ytterligare funktionalitet lades till och nya idéer tillkom för varje möte med Admeta då systemet diskuterades. Många delar tillkom och vissa föll bort, allt för att applikationen skulle bli precis som Admeta ville ha den. Eftersom det hela tiden tillkom nya bitar under gränssnitts- och kravutvecklingen fick den till slut frysas till förmån för implementationen, även om det fortfarande fanns ett flertal idéer kvar. Detta var viktigt för att inte ursprungsidéen med systemet skulle falla bort och att systemet inte skulle växa sig för stort. Under implementationen ifrågasattes vissa delars funktionalitet. Dessa blev tvungna att ändras eftersom de inte 12 (27)

interagerade med de nya bitarna i applikationen på ett förtjänstfullt vis. När programflödet i applikationen var färdigutvecklat kunde kraven fastställas och utveckling av databasen påbörjades. 4.4 Användargränssnitt Ett gränssnitt definieras som en förbindelse mellan olika enheter i ett datasystem. Användargränssnittet, eller GUI:t som man ofta säger, efter den engelska termen Graphical User Interface, är systemets ansikte utåt och är det som definierar vad som kan göras i systemet. GUI:t jobbar mot ytterligare ett gränssnitt som i sin tur jobbar mot ett mycket välkänt gränssnitt, nämligen SQL som är standard för kommunikation med relationsdatabaser. Alla dessa gränssnitt har en uppsättning regler för hur data som flödar får anropas och returneras. Gränssnittet som användaren jobbar mot var det första som utvecklades i systemet. Anledningen till att vi valde GUI:t som första steg i utvecklingen var att vi snabbt fick en bild av vilka behov och krav Admeta hade av systemet. Det skapades först genom skisser och växte så småningom fram till ett ickefunktionellt system. Panelerna formgavs och de tilltänkta användarna gav ständigt förslag på förbättringar och förändringar i gränssnittet. Detta var nödvändigt för att vi skulle introduceras till utvecklingsverktyget Visual Studio.NET, till Admetas affärsverksamhet och till hur de tänkt använda systemet. Med den inblick vi fick var det lättare att komma med förslag och förbättringar till systemet. Det var nyttigt att jobba så pass nära användarna eftersom de innehar mest kunskap om hur systemet kommer att användas framöver och hur de vill att det skall fungera. Det färdigställda användargränssnittet underlättade utformningen av de funktionella kraven för systemet. I figur 4.2 visas en stödgraf för GUI:t där relationen mellan de olika formulären, databasen och logiksskiktet kan beskådas. Figur 4.2: Stödgraf för GUI:t Login_frm: Formulär som visar inloggning för användare. 13 (27)

Main_frm: Formulär för huvudfönstret där användaren sköter det mesta av arbetet. AddModContact_frm: Formulär för att lägga till eller modifiera kontaktperson. ImportContact_frm: Formulär för att importera befintlig kontakt till klient. AddActivity_frm: Formulär för att lägga till en multiaktivitet för flera klienter. 4.5 Logik Logiken (figur 4.3) handhar de funktioner och anrop som kommunicerar mellan databasen och användargränssnittet. Det förmedlar intelligens till GUI:t och är ej synligt för användaren. Figur 4.3: Stödgraf för logik. Database_c: Logikklass för hantering av in- och utdata till databasen. Upprätthåller även koppling till databasen. 4.6 Databasschema Det första steget i designen av databasen var att utifrån design- och kravspecifikationsarbetet ta reda på vilka data som skall sparas och bearbetas i applikationen. Utifrån den informationen utvecklades en konceptuell datamodell. Ett exempel på en konceptuell datamodell är ett EER-diagram och det var vad vi valde att utgå ifrån. Se Appendix B. EERdiagrammet ger en överskådlig blick av databasen, dess primärnycklar och samband mellan de olika entitetstyperna. 4.6.1 Databaskoppling För att koppla upp mot den egenutvecklade databasen behövdes en databaskoppling. Det fanns flera möjliga alternativ för detta. Det går att använda både OLEDB och ODBC.NET komponenter i Visual Studio. OLEDB har stora begränsningar och passade ej vårt projekt, medan ODBC är ett stort och avancerat paket som innehåller väl beprövad teknik. Vi fann dock att paketet var något överdimensionerat för vårt projekt och valde att titta närmare på andra paket som tillhandahöll MySQL-kopplingar. De vi fann var Core Labs MySQLDirect.NET Data Provider 2.00 och MySqlDriverCS 3.0.13. Core Labs tillhandahöll en mycket väl fungerande MySQL-koppling med mycket hjälp medan MySqlDriverCS, till en början, var svårförståeligt och hade en begränsad hjälp. Den största skillnaden låg i att Core Labs paket ej var kostnadsfritt medan MysqlDriverCS var ett projekt med öppen källkod och fick användas fritt. Vårt val föll på det senare alternativet allteftersom vi fick en större inblick i de båda paketens funktionalitet. För mer information om databaskopplingen se [17]. 4.6.2 Databasens uppbyggnad Databasen utgör en central del av programmet då all data lagras, hämtas och ändras däri. Den består av tretton olika entitetstyper. En av dessa entitetstyper är user, som används för att hantera 14 (27)

användare. Den håller koll på vilka olika användare systemet har och vilka rättigheter de har. I databasen finns också ett kundregister. Varje kund är lagrad i entitetstypen client. En kund har adresser, en besöksadress och en faktureringsadress. Ibland är dessa likadana. Adress är alltså en eller två entitetstyper som ett företag kan ha. Ett företag representeras av så kallade kontaktpersoner. En kontaktperson kan tillhöra flera företag och ett företag kan ha flera kontaktpersoner. Att en kontaktperson kan tillhöra flera företag är sällsynt men kan förekomma bland media- och webbyråer som har hand om kunders reklamannonsering. Under entitetstypen contactp sparas all nödvändig data för kontakt med personen i fråga såsom telefonnummer, fax, e-post osv. Tanken med programmet var att det skulle kunna hantera offerter, kontrakt och fakturor. Självfallet har dessa modellerats som egna entitetstyper. Alla offerter lagras i databasen under entitetstypen busprop. Entitetstypen contract har två subklasser i yearcontract och campcontract. Dessa representerar de olika typer av kontrakt som kan skrivas. En faktura, entitetstypen kallad invoice, kan bestå av flera olika artikelnummer. Dessa lagras som en egen entitetstyp, article. Ett CRM-system måste även ha kontroll på alla aktiviteter som sker gentemot ett företag eller en kontaktperson. Därför finns entitetstypen activity, som har en subklass support. Subklassen är en aktivitet i sig, men sparar även supporttid och liknande data som kan vara av intresse. En egen entitetstyp skapades även för noteringar som kallades notes. De flesta entitetstyper har någon form av notering som referar hit. Entitetstypen består endast av ett textfält av typen blob och ett unikt nummer för just den noteringen. För en utförligare beskrivning av databasens uppbyggnad se Appendix B och C. 15 (27)

5 Applikationen Detta kapitel visar olika typer av formulär och paneler som ingår i applikationen. Det förklaras även vilken funktionalitet de har samt hur de är avsedda att användas. 5.1 Login Den första sidan man möts av när man startar Admeta Sales Manager är ett fönster för att logga in i systemet (figur 5.1). Fönstret är uppbyggt av två textboxar där inloggningsnamn och lösenord skall anges och med förklarande text för var och en av dem. Det finns även två knappar där den ena leder till validering för de angivna uppgifterna i textboxarna och den andra till att programmet avslutas. Om man anger rätt inloggningsnamn (E-mail), rätt lösenord (Password) samt trycker på knappen OK, så kommer man vidare in i systemet. Om man anger fel inloggningsnamn eller lösenord visas ett förklarande felmeddelande för det inträffade och textboxen med lösenordet rensas. Trycker man på knappen Quit avslutas applikationen. Figur 5.1: Login fönster Funktionen hos detta fönster är att inte släppa in någon obehörig i systemet. Till detta använder fönstret sig av en klass som håller kontakten med databasen och tar reda på om användaren är behörig till systemet genom att jämföra angivna uppgifter med de lagrade uppgifterna i databasen. 16 (27)

5.2 TreeView Tanken med Admeta Sales Manager är att användaren lätt skall få en överblick över de möjliga alternativ som finns. Detta gjordes möjligt genom att bygga upp systemet på så sätt att det alltid finns en möjlighet att nå huvudmenyn genom en så kallad trädlista (TreeView). Trädlistan döljs aldrig och vid enkelklick på önskat alternativ i trädet visas den tillhörande panelen till höger. 5.3 ListView Mycket av informationen i Admeta Sales Manager visas med hjälp av listor (ListView). Detta för att få en bra överblick och samla information kompakt (se figur 5.2). Elementen i de olika listorna är klickbara. Genom att klicka på ett element i listan länkas man till en annan panel för att se vidare information. Listorna är även sorterbara genom att klicka på den kolumn man önskar att sortera efter, både i stigande och fallande ordning. Många paneler har en liknande struktur och relevant information i listorna visas enbart för den behöriga användaren. Med detta menas att informationen som visas är specifik för den inloggade användaren och systemets administratörer. Figur 5.2: Startfönster för säljare 17 (27)

5.4 Inserter Vissa paneler används till att skapa nya poster i databasen. Exempel på detta är när t.ex. en ny kund skall läggas till i klientregistret (se figur 5.3) eller en ny kontaktperson skall skapas för en klient. Då en ny post skapas i databasen sker det med uppgifter från en panels textboxar, comboboxar, radiobuttons eller dylikt. Olika panelers upplägg för att lägga till data skiljer sig en hel del beroende på avsikten för panelen. Figur 5.3: Panel för att lägga till ny klient. 18 (27)

5.5 Sökning I vissa paneler används en sökmotor för att söka fram information ur databasen till en lista (se figur 5.4). Genom att ange den text som är relevant för det man vill få fram av sökningen, samt eventuellt markera vilken typ av information man söker, letar sökmotorn i databasen efter matchande information. Av de data som överensstämmer väljs vissa poster ut och visas sedan i listan. Uppläggen mellan olika panelers sökmotorer skiljer sig en del då de är avsedda att användas i olika syften och visa olika resultat. Figur 5.4: Sökning bland de klienter som finns i databasen 19 (27)

5.6 Kundmeny Fliken för översikt över kontaktpersoner och historik över aktiviteter är ett exempel på hur panelen är uppbyggd för en specifik klient (se figur 5.5). Informationen som visas i listorna är klickbara element för att vara modifierbara och för att de skall kunna visa mer information om de klickas. Listan har även möjligheten att avgränsa historiken med hjälp av från- och tilldatum. Överst i panelen visas kort men väsentlig information angående klienten, som är angiven under fliken Client info. Hyperlänkarna i fönstret är klickbara och dessa leder till andra paneler eller öppnar nya fönster. Figur 5.5: Överblick över kontaktpersoner och aktiviteter för specifik klient. 20 (27)

5.7 Updater Viss information behöver uppdateras med tiden. All information kan inte uppdateras, men ett bra exempel på något som kan behöva modifieras är klienters kontaktinformation. För att uppdatera information behöver man bara ändra de uppgifter som inte överensstämmer längre i den redan angivna informationen och bekräfta det med ett klick på knappen Modify. Den tidigare informationen som inte ändrades finns kvar i databasen och den nya informationen som angavs ersätter den föregående. Figur 5.6: Panel som visar kundinformation för specifik klient. 21 (27)

5.8 Chart Den sista typen av panel som används i applikationen är den som används för statistik (se figur 5.7). Panelen är uppbyggd av en lista som visar den data som grafen återger. Det finns även möjlighet att välja mer specifikt vilken typ av data som skall visas genom att göra olika val bland dem som finns eller genom att söka fram en specifik klient. Figur 5.7: Panel som visar statistik för Supporttid. 22 (27)

6 Analys 6.1 Lärdomar I examensarbetet agerade Admeta AB kund och vi utvecklare. Examensarbetet fick ytterligare en dimension eftersom ingen specifikation för applikationen fanns klar från början. Utvecklingen av specifikationen blev alltså en stor del i examensarbetet. Genom det upplägget fick vi en bra möjlighet att lära oss tolka en kunds önskemål och utveckla ett system utifrån dem. Det gav oss också en bra syn på hur det framtida arbetslivet kan komma att se ut med kunder som bara vet på ett ungefär vad de vill ha. Mycket av arbetet som konsult går åt till att tänka ut smidiga lösningar och reda ut en kunds alla luddiga krav. Att vara duktig på teknik är inget unikt, men att vara duktig på teknik och att förstå kundernas behov är något som är väldigt unikt och eftertraktat. (Leif Jägerbrand) 6.2 Prioritering Målet från början var att färdigställa systemet. Allt eftersom designen utvecklades så växte även kraven på hur applikationen skulle fungera och beteendet för den. Det som från början bara såg ut att vara ett faktureringsprogram med avstämning för betalda fakturor hade utvecklats till ett CRM-system som innefattar allt som rör en kund. Vi märkte tidigt att utvecklingen skulle bli väldigt tidsomfattande, så därför prioriterades viss funktionalitet framför annan. Detta är också något som senare förmodligen kommer att inträffa i arbetslivet. Detta är ett vanligt fenomen inom programvarubranschen. (Leif Jägerbrand) 6.3 Utvecklingen En svårighet var att vi aldrig använt utvecklingsverktyget Visual Studio.NET tidigare. Detta blev inte ett så stort problem som vi trott från början, då vi lärde oss mycket av verktyget under designfasen. Vi kände även att det var nyttigt att få lära oss ett nytt utvecklingsverktyg, då vi i stora drag bara använt oss av Borlands produkter under studietiden. Eftersom verktyget Visual Studio.NET är väldigt omfattande hann vi bara lära oss de delar som var nödvändiga för utvecklingen av applikationen. Erfarenheten av att ha jobbat i den miljön uppskattar vi väldigt och anser vi vara extremt viktig. Många, stora och små, projekt utvecklas idag i.net-miljön och även om vi bara fått en försmak av det så är alla erfarenheter nyttiga. Vi fick även bevis för att de programmeringskunskaper vi fått under vår studietid varit av stort värde. Detta visade sig då vi valde C# som utvecklingsspråk, vilket ej ingick i någon kurs under utbildningen. Kan man bara grunderna i ett objektorienterat språk går det väldigt snabbt att sätta sig in i hur man använder sig av C#. Det som skulle visa sig vara mest problematiskt var utvecklingen av databasen. Som tur var läste vi en kurs i databaskonstruktion parallellt med examensarbetet vilket underlättade litteraturstudierna. 23 (27)